Planet Drupal

Subscribe to Planet Drupal feed - aggregated feeds in category Planet Drupal
Updated: 43 min 16 sec ago

Cheeky Monkey Media: An introduction to AngularJS and Drupal

Thu, 02/07/2015 - 16:00

If you are looking to create a rich and dynamic web app that has little to no latency, Drupal and AngularJS is the answer as they go hand in hand. In this article I will show you a brief intro of what AngularJS is. There is a bit of a learning curve in this awesome architecture, but if you know some basic JavaScript you will be ok.

AngularJS,  is a front-end JavaScript framework for making web apps and is created by our good pal Google.

Couple of cool facts about AngularJS:

  • Open Source
  • MVC pattern (ASP.NET developer soft spot)
  • Handles task like
  • ...
Categories: Elsewhere

Open Source Training: OSTraining Will Release 200 Drupal 8 Videos for Free

Thu, 02/07/2015 - 10:51

Yes, you read that right: we're going to release 200 free Drupal 8 videos.

We want Drupal 8 to be a success. One way we can help make that happen is to make reliable training available to as wide an audience as possible.

Back in April, we launched our Drupal 8 training Kickstarter project. The project closed in mid-May with enough sponsorship for 100 videos, but over the last 6 weeks we've been talking with more sponsors and now have backing for 200 videos!

Here's an overview of the all the free Drupal training, plus an introduction to the organizations who made it possible.

Categories: Elsewhere

KatteKrab: Certification: Necessary Evil?

Thu, 02/07/2015 - 06:14
Thursday, July 2, 2015 - 14:14

I wrote this as a comment in response to Dries' post about the Acquia certification program - I thought I'd share it here too. I've commented there before.

I've also been conflicted about certifications. I still am. And this is because I fully appreciate the pros and cons. The more I've followed the issue, the more conflicted I've become about it.

My current stand, is this. Certifications are a necessary evil. Let me say a little on why that is.
I know many in the Drupal community are not in favour of certification, mostly because it can't possibly adequately validate their experience.

It also feels like an insult to be expected to submit to external assessment after years of service contributing to the code-base, and to the broader landscape of documentation, training, and professional service delivery.

Those in the know, know how to evaluate a fellow Drupalist. We know what to look for, and more importantly where to look. We know how to decode the secret signs. We can mutter the right incantations. We can ask people smart questions that uncover their deeper knowledge, and reveal their relevant experience.

That's our massive head start. Or privilege. 

Drupal is now a mature platform for web and digital communications. The new challenge that comes with that maturity, is that non-Drupalists are using Drupal. And non specialists are tasked with ensuring sites are built by competent people. These people don't have time to learn what we know. The best way we can help them, is to support some form of certification.

But there's a flip side. We've all laughed at the learning curve cartoon about Drupal. Because it's true. It is hard. And many people don't know where to start. Whilst a certification isn't going to solve this completely, it will help to solve it, because it begins to codify the knowledge many of us take for granted.

Once that knowledge is codified, it can be studied. Formally in classes, or informally through self-directed exploration and discovery.

It's a starting point.

I empathise with the nay-sayers. I really do. I feel it too. But on balance, I think we have to do this. But even more, I hope we can embrace it with more enthusiasm.

I really wish the Drupal Association had the resources to run and champion the certification system, but the truth is, as Dries outlines above, it's a very time-consuming and expensive proposition to do this work.

So, Acquia - you have my deep, albeit somewhat reluctant, gratitude!


Thanks Dries - great post.

(Drupal Association board member)

Categories: Elsewhere

Drupal Easy: DrupalEasy Podcast 158 - FOIAed (Becca Goodman and Brad MacDonald - Drupal Gov Days)

Thu, 02/07/2015 - 03:03
Download Podcast 158

Becca Goodman (onelittlebecca), IT Specialist for Fish and Wildlife Refuges and Brad MacDonald (bjmac), Senior Project Manager for Mediacurrent join Mike to talk about Drupal GovCon, DA revenue, new verbs, and two new exotic animals!

read more

Categories: Elsewhere

ActiveLAMP: How to Use Picture and Image Replace for Drupal 7

Thu, 02/07/2015 - 02:00

