Skip to Content

Planet Drupal

Syndicate content
Drupal.org - aggregated feeds in category Planet Drupal
Updated: 17 hours 54 min ago

Palantir: The Secret Sauce podcast, Ep. 01

20 January 2016 - 9:49am

This is the first in our weekly bonus podcast that deals with shorter tips and resources that will help you with some straightforward facet of your web project. It's a compliment to our monthly, long-form podcast On the Air With Palantir. That's why we call it the Secret Sauce.

Some episodes will focus on strategy, design, metrics, or other such topics, while others will be more technical in nature. Whatever the focus, we want these to be useful for you, so we draw from our real world experience.

iTunes | RSS Feed | Download

This time around Allison Manley lets Larry Garfield take the mic to talk about Drupal 8, how you can prepare for it properly, and how the changes in this new version push us toward a content strategy approach. While applicable to anyone considering Drupal 8, this particular episode is mostly technical in nature and geared more toward site builders and developers.

Look for the Secret Sauce bonus podcast released weekly on Tuesdays.

Want to talk Drupal 8, and see how our consulting services can get you on the right path? Let's schedule a time to talk.

Categories: Drupal

Drupal.org Featured Case Studies: City of Chicago, Office of the City Clerk Website

20 January 2016 - 9:16am
Completed Drupal site or project URL: http://www.chicityclerk.com

Chicago’s Office of the City Clerk (“OCC”) is the most visited office in Chicago government. Citizens regularly use the OCC’s primary website to get information about how to purchase Chicago city vehicle stickers, search prior City Council agendas and legislation, and tune in for the live streaming of Chicago City Council meetings.

The office is known for its technological innovation: it recently moved the purchase of Chicago city vehicle stickers to a year-round online purchasing system, replacing the nearly century-old process of having citizens stand in line once a year to purchase such stickers in person. That mission of innovation was not reflected in its old website, however. The old website was a mix of WordPress and custom PHP files, with document storage split across multiple domains.

On the old site, maintenance was difficult, with simple site content changes often requiring a knowledge of HTML and CSS that OCC staff didn’t have. Additionally, the site was not easily used from mobile devices, despite the fact that nearly 50% of the site traffic came from such devices. OCC knew that it needed an overhaul for its website in order to serve the residents of Chicago for years to come.

Key modules/theme/distribution used: Feed ImportCORSSecurity ReviewSecurity KitDraggableViewsViews DatasourceTeam members: Marc DeLayDrupalKellyTgjangelo
Categories: Drupal

ActiveLAMP: Creating a deployable Docker image with Jenkins - Part 4

20 January 2016 - 7:30am

My previous posts talked about getting your local environment setup using the Drupal Docker image with Vagrant. It’s now time to bake a Docker image with our custom application code within the container, so that we can deploy containers implementing the immutable server pattern. One of the main reasons we starting venturing down the Docker path was to achieve deployable fully baked containers that are ready to run in whatever environment you put them in, similar to what we’ve done in the past with Packer, as I’ve mentioned in a previous post.

Read more...
Categories: Drupal

Modules Unraveled: 152 What to Do About Drupal 6 End of Life on Feb 24th 2016 with David Snopek - Modules Unraveled Podcast

