Skip to Content

Planet Drupal

Syndicate content - aggregated feeds in category Planet Drupal
Updated: 1 day 23 hours ago

Mike Crittenden: How Drupal 7 Works, Part 3: The Router

16 September 2015 - 3:13am

This is a chapter out of my in-progress book, Drupal Deconstructed. You can read it online for free, download it as a PDF/ePUB/MOBI, or contribute to it on GitHub.

Alright! Now we're getting somewhere! Here's what we have so far. We have our request to /about-us and we've already run through a full Drupal bootstrap, thanks to index.php.

Now comes the fun part.

A quick summary

If you want the nickel tour of the Drupal menu router (or you don't want to look at any code), then you're in the right place. Here's what you can expect.

First, the very last line of the index.php file kicks things off by telling the menu system to figure out what the request is asking for, and serve it. This happens by looking at the menu_router database table to see if there are any rows that match the current URL.

Assuming we find a match (in this case, our about-us path has been converted during the bootstrap process to something like node/1234, which matches node/% in the menu_router table), we call whatever function the menu_router table tells us to call.

That function will be responsible for building the page content, and the rest is history (or, will be covered in other chapters).

Now, to dig a little deeper.

Step 0. Fetching the system URL for a path alias

We start with step 0 because it has already happened. Remember in the Bootstrap chapter that, during the DRUPAL_BOOTSTRAP_FULL phase, the drupal_path_initialize() function is called. That function just makes sure that $_GET['q'] is set (if it's not, then it sets it to the frontpage URL).

Then, more importantly, it runs through drupal_get_normal_path() to see if we are looking at a path alias rather than an internal path, and if so, replaces it with the internal path that it's aliasing.

All that is to say that by the time the bootstrap is done, $_GET['q'] is set to node/123 even though the initial request was for about-us, because it converts alias paths to system paths.

Step 1. Kick things off from index.php

Our index.php file calls the grand menu_execute_active_handler() function.

First, it checks to see if the site is offline and bypasses a lot of logic if that's the case. It even gives modules a chance to have their say as to whether the site is offline, using hook_menu_site_status_alter().

$page_callback_result = _menu_site_is_offline() ? MENU_SITE_OFFLINE : MENU_SITE_ONLINE; $read_only_path = !empty($path) ? $path : $_GET ['q']; drupal_alter('menu_site_status', $page_callback_result, $read_only_path);

Assuming it's online, then things finally start to get interesting.

From here, we call the menu_get_item($path) function, which does many things, all of which basically amount to "tell us everything we need to know about what to do with this path".

Step 2: Possibly rebuild the menu system

The first interesting thing that function does is check to see if we need to do a menu rebuild, and kicks one off if so.

if (variable_get('menu_rebuild_needed', FALSE) || !variable_get('menu_masks', array())) { if (_menu_check_rebuild()) { menu_rebuild(); } }

We'll assume for now that we don't need to rebuild the menu table, but later in this chapter we'll talk about what happens there.

Step 3: Find the most relevant menu_router row for this path

Still inside menu_get_item().

So with the assumption that we don't need to rebuild the menu system, we can continue on to actually finding what to do for the path we're on. To do that, we query the menu_router table. This table is the source of truth for "what do I need to do for this path?"

Here's the structure of it:

mysql> explain menu_router; +-------------------+--------------+------+-----+---------+-------+ | Field | Type | Null | Key | Default | Extra | +-------------------+--------------+------+-----+---------+-------+ | path | varchar(255) | NO | PRI | | | | load_functions | blob | NO | | NULL | | | to_arg_functions | blob | NO | | NULL | | | access_callback | varchar(255) | NO | | | | | access_arguments | blob | YES | | NULL | | | page_callback | varchar(255) | NO | | | | | page_arguments | blob | YES | | NULL | | | delivery_callback | varchar(255) | NO | | | | | fit | int(11) | NO | MUL | 0 | | | number_parts | smallint(6) | NO | | 0 | | | context | int(11) | NO | | 0 | | | tab_parent | varchar(255) | NO | MUL | | | | tab_root | varchar(255) | NO | MUL | | | | title | varchar(255) | NO | | | | | title_callback | varchar(255) | NO | | | | | title_arguments | varchar(255) | NO | | | | | theme_callback | varchar(255) | NO | | | | | theme_arguments | varchar(255) | NO | | | | | type | int(11) | NO | | 0 | | | description | text | NO | | NULL | | | position | varchar(255) | NO | | | | | weight | int(11) | NO | | 0 | | | include_file | mediumtext | YES | | NULL | | +-------------------+--------------+------+-----+---------+-------+ 23 rows in set (0.00 sec)

That's a lot of stuff right? The primary key is the path field, and everything else is just data about the given path. Here, we can find access arguments/callbacks, page arguments/callbacks, whether the page is a local task (tab) or a menu item or just a plain old callback, any theming alterations to consider, and a ton of other stuff.

So we have a path, and we need to fetch all that other stuff about it. But unfortunately we can't just query for the path, because we care about ancestors. That is to say that, given a URL of node/1234/edit, all of the following need to be returned as matches (in order of best match to worst match):

  • node/1234/edit
  • node/1234/%
  • node/%/edit
  • node/%/%
  • node/1234
  • node/%
  • node

Why? Well, because there probably isn't a row in menu_router with a path of exactly node/1234/edit. It's node/%/edit that will be our match, because that's the first one in that list that will actually exist in menu_router.

But remember, this is a simple example. What about a custom path of people/george/bio/picture/profile which ends up matching with our custom path of people/%/bio/picture/%? Can you see why it's important to ask for all possible ancestor paths, and that way we can find the one that's the most specific match, and use that?

So before we query menu_router, we need to call menu_get_ancestors($path) to fetch the possible ancestor paths for the given path. Only then can we query menu_router to find the path that fits the best. Here's how that all looks at a code level.

$original_map = arg(NULL, $path); $parts = array_slice($original_map, 0, MENU_MAX_PARTS); $ancestors = menu_get_ancestors($parts); $router_item = db_query_range('SELECT * FROM {menu_router} WHERE path IN (:ancestors) ORDER BY fit DESC', 0, 1, array(':ancestors' => $ancestors))->fetchAssoc(); Step 4. Allow altering the router item

Still inside menu_get_item().

Before we can continue on, we need to give modules the ability to alter the menu item right away, before anything else happens, using hook_menu_get_item_alter().

drupal_alter('menu_get_item', $router_item, $path, $original_map);

This differs from the more commonly used hook_menu_alter() in that this is at run-time, as opposed to hook_menu_alter() which only runs when the menu system is being built, and doesn't run as part of a page request.

Step 5: Check for access to the router item

You guessed it! Still inside menu_get_item().

This part is more confusing than you may expect.

It's confusing first of all because it happens in a function called _menu_translate() which means "translate" as in "translate placeholders in the URL to loaded entities (or other things), when needed". (It also translates the menu title to the appropriate language later in this same function, confusing things further).

To start, it needs to translate placeholders (i.e., "%" signs) in paths to the loaded entity if a load function exists for it. For example, if our path in menu_router is node/%node then this chunk of code will say "ok, I see %node as opposed to just %, therefore, I know I need to run node_load() on whatever is in that part of the URL, which in this case is 1234.

To do this, it runs _menu_load_objects() which calls the appropriate load function if there is one and, assuming we don't get an access error, a missing entity, or anything else which would cause a problem, put the result (i.e., the fully loaded entity) back into the menu router item for later use.

As a side note, this is a very common place to hit an access denied page, in cases where the user doesn't have access to whichever entity we're trying to load. For example, an anonymous user trying to view an unpublished node would fail at this step.

So we've made it this far, and we have a loaded entity (remember that the /about-us page we're talking about is a node), but we're not in the clear yet. We still haven't run the access_callback function given to us from the menu_router table.

That part happens via a call to _menu_check_access(), which basically runs the function set in access_callback if one exists, otherwise it falls back to user_access(), and includes any defined access_arguments. The fallback to user_access() means that we can just pass in a permission as access_arguments completely and leave out access_callback in our hook_menu() and it works out just peachy, which is a nice little shortcut.

And we have finally reached the end of menu_get_item()! Hooray!

Step 6: Call the appropriate function for this path

Back inside menu_execute_active_handler(), and here's what we know at this point:

  • We know that whether the user has access to this page or not
  • We know what function to run if the user does have access
  • We know which arguments to pass into that function, if any

We also know a lot of other stuff, but that's all details. Those 3 bullets are all we need at this point.

This little chunk of code is so nice and readable that I'm going to include it directly:

if ($router_item['access']) { if ($router_item['include_file']) { require_once DRUPAL_ROOT . '/' . $router_item['include_file']; } $page_callback_result = call_user_func_array($router_item['page_callback'], $router_item['page_arguments']); } else { $page_callback_result = MENU_ACCESS_DENIED; }

Nice and simple. If we have access, include any given include file if needed, call whatever the page_callback is, and include any given page_arguments. Or, if we don't have access, then just return the access denied page.

Step 7: Deliver the page

And finally, the work of the router is done, and we can just hand the work off to the callback assigned to this path.

$default_delivery_callback = (isset($router_item) && $router_item) ? $router_item['delivery_callback'] : NULL; drupal_deliver_page($page_callback_result, $default_delivery_callback);

Pretty, right? Yeah, not so much, but it definitely gets the job done.

What about (re)building the menu router?

I mentioned earlier that we'd talk about how the menu router gets assembled in the first place. In other words, what exactly happens in the oh-so-scary menu_rebuild() function that takes forever to run?

Well, it all happens in 3 simple steps.

list($menu, $masks) = menu_router_build(); _menu_router_save($menu, $masks); _menu_navigation_links_rebuild($menu);

Let's take it one by one.

Gather the router items

The menu_router_build() function basically calls all hook_menu() implementations and builds a giant array out of them.

This is actually an incredibly scary process. Don't be fooled by how simple menu_router_build() looks; the magic really happens in _menu_router_build() (underscore functions strike again!). Take a look at that one to see what I mean.

I won't go into much detail about what happens there, but the gist is that it takes the info provided to it by various hook_menu() implementations and figures out everything else that the menu_router table wants to store. That includes things like figuring out what the load_function should be based on named placeholders, figuring out if any given link exists in a custom navigation menu, inheriting access callbacks and page callbacks from parent paths if not explicitly defined, etc.

The end result is that we have all of the data given to us by all of the hook_menu() implementations, and it's in a format that menu_router will play nicely with.

Save the router items

Finally, an easy one. The _menu_router_save() function basically just does a giant db_insert() into the menu_router table for each menu item returned by menu_router_build().

It executes in batches of 20 to find a balance between performance and memory overhead, but other than that, there's nothing really tricky happening.

Update the navigation menus

Since hook_menu() lets you place menu items in actual user facing navigation menus using the MENU_NORMAL_ITEM type and the optional menu_name key, we need to actually do the work of putting those items into navigation menus. This happens in _menu_navigation_links_rebuild.

This little guy handles a lot of tough work. For each menu router entry, it'll add it to the appropriate menu, or update it if it's already there, or move it from one menu to another if that changed, or delete it if needed.

It's also smart enough to remove any items from menus that don't have matching router items anymore (so you don't have orphan menu items), or which have changed types from MENU_NORMAL_ITEM to another type. And to top it all off, it deletes them from the bottom up, meaning it starts with the ones with the greatest depth, so that it doesn't have to do as much re-parenting as it would if it deleted them in the opposite or a random order.

When does this happen?

That's all well and good, but what would trigger this to happen? How does Drupal know when it's time to run rebuild the menu router?

Turns out that lots of things trigger that, but it's a bit complicated because there are two ways it can be triggered.

  1. The menu_rebuild() function can be called directly, of course.
  2. The menu_rebuild_needed variable can be set to TRUE which will trigger a call to menu_rebuild() the next time the menu_get_item() is called (see the Possibly rebuild the menu system section of this chapter to see how that happens).

There are a couple obvious things that trigger menu rebuilds. One of the most common is drupal_flush_all_caches() function. Besides being called whenever you manually flush caches (which is about 9000 times a day if you're anything like me), it also gets called by system_modules_submit() when enabling a new module, so that the module's hook_menu() or hook_menu_alter() implementations (or other menu related hooks) can be respected.

Besides that one, there are a few other places that call menu_rebuild() directly. Most notably:

As far as places which set the menu_rebuild_needed variable to TRUE, achieving the same effect, we have a couple notable ones:

Those are the big ones as far as core is concerned. If you search the standard Drupal site's codebase for menu_rebuild then you'll find a bunch more, but most of them belong to either contrib modules or automated test cases. Runtime core code does a relatively good job of only doing a full menu rebuild when it's absolutely necessary.

This is a chapter out of my in-progress book, Drupal Deconstructed. You can read it online for free, download it as a PDF/ePUB/MOBI, or contribute to it on GitHub.

Categories: Drupal

Realityloop: What to see at DrupalCon Barcelona

16 September 2015 - 2:27am
16 Sep Jarkko Oksanen

Everyone in Realityloop will be attending the DrupalCon at Barcelona this year. There is always a lot to see in Drupal events and I've listed the things that excite me the most this year.

1. The Sessions

The sessions build the core of Drupal events. The sessions will be held on Tuesday-Thursday. It's always difficult to find the best sessions to go to, and often the quality of the speaker overshadows the interest of the topic. However the topic is still how we often choose our sessions. These some examples of the great sessions that we can attend, and that interested me personally the most from each day based on the topics!

  1. Serving the Internet of Things (IoT) with Drupal (Tuesday 14.00)
  2. Configuration Management in Drupal 8 (Wednesday 17.00)
  3. 10,000 hours distributed, why being remote is the best way to run a team (Thursday 14.15)

As you can see from these three examples, the session topics will vary greatly. See the full list of sessions here.

2. Birds of a Feather sessions

BOFs are informal small sessions that are held "on-the-spot" and often include a lot more discussion and happen in smaller groups. If you didnt get a chance to talk about your topic, or there is no session that you're interested in, go join or start a BOF!

Read more on BOFs

3. The Sprints

Sprints are the coding and hands-on part of a DrupalCon. Get together to fix issues in your favorite modules, or just get help setting up your first Drupal website. It is a great way to start contributing code back to the community!

There is a lot of sprints at this years DrupalCon.

  1. 19-20 September - Extended Sprints
  2. 21-24 September - Sprints at the Barcelona International Convention Center
  3. 21-24 September - 24-hour Supporter Sponsored Sprint Lounge at the Princess Hotel
  4. 25 September - General Sprints, Mentored Core Sprint, and First-Time Sprinter Workshop at the Barcelona International Convention Center
  5. 26-27 September - Extended Sprints at Makers of Barcelona

See an updated schedule and locations here.

Check out our earlier blog post about Sprints and what they are.

4. Community Social Events

Meeting the people face-to-face you work with on is one of the more fun parts of a DrupalCon. You can see the person who developed the modules you're working on, and ask a question about why they did something in a weird way. There are some community events that you should not miss.

  1. First time attendee social
  2. iKOS + Lingotek: Beers at the Booth
  3. Trivia Night

You can find a more comprehensive list on the event website.

5. The city of Barcelona

When you're in a DrupalCon and your days are booked with great sessions and sprinting, it might be hard to allocate some time for sightseeing. But dedicating some time for that will make the trip much more worth it.

Go see Tibidabo.

Jarkko Oksanen (jOksanen)

drupal planetdrupalconbarcelona
Categories: Drupal

Drupal core announcements: Your turn to provide feedback on the Drupal 8 cycle!

16 September 2015 - 2:10am

Dries Buytaert, the Drupal project lead, will facilitate a Drupal 8 retrospective discussion at DrupalCon Barcelona.

After more than four years of development, Drupal 8 is quickly approaching its first release candidate. This will be a landmark release with myriad new features and improvements. In addition to many technical changes, we innovated on how we collaborate on the Drupal project itself as well as on We involved more than three times the contributors of Drupal 7. Now it's time to take stock of the cycle, of where we've been and how it went, so we can keep improving. We'd like your input on the following:

  1. What worked well? What were the highlights of the Drupal 8 cycle?
  2. What didn't work well? What are lessons we've learned for upcoming releases or for the community as a whole?
  3. What concrete improvements can we make for future releases (both minor and major)? We welcome suggestions around teams, tools, or processes.

Please submit your answers online. Dries will gather the community's responses and use them as the basis for the open discussion at DrupalCon Barcelona.

Categories: Drupal

Morpht: Creating custom templates in WYSIWYG

15 September 2015 - 4:30pm

Creating responsive websites is easy these days with frameworks like Zurb’s Foundation and Bootstrap. The WYSIWYG API template plugin module allows us to predefine templates in WYSIWYG, helping editors to layout content for a mobile friendly website.

Categories: Drupal

Mediacurrent: Introducing Drupal Through Its Community

15 September 2015 - 2:21pm

When you ask people, “What makes Drupal different?” you can expect a variety of answers. Many people are likely to point to its flexibility. The technically-minded might reference Drupal’s hook system or Entity API. One of the most common answers, however, will be one that many people new to Drupal will find unexpected when discussing software: the Drupal community.

Categories: Drupal

DrupalCon News: Coffee breaks at DrupalCon

15 September 2015 - 12:18pm

DrupalCon is almost here, which means it's time to discuss one of the most controversial topics in our community: coffee!

Categories: Drupal

OSTraining: How to Use Aggregation and Compression in Drupal

15 September 2015 - 11:47am

By default, the Drupal 7 core loads around 20 different CSS and Javascript files.

So, in order to make your Drupal site run quickly, it's essential to load those files as quickly as possible. It's easy to get started by enabling the aggregation and compression options in Drupal.

Aggregation gathers all the files together and loads them as one. Compression reduces the size of each individual file, stripping out unnecessary characters, whitespace and implementing CSS shortcuts.

In this video, Robert Ring shows you how enable Drupal's core aggregation and compression options:

Categories: Drupal

Acquia Developer Center Blog: 10 New Features in Drupal 8 Core

15 September 2015 - 11:17am
Steve Burge

If you're reading this post in the Acquia Developer Center, I'm guessing that you may have used Drupal before.

You might be familiar with Drupal 6 or 7, and with some of the modules that shipped with those Drupal versions.

But, Drupal 8 is coming later this year -- a completely re-written version of the platform. This newest version will include lots of new features.

Here's an introduction to 10 new features that will be exciting when you use Drupal for the first time.

Tags: acquia drupal planet
Categories: Drupal

OSTraining: Introducing the 5 New Fields in Drupal 8

15 September 2015 - 11:13am

The Drupal 8 core has far more features than the Drupal 7 core. Many popular contributed modules have been included in the core, including five field types.

Here are the 5 new fields in Drupal 8:

  • Date
  • Email
  • Link
  • Telephone
  • Reference
Categories: Drupal

Cheeky Monkey Media: Require JS, Grunt, Bower, Foundation and Drupal - Part 2

15 September 2015 - 9:13am

Welcome back. If you just found this, you might want to start with Part 1 before reading on.

Okay, now we’re going into our custom theme folder (that’s based off the STARTER foundation sub-theme. Check out Justin’s Blog post, on how to set that up.

So, now that you’ve got your custom sub-theme...

Categories: Drupal

Drupal @ Penn State: Purespeed: Cache bin backends

15 September 2015 - 8:06am

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

Categories: Drupal Understanding Drupal Security Advisories: The Risk Calculator

15 September 2015 - 7:06am

Every Wednesday, the Drupal Security Team publishes "Security Advisories" (or SA's) to tell users about security vulnerabilities in Drupal core and contrib modules, with advice on how to solve the issue so that their site is secure.

This is the first in a series of articles about how to better understand all the information in a security advisory, so that you know how to take the appropriate action for your site!

Not all security vulnerabilities are equal!

Some are highly critical and require immediate action (like SA-CORE-2014-005, aka Drupalgeddon, was) or your site could be irrepairably damaged and you'll have to restore from backups.

And while you should take action on any security advisory that affects your site as soon as possible (or hire someone else to do it), some security vulnerabilities present less risk, so you might choose to delay updating and focus on more important things in your business or personal life.

But how do you make that decision?

All security advisories come with a "Security risk" that is generated by the Risk Calculator, which is where the labels like "Less Critical" or "Highly critical" come from.

However, those labels aren't very instructive because they don't really tell you want your at risk of. 

Each security advisory also includes the full set of values provided to the Risk Calculator - which contain a wealth of information about the vulnerability - you just need to know how to decode and understand it.

That's what this article is about!

Read more to learn how to understand the Risk Calculator used in Drupal Security Advisories!

Categories: Drupal

Drupalize.Me: Speed Up CasperJS Tests By Skipping Unnecessary HTTP Resources

15 September 2015 - 6:02am

You know all those JavaScript tracking codes that get added to the footer of every page on your site? Google Analytics is the classical example, but there are tons of others out there. They are slowing your pages down, which in turn slows down your test suite. In this post we'll look at how you can skip unnecessary resources when using CasperJS for testing.

Categories: Drupal

Dries Buytaert: How Acquia is addressing the explosion of sites

15 September 2015 - 2:50am

I believe that the "digitalization" of the world is a "megatrend" that will continue for decades. On the one hand, organizations are shifting their businesses online, often inventing new ways to do business. On the other hand, customers are expecting a better and smarter user experience online.

This has led to two important sub-trends: (1) the number of sites an organization is creating and managing is growing at a rapid clip, (2) so is the underlying complexity of each website.

Forrester Research recently surveyed large enterprises about their website portfolio and found that on average they manage 268 properties across various channels. On top of that, each website is becoming more and more advanced. They evolved from simple HTML pages to dynamic websites to digital experience platforms that need to integrate with many other business systems. The combination of these two trends -- increasing number of sites and the growing complexity of each site -- poses real challenges to most organizations.

At Acquia, we are seeing this explosion of websites in the enterprise every day. Many organizations have different websites for different brands and products, want different websites for each country or region they operate in, or offer separate portals for their affiliates, dealers, agents or franchises. We're also seeing organizations, small and large, operate a large number of marketing campaign websites. These organizations aren't focused on scaling back their online properties but rather how best to manage them over time.

I outlined this trend and its challenges almost five years ago (see Acquia product strategy and vision) and most of it is still relevant today, if not more relevant. In this blog post, I want to give you an update and share some lessons learned.

Current situation

Most larger organizations run many different types of websites. It's not unusual for a small organization to have ten websites and for a large organization to have hundreds of websites. Some of our largest customers operate thousands of websites.

Most organizations struggle to manage their growing portfolio of digital properties. It's not unusual that an organization has more than 25 different content management systems. Often this means that different teams are responsible for them and that they are hosted on different hosting environments. It is expensive, creates unnecessary security risks, poses governance challenges, leads to brand inconsistency, makes it difficult to create a unified customer experience, and more. It costs large organizations millions of dollars a year.

Drupal's unfair advantage

When managing many sites, Drupal has an unfair advantage in that it scales from simple to complex easily. That scalability, coupled with a vast ecosystem of modules, elevate Drupal from a single site point solution to a platform on which you can build almost any kind of site: a brand site, a corporate website, a customer support community, a commerce website, an intranet, etc. You name it.

This is in contrast to many of Drupal's competitors that are either point solutions (e.g. SharePoint is mainly used for intranets) or whose complexity and cost don't lend themselves to managing many sites (e.g. Adobe Experience Manager and Sitecore are expensive solutions for a quick marketing campaign site, while WordPress can be challenging for building complex websites). So the first thing people can do is to standardize on Drupal as a platform for all of their site needs.

By standardizing on Drupal, organizations can simplify training, reduce maintenance costs, streamline security, and optimize internal resources – all without sacrificing quality or requirements. Standardizing on Drupal certainly doesn't mean every single site needs to be on Drupal. Transitioning from 25 different systems to 3 still translates into dramatic cost savings.

The Acquia advantage

Once an organization decides to standardize on Drupal, the question is how best to manage all these sites? In 2013 we launched Acquia Cloud Site Factory (ACSF), a scalable enterprise-grade multi-site management platform that helps organizations to easily create, deploy, and govern all their sites. Today, some of Acquia's biggest customers use ACSF to manage hundreds of sites - in fact on average an ACSF customer is currently managing 170 websites within their Site Factory platform and that number is growing rapidly.

Acquia commissioned Forrester Research to analyze the benefits to organizations who have unified their sites on a single platform. Forrester found that moving to a single platform dramatically reduced site development and support costs, conserved IT and marketing resources, and improved standardization, governance, and scalability — all while accelerating time-to-market and the delivery of better digital experiences.

One of the things we've learned is that a complete multi-site management solution needs to include advanced tools for both developers and content managers. The following image illustrates the different layers of a complete multi-site management solution:

The different layers of the Acquia Cloud Site Factory solution stack.

Let's go through these individually from the bottom up.

Infrastructure management

Consider an organization that currently has 50 websites, and plans to add 10-15 more sites every year. With ACSF these sites run on a platform that is scalable, secure, and highly reliable. This infrastructure also allows hardware resources to be logically isolated based on the site's needs as well as scaled up or down to meet any ad-hoc traffic spikes. These capabilities enable organizations to simplify multi-site management efforts and eliminate operational headaches.

Code management

If this organization with 50 sites had individual codebases for each site, that would be 50 disparate codebases to manage. With ACSF, the underlying code can be shared and managed in one central place but the content, configuration, and creative look-and-feel can be catered to each individual sites' needs. ACSF also enable developers to easily add or remove features from their codebases for individual sites. ACSF also comes with tools to automate the process of rolling out updates across all their sites.

Site management

Organizations with many sites also need efficient ways to manage and govern them effectively; from developer tools such as Git, Travis, or Behat that enable them to build, test, and maintain sites, to tools for non-developers to quickly clone and spin up sites using site templates defined by a brand manager or a digital design team. ACSF enables customers to effortlessly manage all their sites from a single intuitive dashboard. Developers can create groups of users as well as sites allowing certain users to manage their dedicated domain of sites without stepping over other sites. Non-technical content managers can quickly spin up new sites by cloning existing ones they have access to and updating their configuration, content, and look-and-feel. These features allow organizations to launch sites at unprecedented speed inherently improving their overall time to market.

Content sharing

Write once, publish anywhere. We learned from customers managing multiple sites that one thing they often need is the ability to easily share content between sites. For example, if an organization has a privacy policy that needs to be updated, it doesn't make sense to update all their 50 sites individually. There needs to be an easier way to discover existing content that can be repurposed across other sites as well as the ability to author new content once within a platform and deliver it to other sites as needed.


Finally, I should mention personalization. For a few years now we have been developing Acquia Lift. Acquia Lift builds unified customer profiles across all your websites, and uses that information to deliver real-time, contextual, and personalized experiences. For instance, if the organization in the above example had 50 websites for each of their 50 different products, Acquia Lift can present relevant content to its users as they browse across these different sites. This enables organizations to convert anonymous site visitors into known customers and establish a meaningful engagement between them.


I believe that the "multi-sites era" will continue to accelerate; not only will we see more sites, but every site will become increasingly complex. Organizations need to think about how to efficiently manage their website portfolio. If you're not thinking ahead, you're falling behind.

Categories: Drupal

InternetDevels: Symfony2 console: tutorial for beginners

15 September 2015 - 12:55am

This tutorial should be useful for those who are interested in Symfony web development. In Symfony, there are many console commands to help you in your work. We will consider the most frequently used Symfony commands. For example, the cache cleaning command:

Read more
Categories: Drupal

ERPAL: 3 business benefits to achieve by using Drop Guard

15 September 2015 - 12:49am

After a month of Drop Guards closed beta we aggregated the most important business benefits from our beta testers. We want to share those benefits with you: 

1. Focus your capacity
As a manager of a company one of your main activities is to hold distractions off your team. You will try to create an environment where your team can focus their time on their work and what they can do best. So how does Drop Guard help you here?
Drop Guard will monitor your websites for new updates. The configuration is very flexible so you can adapt Drop Guard to your workflow easily. What will happen, when you read that there is a new security update for Drupal? You can call your customer and tell them that their site is up to date. Automatically. And what will happen at your team? They will be glad because they don't need to loose their current focus and switch over to updating all your client sites. You will safe time and money and you will relieve your team. 
Drop Guard will even take care about the patches that might be a part of your project's modules. The developer does not need to look through all the patched modules to update the website. Those patches will be detected by Drop Guard and they will be reapplied after the update automatically.

2. Create sustainable monthly revenue
Customers still need support after a project has been released. The services you offer could be ongoing user support or continuous update support with a SLA for security updates. Sometimes those security updates need to be applied very quickly so you'll need someone who monitors those sites and their available updates all arround the clock - even at the weekend. With Drop Guard you can sell this SLA service without the need for developer to monitor those sites. The updates will be processed automatically in a short time. It will help you scaling your business and keep sales fluctuations away from your business by adding monthly recurring revenue.

3. Improve the satisfaction of your customer and your team
Drop Guard helps your support team to keep your websites updated and secure. It will grow your monthly recurring revenue and your development team can focus on more important tasks in your complex projects. If updates are available there is no need to tell "Our developer will take care of it when they are free" - it will be "Drop Guard will take care of it automatically".

We're intrested in every critical input around the topic "can automatic updates improve the Drupal ecosystem?". We'd like to have a constuctive conversation about these three topics: 

  1. Create a monthly recurring revenue with Drupal update services
  2. Optimize the customer relationship by fast and uncomplicated updates
  3. Save time so that your team can focus on important project work

We're looking forward to a dialogue with you!

We're also represented at DrupalCon in Barcelona from September 21st to 25th, you will find us at booth no. 605 – visit us and discover our prepared surprise for you!

Categories: Drupal

DrupalCon News: How to Get Involved with DrupalCon Asia

14 September 2015 - 2:00pm

With DrupalCon Asia planning kicking off, we took some time last week to loop the community in and let everyone know where we are as well as how you can get involved in the Con!. You can watch a video of the webcast that we hosted here.

If you're interested in getting involved, there are many ways that you can do so:

Categories: Drupal Announcing: The Drupal Showcase Podcast

14 September 2015 - 1:55pm
Categories: Drupal

Greater Los Angeles Drupal (GLAD): Silicon Beach Drupal Meetup at Flipagram

14 September 2015 - 1:30pm

We're excited to announce another Greater Los Angeles Drupal special event: Silicon Beach Drupal at Flipagram. This event focuses heavily on the needs of startups, innovative ways to use the Drupal framework and related technologies, and the nuts and bolts of product development and customer acquisition.

This time we're meeting from 7-9pm Pacific Time on September 17, 2015, and are being hosted by our friends at Flipagram in Century City, CA. There is free parking, free food and beer, ping pong, and like-minded people to meet and mingle with.

This event is free to attend! For those who'd like to attend via video conference, stay tuned to @GLADrupal on Twitter and the comments at

There are two main presentations at this event, How to Host on the AWS 12 Month Free Tier and Flipagram’s UI/UX Problem Solving.

How to Host on the AWS 12 Month Free Tier

At this special event, Dylan Burris (wwwprola on, Lead Developer, will show you simple yet robust ways to create high traffic, business-grade websites on Amazon Web Services' 12 month free tier, further demonstrating the Drupal-based AWS management platform he introduced during his lightning talk at the LA Drupal meetup in August, 2015.

We'll show you our Drupal-based point-and-click tools for building infrastructure optimized for popular content management systems, including Drupal and WordPress, and effective workflows, which are built in a matter of minutes and will sustain your needs for the life of your website.

What's Amazon AWS Free Tier?

Amazon Web Services (AWS) offers new customers 12 months of free hosting. We’re going to show you simple ways to take control and build a web hosting platform you can start using in a matter of minutes, but will continue to scale with you in a professional environment.

This web hosting platform will give you freedom to create in your own personal way, and keep you and your clients happy with high performance, scalable and resilient infrastructure for the life of their website.

Even if you’re already familiar with AWS, you will discover new, simpler ways to create websites and manage resources. And, if you’re not familiar, members who show up will receive continued support for answering questions through our website.

Flipagram’s UI/UX Problem Solving

Adrian Lopez, Lead Front-end Architecht for Flipagram, will discuss the challenges Flipagram has encountered and the solutions they discovered on their mission to scaling to billions of users.

Looking to work with a company to solve meaningful problems? Check out their jobs and meet Flipagram decision makers at the event!

Call for Presenters!

Would you like to present at a future event? Do you have a job announcement you’d like to share with our group? Contact Christefano or Dylan.


Flipagram is in the big red building on Santa Monica Blvd. and Beverly Grove. Parking garage entrance is next to SmithHouse's "SH" logo. Parking will be validated!

10351 Santa Monica Blvd Suite 310
Los Angeles, CA 90025

Flipagram makes it incredibly easy for anyone with a phone to create and share compelling visual stories using their photos, videos and music. With tens of millions of monthly users worldwide and growing, Flipagram is fast becoming the world’s favorite app for telling amazing short-video stories that can inspire, entertain or inform -- anyone, anywhere.

To learn more about Flipagram, see the Flipagram website, download it for Android or iOS, or see Flipagram Raises $70M, Scores Record Label Deals Thanks To 30M+ Music Hungry Users on TechCrunch.

Tags: FlipagramSilicon Beach DrupalPlanet Drupal
Categories: Drupal

Drupal @ Penn State: Purespeed: PHP tuning

14 September 2015 - 1:06pm

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

Categories: Drupal

about seo