Drupal Planet

Syndicate content
Drupal.org - aggregated feeds in category Planet Drupal
Updated: 28 weeks 6 days ago

Darryl Norris's Blog: How To Request A Node via REST Using Web Services in Drupal 8

Tue, 2015-07-07 13:05

Drupal 8 is going to be a central place to store data and can easily connect with different third-party applications. Dries Buytaert has talked about this idea multiple times in DrupalCon Austin and DrupalCon Bogota, where Drupal 8 is going to be an API to connect to other places. For this reason, Drupal 8 is now integrated with web services in core. In other words, this is an easy way to export data into Hal-JSON, JSON, and XML. I decided to start playing with web services in Drupal 8 to see how I can export my data in JSON format and connected with third party app. I found many tutorials that talks about Drupal how to export JSON data using the Views module, which for many use cases can be very good. I started to think, “What...Read more
Categories: Drupal

Acquia: How to Evaluate Drupal Modules for Performance Optimization

Tue, 2015-07-07 10:58

Drupal was designed from the ground-up to be modular. Once you install Drupal core, you can add any number of modules to enhance Drupal's basic functions.

Unfortunately, contributed modules can also impede performance. For example, it's common to find contributed third-party modules that are incompatible with newer versions of Drupal, or other modules. Besides being a security hassle, this can often curb performance.

Evaluating Drupal modules for such issues is thus essential for a smooth Drupal experience. As part of this ongoing blog series on ways to improve Drupal website performance, let’s review how you can evaluate modules.

General module evaluation

The first step in module evaluation is to consider general usage reports, statistics, and maintainer reputation. One by one, go through the following:

  • Does the module officially support your version of Drupal?
  • Good maintainers write good code. If you see the same maintainer's name crop up on a number of well-regarded modules, you know you will at least get quality code.
  • A high maintainer activity level (i.e. commits to a module) indicates a proactive maintainer who takes care of issues quickly.
  • Higher total module usage generally means it's a well-regarded module with fewer performance issues.
  • A large number of stagnant, open issues can point to poor code quality and maintenance.
  • Sudden changes in usage patterns over a short period of time can be indicative of performance issues. For example, if people suddenly stop using a popular module, it could mean that users encountered performance or security problems.

Once you've gone through these steps, you can undertake a performance evaluation.

Module performance evaluation

Now you need to analyze the module performance on your own site.

  • Record site performance before installing any modules. This should include page load time, server load, and user scenario completion time.
  • Record site performance immediately after installing the module.
  • Monitor memory usage continuously to correlate the performance before and after module installation.
  • Perform the same steps for every module individually over time.

These actions will give you quantifiable results on each module's performance as it relates to your site. You might find that highly rated, widely used modules sometimes don't play well with your version of Drupal, while less used modules work perfectly well.

Final questions

Besides evaluating performance, you also need to ask a few questions before using a module.

  • Does the module scale? A module that works perfectly well for a small enterprise website might break when used on a large community-powered platform. Scale is difficult to measure but it is one of the biggest performance bottlenecks in any website.
  • Is performance a top priority? While performance is important, it is by no means necessary for certain types of websites. For example, a small corporate website visited mostly by internal team members may not need top-notch performance.
  • What happens if the module fails? This is an important question. If your module stops working, does it break the site completely, or can the users at least access parts of the site? For example, if the module that controls the login system fails, your users won't be able to use their accounts at all.
  • Do I really need the module? Far too many websites use more modules than necessary. This leads to "module bloat." Ask yourself: “Do I really need this module? Is there a simple manual workaround to enable this function?” If "yes," try to avoid using a module. Keep in mind that the fewer modules you use, the smaller chance of failure.

Modules are crucial for running a Drupal website, but they are also one of the leading causes of website performance issues. Evaluating and understanding modules is essential for running a fast and secure Drupal website.

Tags:  acquia drupal planet
Categories: Drupal

Drupal core announcements: Drupal 8 core updates for July 7th, 2015

Tue, 2015-07-07 10:40

