Feed aggregator

This week's podcast features two Drupal Scots: Duncan Davidson (recorded live in a back alley right after Drupal Camp Scotland 2013) and Brian Ward (recorded via Skype, post-event). Duncan is the Scottish regional manager and UK Professional Services Manager for i-KOS and Brian is a developer at heehaw.digital in Edinburgh.

duncan-n-brian_final.mp3

DrupalCon Portland will be happening in a few weeks and, as usual, Lullabot will be out in force. Our entire team will be there and we'll be spending our days training (4 classes) and presenting (8 sessions). We'll also be hanging out at both the Lullabot and Drupalize.Me booths in the exhibit hall. As usual, we've got a lot going on.

As part of the Diamond and Platinum sponsorships for DrupalCon Portland, we've offered leaders at these sponsor companies the opportunity to guest blog on the Drupal Association site. In today's post, Robert Douglass of Commerce Guys takes a look at where Drupal is today, and the untapped opportunities for Drupal growth in e-commerce.

Personal blog tags: sponsor blogDrupalCon Portlandguest blog

There are currently 98 new Drupal contributors awaiting review of their first project. This is a great place to contribute to the community and learn about interesting upcoming projects, for example...

Module: Content Reminder What does it do?

Publishing content feels great. There's a sense of accomplishment and it's there for the world to see. However, that content oftentimes needs to be checked on and updated. Instead of letting a page languish, alone and forgotten, you can use the Content Reminder module to set up reminders to check on it.

Content Reminder adds a notification tab to each node, allowing a user to create a notification to be sent to a site's user with a customizable message and date upon which it should be sent. Now you can ensure that your site's content is fresh and relevant, not forgotten.

Zoom Look Useful? Review it!

If you would like to see this module readily available on Drupal.org, you should review it and help make that happen.

Review It

Pro Tip: If you've never reviewed a project application before, you can find instructions for reviewers on Drupal.org and the Code Review group is happy to help more people get involved.

This is a guest post by Mathew Lowry from Intrasoft International. We suggested him to write this post as a preparation for a BoF session his colleague will be organizing at DrupalCon Portland. If you are working on a Drupal platform for government or for a bigger organization that wants to standardize on Drupal as a communication platform for a series of its departments, and if you are attending Drupalcon Portland, come and join us to discuss best practices and lessons learned.

The European Commission recently launched a pilot Multisite Drupal7 Platform. Intrasoft Labs is organising a BofSession at DrupalCon Portland 2013 to explore the issues surrounding transforming Multisite Platforms into massively multilingual corporate CMS.

Sign up to today's Views Mini-Course, Part II: Creating Flexible Views with Drupal 7. When the recording is available, I will update this post with a link and the slides!

I recently went through the process of contributing my first Drupal 7 module, and while the process isn't too hard there were many things that would have been helpful to know at the start rather than finding out half way through the process. As a result of my experiences I've decided to put together this blog which covers many of the common pitfalls people run into and provides a collection of useful links to various bits of documentation on Drupal.org.

How It Works

When you first register at drupal.org you will only be able to create sandbox projects, once you've created your first sandbox project you will be able to apply for full project access. Applying for full project access means your sandbox project will have to go through a review by the community, once that's approved you will gain full project access and wont have to get any future projects reviewed.

Getting Started

The first thing you'll need is an idea of what the module you want to create will do, once you've come up with the idea check that there aren't existing modules that do the same thing and make sure what you are trying to do should be in its own module and not just part of another existing module. If your module is too similar to an existing module then your project application will be declined, and any hard work you've put into the module will have gone to waste. For more information on duplicate modules see collaboration rather than competition.

Creating a Sandbox Project

Creating a Sandbox project is fairly straight forwards, but be sure to check out tips for a great project page or for even more project page tips How to make your module description useful. Your project application may be delayed if the description of your project isn't sufficiently detailed.

When setting up Git for your new sandbox project if you follow the instructions provided you will end up with a master branch, unfortunately this isn't actually correct, Drupal requires that you work out of a major version branch (7.x-1.x for example) instead of master. You will need to change this before your project goes for review, read through Moving from a master to a major version branch to find out how to do this.

Coding Your Project

