Feed aggregator

OSTraining: Drupal 8 is Close and So Are the 200 Free Videos

Planet Drupal - Wed, 14/10/2015 - 00:22

Last week the Drupal 8 community hit an important milestone with the first Release Candidate for Drupal 8.

What does "Release Candidate" mean? It means that this version is ready to be considered as the official release for Drupal 8. If no more critical bugs are found, then this will indeed become Drupal 8.0.

This is important milestone for OSTraining too. This week we're getting started on the 200 videos we'll release for free.

Categories: Elsewhere

Drupal Association News: FFW Signs On as Signature Supporting Partner

Planet Drupal - 1 hour 6 min ago

We couldn’t be more pleased to announce that our friends over at FFW have signed on to be Signature Supporting Partners, the highest level of partnership currently available with the Drupal Association. They’re our first North American company to sign on for the package, and we’re incredibly happy that they’re on board.

"The best part of Drupal is that we get to work with so many great people. Our friends at FFW are exactly that, and I am thrilled to celebrate their support for Drupal and the Association,” said Holly Ross, the Drupal Association’s Executive Director.

FFW is a digital agency specializing in data-driven Drupal solutions. "We believe it’s important to give back to the Drupal community because Drupal offers us amazing opportunities to deliver quality solutions to our clients,” said FFW Global CEO Michael Drejer.

FFW’s Signature Supporting Partnership is hugely beneficial not only to the Drupal Association, but to the Drupal community as a whole: by supporting the Drupal Association, FFW is helping fund the maintenance and continual improvement of Drupal.org, and is supporting the community by funding important community initiatives like Community Cultivation Grants, Global Training Days, and more.

What is the Supporting Partner Program?

The Supporting Partner Program includes more than 60 companies from around the world. Partners enjoy enhanced promotional services from the Drupal Association, such as brand visibility on Drupal.org, select access at premier events like DrupalCon, and increased publicity via various online social platforms. For their elevated contributions to the program, Signature Partners will receive upgraded promotional services.

To join FFW as one of the Drupal Association's contributing partners, start by learning more about the Supporting Partner Program.

And to join us in thanking FFW for its partnership, we encourage you to send this pre-populated tweet, or to say thanks in the comments of their blog post.

Categories: Elsewhere

OSTraining: What is the Drupal 7 Dashboard?

Planet Drupal - 3 hours 28 min ago

When you login to a Drupal site, the very first link you will see in the admin bar is "Dashboard".

Even though it's the first link, few people seem to use it, perhaps because they don't fully understand what it does. Perhaps as a result, the Dashboard won't be included in Drupal 8.

In this video, taken from our Better Drupal Administration class, Robert explains what the Dashboard does. It really can be a helpful control panel for users of small sites.

Categories: Elsewhere

Drupal core announcements: Critical office hours cancelation (or repurposing) discussion in g.d.o/mentoring

Planet Drupal - 6 hours 42 min ago

Heads up, discussion of canceling or repurposing Friday critical office hours is at https://groups.drupal.org/node/486638

Categories: Elsewhere

Drupal Commerce: Contributor Spotlight: Lars Olesen

Planet Drupal - 7 hours 37 min ago

Ask anyone involved with Drupal Commerce, or Drupal itself what the single greatest thing that keeps them working with the software, and they'll likely say: "THE COMMUNITY". The Drupal Project has thrived because it's built on the backs of a huge community of developers, site builders and users who are all passionate about improving the software the use daily to make a living. The community values and fosters a culture of contribution, where everyone who uses Drupal has an opportunity to pay help out and give back.

...And while no one contribution is valued any greater (or less than) any other, we're taking this opportunity to highlight some exceptional work, presented here in our


Lars Oleson is a native of Denmark and a school teacher by trade. He's also the co-maintainer of Commerce Kickstart v2 and a community member who has brought a lot of positive changes to the project.

Categories: Elsewhere

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

Planet Drupal - 7 hours 44 min ago
Ressources Migrate in Drupal 8

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. »

None of these module have a User Interface.

« Migrate » contains the core framework classes, the destination, source and process plugins schemas and definitions, and at last the migration config entity schema and definition.

« Migrate Drupal » contains implementations of destination, sources and process plugins for Drupal 6 and 7 you can use it or extend it, it's ready to use. But this module doesn't contain the configuration to migrate all you datas from your older Drupal site to Drupal 8.

The core provides templates of migration configuration entity that are located under each module of the core that needs one, under a folder named 'migration_templates' to find all the templates you can use this command in your Drupal 8 site:

To make a Drupal core to core migration, you will find all the infos here : https://www.Drupal.org/node/2257723 there is an UI in progress for upgrading.


A migration framework

Let have a look at each big piece of the migration framework :

Source plugins

Drupal provides an interface and base classes for the migration source plugin :

  • SqlBase : Base class for SQL source, you need to extend this class to use it in your migration.
  • SourcePluginBase : Base class for every custom source plugin.
  • MenuLink: For D6/D7 menu links.
  • EmptySource (id:empty): Plugin source that returns an empty row.
  • ...
Process plugins

There is the equivalent of the D7 MigrateFieldHandler but this is not reduced to fields or to a particular field type.
Its purpose is to transform a raw value into something acceptable by your new site schema.

The method transform() of the plugin is in charge of transforming your $value or skipping the entire row if needed.
If the source property has multiple values, the transform() will happen on each one.

Drupal provides migration process plugin into each module of the core that needs it (for the core upgrade),
To find out which one and where it is located you can use this command :

Destination plugins

Destination plugins are the classes that handle where your data are saved in the new Drupal 8 sites schemas.

