Planet Drupal

Subscribe to flux Planet Drupal - aggregated feeds in category Planet Drupal
Mis à jour : il y a 11 min 47 sec

Chapter Three: Authoring Experience (AX) Best Practices for Images in Drupal

jeu, 03/09/2015 - 21:43

Do you add content to Drupal websites? Have you ever found yourself in the process of uploading an image, with no clue what size to upload? Or whether Drupal will scale or crop the image? If so, you’re not alone.

Drupal sites get built a million different ways because of scope, budget and time. Because of this, sites behave differently. One site may automatically crop and scale an uploaded image to fit within a template. Another may require you to do that work before hand. This behavioral inconsistency can leave admins guessing as to how the site behaves.

You might be thinking “But we account for this during training.” Many teams train clients how to use their sites during a hand off. They account for any lack of help text with verbal explanations. While that trained client maintains the site, everything may go fine. But what happens when that person leaves and another person takes over? Do they get trained? Is there documentation?

Catégories: Elsewhere

Promet Source: WHITEHOUSE.GOV Puts Open Source on the Map

jeu, 03/09/2015 - 21:35

Obama's presidency has been marked by a number of technological firsts: Obama's been unofficially dubbed the "social media President" as he was the first sitting US president to have a twitter account, his campaigns embraced methods such as email marketing and by all accounts he's the first president to use a selfie stick. Yup.

Catégories: Elsewhere

OSTraining: Drupal Slideshows with FlexSlider from WooThemes

jeu, 03/09/2015 - 21:22

Flexslider is a jQuery plugin by WooThemes and it makes it very easy to create slideshows.

You can integrate it into Drupal easily, using the FlexSlider module which has full Views integration.

The FlexSlider page on, shown below, gives you an idea of the slideshows you can build with FlexSlider.

Catégories: Elsewhere

DrupalCon News: Flashback Friday - DrupalCon Barcelona in 2007 and 2015

jeu, 03/09/2015 - 20:52

If you have deja vu when we say DrupalCon Barcelona, you could be one of the people who attended DrupalCon Barcelona back in 2007! In true Throwback Thursday fashion, we are going to break down the tried and true things that have been the same for the past eight years, and what you can expect to be different at our upcoming DrupalCon.

Catégories: Elsewhere

Colan Schwartz: Responding to Drupal's highly critical SQL injection vulnerability

jeu, 03/09/2015 - 20:26

On October 15th, 2014, the highly critical SA-CORE-2014-005 - Drupal core - SQL injection vulnerability was announced. Shortly afterwards, research showed that sites not patched that same day could very well be compromised. Two weeks later, a public service announcement was released explaining the gravity of the situation. There was also a FAQ, a flowchart for dealing with it and a module that could potentially confirm a compromised site. Needless to say, it was a challenging time for the community.

At the time, I was asked by a client of mine to analyze a site to determine risk.

Some common attack vectors associated with the vulnerability were:

  • Changing the superuser's (user ID 1) username, password or e-mail address.
  • Adding new users to the user table with the administrator role (usually ID 3).
  • Adding entries to the menu_router table.
  • Adding PHP files to the code base or in the sites/all/files directory.
  • Adding nodes (pages) or blocks with executable PHP.
  • Downloading the list of user passwords
  • Determining hackability through the version listed in CHANGELOG.txt
  • Spawned processes run by the Web server
  • Adding new roles
  • Permission changes

So based on the above, and some other sources, it was possible to produce a list of things one could look for to determine if a site had been compromised. As has been discussed elsewhere, failure to confirm any of these did not mean the site was not compromised, but it did provide some indication of risk.

  1. Rerun the Security Review module.
  2. Perform checks with the Drupalgeddon & Site Audit modules.
  3. Check for changes to user 1's username, password or e-mail address.
  4. Check all users in roles other than "anonymous" and "authenticated".
  5. Check for strange entries in the menu_router table.
  6. Check for code files outside of version control.
  7. Check for code files inside sites/all/files.
  8. Check for new nodes or blocks in the DB.
  9. Check for strange processes spawned by the Web server user.
  10. Check for any new roles.
  11. Check for any permission changes.
  12. Check the mail logs for anything suspicious being sent out.
  13. Scan site with the Sucuri tools Free Website Malware and Security Scanner and Unmask Parasites.
