Drupal Feeds

Acquia: Ultimate Guide to Drupal 8: Episode 3 - Site builder Improvements

Planet Drupal - Wed, 2014-05-21 11:33

Welcome to the third instalment of an 8-part blog series we're calling "The Ultimate Guide to Drupal 8." Whether you're a site builder, module or theme developer, or simply an end-user of a Drupal website, Drupal 8 has tons in store for you! This blog series will attempt to enumerate the major changes in Drupal 8. Successive posts will gradually get more technical, so feel free to skip to later parts (once they're published) if you're more on the geeky side.

Acquia: Ultimate Guide to Drupal 8: Episode 3 - Site builder Improvements

Feeds from Drupal.org - Wed, 2014-05-21 11:33

Welcome to the third instalment of an 8-part blog series we're calling "The Ultimate Guide to Drupal 8." Whether you're a site builder, module or theme developer, or simply an end-user of a Drupal website, Drupal 8 has tons in store for you! This blog series will attempt to enumerate the major changes in Drupal 8. Successive posts will gradually get more technical, so feel free to skip to later parts (once they're published) if you're more on the geeky side.

Categories: Straight From Drupal

Code Enigma: Drupal 6 Performance Testing

Planet Drupal - Wed, 2014-05-21 10:46

We were recently asked to investigate poor performance on a Drupal 6 site. Memcache was enabled, but a siege test was still showing poor results.

Transactions: 145 hits Availability: 100.00 % Elapsed time: 525.34 secs Data transferred: 1.89 MB Response time: 17.08 secs Transaction rate: 0.28 trans/sec Throughput: 0.00 MB/sec Concurrency: 4.71 Successful transactions: 145 Failed transactions: 0 Longest transaction: 28.38 Shortest transaction: 13.03

We run New Relic for performance testing and the siege traffic gives it plenty to analyse.

The first thing we noticed in New Relic was that there were some slow hook_init functions being called. The worst performing of these was in the Password Policy module, covered at http://drupal.org/node/2008282. Fixing this didn't make a huge change to the performance though.

The site also runs CiviCRM and in the New Relic transactions, it showed that civicrm_invoke was taking a long time to process. Digging into the transaction details, we came across this:

The theme registry was being rebuilt on every page load. We checked to see if there were any theme settings that had been left enabled from development that were causing the theme rebuild, but found none.

Checking through the functions that appeared in the transaction log, the only reason for the theme registry to be rebuilt each time that we could come up with was that it was failing to be saved in the cache. The log shows that _theme_load_registry() is called, it checks memcache for the cached theme registry, but then rebuilds it.

function _theme_load_registry($theme, $base_theme = NULL, $theme_engine = NULL) { // Check the theme registry cache; if it exists, use it. $cache = cache_get("theme_registry:$theme->name", 'cache'); if (isset($cache->data)) { $registry = $cache->data; } else { // If not, build one and cache it. $registry = _theme_build_registry($theme, $base_theme, $theme_engine); _theme_save_registry($theme, $registry); } _theme_set_registry($registry); }

Checking all the logs failed to show any errors relating to memcache. For a quick check, we decided to try moving the cache table (where the theme registry is cached) out of memcache, back into the Drupal database. In settings.php, this was done by changing

$conf['memcache_bins'] = array( 'cache' => 'default', ...

to

$conf['memcache_bins'] = array( 'cache' => 'database', ...

Running the siege test again showed a marked improvement.

Transactions: 112 hits Availability: 100.00 % Elapsed time: 97.70 secs Data transferred: 1.46 MB Response time: 3.83 secs Transaction rate: 1.15 trans/sec Throughput: 0.01 MB/sec Concurrency: 4.39 Successful transactions: 112 Failed transactions: 0 Longest transaction: 5.92 Shortest transaction: 2.80

That seemed conclusive, but didn't help to understand why memcache was failing to store the theme registry. Further investigation led us to http://drupal.org/node/435694. Memcache will only store data up to 1M in size - not only that, but it fails silently, so nothing appears in the logs.

There are patches in http://drupal.org/node/435694 to add logging to capture these memcache failed saves and there's also a php snippet at http://gist.github.com/typhonius/8798894 to scan all the Drupal cache tables and highlight any objects over 1M in size.

If you're using memcache 1.4.2 or later, you can increase the 1M maximum object size, see https://code.google.com/p/memcached/wiki/ReleaseNotes142 for example, but increasing this too much may impact memcache's efficiency.

New Relic certainly made it much quicker for us to diagnose the underlying issue though and having the near instant feedback is great.

Related Service Areas: ConsultancyDevelopmentSupportTeaser: A scenario where memcache can actually impair performanceCategories: ConsultancyDevelopmentDrupal PlanetSupportPrimary Category: Consultancy

Code Enigma: Drupal 6 Performance Testing

Feeds from Drupal.org - Wed, 2014-05-21 10:46

We were recently asked to investigate poor performance on a Drupal 6 site. Memcache was enabled, but a siege test was still showing poor results.

Transactions: 145 hits Availability: 100.00 % Elapsed time: 525.34 secs Data transferred: 1.89 MB Response time: 17.08 secs Transaction rate: 0.28 trans/sec Throughput: 0.00 MB/sec Concurrency: 4.71 Successful transactions: 145 Failed transactions: 0 Longest transaction: 28.38 Shortest transaction: 13.03

We run New Relic for performance testing and the siege traffic gives it plenty to analyse.

The first thing we noticed in New Relic was that there were some slow hook_init functions being called. The worst performing of these was in the Password Policy module, covered at http://drupal.org/node/2008282. Fixing this didn't make a huge change to the performance though.

The site also runs CiviCRM and in the New Relic transactions, it showed that civicrm_invoke was taking a long time to process. Digging into the transaction details, we came across this:

The theme registry was being rebuilt on every page load. We checked to see if there were any theme settings that had been left enabled from development that were causing the theme rebuild, but found none.

Checking through the functions that appeared in the transaction log, the only reason for the theme registry to be rebuilt each time that we could come up with was that it was failing to be saved in the cache. The log shows that _theme_load_registry() is called, it checks memcache for the cached theme registry, but then rebuilds it.

function _theme_load_registry($theme, $base_theme = NULL, $theme_engine = NULL) { // Check the theme registry cache; if it exists, use it. $cache = cache_get("theme_registry:$theme->name", 'cache'); if (isset($cache->data)) { $registry = $cache->data; } else { // If not, build one and cache it. $registry = _theme_build_registry($theme, $base_theme, $theme_engine); _theme_save_registry($theme, $registry); } _theme_set_registry($registry); }

Checking all the logs failed to show any errors relating to memcache. For a quick check, we decided to try moving the cache table (where the theme registry is cached) out of memcache, back into the Drupal database. In settings.php, this was done by changing

$conf['memcache_bins'] = array( 'cache' => 'default', ...

to

$conf['memcache_bins'] = array( 'cache' => 'database', ...

Running the siege test again showed a marked improvement.

Transactions: 112 hits Availability: 100.00 % Elapsed time: 97.70 secs Data transferred: 1.46 MB Response time: 3.83 secs Transaction rate: 1.15 trans/sec Throughput: 0.01 MB/sec Concurrency: 4.39 Successful transactions: 112 Failed transactions: 0 Longest transaction: 5.92 Shortest transaction: 2.80

That seemed conclusive, but didn't help to understand why memcache was failing to store the theme registry. Further investigation led us to http://drupal.org/node/435694. Memcache will only store data up to 1M in size - not only that, but it fails silently, so nothing appears in the logs.

There are patches in http://drupal.org/node/435694 to add logging to capture these memcache failed saves and there's also a php snippet at http://gist.github.com/typhonius/8798894 to scan all the Drupal cache tables and highlight any objects over 1M in size.

If you're using memcache 1.4.2 or later, you can increase the 1M maximum object size, see https://code.google.com/p/memcached/wiki/ReleaseNotes142 for example, but increasing this too much may impact memcache's efficiency.

New Relic certainly made it much quicker for us to diagnose the underlying issue though and having the near instant feedback is great.

Related Service Areas: ConsultancyDevelopmentSupportTeaser: A scenario where memcache can actually impair performanceCategories: ConsultancyDevelopmentDrupal PlanetSupportPrimary Category: Consultancy
Categories: Straight From Drupal

Membersify Paid Memberships

Latest Drupal Modules - Wed, 2014-05-21 08:11

Setting up a paid membership feature on your website can bring your budding site to a grinding halt. We have years of experience with creating paid membership websites, so we know how complicated it can be. We're breaking that trend.

With Membersify, we have stripped out as much of the complexity as possible to give you a truly turn-key solution to getting your content monetized. What used to take weeks or months now can be done in hours or even minutes.

Categories: Straight From Drupal

Oliver Davies: git format-patch is your Friend

Planet Drupal - Wed, 2014-05-21 07:00
The Problem

As an active contributor to the Drupal project, I spend a lot of time working with other peoples’ modules and themes, and occassionally have to fix a bug or add some new functionality.

In the Drupal community, we use a patch based workflow where any changes that I make get exported to a file detailing the differences. The patch file (*.patch) is attached to an item in an issue queue on Drupal.org, applied by the maintainer to their local copy of the code and reviewed, and hopefully committed.

Oliver Davies: git format-patch is your Friend

Feeds from Drupal.org - Wed, 2014-05-21 07:00
The Problem

As an active contributor to the Drupal project, I spend a lot of time working with other peoples’ modules and themes, and occassionally have to fix a bug or add some new functionality.

In the Drupal community, we use a patch based workflow where any changes that I make get exported to a file detailing the differences. The patch file (*.patch) is attached to an item in an issue queue on Drupal.org, applied by the maintainer to their local copy of the code and reviewed, and hopefully committed.

Categories: Straight From Drupal

Oliver Davies: git format-patch is your Friend

Planet Drupal - Wed, 2014-05-21 07:00
The Problem

As an active contributor to the Drupal project, I spend a lot of time working with other peoples’ modules and themes, and occassionally have to fix a bug or add some new functionality.

In the Drupal community, we use a patch based workflow where any changes that I make get exported to a file detailing the differences. The patch file (*.patch) is attached to an item in an issue queue on Drupal.org, applied by the maintainer to their local copy of the code and reviewed, and hopefully committed.

Oliver Davies: git format-patch is your Friend

Feeds from Drupal.org - Wed, 2014-05-21 07:00
The Problem

As an active contributor to the Drupal project, I spend a lot of time working with other peoples’ modules and themes, and occassionally have to fix a bug or add some new functionality.

In the Drupal community, we use a patch based workflow where any changes that I make get exported to a file detailing the differences. The patch file (*.patch) is attached to an item in an issue queue on Drupal.org, applied by the maintainer to their local copy of the code and reviewed, and hopefully committed.

Categories: Straight From Drupal

Oliver Davies: git format-patch is your Friend

Planet Drupal - Wed, 2014-05-21 07:00
The ProblemAs an active contributor to the Drupal project, I spend a lot of time working with other peoples’ modules and themes, and occassionally have to fix a bug or add some new functionality.In the Drupal community, we use a patch based workflow where any changes that I make get exported to a file detailing the differences. The patch file (*.patch) is attached to an item in an issue queue on Drupal.org, applied by the maintainer to their local copy of the code and reviewed, and hopefully committed.

Oliver Davies: git format-patch is your Friend

Feeds from Drupal.org - Wed, 2014-05-21 07:00
The ProblemAs an active contributor to the Drupal project, I spend a lot of time working with other peoples’ modules and themes, and occassionally have to fix a bug or add some new functionality.In the Drupal community, we use a patch based workflow where any changes that I make get exported to a file detailing the differences. The patch file (*.patch) is attached to an item in an issue queue on Drupal.org, applied by the maintainer to their local copy of the code and reviewed, and hopefully committed.
Categories: Straight From Drupal

Druler Drupalgive: Domain Setup

Feeds from Drupal.org - Wed, 2014-05-21 05:20

This simple module is usefull for automatic inject include_once stuff for the Domain Access module into settings.php via profile install.

For enabling domain access through installation profile insert domain_setup dependency just after domain module declaration

Categories: Straight From Drupal

Domain Setup

Latest Drupal Modules - Wed, 2014-05-21 05:11

This simple module is usefull for automatic injection of include_once stuff for the Domain Access module into settings.php via profile install.

For enabling domain access through installation profile insert domain_setup dependency just after domain module declaration

dependencies[] = domain
dependencies[] = domain_setup
and it will do all the work during installation.

Remember, this module will remove injected row after disabling.

Categories: Straight From Drupal

Modules Unraveled: 109 Getting Rules Ported to Drupal 8 with Josef Dabernig, Klaus Purer and Wolfgang Ziegler - Modules Unraveled Podcast

Planet Drupal - Wed, 2014-05-21 05:00
Photo of Josef Dabernig, Klaus Purer and Wolfgang ZieglerPublished: Wed, 05/21/14Download this episodeRules
  • For those new to Drupal, what is the Rules module?

    • Intro Rules: events, conditions, actions
    • Programming for site builders
    • Giving workflows into the hands of the site builders, workflow building blocks like Lego

    The Rules module allows site administrators to define conditionally executed actions based on occurring events (known as reactive or ECA rules).

Example use cases
Build flexible content publishing workflows changes
Send customized mails to notify your users about important updates
Create custom redirections, system messages, breadcrumbs, ...
Build an e-commerce store using Drupal Commerce
And many more…

Rules has fantastic integration with Drupal Core APIs and all structured data exposed using the Entity and Fields systems, over 350 other contributed modules specifically integrate with the Rules API by to provide their own custom events, conditions, actions or exposing custom data in a reusable way.

Use case: Automating processes
Rules serves the need for automating processes like comment moderation, customizable e-mail notifications or event-based calculations on social platforms. These are built by using generic tools like Flag, Organic groups and message module. More specific solutions like Privatemsg, Feeds, Activity, User point or Voting rules also tightly integrate into the system.

What is the Rules module, explain some use cases & tell us about the rules success story
http://d8rules.org/content/rules-success-story

Drupal 8
  • In the last episode, Crell mentioned that because of the advances in D8, there may not be a need for the Rules module. So, I told him that I would ask you guys for a response to that.
  • What Drupal 8 Stuff are you building upon?

Entity API
Out-of-the-box typed data support for all fields, i.e. including custom content entity types

Typed Data API

The Typed Data API was created to provide developers with a consistent way of interacting with data in different ways. Not only does the API allow you to interact with the actual data, it also provides means of fetching more information, or metadata, about the actual data.
The Typed Data API is a low level, generic and reusable object oriented API. One API that implements it is the Entity API - Drupal’s primary data model.

-> Unification of metadata systems of Drupal 7.

Conditions & Actions

We've got an Actions and Conditions API in core already, so one might think another huge part has been taken care off. Unfortunately, no - those APIs have been created/ported with other use cases in mind, so they do not cater for all the more advanced features Rules users are used to.

While I tried to make sure they fit Rules needs as far as possible when they were introduced/updated, they do not fit our needs yet and it might be impossible to make them fit without breaking those APIs. For Rules 8.x we plan to work on improving those APIs (from contrib) as needed first, so we can ensure they fit Rules' requirements.

Once we are sure everything works out we'll know what we have to adapt and whether improvements can be contributed to core.
Depending on how that works out, we'll see whether we can build up on the core Action and Conditions API or there will be Rules' variants of those APIs (again :(). For more details please see the related issues:

Rules 8.x Architecture
Rules 8.x Roadmap

Motivation behind Rules in Drupal 8

Features
http://d8rules.org/content/overview-rules-8x-features

Porting Rules to Drupal 8 will require a major refactoring of the framework. The Rules Core APIs & functionality will evolve and Drupal 8 rewrite opportunities will be taken into account.

Site building based on Drupal 8 core integration wins
Admin UI usability improvements
Simple Views Bulk operations in core

Reusable components
Plug-in based architecture & fully object-oriented code
Rules data selector for tokens, contexts and other use cases
Typed data widgets & formatters
Embeddable Rules UI components to integrate actions & conditions

Evolved developer experience
Unified DX based on Drupal 8 plug-in system
Symfony 2 event system integration
Deployable config via CMI

Funding, milestones, Corporate & crowdfunding - how will that work out?
http://test-d8rules.gotpantheon.com/content/funding-goal-project-milestones
- sponsorship by company
- crowd funding
- What happens if the funding does not succeed?

How & who
http://test-d8rules.gotpantheon.com/team
- fago, klausi, dasjo, nico

crowd funding is live now - drupalfund.us!!!

Who supports you already?
see http://d8rules.org/supporters

Why should we help now?

Questions from Twitter Episode Links: fago on drupal.orgfago on Twitterklausi on drupal.orgklausi on TwitterDasjo on drupal.orgDasjo on Twitterd8rules.orgDrupalFund.us Crowdfunding CampaignKlausi’s BlogBlog post about Supporting Rules in D8d8rules TeamTags: 

Modules Unraveled: 109 Getting Rules Ported to Drupal 8 with Josef Dabernig, Klaus Purer and Wolfgang Ziegler - Modules Unraveled Podcast

Feeds from Drupal.org - Wed, 2014-05-21 05:00
Photo of Josef Dabernig, Klaus Purer and Wolfgang ZieglerPublished: Wed, 05/21/14Download this episodeRules
  • For those new to Drupal, what is the Rules module?

    • Intro Rules: events, conditions, actions
    • Programming for site builders
    • Giving workflows into the hands of the site builders, workflow building blocks like Lego

    The Rules module allows site administrators to define conditionally executed actions based on occurring events (known as reactive or ECA rules).

Example use cases
Build flexible content publishing workflows changes
Send customized mails to notify your users about important updates
Create custom redirections, system messages, breadcrumbs, ...
Build an e-commerce store using Drupal Commerce
And many more…

Rules has fantastic integration with Drupal Core APIs and all structured data exposed using the Entity and Fields systems, over 350 other contributed modules specifically integrate with the Rules API by to provide their own custom events, conditions, actions or exposing custom data in a reusable way.

Use case: Automating processes
Rules serves the need for automating processes like comment moderation, customizable e-mail notifications or event-based calculations on social platforms. These are built by using generic tools like Flag, Organic groups and message module. More specific solutions like Privatemsg, Feeds, Activity, User point or Voting rules also tightly integrate into the system.

What is the Rules module, explain some use cases & tell us about the rules success story
http://d8rules.org/content/rules-success-story

Drupal 8
  • In the last episode, Crell mentioned that because of the advances in D8, there may not be a need for the Rules module. So, I told him that I would ask you guys for a response to that.
  • What Drupal 8 Stuff are you building upon?

Entity API
Out-of-the-box typed data support for all fields, i.e. including custom content entity types

Typed Data API

The Typed Data API was created to provide developers with a consistent way of interacting with data in different ways. Not only does the API allow you to interact with the actual data, it also provides means of fetching more information, or metadata, about the actual data.
The Typed Data API is a low level, generic and reusable object oriented API. One API that implements it is the Entity API - Drupal’s primary data model.

-> Unification of metadata systems of Drupal 7.

Conditions & Actions

We've got an Actions and Conditions API in core already, so one might think another huge part has been taken care off. Unfortunately, no - those APIs have been created/ported with other use cases in mind, so they do not cater for all the more advanced features Rules users are used to.

While I tried to make sure they fit Rules needs as far as possible when they were introduced/updated, they do not fit our needs yet and it might be impossible to make them fit without breaking those APIs. For Rules 8.x we plan to work on improving those APIs (from contrib) as needed first, so we can ensure they fit Rules' requirements.

Once we are sure everything works out we'll know what we have to adapt and whether improvements can be contributed to core.
Depending on how that works out, we'll see whether we can build up on the core Action and Conditions API or there will be Rules' variants of those APIs (again :(). For more details please see the related issues:

Rules 8.x Architecture
Rules 8.x Roadmap

Motivation behind Rules in Drupal 8

Features
http://d8rules.org/content/overview-rules-8x-features

Porting Rules to Drupal 8 will require a major refactoring of the framework. The Rules Core APIs & functionality will evolve and Drupal 8 rewrite opportunities will be taken into account.

Site building based on Drupal 8 core integration wins
Admin UI usability improvements
Simple Views Bulk operations in core

Reusable components
Plug-in based architecture & fully object-oriented code
Rules data selector for tokens, contexts and other use cases
Typed data widgets & formatters
Embeddable Rules UI components to integrate actions & conditions

Evolved developer experience
Unified DX based on Drupal 8 plug-in system
Symfony 2 event system integration
Deployable config via CMI

Funding, milestones, Corporate & crowdfunding - how will that work out?
http://test-d8rules.gotpantheon.com/content/funding-goal-project-milestones
- sponsorship by company
- crowd funding
- What happens if the funding does not succeed?

How & who
http://test-d8rules.gotpantheon.com/team
- fago, klausi, dasjo, nico

crowd funding is live now - drupalfund.us!!!

Who supports you already?
see http://d8rules.org/supporters

Why should we help now?

Questions from Twitter Episode Links: fago on drupal.orgfago on Twitterklausi on drupal.orgklausi on TwitterDasjo on drupal.orgDasjo on Twitterd8rules.orgDrupalFund.us Crowdfunding CampaignKlausi’s BlogBlog post about Supporting Rules in D8d8rules TeamTags: 
Categories: Straight From Drupal

Commerce Deploy Shipping

Latest Drupal Modules - Wed, 2014-05-21 03:23

The shipping component to Commerce Deploy

Categories: Straight From Drupal

Commerce Deploy Promotions

Latest Drupal Modules - Wed, 2014-05-21 03:23

The discount and promotions component to Commerce Deploy

Categories: Straight From Drupal

Commerce Deploy Product

Latest Drupal Modules - Wed, 2014-05-21 03:22

The product component to Commerce Deploy

Categories: Straight From Drupal

Commerce Deploy Customer

Latest Drupal Modules - Wed, 2014-05-21 03:21

The customer component to Commerce Deploy

Categories: Straight From Drupal

Commerce Deploy Checkout

Latest Drupal Modules - Wed, 2014-05-21 03:21

The checkout component to Commerce Deploy

Categories: Straight From Drupal

Pages

Subscribe to My Drupal aggregator