Since the last Drupal 8 Core Update, DrupalCon Los Angeles took place, the proposed organizational structure for the Drupal project was approved and MAINTAINERS.txt was updated to reflect this (although it still needs to be updated in the Drupal 7 branch), and the Drupal Association announced updates to their 2015 financial plan.

What's new with Drupal 8?

Drupal 8.0.0-beta11 and 8.0.0-beta12 were released, a new category for issues, plan, was added to categorize meta issues, the Drupal 8 Security bug bounty program was launched, Angie "webchick" Byron analyzed Drupal major version adoption and walked us through the new DrupalCI testing infrastructure, hook_update_N() became required for core patches that introduce data model changes, the number of outstanding criticals was reduced to a new all-time low of 15, and for a while, every single critical was RTBC or being addressed!

Some other highlights of the month were:

How can I help get Drupal 8 finished?

See Help get Drupal 8 released! for updated information on the current state of the software and more information on how you can help.

We're also looking for more contributors to help compile these posts. Contact mparker17 if you'd like to help!

Drupal 8 In Real Life Whew! That's a wrap!

Do you follow Drupal Planet with devotion, or keep a close eye on the Drupal event calendar, or git pull origin 8.0.x every morning without fail before your coffee? We're looking for more contributors to help compile these posts. You could either take a few hours once every six weeks or so to put together a whole post, or help with one section more regularly. If you'd like to volunteer for helping to draft these posts, please follow the steps here!

Categories: Drupal

Gábor Hojtsy: Win prizes by playing with Drupal 8's multilingual site building features!

Tue, 2015-07-07 06:03

Drupal 8 packs a historic amount of site building features which make producing websites easier than ever with core or just a couple contributed modules only. There are already various live Drupal 8 multilingual sites using little more but core.

It is hard to grasp the many things with useful levers and knobs in Drupal 8. Think about combining views with entity view modes and blocks; block language visibility with menus; user preferences with comment submission; language filtering and entity rendering; translatable fields with administration views; and so on and on.

Wouldn't it be fun to experiment with the possibilities and come up with clever ways to combine core features to solve common problems? You may be familiar with the name and format of O'Reilly's Hacks Series which reclaims the term "hacking" for the good guysfolks — innovators who explore and experiment, unearth shortcuts, create useful tools, and come up with fun things to try on their own.

Long story short, hereby, we announce the Drupal 8 multilingual site building hacks contest!

  1. Come up with clever ways to combine Drupal 8 core features (and if needed one or at most two contributed modules) to fulfill a multilingual site building need.
  2. Write up the steps taken. See an example in hack #1. (We'll do light editing of the post if needed, don't let perfection be the enemy of good).
  3. Register on http://drupal8multilingual.org/user to submit entries (requires approval for spam protection).
  4. Submit entries by end of day (CEST) July 31st.
  5. One person may submit as many entries as they wish.
  6. All entries will be published after review (and possible light editing).
What is in it for you?

The top 3 best hacks will receive unique presents from Hook42 and Amazee Labs! (Further sponsors welcome). You'll either receive the presents at DrupalCon Barcelona or we'll mail it to you if you are not coming to DrupalCon. This is of course additionally to the joy of getting to play with some of the less frequented but definitely no less fun features of Drupal 8.

What is in it for us?

All hacks will be published under Creative Commons Attribution-ShareAlike 4.0, so the community will benefit. Additionally to that Gábor Hojtsy and Vijayachandran Mani are building an open source presentation with the best tips (same license). This will be presented at Drupalaton Hungary and DrupalCon Barcelona. Similar to our existing open source workshop, everyone will be able to present this at local meetups and camps or follow along at home at their own pace.

What kind of hacks are we looking for?

Hack #1 is hopefully a good example. Really the only common thread between the hacks would be to satisfy a multilingual site need or use multilingual features in some other clever way (even for features that are not necessarily multilingual). Some ideas for hacks that may help you start off experimenting:

  1. Swap textual site logo Need to swap a site logo with text on it for different languages? Use a translatable custom block with an image field. Configure the display mode and add some custom CSS if needed.
  2. Translator todo helper Create a views block for content translators to summarize the number of outdated translations they have to update (and link to content administration filtered to that language)
  3. Language dependent front page Use block visibility to display up to date content on a well maintained language while an About us / Contact us page on languages where resources are limited to maintain useful fresh content.