The Picture module is a backport of Drupal 8 Responsive Image module. It allows you to select different images to be loaded for different devices and resolutions using media queries and Drupal’s image styles. You can also use the Image Replace module to specify a different image to load at certain breakpoints.

Categories: Elsewhere

Freelock : Embed or integrate? The problem with widgets

Wed, 01/07/2015 - 22:34

We hear it all the time:

Why do you recommend a 6 hour budget for a simple integration? Here's an embed widget right here -- if this were WordPress I could do it myself!

Well, in Drupal you can do it yourself, exactly the same way you might in WordPress. Add a block, use an input format that doesn't strip out Javascript, paste in your code, put the block where you want it on your page, and away you go.

Drupal PlanetPerformanceIntegrationEmbedSecurity
Categories: Elsewhere

Acquia: Improve Your Site’s Security by Adding Two-Factor Authentication

Wed, 01/07/2015 - 21:42

Identity theft and site compromises are all-too-common occurrences -- it seems a day rarely goes by without a news story detailing the latest batch of user passwords which have been compromised and publicly posted.

Passwords were first used in the 1960s when computers were shared among multiple people via time-sharing methods. Allowing multiple users on a single system required a way for users to prove they were who they claimed to be. As computer systems have grown more complex over the last 50 years, the same password concept has been baked into them as the core authentication method. That includes today’s Web sites, including those built using Drupal.

Why Better Protection Is Needed

Today, great lengths are taken to both protect a user’s password, and to protect users from choosing poor passwords. Drupal 7, for example, provided a major security upgrade in how passwords are stored. It also provides a visual indicator as to how complex a password is, in an attempt to describe how secure it might be.

The password_policy module is also available to enforce a matrix of requirements when a user chooses a password.

Both of these methods have helped to increase password security, but there’s still a fundamental problem. A password is simply asking a user to provide a value they know. To make this easier, the vast majority of people reuse the same password across multiple sites.

That means that no matter how well a site protects a user’s password, any other site that does a poor job could provide an attacker all they need to comprise your users’ accounts.

How Multi-Factor Authentication Works

Multi-Factor authentication is one way of solving this problem. There are three ways for a person to prove he is who he claims to be. These are known as factors and are the following:

  • Something you know - typically a password or passphrase
  • Something you have - a physical device such as a phone, ID, or keyfob
  • Something you are - biometric characteristics of the individual

Multi-factor authentication requests two or more of these factors. It makes it much more difficult for someone to impersonate a valid user. With it, if a user’s username and password were to be compromised, the attacker still wouldn’t be able to provide the user’s second form of authentication.

Here, we’ll be focusing on the most common multi-factor solution, something you know (existing password) and something you have (a cell phone).

This is the easiest method of multi-factor authentication, and is also known as two-factor authentication (TFA) because it uses two out of three factors. It’s already used by a large number of financial institutions, as well as large social websites such as Google, Facebook, and Twitter. Acquia implemented TFA for it’s users in 2014 as discussed in this blog post: Secure Acquia accounts with two-step verification and strong passwords.

How To Do It

A suite of modules are available for Drupal for multi-factor authentication. The Two-Factor Authentication module provides integration into Drupal’s existing user- and password-based authentication system. The module is built to be the base framework of any TFA solution, and so does not provide a second factor method itself. Instead the TFA Basic plugins module provides three plugins which are Google Authenticator, Trusted Device, and SMS using Twilio. TFA Basic can also be used as a guide to follow when creating custom plugins. You can find the documentation here: TFA plugin development.

You’ll find that it’s easy to protect your site and its users with TFA, and given its benefits, it’s a good idea to start now.

But before you do, check out the TFA documentation. Acquia Cloud Site Factory users can find documentation for configuring two-factor authentication for their accounts here.

For more advice, check out TFA tips from

Tags:  acquia drupal planet
Categories: Elsewhere

Red Crackle: Should you create a Page View or a Block View?

Wed, 01/07/2015 - 21:08
You need to show a list of content on a page. You know that you need to use Views for it. But you are wondering whether to create a Page View or a Block View. Ask yourself this simple question to decide it for yourself.
Categories: Elsewhere

Another Drop in the Drupal Sea: How Much Will it Cost to Build this Website?

Wed, 01/07/2015 - 20:59

