Subscribe to Forum One feed
Updated: 1 hour 3 min ago

Big on Drupal in the Big Apple – NYC Camp 2014

April 14, 2014 at 8:27pm

We’re back from another successful Drupal NYC Camp!

A great event as always (thanks to Forest Mars and all the other volunteers and organizers that made the event possible), this year the event attracted more than 800 attendees and was held at a truly awesome venue: the United Nations.

Forum One’s presence this year was bigger than ever! Five of us attended, four of whom spoke at five different sessions covering a variety of topics:
Keenan Holloway talked to a packed room with his tongue-twisting, alliteratively-titled session: Paraphrasing Panels, Panelizer and Panopoly;
Chaz Chumley showed his extensive knowledge of the upcoming Drupal 8 Theming system – look for his book on the same topic later this year;
Michaela Hackner joined forces with Chaz Chumley to highlight some of our recent work with the American Red Cross on the Global Disaster Preparedness Center in a session called Designing for Disasters: An Iterative Progression Towards a More Prepared World;
• and William Hurley (that’s me!) was honored to have the opportunity to talk about Building Interactive Web Applications with Drupal, as well as Developing Locally with Virtual Machines at the DevOps summit (this latter one, sadly, wasn’t recorded due to some technical difficulties). I was blown away by the attendance at both of my sessions and was honored to be able to share some of our challenges and solutions at each.

These camps aren’t solely about sessions, of course. While not all of us were able to stay the whole weekend, Kalpana Goel stayed through Monday to work on some of the Drupal 8 sprints that were going on.

We love the opportunity to give back to the community in as many ways as possible, in code contributions to Drupal 8, contributed modules and also attending and speaking whenever possible. If you appreciate our expertise and would like us to speak at an event, drop us a line at marketing (at) forumone (dot) com and we’ll be happy to participate!

Back from the Big Apple, we highlight our participation in the 2014 NYC Drupal Camp and share the recordings of the five sessions that our team rocked at the event, which was held at the United Nations building in New York City.

Categories: Planet Drupal

A closer look at Entity Forms

March 28, 2014 at 5:27pm
A Closer Look at Entity Forms

Almost every project we work on requires a method for capturing user information. In most cases we have a Contact form and in more general purposes the client requires additional forms for various reasons. In the past our go to for creating forms was the Webforms module. As requirements have changed, so has the need for a web form solution that is exportable using Features.

In this series I will be walking you through an introduction to Entity Forms, including installing, configuring and creating an Entity Form from scratch. Later we will explore Exporting Entity Forms using Features and then follow up with integrating Entity Forms with Panels.

Why not Webforms?

