Skip to Content

Planet Drupal

Syndicate content
Drupal.org - aggregated feeds in category Planet Drupal
Updated: 4 hours 13 min ago

Drupal Easy: DrupalEasy Podcast 125: History of the (Drupal) World, Part 1

18 March 2014 - 6:16am
Download Podcast 125

Moshe Weitzman (moshe weitzman), one of the earliest Drupal contributors, Drush and Devel maintainer, and the Director, Research and Development for Acquia joins Mike Anello for a look back down Drupal’s memory lane. Moshe shares stories of the first publically available version of Drupal, the first DrupalCon, and how groups.drupal.org came about. As always, we also cover some Drupal-y news, share our picks of the week, and subject our guest to five questions!

read more

Categories: Drupal

TimOnWeb.com: Replacing Menu Item Visibility module with custom "in code" solution

18 March 2014 - 4:03am

I'm a big fan of fighting with Drupal's inefficiencies and bottlenecks. Most of these come from contrib modules. Everytime we install a contrib module we should be ready for surprises which come on board with the module.

Drupal Tags  drupal 7, drupal snippets, drupal planet Read on about Replacing Menu Item Visibility module with custom "in code" solution
Categories: Drupal

Open Source Training: Videos on Using Linkit with CKEditor in Drupal

18 March 2014 - 1:15am

CKEditor will be the default editor in Drupal 8 and is currently the most popular editor in Drupal 7.

However, in some respects, CKEditor isn't very tightly integrated into Drupal. For example, it's not able to access Drupal images or link to Drupal content.

The Linkit module is the best way to improve linking.

Linkit provides an auto-complete field for linking to nodes, users, files, terms, and fields. Linkit makes creating links significantly more user-friendly.

Categories: Drupal

Michael J. Ross: Drupal Flag Module Checkbox Solution

17 March 2014 - 9:09pm

By

Web users are accustomed to clicking on checkboxes, buttons, and icons to flag and unflag items of all sorts, such as favorite blog posts. The Flag module is a popular project for implementing flag capabilities on Drupal websites. Thus, it is a shame that it does not support checkboxes or any other intuitive interface elements on entity displays, but instead uses only links (as of this writing).

Fortunately, there is at least one workaround, which would be implemented on the flag admin page for the given entity type, such as nodes (admin/structure/flags/manage/node_flag): You can use characters that look like unchecked and checked checkboxes (☐ and ☑), instead of or as part of the "Flag link text" and "Unflag link text" values, respectively. These special characters are the Unicode characters U+2610 ("ballot box") and U+2611 ("ballot box with check"), and can be displayed on web pages using the HTML decimal entities "☐" (hex "☐") and "&amp#9745;" (hex "☑").

Beware that, if these characters are used alone, with no accompanying explanatory text and no helpful title attribute in each anchor's open tag, then this approach produces HTML that may not be accessible by assistive browsing technologies. But for now, it may have to do.

Copyright © 2014 Michael J. Ross. All rights reserved.

Categories: Drupal

Drupal Association News: Drupal Association Board Meeting: March 13, 2014

17 March 2014 - 4:21pm

Another month, another Drupal Association Board Board Meeting! Huge thanks to the community members who showed up in the meeting and on IRC to participate. We are very lucky to have so many active and passionate community members who help shape the direction of the Association. This month we tackled several meaty topics, made a big announcement, and more.

Categories: Drupal

PreviousNext: Drupal 8 Now: PSR-0 code in Drupal 7

17 March 2014 - 3:00pm

Drupal 8 embraces modern PHP with all the trimmings, shedding the baggage of supporting earlier PHP versions and embracing the new object-oriented features.

One such feature is namespaced objects and the PSR-0 standard for autoloader compatability.

But if you know your project will run on a recent version of PHP, there's no reason you can't write your custom modules using PSR-0 now, in Drupal 7

Categories: Drupal

PreviousNext: Drupal 8 Now: PSR-0 code in Drupal 7

17 March 2014 - 3:00pm