Drupal provides a lot of useful destination classes :

  • DestinationBase : Base class for migrate destination classes.
  • Entity (id: entity) : Base class for entity destinations.
  • Config (id: config) : Class for importing configuration entities.
  • EntityBaseFieldOverride (id: entity:base_field_override): Class for importing base field.
  • EntityConfigBase : Base class for importing configuration entities.
  • EntityImageStyle (id: entity:image_style): Class for importing image_style.
  • EntityContentBase (id: entity:%entity_type): The destination class for all content entities lacking a specific class.
  • EntityNodeType: (id: entity:node_type): A class for migrate node type.
  • EntityFile (id: entity:file): Class for migrate files.
  • EntityFieldInstance: Class for migrate field instance.
  • EntityFieldStorageConfig: Class for migrate field storage.
  • EntityRevision, EntityViewMode, EntityUser, Book...
  • And so more…
Builder plugins:

Builder plugins implement custom logic to generate migration entities from migration templates. For example, a migration may need to be customized based on the data that is present in the source database; such customization is implemented by builders.

This is used in the user module, the builder create a migration configuration entity based on a migration template and then add fields mapping to the process, based on the data in the source database. (@see DrupaluserPluginmigratebuilderd7User)

Id map plugins:

It creates one map and one message table per migration entity to store the relevant information.
This is where rollback, update and the map creation are handled.
Drupal provides the Sql plugin (@see DrupalmigratePluginmigrateid_mapSql) based on the core base class PluginBase.

And we are talking only about core from the beginning.
All the examples (That means docs for devs) are in core !

About now :

While there *almost* a simple UI to use migration in Drupal 8 for Drupal to Drupal, Migrate can be used for every kind of data input. The work is in progess for http://Drupal.org/project/migrate_plus to bring an UI and more source plugins, process plugins and examples. There already is the CSV source plugin and a pending patch for the code example. The primary goal of « migrate plus » is to have all the features (UI, Sources, Destinations.. ) of the Drupal 7 version.

Concrete migration (migration with Drupal 8 are made easy)

I need to migrate some content with image, attached files and categories from custom tables in an external SQL database to Drupal.

To begin shortly :
  • Drush 8 (dev master) and console installed.
  • Create the custom module (in the code, I assume the module name is “example_migrate”):
    $ Drupal generate:module
    or create the module by yourself, you only need the info.yml file.
  • Activate migrate and migrate_plus tools
    $ Drupal module:install migrate_tools
    $ drush en migrate_tools
  • What we have in Drupal for the code example :
    • a taxonomy vocabulary : ‘example_content_category’
    • a content type ‘article’
    • some fields: body, field_image, field_attached_files, field_category
  • Define in settings.php, the connexion to your external database:

We are going to tell migrate source to use this database target. It happens in each migration configuration file, it’s a configuration property used by the SqlBase source plugin:

source: plugin: id_plugin #Your plugin that extend SqlBase target: db_migration

This is one of the reasons SqlBase has a wrapper for select query and you need to call it in your source plugin, like $this->select(), instead of building the query with bare hands.

N.B. Each time you add a custom yml file in your custom module you need to uninstall/reinstall the module for the config/install files to imports. In order to avoid that, you can import a single migration config file by copy/paste in the admin/config configuration synchronisation section.

The File migration

The content has images and files to migrate, I suppose in this example that the source database has a unique id for each file in a specific table that hold the file path to migrate.

We need a migration for the file to a Drupal 8 file entity, we write the source plugin for the file migration:

File: src/Plugin/migrate/source/ExampleFile.php

We have the source class and our source fields and each row generate a path to the file on my local disk.

But we need to transform our external file path to a local Drupal public file system URI, for that we need a process plugin. In our case the process plugin will take the external filepath and filename as arguments and will copy it to the public file system and return the new Drupal URI.

File: src/Plugin/migrate/process/ExampleFileUri.php

We need another process plugin to transform our source date values to timestamp (created, changed), as the date format is the same across the source database, this plugin will be reused in the content migration for the same purpose:

File: src/Plugin/migrate/process/ExampleDate.php

For the destination we use the core plugin: entity:file.

Now we have to define our migration config entity file, this is where the source, destination and process (field mappings) are defined:

File: config/install/migrate.migration.example_file.yml

We are done for the file migration, you can execute it with the migrate_tools (of the migrate_plus project) drush command:

The Term migration

The content has categories to migrate.
We need to import them as taxonomy term, in this example I suppose the categories didn't have unique ids, it is just a column of the article table with the category name…

First we create the source :

File: src/Plugin/migrate/source/ExampleCategory.php

And we can now create the migration config entity file :

File: config/install/migrate.migration.example_category.yml

This is done, to execute it :

The Content migration

The content from the source has an html content, raw excerpt, image, attached files, categories and the creation/updated date in the format Y-m-d H:i:s

We create the source plugin:

File: src/Plugin/migrate/source/ExampleContent.php

Now we can create the content migration config entity file :

File: config/install/migrate.migration.example_content.yml

Finally, execute it :

Group the migration

Thanks to migrate_plus, you can specify a migration group for your migration.
You need a to create a config entity for that :

File: config/install/migrate_plus.migration_group.example.yml

Then in your migration config yaml file, be sure to have the line migration_group next to the label:

So you can use the command to run the migration together, and the order of execution will depend on the migration dependencies:

I hope that you enjoyed our article.

Best regards,

Delta https://www.drupal.org/u/delta

We at Studio.gd are Drupal experts since 2009.

Categories: Elsewhere

Drupalize.Me: How to Log Messages in Drupal 8

Planet Drupal - 8 hours 12 min ago

Developers familiar with Drupal 7 will also be familiar with watchdog(), an API function that allows you to create a log message that appears on the Reports page in the Drupal administrative UI. Implementing D7’s hook_watchdog allows module developers to customize the destination of these log messages. In Drupal 8, both functions are replaced by a PSR-3-compatible logging interface (change notice).

Categories: Elsewhere

InternetDevels: How to Improve Your Website’s Navigation

Planet Drupal - 12 hours 40 sec ago