As professionals in the web tech sector, we know that there is no one set answer to that question. And yet, we really don't want to be spending our time having to explain over and over to prospects why we can't just answer the question.

We could provide an analogy and respond by saying, "That's like asking a random custom home builder how much it's going to cost to build a house." We could continue by explaining that the builder will need to know the location of the house, the square footage of the house, the desired finishes on the house, etc.

read more

Categories: Elsewhere

Drupal @ Penn State: A Significant Event

Wed, 01/07/2015 - 17:36

Yesterday something significant occurred, launched on the new Polaris 2 Drupal platform. And soon the Abington Campus web site will move to the same platform. And perhaps many more.

Categories: Elsewhere

Advomatic: Protecting’s Privacy and Security

Wed, 01/07/2015 - 17:25
Earlier this year, we launched a new site for the ACLU. The project required a migration from Drupal 6, building a library of interchangeable page components, complex responsive theming, and serious attention to accessibility, security and privacy. In this post, I’ll highlight some of the security and privacy-related features we implemented. Privacy As an organization, the... Read more »
Categories: Elsewhere

Agaric Collective: Performant bulk-redirection with Apache RewriteMap

Wed, 01/07/2015 - 15:47

When continuing development of a web site, big changes occur every so often. One such change that may occur, frequently as a result of another change, is a bulk update of URLs. When this is necessary, you can greatly improve the response time experienced by your users—as they are redirected from the old path to the new path—by using a handy directive offered in Apache's mod_rewrite called RewriteMap.

At Agaric we regularly turn to Drupal for it's power and flexibility, so one might question why we didn't leverage Drupal's support for handling redirects. When we see an opportunity for our software/system to respond "as early as it can", it is worth investigating how that is handled. Apache handles redirects itself, making it entirely unnecessary to hand-off to PHP, never mind Drupal bootstrapping and retrieving up a redirect record in a database, just to tell a browser (or a search engine) to look somewhere else.

There were two conditions that existed making use of RewriteMap a great candidate. For one, there will be no changes to the list of redirects once they are set: these are for historical purposes only (the old URLs are no longer exposed anywhere else on the site). Also, because we could make the full set of hundreds of redirects via a single RewriteRule—thanks to the substitution capability afforded by RewriteMap—this solution offered a fitting and concise solution.

So, what did we do, and how did we do it?