There are some worthwhile things to note with respect to the checklist above:
  1. Some of the clues (such as 5 and 6 above) would have been long gone as they're rebuilt during cache clears and deployments.
  2. It's theoretically possible that malicious processes could have been spawned by the Web servers. The names could have been renamed to look non-malicious, but unless something was set up to make these persist across power cycles, they would be wiped on a system reboot.
  3. It's also theoretically possible that user passwords could have been compromised. In Drupal 7, hashed passwords are salted, but the random string used for the salt could have been read as it's in sites/default/settings.php. With that in mind, the site would be susceptible to brute force, dictionary and rainbow table attacks. If the site isn't going to be rebuilt, it would be a good idea to expire all passwords and forcing users to reset them. If another system is handling authentication, this isn't an issue.

And of course there could be any number of other things. The best course of action would be to rebuild the site. If that's a challenge, always consider the level of risk before deciding not to. Hopefully we won't have to make too many of these determinations in the future.


This article, Responding to Drupal's highly critical SQL injection vulnerability, appeared first on the Colan Schwartz Consulting Services blog.

Catégories: Elsewhere

Acquia Developer Center Blog: Building Drupal Web Sites in China: The Existing Landscape

jeu, 03/09/2015 - 19:02
Adam Malone

After working with both Chinese customers and global customers with a Chinese user base, we at Acquia have developed an understanding not only of the sometimes difficult requirements faced, but also the existing state of both sites and platforms.

Tags: acquia drupal planet
Catégories: Elsewhere

Cheeky Monkey Media: Require JS, Grunt, Bower, Foundation, Compass and Drupal - Let’s just be friends, with benefits.

jeu, 03/09/2015 - 18:41
In depth, but not too deep

Okay, so you want to use RequireJS to manage and organize your JS and all the dependencies, in a modular way. You also don’t want deal with RequireJS caching the heck out of your JS changes during development, otherwise...Derpal..  but, you do if you’re ready for production.

Also...  Compiling with Grunt (compass), component package management with Bower, and having it not interfere with Drupal. (.info files… we’ll get to that).

And finally, I’m not a fan of installing ruby gems and all that globally...

Catégories: Elsewhere

InternetDevels: InternetDevels on Clutch’s Top Ukrainian Developers List

jeu, 03/09/2015 - 16:01

Hey Drupalists! Any news – fine or great? Because we cannot restrain our emotions for longer: American researcher of world’s IT industry Clutch ranged us as one of 12 Top Web and Software Developers in Ukraine. Not bad, yes? Especially if to take into account that we are the only Drupal developer on the list.

Read more
Catégories: Elsewhere

Acquia Developer Center Blog: Why Drupal, Why Now? An Agency CTO’s Perspective

jeu, 03/09/2015 - 15:22
Corey CapletteReason #1: Drupal is Technology Ready

For the past 15 years Velir has been customizing and implementing top-tier content management systems. Given our focus on creating digital solutions, content management is at the core of almost every project we take on.

We’re veterans in the CMS space, but up until recently we exclusively worked with commercial CMS platforms. As the CTO of my agency, I wanted to explain why we’ve now decided to take the leap with Drupal.  

Tags: acquia drupal planet
Catégories: Elsewhere

.VDMi/Blog: Pane Field: World domination with ctools panes inside your content

jeu, 03/09/2015 - 14:29
If you're building flexible content with something like Paragraphs and build your sites from an editors perspective, you will really like this one. Pane Field brings the ease of ctools panes to Entity Fields. With this modules you can use ctools panes inside your content!

Pane Field is a new Drupal module by VDMi.
Most of the time we will give our users 3 Paragraphs types:

  • Text (just a simple WYSIWYG and a title field)
  • Text with image (simple WYSIWYG, title field, image field (media/scald/image), image position)
  • Image (media/scald/image)

Over time we learned that when content editors discover such flexible content, they immediately start thinking about exceptions. You’ll probably get some questions about “special” content like animations, videos and call-to-actions. That's where Pane Field comes in!

While most of these exceptions can be implemented in Paragraphs, it’ll become a problem when you have 10 different animations, or 10 different call to actions and the list keeps growing. That’s why we thought of another way to keep the ease of content editing, but have the flexibility of ctools panes. Which gives you - the developer - an very easy way to quickly create new pieces of content that the editor can use.