Drupal 8 embraces modern PHP with all the trimmings, shedding the baggage of supporting earlier PHP versions and embracing the new object-oriented features.

One such feature is namespaced objects and the PSR-0 standard for autoloader compatability.

But if you know your project will run on a recent version of PHP, there's no reason you can't write your custom modules using PSR-0 now, in Drupal 7

Categories: Drupal

PreviousNext: Drupal 8 Now: PSR-0 code in Drupal 7

17 March 2014 - 3:00pm

Drupal 8 embraces modern PHP with all the trimmings, shedding the baggage of supporting earlier PHP versions and embracing the new object-oriented features.

One such feature is namespaced objects and the PSR-0 standard for autoloader compatability.

But if you know your project will run on a recent version of PHP, there's no reason you can't write your custom modules using PSR-0 now, in Drupal 7

Categories: Drupal

Daniel Pocock: Hangouts Outage? Try WebRTC and JitMeet

17 March 2014 - 2:35pm

With Hangouts being offline right now, it might be a good opportunity to catch up on some of the exciting, free and open alternatives:

Categories: Drupal

Drupal governance announcements: Draft charter for Security Working Group posted

17 March 2014 - 12:29pm

Michael Hess, Greg Knaddison, Mori Sugimoto, Ben Jeavons, Matt Chapman, Angie Byron and myself have been working on the charter for the Security Working Group (DocWG). The mission of the SecWG is to ensure that Drupal core and Drupal's contributed project ecosystem provide world-class security, and to provide security best practices for site builders and module developers. The work is part of our work on evolving and streamlining the Drupal project's governance.

We just shared our proposed SecWG charter, which has also been run by the existing security team, and now we are looking for feedback and input from the community before formalizing it. We hope to finalize this within the next month, so that leaves some time for community feedback.

Categories: Drupal

Marzee Labs: Coding as a team: content fixtures

17 March 2014 - 12:00pm

Any frontend guy will tell you that content is very important to be able to do their thing. You cannot properly structure content display and style it without having material to play with. And there is nothing more tedious than creating fake content on-the-fly to do the job. It will end up being destroyed, and you'd have to do it again because a new field was created. How about fixturising your content and keep on iterating it?

When time comes to start frontend implementation, you will take over some structure built by the backend guy. And if you usually work on large sites, then you certainly have to deal with a bigger team. Beyond the production of CSS and JS, you will need to have some dummy content to understand how it looks on the display. But, wouldn’t it be nice if everyone in the team would be looking at the same site content? Imagine how easier would it be to reference a specific URL or part of a page when debugging. It would also allow the initial site review by the client or PM to happen much sooner, before the actual content is ready. How easier would it now be to test your app, either manually or through an automated setup! Are you nodding yet? Then let me show you how we do it in Marzee Labs as part of our Drupal development workflow.

The Migrate module

You are probably aware of the existence of the migrate module that is now part of Drupal 8 core. From the project page we can read “The migrate module provides a flexible framework for migrating content into Drupal from other sources”.

Essentially, the migrate module is a swiss army knife that allows you to insert content into Drupal. By default it can import nodes, users, files, terms, and comments; other modules can easily extend it further. Check the official module documentation for further insight.

A practical tutorial: Sample content ready on install

We’ll use a sample migrate module of our own: the MZ Migrate Example module (this module is part of our MZ installation profile).

This sample module feature defines two content types: Trappist (an exclusive Belgian Beer) and Brewery. Feel free to download and check the anatomy of this module. Don’t worry if it seems complex, we will dissect it and unveil all its secrets. You can install it directly on a drupal test site but we will also talk about a more advanced way™ later on, so keep reading!

The feature module is responsible for migrating it’s own sample content. It’s a nice way of organizing your code, keeping both the content definition and the sample content together in a single feature.

We will be focusing on migrating sample content, so open up trappists.csv under the import folder of the same module. It contains the following lines:

id,title,brewery,image,type 1,"Westvleteren XII",1,westvleteren.jpg,Other 2,"Chimay",2,chimay.jpg,Dubbel|Tripel

Breaking it down you have:

  • An ID of the content
  • The title
  • The ID of the related brewery, this is not the final node ID, but an internal ID we use to reference content via these CSV files
  • The image file name, under import/files
  • The taxonomy term, with support for multivalue, in this case separated by the | character.

This is a simple CSV file. In complex content types with several fields and multiple references it can get more confusing so you can use a spreadsheet tool for editing.

So, now that we have some sample content, we need to define how to import that content. In the file mz_migrate_example.migrate.inc you’ll see we have declared a migration class for each content type: MZBrewery and MZTrappist.

trappist.inc defines the actual migration code. You’ll see that we prepare the migration of several field types: text (either title or body), references to other migrate content (e.g. the Brewery the trappist beer is associated to via an entityreference field), some images, taxonomy terms and the author (with default uid = 1):

For example, here is a simple field mapping:

// Title $this->addFieldMapping('title', 'title');

and a more complex one:

// Image $this->addFieldMapping('field_trappist_image', 'image'); $this->addFieldMapping('field_trappist_image:file_replace') ->defaultValue(FILE_EXISTS_REPLACE); $this->addFieldMapping('field_trappist_image:source_dir') ->defaultValue(drupal_get_path('module', 'mz_migrate_example') . '/import/files');

That’s it, you are now all set to import that content.

Import that content!

You can import the sample content through the migrate UI in the backend, at /admin/content/migrate or using drush.

If you are using the stand-alone example module you can use the following drush commands to test it:

drush en mz_migrate_example drush cc all drush mi MZBrewery,MZTrappist

You can find more information on drush migrate commands and a discussion on why you should use drush instead of the backend UI to use migrate here.

But that’s just beginning

Doing it all automatic now… aka the More Advanced Way™

As I mentioned above, there is a more advanced way™, and that is using Phing. What is Phing you ask? For the more distracted of you, we wrote a blog post on how to automate development using phing.

The integration is pretty simple: whenever the database is rebuilt there is some sample content ready to be used. The best part of this is when a fellow team mate goes in to review your feature, jumps into the branch you are working on and only has to do a phing build. Your team mate will then have the sample content ready to test your feature, because while building the feature you’ve been updating that magical CSV file for the migrate procedure, right? Of course you have!

On a more personal note, as a frontend guy, but also as a site builder, sometimes I had to add fields to features and I was a bit lost in the beginning looking at the migrate.inc files of the features. That’s when I remembered that Drupal has great documentation. In this particular instance I needed to add sample content to a multivalue link field, I checked link.migrate.inc and saw in the comments how to import links automatically. Easy, isn’t it?

How could I live without this?

Your frontend folks will love it and they will also start doing it themselves. Besides having the same code base, better yet is to always have the same sample content to play with as you build the website. And all of it done automatically, with phing to the rescue! Speed up the process, and manage short deadlines better by using content fixtures from day 1. Working as a team is great, and with this workflow it just got easier!

Have you got similar experiences, or totally different approaches on how you manage your test content? Drop us a line in the comments below, let’s start a conversation.

Featured image credit: Quantum_Kitten / Flickr

Categories: Drupal

Stanford Web Services Blog: Creating a Static Copy of a Website

17 March 2014 - 10:09am

The modern Web is a dynamic place. However, sometimes it's necessary (or desirable) to remove the dynamic functionality of a website, while preserving its static content.

Inspired in part by Karen Stevenson's excellent blog post, "Sending a Drupal Site into Retirement," I wanted to outline a few other techniques for accomplishing this.

Reasons you may want to create a static copy of a site:

Categories: Drupal

Appnovation Technologies: 5 of the Best Designed Magazine Websites

17 March 2014 - 9:53am
In the age of fast-paced news and social media there are still some who look to their favourite magazines to stay up to date with their news and events. Luckily, some of the most well-known magazine brands have made it easy to look for the same information, but through the web. The following are some of the best designed magazine websites on the internet. var switchTo5x = false;stLight.options({"publisher":"dr-75626d0b-d9b4-2fdb-6d29-1a20f61d683"});
Categories: Drupal