First-class navigation is the keystone of a pleasing web design and satisfied users. If you want your website to succeed, but don’t care about its navigation, you are flogging a dead horse! Without a captivating website layout and a good navigation structure, visitors won’t be able to find the needed information swiftly and smoothly. Luckily, we are going to provide you with eight golden rules you have to preserve when improving your UI design and website’s navigation.

Read more
Categories: Elsewhere

ERPAL: Preventing problems on your Drupal site before they happen

Planet Drupal - 12 hours 46 min ago

What do you do when your site goes down, or is hacked, or gets unreasonably slow?

Well, if your site is important to your business or organization or life, then you drop everything and work as long as it takes to fix the problem!

This can be super stressful, and keep you up into the late hours of the night.

Wouldn't it be great to discover these issues before they become a problem and fix them on your own time? Performing a site audit of your Drupal site can help you do just that!

While hiring a Drupal professional to perform the audit would give you more comprehensive results, it can also be expensive.

Luckily, there are some useful tools that you can use to perform an automated audit yourself!

In this article, we'll look at three simple tools to perform a rudimentary site audit.

What is a Drupal site audit?

At myDropNinja.com, performing site audits is a very important part of what we do. When we take on a new support and maintenance client, we need to quickly learn about the current state of their site!

(And starting last month, we've been giving away free site audits - so we've been doing quite a few of them lately! ;-))

A site audit can look at many different things (including SEO, custom modules/themes, etc) but the fundimental goal of a site audit is to answer these questions:

  • Is my site following Drupal best practices?
  • Is it secure?
  • How can I make it faster?
  • What can I do (or look into) to improve my site and make it easier to maintain?

While some things can only be evaluated manually by a human being, there are some basic things that can be checked automatically!

The "Hacked!" module

The "Hacked!" module checks to see if Drupal core or any of the contributed modules or themes on your site have been modified from their original versions.

This is useful for two reasons:

  1. Checking to see if your site was hacked, and the code files changed. Or,
  2. Checking to see if you applied any patches, which can affect the long-term maintenance burden of your site (ie. you'll need to remember to re-apply patches when updating, and check for bugs/security holes in the patches).

If you also install the "Diff" module, it'll show you the line-by-line differences in the code, which can make it easier to discern a nefarious change from a benign patch.

After installing the module, visit Admin -> Reports -> Hacked (or the path /admin/reports/hacked) and you'll see a report like:

The "Security Review" module

The "Security Review" module automatically checks your site for Drupal security best practices, and common easy-to-make mistakes that render your site insecure.

After installing it, visit the user permissions page (at Admin -> People -> Permissions or the path /admin/people/permissions) and make sure that only trusted users have the "Access security review pages" permission. The report it generates can contain sensitive information!

Then go to Admin -> Reports -> Security review (or the path /admin/reports/security-review) and click "Run checklist". It'll generate a report like this:

Be sure to click the "Details" link by any of the failing checks on the report to learn more and get information on how to fix them.

The most common critical issues that we've seen are enabling the PHP module or configuring text formats to allow untrusted users to input dangerous HTML tags. If your site suffers from either of these problems, you should try to address them ASAP!

You should also consider using the "Paranoia" module which makes it difficult (or impossible) to enable dangerous things on your site in the first place.

The "Site Audit" drush extension

We saved the best for last. :-)

While using the "Site Audit" drush extension is a little harder because it requires drush, the report it generates is by far the most comprehensive.

To install it, download and extract the .zip or .tar.gz file into your ~/.drush directory (if that directory doesn't exist, you'll have to create it) and then run drush cc drush.

Then run drush aa --html --bootstrap --detail > site_audit.html and when it's done, open the site_audit.html file in your web browser.

You'll see a report like this:

This covers many areas, including:

  1. Best practices
  2. Server configuration
  3. Caching
  4. Codebase
  5. Content
  6. Database
  7. ... and much more!

Keeping your site secure is not only about using the right tools but also about processes. Drupal moves quickly and if you maintain a site seriously, keeping your site updated and delivering Drupal updates continuously is the easiest task to prevent security issues. There is also a solution that automates Drupal updates with integration into your development and deployment processes to save your time.

Need help? Or want to dig deeper?

While these three tools are super powerful, we really only scratched the surface of all the things covered in a comprehensive site audit. Some other things include:

  • Checking for other signs the site was hacked (the "Drupalgeddon" module can find the tell tale signs of common exploits for that vulnerability, but there's other exploits as well)
  • Code review of custom code and themes (the PAReview.sh script can help a little with that)
  • Performance review
  • ... among many other things!

If you'd like some professional help, please feel free to contact us at support@mydropninja.com or via myDropNinja.com. Did I mention we're currently giving away free site audits? ;-) Availability is limitted, so request yours today!

David Snopek is a founder of myDropNinja.com and a long-time Drupal developer and community member. Among other things, he co-maintains the Panopoly distribution, is a member of the Drupal security team, and co-organizes the local Drupal meetup group in Milwaukee, WI.

Categories: Elsewhere

Drupal core announcements: Drupal 7 core release on Wednesday, October 14

Planet Drupal - 14 hours 53 min ago
Start:  2015-10-14 (All day) America/New_York Online meeting (eg. IRC meeting) Organizers:  David_Rothstein

The monthly Drupal core bug fix/feature release window was last week, but after being postponed by a few days will now be this week instead. Since it has been a while since the last release, I plan to release Drupal 7.40 this Wednesday, October 14.

The final patches for 7.40 have been committed and the code is frozen (excluding documentation fixes and fixes for any regressions that may be found in the next couple days). So, now is a wonderful time to update your development/staging servers to the latest 7.x code and help us catch any regressions in advance.

There are three relevant change records for Drupal 7.40 which are listed below. This is not the full list of changes, rather only a list of notable API additions and other changes that might affect a number of other modules, so it's a good place to start looking for any problems:

You might also be interested in the tentative CHANGELOG.txt for Drupal 7.40 and the corresponding list of important issues that will be highlighted in the Drupal 7.40 release notes.