Getting your code to meet the standards expected by Drupal is quite easy, it does however involve reading through a lot of documentation, these are the bits I found most useful:

• Coding standards
• Commenting standards
• Writing secure code
• Module documentation guidelines (also see README files)

Once you've read through the above and written some code there are some handy tools available to check that your code complies with Drupal's standards:

• The Coder module which checks your module code on your local Drupal installation.
• ventral.org which can be used to test your code once it has been pushed to the repository on drupal.org.

If either of the above tools pick up any errors they will be brought up in your project application, and you will be expected to fix them however trivial they may seem.

 

Applying for Full Project Access

Before you apply make sure you check that the sandbox module you are going to apply with meets all of the requirements listed in the Project application checklist, also note you can only apply for full project access with one sandbox module.

When you're ready to apply for full project access read Apply for permission to create full projects for guidance. Once you've done this you will need to obtain a review bonus. Although the documentation suggests obtaining a review bonus is optional in practice, it truly isn't if you want your module to be reviewed in any sensible amount of time.

To get the review bonus you will need to review three other modules, see Review bonus for guidance on how to do this. Make sure that your review of the other modules is sufficiently detailed as your review will not be counted if it's just a copy of the results from ventral.org.

Once you have your review bonus add the tag and you should find your module being reviewed shortly after. Note though if any major issues are found you will not only have to fix them but will have to re-earn your review bonus so it's well worth reading the standards documentation etc... beforehand as it will probably save you time in the long run.

 

Good luck with your module!

Over the years, I have noticed a significant increase in the need for businesses to create user dashboards from which their customers are provided account details, up-to-date reports, downloadable documents and other important information. As more clients ask for user-driven websites that provide user-specific information, the need to relate or reference various types of content/data together is becoming commonplace.... Read more

Download Podcast 105

Bob Kepford (kepford) from The Weekly Drop joins Andrew Riley, Ted Bowman, and Mike Anello to talk about how Bob mines nuggets of Drupal goodness from the weekly Drupal firehose. Other topics discussed include Panopoly, open-source project statistics, the impending Google Reader apocalypse, Open Atrium 2.x, and a bunch of other mostly Drupal-related topics.

read more

Views is a great module and as you'll probably know it is the most downloaded module in Drupal's history. The possibilities which Views provides you with are almost endless but there is one limitation. The generated output of a view is by default static. What if you want to have a dynamic activity stream as you know it from Twitter or Facebook?

Allow Drupal's unofficial slogan to answer that question: There is a module for that! The module in question is "Views Hacks" and contains another module called "Views Auto-Refresh". There is a blog post about how to implement this module in order to get it to work as you want to, but it seems like this post doesn't cover all of the aspects that are implemented in the "dev"-version. A follow up blog post offers a little more insight, but still not everything I needed.

On a side note: In this tutorial we will use the "dev"-version of "Views Hacks", because the alpha was buggy at the time, and the implementation of the JavaScript part is not in the Drupal way anymore.

Preparation

Let's get started with the implementation. I assume that you have downloaded, installed and activated Views, Views UI, Views Hacks and Views Auto-Refresh. Further I assume that you have created a view for which you want to use the auto-refresh feature.

I will demonstrate the implementation of Views Auto-Refresh by showing screenshots of the actual project.

Implementation

Make the following configurations:

• First of all, you need to duplicate your actual view as a view page. Give it a semantic name like "autorefresh".
• Give the page a unique path as displayed in the screenshot above.
• Also give an easy-to-remember machine name.
• Make sure that the view is using AJAX.
• Add the Content: Post date (with operator) or any other timestamp as a contextual filter (we used the "Content: Updated date"). Views Auto-Refresh will provide the timestamp needed.

Now head over to your view and add a "Global: Text area" with the text format "PHP Code" and add following code:

<?php print theme('views_autorefresh', array('interval' => '30000', 'incremental'=> array( 'view_base_path' => 'frontpage/autorefresh', 'view_display_id' => 'autorefresh', 'view_name' => 'articles', 'sourceSelector' => '.view-content', 'targetSelector' => '.view-content', 'firstClass' => 'views-row-first', 'lastClass' => 'views-row-last', 'oddClass' => 'views-row-odd', 'evenClass' => 'views-row-even', ))); ?>   As you can see, there is a base path and a display ID.
The base path equals your defined page path, and the display ID equals the Machine name of the auto-refresh View. "interval" defines how often the auto-refresh View is being called while "view_name" is the machine name of the actual view.