InternetDevels: SEO-modules for Drupal 7 to make your site better

17 March 2014 - 6:47am

If you want your Drupal-site to fit all SEO demands there are hundreds of out-of-box modules on drupal.org. Previously we have described the most important SEO modules. This time we will provide you with the list of modules one can hardly call ‘must have’. However your website will gain additional benefits if using them in a right way.

So let’s review these modules.

Read more
Categories: Drupal

Drupal Association News: Debuting a Drupal Camp, Uniting a Community

17 March 2014 - 6:43am

Fresh off the train from Fort Wayne, Indiana, Andrea Soper hit Chicago with eyes full of big city excitement. The opportunities seemed as endless as Lake Michigan.

Categories: Drupal

Commerce Guys: Guest Blog: eCommerce for Manufacturers Part 2: Sales & Marketing

17 March 2014 - 5:00am
The second in a three part series on "eCommerce for Manufacturers" from Alex Salvador of Drupal Commerce Delivery Partner The Jibe

In last week's post, we discussed product customization, discounting, and inventory management. This week, we touch on how eCommerce changes can bolster sales and marketing initiatives.


Sales Representatives

Sales Representatives have been forced to change their methods in today’s digital marketplace. They now work in a cross-functional team composed of digital marketing and web development departments to engage with their contemporary audience. From the perspective of the sales team, eCommerce is a great resource for detailed customer account information. Manufacturers face customers that are empowered, connected, and expect a buyer-centric approach to online sales. In some cases, having a buyer deal with a manufacturer’s sales representative and browsing through a manual is unnecessary–they could be using an efficient online catalogue which allows them to buy without human intervention.

Although more technical products may require a person-to-person discussion, simpler products which do not require much support make good candidates for online sales. Enabling online sales for a subset of these products allows the organization to ease into the eCommerce marketplace, simplify the buying process, and reduce paperwork.


Social Media

Online commerce improves marketing reach and increases brand awareness and loyalty through enabling promotional offers and social media campaigns. Integrating community into an online sales framework takes advantage of social proof, and provides customers with the tools to market to their network on behalf of the brand–social sharing icons on product pages are a must. For example, Pinterest is a likely community to share an image of a home improvement product.


Analytics

A major incentive for manufacturers moving to an eCommerce system is the value provided by web analytics. Manufacturers can obtain information on campaign performance, site effectiveness, conversion, sales and other user behaviour. With this data, they can zero in on what their customers are attracted to, and market intelligently on upsell opportunities.

eCommerce has become a must for retailers of all sizes and markets. Flexible and scalable platforms such as Drupal Commerce allow for a highly customizable sales system, and a truly productive end-user experience. There is nothing preventing the manufacturing sector from moving online.
 

Read last week's post on Product Customization

Upcoming in our eCommerce for Manufacturers series: Customer Experience.

 

Categories: Drupal

Mark Shropshire: Drupalcamp South Carolina

17 March 2014 - 4:20am

When I first heard that the a number of Drupalers in South Carolina were planning a camp, I was excited, but knee deep in organizing the Charlotte Drupal-Drive with Thomas Lattimore. All I could do at the time was mentally commit to going.

Now that Drupalcamp South Carolina is a little more than a month away, I am getting very excited about it. It is nice to have a local camp to tide me over until Drupalcon Austin.

The camp is happening on Saturday, April 19th at IT-oLogy in Columbia, SC. Pre-camp training will occur on Friday, April 18th, featuring beginner Drupal and Commerce Kickstart classes.

Drupalcamp South Carolina will feature a keynote by Ryan Szrama, of Commerce Guys, and a day of sessions covering a wide range of Drupal related topics. Session tracks include, beginner, design/ theming/usability, and development & performance. Following a full day of sessions, attendees are invited to the after party, which will be held at Five Points. If you can allocate time Sunday, there will be an after-camp outdoor adventure (more details to come).