19 January 2016 - 11:00pm
Published: Wed, 01/20/16Download this episodeDrupal 6 End of Live
  • What does Drupal 6 EOL mean?
  • When is Drupal 6’s End-Of-Life (EOL)?
    • February 24th
  • Why is support for Drupal 6 being dropped by the Drupal project in the first place? (ie. why does our community even do this?)
    • What makes Drupal 6’s End-of-Life (EOL) different than previous ones (ie. Drupal 5)?
  • What, specifically, will happen after February 24th?
    • All D6 modules will be marked as “unsupported” on Drupal.org - which will mean the ‘update’ module will start telling you that ALL your modules are out-of-date
    • Also, the status information that the ‘update’ module uses could go away at any time - so, you’ll no longer be able to rely on that in general (myDropWizard or another vendor MAY create a replacement for the ‘update’ module…)
    • The Drupal security team will no longer be making Security Advisories (or coordinating security releases)
    • In general, most module maintainers will no longer pay attention to Drupal 6 issues and will stop making new releases
  • What should people with Drupal 6 sites do?
    • Archive the site, or
    • Plan upgrade, and
    • If you can’t upgrade by February 24th, buy Drupal 6 Long-Term Support from one of the “official” vendors:
      • https://www.drupal.org/node/2646980
  • What makes the “official” vendors special (vs. any other vendor)?
    • Get confidential information from Drupal security team
    • Agree to follow security team processes and release all security patches publicly
    • Were vetted by the Drupal security team
  • How will the Drupal 6 LTS work?
    • Same process as security team - but work done by vendors rather than security team
    • Will publish patches on the D6LTS project:
      • https://www.drupal.org/project/d6lts
    • Likely, but not 100% decided:
      • Announce new patches on the D6LTS issue queue
      • Make new Pressflow 6 releases with the Drupal core patches
  • So, can the community get this without working with a vendor?
    • Yes!
    • But each vendor only supporting those modules their customers depend on
    • And what about security issues that hackers find first?
  • What does myDropWizard.com do? And how is your offer different than the other vendors?
    • “myDropWizard.com provides 24/7 support and maintenance from Drupal experts for a fixed monthly fee. We keep your site online, up-to-date and secure!”
    • Our Drupal 6 Long-Term Support offer:
      • http://www.mydropwizard.com/drupal-6-lts
      • making security fixes
      • fixing bugs
      • performing one-off maintenance and support tasks on request
      • getting your site back online in the case of an outage, and
      • remediation if your site gets hacked.
    • Basically, keep your site online and secure until you’re ready to upgrade - and we can help with a D7 or D8 upgrade as well
  • Technical questions about how we do what we do?
  • Your offering includes a whole bunch of stuff! Why don’t you have a “security updates only” offering?
Episode Links: David on drupal.orgDavid on TwittermyDropWizard.comEmail myDropWizardD6LTS ProjectD6 Long-term-support Official VendorsTags: Drupal 6Securityplanet-drupal
Categories: Drupal

DrupalCon News: Join us at the sprints

19 January 2016 - 3:17pm

If you’ve been using Drupal for more than a day, chances are that you’ve benefitted from some of the work done at DrupalCon sprints. Some of the most important breakthroughs for the project are made by sprinters at DrupalCon, and attending sprints is a great way to give back to the project you love.

Categories: Drupal

Agaric Collective: Moving towards a service oriented architecture

19 January 2016 - 1:25pm

In this installment of our case study about working with long term projects I will explain the architectural decisions made by our client, ZEIT ONLINE, regarding the relaunch of their digital subscription platform. Please refer to part 1 of this series for basic information about the project and a discussion of how to deal with the evolution of programming languages and operating systems.

Early on our client had decided to split up the platform into separate services that communicate via HTTP. This would allow them to develop those components using the most suitable technology for each, as well as allowing the services to progress more independently. The existing platform already used a separate service for authentication and storing user profile information. We took it from there and worked with the client to take it a step further.

First we identified the major logical components of the platform:

  • User accounts
  • Product presentation
  • Checkout
  • Order management (including data exchange with fulfillment provider)
  • Content delivery (via HTTP and E-Mail)

When considering how to divide the whole into services, we found it helpful to elaborate on the interfaces between them. The overall idea here is similar to what is accomplished by writing tests first: by grasping how you will consume an interface, it helps define the implementation more succinctly. In order to keep it simple we imposed a constraint on communications between services: When responding to any request, a service must not depend upon another HTTP request to a third party. That way developers would not have to deal with complex dependencies in their development environment and errors would be easy to locate.

Another important consideration was not to do too many things at the same time. Drupal 6 was fulfilling the roles of delivering content and product presentation to the client's satisfaction and the functionality was provided by a small amount of modules. As an upgrade of those parts to Drupal 7 would be straight forward, that was the direction taken for those items. A new client side order form had been developed already and was in experimental use as an alternative to the Ubercart checkout process.