Ctools panes (also known as content types) are simple ctools plugins that basically define what they are, how they are configured and how they should be rendered. A definition is placed inside the same file that takes care of configuration/rendering. The definition will look something like this:

<?php /** * Plugins are described by creating a $plugin array which will be used * by the system that includes this file. */ $plugin = array(   'title' => t('Buy our product'),   'description' => t('Buy our product and get another one for free call to action.'),   'category' => t('Call to Actions'),   'edit form' => 'shop_cta_buy_our_product_edit_form',   'render callback' => 'shop_cta_buy_our_product_render',   'admin info' => 'shop_cta_buy_our_product_admin_info',   'required context' => new ctools_context_required(t('Node'), 'node'),   'defaults' => array(     'title' => 'Improve your daily workflow with our turboblender',     'subtitle' => 'Buy now and get one free!',     'button' => 'Buy now!',     'button_link' => 'order',   ) );

The callbacks will look like this for a simple pane, they are in the same file as the definition:

/** * 'Edit form' callback for the content type. */ function shop_cta_buy_our_product_edit_form($form, &$form_state) {   $conf = $form_state['conf'];   $form['title'] = array(     '#title' => t('Title'),     '#type' => 'textfield',     '#default_value' => $conf['title'],   );   $form['subtitle'] = array(     '#title' => t('Subtitle'),     '#type' => 'textfield',     '#default_value' => $conf['subtitle'],     '#maxlength' => 2048,   );   $form['button'] = array(     '#title' => t('Button'),     '#type' => 'textfield',     '#default_value' => $conf['button'],   );   $form['button_link'] = array(     '#title' => t('Button Link'),     '#type' => 'textfield',     '#default_value' => $conf['button_link'],   );   return $form; } function shop_cta_buy_our_product_admin_info($subtype, $conf, $context) {   $output = new stdClass();   $output->title = '';   $output->content = '<strong>'. t('Title') . ':</strong> ' . check_plain($conf['title']) . '</br>';   $output->content .= '<strong>'. t('Subtitle') . ':</strong> ' . check_plain($conf['subtitle']) . '</br>';   $output->content .= '<strong>'. t('Button') . ':</strong> ' . check_plain($conf['button']) . '</br>';   $output->content .= '<strong>'. t('Button Link') . ':</strong> ' . check_plain($conf['button_link']) . '</br>';   return $output; } function shop_cta_buy_our_product_render($subtype, $conf, $panel_args, $context) {   $node = $context->data;   $block = new stdClass();   $block->title = '';   $content = array(     '#theme' => 'shop_cta_buy_our_product',     '#path' => drupal_get_path('module', 'shop_cta'),     '#title' => $conf['title'],     '#subtitle' => $conf['subtitle'],     '#button' => $conf['button'],     '#button_link' => $conf['button_link'],   );   $block->content = $content;   return $block; }

And there you go, you created a new piece of custom content for your website. In the theme function you can use a template that has some custom HTML. Now you can enable the pane in the instance settings of the pane field:

As you can see, your new pane is available, all default ctools panes are also available.

When you edit content, you can now add a new Paragraph, select the paragraph type with the pane field and then select the new ctools pane:

You’re probably wondering “WHY?” at this moment

Pane Field causes extreme flexibility in your content without the hassle of creating a new paragraphs type, adding fields to them, adding preprocess functions, creating a bundle template. It allowes you to create exceptions to your base types much faster. It also is faster (in CPU time) compared to using a new Paragraphs type because it’s not a new entity, it’s just a field value with a reference to the ctools pane and some configuration values.

One big note: because the pane configuration is simply stored serialized in the field value, you can’t use them in stuff like Views or Search API (you can render the field and index that though).

Here is a more comprehensive article about how to write content panes.

Catégories: Elsewhere

Colan Schwartz: Upgrading a Drupal distribution

jeu, 03/09/2015 - 00:54

Upgrading Drupal distributions, technically referred to as installation profiles, can be tricky. If you aren't using Drupal Core, but rather a distribution of it, it's not possible to follow standard processes for upgrading Drupal core and contributed modules. You must upgrade the distribution as a whole.

In this article, we'll be working with the Web Experience Toolkit (wetkit) as the example distribution.