The additional settings are the selectors and classes which will be addressed by the JavaScript of Views Auto-Refresh. I don't want to dig too deep since they should be self describing.

Now you might think that everything is done. But no, wait, we have to add the same code to the header of your original view. So do the same thing there as I have described it above. Please make sure that this view also uses AJAX, else it wouldn't work.

Further possibilities

In our project we use the jQuery library Isotope which sorts all the posts dynamically on loading or resizing. But you have to trigger the re-layout of the page if the Views Auto-Refresh has delivered some new posts. This is really simple and straight forward. You just have to add a Drupal behavior in your JavaScript like this:

/** * Add functionality to trigger reloadItems after an autorefresh */ Drupal.behaviors.triggerIsotopeAfterAutorefresh = { attach: function(context, settings){ $('.view-id-articles').bind('autorefresh.incremental', function() { //getting the content/context $isotope = $('.view-id-articles .view-content'); //reload all items by original order $isotope.isotope( 'reloadItems' ).isotope({ sortBy: 'original-order' }); }); } }

As you can see, you can just bind the event 'autorefresh.incremental' to execute your own code. 'autorefresh.incremental' is fired every time the Views Auto-Refresh module loads the designated view.

Conclusion

After a few trial and error attempts, I finally figured out how Views Auto-Refresh really worked. There is a lot more to this module that isn't documented. So it is much more powerful than I can describe in only one blog post. So go on and give it a go.

 

Drupal 8 may seem a long way off but we are approximately 6 months away from its target release date in fall 2013. Though Drupal 8 won’t be released until all critical issues have reached zero (Are you helping get there?) there are things you can do now with your Drupal site to prepare for Drupal 8’s release.

During development of the pgbar module I often ran into Notices for something in $items. This time I said to myself: Let's get this straight once and for all. So I've inserted some debug code into my module to track which field related hook can manipulate data and in which order they are called. You can see the result in the dot-graph at the bottom.

Tags:

• Drupal Planet
• drupal7
• fields

Walkthrough.it

• What is walkthrough.it?
• I heard that this works with Selenium in the background
  • What is Selenium?
  • How does Selenium make this awesome?
• How is this related to the Tour module in Drupal 8 core?
• How do you record walkthroughs?
• How do you play walkthroughs?
• You recently finished a crowdfunding campaign on IndieGoGo, can you tell a bit more about
  that?
• What things did you promised as part of the campaign?
  • WalkHub: walkthrough server distribution,
  • Walkthrough module for Drupal
  • really awesome t-shirts
  • WalkHub.net: GitHub for interactive tutorials
  • An iPad application with introductory tutorials for Drupal distributions

App

• What is this iPad app for?

Drupal Module

• Can you tell me a bit more about the Drupal module?
• Will there be versions for both Drupal 7 and Drupal 8?

Grand prize: documentation of a distribution

• You promised that you would document 1 distribution with walkthroughs if your IndieGoGo
  campaign would be a success. Do you already know which one will win?

Recently the company I work for shifted the bulk of our instant message communications over to Campfire, and established a series of rooms to discuss our various projects. This transition seemed to go fairly well, once everyone settled on their preferred client interface. I was used to using IRC and found a nice little Ruby gem that piped Campfire through my IRC client. Chatting in this environment quickly had me missing Druplicon, the friendly Drupal fueled chat bot that tirelessly serves the Drupal IRC community. I decided to look for a replacement, and after some searching I stumbled upon Hubot, a Node.js powered chat bot. It was initially built by the folks at GitHub and includes a long list of plugin scripts added by community developers. This was immediately appealing for several reasons:

• It is built using Node.js
• It is written in Coffeescript (something I have wanted to try my hand at for a while)
• Additional scripts appeared easy to write, and plugin simply
• It has built in Campfire integration

So I installed Hubot on a small server, with a handful of scripts that I thought would be useful and fun for our team. Adding the bot to our Campfire rooms was fairly painless, and after writing a small init script we were good to go. This sparked some discussion among our team about how the bot was deployed, cool ways it could be extended, and methods of use. A fellow developer, David Fells, mentioned that it would be handy if we could tell Hubot to execute Drush commands. This gave me pause, and after a quick:

"That's a great idea! You mind if I implement that?"
"Sure, go for it."

I found myself firing up my editor, trying a few test methods, and reading up on CoffeeScript. Things moved fairly quickly, once I got going. I realized child_process.spawn()was going to be my friend, a core Node method that I had yet to use. Generally CoffeeScript proved to be the biggest challenge. While writing the initial prototype I actually used a JavaScript to CoffeScript translator and was cursing the whole time. However, by the time I was putting the finishing touches on my methods and objects I found myself smiling as I wrote in this almost comical syntax. Simply put, CoffeeScript is fun! I still find myself favoring the comforting structure of the curly braces and semicolons when working with JavaScript, but now that all seems somewhat gray and drab, knowing there is something much more playful out there.

As you can imagine there were, and are, several security concerns. The early prototype actually had user commands pipe right into Drush which is a security nightmare. Any user with access to the bot could escape or pipe in any old Bash command directly through the bot. Further, any Drupal installation that Drush is aware of would be at the mercy of users who may or may not have the best intentions at heart. Needless to say this approach was quickly abandoned in favor of a hand picked list of commands made available to the bot. This caused the code to be a bit more tedious, and likely less elegant, but I needed to insure that Drush would be executing the allowed commands, and nothing more. After some discussion I also decided to weed the available commands down to a relatively innocuous set (giving information vs. actually changing something). I attempted to structure the code in a way that it would not be difficult for another developer to add commands. Overall, I'm pretty happy with the end result, and the pull request was soon accepted. You can find this script along with all of the other Hubot scripts on GitHub.

tl;dr If you're looking for a fun chatbot for campfire (or otherwise) check out Hubot and enable drush.coffee if you'd like that bot to have cool Drush functionality.

 

In this tutorial we will be looking at how we can allow multiple file upload in drupal. To achieve this, we will be considering the plupload module. Plupload is a GPL licensed library used for multiple file uploading The plupload module allows backwards bend in other to achieve cross-browser compatibitility. using HTML5, flash, silverlight and even the classic HTML4 depending on the clients computer resources.   Modules used for this tutorial.   Filefield sources Filefiled sources plupload plupload

One time consuming task for all software users is testing.

It takes time to find all the download links, to set up a test environment and to install all the additional software you need.

Simplytest.me is an ingenious solution for Drupal. Simplytest will install Drupal sites for you and also install and modules and themes that you want to use. Here's a brief introduction to this very useful site.

One of the best things about Drupal is the ability to flexibly manage your content. If you're coming from a WordPress background, you'll know that system uses the Post and Page for its content types. In Drupal you have something similar in the Article and Basic page, but also an easy to use interface for creating a virtually unlimited number of other content types.

Before we get into the how, let's briefly discuss why we would want to use custom content types. Some of you may be thinking to yourselves that you've been getting along very nicely without additional content types. Whenever you've needed to organize your content, you've always had your taxonomy terms handy.

Although taxonomy terms (the equivalent of Categories in WordPress) are very useful, they don't solve the same problem as content types. Let's break away for a moment from the idea of our site consisting of pages and instead think of it as being comprised of objects. Of course we still have objects we call pages, but we may also find that our site has other types of objects like products, events, and forum topics.

Ultimately, all of our objects may be expressed as web pages, but they represent different types of things. We can use Drupal's custom content types and the Fields UI to define these objects and give a more logical structure to our site's content. 

Now you may be asking about those taxonomy terms...where do they fit in? Taxonomy terms simply help us differentiate between the variations we find within our objects. For example, a bicycle and a shirt are both products, but certainly quite different. So we can use taxonomy terms to essentially create sub-categories within our content types. In a future lesson in this series we'll take a closer look at taxonomy in Drupal.

Creating a Custom Content Type

Now that we have an idea of why we would want a new content type, let's create one called "Product" for our example site. We'll begin by going to Structure > Content types. You should see something like the screenshot below.

You'll see a link at the upper left that says, "Add content type". Go ahead and click that link. You'll be directed to the screen below where we can define our new content type.

The name and description fields are pretty self explanatory, but we'll briefly go through the other fields in the tabs at the bottom of the form.

Submission form settings
You see three settings under this tab. The first is "Title field label". This is what content creators will see when creating a new piece of content and by default it's set to, "Title". Frequently with custom content types, this isn't as descriptive as we would like. In our case we should change it to something like, "Product name". 

The second setting controls preview options and the last one allows you to create a message that will be displayed at the top of the page providing submission guidelines. This can be very useful if the content type you are creating will be user-generated content.

Publishing options
These setting help you determine the default status of the post when you click 'Save'. For example, should the post be automatically published? Should it be promoted to the front page? If you have the Revisioning module installed you will also see options for creating a new revision - very handy if you want to be able to roll back any changes.

Display settings
You can disable the display of the author and post date information by unchecking this box.

Comment settings
This is where you can adjust the settings for the comments on your site. I personally recommend you consider disabling Drupal comments and use a third party commenting system. I've talked about this in a recent post, but suffice it to say there are significant advantages to not using Drupal's built-in comments.

Menu settings
With this setting, you can optionally make your content assignable to the any menus you may have created for your site.

XML sitemap
This setting isn't present in Drupal by default, but is found in our example site because using a sitemap is such an important - and in my view, fundamental - part of building a website. However, there are times when you may not want a content type indexed by search engines and here is where you can disable that if needed.

Custom breadcrumbs
This is another one that isn't included by default with Drupal, but also very useful for most sites. It exposes the custom breadcrumb information on the node edit form. 

For most of these settings, we'll stick with the defaults. Once we've given our content type a name we'll click the "Save and add fields" button at the bottom of the form. You should then see something similar to the image below.

The Fields UI

The image above is the Fields UI, the administrative interface for adding and configuring the fields for your content types. There are a few fields here that have been added by modules that are installed with the example site (Meta tags, for example) and two that are included by default by Drupal. The default fields are Title - in our case renamed to Product name - and Body.

What we're going to do next is add a new field. Since we're adding a content type for our products,  Price seems like a logical field to start with.

You'll notice in the area highlighted in green how we have the form filled out. Our Field type is set to decimal and we've chosen a text box for the widget - aka input element -  that will appear on the node create form for our content type. Let's go ahead and click Save to continue.

The next screen (not shown) allows us to set the precision of our decimal number as well as how many digits should be to the right of our decimal point. We've kept these at the defaults and continued to the screen below.

We won't go over each of these, but an important point to keep in mind is that these settings will change depending on the content type you set for the field. For example, if you chose the field to be an image, you would have settings for allowable formats, maximum and minimum sizes, as well as for which image style you wanted to use.

In this particular example, one field we may want to change would be the prefix. Maybe setting it to the dollar sign (or pound, euro, etc.) might be a good idea. Let's do this and then click save. You'll then see that our field has been added to our content type and we can change its position on the node create/edit form by dragging it up or down our list of fields.

Before we move on we should briefly note that you can also reuse fields that you may have defined previously using the, "Add existing field" component. One situation where this may come in handy is for an image field. Instead of having multiple image fields, you could reuse a single field for all of your content types and control the display of the image using image styles. Sometimes this may not be what you need, but in general it's a good practice because it will make things less confusing as your site grows in complexity.

Managing Display

The final thing we'll discuss is managing the display of our fields. You'll see a tab on the page titled, "Manage Display". The settings on that tab are pretty straightforward so I won't go into too much detail, but something that new site builders sometimes do is forget to hide the display of the label for certain fields, in particular, those for images. This tab is where you can remove the label for those images as well as other aspects of how the fields for the content type will be displayed on your nodes (aka web pages).

That's it for our discussion of content types and the fields UI. There is a lot going on, but fortunately it is pretty intuitive to use, particularly once you've got a handle on what is happening conceptually. Next time we're going to take a look at using Views - a big and very important topic! If you'd like to keep up to date on this series, you can subscribe to the RSS feed.

In the meantime, if you'd like to comment on this post, you can do so on this discussion forum.

I am sick and tired of hearing that the Drupal learning curve is a much steeper than the WordPress learning curve. The reality is, both platforms are starting to converge in several areas.... Read more

Nowadays Drupal Services support becomes stronger and more flexible. The main functionality is provided by Services module. You can find more than 1300 modules tagged with “services” that is more than enough :).

Out of the box services provides just REST/RCP server and pure documentation of available options. But sometimes we need to build Client instance to retrieve data from another Drupal env that provides for example RESTful server. You have some ways to implement it:

• Custom handmade solution, built using services source only
• Use “Services Documentation” or “Services API” modules to get more useful info to build your own handmade Client instance :)
• Use contrib modules which provides already created Client instance like Services Client or Services Guzzle!

I prefer to use ready, tested solutions, not to reinvent the wheel and save my time :) Meet Services Guzzle module. It brings power of Guzzle framework to Services module, also Guzzle is already part of D8. The module provides three things:

• Generate Guzzle Service Description from endpoint definition.
• Example of Guzzle Client instance implementation and usage.
• GUI for Client debugging

 

Guzzle Service Description

Guzzle has really amazing feature - factory method to create Client instance from Guzzle description. You can read about it here. So the main job of our module is generate this description for particular endpoint object. For example we have endpoint “Node service” that provides all node operations: retrieving, creating, deleting, etc. SG (let make a shortcut for Services Guzzle module) create an additional tab for endpoints that looks like:

Here we can see Guzzle version of endpoint object in JSON format, that is even human-readable :) Now we have two ways to create a Guzzle Client (see on DrupalServicesClient class in the services_guzzle_client submodule):