If you do find any regressions, please report them in the issue queue. Thanks!

Upcoming release windows after this week include:

  • Wednesday, October 21 (security release window)
  • Wednesday, November 4 (bug fix/feature release window)

For more information on Drupal core release windows, see the documentation on release timing and security releases, and the discussion that led to this policy being implemented.

Categories: Elsewhere

OSTraining: Create a Hover Effect with CSS3 Transition and Transform Properties

Planet Drupal - 19 hours 44 min ago

One of our members wanted to reproduce the hover effect from the team's pictures in our About Us page.

In this tutorial, I'm going to show you how to use CSS to get same result. I'll also show you how to customize the animation.

Categories: Elsewhere

Arthur Foelsche: Sitespeed.io testing with CircleCi

Planet Drupal - 20 hours 9 min ago

If you're using a continuous integration service it is pretty easy to add in-browser site performance testing to your suite of tests. Sitespeed.io is a fantastic tool for analyzing the render processing time (among other things) for sites- far beyond just looking at the time totals but specifics such as paint times, DOM content load and complete times, and more. If you're doing javascript heavy work or lots of intergrations with asynchronous or third party services this can be really helpful for tracking the improvement- or degradation- of your work.

I'm using CircleCi as my continuous integration tool. This should work with services such as Travis as well. My circle.yml file adds the following items:

dependencies: pre: npm install -g sitespeed.io

And something like this test. Craft the URI to meet your testing environment, browser types, and number of test iterations to meet your needs.

test: override: - sitespeed.io -u http://SITE.LOCAL --budget cnf/sitespeed/budget.json -b chrome -n 3 -r $CIRCLE_ARTIFACTS/sitespeed --suppressDomainFolder --outputFolderName test

The test specifies performance budget file which sets the performance requirements. You can tune the specifications in this file for the characteristics that you're looking for- first paint time, final render time, etc. Your test results are put into the artifacts directory so you can browse them at some later point- here's where the artifacts are in the circle build:




And here's an actual report which has been run as part of the CircleCi build. 


Arguably the hardest part of this process is building the performance budget file which is tailored to your needs, particularly since running them on a CI server is going to have a different profile than your production environment.


Categories: Planet Drupal
Categories: Elsewhere

OSTraining: Using Docker with Drupal

Planet Drupal - 21 hours 38 min ago

At the end of 2014, one of the OSTraining team choose Docker as their favorite innovation of the year.

Why is Docker so great? Often developers discover code that’s working on a local machine may not work as expected in other environments.

Also a lot of time is often wasted in cases of new developer joining a team and configuring developers environments to work perfectly for the application you need to run.

Categories: Elsewhere

Drupal Easy: DrupalEasy Podcast 163 - Drupal Potato (David Rozas, Open-source contributing)

Planet Drupal - Mon, 12/10/2015 - 23:03
Download Podcast 163

David Rozas (drozas), PhD candidate at the University of Surrey and recent DrupalCon Barcelona keynote speaker joins Mike Anello, Ryan Price, and special guest co-host Anna Kalata (akalata) to discuss David's PhD research on open-source contributing as well as wrap-up of DrupalCon Barcelona.

read more

Categories: Elsewhere

Web Wash: Build a Blog in Drupal 8: Using Views

Planet Drupal - Mon, 12/10/2015 - 22:14

Just when you thought Drupal 8 couldn't get more powerful; I give to you Views in core. Yes, the most installed module in Drupal is now part of core.

No longer will you have to wait for Views to be upgraded to use the latest version of Drupal. Just install Drupal and start building your custom views page or block.

For people who don't know, Views allows you to list Drupal content. That's a simple explanation, but it doesn't give the module the respect it deserves.

For instance, you could create a page (/latest-reviews) which displays all the latest content by content type and sorted by created date. Using the module, you can query the site's content and display it in a block, table or page just to name a few.

Now that Views is part of core, it's used throughout the administration section. Take for example the Content (admin/content) and People (admin/people) pages. All of these are powered by Views.

In this tutorial, we'll continue building our blog site by adding in a few custom views. We'll create a listing of blog posts for the homepage, a "Recent blog posts" block and we'll enable Archive view which comes with Drupal but it's disabled.

Categories: Elsewhere

Wim Leers: Drupal 8's Dynamic Page Cache

Planet Drupal - Mon, 12/10/2015 - 20:00

Drupal 8 now has a Dynamic Page Cache. The Page Cache module only works for anonymous users, the Dynamic Page Cache module takes that a step further: it works for any user.

Since April 8, Drupal 8 had its Page Cache enabled by default. Exactly 5 months later, on September 8, the Dynamic Page Cache1 module was added to Drupal 8, and also enabled by default.


The Page Cache module caches fully rendered HTML responses — it assumes only one variant of each response exists, which is only true for anonymous users2. The innovation in 8 on top of 7’s Page Cache is the addition of cache tags, which allow one to use the Page Cache but still have instantaneous updates: no more stale content.

The Dynamic Page Cache module caches mostly rendered HTML responses — because it does not assume only a single variant exists: thanks to cache contexts, it knows the different variants that exist of each part of the page, and thus also of the final (fully assembled) page. During the rendering process, auto-placeholdering ensures that the parts of the page that are too dynamic to cache3 or are simply uncacheable are replaced with placeholders. These placeholders are only rendered at the very last moment. The Dynamic Page Cache module caches the page just before those placeholders are replaced.

So, conceptually speaking:

keyvalue Page Cache
  • URL
  • final response
  • cache tags
Dynamic Page Cache
  • URL
  • cache contexts
  • partial response
  • placeholders
  • cache tags
Page Cache ⟷ Dynamic Page Cache

This table also illustrates quite clearly the strengths and weaknesses of both: Page Cache is faster because it contains the final response, unlike Dynamic Page Cache which only contains a partial response, but thanks to that response not yet being personalized it can be used across users.

In other words: Dynamic Page Cache saves us less work, but in doing so, allows us to apply it in many more cases.