Assumptions Steps
  1. Switch to your Web directory and make sure your working tree is clean.
    1. cd $(drush dd @site); git status
  2. Note any commits made to the distro since it was last upgraded. These will have to be reapplied (cherry-picked in git-speak) after the upgrade unless they were explicitly added to the distro in the latest release. Find them with this command.
    • git log profiles/wetkit/
  3. Make sure that you read and understand any distro-specific information on upgrading it. In this example, the documentation is available over at Release Cycle / Updates.
  4. This is a workaround until Drush up should update contrib profiles as well is fixed. Download the distro with the following command. For the version number, use the version that was released immediately after the version that you currently have installed. For example, if you have 7.x-1.4, you need to download 7.x-1.5. If you're multiple versions behind, you'll need to repeat these instructions multiple times. Jumping more than one release ahead could cause problems.
  5. Unpack it.
    1. tar zxvf /tmp/wetkit-7.x-Y.Z-core.tar.gz --directory /tmp
  6. Move your sites folder out of the way so that it won't be overwritten. It's necessary to do this as the administrator to maintain permissions on the files directory.
    1. sudo mv sites /tmp
  7. Copy the new release's files into your Web dir. Don't copy core's Git ignore file; keep ours. This is a workaround for Rename core .gitignore file to example.gitignore and add explanatory comments.
    1. cp -r /tmp/wetkit-7.x-Y.Z/.htaccess /tmp/wetkit-7.x-Y.Z/* .
  8. Replace the new default sites dir with our own.
    1. rm -rf sites
    2. sudo mv /tmp/sites .
  9. Remove the distro-specific Git ignore files, as they'll cause us to ignore files we shouldn't.
    1. rm $(find profiles/wetkit -name ".gitignore")
  10. Stage all of the changed files.
    1. git add --all
  11. Commit the upgrade with a comment like, "Issue #123: Upgraded the WxT distro from release 7.x-A.B to 7.x-A.C."
    1. git commit
  12. Cherry-pick each of the commits that you noted in the first step. Ideally, these are upstream patches that you either found or posted yourself while working on the distro. For each commit message, use something like "Issue #567: Applied patch from" so you'll know if you'll be need to re-apply it again, or if it's been committed (and you no longer need to worry about it).

    1. git --edit cherry-pick COMMIT_ID_1
    2. git --edit cherry pick COMMIT_ID_2
    3. ...
  13. Update the database schema.
    1. drush updb
  14. Clear all of the application caches.
    1. drush cc all
  15. Test the local site to ensure everything is working.
  • Whenever we override the distro's module versions in sites/all/modules/contrib (this should be an extremely rare occurence, if ever), we should set up Profile Status Check. In fact, it probably wouldn't hurt to include this module in all of the official distributions.

This article, Upgrading a Drupal distribution, appeared first on the Colan Schwartz Consulting Services blog.

Catégories: Elsewhere

DrupalCon News: From Our Sponsor: Managing Data with Drupal

mer, 02/09/2015 - 23:08

There has been a radical shift in how enterprises want to use Drupal. Their focus is moving from sites to integrated services., and this change is typically accompanied with a set of new technologies, such as MongoDB and Node.js. Still, the role of Drupal has become more central than ever. How?

Catégories: Elsewhere

DrupalOnWindows: Drupal: Add new operators to views filters (such as contained in CSV) or how to override default view's handlers

mer, 02/09/2015 - 22:21
Language English

Today I'm going to show you how to turbo boost Drupal's default views filters with an example on how to add  a "Conatained in CSV" operator for Numeric and String filters.

Imagine a user wants to perform a batch operation on entities with ID's X, Y and Z. Unless they all appear on the same page, or you set the page size to inifinte this is impossible because Views Bulk Operations won't let you manually pick items between searches and/or pages.

We want something like this to happen:

More articles...
Catégories: Elsewhere

Axelerant Blog: The Top 7 Reasons To Use Drupal In Higher Education

mer, 02/09/2015 - 20:00

In recent years, using Drupal in higher education is a popular choice among leading schools. It has become the preferred website platform for hundreds of higher education institutions around the world. Schools like Harvard University, University of Adelaide, Bentley University, Uncommon Schools, University of Waterloo, and Yale all agree that Drupal is the content management framework that supports the current and future needs of students, faculty, alumni, and their communities.

In short, Drupal has proven it serves higher education website needs. Here are seven specific reasons it's best for your school.

The Top 7 Reasons To Use Drupal In Higher Education 1. Multi-Site Functionality

Most universities and colleges maintain multi-faceted websites, ones that serve a broad range of purposes. By leveraging Drupal's inherent multi-site functionality, institutions provide their departments with a substantial toolbox and relevant media types for communicating with students, staff, and other users via a single system.

This multi-site capability helps institutions break out independent websites by giving control and ownership to individual departments. This significantly reduces administrative overhead from the IT office.

2. Easy Responsive Design Implementation

According to an eMarketer study, an estimated 90 percent of US college students will own a smartphone by the time they graduate in 2016. Another study done in 2012 has published findings that "nearly half of all 18 to 29 year-olds using the Internet, do most of their online browsing on their mobile device."

Academic centers can use Drupal to stay up-to-date and relevant to users by delivering smoother, responsive website experiences. Experiences from each user's device of choice. Drupal sites adapt to user evolutions, making it optimal for institutions with student demographics.

3. Workflow Modules

Drupal's Workflow modules and features set allows universities and colleges to control and manage the publication process effectively, without limiting its use as a mere content management tool. There's granular control available for every content publishing processes. At each step, employees can be notified to complete their tasks (like copy editing). This keeps team members from performing tasks out of order.

4. Content and User Access Control

With Content and User Access Control, site administrators can create privileges grouped together by access level, function, and role. These permission sets can be assigned to groups of users rather than manually granting privileges to each and every user. Permission sets help decentralize task responsibilities like creating, editing, and managing content. All without putting extra workload on your IT hub. These access control features are exceptionally handy with respect to university websites where professors, students, alumni, and site visitors require unique user experiences and different access rights.

5. Efficient Use of Taxonomy System

Drupal's taxonomy system is a robust method for classifying website content into groups. Taxonomy systems can be designed and deployed on a per-content basis. This ensures extremely efficient content categorization on the site, resulting in ease of access for site visitors or users. Through taxonomy usage only relevant content is delivered to user; this avoids distractions and simplifies navigation.

6. Collaboration Modules

Apart from forward-facing content—static pages, forums, course schedules, blogs, and articles—Drupal provides powerful collaboration features and document management for back-end users. These systems are not typically part of the public front-end, but are critical for faculty and students who require access to manuals, handbooks, procedural guides, and research documents. Because of its tools for collaboration, Drupal is arguably the best tool for supporting internal teams and research for university and college websites.

7. Single Sign-On

Most every higher education institution has existing authentication systems for email or other internal accounts. Through Drupal using LDAP and CAS, single sign-on academic websites are easily possible. These single point access integrations result in a secure environment for users to multiple resources and services through a single login.

Drupal Distributions for Higher Eduction

Want to get started with Drupal? There are complete Drupal distributions like OpenAcademy, OpenEDU, and OpenScholar for kickstarting educational sites. These higher education Drupal distributions will provide your academic website with relevant and highly useful features with little effort from your end.

Want More Help?

Axelerant has worked on multiple higher education projects, like SUNY Maritime's Drupal migration. Contact us below and we'll talk about how we can make Drupal happen for your institution.


The post The Top 7 Reasons To Use Drupal In Higher Education first appeared on Axelerant.

Catégories: Elsewhere

Drupal core announcements: Drupal 8 beta 15 on Friday, September 4, 2015

mer, 02/09/2015 - 18:38
Start:  2015-09-04 00:00 - 23:30 UTC User group meeting Organizers:  catch xjm

The next beta release for Drupal 8 will be beta 15! (Read more about beta releases.) The beta is scheduled for Friday, September 4, 2015. To ensure a reliable release window for the beta, there will be a Drupal 8 commit freeze from 00:00 to 23:30 UTC on September 4.

Beta 15 will include a couple of important API changes. See SafeMarkup::set(), SafeMarkup::checkPlain(), and other methods are removed from Drupal 8 core for details.

Catégories: Elsewhere

Drupal core announcements: SafeMarkup::set(), SafeMarkup::checkPlain(), and other methods are removed from Drupal 8 core

mer, 02/09/2015 - 18:21

Before the release of the first Drupal 8 beta, Twig's autoescape functionality was enabled in Drupal 8 core. At the time, the SafeMarkup class was added in order to integrate Drupal core's own filtering and escaping APIs with Twig's.

Following extensive critical work on Drupal 8's sanitization APIs, most of the public API for the SafeMarkup class has been removed. Of particular note: for the next beta (beta 15), SafeMarkup::set() will be removed and SafeMarkup::checkPlain() will be deprecated for removal before 8.0.0.

SafeMarkup::set() will be removed

The SafeMarkup::set() method was documented for internal use when it was originally added. However, Drupal 8 core (as well as some contrib and custom modules) used it incorrectly to avoid unwanted escaping, because at the time there were not good examples for all usecases, particularly for code that assembled together multiple different strings of markup. Now, all core usages have been removed, and the change record has been updated to include recommended strategies for concatenating markup strings. Refer to this change record to replace any remaining usages of SafeMarkup::set().

SafeMarkup::checkPlain() is deprecated and will be removed

In Drupal 7 and earlier, check_plain() was important for sanitizing untrusted input for output to the page. In Drupal 8, Twig's autoescape provides this functionality for any variables passed to a Twig template, and other APIs are used in other circumstances.

When explicit escaping is needed, the most direct replacement for check_plain() or SafeMarkup::checkPlain() is Html::escape(). See the change record section on escaping text in Drupal 8 for details.

The correct use of t() and SafeMarkup::format() is not affected and these functions will still automatically escape input passed in the second parameter for a @variable or %variable placeholder. See the SafeMarkup::format() documentation for details.

Catégories: Elsewhere

Drupal Watchdog: VIDEO: DrupalCon Los Angeles Interview: Jen Lampton & Nate Haug

mer, 02/09/2015 - 17:53

Jen Lampton and Nate Haug (co-founders, BackDrop CMS) explain their fork of Drupal 7: why they felt the move was necessary; who benefits from it; and the Drupal community’s reaction.
There’s also a blatant plug for Drupal Watchdog. (Which you should subscribe to, right now, before you forget:

Tags:  DrupalCon DrupalCon Los Angeles Video Interview Video: 
Catégories: Elsewhere

Lullabot: Between Releases: When Should I Adopt the Newest Version of Drupal?

mer, 02/09/2015 - 17:30

Watching the Drupal release cycle ebb and flow reminds me of sitting on the beach as the waves roll in. There is Drupal 5! It’s getting closer and closer! Finally it crashes on the beach in a splash of glory. But immediately, and initially imperceptibly, it starts to recede, making way for Drupal 6. And so the cycle goes, Drupal 5 recedes and Drupal 6 rushes in. Drupal 6 is overcome by Drupal 7. And now, as I write this, we’re watching as Drupal 7 washes back and Drupal 8 towers over the beach.

Each new version of Drupal is a huge improvement on the one before. But each version also introduces uncertainties. Is all that new functionality necessary? Has Drupal core become ‘bloated’? Does it do too much (or too little)? Will it be performant? How much work will it take to implement? Is it still buggy? And, arguably, the most important question of all, when will the contributed modules we need catch up?

So when is Drupal “ready” for our clients? If clients want a new site in this between-releases period, do we build it on the solid, safe, predictable older release? Or jump in with the shiny, new, improved release that is just over the horizon, or just released? Or do we wait for the new version to mature further and delay building a new site until it’s ready?

We’ve dealt with these questions over and over through the years. Knowing when to embrace and build on a new major release requires careful consideration along several axis, and making the right decision can be the difference between success and failure.Here are the guidelines I use.

How Complex is the Site?

If the site is simple and can be built primarily with Drupal Core, than the shiny new version is likely a safe bet. Contributed modules may add nice features, but creating the site without many (or any) of them will mitigate your risk.

Each new Drupal release pulls into core some functionality that was previously only possible using contributed modules. Drupal 5 allowed you to create custom content types in the UI. Drupal 7 added custom fields to core. Drupal 8 brings Views into core. And every Drupal release makes some contributed modules obsolete. If the new core functionality is a good match for what the site needs, we’ll be able to build a new site without using (and waiting for) those contributed modules, which would be a good reason to build out on the frontier.

Correspondingly, if the site requires many contributed modules that are not included in core, we’ll have to wait for, and perhaps help port, those modules before we can use the new version. If we can’t wait or can’t help we may have no choice but to use the older version, or wait until contributed modules catch up.

How Tight is the Deadline?

It will probably take longer to build a site on a new version of Drupal that everyone is still getting familiar with than an older version that is well understood. It always takes a little longer to do things when using new processes as when repeating patterns you’ve used many times before.

Delays will also be introduced while waiting for related functionality to be ready. Perhaps there is a contributed module that solves a problem, but it hasn’t been ported yet, so we have to stop and help port it. Or there may not be any contributed module that does anything close to what we need, requiring us to plan and write custom code to solve the problem. Latent bugs in the code may emerge only when real world sites start to use the platform, and we might have to take time to help fix them.

In contrast, if we’re using the mature version of Drupal, odds are good that the bugs have been uncovered and there is code somewhere to do pretty much anything that needs to be done. It might be a contributed module, or a post with examples of how others solved the problem, or a gist or sandbox somewhere. Whatever the problem, someone somewhere probably has already run into it. And that code will either solve the problem, or at least provide a foundation for a custom solution, meaning less custom code.

Basically, if the deadline is a key consideration, stick with the tried and true, mature version of Drupal. There just may not be enough time to fix bugs and create custom code or port contributed modules.

How Flexible is the Budget?

This is a corollary to the previous question. For all the same reasons that a deadline might be missed, the budget may be affected. It takes more time (and money) to write custom code (or stop and port related contributed modules). So again, if budget is tight and inflexible, it might be a bad decision to roll out a site on a shiny new version of Drupal.

How Flexible is the Scope?

If we use the latest, greatest, version of Drupal, is the scope flexible enough to allow us to leverage the way the new code works out of the box? If not, if the requirements of the new site force us to bend Drupal to our will, no matter what, it will require custom code. If we build on a more mature version of Drupal we may have more existing modules and code examples to rely on for that custom functionality. If we build on the bleeding edge, we’ll be much more on our own.

Where is the Data Coming From?

If this is a new, from-scratch site, and there’s no need to migrate old data in, that would be a good use case for building this shiny new site with the latest, greatest version of Drupal.

But if there is an existing site, and we need to not only create a new site, but also migrate data from the old site to the new, the question of which version to use gets more complicated. If the source is another, older Drupal site, there will (eventually) be a supported method to get data from the old site to the new site. Even so, that may not be fully ready when the new version of Drupal is released. Drupal 8 uses Migrate module for data migration, but only the Drupal 6 to Drupal 8 migration path is complete, and that migration process will likely improve in future point releases. The upgrade path in previous versions of Drupal was often fraught with problems early on. It's something that never gets fully baked until the new version is in use and the upgrade process is tested over and over with complex, real-world sites. So the need to migrate data is another reason to use the older, more mature version of Drupal (or to wait until the new release is more mature).

How Important Is the New Hotness?

Every version of Drupal has a few things that just weren’t possible in previous versions. CMI (Configuration Management) in Drupal 8 provides a much more rational process for deploying code and configuration changes than Drupal 7 does. Drupal 7 requires banging your head against the limitations of the Features module, which in turn is hampered by the fact that Drupal 7 core just isn’t architected in a way that makes this easy. And Drupal 8 core has built-in support for functionality previously only possible by using one or more additional Services modules in Drupal 7.

If these new features are critical features, and if struggling to solve them in older versions has been a time sink or requires complex contributed modules, it makes sense to dive into the latest greatest version that has this new functionality built in.

How Long Should It Last?

A final question is how often the site gets re-built. If it is likely to be redesigned and re-architected every two or three years to keep it fresh, there should be little concern about rolling out on the older, mature version of Drupal. Drupal 7 will be supported until Drupal 9 is released, and that is likely to be a long time in the future. If it will be many years before there will be budget to re-build this site that might be a reason to build it on the latest version, delaying the project if necessary until the latest version is fully supported by contributed modules and potential problems have been worked out.

It’s Complicated!

The ideas above are just part of the thought process we go through in evaluating when to use which version of Drupal. It’s often a complex question with no black and white answers. But I take pride in our ability to use our long experience with Drupal to help clients determine the best path forward in these between-release periods.

Catégories: Elsewhere

OSTraining: Views Bulk Operations Makes Mass Updates Easy in Drupal

mer, 02/09/2015 - 17:18

Views Bulk Operations (VBO) is one of those modules whose name and description doesn't indicate how useful it is.

Here's the short version of what VBO does it:

  • Allows you quickly select all the items displayed in a View.
  • Allows you to perform advanced operations on all the items you selected.
Catégories: Elsewhere