Add reCaptcha to your Drupal 7 forms programatically

Posted by on October 25, 2016 at 12:46pm

If you want to add Google's reCaptcha ( to your Drupal 7 forms programmatically you need to follow these two steps:

1) Install and enable captcha ( and recaptcha ( modules. The best ...

Read now

Some great health care websites built with Drupal

Posted by InternetDevels on October 25, 2016 at 12:02pm
Some great health care websites built with Drupal

Let’s feel Drupal’s pulse! It looks like the popular site-building platform is doing great. It remains a perfect fit for all kinds of sites.

Read more

My second BADCamp

Posted by Enzolutions on October 25, 2016 at 12:00am

Last week I had the opportunity of participating in my second BADCamp as part of my tour Around the Drupal world in 140+ days.

My first assistance was in 2012, a lot have changed from that time to now. At that time I was only assistant and was impress for the quality of the event and how vibrant was the community in San Francisco Bay Area.

The event itself doesn't change too much, the same venue, but a little more disperse in my opinion.

What change was my participation with Jesus Manuel Olivas one of my business partners at weKnow. We lead a training about Drupal 8 module development

Slides: []

Also we have a session about how to learn about Drupal 8 via debugging


Airplane Distance (Kilometers) San Jose, Costa Rica → Panama, Panama → San Francisco, USA 5.880 Previously 109.137 Total 115.017 Walking Distance (steps) Bay Area 58.408 Previously 1.936.685 Total 1.995.093 Train Distance (Kilometers) Today 0 Previously 528 Total 528 Bus/Car Distance (Kilometers) Today 796 Previously 2.944 Total 3.740

Highlights From HighEdWeb 2016

Posted by Palantir on October 24, 2016 at 8:23pm
Highlights From HighEdWeb 2016 brandt Mon, 10/24/2016 - 15:23 Allison Manley Oct 24, 2016Pano photo of Memphis river view

HighEdWeb proved to be a valuable experience (again!) and we will be back.

In this post we will cover...
  • What makes HighEdWeb special
  • A few things we learned
  • Some of our favorite sessions

We want to make your project a success.

Let's Chat.

Last week I returned from the HigherEd Web Conference in Memphis, TN. This is one of my favorite conferences because the community is fantastic, the energy is high, the events are well-attended and create an inclusive atmosphere, and it’s just well-run. It’s also a very heavy Twitter user group . . . attendees love to tweet everything early and often, and each session is given its own hashtag so people can follow along. They also have a coveted award called the “Red Stapler” given for best in each track, culminating in a Best Of Conference award.

As if that wasn’t enough, the keynote speakers each year are amazing! This year, Kimberly Bryant of was the first keynote. The community was so supportive of her organization’s work to bring computer science and code to young girls of color that people were donating money on the spot as she spoke, and tweeting it around to encourage others to keep the donations coming.

The final keynote was LeVar Burton. As the son of an educator, a Star Trek: The Next Generation actor, and Reading Rainbow creator, Mr. Burton is perfectly positioned to speak on the intersection of technology and education. He was funny, engaging, and accommodating. Plus he made everyone cry when talking about the important teachers in his life, and asked us to take a moment to reflect on ours. And kudos to the Reading Rainbow social media team, who were impressively following along with his talk and engaging via Twitter with the audience in real time.

This conference is mostly focused on implementers. It’s a conference of editors, designers, developers, admissions, and IT staff. This is a passionate group of people who want to do better by their schools via the school’s online presence, and I’m continually impressed by how creative the teams get within their limited resources (people, time and money). The smaller schools have the ability to be more nimble around internal politics and the lack of resources than larger institutions, but even the larger schools are making amazing things happen online.

Though this isn’t something that Palantir works in directly, schools and libraries are really getting savvy about social media. There were sessions on how schools were using Pinterest, the success around ways to text students (including admissions acceptances!), Snapchat (again . . . including admissions acceptances!), and more.

Schools are really looking about how to personalize and individualize the experience for students from a visual perspective, understanding that the younger generations are used to a personalized experience via Netflix, Spotify, and Amazon where recommendations can be made based on interests. Schools are responding to this by designing more around creating a “choose your own adventure” feel either through filtering majors and interests, or through messaging and branding in addition to social media.

I also learned a lot about the concerns that schools have in the areas of accessibility, crisis control, and rebuilding trust among faculty and administrators when past web projects either haven’t gone well, or due to internal power struggles over which content gets priority.

Between representing all the factions of a large organization, juggling the needs of multiple audiences, and having to keep up with the constantly changing workspace online, these small teams of web professionals have a lot to handle! And this annual meeting allows them to collaborate, learn from each other, compare notes, and celebrate their hard work.

Some Favorite Sessions

In addition to the Red Stapler winners, there were a lot of great sessions. Videos will be up on the schedule page eventually, but below are links to slides to some noteworthy ones:

My colleague Joe Allen-Black and I were able to give our presentation “Project Management: The Musical!” to this crowd as the last session on Monday. We added one more song since the last conference, and thankfully it all went smoothly without a full rehearsal! Considering the amounts of tweets there were related to the session and feedback we received in person, the attendees seemed to enjoy our musical take on how to get a project moving successfully from start to finish.

I learn so much from this conference every year about what the higher education community’s needs are for their online presence, what they are doing to solve those problems, and how we at Palantir can assist. HEW hosts regional conferences all over the country throughout the year, leading up to the big annual conference next October in Hartford, CT. I don’t yet know what my calendar holds for next year, but I look forward to being able to attend and see the great community of HEW often in 2017.

Stay connected with the latest news on web strategy, design, and development.

Sign up for our newsletter.

Responsive Images in Drupal 8 Using "srcset"

Posted by Chromatic on October 24, 2016 at 3:26pm

There are a handful of tutorials out there that explain how to use Drupal 8's responsive image and breakpoint modules. However, from what I could find, none of them address how to instruct Drupal to output simple tags that leverage srcset instead of using the element. Using srcset can be preferable in many circumstances and as such, knowing how to use it in Drupal 8 will be good for most developers to understand. Since I was so confused on how to make this work, I thought it would be worth sharing.

Why srcset over ?

Others have done a much better job explaining the "why" of this approach, namely Chris Coyier and Jason Grigsby. Read those posts for the full picture (heh) but suffice to say, if you're only needing to change the resolution of an image at different viewport sizes/densities, you should use srcset instead of the element. If you need images that vary more specifically (i.e. different croppings, styles, etc.) then you should use the element. The reason srcset is preferred, is that it allows the browser to make informed decisions about which version of the image to serve, whereas the element explicitly tells the browser which images to use and when via media queries. Browsers know way more about our end users than we (developers) can ever know, so why not let them make the hard decisions?

In short:

  • Use srcset for different image sizes/densities across breakpoints.
  • Use when you need separate art direction/crops across breakpoints.
Convincing Drupal to Use srcset

Drupal's UI for responsive images is confusing and (maybe) rightfully so. Responsive images are confusing. As a rule, Drupal tries really hard to not make assumptions about what the user needs. While I understand why we (the Drupal community) built core this way, this can lead to interfaces that even seasoned professionals have a hard time understanding. In this case, it wasn't clear to me how (or if) I could instruct Drupal that I just wanted an element with srcset and sizes, not a full element. Each method I tried produced a element.

Responsive Image Interface

After some digging, I found the core issue where this development and discussion occurred. After skimming that thread and poking around the accepted patch, I knew that what I wanted was possible, but I still couldn't grok how to configure things in Drupal to get the desired output.

Further digging revealed that the default template responsible is called: responsive-image.html.twig. Here is the full file that ships with the Stable base theme:

 * @file
 * Theme override of a responsive image.
 * Available variables:
 * - sources: The attributes of the  tags for this  tag.
 * - img_element: The controlling image, with the fallback image in srcset.
 * - output_image_tag: Whether or not to output an  tag instead of a
 *    tag.
 * @see template_preprocess()
 * @see template_preprocess_responsive_image()
{% if output_image_tag %}
  {{ img_element }}
{% else %}
    {% if sources %}
      Internet Explorer 9 doesn't recognise source elements that are wrapped in
      picture tags. See
      {% for source_attributes in sources %}
      {% endfor %}
    {% endif %}
    {# The controlling image, with the fallback image in srcset. #}
    {{ img_element }}
{% endif %}

The key in this template is the output_image_tag boolean. When true, the template renders an tag instead of the tag. Inline documentation within the responsive_image module's template_preprocess_responsive_image() function explains that this output_image_tag variable is true when:

There is only one source tag with an empty media attribute. This means we can output an image tag with the srcset attribute instead of a picture tag.

In this context, Drupal is basically saying: if the user hasn't setup multiple breakpoints for this style AND there isn't any specific media query attached. Or in other words, the user doesn't want the theme to determine the images served but wants to put that onus on the browser via srcset.


If your use-case is to of the "resolution-switching" variety, here is how you get the desired output (no picture element) within Drupal:

  1. Skip creating specific breakpoints in your theme, they aren't needed with this approach.
  2. Setup your different image styles at admin/config/media/image-styles. Usually something like, Author Small, Author Medium and Author Large.
  3. Create a responsive image style at admin/config/media/responsive-image-style. Make sure the Responsive Image module is enabled first. Screenshot of responsive image style creation interface
  4. Ensure "Responsive Image" is selected for the "Breakpoint group".
  5. Choose a suitable "Fallback image style". Click "Save". The following screen is where the secret sauce is.
  6. Under the "1x Viewport Sizing []" fieldset, Select "Select multiple image styles and use the sizes attribute."
  7. Select each of Image styles you'd like to use.
  8. Adjust the Sizes value as needed. The default here 100vw is hard-coded for a good reason, it's a pretty sane default and works well in most situations. Customize this is you want even finer control. More on Sizes. Screenshot of an example Resposive Image Style
  9. Adjust your content type (or other entity) to use your new responsive image style either by altering the display formatter or handling programmatically. Adjust Entity Screenshot
  10. Verify results!

For a thorough explanation of how all of the bits of the Responsive Image module work, see the documentation at admin/help/responsive_image with the _Help module enabled._

You should see something like this for the output of that image field now (formatted for readability):

Ogden, Utah Panorama

We now have an element with a srcset attribute containing paths to each of our image styles, a sizes attribute and a fallback src attribute which points to our fallback image style.

Now our browser will automatically determine which image to serve up based on the client's viewport size, pixel density, etc. Also, if the client's browser doesn't yet support srcset, it will simply fall back to the value set in the src attribute.

Screencast demonstration of responsive images loading as the viewport changes.

Armed with this knowledge, you can configure your Drupal sites to leverage the power of srcset and allow the browsers of the world to do the hard work of determining which image style to serve to your users.

Drupal Board Staff Mixer

Posted by Unimity Solutions Drupal Blog on October 24, 2016 at 11:28am

During our Board Retreat, the Staff Board mixer gave us a chance to meet the staff members and the staff members to meet the Board. The staff's commitment and involvement to the project is amazing and definitely needs a pat on the back!

Upload PDF, Excel, Word Files to Drupal Content

Posted by OSTraining on October 24, 2016 at 10:17am
Upload PDF, Excel, Word Files to Drupal Content

An OSTraining member asked how he could attach files such as PDFs, Excel Documents, Word Documents to his content. 

There are many ways to do this in Drupal, but the easiest approach is to use the "File" field.

  • Login to your Drupal site.
  • Go to Structure > Content types.
  • You either add the field to an existing content type, or you can create a new one for specifically adding the files:

Drupal SearchAPI and result grouping

Posted by Liip on October 24, 2016 at 7:17am

In this blog post I will present how, in a recent e-Commerce project built on top of Drupal7 (the former version of the Drupal CMS), we make Drupal7, SearchAPI and Commerce play together to efficiently retrieve grouped results from Solr in SearchAPI, with no indexed data duplication.

We used the SearchAPI and the FacetAPI modules to build a search index for products, so far so good: available products and product-variations can be searched and filtered also by using a set of pre-defined facets. In a subsequent request, a new need arose from our project owner: provide a list of products where the results should include, in addition to the product details, a picture of one of the available product variations, while keep the ability to apply facets on products for the listing. Furthermore, the product variation picture displayed in the list must also match the filter applied by the user: this with the aim of not confusing users, and to provide a better user experience.

An example use case here is simple: allow users to get the list of available products and be able to filter them by the color/size/etc field of the available product variations, while displaying a picture of the available variations, and not a sample picture.

For the sake of simplicity and consistency with Drupal’s Commerce module terminology, I will use the term “Product” to refer to any product-variation, while the term “Model” will be used to refer to a product.

Solr Result Grouping

We decided to use Solr (the well-known, fast and efficient search engine built on top of the Apache Lucene library) as the backend of the eCommerce platform: the reason lies not only in its full-text search features, but also in the possibility to build a fast retrieval system for the huge number of products we were expecting to be available online.

To solve the request about the display of product models, facets and available products, I intended to use the feature offered by Solr called Result-Grouping as it seemed to be suitable for our case: Solr is able to return just a subset of results by grouping them given an “single value” field (previously indexed, of course). The Facets can then be configured to be computed from: the grouped set of results, the ungrouped items or just from the first result of each group.

Such handy feature of Solr can be used in combination with the SearchAPI module by installing the SearchAPI Grouping module. The module allows to return results grouped by a single-valued field, while keeping the building process of the facets on all the results matched by the query, this behavior is configurable.

That allowed us to:

  • group the available products by the referenced model and return just one model;
  • compute the attribute’s facets on the entire collection of available products;
  • reuse the data in the product index for multiple views based on different grouping settings.
Result Grouping in SearchAPI

Due to some limitations of the SearchAPI module and its query building components, such plan was not doable with the current configuration as it would require us to create a copy of the product index just to apply the specific Result Grouping feature for each view.

The reason is that the features implemented by the SearchAPI Grouping are implemented on top of the “Alterations and Processors” functions of SearchAPI. Those are a set of specific functions that can be configured and invoked both at indexing-time and at querying-time by the SearchAPI module. In particular Alterations allows to programmatically alter the contents sent to the underlying index, while the Processors code is executed when a search query is built, executed and the results returned.
Those functions can be defined and configured only per-index.

As visible in the following picture, the SearchAPI Grouping module configuration could be done solely in the Index configuration, but not per-query.

 processor settings

Image 1: SearchAPI configuration for the Grouping Processor.

As the SearchAPI Grouping module is implemented as a SearchAPI Processor (as it needs to be able to alter the query sent to Solr and to handle the returned results), it would force us to create a new index for each different configuration of the result grouping.

Such limitation requires to introduce a lot of (useless) data duplication in the index, with a consequent decrease of performance when products are saved and later indexed in multiple indexes.
In particular, the duplication is more evident as the changes performed by the Processor are merely an alteration of:

  1. the query sent to Solr;
  2. the handling of the raw data returned by Solr.

This shows that there would be no need to index multiple times the same data.

Since the the possibility to define per-query processor sounded really promising and such feature could be used extensively in the same project, a new module has been implemented and published on the SearchAPI Extended Processors module. (thanks to SearchAPI’s maintainer, DrunkenMonkey, for the help and review :) ).

The Drupal SearchAPI Extended Processor

The new module allows to extend the standard SearchAPI behavior for Processors and lets admins configure the execution of SearchAPI Processors per query and not only per-index.

By using the new module, any index can now be used with multiple and different Processors configurations, no new indexes are needed, thus avoiding data duplication.

The new configuration is exposed, as visible in the following picture, while editing a SearchAPI view under “Advanced > Query options”.
The SearchAPI processors can be altered and re-defined for the given view, a checkbox allows to completely override the current index setting rather than providing additional processors.

 view's extended processor settings

Image 2: View’s “Query options” with the SearchAPI Extended Processors module.


Conclusion: the new SearchAPI Extended Processors module has now been used for a few months in a complex eCommerce project at Liip and allowed us to easily implement new search features without the need to create multiple and separated indexes.
We are able to index Products data in one single (and compact) Solr index, and use it with different grouping strategies to build both product listings, model listings and model-category navigation pages without duplicating any data.
Since all those listings leverages the Solr FilterQuery query parameter to filter the correct set of products to be displayed, Solr can make use of its internal set of caches and specifically the filterCache to speed up subsequent searches and facets. This aspect, in addition to the usage of only one index, allows caches to be shared among multiple listings, and that would not be possible if separate indexes were used.

For further information, questions or curiosity drop me a line, I will be happy to help you configuring Drupal SearchAPI and Solr for your needs.

7 Of The Biggest Challenges When Drupal Grows At Your Higher-Education Institution

Posted by Dewy on October 24, 2016 at 6:00am
Your web team has empowered your higher-ed insitution's digital presence with Drupal, and everything is awesome. But over time issues will arise that could pose significant risks to your institution. These are the biggest challenges and how they can be managed.

Should I build a career on Drupal?

Posted by TheodorosPloumis blog on October 22, 2016 at 9:14pm

An IT university student asked me one week before in a developer meetup here in Thessaloniki - Greece:

"Senior developers say to never count on a CMS to build a career. I have heard that Drupal 8.x is more mature than ever but how risky it is to spend my time on a hard to learn CMS in order to make a living? What is your advise as a Drupal developer?"

First of all I would like to say that it is a very hard question. If you are already using Drupal the answer may be obvious but here we are talking about a young person studying IT, who doesn’t have any real experience on any CMS, and would be afraid to rely on a specific CMS. This is expected and totally fine.

Secondly, in order to be more objective I should compare Drupal with the other similar software out there like WordPress, Joomla, SiteCore, SquareSpace, Adobe AEM etc. Or, to be honest I should compare Drupal with other the alternative frameworks like Laravel, Django, Ruby on Rails etc. Since I do not have a personal experience of all the above "competitors" I will talk only about Drupal. So it's up to you, the young IT Student to investigate if similar software out there can offer what Drupal offers and how much does it cost to focus or not to Drupal.

Thirdly I would say that I make a living from Drupal for the last 8 years now as a freelancer. I work from home and I work 100% on Drupal projects.

So, here is why Drupal is a very good path to follow in order to build a long time career.


Open Source:

This may be a "hidden" advantage of Drupal but notice this: with Drupal you and your customers will never stand behind a company, a commercial license or a company strategic. Behind Drupal there are thousand of people and this is your stable ground to step. Behind any commercial software there is a company. Drupal is open source and will stay as that for ever. Remember that.


Ready for tomorrow:

Drupal is not a "static" code CMS, outdated and heavy. Drupal is always "regenerated" and stays on the edge of the technology. Current version of 8.x is built with Backbone.js, RESTful services, In Place Editor, Symfony2, Twig, CKeditor and many other things that are game-changers. It's UX is always improved. You may have difficulties to get started and the learning curve will not be easy. But it worths the effort. Drupal is a CMS that never stagnates.


Career Evolution:

Using and building experiences with Drupal is challenging. On every release you are almost forced to learn new things. That's because Drupal tries to get better and better over time even after 15 years of existence. For Drupal 8.x for example you may need to learn to use Composer, Object Oriented patterns, RESTful APIs, Symfony services and many other interesting things which were not in Drupal 7.x. Nowadays Drupal is adding new stuff in its core even on minor releases of 8.x. I can really promise, "you will never get borrowed with DrupalTM".


Companies are investing:

Huge, medium and small companies investing to Drupal. IT companies and advertisement agencies are moving to Drupal as their preferable tool to create websites or other apps. Big corporations, organizations, governments, institutes etc are using Drupal or planning to use Drupal to build their web presence. In terms of the open source CMS Drupal is by far a leader when there are security, flexibility and long term maintenance requirements. Especially for Drupal 8.x we are going to see even more "big" players to investigate on Drupal and migrate from other CMS - even paid -. Drupal creates new market opportunities and that's why demand for Drupal talent is great​.


Drupal Community:

Drupal is very proud of its' incredibly unique community. The motto of Drupal is "Come for the Code, Stay for the Community". It is the key for success of the software. The website, the unified and fully open online place where Drupal lives, is full of helpful information, extensions, themes, documentation and thousands of humans ready to help you find your way. People are giving back to Drupal and this is a win win situation. I could say so many about Drupal community and how it works but you should better see on your self.


Drupal Association:

Behind (or in front of) Drupal there is the Drupal Association, a passionate group of people elected from the community and working for the community. The Drupal Association is dedicated to fostering and supporting the Drupal software project, the community and its growth (funding, infrastructure, education, promotion, distribution, online collaboration etc). So behind the community there is the same community trying to help the community! Probably the larger online community of an open source software.



I could not avoid refer to the founder of Drupal. Dries is one of us, a humble community member, an open mind businessman, a lead developer, a Drupal evangelist, a restless leader. His thoughts are really inspiring and you feel safe when you listen him talking about the mission and strategic of Drupal.


After all these I hope you get the idea.

Good luck with your professional (Drupal) career ;-)


Further reading.

Conductor, a Composer UI

Posted by Matt Glaman on October 22, 2016 at 1:30pm

Developers have many tools. We have version control systems, we have dependency management tools, we have build and task automation tools. What is one thing they all have in common? They are command line tools.

However, the command line can be daunting to some and create a barrier to adoption. We’re currently experiencing this in the Drupal community. People are considering Composer a barrier to entry, and I believe it’s just because it’s a command line tool and something new.

Providing a user interface

User interfaces can make tools more usable. Or at least lower the barrier to entry. I like to think of Atlassian's SourceTree. SourceTree is an amazing Git user interface and was my entry into learning how to use Git.

If you work with Java, your IDE provides some sort of user interface for managing your dependencies via Maven.

The PhpStorm IDE provides rudimentary Composer support - initializing a project and adding dependencies - but doesn’t support entire workflows. It’s also proprietary.

Here’s where I introduce Conductor: a standalone Composer user interface built on Electron. The purpose of Conductor is to give users working with PHP projects an interface for managing their projects outside of the command line.

Hello, Conductor

Conductor interfaces

Conductor provides an interface for:

  • Creating a new project based on a Composer project
  • Managing projects to install, update, add, and remove dependencies
  • View dependencies inside of a project
  • Ability to update or remove individual dependencies by reviewing them inside of the project.
  • Run Composer commands from the user interface and review console output.

The project is in initial development, granted by the downtime the Dyn DDoS attack created.

The initial application is now in an above minimal viable product. It works. It can be used. But now it needs feedback from users who feel a barrier by having to use Composer, and code improvements as well.

Head over to GitHub and check out the project: Currently, there are no prebuilt binaries and you'll need to manually build to try it out.'s Guide to Digital Governance: Roles and Permissions

Posted by Palantir on October 21, 2016 at 7:17pm's Guide to Digital Governance: Roles and Permissions's Guide to Digital Governance brandt Fri, 10/21/2016 - 14:17 Scott DiPerna Oct 24, 2016Illustrated collage of website icons

This is the fifth installment of’s Guide to Digital Governance, a comprehensive guide intended to help get you started when developing a governance plan for your institution’s digital communications.

In this post we will cover...
  • Why defining roles and permissions is important
  • Some common roles and associated permissions
  • Questions you should consider when defining permissions for your organization

We want to make your project a success.

Let's Chat.

We live in an era where few institutions have Websites and other Internet-based properties that are managed and maintained by one or only a few people. Where these spaces were once controlled by the few who knew how to code in HTML, content management systems have now dramatically lowered (and arguably eliminated) the need to possess extensive HTML knowledge. This means that most organizations have lots of people editing their Web properties, and without some well-defined rules for all those cooks in the kitchen, things get messy quickly.

Whether or not the platform you are using has roles and permissions built into it, a good governance plan will define roles for users and then apply specific permissions to those roles. Based on my experience, here are some common, fairly generic, roles and permissions that many Websites have (or have variations):

  • ROLE: Authenticated User
    • PERMISSIONS: Anyone who has activated an account on the Website, but has no editing or publishing permissions; authenticated users may be able to see content an un-authenticated user may not see.
  • ROLE: Contributor
    • PERMISSIONS: A user with an account who can create new and edit their existing content on the Website, but may not publish or delete any content, including their own, or edit content they have not created.
  • ROLE: Editor
    • PERMISSIONS: A user with an account who can create new and edit existing content on the Website, including content that is not their own; they may or may not publish or delete content.
  • ROLE: Publisher
    • PERMISSIONS: A user with an account who can create new, edit existing, publish, and delete any content on the Website; typically a person who approves and publishes the work of Contributors and Editors.
  • ROLE: Administrator
    • PERMISSIONS: A user with the same permissions as a Publisher, however they may administer accounts, roles, and permissions of other users on the Website, along with managing certain site-wide settings.
  • ROLE: Webmaster
    • PERMISSIONS: A user with full permissions to all aspects of managing and administering the Website, a role typically reserved to the few, most highly trained and experienced users.

These common roles can be modified easily to address the specific needs of your organization. You may also find that they are lacking certain roles you need, in which case I recommend using one of these for the basis of a new role you create to meet your specific requirements. For example, let’s say you have a microsite that is a subset of your main site, and you need to assign a user the role of Administrator ONLY for that micro-site and not the entire main site. Simply take the permissions assigned to Administrators and create a new role call Micro-Site Admin whose permissions as “Administrator” are limited to only the micro-site that role manages.

Here are some questions to consider to help you begin defining the roles your organization will need, along with the permissions each role should have.


  • Who should have an account for accessing your Website?
  • How do users acquire or activate accounts?
  • What are the policies for using accounts?
  • Is sharing an account permissible?
  • What are the conditions under which users may lose their access privileges?

Roles & Permissions

  • Who is permitted to edit content on the Website?
  • Who is permitted to create new content on the Website?
  • Who is permitted to publish content on the Website?
  • Who is permitted to delete content on the Website?
  • Who is permitted to see unpublished content on the Website?
  • Are there users who should have higher levels of administrative access to perform site-wide changes or to administer user accounts?
  • Are there sets of users who need special access to only limited parts or functions within the Website?
  • Are there limitations to the level of access different users should have?
  • Do all users have access to all content?
  • Do some users have access to only the content they create?
  • Do certain users need to approve content before it is published?
  • Does a workflow need to be established for defining how content is produced and published?


This post is part of a larger series of posts, which make up a Guide to Digital Governance Planning. The sections follow a specific order intended to help you start at a high-level of thinking and then focus on greater and greater levels of detail. The sections of the guide are as follows:

  1. Starting at the 10,000ft View – Define the digital ecosystem your governance planning will encompass.
  2. Properties and Platforms – Define all the sites, applications and tools that live in your digital ecosystem.
  3. Ownership – Consider who ultimately owns and is responsible for each site, application and tool.
  4. Intended Use – Establish the fundamental purpose for the use of each site, application and tool.
  5. Roles and Permissions – Define who should be able to do what in each system.
  6. Content – Understand how ownership and permissions should apply to content.
  7. Organization – Establish how the content in your digital properties should be organized and structured.
  8. URLs – Define how URL patterns should be structured in your websites.
  9. Design – Determine who owns and is responsible for the many aspects design plays in digital communications and properties.
  10. Personal Websites – Consider the relationship your organization should have with personal websites of members of your organization.
  11. Private Websites, Intranets and Portals – Determine the policies that should govern site which are not available to the public.
  12. Web-Based Applications – Consider use and ownership of web-based tools and applications.
  13. E-Commerce – Determine the role of e-commerce in your website.
  14. Broadcast Email – Establish guidelines for the use of broadcast email to constituents and customers.
  15. Social Media – Set standards for the establishment and use of social media tools within the organization.
  16. Digital Communications Governance – Keep the guidelines you create updated and relevant.

Stay connected with the latest news on web strategy, design, and development.

Sign up for our newsletter.

Add date pop-up calendar in custom drupal 7 form

Posted by Phponwebsites on October 21, 2016 at 6:48pm
     This blog describes how to add date pop-up calender to a custom form in the Drupal 7.

Use date pop-up calendar in custom form - drupal 7

     The use case is if you want to use date pop-up calendar in a custom form, then how you can do it in the drupal 7. Actually, the drupal 7 form API provides lots of form types like textfield, checkbox, checkboxes etc to create a custom form. Similarly, the date module  also provides the form type called date_popup. We can use it in the custom form in order to display the date pop-up in the custom form.

Use date pop-up calendar with the custom form in drupal 7:

   Let consider the below code snippet:

function phponwebsites_menu() {
  $items = array();

  $items['customform'] = array(
    'title' => t('Custom Form'),
    'type' => MENU_CALLBACK,
    'page callback' => 'drupal_get_form',
    'page arguments' => array('phponwebsites_display_date_popup_form'),
    'access callback' => TRUE,

  return $items;

function phponwebsites_display_date_popup_form($form, &$form_state) {
  $form['date'] = array(
    '#type' => 'date_popup',
    '#default_value' => date('Y-m-d'),
    '#date_format'   => 'Y-m-d',
    '#date_year_range' => '0:+5',
    '#datepicker_options' => array('minDate' => 0, 'maxDate' => 0),

  return $form;
      '#date_format'   => 'Y-m-d' if you need to display only date
      '#date_format'   => 'Y-m-d H:i:s' if you need to display date & time
      '#date_year_range' => '0:+5' if you need to display only future 5 years
      '#datepicker_options' => array('minDate' => 0, 'maxDate' => 0) if you want to display only current date. We can hide the future & past dates using this option.

   Please add the above code into your module file and look into the "customform" page. It looks like the below image:

Display only current date in date -pop-up - drupal 7

   Now I've hope you know how to add date pop-up calendar with custom form in the drupal 7.

Related articles:
Remove speical characters from URL alias using pathauto module in Drupal 7
Add new menu item into already created menu in Drupal 7
Add class into menu item in Drupal 7
Create menu tab programmatically in Drupal 7
Add custom fields to search api index in Drupal 7
Clear views cache when insert, update and delete a node in Drupal 7
Create a page without header and footer in Drupal 7
Login using both email and username in Drupal 7
Disable future dates in date pop-up calendar Drupal 7

DrupalCon showcase: a very British migration

Posted by - Thoughts on October 21, 2016 at 3:44pm

The Ixis team were out in force, exhibiting as a gold sponsor (along with a small army of Druplicon stress-balls) As well as meeting lots of other Drupal developers and businesses deploying open source infrastructure, one of the highlights of the convention was our Technical Director, Mike Carter, being given the opportunity to co-present a Drupal Showcase session, detailing our work with the British Council.

Nasdaq Chooses Drupal 8

Posted by blog on October 21, 2016 at 12:47pm

Republished from

Nasdaq chooses Drupal 8

I wanted to share the exciting news that Nasdaq Corporate Solutions has selected Drupal 8 as the basis for its next generation Investor Relations Website Platform. About 3,000 of the largest companies in the world use Nasdaq's Corporate Solutions for their investor relations websites. This includes 78 of the Nasdaq 100 Index companies and 63% of the Fortune 500 companies.

What is an IR website? It's a website where public companies share their most sensitive and critical news and information with their shareholders, institutional investors, the media and analysts. This includes everything from financial results to regulatory filings, press releases, and other company news. Examples of IR websites include http://investor.starbucks.com and -- all three companies are listed on Nasdaq.

All IR websites are subject to strict compliance standards, and security and reliability are very important. Nasdaq's use of Drupal 8 is a fantastic testament for Drupal and Open Source. It will raise awareness about Drupal across financial institutions worldwide.

In their announcement, Nasdaq explained that all the publicly listed companies on Nasdaq are eligible to upgrade their sites to the next-gen model "beginning in 2017 using a variety of redesign options, all of which leverage Acquia and the Drupal 8 open source enterprise web content management (WCM) system."

It's exciting that 3,000 of the largest companies in the world, like Starbucks, Apple, Amazon, Google and ExxonMobil, are now eligible to start using Drupal 8 for some of their most critical websites. 

Fun with Drupal 8 configuration management

Posted by Capgemini Engineering on October 20, 2016 at 11:00pm

It has been a few years since I have had the opportunity to build a website from the absolute beginning. The most recent project I’m on continues in that vein, but it’s early enough for me to consider ripping it apart and starting all over again. The project is particularly interesting to me, as it’s my first opportunity to use Drupal 8 in earnest. As I’ve got an interest in automating as much as possible, I want to gain a better understanding of the configuration management features which have been introduced in Drupal 8.

Tearing it apart and starting again wasn’t the first thing considered. Being an arrogant Drupal dev, I figured I could simply poke around the GUI and rely on some things I’d seen at Drupalcon and Drupal camps in the past couple of years to see me through. I thought I would find it easy to build a replicated environment so that any new developer could come along, do a git clone, vagrant up, review a file and/or wiki page and they’d be off and running.


This post outlines many of the things that I examined in the process of learning Drupal 8 while adopting a bit of humility. I’ve created a sample project with names changed to protect the innocent. Any comments are welcome.

The structure of the rest of this post is as follows:

Setting up and orientation with Drupal VM

I am a big fan of Jeff Geerling’s Drupal VM vagrant project, so I created a fork of it, and imaginatively called it D8config VM. We will be building a Drupal site with the standard profile which we’ll use to rapidly build a basic prototype using the Drupal GUI - no coding chops necessary. The only contributed module added and enabled is the Devel module at the start, but we will change that quickly.

Here are the prerequisites if you do follow along:

  • familiarity with the command line;
  • familiarity with Vagrant and that it’s installed on your machine (note: the tutorial requires Vagrant 1.8.1+);
  • as well as Vagrant 1.8.1+, you need to have Ansible 2.0.1+ and VirtualBox 5.0.20+ installed;
  • have installed the Vagrant Auto-network plugin with vagrant plugin install vagrant-auto_network. This will help prevent collisions with other virtual networks that may exist on your computer;
  • have installed the Vagrant::Hostsupdater plugin with vagrant plugin install vagrant-hostsupdater, which will manage the host’s /etc/hosts file by adding and removing hostname entries for you;
  • familiarity with git and GitHub;
  • if using Windows, you are comfortable with troubleshooting any issues you might come across, as it’s only been tested on a Mac;
  • familiarity with Drush.

Here is how the D8config VM differs from Drupal VM:

  • the config.yml and drupal.make.yml files have been committed, unlike the normal Drupal VM repo;
  • the hostname and machine name have been changed to and d8config respectively;
  • to take advantage of the auto-network plugin, vagrant_ip is set to The d8config machine will then have an IP address from to;
  • the first synced folder is configured with a relative reference to the Vagrant file itself:
# The first synced folder will be used for the default Drupal installation, if
# build_makefile: is 'true'.
- local_path: ../d8config-site         # Changed from ~/Sites/drupalvm
  destination: /var/www/d8config-site  # Changed from /var/www/drupalvm
  type: nfs
  create: true

I’ll do the same with subsequent shared folders as we progress - it’s a useful way to keep the different repos together in one directory. At the end of the tutorial, you’ll have something like:

└── projects
    ├── another_project
    ├── d8config
    │   ├── d8config_profile
    │   ├── d8config-site
    │   └── d8config-vm
    ├── my_project
    └── top_secret_project


New nice-to-haves (thanks to recent changes in Drupal VM)

If you have used Drupal VM before but haven’t upgraded in a while, there are a load of new features. Here are just two to note:

  • Ansible roles are now installed locally (in ./provisioning/roles) during the first vagrant up;
  • PHP 7 is now an option to be installed. In fact, it’s installed by default. You can select 5.6 if you like by changing php_version in the config.yml file (see PHP 5.6 on Drupal VM).

Now do this

Create a directory where you’re going to keep all of the project assets.

$ mkdir d8config

# Change to that directory in your terminal:
$ cd d8config

Clone the D8config VM repo. Or, feel free to fork D8config VM and clone your version of the repo.

$ git clone

# Change to the `d8config-vm` directory:
$ cd d8config-vm

# Checkout the `CG01` branch of the repo:
$ git checkout CG01

# Bring the vagrant machine up and wait for the provisioning to complete.
$ vagrant up

After successful provisioning you should be able to point your browser at and see your barebones Drupal 8 site. Username: admin; Password: admin.


If you’ve used Drupal VM before, you will want to examine the changes in the latest version. From Drupal VM tag 3.0.0 onwards, the requirements have changed:

  • Vagrant 1.8.1+
  • Ansible 2.0.1+
  • VirtualBox 5.0.20+

One sure sign that you’ll need to upgrade is if you see this message when doing a vagrant up:

ansible provisioner: * The following settings shouldn't exist: galaxy_role_file


Build your prototype

In this section of the tutorial we’re going to start building our prototype. The brief is:

The site is a portfolio site for for a large multinational corporation’s internal use. But hopefully the content architecture is simple enough to keep in your head. The following node types need to be set up: Case study, Client, Team member (the subject matter expert), and Technologies used. Set up a vocabulary called Country for countries served and a second to called Sector classify the information which will contain tags such as Government, Music industry, Manufacturing, Professional services, etc. Delete the existing default content types. You can then delete fields you know you won’t need to avoid confusion - Comments for example - which will then allow you to uninstall the comment module. And, as you might deduce by the modules I’ve selected, it’s to be a multilingual site.

Hopefully this should feel comfortable enough for you, if you are familiar with Drupal site building. There are enough specifics for clarity, yet it’s not too prescriptive that you feel someone is telling you how to do your job. Whereas in one context, you may hear a manager say “don’t bring me problems, bring me solutions”, most engineers would rather say for themselves “don’t bring me solutions, bring me problems”. I hope this brief does the latter.

Have a go at making the changes to your vanilla Drupal 8 site based on the brief.

Beyond the brief

Every ‘site building’ exercise with Drupal is a move further away from the configuration provided by the standard or minimal profiles. In our circumstance, we will enable these modules via the GUI:

  • Responsive Image
  • Syslog
  • Testing
  • BigPipe
  • Devel Generate (Devel was installed due to settings in config.yml in the d8config-vm repo)
  • Devel Kint
  • Devel Node Access
  • Web Profiler
  • Configuration Translation
  • Content Translation
  • Interface Translation
  • Language

I’ve also added a couple of contributed themes via Drush so the site will no longer look like the default site.

# While in your d8config-vm directory:
$ vagrant ssh

# Switch to your Drupal installation:
$ cd /var/www/d8config-site/drupal

# Download and install two themes:
$ drush en integrity adminimal_theme -y

For more details on these themes, see the Integrity theme and the Adminimal theme. As you might expect, I set Integrity as the default theme, and Adminimal as the admin theme via the GUI.

After switching themes, two blocks appeared in the wrong regions. I went to the Block layout page and moved the Footer menu block from the main menu region to the footer first region and the Powered by Drupal block from the Main menu to the Sub footer block.

Due to the multilingual implication, I went to the Languages admin page and added French.


Replicate and automate

At this stage you’ve made quite a lot of changes to a vanilla Drupal site. There are many reasons you should consider automating the building of this site - to save time when bringing other members into the development process, for creating QA, UAT, pre-prod and production environments, etc. We will now start to examine ways of doing just this.

drush make your life easier

In this section we’re going to create a Drush makefile to get the versions of Drupal core, contrib modules and themes we need to build this site as it currently is. This file will be the first file added to the D8config profile repo. Makefiles are not a required part of a profile, and could reside in a repo of their own. However to keep administration down to a minimum, I’ve found that this is a useful way to simplify some of the asset management for site building.

Let’s first tweak the config.yml in the D8config VM repo, so that we have synced folder for the profile. To do so, either:

  1. git checkout CG02 in the d8config-vm directory (where I’ve already made the changes for you), or;
  2. Add the following to the config.yml in the vagrant_synced_folders section:
# This is so the profile repo can be manipulated on the guest or host.
- local_path: ../d8config_profile
  destination: /build/d8config/d8config_profile
  type: nfs
  create: true

After doing either of the above, do a vagrant reload which will both create the directory on the Vagrant host, and mount it from the d8config-vm guest.

Next, let’s generate a basic makefile from the site as it now is.

# From within the d8config vm:
$ cd /var/www/d8config-site/drupal
$ drush generate-makefile /build/d8config/d8config_profile/d8config.make

This makefile is now available in the d8config_profile directory which is at the same level as your d8config-vm directory when viewing on your host machine.

Because we only have Drupal core, two contrib themes and the Devel module, it’s a very simple file and it doesn’t need any tweaking at this stage. I’ve committed it to the D8config profile repo and tagged it as CG01.

Raising our profile

Since we’ve established that the makefile is doing very little on this site, we need to look at completing the rest of the profile which will apply the configuration changes when building the site. The How to Write a Drupal 8 Installation Profile is quite clear and we’ll use that page to guide us.

First, our machine name has already been chosen, as I’ve called the repo d8config_profile.

Rather than writing the file from scratch, let’s duplicate from the standard profile in Drupal core, as that’s what we used to build the vanilla site to begin with. We can then modify it to reflect what we’ve done since.

# From within the /build/d8config/d8config_profile directory in the vagrant machine:
$ cp /var/www/d8config-site/drupal/core/profiles/standard/ .

$ mv

The first five lines of the need to look like this:

name: D8config
type: profile
description: 'For a Capgemini Engineering Blog tutorial.'
core: 8.x

At the end of the file it looks like this, which shows the required core modules and adding the modules and themes we’ve downloaded:

- automated_cron
- responsive_image
- syslog
- simpletest
- big_pipe
- migrate
- migrate_drupal
- migrate_drupal_ui
- devel
- devel_generate
- kint
- devel_node_access
- webprofiler
- config_translation
- content_translation
- locale
- language
- bartik
- seven
- integrity
- adminimal_theme

Also, don’t forget, we uninstalled the comment module, so I’ve also removed that from the dependencies.

You still need moar!

The profile specifies the modules to be enabled, but not how they’re to be configured. Also, what about the new content types we’ve added? And the taxonomies? With previous versions, we relied on the features module, and perhaps strongarm to manage these tasks. But now, we’re finally getting to the subject of the tutorial - Drupal 8 has a configuration system out of the box.

This is available via the GUI, as well as Drush. Either method allows you to export and import the configuration settings for the whole of your site. And if you look further down the profile how-to page, you will see that we can include configuration with installation profiles.

Let’s export our configuration using Drush. This is will be far more efficient than exporting via the GUI, which downloads a *.tar.gz file, which we’d need to extract a copy or move to the config/install directory of the profile.

While logged into the vagrant machine and inside the site’s root directory:

# Create the config/install directory first:
$ mkdir -p /build/d8config/d8config_profile/config/install

# Export!
$ drush config-export --destination="/build/d8config/d8config_profile/config/install"

When I exported my configuration, there were ~215 files created. Try ls -1 | wc -l in the config/install directory to check for yourself.


The reason we’re gathered here today (a brief intermission)…

I hope you are finding this tutorial useful - and also sensible. When I started writing this blog post, I hadn’t realised it would cover quite so much ground. The key thing I thought I would be covering was Drupal 8’s configuration management. It was something I was very excited about, and I still am. To demonstrate some of the fun I’ve had with it is still the central point of this blog. All of the previous steps to get to this point were fun too, don’t get me wrong. From my point of view, there were no surprises.

Spoiler alert

Configuration management, on the other hand - this is true drama. Taking an existing shared development site and recreating it locally using Drush make and a basic profile (without the included config/install directory) is just a trivial soap opera. If you want real fun, visit the configuration-syncing aspect, armed only with knowledge of prior versions of Drupal and don’t RTFM.


No, really. Do it.

The secret sauce in this recipe is…

After doing the export of the configuration in the previous section, I finally started running into the problems that I faced during my real world project - the project mentioned at the beginning of this post. Importing the configuration repeatedly and consistently failed with quite noisy and complex stack trace errors which were difficult to make sense of. Did I mention that perhaps I should have read the manual?

We need to do two things to make the configuration files usable in this tutorial before committing:

# Within the d8config_profile/config/install directory:
$ rm core.extension.yml update.settings.yml
$ find ./ -type f -exec sed -i '/^uuid: /d' {} \;

The removal of those two files was found to be required thanks to reading this and this. At this stage, I can confirm these were the only two files necessary for removal, and perhaps as Drupal 8’s configuration management becomes more sophisticated, this will not be necessary. The second command will recursively remove the lines with the uuid key/value pairs in all files.


Packaging it all up and running with it.

We’ve done all the preparation, and now need to make some small tweaks and commit them so our colleagues can start where we’ve left off. To do so we need to:

  1. add the profile to the makefile;
  2. commit our changes to the d8config_profile repo;
  3. tweak the config.yml file in the d8config-vm repo, to use our makefile and profile during provisioning.

To have the profile be installed by the makefile, add this to the bottom of d8config.make (in the D8config profile):

  type: profile
    type: git
    working-copy: true

I’ve committed the changes to the D8Config profile and tagged it as CG02.

Then the last change to make before testing our solution is to tweak the config.yml in the D8config VM repo. Three lines need changing:

# Change the drush_makefile_path:
drush_makefile_path: "/build/d8config/d8config_profile/d8config.make"

# Change the drupal_install_profile:
drupal_install_profile: d8config_profile

# Remove devel from the drupal_enable_modules array:
drupal_enable_modules: []

As you can see, the changes to the vagrant project are all about the profile.

With both the D8Config VM and the D8Config profile in adjacent folders, and confident that this is all going to work, from the host do:

# From the d8config-vm directory
$ vagrant destroy
# Type 'y' when prompted.

# Go!
$ vagrant up

Once the provisioning is complete, you should be able to check that the site is functioning at Once there, check the presence of the custom content types, taxonomy, expected themes, placement of blocks, etc.


Summary and conclusion

The steps we’ve taken in this tutorial have given us an opportunity to look at the latest version of Drupal VM, build a quick-and-dirty prototype in Drupal 8 and make a profile which our colleagues can use to collaborate with us. I’ve pointed out some gotchas and in particular some things you will want to consider regarding exporting and importing Drupal 8 configuration settings.

There are more questions raised as well. For example, why not simply keep the d8config.make file in the d8config-vm repo? And what about the other ways people use Drupal VM in their workflow - for example here and here? Why not use the minimal profile when starting a protoype, and save the step of deleting content types?

Questions or comments? Please let me know. And next time we’ll just use Docker, shall we?

Fun with Drupal 8 configuration management was originally published by Capgemini at Capgemini Engineering on October 21, 2016.

Migrating XML in Drupal 8

Posted by Palantir on October 20, 2016 at 10:14pm
Migrating XML in Drupal 8 brandt Thu, 10/20/2016 - 17:14 Kelsey Bentham Oct 21, 2016Icons of XML file, arrow, and Drupal 8 logo

Migrate in Drupal 8 is a flexible and powerful tool - you just need to know where to look. 

In this post we will cover...
  • Some findings from our first D8 projects

  • How to use the Migrate Plus XML data process plugin

  • A note on prefixed namespaces

Stay connected with the latest news on web strategy, design, and development.

Sign up for our newsletter.

Drupal 8 is here which means I have had the privilege of working on my first D8 projects and the migrations that accompany them. I wanted to share some of the key findings I’ve taken away from the experience.

Migrate in Drupal 8 is awesome as long as you know what you are looking at. It is flexible, powerful and relatively easy to read. But as is the case with most things, a lot of its power is tucked away where it is hard to find if you don't know where to look. This is definitely the case with Migrate Plus XML data process plugin which is presently available only in the dev version of Migrate Plus. It is a pretty solid tool for migrating from a variety of XML based sources and today we are going to talk about how to use it.

The first thing we have to consider is where our data is coming from. Migrate plus expects to have this information fed to it in the form of a url which gives us two options:

  1. our source is from outside the website, like an rss feed; or
  2. it is stored locally.

If you have an external url, all you need to do is plug it into the url’s parameter. If your source is stored locally, you will either need to construct a url for the source or store it in the private file directory, using the private:// stream wrapper. I would go for the latter as it involves less overhead. At this point your migration source should look something like this:

   plugin: url    
   data_fetcher_plugin: http    
   data_parser_plugin: xml   
   urls: private://migration.xml

This brings us to parsing out the XML. All of the selectors we will be talking about are using xpath. The first thing you need to do is define the item selector so migrate can identify the individual items to migrate into your choose destination. For example, if we were migrating posts from a WordPress export it might look something like this:

item_selector: /rss/channel/item[wp:post_type="post"]

Next up we need to map all of our fields to nice, readable machine names that we can use in the process part of the migration. Each field will have a name that will identify it in other parts of the migration, a label for describing what sort of data we will find in that XML element, and a selector so the migration can map that data from the xml file:

    name: title
    label: Content title
    selector: title
    name: post_id
    label: Unique content ID
    selector: wp:post_id
    name: content
    label: Body of the content
    selector: content:encoded
    name: post_tag
    label: Tags assigned to the content item
    selector: 'category[@domain="post_tag"]/@nicename'

If you are using anything more complicated than the XML node names, you will need to wrap the selector as a string. The selectors are being passed to xpath in the data processor, so you can get pretty precise in selecting XML nodes.

All that is left to do is define the migration id and you have your source all ready to go:

     type: integer

Put it all together and you should have something that looks something like this:

   plugin: url    
   data_fetcher_plugin: http    
   data_parser_plugin: xml   
   urls: private://migration.xml
   item_selector: /rss/channel/item[wp:post_type="post"]
       name: title
       label: Content title
       selector: title
       name: post_id
       label: Unique content ID
       selector: wp:post_id
       name: content
       label: Body of the content
       selector: content:encoded
       name: post_tag
       label: Tags assigned to the content item
       selector: 'category[@domain="post_tag"]/@nicename'
           type: integer

A note on prefixed namespaces: you can see we mixed XML nodes that have prefixes with those that don’t. Sometimes Migrate handles this with no problem at all; sometimes it refuses to fetch data from XML nodes that don’t have prefixes. As far as I can tell, it does this when one of the nodes in the item_selector has a prefix (although it doesn’t seem to have this problem with the filters in the item_selector). If you should have a datasource with a parent prefixed node, you can still get non-prefixed children by using the following syntax:

name: description
label: Content description
selector: '*[local-name()="description"]'

It will allow you to select XML nodes with a given local name regardless of the prefix, which is very handy when you have no prefix at all.

Stay connected with the latest news on web strategy, design, and development.

Sign up for our newsletter.

What is Information Architecture and Why it is Important to Your Website

Posted by Acquia Developer Center Blog on October 20, 2016 at 8:23pm

Website navigation is something you probably use every day but don’t think too much about. This is how you travel from page to page within a website. It is probably the most used part of your website that you spend the least amount of time evaluating, right? I used to feel the same way. A few years ago, I inherited a site navigation that seemed to be working so my team focused on growing other areas of the site. Looking into how our menu was organized was low priority.

Tags: acquia drupal planet

Tag1 Quo: Versions, Versions Everywhere, Part 1

Posted by Tag1 Consulting on October 20, 2016 at 4:55pm
sam Thu, 10/20/2016 - 09:55

When Tag1 decided to build Tag1 Quo, we knew there was one question we’d have to answer over, and over, and over again: is there a security update available for this extension? Answering that question - at scale, for many websites, across many extensions, through all the possible versions they might have - is the heart of what Quo does.

How to Make Acquia Lift for Content Syndication Work with Existing Sites

Posted by Acquia Developer Center Blog on October 20, 2016 at 3:33pm
lift cropped

Acquia Lift for Content Syndication is an Acquia product that allows you to have a central repository for your content and syndicate it out to various connected sites. All the connected sites are able to send content to the repository for use on any other connected site. In an ideal world, all the connected sites would have matching content type and field machine names. However, in our reality, we had two existing sites where this was not true.

Tags: acquia drupal planet


Subscribe with RSS Subscribe to aggregator - Planet Drupal