Drupal 8’s Page Cache can respond in constant time. So, for anonymous users, Drupal 8 already responds in constant (amortized) time.

With Dynamic Page Cache, Drupal 8 is now able to respond in constant amortized time + the time it takes to render the placeholders. Which means that most parts of most pages can be cached in the constant part (and it doesn’t matter how much content is in there!). The parts of the page that end up as placeholders are the ones you want to optimize, and if possible, avoid. (Also see BigPipe further down.)

On my machine (ab -c1 -n 1000, PHP 5.5.11, Intel Core i7 2.8 GHz laptop, warm caches, 15 nodes with one comment each, 10 of which are listed on the frontpage):

  • Without Dynamic Page Cache
    • Front page: 61.3 ms/request (16 requests/s)
    • node/1: 92.3 ms/request (10.8 requests/s)
  • With Dynamic Page Cache
    • Front page: 38.3 ms/request (26 requests/s)
    • node/1: 73.8 ms/request (13.5 requests/s)


The front page only contains a single placeholder (for messages). This makes it is a strong indicator of the lowest response times to expect: roughly 38 ms on my machine.

  • ~38 ms goes to bootstrapping, routing, route access checking, and of course retrieving the cached response from the Dynamic Page Cache.4
  • Compare that with the node/1 case: 35.5 more milliseconds are spent replacing placeholders there. Which means that we do some very expensive rendering there… and that is the comment form.5

As you can see: Dynamic Page Cache actually becomes a helpful assistant while developing: it surfaces the impossible-to-cache-and-expensive-to-render parts of the page!

Note that we do have an issue to make Dynamic Page Cache run much earlier, see more about that below.

Easily tenfold that on actual servers

The above is tested with a concurrency of 1 client, to ignore web server performance (Apache in my case). See e.g. Rasmus Lerdorf’s profiling of the Page Cache.


The real beauty is that it’s a win-win: enterprise (Acquia), medium, small, tiny (hobbyist) all win:

  • Enterprise sites get better tunability and reverse proxy/CDN-based hosting even for authenticated users
  • Tiny sites can handle more simultaneous authenticated users, and serve those faster

So my work was sponsored by Acquia, but benefits everyone!

People have been expressing concerns that Drupal 8 has become too complex, that it doesn’t care about site builders anymore, that it is only for enterprises, etc. I think this is a good counterexample — in fact an even stronger one than Page Cache being enabled by default: this was absolutely out of reach for the majority of Drupal 7 sites. Yet every Drupal 8 site will have this enabled by default.
Yes, we added the complexity of cacheability metadata, but that only affects developers — for whom we have good documentation. And most importantly: site builders reap the benefits: they don’t even have to think about this anymore. Manually clearing caches is a thing of the past starting with Drupal 8!

Drupal is very much like LEGO. Until Drupal 8, if you combined too many LEGO blocks, your Drupal site would become very slow. Setting up caching was very often prohibitively complex. Now the LEGO blocks must specify their cacheability metadata. Which allows Drupal to automate a huge portion of “making things fast”.

New possibilities for small sites (and shared hosting)

Smaller sites will be able to handle more authenticated users simultaneously. And have pages be much faster for those users.

Without any configuration.

Without any frustrating searching on the internet.

New possibilities for enterprise sites (and enterprise hosting)

On the other hand of the spectrum, enterprise hosting now gains the ability to tune: if they prefer to running caching infrastructure with enough storage capacity rather than rendering placeholders on the fly (i.e. more storage for less computation), then they can: just override the default configuration for auto-placeholdering conditions.

It also opens the door to — for the first time — caching responses for authenticated users in a CDN.

New possibilities for developers

The addition of cacheability metadata (cache tags, contexts and max-age), allow for greater insight and tooling when analyzing hosting, infrastructure, performance and caching problems. Previously, you had to analyze/debug a lot of code to figure out why something that was cached was not being invalidated when appropriate by said code.

Because it’s now all standardized, we can build better tools — we can even automatically detect likely problems: suspiciously many cache contexts, suspiciously low maximum ages, suspiciously frequent cache tag invalidations…

And finally, it makes it possible to do BigPipe-style rendering, making Drupal 8 the fastest Drupal yet:

Dynamic Page Cache in 8 vs. Authcache in 7

Dynamic Page Cache’s closest comparison in Drupal 7 is the Authcache module. It’s possible to achieve great performance with Authcache in Drupal 7, but it requires a huge amount of work: all code (contrib & custom) must be analyzed to ensure all aspects that cause variations in the output (rendered pages) are taken into account. All of these factors must then be passed to Authcache so that it can calculate its “authcache key” correctly. The “key properties” that you specify there are conceptually similar to Drupal 8’s cache contexts. However, it is very easy to miss anything, because it’s you as a site owner that is responsible for identifying all the variations (and corresponding key properties) across all modules across all pages6. By default, Authcache assumes the only thing that your site varies by, are a site’s base URL and a user’s roles. So unless your site is very simple (for example not even multilingual), you will need an enormous amount of knowledge/research in order to be able to use Authcache.

(For example, Drupal.org — which currently still runs on Drupal 7 — rolled out render caching of comments several months ago. It works very much like Authcache: you must specify the things that cause variations. One aspect (timezone) was forgotten, and it led to rather confusing broken output. If even Drupal.org’s very strong team can get it wrong, then what hope does a team with less expertise have?)

Dynamic Page Cache in 8 simply builds on the existing cacheability metadata concepts and infrastructure. There’s no need for custom hooks. There’s no possibility of something being forgotten as a site owner. It’s the individual modules’ responsibility now — and those modules know far better what they’re doing. The entire “analyze the entire codebase” phase is gone. And of course, Dynamic Page Cache also supports cache tags, so unlike Authcache in Drupal 7, responses cached in Dynamic Page Cache will actually be updated instantaneously.