Of course these are just some things we made up (although still eligible for the contest). Looking for your creative ideas and solutions!

Questions, concerns? Contact us!

This is a crosspost from http://www.drupal8multilingual.org/hacks.

Categories: Drupal

InternetDevels: 6 Reasons Why You Should Use Drupal For Website Development

Tue, 2015-07-07 05:50

Our guest blogger Jack Dawson, founder of Big Drop Inc, expains why he thinks Drupal is the best choice for website development services.

Read more
Categories: Drupal

ERPAL: Drop Guard vs. Drupalgeddon - The 1:0 knockout in just a few minutes

Tue, 2015-07-07 02:00

Get ready to rumble! Watch how Drop Guard won against Drupalgeddon on 15.10.2014 at 6:00 PM in this live webinar! We're going to run a live demo re-enacting the whole epic match, and you'll learn about the techniques and strategies that Drop Guard uses to sucker-punch any future Drupal security threats. Don't expect a second round: it'll be a technical KO within minutes!

This free, 45-minute webinar takes place via Google Hangout on 27.07.2015 at 4 PM GMT+2. You'll learn the following:


  1. How to set up an automated workflow to keep your Drupal site updated and secure
  2. Three simple prerequisites for starting with Drop Guard
  3. How Drop Guard integrates with your individual development and deployment workflows


We'll use a Drupalgeddon-infected Drupal installation including several other modules with security issues. This exclusive live demo shows the current status of Drop Guard. All attendees also get free Drop Guard access until the end of September 2015. All attendees get free Drop Guard access until the end of September 2015.


Sign up for free!


Categories: Drupal

Mpumelelo Msimanga: Drupal: Using Views Database Connector (VDC) To Display Data in External Database

Mon, 2015-07-06 13:17
Drupal: Using Views Database Connector (VDC) To Display Data in External Database

Apart from Drupal most organisations may have many systems such as a CRM, HR and e-commerce system. The field of Business Intelligence (BI) deals with bringing disparate data sources into a single data warehouse(DW). If you wanted to display data from your DW using Drupal, the Views module is a good place to start. Before you can use the Views module you need to connect to the database and describe the tables to Views. I am a SQL developer so I am reluctant to write my own module.

Categories: Drupal

Klaus Harris: Some ways you could start using Drupal in your organisation

Mon, 2015-07-06 12:56

Looking at my blog posts, you would be forgiven for thinking that I work with Drupal all day but actually I don't. I've used it for odd private and business projects over the years, built a startup (1) with it and run my sailing club's website on it.

Actually, my working day is spent on a mix of legacy and new Symfony 2 applications. In years gone past that included applications written in frameworks such Zend framework, SugarCRM and plenty of home grown ones from early PHP days.

Sure there are things I don’t like about Drupal 7 such as configuration management, deployment, lack of modern OOP and practices and the fairly blunt caching mechanism (2) but I think it is because of having seen so much legacy code and so much internally written software that I still like Drupal.

Starting from the assumption that you aren’t going to touch your main application which could be running on another framework or technology, I’m going to write about using Drupal in your organization in ways that you might not have considered.

We’re just not going to switch to Drupal!

I think the reality regards PHP applications is that most companies use their own legacy frameworks and/or something like Zend Framework or Symfony, or they are using a totally different stack and they certainly aren’t about to switch any time soon to something else. Which is fair enough.

However there are ways to get value from Drupal with low effort and risk alongside - and in some cases replacing - existing applications and other technologies.

1. Drupal for building intranet tools

In my current company we have a myriad of intranet tools built on different technologies, mostly home grown legacy PHP apps, but also ones built on other frameworks and some in .NET. Nothing is standard, every one is special and each demands developer ramp up time. One is even stuck on a dead framework on an early PHP version.