• Create service.json file and put Guzzle description json string there, then this lovely piece of code will create ready-to-work instance: $client = \DrupalServices\DrupalServicesClient::factory(array('includes' => array($path_to_json . '/service.json'));
• Provide array with this description and use $client = \DrupalServices\DrupalServicesClient::factory($array_of_service_description);

That’s all, now you have full Guzzle Client object!

 

Guzzle Client usage

Now when we have a Guzzle Client lets see how it works. If you return to Guzzle endpoint service description json you will find array of operations like "NodeOperationRetrieve" or "NodeOperationCreate". Inside every operation there are some other options, but now we need only “parameters”. So for NodeOperationRetrive we need name of operation and param - “nid”. Lets use our Client to retrieve a node:

$arguments = array('nid' => 1);
$command = $client->getCommand('NodeOperationRetrieve', $arguments);
$response = $client->execute($command);

And if node with given id exists we will get node data into $response variable. Did you notice that it is template of using any operation provided by your endpoint. Just change operation name and arguments :) For example updating node:

$arguments = array('nid' => 1,
‘node’ => array(‘title’ => ‘Modified title’));
$command = $client->getCommand(NodeOperationUpdate, $arguments);
$response = $client->execute($command);

 

Gui for Guzzle client debugging

Service Guzzle Client provide example of usage and also UI to test and debug your local endpoint or external from given service description. After you choose one of these options you will get a list of available operations to test.