In Drupal 8.0.0, Dynamic Page Cache runs after bootstrapping, routing and route access checking. Because Authcache makes certain simplifying assumptions, it can run before Drupal 7 has even fully bootstrapped, thus it is much faster most of the time7. We do have an issue to make Dynamic Page Cache run much earlier, which would result in a great speed-up: #2541284 — we will aim to do that in Drupal 8.x.0.

Finally, because it is enabled by default in Drupal 8, Dynamic Page Cache has one enormous advantage: it brings this functionality to all Drupal sites and all Drupal developers. All Drupal developers are thus heavily encouraged to specify the appropriate cache contexts in their code. Which means that Drupal 8 contrib modules will be battle-hardened by many (tens of) thousands of websites, and missing cacheability metadata will be added. Instead of an enormous burden lying on the shoulders of the Authcache site owner, a very small burden lies on the shoulders of every contrib module maintainer (and user). Drupal 8 contrib modules should have integration test coverage with Dynamic Page Cache enabled.

Historical note

Somewhere in mid-February, Dries asked me what the state was of ESI support in Drupal 8, whether partial pre-rendering was possible, and so on. I replied in two ways: in short (No, ESI is not fully supported yet8) and comprehensively, describing how full ESI support was now more feasible than ever, which other exciting things are possible with the render- and caching-related improvements, and so on. That e-mail I sent formed the foundation of Dries’ Making Drupal 8 fly blog post :)

But a side effect of me describing at a high level the exciting new possibilities got me thinking… I had spent a full year working on improving Drupal 8’s performance & cacheability. At that point, cache tags were ~90% done. Thanks to that, it had become clear that enabling page caching by default had finally become within reach (and it effectively happened two months later).

Cache contexts were also getting in better and better shape. What if… I would be able to leverage cache contexts in a similar way I was able to leverage cache tags? Complete cache tag support allowed us to enable page cache by default. What would complete cache context support allow? Cache tags capture data dependencies. Cache contexts capture (request) context dependencies. Cache tags allow for correct invalidations. Anonymous users do not get any variations, so cache tags are sufficient for them. Which means… that cache contexts would allow me to … do page caching, but for all users — i.e. also authenticated ones!

Or: how articulating an answer to a fairly specific question can make one think of other ideas :)