Each generation of developers had seemed to want to try out a new framework, different stack or just write something new. I think that is fairly common in old internet companies.

Drupal can be pretty good for building intranet tools. It has some nice APIs, you certainly aren’t limited to the Drupal data model, you get a lot for free (no custom coding needed) plus there are many good modules out there that expose APIs as well. It is a bit of a revelation to define your own DB table structures and then manipulate or expose them using standard Drupal modules like Views.

Also, if you have good developers to set things up correctly initially, management of the application can then be moved to non-technical staff. For example, it won’t then take a developer to alter a permission, set up a new data view, trigger an alert, turn off a functionality, set up a new workflow or add a new language and so on.

This is one of the things I really like about Drupal in that if done properly, it pushes more control to non-technical staff. Developers are expensive. And just using Drupal on an intranet simplifies things a lot in the sense of deployment, maintenance and possible custom coding / themeing.

I think this “myriad of unique applications” scenario should just end. It’s too expensive, complicated and risky and companies should choose standard solutions and stick with them. A number of open source PHP projects are now very established, not going away and 100% enterprise ready. In the PHP world Symfony 2 with its connected eco system is one, Drupal is another.

Take a look at intranet distributions like Open Atrium for intranets and also other disributions on the Acquia downloads page.

2. Drupal as a data source for other applications

In 2010, in one company we had a large Zend Framework application, a java powered auction system in the back end and we wanted to add multilingual news and help sections. I chose Drupal as the CMS as it had great multilingual functionality, rock solid content management and the possibility to build nice workflows for editors and managers.

There was however just no way that we were going to build a new Drupal application for news and faqs, theme it, deploy it and manage it in production alongside the existing frontend.

The solution for this was simple, use Drupal as an intranet CMS only and just pull the data where needed. I set up a multilingual content management application in Drupal to enable staff to add news and help pages, and we just pulled that data into the front facing Zend Framework application through the caching layer via some simple database views.

Note: this was how it looked in 2010, nowadays you would most likely use the services module to surface the data.

The Drupal application used only out of the box modules, needed no theming and had no special deployment , it was simple and with short development time. Everyone was happy.

I’ve seen plenty of home built CRUD applications for all sorts of things like FAQs, news and help pages, community announcements, landing pages, email templates, translation strings, configuration management. Why write and maintain that stuff yourself? Just use a CMS like Drupal.

Just on translation strings, it would be very easy to build a Drupal application to manage translation strings consumed by other applications. Just build the translations app in Drupal and then write a script to export them to a format that the external application needs, e.g. see here for Symfony translations.

And regards exposing Drupal data, Drupal does have an XML-RPC API and RSS but check out services. See the links below.

3. Drupal as a frontend for manipulating data on other applications

Let’s say you have a public site where users can add content. Rather than add more code to your public facing application, you could make a management frontend for that data in Drupal. Drupal has nice APIs for forms and data access, but you could even hook that data into Drupal APIs more fully, allowing you to use native drupal modules to manipulate the data.

4. Drupal for microsites

Drupal can be perfect for microsites such as News and FAQ sections or forums that work alongside your main application(s). Theming isn’t that difficult and if you don’t need to authenticate users, this is a very easy option.

5. Drupal for your corporate website

The corporate website is usually separate from the main application(s) and a good use case for Drupal. A corp site is usually content heavy, needs frequent updates and might need publishing workflow.

6. Drupal for rapid prototyping

Rocket Internet, the giant European incubator gets new minimum marketable websites out in under 100 days. I think this is a very good plan and Drupal is good for the rapid prototyping of ideas even if the data comes from other sources like search services.


If you are having to make long term decisions now, then with Drupal 8 just around the corner whether you choose Drupal 7 or 8 needs careful research.

Further reading, listening, watching (1) I ceased work on it in 2012
(2) Drupal 8 which is built using Symfony 2 components fixes these issues Blog tags: Link tags:
Categories: Drupal

Chapter Three: Goals First, Then Tactics

Mon, 2015-07-06 11:24

When I kick off a client project, two of my first questions are:

  • What are your project goals?

  • What are your project tactics?

