Planet Drupal

Subscribe to flux Planet Drupal
Drupal.org - aggregated feeds in category Planet Drupal
Mis à jour : il y a 44 min 5 sec

Lin Clark: Video: Setting up REST Services in Drupal 8

mer, 22/01/2014 - 23:00

With Drupal 8, you can provide REST services to interact with your site’s data, and you don’t have to rely on contrib modules to do it. This screencast is the first in a series demonstrating how to configure such services. In this one, I will show...

Catégories: Elsewhere

Midwestern Mac, LLC: Debugging Varnish VCL configuration files

mer, 22/01/2014 - 18:45

If you're a Drupal or PHP developer used to debugging or troubleshooting some code by adding a print $variable; or dpm($object); to your PHP, and then refreshing the page to see the debug message (or using XDebug, or using watchdog logging...), debugging Varnish's VCL language can be intimidating.

VCL uses C-like syntax, and is compiled when varnish starts, so you can't just modify a .vcl file and refresh to see changes or debug something. And there are only a few places where you can simply stick a debug statement. So, I'll explain four different ways I use to debug VCLs in this post (note: don't do this on a production server!):

Catégories: Elsewhere

Aten Design Group: A Seamless Media Experience

mer, 22/01/2014 - 18:07

One of the primary goals of the new CPR.org website was creating a great, seamless media experience. Part of this was the creation of a persistent audio player that worked on as many modern browsers and devices as possible. Creating this experience, though, was a bit of a process. The audio landscape is pretty scattered when you take a close look at HTML5 audio support and Flash support. So the first thing up was finding a library that let us use both types of audio to reach a wider audience.

jPlayer for HTML5 Audio

HTML5 Audio is an important step forward in bringing media to the masses. It allows browsers to natively play audio without the help of plugins, whereas Adobe Flash was the primary means for playing audio in the past. This is doubly necessary for the plethora of new devices that don’t use Adobe Flash. But HTML5 Audio isn’t exactly a silver bullet just yet. While all modern browsers support Audio, each browser supports different formats (especially when considering compressed formats like MP3 or AAC).

The player on the site is using a library called jPlayer, which provides HTML5 Audio and a Flash fallback. The change between players is transparent to site visitors and works well across the devices we tested. The site can play the audio files for stories and the audio streams that let you listen to live CPR programming anywhere you have an internet connection.

AJAX Navigation

The next issue is that if you throw an audio player on a page, and the users get excited about a link they see on the site the browser will leave the page and the audio will stop. We wanted to accomplish something more seamless, which leaves a couple options:

  1. Have an audio player that pops up in a new window
  2. Use AJAX for navigation, keeping the audio player on the page between requests

The new window approach is tried-and-true, but does present a user experience we wanted to avoid: having a separate window is confusing, especially on mobile devices. On a mobile device that would essentially become a new tab/screen and prevent the site exploration that we wanted. Desktop users would still have to deal with a separate window that may or may not be visible.

We opted to make the site use AJAX navigation and leverage HTML’s new History API. This gives us the seamless navigation that the site uses and keeps the address of site resources clean, which is not only important from an OCD standpoint but also for search engine’s and users a-like. To pull this off, we turned to the AJAX Links API (“Ajaxify Drupal with JQuery Ajax”) module. The module will take a normal Drupal site and allow you to target a set of links to work via an AJAX load instead of via normal navigation.

For the most part, the module seemed to work as needed out of the box. There were a few small changes we made and submitted back to the project as we came across issues. Many of these were feature additions, but we also ended up fixing some bugs along the way. In the end, we had diverted from the installed version quite a bit to make the functionality work with an updated jQuery, fixing bugs, and a few specifics from the site. Some of our changes included:

  • Updated to work with jQuery 1.8
  • Added “negative selector” support
  • Fixed some issues with browser history navigation (forward & back buttons)
  • Fixed targeting of links to downloadable files, mailto: links, and external links
  • Added custom callbacks for successful link navigation
  • Fixing a couple smaller issues with the module: 2135145, 2135135

Some issues were outside of the AJAX module’s control though. Other modules like reCaptcha and Webform had to be updated to submit and update via AJAX. We even wrote code to allow Polls to work via AJAX.

In the end, we hope the site encourages listeners to enjoy the programs and stories they have come to love, but also explore CPR’s stories in word and graphic form. So, sit back with your favorite device, enjoy some audio streams, and catch up on some stories you may have missed on CPR.org.

Catégories: Elsewhere

Lullabot: Processing Forms in AngularJS

mer, 22/01/2014 - 18:00

AngularJS is an MVC JavaScript framework which elegantly separates controller, business and model logic in your application. Although it takes getting used to after years of writing server-side code, it simplifies a lot of backend logic in our projects and we've had wonderful success with it so far.

Catégories: Elsewhere

Commerce Guys: Evolving Drupal Commerce Support

mer, 22/01/2014 - 15:58
As one of the most recent additions to the Commerce Guys team—I’m the new Director of Customer Support & Service—I’ve been presented with a unique and exciting challenge: to further develop how Commerce Guys offers support of Drupal Commerce in a way that meets current market needs and implements commercial software support industry standards, all in the context of the largest self-supporting, open-source community there is.    I like big challenges. So with the help of the team here, I’ve set about studying, listening, and learning. I’ve pored over forums, read through resolved Turbo Tickets, and reviewed business artifacts from our most successful projects. And through that, I’ve seen that with Drupal Commerce—   there’s a need to fill—to offer ongoing support for businesses running live commerce sites, making sure they minimize downtime and have an expert available whenever problems may arise. We see this most commonly with our Delivery Partners, the teams charged with integrating Drupal Commerce successfully in unique and complicated contexts, and they have inspired us to bring a few new things to the marketplace.   Available in 2014: Support Subscription Packages Many of our Delivery Partners have been asking for the same thing: to continue to own their relationships with their users, but to be able to count on having Commerce Guys there to support Drupal Commerce specifically. Some of our Delivery Partners just need a basic level of support—a few tickets a year and peace of mind knowing that they’ll get a response within a specific time frame—while others need a more comprehensive offering, like 24-7 coverage for anything, most importantly their major, show-stopping issues.    I’m happy to share that starting now, we’re offering Drupal Commerce Support Packages. We’ve designed these subscription-based packages based on our experiences with you, our partners and customers, so that we can offer the right amount of support for businesses of all sizes.    The details of each of the packages can be found in our new Support Offering Data Sheet, but in a nutshell: we’re offering Support Standard, Support Plus, and Support Premium packages, each with incremental degrees of support availability, response times, and available support tickets.    If you’re interested in leveraging Commerce Guys’ support, but aren’t a delivery partner—get in touch with us. We’re more than happy to help you find a Delivery Partner with a proven track record, or we can come up with a custom package to meet the needs of your business, no matter the size. We believe that through Commerce Support packages, we’ll have the opportunity to help our Delivery Partners be more successful by helping them solve complex issues and making sure we’re maximizing their sites’ uptime. I’m excited that Commerce Support packages will give us the chance to have ongoing relationships with the developers who depend on Drupal Commerce every day. We hope you’re as enthusiastic as we are about the launch of these services, and I invite you to learn more (the aforementioned data sheet provides quite a bit more detail, but you can always contact us for additional information).   Honoring the Roots of Drupal: Individual Contributors I want to be perfectly clear that while we at Commerce Guys are taking big steps to promote larger efforts like support subscriptions and bigger projects with our Delivery Partners, we haven’t forgotten our roots—namely, the individual developers who continue to provide Drupal’s greatest asset of community support.    We will continue to actively participate in all of the discussions that happen all over the Web—Drupal.org, Reddit, StackOverflow, and of course our own sites—and we won’t lose our passion for moving Drupal Commerce forward with you, together. Although I’ve only been with Commerce Guys a short while now, it’s become obvious to me that the Drupal Commerce community is one of communicators and creative problem solvers, and I look forward to continuing that relationship through online conversations.   In addition to that, we will continue to offer Turbo Tickets, our à la carte support offering, for those times when developers are in a jam and just need an expert to dig into one specific issue. Turbo Tickets are an analysis service for development support, and not a code-fixing offering or production-site support—so think of us in that context more as advisors than mechanics—but I’m proud of the fact that the majority of our Turbo Ticket users have reported high satisfaction, and Turbo Tickets continue to be a great way to get quick answers to developers.    The Number One Rule in Software Support: Listen to Your Users Much like Drupal and Drupal Commerce themselves, we at Commerce Guys will always be evolving, pushing the boundaries of what we can do, and asking ourselves and our users how we can do better. So in that spirit, I’m issuing an open invitation to you as a member of the Drupal Commerce community: Tell me what you’d like to see next. The top priority of anyone in software support should be to listen first—as the saying goes, “A problem well-stated is a problem half-solved,”—and along with the rest of the Commerce Guys team, I am eager to hear from you, our users, customers, and Delivery Partners about new needs as you see them. I can be reached at jaime@commerceguys.com, and I look forward to your feedback.   Tags: Planet Drupal
Catégories: Elsewhere

Mediacurrent: Getting Git: An Intro for Beginners

mer, 22/01/2014 - 15:52

Git is a version control system that's used extensively by the Drupal community.  It lets you and your team manage snapshots of your project.

Here are several benefits:

  • Coordinate concurrent work
  • Avoid teammates overriding your files.
  • Organize your team's development cycle.
  • Facilitate feature-based development methodologies.
  • Restore all or parts of previous work done within a project.
  • Minimize loss if your computer breaks, all but the latest work will have been stored remotely.

If you’re new to Git, you may be feeling a bit overwhelmed. However, once you get the hang of it, you won’t look back.

Catégories: Elsewhere

Drupal Easy: DrupalEasy Podcast 121: Good Soul

mer, 22/01/2014 - 08:02
Download Podcast 121

Damien McKenna (DamienMcKenna) makes his fourth appearance on the podcast (one more and he gets a tweed jacket!) to talk about the Metatag module and his prolific contribution history. Along the way Ryan Price sneaks in to join Ted Bowman and Mike Anello to discuss Drupal’s 13th birthday, some facts about core development in 2013, and Dries’ Reddit AMA.

read more

Catégories: Elsewhere

Drupal Association News: Drupal Dev Days shapes up to be an amazing event in 2014

mer, 22/01/2014 - 06:50

While the Drupal Association’s regular events are DrupalCons in Europe and North America, the community is always busy organizing all kinds of events around the world. The community has a long standing tradition to augment DrupalCon with the Frontend United and Drupal Dev Days traveling conferences in Europe which have more focused target groups.

Catégories: Elsewhere

R.J.'s Blog: The SysAdmin's Guide to Drupal 7

mer, 22/01/2014 - 04:09

This post is written for SysAdmins, IT Directors, and CTOs who either manage a Drupal 7 site or are thinking of bringing a Drupal 7 site into their portfolio of technologies. My goal is to demystify Drupal and help you understand how it works, how to best manage it, and the various tools and techniques to help ensure a good experience with Drupal.

Tags: DrupalsysadminDrupal Planet
Catégories: Elsewhere

Drupalize.Me: Release Day: Acquia Cloud Network

mar, 21/01/2014 - 23:33

Acquia's open cloud platform delivers your Drupal site to the world in a scalable, and secure manner. Our latest learning series publishes Acquia's most popular videos for their Cloud Network.

Catégories: Elsewhere

Phase2: Using Email with Open Atrium 2

mar, 21/01/2014 - 18:01

One purpose of collaboration tools is to move beyond standard email communications.  When collaborating with a team on a project you don’t want important messages stuck in somebody’s email inbox.  By posting all messages to a common discussion area, the entire team can stay informed.  However, most of us still use email on a regular basis.  Using an additional collaboration tool can often become a burden of extra work.  This isn’t a problem with Open Atrium 2 because it fully integrates with your existing email workflow.  In this article, I’ll describe how the Open Atrium 2 collaboration tool can send information to your email, as well as how you can post messages back to OA2 using email.

Notifications

One of the core features of Open Atrium 2 is the notification system.  A notification is just a simple message about something that happened within the collaboration space.  For example, a new post was created, or a document was changed, or a reply was added to a discussion thread.  These notification messages are summarized in the Recent Activity stream within each collaboration space.  When you create a new piece of content, you decide who will be notified: groups, teams, and/or individual users.  When the content is changed, or commented, notification emails will be sent to that collection of users.  The HTML templates used for these email messages can be customized for your specific site and can use Drupal tokens to insert elements such as the title of the content, who changed it, etc.  The default “content changed” message is even configured to show the specific changes (diff) between the old version and the new.

Message Digests

Within the Settings page of the user dashboard, each user can customize what kinds of notifications generate emails for each collaboration space the user is a member of.  For example, maybe you don’t want to get an email when content is deleted and only when it is added or changed.  Perhaps you don’t want to receive any email at all from certain spaces.  Open Atrium 2 even allows you to summarize the notification activity into daily or weekly digest emails.  You can even control whether you receive a separate digest message for each collaboration space, or whether you wish to receive a single message that summarizes all of your spaces.

Emailing replies back to Open Atrium

Getting email notifications is great and is part of most collaboration software.  They allow you to keep your normal email workflow and be notified when there is something important to see in your project spaces.  But Open Atrium goes even further than that:  it allows you to actually reply to those notifications within your email client and have your reply posted back into the OA2 space!  This feature is especially critical for mobile users.  Even with a mobile-friendly responsive web application such as Open Atrium, who wants to switch to another app just to reply to a discussion that you received a notification about in your email? The “email reply” feature is not included in the base Open Atrium 2 distribution because it requires a software library that might not be installed on your server by default.  So let me show you exactly how you set up this important feature on your Open Atrium 2 site.

Installing Open Atrium Mailhandler

The optional module that adds “email reply” support is the OA2 Mailhandler module.  Download this module from drupal.org and place it into your sites/all/modules folder.  You will also need to download the dependent modules: mailhandler, mailcomment, and feeds_comment_processor.  Place them also into your sites/all/modules folder.  Then enable oa_mailhandler and agree when asked to enable the dependent modules. Using Mailhandler requires that you have the PHP IMAP extension installed on your server.  This is a common PHP extension so you might already have it.  If not, you’ll need to ask your system administrator to install it and restart your web server.

Adding your OA2 Mailbox

Once you have OA2 Mailhandler installed and enabled you need to configure the email account that you will be using.  When a user replies to an email notification, that reply needs to go to some email address that you configure.  This needs to be a real email account that can store messages and which supports IMAP.  Every few minutes your Open Atrium site will query this mailbox to see if any new messages have been received.  When a message is received, it is taken from the mailbox and posted to the proper discussion thread in your OA2 site via the Feeds module. To set up this mailbox, go to admin/structure/mailhandler and click the Add link.  Give this mailbox a name, then enter the server hostname into the Domain field (for gmail this is: imap.gmail.com), then the Port number, Username, and Password.  An easy way to get all of this information is to add this mailbox to your normal email client.  Most email clients can configure a server just by entering the email address and password.  You can then look at the server settings for Domain/Host, Port, Username and copy them to the Open Atrium configuration page.  When you save your mailbox configuration, Drupal will test the connection to your mail server and verify that it is working. Once this is all working, the final step is to set the email address of your OA2 site.  Go to admin/config/system/site-information and enter the full email address of your mailbox into the “Mailbox E-mail address” field.  This will become the “reply-to” address of the notification messages.  If you also want to set the “from” address of these messages, change the normal Drupal “E-mail address” field to match.

Scheduling Email Import

When you reply to a notification email, your reply will be sent to the mailbox that you configured in the previous section.  By default, Open Atrium 2 will only fetch email replies and post them to your discussion threads whenever the “cron” task runs.  The “cron” task in Drupal runs periodically and performs all sorts of maintenance functions on your site, including checking for new versions of modules, indexing your search, etc.  By default it runs every 3 hours, but only when somebody actually views a page on your web site (this is the reason Drupal is slower the first time you fetch a page on your development server if no pages have been accessed in the past three hours).  You can change your Drupal cron interval at admin/config/system/cron, but the minimum value is still one-hour.  You probably want to fetch email more often than that, but you also probably don’t want to run all of the other cron tasks as often. The Elysia Cron module (among others) can help with this.  After installing it, you can visit admin/config/system/cron to fine tune when each different cron task is run.  For example, you can configure your email fetching by setting the feeds_cron and job_scheduler_cron tasks to run every couple of minutes, while keeping your search index at once an hour, and perhaps your Drupal update checker at once a day.  Follow the instructions given for the Elysia Cron module on how to set up a cron job on your web server to run this task every minute.

How does this all work securely?

When Open Atrium sends a notification email that can be replied to, it appends a secure token to the subject line, such as [#123-45678].  This token is unique per discussion post and is used to route the reply back to the correct discussion thread.  When a user replies to this email notification, Open Atrium verifies this secure token and also checks the email address of the reply to see which Drupal user account it matches.  OA2 then checks to ensure that this user account has permission to post content to the specified discussion thread.  While email addresses can be spoofed, the addition of the unique secure token for each discussion thread should prevent both spam and unauthorized posting.  Just ensure that your users are not sharing the email messages with the tokens to outside users. Sometimes a user might have more than one email account.  You can use the Multiple Email Addresses module to add more than one email to use Drupal user so OA2 will accept replies from any of a user’s mail accounts.

Conclusion

If you have any trouble setting up Mailhandler, take a look at the documentation for that module, and for related modules such as Feeds.  Once you have it set up your Open Atrium users will thank you for integrating their new collaboration tool with their regular email workflow!  Check out more Open Atrium news and updates on the Open Atrium documentation site!

Catégories: Elsewhere

Drupalize.Me: Risk and Drupal 8

mar, 21/01/2014 - 15:13

Every year Real Story Group (RSG) releases an updated snapshot of the web CMS market. Where will Drupal 8 be placed on the 2015 RSG snapshot?

Catégories: Elsewhere

Wunderkraut blog: Bernt’s Drupal Gotchas

mar, 21/01/2014 - 14:37

During my first year of being a full time Drupal developer, I ran into quite a few stumbling blocks. Here are 14 of them that you don't want to trip over too - whether you are new to Drupal or a seasoned expert.

I have just completed my first year as a full time Drupal developer. It has been an interesting year, I have learned a lot and continued to be impressed as to how productive you can be with Drupal. Time and again I have started a user story thinking it could take days or even weeks, but then finished it by a few clicks of my mouse. I am also very grateful to my awesome colleagues that have patiently pointed me in the right direction more than once.

There have been some surprises along the way, to a guy that has worked with web development for some ten years before starting with Drupal for real.

I have made a list of these for myself, titled Drupal gotchas. These are stumble blocks, or counterintuitive things that developers could benefit from knowing about when they meet Drupal for the first time.

They are not necessarily bugs, it is just nice to know about them in advance.

GOTCHA 1: Cache clear all doesn’t

Most developers use drush, and we use drush cc all a lot to clear drupal’s caches during development. But sometimes, just sometimes, that doesn’t help. Try logging on to drupal in your browser and clear the cache. Just because .. it would be too easy otherwise? 

GOTCHA 2: With features module and taxonomy

If you on your local env have some taxonomy, user role or permission that is not on the other end, and try to export permissions regarding one that is the newest, there will be lots of SQL errors on the other end.

Cause: Taxonomy permissions, user roles and permissions are put into feature based on their id numbers from the database, and not the name as you would expect.

GOTCHA 3: Reverting Features doesn’t give you a feature in default state

Removing a field or field group from a content type? It won't be removed when you do a feature revert on the target.

This is probably what you want in many cases; having features module delete fields might lead to unwanted data loss.

When removing fields from a project, you should either do it through an update hook or manually delete them from all environments.

GOTCHA 4: Changing date fields

Oh, so you have a date field, and you decide that you want to collect the end date? Well, if there is content in the database, sorry it can't be done. It’s not like the project’s requirements will ever change, you know. 

I received a comment from Olli about this one which I think it is important to keep in mind:

Well, technically, it can be done. It just requires a manual change to the database. And filling in the missing end dates too. So, quite a bit of work instead of a simple field edit in the UI.

GOTCHA 5: Entity translation and views

If you use entity translation, and it is sort of your first time you are creating a view with this, you should print out this comment from Fabsor and hang it on the wall before you start:

"You can add a relationship to the entity translation table, and from there you can add entity translation: language as your filter. This filters out entities on a specific language."

GOTCHA 6: Default permissions in Drupal

In a vanilla Drupal installation, without any contributed modules installed, I would really want to be able to let editors add content and edit content, and even publish it on their own, but not delete anything.

Can you manage that?

If you grant the “Administer Content”-permission they will also be able to delete content.

GOTCHA 7: Machine name confusion

So is the machine name main_menu or main-menu? Not that consistent.

GOTCHA 8: Ajax forms

(From Cristian)

This might be trivial but it's good to remember: when doing ajax forms

"wrapper" => "form_id" is wrong

but "wrapper" => "form-id" is correct

GOTCHA 9: Views block deltas turn into md5 hashes

Sometimes CSS block views classes turn into md5 hashes, which can be quite annoying in several situations, for instance when writing CSS for a project. Instead of having developer friendly machine names as selectors, you end up with md5 hashes in your CSS.

merlinofchaos’ explanation was spotted by Joonas M:

This is not a random ID, it's an md5 hash. The reason md5 hash is used here is that it is guaranteed to be 32 characters or less.

The 'delta' field of a block is limited to 32 characters. However, the only guaranteed unique way of identifying a view and a display takes as many as 65 characters (32 characters for the view name, up to 32 characters for the display id, and a character to separate them, which is a dash). If this combination is 33 characters or longer, an md5 hash is used instead. It was the only solution I could come up with that functioned.

If you don't like the md5 hash, use shorter view names.

GOTCHA 10: Perhaps a bit too many a’ cache clears

This I learned in a caching session at drupalcon Prague:

If you turn on caching of pages for anonymous users, and an anonymous user adds a comment or something, all those caches are cleared.

GOTCHA 11: Why aren’t my new strings in the translate strings page?

This one is the fantastic t() function GOTCHA. I stumbled on it more than once..

I found a helpful comment by span:

It should also be noted that the string is not added to the database until it has been displayed in a language that is not the default. It is not enough to only display the string in the default language to be able to translate it via 'Translate interface'.

And Nick_vh:

"If you're visiting the Default language (mostly English) version of the site the translation table doesn't get populated... t() just output the passed string without accessing the DB. "

in the API documentation for Drupal 6.

And just now, in the same documentation for Drupal 7 I saw an interesting tip from jonathanpglick on how to get the strings programmatically into your system which I am looking forward to try:

If you want to get a string into the translate interface programmatically (without displaying the page containing it) you can call:
locale($string, '');
The empty string as the second argument is important!

GOTCHA 12: About blocks and caching

So you are making a custom block whose content depends on some variables, for instance $_GET ones, and you have turned on .. role based caching of your block (which is default)?

Well, then you are in for a surprise - Drupal will cache contents of the block as it is shown to the first visitor with their variables and show it to everybody with the same role.

In this case a DRUPAL_NO_CACHE directive for the block solved the issue, and I have a mental note about the caching from this point on.

GOTCHA 13: Disabling stuff in settings.php not disabling

So I had this nice learning experience where I wanted to turn off caching with redis, and instead use the default drupal cache. We had some issues with caching not clearing properly.

I commented out the redis cache config in in settings.php:

;$conf['cache_default_class'] = 'Redis_Cache';

But nothing changed! The problem was still there, and yes Drupal was still using redis as cache backend even though there was nothing in the config file to tell it to.

Then we realised that we had to add

$conf['cache_default_class'] = 'DrupalDatabaseCache';

into the config file too for it to work. Drupal doesn’t revert to the default state by itself as you might have expected from other config files.

GOTCHA 14: Memcached does not cache everything you want

This Gotcha is provided by Ilmari:

In memcached, a single cache entry is limited to 1Mb. Memcached itself won’t show up any error if something doesn’t fit in it, it will just act as if there was no cache at all for that entry, which can make a site very slow.

Cache bins that most often contain entries over 1Mb are those of views. That is why views bins would be the primary item I would/have put in Redis instead of memcached.

This is a configuration example:

# Cache bins. First cache_views, that doesn’t fit in memcached, and takes up to 30-40% CPU time of total when in MySQL. Redis works best. $conf['cache_class_cache_views'] = 'Redis_Cache'; $conf['cache_class_cache_views_data'] = 'Redis_Cache'; Over to you

Phew, that was it. Have you stumbled into another one? Please add it in the comments, so that other people will not have to spend those frustrating hours too!

Catégories: Elsewhere

Web Wash: Display Custom View Modes on Individual Nodes Using Display Suite

mar, 21/01/2014 - 08:01

When it comes to managing the look and feel of a content page, nothing can beat Display Suite. It's become an essential module for when you need to change the layout and fields on a node or any entity page.

Today I want to talk about a piece of functionality that you may not be aware of in Display Suite. It's the ability to switch the view mode will be used for an individual node.

Let me explain, when you go to a node page (node/1) the "Full content" view mode is displayed. But, you can only have a single version of this view mode for each content type.

Display Suite can be setup to allow authors to select a specific view mode on an individual node.

Instead of displaying "Full content", you could, on a select group of nodes use another view mode called "Feature landing page".

This functionality is not exclusive to Display Suite. You can do similar stuff using Panels or Panelizer.

In this tutorial, we'll create a custom view mode called "Full content feature" and we'll allow an editor to select which one will be used on individual nodes.

Catégories: Elsewhere

Phase2: Using and abusing the Configuration Management module for Drupal 7

mar, 21/01/2014 - 07:39

Just about any Drupal developer these days will be happy to do his or her share of moaning and groaning about the agony that is moving configuration between environments and keeping all of that stuff in code. The Features module has helped tremendously with that, and as a result, it’s a whole new world compared to a few years ago. But this really isn’t the problem that Features was created to solve (which involves capturing and reusing nice little bundled-up “features” from site to site). As a result, some feel that Features may not be the ideal solution to the problem that it ends up getting used for in practice.

A prime example is the Configuration Management (“CM”) module for Drupal 7. Having taken some notes from the Drupal 8 CMI notebook, it’s specifically built for what many people use Feature for–exporting general site configuration to code and moving it between environments.

The “Bucket” List

With that in mind, there are a couple major differences between Features and Configuration. The first and most major difference is that Features is built with the assumption that config needs to be split up into separate, cohesive, neat little packaged modules, and CM just throws it all into one big bucket.

There are a number of pros to the big bucket approach.

  • No confusion about what config is where
  • No tangled web of feature modules that depend on other feature modules
  • No chance of one feature module overwriting the config from another

But there are also a couple obvious disadvantages:

  • Not possible to toggle individual sets of config for a specific use case (“features”)
  • As such, not well suited for Drupal distributions that need to offer flexibility/modularity
  • Putting that much stuff into one directory can feel a bit dirty
So why bother?

Given that CM is simpler and less confusing but at the cost of modularity and flexibility, it’s generally more useful for custom site builds than for general purpose Drupal distributions.

If I’m a distribution, I need to be useful to as many people as possible (within reason). A big part of this is giving users the option to turn parts of me off if they don’t want them. If I’m using Features, that’s easy–just disable the module. With CM, it’s basically not possible outside of manually deleting the config items yourself from the GUI item by item or understanding how to edit the config files.

However, if I’m a custom website for a client and I don’t need any parts of me to be bundle-able or easily toggled (which, if we’re honest, is accurate for the majority of client sites) and I’m more concerned with simplifying the development workflow, then I might be best off with CM.

Set ‘er up

There’s not much to do to get rolling with CM. All you really need to do is tell it where it can find your config directory. By default, this is sites/default/files/config but you can put it wherever you want in CM’s Settings tab. Once you have that pointing to a directory that’s writeable by the server you’re good to do your first export.

Remember that for obvious reasons, the setting that controls the location of CM’s config directory is the only variable that cannot be exported by CM itself, because doing so would mean that on new installs, CM would not know where to look to find out where to look. Deep, right?

So that means that if your goal is to capture all configuration in code, then you’ll have to store that single variable another way, such as in the <code$conf</code> array in settings.php or by setting it in a module’s update hook. That said, once Drupal knows where to look for config, any and all other variables and settings can be managed by it.

Let’s configify some config!

Let’s dive in and see how the CM module works. To start, head on over to /admin/config/system/configuration/notracking to view the list of components you can start keeping track of.

This brings up an important distinction in CM: the difference between tracking and exporting. The main thing to remember here is that tracking is what you’ll be doing almost all of the time. Exporting creates a little tarball of config for you to send over to someone else, but it’s useful day to day as a part of your workflow. Tracking, on the other hand, is where the magic happens. You’ll need to check boxes next to things you want to keep track of in config (content types, variables, permissions, etc.). In return, CM will keep an eye on all of those things so that it can easily export them to code on command when they change.

With that in mind, let’s walk through the specific steps to make it happen.

GUI (non-drush) approach:
  1. Go to admin/config/system/configuration/notracking and choose which “thing” you want to start tracking GUI changes to. Note that it automatically selects dependencies.
  2. Go make your changes in the GUI.
  3. When you’re ready to export and commit the config, go to admin/config/system/configuration/tracking and click “Write Activestore to Datastore”
  4. In your config directory, commit the new changes and push them to the remote repo for others to get.
Drush approach:
  1. Run “drush config-get-non-tracked” to get a list of all non-tracked components, and find which one you want to start tracking.
  2. Run “drush config-start-tracking ” to start tracking it. It will automatically track dependencies as well.
  3. Go make your changes in the GUI.
  4. When you’re ready to export and commit the config, go to admin/config/system/configuration/tracking and click “Write Activestore to Datastore” (this unfortunately can’t be done in drush)
  5. In your config directory, commit the new changes and push them to the remote repo for others to get.

Typically, the non-drush approach is a bit quicker and easier, but the drush approach can be handy, especially if scripting.

Let’s import our friends’ configified config!

Importing config and updating our active store to match it is super simple.

  1. Pull in the latest config code from whatever repo you’re using.
  2. Run “drush config-sync” to sync the data store to the active store, or just run it in the GUI under the Synchronize tab.
What else do we have here?

All of that describes probably 95% of what you’ll be spending your time with if you use CM, but it’s not the whole picture. There are a few other things to be aware of:

“Migrate” tab

For times when you just want to let someone else quickly see a chunk of changes you’ve made without going to the trouble of syncing to the config directory and pushing the changes, you can click on over to the Migrate tab.

Here, you can use the Export tool to select bits of config which will dump it all into a tarball. That tarball can in turn be consumed by the Import tool on another site to pull the config into the active store.

Spiffy diffs

If you install the Diff module you’ll be able to view diffs comparing the active store to the data store so that you can see what you’ll be exporting when you click the “Write Activestore To Datastore” button, or its opposite, the “Synchronize configurations” button.

This is helpful in making sure you’re not exporting some test field you threw in or accidentally obliterating someone else’s config (which, if we’re honest, has happened to the best of us in one Features module or another).

Exclude configurations

For any environment specific configurations you don’t want to risk exporting and tracking, you can add it to the “Exclude configurations” option under the Settings tab. This is a pretty useful feature that can definitely same some headaches.

Let’s wrap this bad boy up

And there we have it–CM is a pretty nice alternative to Features. It’s certainly worth a look, wouldn’t you say?

Check out this sweet guide to solving 6 Drupal “gotchas” by our own Peter cho!

Catégories: Elsewhere

Théodore 'nod_' Biadala: Using ES5 with Drupal 8

mar, 21/01/2014 - 05:20

In fixing contrib javascript I mentioned that as a contrib maintainer or developer you could do a bit more than just run JSHint. This is because Drupal 8 will not support IE8, meaning that core and contrib are free to go crazy! The incredibly useful caniuse.com website holds extensive compatibility tables for the fancy new HTML/JS/SVG features in the works. But talking about ES5 specifically, the ECMAScript 5 compatibility table is what you’re looking for to know what you can rely on.

For core and contrib, here is a peak at what’s coming to a future near you.

Safe

By safe I mean that those are features that won’t bite you horribly. Some of them are already used in Drupal 8 core or are in a patch that’ll be committed soon enough.

"use strict"

This is actually enforced by JSHint — you know the thing that you should be running on your JS — while we’re not relying on the advanced features of the strict mode it is used to make sure there are no leaking variable. I’ve seen too many strays variable in contrib and projects. To use, put "use strict"; at the top of the file-closure.

(function ($, Drupal, drupalSettings) { "use strict"; // Your code. })(jQuery, Drupal, drupalSettings); Function.prototype.bind

It is the native version of the basic usage of jQuery.proxy().

Before var handler = $.proxy(callback, this); After var handler = callback.bind(this); Array.prototype.forEach

Looping is a rather large topic so we’ll stick with the basics. Given the following array:

var valueList = [ 'a', 'e', 'i', 'o', 'u', 'y' ]; Before var i = 0; var il = valueList.length; for (; i < il; i += 1) { } After function callback (value, index) {} valueList.forEach(callback); Object.keys

This one combined with forEach allow you to do painless filtered for each if we take the following object:

var snacks = { banana: 0, chips: 1000 }; Before for (var snack in snacks) { if (snacks.hasOwnProperty(snack)) { } } After function eatSnacks (snack) {} Object.keys(snacks).forEach(eatSnacks);

And that looks much better than the first example. Giving a name to your function gives you extra info on what is it the loop is doing without having to comment it too much. Also makes profiling easier since you’ll have data on the callback function.

Now you’ll probably ask why not use jQuery.each in both cases? or even _.each. First it’s native so there is no need for an extra library. I’m not talking about speed — if your bottleneck is how you do your loops, you don’t need to read all this, otherwise go profile your DOM manipulations. jQuery each doesn’t filter with hasOwnProperty which means that is some script on your page extends either Object.prototype or Array.prototype — on top of breaking jQuery — you’re gonna have a bad time. Underscore does filter properly so it’s fine using that if you have the library on the page anyway.

I still need IE8 support

Does Drupal 8 dropping IE: 6, 7, 8 means you can’t use it in a market like china or big administrations where IE8 is still the default and supported browser?

IE8 module

The IE8 module was started to introduce IE8 compatibility back to Drupal 8 — in fact it was started to help take the decision to drop IE8. While the level of support is still undecided the goal is to allow people who develop for IE8 to be able to use Drupal 8. We’ll see what that means when that time comes. For now you can use the ie8 tag in the issue queue to help up see what’ll go wrong on IE8.

There is a lot more good stuff we can use such as localStorage, document.querySelector but those are DOM-related and have nothing to do with ES5 so expect a follow-up post on those.

Catégories: Elsewhere

Appnovation Technologies: The Dark Side of Aggregation

lun, 20/01/2014 - 23:22
CSS and JavaScript aggregation is one of the easiest ways in all known methods to increase performance of any Drupal site. In this post I discuss how to employ aggregation as a site grows more complex. var switchTo5x = false;stLight.options({"publisher":"dr-75626d0b-d9b4-2fdb-6d29-1a20f61d683"});
Catégories: Elsewhere

Drupal core announcements: We still have numerous "fixed" D8 issues that cannot be closed until a Change Record is published

lun, 20/01/2014 - 23:06

Two weeks ago I wrote that we had 40 "fixed" issues that cannot be closed until a change record is published for them. That number now stands at 39 issues as a result of churn from a few change records being written and a couple new issues fixed and tagged for a change record.

We have documentation about how to write a change record if you have not written one before.

If you start a change record and feel that you need input from the original issue authors, you can use the original issue queue to work out a draft just like jgSnell, SebCorbin and Cottser are doing in Remove first/last/odd/even classes in favor of CSS3 pseudo selectors.

Today is a great day to become involved with getting Drupal 8 to a stable release.

Catégories: Elsewhere

Drupal core announcements: The biggest Drupal core sprint and developer camp is coming up in March!

lun, 20/01/2014 - 18:35

Drupal Developer Days 2014 is coming up quick in Szeged, Hungary from March 24th (Mon) to the 30th (Sun) 2014. Szeged, Hungary may sound like it is the middle of nowhere but what do you need to get together with a bunch of Drupal developer friends and learn about and advance the platform together? As those who have been to DrupalCon Europe 2008 in the same city know, Szeged is the ideal place for just that. Check out our interviews about those experiences.

Here are some quick facts about Drupal Dev Days 2014:

  • A whole week of sprints with two core committers (Alex Pott and Nathaniel Catchpole) as well as the testbot system maintainer (Jeremy Thorson) on location! Could we help more to make progress? Oh, most top European Drupal developers are already signed up to come as well!
  • Three days of sessions and workshops (50 topics providing 56 hours of content). Get lots of readily applicable know-how including website monitoring, e-commerce, practical scrum, Vagrant, product development in real life, Heisencache, IDE tricks and so on. Look into how Drupal is made, see the life of a core maintainer, get gamification tips or discuss a new type of money: Druplicoins!
  • Want to work on upgrading your modules to Drupal 8 but don't know how? No problem! Additionally to learning about all the new Drupal 8 subsystems, there is a bring-your-own-module workshop as well, where mentors will help you upgrade your module!
  • Want to get into Drupal development? Attend the community tools workshop and learn all the tools we use to communicate and work on solutions and learn and enjoy how the Drupal mentoring program works.

A truly fantastic opportunity isn't it? Last but not least its also very cheap. The ticket is only 30 Euros for the whole week! If you want to get to know Drupal 8 or even help make it happen, this is the place to be in March. Note that some cheap hotel deals expire this week. Don't miss out!

Catégories: Elsewhere

Pages