The drawback of using the Webform module ((https://drupal.org/project/webform) is that there is no consistent port of this module to Drupal 8 and from an exportable solution you cannot use Features and Webform to easily migrate changes into code an on to a development or staging environment as Webforms are node based. While you could choose to use Webform Share (https://drupal.org/project/webform_share) to import and export Webform changes, this is not ideal for our development lfe cycle.

Advantages of using Entity Forms

This is where Entity Forms is starting to look like a more viable solution. Entity Forms if you are not familiar with them, enables the end user or developer to create front-end forms in a similar manner as Webforms. However, Entity Forms provide what I think is a more rich feature set.

  • Ability to attach any Drupal Field to the Forms

  • Ability to use most field based and entity aware modules.

  • You can download submitted data to XML and / or CSV data files using View Data Export.

  • Rules based form submission notifications. Allows for complex notifications logic.

  • Rules based form access control. Allows for complex access logic.

  • Use Views to create to an administrative listing of each Entityform type Submissions for fine grain control.

The Entity form module takes advantage of the Entity API, allowing for use of the Field UI and some consistency with how we are already developing. Oh, and they are exportable as well using Features, which make placing them in code advantageous for continuous integration.

 

Installing Entity Forms

Like most modules, Entity Forms can be found at Drupal.org and downloaded by browsing to (https://drupal.org/project/entityform). Feel free to choose the download version that is right for you. For sake of demonstration I will be using the 7.x-2.0-beta2 version along with Drush to download the module into my “sites/all/modules/contrib” folder.

Note: If you do not have a “contrib” folder under your “modules” directory, you can create one or simply place the downloaded module directly into the “modules” folder.

 

One we have the module downloaded we need to navigate to “admin/modules” and enable the “Entityforms” module. Keep in mind that Entityforms has dependencies of “Entity API, Views, Chaos tools, Field UI, Field and Field SQL storage”, so you will also need to download and install the dependencies. If you want to have Forms send email to users you will also need to download and install the Rules module and finally since Entityforms uses the Fields UI, you may want to download and configure the “Email Field” module.

Configuring Entity Forms

Entityforms work much like that of a Content type in that you can configure them by creating an entityform type and add fields to it. If we navigate to “admin/structure/entityform_types” we can begin to create a new Entityform as shown in the following image.

 

Configuring Entityforms

 

Creating an Entity Form

For demonstration purposes we will create a new “Contact” form. To begin creating an Entityform click on “Add entityform type” and fill out the fields as shown in the following image.

 

 

Creating an Entityform

 

 

  1. Name - Human readable name of our form.

  2. Redirect path - Relative path that a user is redirected to upon submission..

  3. Intro form instructions - User instructions you want to display.

 

We now are presented with multiple settings on how our new form will function. We will need to complete some or all of these sections so let’s review those now.

Access settings

Access settings control who can submit a form, whether a form is open for submissions and whether a form can be resubmitted by the same user. The controls contain the following fields and you can view the defaults I have selected in the following image.

 

 

Access settings

 

 

  1. Form status - Can users submit the form. Value allows for form submission to be open or closed.

  2. Roles - Roles that can submit our new form.

  3. Resubmit action - Action to take if logged in user has already submitted our form.

Submission page settings

Submission settings control the page title and response that a user will see upon successfully submitting a form. The controls contain the following fields and you can view the defaults I have selected in the following image.

 

 

Submission page settings

 

 

  1. Preview Page - Boolean value to show a preview page to user when they are about to submit a form.

  2. Submission page title - Page title displayed after form is submitted.

  3. Submission reply - The text that will be displayed to user upon form submission.

  4. Show submission information - Boolean value to show user submission form data.

 

Submission views

Submission views allow you to specify the view used to display submission reports to both the admin and end user. The controls contain the following fields and you can view the defaults I have selected in the following image.

 

 

Submission views

 

 

  1. View for submission reports - Select the view that should be used for Submission reports. These views are customizable.

  2. View for current user’s submissions - Select the view that should be used to show users their previous submissions.

 

Draft settings

Draft settings control whether a form can have multiple drafts prior to actually submitting it. The controls contain the following fields and you can view the defaults I have selected in the following image.

 

 

Draft settings

 

 

  1. Draftable - Boolean value to specify whether a user can save a draft of the form.

  2. Override drat button text - Text to use for draft save button.

  3. Draft save text - Text to be displayed to user when the form is saved as a draft.

 

Menu settings

Menu settings control whether a form has a link on a specific menu for user to navigate to. The controls contain the following fields and you can view the defaults I have selected in the following image.

 

 

Menu settings

 

 

  1. Provide a menu link - Boolean value to provide a menu link for form.

  2. Menu link title - Title of menu link that will be displayed.

  3. Description - Alt or Title attribute that will display when hovering over menu link.

  4. Parent item - Menu that men link will belong to.

  5. Weight - Specified order of menu link within menu.

 

URL path settings

URL path settings control the url alias for both submitting the form and the confirmation page once a form has been submitted. The controls contain the following fields and you can view the defaults I have selected in the following image.

 

 

URL path settings

 

 

  1. Submit URL alias - URL where user can find the form.

  2. Confirm URL alias - URL user is taken to upon submitting the form. This will display a page with the settings from the “Submission page settings”.

 

Form overrides

Form overrides allows you to change some of the default values of the form including the submit button text, confirmation text and titles. The controls contain the following fields and you can view the defaults I have selected in the following image.

 

 

Form overrides

 

 

  1. Submit Button Text – Text to use for submit button

  2. Submission confirmation Text – Text to use for Submission Confirmation

  3. Your Submissions Text – Text to use for “Your Submissions” page

  4. Form Disallow Resubmit Text – Text to use for “You already submitted this form”

  5. Submission Delete Text –Text to use for “Delete Confirmation”

  6. Submission View Title – Text to use for page title of submission view

 

Now that we have configured our Contact form we need to add fields to it for the user to be able to input information that will be submitted. Since Entityforms utilizes the Fields UI, we should be pretty comfortable in adding fields.

Managing fields

To manage fields we need to simply navigate to the “Manage Fields” tab and add our fields as shown in the following image.

 

 

Managing fields

 

For our particular Contact form we added the following fields.

  1. Name - Text field with the default settings.

  2. Email - Email field with the default settings.

  3. Subject - Text field with the default settings.

  4. Message - Long text field with the default settings.

 

Finally let’s preview what our form look like by browsing to the Contact link we provided earlier in our settings as shown in the following image.

 

 

Contact form

 

 

Summary


We covered a lot of information in a short period of time. Including how to download and install the Entityforms module and the dependencies it has to configure properly. We looked at configuring a new Entityform with proper settings and finished off by adding the fields through the Fields UI and previewing our new form. Next time we will look at configuring the Rules module for allowing Entityforms to notify uses by emailing them that a form has been submitted.

 

 

 

 

Almost every project we work on requires a method for capturing user information. In most cases we have a Contact form and in more general purposes the client requires additional forms for various reasons. In the past our go to for creating forms was the Webforms module. As requirements have changed, so has the need for a web form solution that is exportable using Features. In this series we will be walking taking a closer look at Entityforms.

 

 

Categories: Planet Drupal

5 Lessons Learned for Content Migration

March 6, 2014 at 2:16pm

This past fall I undertook my first content migration effort. This was to migrate an existing site from Expression Engine to Drupal 7. I immediately began looking at the Migrate module to learn it's use and here are some lessons I learned along the way.

First of all, be aware that migrate is a module for developers. It does have a user interface, but this is merely to run the import process. All the real action happens in the code, so you will need to be familiar with object oriented programming in PHP.

Lesson One: Don't Force a 1-1 Relationship

Do not try to force a 1-1 relationship with your migration classes and your destination content types. If you are migrating a site, you very likely are taking the equivalent of Drupal content type in the legacy system, creating similar types in Drupal, and probably combining a few of these because you realized in discovery sessions that some of the legacy system's content types are redundant. Although I did not use this method myself, given another migration project, I would create a 1-1 relationship between the migration classes and the legacy system's content types. This will avoid some awkward logic in your migration code as you try to route multiple possible source fields into a single field in Drupal.

In other words, don't do this:

Source type \
Source type ---> Migration ---> Drupal content type
Source type /

Do this:

Source type ---> Migration ---> Drupal content type
Source type ---> Migration ---> Drupal content type
Source type ---> Migration ---> Drupal content type

Lesson Two: Document

Be obsessive about in-code documentation/comments. In code comments are always a good idea, and you can never comment too much, but this is especially true with migrations. I did this from the start and it helped greatly when I had to revisit the migration code. Migrate is handy in that it provides tools to integrate in a project management system by linking to available tickets and places to add descriptions for mappings. Use these, your client's product owner will greatly appreciate it as they are reviewing the state of the migration. Which brings us to Lesson 3.

Lesson Three: Break out your migration into tasks

Break out the migration task into it's own project/ticketing system and use it! Migration tasks seem to live in a bubble within the larger site build project. Avoid this by separating the migration effort into it's own sub-project with a dedicated ticketing system. This way you won't clutter up the build's ticket queue with migration work and the whole team can observe the progress of the migration.

Lesson Four: A Gotchya!

A small gotchya on Migrate: If your source and legacy databases are owned by separate users, remember to set the "join" option to false in each of your migration classes with this bit of code:

    $options = array('map_joinable' => FALSE);

    $this->source = new MigrateSourceSQL($query, array(), $count_query, $options);

This may be the cause of some permissions errors. You may wish to make these databases joinable however, since the performance hit of not joining these is huge, (close to doubling the import in my own casual observation).

Lesson Five: Entity Reference Field Handlers

Entity reference field handlers do not currently support multiple cardinality (as of December 2013). This means fields with multiple values. You will need to write extra code in your prepare() method to handle this, e.g. 

     $related_nodes = $this->getRelatedContent($row); //Custom method to seek related nodes based on source id

      foreach ($related_nodes as $related_node) {

        $node->field_content_relationship[LANGUAGE_NONE][]['target_id'] = $related_node->nid;

      }

* assuming this is not a multi-lingual field. 

During this effort, I took it upon myself to develop a small Drupal module that would allow users to explore the Channel data (Expression Engine's version of a content type) of an Expression Engine site. I call it Expression Engine Analyzer and have posted it on Drupal.org as a sandbox project. It's been a great tool to help self understand the source data better and proven to be an excellent visual aid with clients while we discuss the the migration work. The whole team wishes we had such a tool at the beginning of a project, and going forward, I may consider making similar tools at the beginning of other migration efforts.

Five practical Drupal lessons learned during a recent content migration effort.

Categories: Planet Drupal

Manually Migrating Comments from Drupal to Disqus

January 17, 2014 at 7:32pm

Even if you've never heard of Disqus before, you've almost certainly seen it. With slick social integration, support for a variety of platforms (including WordPress, Blogger, Tumblr, and Drupal) and a rapidly expanding user base, Disqus has become one of the most popular hosting services for website comments. If you've had misgivings about the commenting system you're using – or just envied the functionality and polish of other systems – you may get to a point where you decide (as we did for our Forum One blogs) to make the switch to Disqus.

Making this switch is fairly straightforward – but what about all those wonderful comments that your blogs have earned over the years? You don't want to lose all the valuable discussion, tips and virtual high fives from your online fans, do you? Probably not. So if you're using Drupal and looking to upgrade to Disqus from a system like Mollom, there are various resources that already exist for manually migrating those comments, but nothing explains the process from A-Z, so I've compiled this step-by-step guide to show you how to manually migrate your comments from Drupal.

There are two primary ways to migrate comments: (1) Using the API to automate the whole process by directly connecting to Disqus from Drupal and move the comments for you (which isn't working at the moment); or (2) Using the Disqus XML export tool to migrate comments from Drupal in XML format which you can then import manually into Disqus.

Versions

  • Disqus module (Do NOT use 6.x-1.9 which was the stable version at the time of writing this. In normal Drupal fashion the Dev version is the one to use which is 6.x-1.x-dev released Nov 22, 2013 which contains the extra features needed to do this.)
  • This was done in Drupal 6 though D7 is very similar

Step 1 - Module Enabled

Enable both Disqus and Disqus Migrate modules (Disqus Migrate provides migration tools for moving comments between Disqus and the Drupal comment system). Disqus has a great reference for this.

Note: There are additional steps to enable Disqus (ie. downloading and installing the API library, adding your Disqus keys and verifying connection with Disqus, as well as actual Drupal access permissions) which are well documented in the list of references I've provided at the foot of this article. Since those steps are primarily used for setting up the module rather than carrying out the actual migration, I will not review those steps here.

Step 2 - Export Drupal Comments

 

  • Navigate to the Disqus export page /admin/content/comment/disqus_export which contains two buttons, Export Awaiting Comments Using API (which doesn't work as of writing this) and Export All Comments to XML File which is the one you should click.
  • Select Export All Comments to XML File (This option is explained as Exporting via XML will just gather all of your websites comments and format them for importing manually into Disqus)
  • Save the file to your local file system.

At this point you will have all the comments from your site in XML format which we will not import into Disqus.

Step 3 - Import Drupal Comments Into Disqus

 

  • Log into Disqus and navigate to Admin -> Discussions (Tab) -> Import (Tab)
  • Select the Generic WXR sub-tab option.
  • Select the Upload WXR file browser button and select your XML file you saved locally.
  • Select Upload and Import button.

Upon completing this, the comments will be imported to Disqus and you might want to do some house cleaning of those comments using the Disqus Admin interface tools.

Step 4 - Optional, but pretty much needed

After the comments are imported you may notice that some comments that exist on your Drupal nodes are not being displayed in Disqus. This is most likely caused by URL aliases. Since Disqus maps comments to nodes by path, this means that example.com/node/32 and example.com/how-to-play-ball may be the same node, but Disqus doesn't know that – so the result is that those comments will only show for the URL that was in the export XML file. What we need to do now is provide Disqus URL mapping.

  • In Disqus navigate to Admin -> Discussions (Tab) -> Tools (Tab)
  • Select Start URL Mapper. This takes you to a page that will give you a list of comment paths Disqus knows so you can provide manual path mapping information OR you can have Drupal create a mapping file for you. I chose to do this using a custom script.

    This page shows you the format it expects the CSV format (comma separated value) file to be in:
    http://example.com/old-path/old/posta.html, http://example.com/new-path/new/posta.html
    http://example.com/old-path/old/postb.html, http://example.com/new-path/new/postb.html

  • Follow the link to download the CSV file from Disqus to your local file system and name it disqus-urls.csv.
  • Copy this CSV file to your Drupal root directory.
  • Create a file with the following PHP code in that same Drupal directory called disqus-custom-script.php

<?php

$base = 'http://forumone.com/';

$n = strlen($base);

foreach (file('disqus-urls.csv') as $url) {

  $path = substr(trim($url), $n);

  $source = drupal_get_normal_path($path);

  if ($source != $path) {

    echo "$base$path, $base$source\n";

  }

  else {

  $source = drupal_get_path_alias($path);

  echo "$base$path, $base$source\n";

  }

}

  • Browse to the PHP file (or execute your preferred way so you can see echo output). Browsing to it with yoursite.com/disqus-custom-script.php assuming you named your PHP file that and saved it in the root directory as asked.

    This will give you output that can be saved into a CSV file and will be in the exact format that Disqus expects.
     
  • In Disqus navigate back to Admin -> Discussions (Tab) -> Tools (Tab) -> Start URL Mapper (Button) and upload the text file containing the output from our PHP script.

Make sure you give it a few minutes to complete, as the mapping in Disqus isn't instantaneous, but you should start seeing your comments appear where they should for the URLs that were in the mapping CSV file.

That's it! Below I've provided a list of references that you can use when following these steps. If this guide is helpful for you, or if you discover a different solution, please leave us a comment ;)

References

Disqus Module

Disqus setup instructions for Drupal

Disqus URL mapper

Imported DISQUS Comments Not Showing Up On Drupal Nodes

There are two primary ways to migrate comments from Drupal to Disqus. The API way that automates the whole process by directly connecting to Disqus from Drupal and moves the comments for you. The second way is an XML export tool that Disqus migrate provides to migrate comments from Drupal in XML format which you can import into Disqus manually which is what I will show you how to do.

Categories: Planet Drupal

Introducing the Pane Module

January 7, 2014 at 3:28pm

There are a couple of scenarios we see on pretty much any Drupal-powered website we work on. The first and foremost among those is often that our client wants to – you know – actually be able to easily manage their content. At the same time we need to be able to fit their content into the information architecture and design of the site. When we're talking about entities, nodes, and taxonomy terms it is pretty easy for content managers to go in and edit content. But what about little blocks of text on the home page, in the footer – or featured call-outs on various pages? These kinds of features have been a constant struggle to ensure that they exist through the process, but allow the content itself to change as needed.

Front-end example of the Pane Module at work.

Over the years we've tried many different Drupal modules and solutions including, Core blocks, Boxes, Beans, and Fieldable Panels Panes, but none of them quite worked right for both us and our clients. So we wrote our own module called Pane. The key features that we needed from our new module were:

  • Exportability – allow it to be exported through CTools and Features; neither Core blocks, Beans or Fieldable Panels Panes are easily exported
  • Separation of configuration from content – allow the guarantee of existence and format but allow the content to vary; when Boxes are exported they export the content along with configuration
  • Integration with CTools/Panels – we're heavily invested into the CTools universe and needed our tool to work nicely with those; most of the modules above stem from the block system and don't play nicely with CTools
  • Internationalization – allow the content to vary based on the current language; Beans and Fieldable Panels Panes are entities and could presumably be translated, but there's a layer of complexity involved in that which makes it more challenging

What the Pane module allows a developer to do is create a Pane and embed it on either a CTools Page Manager page as a CTools Content Type or through the normal Block interface. From there the Pane can be edited through the normal Panels or Block interface to edit HTML through a WYSIWYG or if using the Pane Entity Reference plugin to add and order references to various entity types much like the Entity Reference module. Those referenced entities can be output using either a display mode or a View. 

Once the module is installed and the permissions configured, an admin can go to Administer -> Structure -> Panes and see a list of current Panes and add new ones.

They can also edit Panes through the normal Panels interface or through the In Place Editor.

And then exporting can be done through the normal Features interface. The configuration and the data can be exported separately and generally only the container is exported. But if you know that the content isn't going to change and needs to be locked down in Features it can be there as well.

This module makes a lot of sense both for developers and content administrators. Let us know what you think in the comments.

We needed a way to have areas of content on pages that we could create, design and export and that our client could then take over and edit as they wanted. None of the modules out there quite fit the bill so we wrote the Pane module.

Categories: Planet Drupal