That left the order management as a candidate for a new service. It needs to take orders from the client side order forms, store them, and send them to the fulfillment provider. It would also need to receive updates about the states of an order from the fulfillment provider. Agaric was asked to develop that component and picked Flask as a framework. That was a subjective choice, any other technology for building web applications could have been employed as well.

In upcoming posts I will cover the individual components and how they fulfill the goals of the overall architecture. ZEIT ONLINE is happy with the architecture and is currently moving further along those lines.

Categories: Drupal

Drupal @ Penn State: Implementing drupal_static on function with dynamic variables

19 January 2016 - 10:36am

Using drupal_static() on your helper functions is a great habit to get into when developing your modules. Drupal static ensures that your function will only run through its logic once during the bootstrap process. Depending on your functions logic, this can start saving lots of processing time if your function is being called multiple times during bootstrap or page load.

Implementing drupal_static

Let's take the following function for example. Here is helper function takes a url string from the ELMSLN network and breaks it up into identifiable parts.

Categories: Drupal

Drupal @ Penn State: Purespeed: Cache bin backends

19 January 2016 - 10:36am

Drupal is fantastic at caching itself (I mean, you've gotta be with a code base this hefty).  Drupal 8 will see the dawn of render cache in core which is why most metrics you see of D8 are uncached (because it's basically cheating its so fast cached). If you want to play around with Render Cache in D7, it can be done but still needs some work (Drupal.org actually runs Render Cache backport to handle comments in issue queues among other things).

Categories: Drupal

Drupal @ Penn State: Purespeed: PHP tuning

19 January 2016 - 10:36am

The Buzz is all about PHP 7, and rightly so, it's pretty incredible some of the performance metrics its pulling even relative to Facebook's HHVM. Brad Fisher wrote about a one-line installer to get up and going with PHP 7 if you want to play around with it. But then reality sets in...

Categories: Drupal

SitePoint PHP Drupal: Tutorial on Using Drupal 8 Plugin Derivatives Effectively

19 January 2016 - 10:00am

In an earlier tutorial, we looked at the Drupal 8 plugin system and how to create our very own custom plugin type. We’ve seen that much of the functionality declared via _info hooks in Drupal 7 has been replaced by these plugins. Our use case was very basic and it allowed each instance of such functionality to be declared manually via a new plugin class and associated form.

But what if we needed such instances declared dynamically depending on some factors external to our little subsystem? For example, when declaring _info hooks in Drupal 7, we can get a list of something, loop over it and declare a new item in the returned array for each individual something. The menu system does this in order to provide a new block for each menu that either comes with Drupal core or is later created through the UI.

So what about Drupal 8? We’ve seen that for each plugin of a certain type we need to declare a different PHP class. To create a new block, we need a new class. To create another block, we need another class. So where would that looping we see in Drupal 7 take place? The short answer to this is: within a plugin derivative.

In this article we will explore the long answer to that and learn what derivates are and how we can use them. For the latter, we will build an example inside the demo module that can be found in this git repository and which should hopefully help us better understand what’s going on. For a slightly more complex example, the Menu system is great as it provides an individual block for each of its menus (similar to Drupal 7 but using plugins).

What we are going to do is actually very simple. We are going to implement basic Node Block functionality by which for all the article nodes on our site we will have a block. Ridiculous? Sure. Should we be doing this for all the nodes on our site? Definitely not! But it’s a very basic implementation meant to keep things short and demonstrate the use of the plugin derivatives.

Plugin Derivatives

Plugin derivatives are the way through which a plugin of a certain type can be represented in the system as multiple instances of itself. In other words, a plugin can reference a deriver class which is responsible for providing a list of plugin definitions that are based on the initial plugin (start from the same base definition) but have slightly different configuration or definition data. The SystemMenuBlock we referred to above is a great example. It’s a single plugin which has as many derivatives as there are menus on the site.