I started experimenting and was blown away by the results of my rough proof and concept patches. I opened the “SmartCache” ([#2429617]) issue and the “finalize cache contexts API & DX/usage, enable a leap forward in performance” ([#2429287]) issue that captured the many, many places where we’d still have to finish cache context support in order to be able to actually do what the experiment describes.

At the same time, I was talking to Fabian Franz. Together with him, I devised an algorithm (and a proof) to make it possible to bubble cache contexts, which is absolutely essential for Dynamic Page Cache.

Fast forward seven months and we’ve fixed many dozens of blockers for Dynamic Page Cache, and have landed Dynamic Page Cache itself, thanks to the hard work of many people!

  1. Originally, it was called Smart Cache. See issue #2429617

  2. Not every site serves the same exact responses to all their anonymous users, but most do. Therefore this is a great default. If your site serves different responses to different anonymous users, then you can just disable that module. The Page Cache therefore operates just like any other simple reverse proxy setup. 

  3. Because they contain user-specific or session-specific data, i.e. because they have the user or the session cache context associated. 

  4. That is significantly slower than 7. We still have lots of work ahead in Drupal 8.1, 8.2 etc to make bootstrapping and routing much faster. 

  5. We’re working on making forms cacheable in #2578855, which should then put the node/1 response time roughly on par with the front page’s response time when using Dynamic Page Cache. 

  6. And it always varies by the same key on all pages, even if page A only varies by role, and page B varies by role, user, interface language and organic group. So Authcache always varies by the superset of all possible variations across the entire site. Which means that AuthCache will generate many more variations, even unnecessary ones, and will therefore consume much more space in the cache back-end. 

  7. When a user first logs in, they will get a full bootstrap, so that the user is authenticated. Since the key is the same on all pages (again, see [^5]), it is then able to cache this key per session and reuse it on all future requests, which means that all subsequent requests for this session will be much faster. See _authcache_builtin_cacheinc_cache_key_get(). 

  8. Technically, Drupal 7 supported ESI, but it was very, very complex, either via drupal_render_cache_set()’s ability to have cache backends modify the markup they’re being asked to cache (in other words: ESI via side effects) which links to custom endpoints in custom code to generate the dynamic content, or via the ESI module, which is complex to use and also requires custom code. “Full support” in my book means that anything can be served over ESI, transparently, without any custom code, code changes or deep technical knowledge. 

Categories: Elsewhere

Axelerant Blog: Drupal 8 is Mobile First, Global Ready

Planet Drupal - Mon, 12/10/2015 - 20:00

If your organization needs to be accessible, here is the answer. Drupal 8 is mobile first and global ready. Its initial RC was released on October 7th, 2015, the collective work of over 3,000 contributors. D8 is the epitome of what mobile, global sites should be.

  1. The Need For a Responsive, Mobile-First Website
  2. How Is Drupal 8 Mobile First
  3. Global Users On The Go
  4. The Need For a Global Ready Website
  5. What Makes Drupal 8 Global Ready
  6. What This Means For Your Organization

Let’s delve into the details and ultimately discover what all this means for your organization in 2016 and beyond.

The Need For a Responsive, Mobile-First Website.

Having a responsive design means having a site that scales to meet your user’s needs. The way we search the Internet has changed and search technologies are responding to this. Google rolled out a mobile friendly algorithm on April 21, 2015. It’s been called the mobilegeddon update because of the tremendous boost it gives to responsive websites and the dead weight it adds to sites that aren’t.

In the US, one out of every three people owns a smartphone. Worldwide, it’s one out of every five. The number of users browsing on tablets, phablets, and phones will continue to rise—website responsiveness is critical.

This is made possible with CSS, which goes to work defining how page elements should be displayed to device users. Its effectiveness can be checked with responsive plugins and extensions from Chrome and Safari. At Axelerant, we created a simple URL mobile friendly tester that can test your pages.

Your website’s responsiveness has to be taken into account if it’s going to be productive—to inform, deliver services, generate leads, and more.

But Shouldn’t “Desktop” Versions Come First?

Not anymore. Productive websites from now on should be treating the desktop as secondary.

The demand for mobile, responsive themes has never been higher and will continue to rise. The amount of users accessing sites from a mobile device has been steadily growing.

Users in the US alone are accessing mobile online media 51% of the time, compared to the 41% using desktop. This drives the Drupal community to focus on mobile first because we’re passed the 50-50 mark. Having a clear focus on mobile first designs can also improve the efficiency of your desktop website.

So How Is Drupal 8, Mobile First?

Drupal’s original creator and product lead Dries Buytaert said way back in 2011 that

If I were to start Drupal from scratch today, I’d build it for mobile experiences first, and desktop experience second.

True then and truer still today, but considering all of the modern features the latest update contains, it was worth waiting for. Contributors have charged forward with a transforming Mobile Initiative to create a first class mobile platform, spearheaded by the initiative’s lead John Albin Wilkins. The admin interface, themes, tables, and pictures were a focus and are incredibly useful mobile features:

The Admin

As a mobile friendly CMS, Drupal enables on the go administration. Managing content while on a mobile device becomes painless. The admin layer has been revamped. It’s simple, straight-forward, and light. Toolbars go horizontal or vertical as needed.

The Themes

All built-in themes are responsive. These give you the power to change the way your site looks and feels. Drupal 8’s new theming engine Twig is PHP-based, secure by default, easier to read, and friendlier to front-end developers.

This new flexibility enables the creation of highly attractive, highly functional sites that look great on mobile. The right theme will help power your organization’s branding while providing positive user experiences.

The goal was to transition all existing D8 themes from “desktop only” to mobile first, and for all to include a useful backend platform.  This ties into the push to make Drupal the leading mobile CMS platform.

The Tables

When a user views the page from a narrow viewport, the page’s horizontal elements will automatically become vertical, with less important columns being removed. Breakpoints are built into Drupal 8, which keep track of height, width, and resolution. This enables a site to respond appropriately to device needs; tables and the likes shrink readily to preserve mobile integrity. So when transitioning from a desktop screen to a mobile one, you’ll see tables adapt seamlessly.

The Pictures

With such an emphasis being placed on ease of use (for both end users and administrators), D8 had to address the question of responsive images. Administrators can add large photos to their pages that size themselves appropriately based on the viewer’s device. A module effectively reduces file size by resizing the image.

The D8 update includes a responsive module that contains breakpoint mapping and an image formatter. These features can be used to output responsive images using the HTML5 picture tag.

Responsive image support isn’t just visually convenient; it helps pages with large, high-quality images load faster. Meaning the pictures worth 1,000 pixels don’t have to make your mobile site slow or awkward.

Global Users On The Go

You already know that the current standards of your website should be up to par with the growing number of relevant on-the-go, global web users. This number will have a direct effect on your organization one way or another.

Websites existing within the digital space will either experience the positive or negative side of the expanse: one billion users in 2005, two billion in 2010, three billion in 2014, and counting.

With these numbers in mind, the number of smartphone users in the world is expected to hit a whopping 6.1 billion by 2020. This means that in less than five years, 90% of the world will be online, 70% will be mobile.

You might be tempted to think: “these numbers don’t apply to my organization. Relevant visits to my site aren’t going to increase as these figures grow.” That’s correct. Not if your website isn’t mobile first and global ready. If your website is neither of these, you can expect the number of new, relevant visitors (potential customers searching for your services) to dwindle.

The Need For a Global Ready Website

Global websites are designed to be accessible for international users from other countries and different cultures. Modern organizations looking to target specific, global demographics require websites like these.

However, due to rising internationalization (increasing globalization), all forward thinking businesses will eventually need to take up these websites. This is especially true for e-commerce sites, which must be prepared to cater to changing global e-commerce data.

If you’re selling a product or a service online, chances are you’ve been made aware of increasing numbers of international visitors. If your organization has the structural capabilities to sell to these demographics, it needs to.

What About Website Localization?

This isn’t the opposite of what’s called website internationalization or globalization. Website localization refers to “locale” site adaptations, which facilitate particular communicative, cultural (or other special requirements) which cater to a specific target market. Globalized or internationalized sites enable localization.

Ongoing Drupal initiatives are aimed at improving its localizing interface to suit international users. Likewise, these users can create localized Drupal sites for their audience.

What helps make this possible is a sophisticated translation manager in the core. This empowers users to utilize the right translations for each target demographic that need to be reached.

What Makes Drupal 8 Global Ready?

To be global ready is really to be user-friendly on an international scale, and Drupal 8 accomplishes this. In the late 90’s, over 80% of internet users were native English speakers, by 2010 this dropped to less than 30%.

With Drupal 8’s multilingual capabilities, international site visitors and D8 site builders alike aren’t met at a half-way mark, but where they’re most comfortable. Drupal 8’s Configuration Translation enables the translation of essential elements—blocks, toolbars, menus, etc.

  • The Content Translation module can address your website’s copywriting, like articles et al.
  • The Interface Translation module enables the other page elements (e.g. form labels) to be translated.
  • The Language module allows you to define which languages your website supports.

With these key features, Drupal 8 positions itself as the global ready website option. Multilingual feats like translation and transliteration are two pillars of this positioning.


Advanced multilingual capabilities of Drupal 8 are hallmarks of this release. Whereas D7 has regional settings, language support, and usability attention given to interface translation, D8 brings this into the core. It comes with highly improved language detection abilities that are browser based, meaning it functions to identify preferred languages and present them to users.

Now you can install 94 languages (and counting). You can assign the right language, out of these 94, to content and configurations. Blocks can also be language dependent and more page elements than ever are Blocks in D8.


There are times when characters need to be romanized for various purposes. Drupal core has addressed this. Now, built-in user interfaces transliterate key language assignments. This transliteration is an advancement from other CMS solutions, enabling efficient romanization of several challenging scripts and types (e.g. Hungarian, Czech, Marathi)

There is a variety of live multilingual Drupal 8 sites that are being put to the test in various industries. These are testaments to what D8 makes possible.

What Does All This Mean For Your Organization?

It means your organization doesn’t have to fall behind. The importance of mobile-friendly, global ready websites cannot be overstated or underestimated.

You’ve heard it 1,000 times that “content is king.” What we’re seeing is that while this is true, isolated content isn’t king. Mobile content is king. Global content is king.

With targetted content taking the center stage on every stage, Drupal’s latest update can empower your organization to do it right.

Check Out Axelerant’s Contributions.

The post Drupal 8 is Mobile First, Global Ready first appeared on Axelerant.

Categories: Elsewhere

Modules Unraveled: What is the #1 thing keeping you from using Drupal 8 right now?

Planet Drupal - Mon, 12/10/2015 - 18:00

In order to produce training and informational material on Drupal 8, I'd like to know what's keeping you from using Drupal 8 right now.

Please answer this ONE QUESTION survey to explain the biggest issue, concern or other reason you're not using it already.



Tags: Drupal 8planet-drupal
Categories: Elsewhere

Aten Design Group: Determining Most Shared Content

Planet Drupal - Mon, 12/10/2015 - 17:20

Our client, Human Rights Watch, publishes a large volume of content and with the redevelopment of HRW.org, they wanted a way to curate their content in more meaningful ways. One way we did this was by showing what content is shared most frequently across a variety of social networks.

Keeping up with the number of shares across multiple social networks seemed like an uphill battle. A system like this would require creating a background process that looks up and stores the number of shares for HRW.org URLs. It would also require writing separate API integrations for each social network HRW wants to target and maintaining them over time.

Since we didn’t want to create and maintain a custom social share count aggregation system if we didn’t have to, we started looking at 3rd party solutions. HRW.org is a multi-lingual site, so some of the options weren’t viable since they provide the most shared items for a domain without taking into account the language of the content. We selected SharedCount.com, which has a simple API that allowed us to quickly build a system to determine most shared content. The system sends SharedCount a batch of URLs and it returns a JSON object with the number of shares across a variety of social networks for each URL.

Here is a sample JSON response from the API: https://docs.sharedcount.com/v1.0/docs/bulk-1

{ "data": { "http://google.com/": { "StumbleUpon": null, "Pinterest": 1003223, "Twitter": 11400, "LinkedIn": 95, "Facebook": { "commentsbox_count": 10117, "click_count": 265614, "total_count": 9476803, "comment_count": 1793601, "like_count": 1500762, "share_count": 6182440 }, "GooglePlusOne": 7710780 }, "http://stackoverflow.com/": { "...snip...": "98 URLs not shown for brevity..(snip).." }   }, "_meta": { "urls_completed": 100, "bulk_id": "a4f8f0fd436995987dbef98bbff9accc61282c63", "completed": true, "urls_queued": 100 } How it Works

HRW.org is built with Drupal. In a custom module, we set up several Drush commands that can run at intervals. We use Jenkins to run this every 10 minutes, so we can provide a nearly real-time look at what is happening socially with HRW’s content. The workflow looks like this:

  1. Query a batch of URLs in Drupal. Currently, it sends any URL published in the last 30 days. To make this easy for HRW to adjust, we used Drupal Views to determine which URLs to send to the ShareCount API.
  2. Send a batch of URLs to the SharedCount bulk API https://docs.sharedcount.com/v1.0/docs/bulk.
  3. Process a JSON object from SharedCount, which includes the number of shares for each URL.
  4. Store the results in a simple database table with the URL, number of shares and language of the content.
  5. Query the custom database table to show most shared content in a custom Drupal block on the HRW.org homepage.

Hooray for leveraging all that social data in a simple, but meaningful way.

Categories: Elsewhere

Drupal Watchdog: Dreaming of Drupal 8

Planet Drupal - Mon, 12/10/2015 - 17:08

At DrupalCon Los Angeles, the question on everyone’s lips was: “When will Drupal 8 be released?”

Each time it was asked, it felt more and more like a recurring dream. Is this thing real, or did some Belgian guy start a rumor?


Views in core? Really?

Drupal configuration in code?

Ha! Now I know you're kidding!

Well guess what: Drupal 8 is not just some intangible vision that Drupalistas keep dreaming about. It exists and, ready or not, here it comes, barreling down the road. Very soon, my friend, the dream will become reality.

But bear in mind that the Drupal 8 dream is a lot like Disneyland:

  • Entry to the park ain’t free. (You're going to have to acquire some new skills.)
  • There will be long lines for your favorite rides. (Not all modules will be stable right away.)
  • At the end of the day, you’ll be pooped. (Your first Drupal 8 project will exhaust you.)
  • You might be too small for some attractions. (Neither you nor your clients will be quite ready-to-go on Day One of Drupal 8’s release.)

Putting skepticism aside, I am truly excited about the things coming in Drupal 8. The one new feature that I’m particularly excited about – and I think many others are, too – is Configuration Management. Drupal 8 will finally give us the ability to store site settings and configurations in code instead of mingled with content in the database. For me, and for your DevOps person, that’s the dream: Finally, no more scribbling notes on the back of an envelope for what we changed so we can remember to do it live in production.

If you’re as excited about configuration management as I am, you may stop reading now and just jump in and play with Drupal 8. Or maybe take a look at this article from a couple of Drupal Watchdog issues ago.

But if you're not ready to take the plunge, or know that you’ll be using Drupal 7 for a while longer, then please read on.

Categories: Elsewhere


Subscribe to jfhovinne aggregator