Session proposals are now in full swing. Make sure to register for the camp and propose a session. Presenting at a camp is a great way to share your passion for Drupal.

If you want to attend Drupalcamp South Carolina, register today while early bird registration is still $20. If you have interest in sponsoring the camp or have any other questions, contact the camp organizers on the Drupalcamp South Carolina contact form. As always, thanks to the fine sponsors for helping make the camp happen.

I hope to see and meet you at Drupalcamp South Carolina!

Blog Category: 
Categories: Drupal

Wunderkraut blog: Going beyond the permissions page for nodes and fields in Drupal 7

17 March 2014 - 2:30am

Today, I will talk a bit about access control. Specifically, what options you as a module developer have for controlling access to nodes and individual fields. As I'm sure you agree, the Drupal permission system available for site builders is powerful. Yet, fringe cases occur that leave this system wanting. It's a case like this I will talk about below.

The context

The Drupal core permissions system for site builders is very flexible. You can control what kinds of access user roles have over the content (nodes). This means that you can grant users of a particular role the following permissions (to):

  • Create new content
  • Edit own content
  • Edit any content
  • Delete own content
  • Delete any content

And these permissions can be further targeted towards specific content types. So for instance you can have users of a certain role create Article nodes but not Basic pages.

The requirement

With these permissions you have a lot of ground covered. But there are cases in which you'll need to write some code to account for what you need. Let's look at one of these cases, albeit simplified for this article.

Users of the roles Supervisor can create articles. They can then edit all Articles that other Supervisors created but not the ones they themselves created. And herein lies the problem. With the Drupal permissions page alone, you just can't get there.

If Supervisors can edit all Article nodes, that includes also the ones they created. So how to tackle this problem? Using hook_node_access() in your custom module.

The solution

So what can you do with this hook? The short version is that you can control access to nodes.

This hook gets called by the node access system to determine if the user that wants to see the node being loaded, should. Using this hook, the system checks if there are any modules that actively want to grant or block access to the node in question. Let's see how we can implement this to solve our problem:

/** * Implements hook_node_access(). */ function module_name_node_access($node, $op, $account) {   // If Supervisor, do not allow to edit their own node. if ($account->roles[3] && $account->uid == $node->uid && $node->type == 'article') { if ($op == 'update') { return NODE_ACCESS_DENY; } }   }

Let's do a quick rundown of what happens in this code. The function takes three parameters: the $node object being loaded, the $op (operation) being performed and the user $account object trying to access. All the right ingredients basically.

First, we perform three checks in an if conditional. We check if the current user has the Supervisor role. We know that this role has an id of 3. Then we check if the id of the current user equals the one of the author of the node being loaded. Finally, we check if the node being loaded is an Article.

If these three checks pass, we move on to the operation. There can be 4 different types of operations: create, update, delete and view. We check if the operation being performed is update, and if it is, we return the NODE_ACCESS_DENY constant to deny access to the user. Not so complicated.

This will therefore deny access to the node author if s/he wants to edit it. However, this will not stop him or her from viewing the node or even deleting it. But you can perform logic that will help you control that as well if you want. And even more complex stuff like access depending on relationships between users. But again, story for another day.

Granularity

To illustrate a slightly more complex case, imagine that our Supervisor should be allowed to edit his or her Article, but not all fields on that node. Field X must be visible but impossible to update. However, the Supervisor must be able to edit Field X on all the other Articles.

In this case, our implementation of hook_node_access() won't do the job since it controls access to the entire node. We'll need a more granular approach, provided by, you guessed it, hook_field_access().

Before explaining how this works, I want to point out the existence of the great Field Permissions module. Using this module, we bring the power of the core Drupal node permissions down to the level of fields. Which is awesome. However, we are restricted in our case by the same implication of granting a role the permission to edit all content of a certain type. So let's see what hook_field_access() brings to the table.

The function works similarly to the previous one, but it takes different parameters. You have again operation ($op) which only includes view and edit in this case. Then you have the $field on which the operation is performed. The third one is the $entity_type the field is attached to, which means using this hook is not restricted to nodes only. Then you have the two optional ones, the $entity object itself and the user $account that tries to access.

And yet again let's see some code that will help us with our slightly more complex case:

/** * Implements hook_field_access(). */ function module_name_field_access($op, $field, $entity_type, $entity, $account) {   // If Supervisor, do not allow to edit Field X on their own Article if ($account->roles[3] && $account->uid == $entity->uid && $entity_type == 'node' && $entity->type == 'article' && $field['field_name'] == 'field_x') { if ($op == 'edit') { return false; } } }

In this function you'll notice a similar logic but oriented towards the field. We check if the accessing user is a Supervisor, if they are the author of the entity, if the entity type is a node, if the node type is an Article and if the field requested is named field_x. If all these are true, we move on to check the operation and return false (no constants here) to deny access to this user from editing the field (if $op == 'edit').

So what happens in practice? The user can view the Article s/he created. But if s/he edits the Article, Field X is hidden. If the user then goes to edit the Article created by another user, s/he can edit Field X. Neat.

One thing to note here is that since hook_field_access() has only 2 types of operations, if you check against edit, you'll deny access to the user even when first creating the node. To circumvent this behavior, you can perform an additional check. In addition to ($op == 'edit'), you can check also if the $entity in question has an id set. Since we are talking about nodes here, you can replace this line:

if ($op == 'edit') {

With this:

if ($op == 'edit' && isset($entity->nid) {

This way, if the node is not yet created, the user can work with Field X. But as soon as the node has been saved, the values of Field X can no longer be changed by this user. But this of course depends on your needs.

Conclusion

To recap, we've seen above how to control access to nodes and fields in a custom module. All you have to do is implement these hooks (as needed) and perform your logic inside. One thing I urge you though is to always document properly this kind of code to make it easier to understand later why certain users have what can seem inexplicable permissions.

Another interesting thing we've seen is that even one of the most powerful features Drupal has cannot account for all real life cases. But not to worry, under the hood, Drupal allows us to customize its behaviour with just a few lines of code to meet our exact requirements. And be honest, was that complicated?

Categories: Drupal

Drupal core announcements: Drupal core security release window on Wednesday, March 19

16 March 2014 - 8:34pm
Start:  2014-03-19 (All day) America/New_York Sprint Organizers:  David_Rothstein

The monthly security release window for Drupal 6 and Drupal 7 core will take place on Wednesday, March 19.

This does not mean that a Drupal core security release will necessarily take place on that date for either the Drupal 6 or Drupal 7 branches, only that you should prepare to look out for one (and be ready to update your Drupal sites in the event that the Drupal security team decides to make a release).

There will be no bug fix release on this date; the next window for a Drupal core bug fix release is Wednesday, April 2.

For more information on Drupal core release windows, see the documentation on release timing and security releases, and the discussion that led to this policy being implemented.

Categories: Drupal

Colan Schwartz: Talking Performance at DrupalCamp Ottawa

16 March 2014 - 6:56pm
Topics: 

I'd like to thank all of the DrupalCamp Ottawa organizers. Everything appeared to run smoothly, and there was a great turnout for the second annual event.

I gave a presentation on Drupal performance to a completely-packed room. Either the subject matter interested a lot of people, or the room was too small. From my perspective, it's difficult to say which, but I'd like to think my topic was something folks wanted to hear.

As promised, my slides are now available on this blog post and the session page.

If you missed it, I'm planning to give this talk again at the Western NY State Drupal Mini-Camp, and if it gets accepted, DrupalCon Austin. If you'd like to see it there (or can't make it, but still think it's a great topic), please show your support by commenting on the session page. Hopefully, this will persuade the track team to accept it!

File(s):  2014-03-14 - DrupalCamp Ottawa - Performance Optimization Options & Checklist.pdf
Categories: Drupal


about seo