To go a bit deeper, when a list of all the plugins of a certain type is requested, the plugin manager uses its discovery mechanism to load all the plugins of this type. If that mechanism is decorated with the DerivativeDiscoveryDecorator, the manager will be able to also retrieve derivatives. In order to do this, the derivative discovery looks for a deriver class on each plugin and, if it finds one, asks it for this list.

Continue reading %Tutorial on Using Drupal 8 Plugin Derivatives Effectively%

Categories: Drupal

Acquia Developer Center Blog: Drupal 8 Module of the Week: Services

19 January 2016 - 8:17am
Reena Leone

Each day more Drupal 7 modules are being migrated over to Drupal 8. In this series, the Acquia Developer Center is profiling some of the most prominent, useful modules that have crossed the chasm. This week: Services.

Kyle Browning, Drupalist since 2006 and Technical Consultant at Acquia, provides some insight on this Top 150 Drupal module he maintains.

What does the Services module do?

Tags: servicesdrupal 8acquia drupal planet
Categories: Drupal

Out & About On The Third Rock: #DPSX Jan 2016 meet up – Drupal Distribution for local government

19 January 2016 - 6:40am
Our January meet up was in the making since the #DPSX BoF at DrupalCon Barcelona in September 2015, the sign up for the 13th Jan event was great but logistical challenges mid December left quite a few folks confused. In retrospect the meet up needs a permanent abode, if you’d like to host the next […]
Categories: Drupal

Drupal core announcements: Work on Migrate UI, frontend testing, bug fixes, and more for Drupal 8.1.0

19 January 2016 - 6:35am

Drupal 8.1.0 will be released on April 20, 2016, so the beta phase for Drupal 8.1.x is coming up soon! We have until February 24 to make additions for Drupal 8.1.0. (After that, new additions will go toward 8.2.0 instead, which is currently planned for release in October.)

Our priorities for 8.1.x improvements are an experimental Migrate user interface, automated frontend testing, and most importantly bug and usability fixes.

Migrate user interface

Migrate is in core as an experimental module in Drupal 8.0.x, but it does not provide a user interface. The next step is to add the user interface as a core experimental module as well as fix a few important bugs, such as missing test coverage for the user interface and delaying migration entity saving for safer rollbacks.

Frontend testing

As we use more and more frontend components, we need to ensure that our frontend implementations are tested as well as we already test our backend. There were some prior steps introduced in Drupal 8 towards using Behat for frontend testing, and infrastructure support is almost ready. However there is more to do.

Bug and usability fixes

There are currently over 500 major bugs filed against Drupal 8 branches. The stability of Drupal 8 is always a top priority, so help with these major issues by helping create and test patches, as well as testing to determine if the issues are still relevant. Usability issues and contributed project blockers are also especially important.

Categories: Drupal

Yuriy Gerasimov: Visual testing for Migrations

19 January 2016 - 2:36am
Testing stale designs

Usually visual testing is very effective when website has stable design that should not be broken.

There are projects the whole idea of those is to keep design the same but to migrate the content to new platform. This is where visual regression testing can help a lot to identify very fast what pages are not yet complete and which ones are 100% accurate and can be shown to client.

 

Real life example Migrations

Consider the following example. We had a project where we needed to migrate from custom written CMS to Drupal 8 and we had to keep designs as they are. Because of the nature of the older CMS migration process was most complex part of the project. Legacy system was page based with possibility to place multible blocks around each page. In Drupal we had to migrate each block separately and place them in similar way on pages.

So our strategy during migration was to tackle low hanging fruits first. In this way we were able to migrate some of pages pretty quick and then evaluate more complex scenarios.

 

Visual testing of migrated page

The moment we were able to migrate all blocks on one page including its URL we were able to start using visual testing to find differences and fix them.

So we have quickly identified that our styles are little bit off, breadcrumbs are missing and header and footer menu items were not migrated fully.