We started with an existing set of URLs that followed the pattern:[/tab-name]. Subsequently we implemented a module on the site that produced aliases for our user page URLs. The new patten to the page was then (given exceptions for multiple J Smiths, etc via the suffix):[-suffix#][/tab-name]. The mapping of ID to firstname-lastname[-suffix#] was readily available within Drupal, so we used an update_hook to write out the existing mappings to a file (in the Drupal public files folder, since we know that's writable by Drupal) . This file (which I called 'staffmapping.txt') is what we used for a simple text-based rewrite map. Sample output of the update hook looked like this:

# User ID to Name mapping: 1 admin-admin 2 john-smith 3 john-smith-2 4 jane-smith

The format of this file is pretty straight-forward: comments can be started on any line with a #, and the mapping lines themselves are composed of {lookupValue}{whitespace}{replacementValue}.

To actually consume this mapping somewhere in our rules, we must let Apache know about the mapping file itself. This is done with a RewriteMap directive, which can be placed in the Server config or else inside a VirtualHost directive. The format of the RewriteMap looks like this: RewriteMap MapName MapType:MapSource. In our case, the file is a simple text file mapping, so the MapType is 'txt'. The resulting string added to our VirtualHost section is then: RewriteMap staffremap txt:/path/to/staffmapping.txt This directive makes this rewrite mapping file available under the name "staffremap" in our RewriteRules. There are other MapTypes, including ones that uses random selection for the replacement values from a text file, using a hash map rather than a text file, using an internal function, or even using an external program or script to generate replacement values.

Now it's time to actually change incoming URLs using this mapping file, providing the 301 redirect we need. The rewrite rule we used, looks like this:

RewriteRule ^user-detail/([0-9]+)(.*) /user-detail/${staffremap:$1}$2 [R=301,L]

The initial argument to the rewrite rule identifies what incoming URLs this rule applies to. This is the string: "^user-detail/([0-9]+)(.*)". This particular rule looks for URLs starting with (signified by the special character ^) the string "user-detail/", then followed by one or more numbers: ([0-9]+), and finally, anything else that might appear at the end of the string: "(.*)". There's a particular feature of regex being used here as well: each of search terms in parenthesis are captured (or tagged) by the regex processor which then provides some references that can be used in the replacement string portion. These are available with $<captured position>—so, the first value captured by parenthesis is available in "$1"—this would be the user ID, and the second in "$2"—which for this expression would be anything else appearing after the user ID.

Following the whitespace is our new target URL expression: "/user-detail/${staffremap:$1}$2". We're keeping the beginning of the URL the same, and then following the expression syntax "${rewritemap:lookupvalue}", which in our case is: "${staffremap:$1}" we find the new user-name URL. This section could be read as: take the value from the rewrite map called "staffremap", where the lookup value is $1 (the first tagged expression in the search: the numeric value) and return the substitution value from that map in place of this expression. So, if we were attempting to visit the old URL /user-detail/1/about, the staffremap provides the value "admin-admin" from our table. The final portion of the replacement URL (which is just $2) copies everything else that was passed on the URL through to the redirected URL. So, for example, /user-detail/1/about includes the /about portion of the URL in the ultimate redirect URL: /user-detail/admin-admin/about

The final section of the sample RewriteRule is for applying additional flags. In this case, we are specifying the response status of 301, and the L indicates to mod_rewrite that this is the last rule it should process.
That's basically it! We've gone from an old URL pattern, to a new one with a redirect mapping file, and only two directives. For an added performance perk, especially if your list of lookup and replacement values is rather lengthy, you can easily change your text table file (type txt) with a HashMap (type dbm) that Apache's mod_rewrite also understands using a quick command and directive adjustment. Following our example, we'll first run:

$> httxt2dbm -i staffrepam.txt -o

Now that we have a hashmap file, we can adjust our RewriteMap directive accordingly, changing the type to map, and of course updating the file name, which becomes:

RewriteMap staffremap dbm:/path/to/

RewriteMap substitutions provide a straight-forward, and high-performance method for pretty extensive enhancement of RewriteRules. If you are not familiar with RewriteRules generally, at some point you should consider reviewing the Apache documentation on mod_rewrite—it's worthwhile knowledge to have.

Categories: Elsewhere

Dries Buytaert: One year later: the Acquia Certification Program

Wed, 01/07/2015 - 15:31

A little over a year ago we launched the Acquia Certification Program for Drupal. We ended up the first year with close to 1,000 exams taken, which exceeded our goal of 300-600. Today, I'm pleased to announce that the Acquia Certification Program passed another major milestone with over 1,000 exams passed (not just taken).

People have debated the pros and cons of software certifications for years (including myself) so I want to give an update on our certification program and some of the lessons learned.

Acquia's certification program has been a big success. A lot of Drupal users require Acquia Certification; from the Australian government to Johnson & Johnson. We also see many of our agency partners use the program as a tool in the hiring process. While a certification exam can not guarantee someone will be great at their job (e.g. we only test for technical expertise, not for attitude), it does give a frame of reference to work from. The feedback we have heard time and again is how the Acquia Certification Program is tough, but fair; validating skills and knowledge that are important to both customers and partners.

We also made the Certification Magazine Salary Survey as having one of the most desired credentials to obtain. To be a first year program identified among certification leaders like Cisco and Red Hat speaks volumes on the respect our program has established.

Creating a global certification program is resource intensive. We've learned that it requires the commitment of a team of Drupal experts to work on each and every exam. We know have four different exams: developer, front-end specialist, backend specialist and site builder. It roughly takes 40 work days for the initial development of one exam, and about 12 to 18 work days for each exam update. We update all four of our exams several times per year. In addition to creating and maintaining the certification programs, there is also the day-to-day operations for running the program, which includes providing support to participants and ensuring the exams are in place for testing around the globe, both on-line and at test centers. However, we believe that effort is worth it, given the overall positive effect on our community.

We also learned that benefits are an important part to participants and that we need to raise the profile of someone who achieves these credentials, especially those with the new Acquia Certified Grand Master credential (those who passed all three developer exams). We have a special Grand Master Registry and look to create a platform for these Grand Masters to help share their expertise and thoughts. We do believe that if you have a Grand Master working on a project, you have a tremendous asset working in your favor.

At DrupalCon LA, the Acquia Certification Program offered a test center at the event, and we ended up having 12 new Grand Masters by the end of the conference. We saw several companies stepping up to challenge their best people to achieve Grand Master status. We plan to offer the testing at DrupalCon Barcelona, so take advantage of the convenience of the on-site test center and the opportunity to meet and talk with Peter Manijak, who developed and leads our certification efforts, myself and an Acquia Certified Grand Master or two about Acquia Certification and how it can help you in your career!

Categories: Elsewhere

Jim Birch: Essential Drupal: Stage File Proxy

Wed, 01/07/2015 - 11:20

We can easily checkout code from our git repositories for our local, development, and staging servers.  We can get a database from the live site through Backup and Migrate, drush, or a number of other ways.  But getting the files of the site, the images, pdfs, and everything else in /sites/default/files is not on the top of the list of most developers.  In recent versions of Backup and Migrate, you can export the files, but often times, this can be a huge archive file.  There is an easier way.

The Stage File Proxy module saves the day by sending requests for files to the live server if it does not exist yet in your local environment.  This saves you space on your non-production environment since it only grabs files from the pages you visit.  Great for us that have dozens of sites on our local. 

As simple as can be, it gets the files you need on your local server, as you need them.  No more navigating broken looking dev sites.  This will get your environment looking as it should so you can concentrate on your task at hand.

Read more

Categories: Elsewhere

Sooper Drupal Themes: YoutTube Video of Drupal Theme integrated Drag and Drop builder

Wed, 01/07/2015 - 10:22
After I posted a case study last week I had a number of readers ask me if they could try a demo and see how it works. There is no try-out demo yet but in the meanwhile I produced a video that demonstrates the basic controls: .embed-container { position: relative; padding-bottom: 56.25%; height: 0; overflow: hidden; max-width: 100%; } .embed-container iframe, .embed-container object, .embed-container embed { position: absolute; top: 0; left: 0; width: 100%; height: 100%; } If you have any questions about integration and the open source library that powers it feel free to contact or comment! Tags planet drag and drop glazed planet drag and drop glazed Drupal 7.x
Categories: Elsewhere

KatteKrab: Comparing D7 and D8 outta the box

Wed, 01/07/2015 - 03:53
Wednesday, July 1, 2015 - 11:53

I did another video the other day. This time I've got a D7 and D8 install open side by side, and compare the process of adding an article.

Categories: Elsewhere

Pixelite: Debugging Drupal performance with Cache Debug module

Wed, 01/07/2015 - 02:00

This blog post is for developers, not site builders, as the analysis for cache debugging requires knowledge about the runtime stack of Drupal.

The Problem with Caching in Drupal 7

To obtain performance in Drupal 7, Drupal relies heavily on caching. That is, to process something and cache the end result so that same work doesn’t need to be repeated. Conditions also have to be created for when that cache expires or is invalidated. Drupal has a caching layer to help with this. When you want to store something in cache, you use cache_set, to retrieve it, you use cache_get and to wipe the cache bin clean, you can use cache_clear_all.

Often, modules can implicitly clear or set cache unintentionally. This can lead to more caching overhead than you need. For example, theme registry clearing, use of the variable_set function or calls to other modules that call cache_clear_all. The problem is, how do you track down culprits to fix the issue?

Enter Cache Debug

Cache Debug is a module that wraps around the caching layer and adds logging. Including stacktrace information. It means when a cache_set or cache_clear_all is called, you can trace back to what called it - understand the problem and fix it. Very quickly.

It comes with three logging options:

  • watchdog - good if you’re using syslog module but deadly if you’re using dblog.
  • error_log - logs to your php error log
  • arbitrary file - specify your own log file to log to
Configuring Cache Debug

Because the caching system is so highly utilized, cache logging can be incredibly verbose. Perhaps this is why there is no logging around this in Drupal core. Fortunately, Cache Debug is highly configurable to control what to log.

NOTE: Because the caching system is loaded and used before Drupal’s variable system which manages configuration, it is best to set configuration in settings.php rather than in the database. However, there is a web UI that does set configuration in the database for ease of use.

Basic configuration

If you’ve used the memcache module before, this should feel familiar. In order to use Cache Debug, you need to set it as the cache handler:

<?php $conf['cache_backends'][] = 'sites/all/modules/cache_debug/'; $conf['cache_default_class'] = 'DrupalDebugCache'; ?>

This tells Drupal that there is a cache backend located in the path provided (make sure its correct for your Drupal site!) and that the default class for all cache bins is the DrupalDebugCache class. If you only want to monitor a single bin you may want to omit this option.

Since Cache Debug is a logger and not an actual caching system, it needs to pass cache requests onto a real cache system. By default, Debug Cache will use Drupal core’s Database Cache system for cache storage, but if you’re using memcache, redis or similar, you may want to set that as the handler for Cache Debug:

<?php $conf['cache_debug_class'] = 'MemCacheDrupal'; $conf['cache_cache_debug_form'] = 'DrupalDatabaseCache'; ?>

You need to also configure those modules accordingly.

At this point, you’ll be logging all cache calls and stack traces to set and clear calls to the php error log.

Configure the logging location

You may want to choose your own logging location. For example, if you use dblog, then you won’t want to log to watchdog because it will bloat your database. Likewise, if you don’t want to bloat our php error log, then you may want to log to an arbitrary file. You can choose your logging location by setting cache_debug_logging_destination to error_log (default), watchdog or file. For file you will also need to provide the location:

<?php $conf['cache_debug_logging_destination'] = 'file'; $conf['cache_debug_log_filepath'] = '/tmp/cachedebug.log'; ?> Configuring logging options

You can choose to log calls to cache get, getMulti, set and clear. You can also choose to log a stacktrace of these calls to show the stack that triggered the call. This is most useful for calls to SET and CLEAR. For a minimal logging option with the most about of insight, you might want to try this:

<?php $conf['cache_debug_log_get'] = FALSE; $conf['cache_debug_log_getMulti'] = FALSE; $conf['cache_debug_log_set'] = TRUE; $conf['cache_debug_log_clear'] = TRUE; $conf['cache_debug_stacktrace_set'] = TRUE; $conf['cache_debug_stacktrace_clear'] = TRUE; ?> Logging per cache bin

You don’t have to log the entire caching layer if you know which bin to look at for the caching issue you’re observing. For example, if you’re looking for misuse of variable_set, you only need to log the cache_bootstrap bin. In which case you could do this:

<?php # Do not log to all cache bins so ensure this line is removed (from above): # $conf['cache_default_class'] = 'DrupalDebugCache'; $conf['cache_bootstrap_class'] = 'DrupalDebugCache'; ?> Configure for common issues

Variable set calls and theme registry rebuilds are the two most common issues and so Cache Debug has use cases for these issues built in. So long as Cache Debug is the cache handler for the bin, you can turn off logging and turn on these features and Cache Debug will only log when these issues occur:

<?php $conf['cache_default_class'] = 'DrupalDebugCache'; $conf['cache_debug_common_settings'] = array( 'variables' => TRUE, 'theme_registry' => TRUE, ); // Turn off logging $conf['cache_debug_log_get'] = FALSE; $conf['cache_debug_log_getMulti'] = FALSE; $conf['cache_debug_log_set'] = FALSE; $conf['cache_debug_log_clear'] = FALSE; ?> Analysing the logged data

Cache debug logs to a log file like the example below:

In this snapshot of log output you can see both how cache debug logs cache calls and the stacktracing in action.

Log format structure

A log line starts with a value that describes the cache bin, the cache command and the cache id. E.g. cache_bootstrap->set->variables would bet a cache_set call to the cache_bootstrap cache bin to set the variables cache key. Some calls also log additional data, for example, cache clear also indicates if the call was a wildcard clear. Set calls also log how much data (length) was set.

Stack trace logs

When stack tracing is enabled for specific commands, a stack trace will be logged immediately after the log event that triggered it. The trace rolls back through each function that led to the current cache command being triggered. In the example above you can see that cache_clear_all was called by drupal_theme_rebuild which was called by an include from phptemplate_init. If you look at the source code in phptemplate_init, you’ll see that this means a cache rebuild was triggered from including template.php. In this case it was that Zen base theme had the theme registry rebuild left on.

Categories: Elsewhere

Open Source Training: Using Administration Menu and Shortcuts in Drupal

Tue, 30/06/2015 - 19:26

An OSTraining members took our recommendation and installed the Administration Menu module, which makes it much easier to navigate through your Drupal site.

However, after enabling Administration Menu, they found that they lost their Shortcuts menu. This is normally the grey bar under Drupal's default admin toolbar.

Here's how to use Administration Menu and Shortcuts together.

First, make sure that "Administration menu" is enabled, but also make sure that the "Administration menu Toolbar style" module is enabled:

Now go to Configuration > Administration Menu and you'll now be able to check the "Shortcuts" box, as in the image below. This will re-enable the Shortcuts menu.


If you don't see the Shortcuts menu immediately, try clicking the down arrow in the top-right corner:

Categories: Elsewhere

Pantheon Blog: An Example Repository to Build Drupal with Composer on Travis

Tue, 30/06/2015 - 18:59
A robust Continuous Integration system with good test coverage is the best way to ensure that your project remains maintainable; it is also a great opportunity to enhance your development workflow with Composer. Composer is a dependency management system that collects and organizes all of the software that your project needs in order to run. 
Categories: Elsewhere

Acquia: Caching to Improve Drupal Performance: The Three Levels You Should Know

Tue, 30/06/2015 - 18:07

In our continuing mission (well, not a mission; it’s actually a blog series) to help you improve your Drupal website, let’s look at the power of caching.

In our previous post, we debunked some too common Drupal performance advice. This time we're going positive, with a simple, rock-solid strategy to get you started: caching is the single best way to improve Drupal performance without having to fiddle with code.

At the basic level, it is easy enough for a non-technical user to implement. Advanced caching techniques might require some coding experience, but for most users, basic caching alone will bring about drastic performance improvements.

Caching in Drupal happens at three separate levels: application, component, and page. Let’s review each level in detail.

Application-level caching

This is the caching capability baked right into Drupal. You won't see it in action unless you dig deep into Drupal's internal code. It is enabled by default and won't ever show older, cached pages.

With application-level caching, Drupal essentially stores cached pages separately from the site content (which goes into the database). You can't really configure this, except for telling Drupal where to save cached pages explicitly. You might see improved performance if you use Memcached on cached pages, but the effect is not big enough to warrant the effort.

Drupal stores many of its internal data and structures in efficient ways to improve frequent access when application-level caching. This isn’t information that a site visitor will see per se, but it is critical for constructing any page. Basically, the only enhancements that can be made at this level are improving where this cached information is stored, like using Memcached instead of the database.

You just need to install Drupal and let the software take care of caching at the application-level.

Component-level caching

This works on user-facing components such as blocks, panels, and views. For example, you might have a website with constantly changing content but a single block remains the same. In fact, you may have the same block spread across dozens of pages. Caching it can result in big performance improvements.

Component-level caching is usually disabled by default, though you can turn it on with some simple configuration changes. For the best results, identify blocks, panels, and views that remain the same across your site, and then cache them aggressively. You will see strong speedups for authenticated users.

Page-level caching

This is exactly what it sounds like: The entire page is cached, stored and delivered to a user. This is the most efficient type of caching. Instead of generating pages dynamically with Drupal bootstrap, your server can show static HTML pages to users instead. Site performance will improve almost immeasurably.

Page-level caching gives you a lot of room to customize. You can use any number of caching servers, including Varnish, which we use at Acquia Cloud. You can also use CDNs like Akamai, Fastly, or CloudFlare to deliver cached pages from servers close to the user's location. With CDNs, you are literally bringing your site closer to your users.

Keep in mind that forced, page-level caching works only for anonymous users by default. Fortunately, this forms the bulk of traffic to any website.

It bears repeating: Caching should be your top priority for boosting Drupal performance. By identifying and caching commonly repeated components and using a CDN at page-level, you’ll see site speed improvements that you can write home about.

Next time: How to Evaluate Drupal Modules for Performance Optimization.

Tags:  acquia drupal planet
Categories: Elsewhere