Most of the time, my clients define their goals as tactics. For example, “I want a beautiful site with a great user experience.” While this is a useful thing to identify, it’s not a goal. It’s a tactic.

What purpose does a beautiful site serve? Does beauty drive revenue? Why improve the user experience? Doex UX cultivate positive emotions towards your business?

Asking the “why" behind the tactics can help reveal the true goals of the redesign. It’s easy to define the purpose of a project as “I need my site to look better” because it’s the most obvious thing to be improve. However, there is a missed opportunity in looking only skin deep. 

Categories: Drupal

Dcycle: Catching watchdog errors in your Simpletests

Mon, 2015-07-06 11:04

If you are using a site deployment module, and running simpletests against it in your continuous integration server using drush test-run, you might come across Simpletest output like this in your Jenkins console output:

Starting test MyModuleTestCase. [ok] ... WD rules: Unable to get variable some_variable, it is not [error] defined. ... MyModuleTestCase 9 passes, 0 fails, 0 exceptions, and 7 debug messages [ok] No leftover tables to remove. [status] No temporary directories to remove. [status] Removed 1 test result. [status] Group Class Name

In the above example, the Rules module is complaining that it is misconfigured. You will probably be able to confirm this by installing a local version of your site along with rules_ui and visiting the rules admin page.

Here, it is rules which is logging a watchdog error, but it could by any module.

However, this will not necessarily cause your test to fail (see 0 fails), and more importantly, your continuous integration script will not fail either.

At first you might find it strange that your console output shows [error], but that your script is still passing. You script probably looks something like this:

set -e drush test-run MyModuleTestCase

So: drush test-run outputs an [error] message, but is still exiting with the normal exit code of 0. How can that be?

Well, your test is doing exactly what you are asking of it: it is asserting that certain conditions are met, but you have never explicitly asked it to fail when a watchdog error is logged within the temporary testing environment. This is normal: consider a case where you want to assert that a given piece of code logs an error. In your test, you will create the necessary conditions for the error to be logged, and then you will assert that the error has in fact been logged. In this case your test will fail if the error has not been logged, but will succeed if the error has been logged. This is why the test script should not fail every time there is an error.

But in our above example, we have no way of knowing when such an error is introduced; to ensure more robust testing, let's add a teardown function to our test which asserts that no errors were logged during any of our tests. To make sure that the tests don't fail when errors are expected, we will allow for that as well.

Add the following code to your Simpletest (if you have several tests, consider creating a base test for all of them to avoid reusing code):

/** * {inheritdoc} */ function tearDown() { // See http://dcycleproject.org/blog/96/catching-watchdog-errors-your-simpletests $num_errors = $this->getNumWatchdogEntries(WATCHDOG_ERROR); $expected_errors = isset($this->expected_errors) ? $this->expected_errors : 0; $this->assertTrue($num_errors == $expected_errors, 'Expected ' . $expected_errors . ' watchdog errors and got ' . $num_errors . '.'); parent::tearDown(); } /** * Get the number of watchdog entries for a given severity or worse * * See http://dcycleproject.org/blog/96/catching-watchdog-errors-your-simpletests * * @param $severity = WATCHDOG_ERROR * Severity codes are listed at https://api.drupal.org/api/drupal/includes%21bootstrap.inc/group/logging_severity_levels/7 * Lower numbers are worse severity messages, for example an emergency is 0, and an * error is 3. * Specify a threshold here, for example for the default WATCHDOG_ERROR, this function * will return the number of watchdog entries which are 0, 1, 2, or 3. * * @return * The number of watchdog errors logged during this test. */ function getNumWatchdogEntries($severity = WATCHDOG_ERROR) { $results = db_select('watchdog') ->fields(NULL, array('wid')) ->condition('severity', $severity, '<=') ->execute() ->fetchAll(); return count($results); }

Now, all your tests which have this code will fail if there are any watchdog errors in it. If you are actually expecting there to be errors, then at some point in your test you could use this code:

$this->expected_errors = 1; // for example Tags: blogplanet
Categories: Drupal

Powered By