Now we can run this test as often as we like and develop migration and styles of this page till they match exactly. This is something like Test Driven Development when first you write failing test and then implement code to make test pass. This is pretty much the same. We compare two pages and work on migrated on till it matches 100%.

Please share your thoughts about this way of using visual regression testing. Do you know any other interesting ways to use it? Please let us know in comments below.

Register at backtrac.io to try the tool yourself.

This is a cross post from http://backtrac.io/blog/visual-testing-migrations

Tags: drupal planet
Categories: Drupal

InternetDevels: Using Neo4j graph database: part 1

19 January 2016 - 1:56am

Let's keep getting the most useful web development tips from InternetDevels developers.
Here's the first blog post about Neo4j in which you will learn the basics.

Read more
Categories: Drupal

lakshminp.com: Writing your first Drupal service

19 January 2016 - 1:48am

We got a basic understanding of what a Drupal service is previously. Let's put that into action by creating a simple service in Drupal 8. Take note that this service what we are about to create doesn't do anything useful yet, and is written with a pedagogical purpose in mind.

This service will list a few best selling books from Leanpub. First, to deal with all the boilerplate of creating a module using DrupalConsole. Never ever write a module from scratch by hand!

$ drupal generate:module // Welcome to the Drupal module generator Enter the new module name: > techbooks Enter the module machine name [techbooks]: > Enter the module Path [/modules/custom]: > Enter module description [My Awesome Module]: > My first service Enter package name [Custom]: > Enter Drupal Core version [8.x]: > Do you want to generate a .module file (yes/no) [no]: > no Define module as feature (yes/no) [no]: > no Do you want to add a composer.json file to your module (yes/no) [yes]: > no Would you like to add module dependencies (yes/no) [no]: > no Do you confirm generation? (yes/no) [yes]: > yes Generated or updated files Site path: /var/www/html/drupal-8.0.2 1 - modules/custom/techbooks/techbooks.info.yml

The next step is to write a service configuration in our module. This configuration dictates how the service class will be initialized and how it can be called from code. The Drupal convention is to write this in a <module-name>.services.yml.

services: techbooks.listbooks: class: Drupal\techbooks\ListBooks

The services configuration part begins with services: and lists all the services provided by our module. In our case, we have just one service. We give it a name, techbooks.listbooks. Its a good idea to namespace services, which can be done by prefixing a namespace name followed by a dot. The class tells Drupal what class to call to create the service. This should be the fully qualified name of the class. The services YAML file can also store any service related information as well. All the book related data like title, author etc. is stored in the same file.

parameters: leanpub.booklist: - {title: 'The Elements of Data Analytic Style', author: 'Jeff Leek', url: 'https://leanpub.com/datastyle'} - {title: "Build APIs You Won't Hate", author: 'Phil Sturgeon', url: 'https://leanpub.com/build-apis-you-wont-hate'} - {title: 'Easy Laravel 5', author: 'W. Jason Gilmore', url: 'https://leanpub.com/easylaravel'} - {title: 'Ansible for DevOps', author: 'Jeff Geerling', url: 'https://leanpub.com/ansible-for-devops'} - {title: 'Principles of Package Design', author: 'Matthias Noback', url: 'https://leanpub.com/principles-of-package-design'} - {title: 'Modernizing Legacy Applications In PHP', author: 'Paul M. Jones', url: 'https://leanpub.com/mlaphp'} - {title: 'Front-End Fundamentals', author: 'Carwin Young, Joe Fender', url: 'https://leanpub.com/front-end-fundamentals'} - {title: 'Talking with Tech Leads', author: 'Patrick Kua', url: 'https://leanpub.com/talking-with-tech-leads'}

We shall come back in a bit on how we will use this data. Note that creating a service is also mostly boilerplate code. Hence, we can avail Drupal Console to do the job for us and fill out the custom details.