Use “UserOperationRetrieve” for example. Some operations will need Authorize first, it depends on your permissions. SG UI provides form for auth every time. So for UserOperationRetrieve we have such separate page with form:

And if you provide valid credentials and existed user id you will get the full user object via dpm theme (so familiar for Drupal developers). Also you will get the full exception message if some occurs.

Service Guzzle module introducing is over :) Waiting for feedback.

Language English Tags: DrupalDevelopmentTutorialsCheck this option to include this post in Planet Drupal aggregator: planet

Welcome to another Commerce Module Tuesday! Today we are looking at Commerce Reporting, maintained by Christophe Van Gysel who interned at Commerce Guys last year and is now interning at Google in the United States (yes, we’re all jealous of Christophe). Get ready for a high impact and extremely useful module, folks. It not only “just works” it takes all of it’s data from the existing database and displays fancy graphs and filterable reports. In other words, even if your store was built on a pre-beta Commerce from 2011, this module would still be able to read your store history.

Christophe had to really jump a number of hurdles to get this module launched last year, not the least of which was a lack of community consensus on how to display graphs from Views 3.x on Drupal 7. So he built the Visualization API which has now eclipsed commerce_reports in terms of active installs. So, as a part of another Commerce Module Tuesday, I invite you to sit back and take a look at another awesome community contributed module that fills a vital role: data mining.

(Video and Setup steps after the break.)