$ drupal generate:service // Welcome to the Drupal service generator Enter the module name [techbooks]: > Enter the service name [techbooks.default]: > techbooks.listbooks Enter the Class name [DefaultService]: > ListBooks Create an interface (yes/no) [yes]: > no Do you want to load services from the container (yes/no) [no]: > no Do you confirm generation? (yes/no) [yes]: > yes Generated or updated files Site path: /var/www/html/drupal-8.0.2 1 - modules/custom/techbooks/techbooks.services.yml 2 - modules/custom/techbooks/src/ListBooks.php Rebuilding cache(s), wait a moment please. [OK] Done clearing cache(s).

We have defined a service, but haven't exactly told Drupal what it does. For this, we have to flesh out the ListBooks class inside the module's src/ directory.

namespace Drupal\techbooks; /** * Class ListBooks. * * @package Drupal\techbooks */ class ListBooks { public function getBooks() { return t('All your books will be listed!'); } }

Once you have defined this service and enabled the module, you can use it anywhere in your code by invoking the service:

$book_list = \Drupal::service('techbooks.listbooks')->getBooks();

Drupal creates an instance of your listbooks service and fetches that instance on every call to the service. It effectively calls getBooks() of that instance, which returns a string. Let's add a route for listing books.

If you hit /techbooks in your browser, you should get this:

Not a lot happening there. Let's actually list some books!

Services can take in parameters while initializing. They are just plain PHP classes in disguise after all! Let's pass the book list we defined earlier in the yaml file as a parameter to the listbooks service.

services: techbooks.listbooks: class: Drupal\techbooks\ListBooks arguments: ["%leanpub.booklist%"]

The only change is the arguments property. We refer to the leanpub.booklist property as the argument. The enclosing % is to indicate that it is an internal variable/property. Also, notice that we wrap the argument within quotes, failing which it will be interpreted as a literal string. For example, arguments: [leanpub.booklist] will send the string "leanpub.booklist" as argument to the ListBooks class, which is not what we want!

Let's modify the ListBooks class to take in the arguments.

class ListBooks { public function __construct($books) { $this->books = $books; } public function getBooks() { return $this->books; } }

Changing the controller code accordingly,

public function bookList() { $book_list = \Drupal::service('techbooks.listbooks')->getBooks(); $render = ''; foreach($book_list as $book) { $render .= '<div><span>Title: ' . $book['title'] . '</span></div>'; $render .= '<div><span>Author: ' . $book['author'] . '</span></div>'; } return [ '#type' => 'markup', '#markup' => $render ]; }

Now, our /techbooks page actually lists books!

It doesn't look pretty and all, but hey, we just created our first Drupal service :)

You can grab the code for this example from github and checkout the basic-service tag to see it come to life.

Resources Drupal, Drupal 8, Drupal Planet
Categories: Drupal

hussainweb.me: My Drupal Story – How I came for code and stayed for community

18 January 2016 - 9:57pm
As taglines go, I know this is heavily cliched but it happens to be true to every letter. I can't think of any better way to describe the overall Drupal ecosystem as "Come for the code, stay for the community."
Categories: Drupal

DrupalCon News: Get ready for DrupalCon New Orleans

18 January 2016 - 5:37pm

Where y’at! The DrupalCon New Orleans site is here and ready for you to submit your proposals for trainings, scholarships, and grants.

Happening in the Big Easy this May, DrupalCon New Orleans is going to be a colorful, exciting expression of the Drupal Community’s diversity, creativity, and fun. New Orleans is a city unlike any other, and this DrupalCon promises to be exceptional. Join us for the first North American DrupalCon since the release of Drupal 8 for a healthy dose of culture, history, and all things Drupal blue.

Categories: Drupal

blog.studio.gd: Migrate to Drupal 8 from a custom site

18 January 2016 - 3:16pm
Migrate is now included in the Drupal core for making the upgrade path from 6.x and 7.x versions to Drupal 8.

Drupal 8 has two new modules :

- Migrate: « Handles migrations »
-Migrate Drupal : « Contains migrations from older Drupal versions. »
Categories: Drupal

blog.studio.gd: Inline Entity Display

18 January 2016 - 3:16pm
Handle referenced entity fields directly in the parent entity
Categories: Drupal


Google+
about seo