Drupal vs Wordpress: functionality vs simplicity

Posted by InternetDevels on June 18, 2015 at 10:18am
 functionality vs simplicity

Drupal and WordPress are very popular content management systems for website development. They are both built on PHP + MySQL, they are both free, they are almost of the same age (Drupal was “born” in 2001 and Wordpress in 2003). However, they have significant differences in the ease of use, functionality, flexibility and more. Accordingly, each CMS has a passionate army of its own fans.

Rivals in different categories

Read more

Video: Metatag 1.5

Posted by Mediacurrent on June 17, 2015 at 7:41pm
Custom Modules

With meta tags still being important for search engine optimization and improving how content looks when shared via social networks like Facebook and Twitter, it's worth learning how to use Drupal's Metatag module the right way. Let me show you how a site can benefit from using meta tags, then find out about the latest improvements, along with recommendations on how to get it set up correctly for your site.

Building Native Apps - Part 2

Posted by Blink Reaction on June 17, 2015 at 6:38pm
Building native mobile apps with Ionic Framework and Drupal back-end: Starting a new Ionic Project

Planning app structure

Today, we continue the process of building our first Android app with Ionic Framework and Drupal 7 back-end. If you missed yesterday’s post, you might want to start there. I decided to demonstrate the process using a simple application that will receive data from a blog-type website with RESTful services.

Now, let’s plan our app. In the first stage we will make a hybrid app with two tabs. The first tab will show all blog posts filtered by the newest first, and the second tab will show the list of categories and articles in each category. Then, when a user taps on an article, they will see the full article content and comments. It looks simple enough, so let’s get started.

Start Ionic project from scratch

Ionic comes with three boilerplates to start a new app: blank, tabs and side menu. You can see those variants here. We decided to make our application using tabs, so we should use the tabs boilerplate. To start, run command “ionic start ApplicationName tabs” (you should replace ApplicationName with the name of your own app) in NodeJS prompt from the folder where you would like to store your projects. This command will install Cordova and Ionic with all dependencies and base files for your project, with prebuilt tabs in it.

Next, enter to the folder with your app name (the same ApplicationName that you entered in the previous prompt command) and run “npm install” to download all build tools dependencies. Let’s see what we get from scratch: run “ionic serve” and it will start a local server and open the project in your web browser. You can resize the window to show the app as in a mobile view, or, if you are using Google Chrome, you can utilize Chrome Dev Tools to emulate a device.

So, now we have the application with four tabs and some dummy content. You can explore that design to really see how the default site is set up. Notice how it changes if you switch between iOS and Android devices; the founders of Ionic did this because each platform has its own design recommendations, and if you follow them, your applications have a better chance of being approved for that platform’s marketplace.


Files structure

Next, take a look at the folders and files we get in our project folder:

  • hooks folder - here you can determine callback functions for Apache Cordova to add actions to the build process

  • plugins folder - for Cordova plugins, which extend support of some mobile API’s

  • scss folder - with default Ionic styles of apps. We will use this to customize our app

  • www folder - here are all the AngularJS app files, and our main working directory. Inside this folder we have the js folder, to keep all application files - in our case this includes apps, controllers and services; and the lib folder, for ionic core - this includes Angular with a few additional modules

  • templates folder - to keep assets of each app view

  • index.html file - which is the starting point of the app

Tabs definition

Our framework uses Angular UI Router to handle all application routes. We’ll change the default one in the config method of our app, in the app.js file, to define the routes that we need.

gist link - seems to be missing - verify where this link should go?

Here we define an abstract tabs route, which means that this element will have only a template without its own path. We define the following states:

Tab - Routes are children of tabs

Categories - will show list of all non-empty categories

Category - page that displays all articles related to that category

Articles - tab that shows a list of all posts, sorted by newest first

Article details - full post content of an article

Article detail pages and category articles contain the same content. They will each show full article content with comments; we define them twice to ensure smooth navigation for each path, from all articles to article details and from categories to article details, but we define one template for them. So, we will see the same result but the path to it will be different, depending on how we navigated to the article page.

Finally, we define the default path for our app, which will be the first view that users will see after it launches. Also, we define controllers for each route, which will keep all logic for pages.

Controllers creation

We should create empty controllers for now to avoid application errors; we’ll write the controller functionality later.

gist link

We set $stateParams provider for Category and Article details controllers that will catch ids of the source that we need; this is very easy to do with UI Router. Also, we passed Categories and Articles entities that will be an Angular service, helping us load data from the remote Drupal REST server and giving us the ability to use it in our views.

Services formation

We don’t have any RESTful services to grab data from, so as we do with controllers we will define clear services. In the next part we will configure REST on our Drupal website.

gist link

In general, we created Categories and Articles factories that have all get methods, that give us an ability to get all categories or articles, or only one by its ID. We post the ID parameter to the factory from controllers with the help of the UI Router. Endpoint variables are empty for now. This service will only make a request to our server and return promises; all logic and data transformation will located in controllers.

Adding templates

Finally, we will create templates for all application pages inside our templates folder: article-detail.html, category.html, tab-articles.html, tab-categories.html and tabs.html. Ionic comes with Ionicons - this is the icon pack for apps, so I set icons for our tabs.

gist link

gist link

gist link

gist link

gist link

Now you can check that it works in browser - just run “ionic serve”.

We get a starter point to show blog data.

You can clone and try all this code from my github repository, and to get code just from this part, checkout to the part1 branch by running “git checkout -f part1”.

Check back in tomorrow for the next part of the series when we look at Framework and Drupal back end configuration. 


DrupalDrupal How toDrupal PlanetDrupal TrainingTechnology ToolsPost tags: AppsIonic

Managing Remote Team Members The Promet Way

Posted by Promet Source on June 17, 2015 at 5:19pm
Managing a remote team isn’t remotely easy.

While many people get excited about the perceived freedoms of working at home (no dress code! building your own workspace! unfettered access to the couch!), the are significant challenges as well. The differences in geography and time zones, the reliance on virtual communication, the isolation of being the sole team member in a given city or region...life for the remote team member is not always a walk in the park.

Drupal 7.38 and 6.36 released

Posted by Drupal.org frontpage posts for the Drupal planet on June 17, 2015 at 5:06pm

Drupal 7.38 and Drupal 6.36, maintenance releases which contain fixes for security vulnerabilities, are now available for download. See the Drupal 7.38 and Drupal 6.36 release notes for further information.

Download Drupal 7.38
Download Drupal 6.36

Upgrading your existing Drupal 7 and 6 sites is strongly recommended. There are no new features or non-security-related bug fixes in these releases. For more information about the Drupal 7.x release series, consult the Drupal 7.0 release announcement. More information on the Drupal 6.x release series can be found in the Drupal 6.0 release announcement.

Security information

We have a security announcement mailing list and a history of all security advisories, as well as an RSS feed with the most recent security advisories. We strongly advise Drupal administrators to sign up for the list.

Drupal 7 and 6 include the built-in Update Status module (renamed to Update Manager in Drupal 7), which informs you about important updates to your modules and themes.

Bug reports

Both Drupal 7.x and 6.x are being maintained, so given enough bug fixes (not just bug reports) more maintenance releases will be made available, according to our monthly release cycle.


Drupal 7.38 is a security release only. For more details, see the 7.38 release notes. A complete list of all bug fixes in the stable 7.x branch can be found in the git commit log.

Drupal 6.36 is a security release only. For more details, see the 6.36 release notes. A complete list of all bug fixes in the stable 6.x branch can be found in the git commit log.

Security vulnerabilities

Drupal 7.38 and 6.36 were released in response to the discovery of security vulnerabilities. Details can be found in the official security advisory:

To fix the security problem, please upgrade to either Drupal 7.38 or Drupal 6.36.

Known issues


Front page news: Planet DrupalDrupal version: Drupal 6.xDrupal 7.x

Build a better local Drupal development environment

Posted by iterate. on June 17, 2015 at 2:26pm

Learn how we build Drupal websites within a local development environment that matches the configuration of production.

7 Great Reasons Why You Should Integrate Your Website and CRM

Posted by Annertech on June 17, 2015 at 12:55pm
7 Great Reasons Why You Should Integrate Your Website and CRM

Every organisation needs a CRM (C. Relationship Management) system, no matter how large or small that organisation is. Whether the C stands for Customers, Clients, Constituents, Contributors or other Contacts, organisations need to manage their contacts and keep track of their interactions with them.

Testing blocks using Red Test

Posted by Red Crackle on June 17, 2015 at 9:30am
Have you ever worked on a large project where out of the blue, one day, the client says that editors are not seeing a block of new blog posts in right sidebar on so and so page? It's generally pretty easy to fix this problem. Just go to the configuration form of that block and see what the conditions are for displaying the block. Or it could be a block written by you in a custom module and then you'll need to check hook_block_view() in your module to see where the problem lies. But you are still unhappy because the bug was caught on production. Have you thought of automating the block test so that a block with wrong settings never gets deployed in production? In this post, we'll show you how to automate the test for blocks in less than 10 mins.

Vimeo Advanced API for Drupal

Posted by KnackForge on June 17, 2015 at 7:33am
The Vimeo Advanced API allows the users to access, edit, and upload videos (if approved). With the advanced API, we will be able to create albums, add videos to albums, channels, and groups as well. Let's take a look at what you need to do in order to make the vimeo advanced API work in drupal:
  1. Install the vimeo API on your drupal site.
  2. Register your site with vimeo and get the Consumer Keys.
  3. Authorize your site and get the OAuth Tokens.
  4. Start using the Advanced API for vimeo.
Installing the vimeo API
  • Download the "Advanced API PHP Library" from here
  • Extract the contents of the zip file and move them to a folder called "vimeo" on the root of your drupal website.
Registering the drupal site with Vimeo
  • Login to your vimeo account, and register your website as a new "app" at https://developer.vimeo.com/apps/new
  • Enter the values of required field.
  • Use the URL of your website as the 'Application URL'.
  • Enter the "Application Callback URL", which is very important as the authentication process will start from here.
  • When you are registering an app for the first time, then you may have to wait for a human to authorize the app request.
  • Get your 'Consumer Key' and 'Consumer Secret' and save them to proceed forward.

139 DrupalCon New Orleans Details with Eric Schmidt, Sabrina Schmidt, Jason Want and Jeff Diecks - Modules Unraveled Podcast

Posted by Modules Unraveled on June 17, 2015 at 5:00am
Photo of Eric, Sabrina, Jason and JeffPublished: Wed, 06/17/15Download this episodeDrupalCon New Orleans
  • Where is the DrupalCon going to be?
    • New Orleans convention center
  • When is it?
    • May 9-13 2016
  • Why New Orleans?
    • We are seeing an incredible rebirth of a Great American City. Hurricane Katrina was such an unbelievable disaster, 80% of the city was flooded. Surrounding Parishes even worse, (we have Parishes instead of Counties), St. Bernard Parish, just down river, 99% was flooded. In the last 10 years we have overcome seemingly unsurmountable rebuilding, and have plenty more in the works. DrupalCon coming to New Orleans is great affirmation of progress we have made. It has a vibe like no other city, you can feel the life.
  • Why were you so driven to bring DrupalCon to your town?
    • It’s such a great place to be! Growing up 5 miles from Bourbon Street, we tend to take our City for granted. We do things that are rarely seen in the world! Food, Festivals, Family activities, Music, and of course you can drink in public! The general attitude across the whole city is very inviting and laid back. Really, a perfect place for a crowd like the Drupal Community!
  • What does the tech community look like there?
    *Growing in leaps and bounds. The entrepreneur landscape is one of the top in the country – we lead the nation in startups per capita by 64%, and we have a growing network of capital, which is important for startups. Game Loft, GE Capital, High Voltage Software have all chosen New Orleans because of our deep incentives, unique culture, and low cost of living. And our tech community is coalescing with the formation of TechNO, a coalition of local tech companies who meet regularly to promote the presence of the industry, New Orleans Entrepreneur Week hosted by the Idea Village, and NOLA Tech Week, which attracts national speakers and provides a great opportunity to showcase the industry. Finally, many local community colleges and universities are developing curricula to meet new digital workforce demands. There is no better opportunity in the country for tech companies than New Orleans. (from GNO, Inc. can be summarized)
  • What does the Drupal community look like?
    • We just had our Second camp! :-) Small but dedicated! We have had Meetups Monthly since 2010.
  • How important is the local community with the regards to putting on a DrupalCon.
    • I think now that the Drupal Association has taken the reigns of the Cons, the local community plays a part, but not like say, 2010, when we were in San Francisco. The local community had to shoulder the brunt of the work. And frankly, it was a lot, plus we probably had a limited number of cities with that size local community. That’s one of the great things about the Association, organizing DrupalCons!
  • What’s the Drupal adoption look like in New Orleans?
    • Growing, like everything else down here! The larger Universities have adopted Drupal, Tulane, Loyola, LSU up in Baton Rouge, plus the WWII museum, WWOZ (a great radio station, you should listen online), Cafe Du Monde, The Chef John Besh Restaurant Group, Audubon Nature Institute, Dr. Tichenor’s, maybe more….(or we keep it short??)
  • Who’s going to be the “boots on the ground” in New Orleans playing “host”?
    • Hopefully, us! We are both born and raised in the New Orleans area. I am involved in the local civic and business community and the entire Tech community are excited to host Drupalers!
  • How is it organized compared to years past? (Level of community and association involvement)
    • Again the Drupal Association has done a great job of spearheading the Cons. We worked closely with them to develop the logo and overall branding of the Con. In the coming months, we will work with them to look at venues and locations for events. Sponsors have reached out to us to help them organization of their specific needs for parties and meeting.
  • How will you be choosing who is selecting sessions

    • Each Con we put together the Track Team which is comprised of global track chairs (people who have evaluated and selected sessions for a Con at least once before) and then we work to assemble the Local Track Chairs who work in conjunction with the globals. We get these people from recommendations from within the community, people reaching out to volunteer and people expressing interest to Global Track Chairs. They go through an interview process with the Drupal Association and then the team is assembled and starts working to get out the call for content. It’s quite a ways away planning-wise but the Drupal Association will start putting together the New Orleans Track Team in the late fall, so if you’re interested or know someone who would be a great addition please reach out to amanda@association.drupal.org.
      You can read all about the session selection process here: https://events.drupal.org/barcelona2015/session-selection-process
  • For those that want to have a future Con in their community, do you have any advice?

    • We heard interest from the Drupal Association in having a New Orleans Con about five years ago, but we didn’t have a local community to support it. We started up a small meetup in Baton Rouge in 2010, then it slowly migrated to New Orleans. We didn’t lobby anyone to win the conference for the city. We just tried to establish a community and show consistent interest over the years, and trusted that New Orleans is a destination that the community would want to visit. Eric: you were at that first meetup and have helped to coordinate the growth of the group, what are your thoughts?
    • Have a consistent Meetup! We decided at our first Meetup we would meet on the First Thursday of the Month, even if it was only two people. And barring that occasional conflict with a carnival parade we have done that. Then organize a Camp, start small and be consistent!
  • Before we started recording, you mentioned that you wanted to talk about possible afterparty locations. Do you want to do that now?
    • Everywhere!
    • Crawfish season
Questions from Twitter
  • Ryan Gibson
    What kind of festivities can we expect during DrupalCon NO? #MUP139
  • Carie Fisher
    #MUP139 best place for drupalcon parties? any places we should try and visit in NO?
  • Robyn Green
    Question for Jeff, What amount of LSU attire will I be required to have for Drupalcon, and where can I get a 'I <3 Hallman" hat? #MUP139
  • Ryan Gibson
    What is the must-have NO food that I should plan on bringing Tums to be able to enjoy? #MUP139
  • markie
    Thanks @jasonawant for letting me crash at your place during JazzFest. #MUP139
  • Ryan Gibson
    And for letting us take a spin on the boat.
Episode Links: DrupalCon New Orleans WebsiteDrupalCon NA on TwitterSabrina on TwitterSabrina on Drupal.orgEric on TwitterEric on Drupal.orgJason on TwitterJason on Drupal.orgJeff on TwitterJeff on Drupal.orgNew Orleans Announcement VideoMedia Current WebsiteevanSchmidt design WebsiteLouisiana Drupal GroupLouisiana Drupal on Meetup.comDrupal Camp NOLALouisiana Drupal on TwitterTags: DrupalConNew Orleansplanet-drupal

Wysiwyg Fields

Posted by Realityloop on June 17, 2015 at 4:40am
17 Jun Stuart Clark

Wysiwyg Fields has been one of my more ambitious ideas in the world of Drupal. It is something that I feel Drupal has needed for a very long time, and something I could not resist taking on, but at times I felt that I had bitten off more than I could chew.

As difficult as it has been to write, it has been equally as difficult to write about, but here I go; My name is Stuart Clark, and this is Wysiwyg Fields.


What is Wysiwyg Fields?

Wysiwyg Fields is an Inline field management system, a module that bridges the gap between Drupal fields and CKEditor, giving the power of Drupal’s field system via the simple usability of a CKEditor dialog.

What that means is that Wysiwyg Fields allows for any Drupal field to be embedded directly into CKEditor and behave as a native CKEditor plugin, removing unnecessary clutter from your Drupal entity forms.


So… what is Wysiwyg Fields?

Let’s look at a standard use case for Drupal; Inline image management.

The below screenshot is of the Article content type provided by a default Drupal install. It includes three fields: Tags, Body and Image.

In my experience, clients and content editors alike would take an instant disliking to this form, as it’s missing a Wysiwyg and a simple method of inserting images into the body content.

Adding a Wysiwyg is easy enough, and while most (if not all) Wysiwygs will provide an image solution, the Images live outside of the Drupal realm; They can not take advantage of Drupal’s field formatter system, not be easily re-used in content or Views, or generally utilised by any other Drupal module.


Below is the same Article content type with Wysiwyg Fields enabled and configured for the Image field.

Apart from the addition of the Wysiwyg, the other most obvious change here is that the Image field is no longer present, leaving us with a much more compact form.

But the Image field is still there, it’s just now embedded in the Wysiwyg instead of part of the page. Simply click the Image field button on the Wysiwyg and you will be presented with something like the following:

This is a standard Image field widget embedded into a CKEditor dialog with a minor difference; Formatter and Formatter settings.

Upon uploading the image, the user can choose the formatter (if multiple formatters are set up for the field) and the formatters settings (if the formatter has settings) before clicking the OK button to insert the image.

Once inserted, the field, formatter and formatter settings can all be adjusted by selecting the inserted field and re-opening the Image field dialog, or simply by double clicking on the inserted field.

The field is rendered in the Wysiwyg as per the formatter and formatter settings as it would be when viewing the article after it has been created, however in the source code view (or via a non-Wysiwyg based Text format) it is a simple Token, as seen below.

The benefit of this approach is that whether the field or formatter ever changes, the content will automatically change to reflect those changes, whereas where markup injected it would not have the same flexibility.


Is Wysiwyg Fields a Image/Media solution?

No, Wysiwyg Fields can be used as an Image or Media solution, but it is not limited to any specific type of field. It can be used with any Drupal field, be it an Image field or a Text field, an Entity reference field or a View field.

Wysiwyg Fields doesn’t focus on being the best Image or Media solution, instead I would generally use Wysiwyg Fields in conjunction with existing Image or Media solutions; If they provide a field, Wysiwyg Fields can work with it.

However, Wysiwyg Fields is the successor to a module that was intended to be an inline image solution, Wysiwyg ImageField, and it is not out of the realm of possibility that Wysiwyg ImageField may see a future where it becomes a layer on top of Wysiwyg Fields to provide a simple inline solution.


Ok, I’m convinced, how do I set it up?

Setup is (hopefully) relatively easy to do, there are really only a few steps to get it running on a fresh Drupal installation:

  1. Install the module and dependencies as per standard Drupal instructions.

  2. Create or update a field so that it uses the Wysiwyg field widget.

  3. As per instructions provided on screen, add your Wysiwyg field button to a CKEditor profile.

That’s all it takes.

As Wysiwyg Fields is made up of many components, some of these components also require relevant setup, but Wysiwyg Fields manages this all behind the scenes as simply as possible. Primarily, Wysiwyg Fields that the Replace tokens filter is enabled on the Text formats utilised by CKEditor profiles with a Wysiwyg field button assigned.


Additional configuration

In the case that you create the field rather than change the widget of an existing field, you should have seen that there were some additional settings for the field, as seen below.

  • Sub widget type
    Wysiwyg Fields defines it’s own field widget, but some field types have multiple other widgets that change the way a field acts. This field allows you to chose the sub widget that will be used within the Wysiwyg Fields wrapper widget.
  • Sub widget settings
    These are settings specific to the fields sub widget.
  • Label
    By default, the button and dialog on the Wysiwyg will use the field label. This field allows that value to be overridden.
  • Icon
    Allows the customisation of the Icon which will be displayed in the Wysiwyg.
    Icons are provided by the Icon API module and any modules that defines Icon providers.
  • Formatters
    These are the field formatters that you wish to make available to the end user for the rendering of the field output.


Sounds good, can I use it now?

Yes! As of today (the 17th of June 2015) the first stable release for Drupal 7 is available; 7.x-2.0-beta1.

You can head over to the Wysiwyg Fields project page and grab it right now.


Can I simply test it?

Why yes, you can simply test it out now, thanks to SimplyTest.me, you can spin up a test Drupal 7 site with Wysiwyg Fields already installed just by going to: http://ply.st/wysiwyg_fields

You will still need to run through the setup steps above, but as I said, it’s easy.


This is a beta?

Yes, this is a beta, and as such there may still be some outstanding issues, as well as functionality still on the todo list.

It is recommended that in using the module you keep the beta status in mind, and if you do experience any troubling behaviour, or just have suggestions for the module, let us know over at the Wysiwyg Fields issue queue.


Get it now!

Download Wyswiyg Fields 7.x-2.0-beta 1 now!

drupaldrupal planetmodule

The case for git as a deployment tool

Posted by Freelock on June 17, 2015 at 4:10am

More and more I keep running into assertions that Git is a version control tool, and that if you use it for deployment, you're doing it wrong.


At Freelock we find it to be a very effective deployment tool, and I'm not seeing a solution that meets our needs any better.

Two presentations in particular caught my attention recently mentioned this:

DevOpsDeploymentDrupal PlanetDrupalgitSaltJenkinsDocker

DrupalEasy Podcast 157 - Rabbit Food (Anna Kalata - Getting Started in Core Development)

Posted by Drupal Easy on June 16, 2015 at 6:40pm
Download Podcast 157

Anna Kalata (akalata), a freelance Drupal Developer (AnnaKalata.com) from the Chicago area joins Ryan Price and Mike Anello to talk about getting started in core development, the New Jersey Shore Sprint, workflow, the Druplicon, Drupal major version stats, and our picks of the week.

read more

Building Native Apps - Part 1

Posted by Blink Reaction on June 16, 2015 at 5:39pm
Building native mobile apps with Ionic Framework and Drupal back-end: Setup Development Environment

Today, a large amount of web traffic comes from mobile device users. For this reason, responsive websites – those with great adaptation for smartphones, tablets and even watches and TVs – are a must-have for any company or startup. However, browser web-applications have a lot of limitations and some performance issues on devices. If you want a prime user experience for customers who use gadgets to interact with your services, a native mobile app is the best choice. It will give you an opportunity to use all native APIs, which use device hardware resources to communicate with users. In most cases web-apps don’t have that capability.

Technology introduction

There are currently two popular platforms for mobile devices: Android and iOS. Each relies on a specific language for applications – Android uses Java as its main programming language, and iOS uses Swift in its latest version. But it is possible to make apps for these and other platforms, without needing to learn each language (or having a different developer for each). This is done through hybrid applications: you can write simple HTML + CSS + JavaScript web-apps, and then convert them to native apps. There a few pros and cons to using hybrid apps instead of native ones:


  • No need for developers to learn new programming languages

  • One codebase for all mobile platforms

  • Can use almost all native API’s

  • Can use the same content as your web-app


  • A little bit slower than native, but not critical

  • Output files have a bigger size

Why Ionic?

In this tutorial series, I will use Ionic Framework to build our native app. Ionic Framework is an open-source project that works under the Apache Cordova platform and has AngularJS under the hood. The Cordova platform functions as a bridge between our HTML5 application and native device APIs; it has a base functionality for building, and many more available plugins. In addition, it works with a dozen mobile operating systems such as: Android, iOS, Windows Phone, FirefoxOS and more. Ionic provides us with an opportunity to write an app with all capabilities of AngularJS and its modules, along with a design starting point and UI elements. It has a NodeJS CLI to control building processes and a couple of boilerplates to make project starts immediate and simple.

Environment Setup

At this point we have a choice of how to build our development process. The first option is to use a preconfigured Vagrant install called Ionic Box - if you aren’t familiar with Vagrant you can read the following tutorial series. Ionic Box is a Windows virtual machine with all the software you’ll need to develop Android native apps. In this post, I will build an Android application because I’m working on Windows, but I will show how to add iOS support to your project if you are on Mac.

The second option is to install all programs manually on your system. For this, I made a step-by-step plan to set up your Windows environment:

  1. Install Java:

    1. Go to Oracle Java downloads page and click on the JDK download link:

    2. On the JDK download page, accept license agreement, choose and download the distributive for your operating system

    3. Run installer with default options

    4. Configure Environment Variables in system

        1. Go to Control Panel -> System and Security -> System

        2. Click on Advanced system settings

        3. Click Environment Variables button

        4. Click New button in System variables fieldset and add JAVA_HOME variable with value being the path to your jdk folder

  1. Install Apache Ant

    1. Download distributive from here

    2. Run installer

    3. Configure Environment Variables in system

        1. Go to Control Panel -> System and Security -> System

        2. Click on Advanced system settings

        3. Click Environment Variables button

        4. Click New button in System variables fieldset and add ANT_HOME variable with value being the path to your ant/bin folder

  1. Install Android SDK:

    1. Go to the Android SDK download page

    2. Click on “Other Download Options” link

    3. Download distributive for your system

    4. Run installer with default options

    5. In command prompt, run command: android
      This will start Android SDK Manager Tool, which allows you to download all packages that you need

    6. Check all Tools, Extras, and APIs 14 and higher, then click Install Packages button

    7. Configure Environment Variables in system

        1. Go to Control Panel -> System and Security -> System

        2. Click on Advanced system settings

        3. Click Environment Variables button

        4. Click New button in System variables fieldset and add ANDROID_HOME variable with value being the path to your sdk folder

  1. Install NodeJS:

    1. Go to the NodeJS web-site.

    2. Click on “Install” link, and it will start downloading the distributive for your operating system automatically

    3. Run installer with default options

  2. Install Cordova and Ionic:

    1. Open NodeJS command prompt

    2. Run the following command: npm install -g cordova ionic
      This will install Cordova and Ionic globally in your system, so you can access their commands from command prompt.


Congratulations - you have setup your environment to build hybrid mobile applications for Android with Ionic Framework! Check back in tomorrow and we’ll continue this process. Or, contact us if you have questions about this process or anything else, we'd like to help.

Best PracticesDrupal PlanetLearning SeriesTechnology ToolsPost tags: AppsIonicDrupal

Write a Migrate Process Plugin, Learn Drupal 8

Posted by Drupal Watchdog on June 16, 2015 at 5:24pm

A few of us were coaching Campbell Vertesi on porting the CSV source to Drupal 8 and he asked as an aside about mapping US states he had in a taxonomy vocabulary to taxonomy IDs during a migration. Glad you asked! The answer gives us an example for quite a few concepts in Drupal 8, so let’s dig in! We will go over the code line by line.


This particular class is a plugin. Plugins are normal objects in a predefined directory with a little metadata. For example, field widgets and formatters are plugins: they get a field and they return a form or a render array. We can change the formatter freely, only the type and meaning of the inputs and the output is fixed. Another good example are the image effects. Migrate uses plugins for everything: sources, processing, destinations. See more.

Namespaces, PSR-4

Line 8 contains a namespace declaration: the first part is Drupal and then the module name migrate_plus then the rest. Typically a plugin will follow by the a Plugin part and then the name of the defining module migrate and finally the type of a plugin process if the defining module has several. Not every plugin type requires such a long namespace, for example entities simply use Entity after the module name: Drupal\taxonomy\Entity. Drupal 8 will look for classes of the migrate_plus module under modules/migrate_plus/src (and all the other usual places for modules) and then the rest of the path is the same as namespace -- this is specified by the PSR-4 standard so this class is in the directory modules/migrate_plus/src/Plugin/migrate/process (sneak preview: a few lines later we will find the class name is TermReference and so the filename is TermReference.php).

Use Statements

Line 10-16 contains use statements. use some\namespace\classallows us to just write class in later code and the Drupal coding standards require this. It really is just syntactic sugar, you can even use non-existing classes. As an aside, many of us have found the PhpStorm IDE very convenient for Drupal 8 development: for example, it takes care of the file placement and naming from the previous section and adds these use statements automatically for you.


Line 21-23 contains an annotation. Annotations are a very useful feature in sane languages (like Python) so much so that the PHP community have implemented them in user space… several times. As such, Drupal 8 uses the annotations syntax of Doctrine on classes and PHPUnit annotation on tests. The Doctrine annotations are pretty close to a PHP array except {} is used instead of array(). We can see a very simple example here: this is using the MigrateProcessPlugin annotation and the plugin definition is array(‘id’ => ‘term_reference’). Every plugin must have an id at least. In previous versions of Drupal you would’ve used a hook_migrate_process_info returning an array keyed by the same id and some data. Although the info hooks are gone the alter hooks are still here: for example migrate_process_info_alter is a valid hook (although at this moment undocumented as its utility is severely limited). Other similar hooks, however, are much more useful, for example hook_entity_info_alter.

MigrateProcessPlugin itself is a class in the Drupal\migrate\Annotation namespace and it’s useful to know this because this class is the nexus of information about process plugins.

Classes, Base Classes and Interfaces

Line 25 contains the class name, a base class and an interface. One of the fundamental building bricks of Drupal 8 are interfaces. Interfaces provide a contract, that by which classes that implement it agree to provide certain functionality so that they can be used the same way other classes that use the interface. In other words, every class will have certain methods which take a certain kind of input and provide a certain kind of output. They are absolutely fundamental to plugins since any code interacting with a plugin will only know about the methods the interface require and nothing about the plugin details itself. Because of this, plugin types can require their plugins to implement a specific interface and Drupal throw an exception if they don’t.

Base classes are not a language feature, they are typical of Drupal 8 however: these classes contain some useful common logic for implementing an interface. Extending these instead of implementing an interface is very strongly recommended (although not mandatory at all). Some interfaces do not have a base class, for example ContainerFactoryPluginInterface.

Services, Injection

We will skip the constructor for now and talk about the create method starting on Line 40 required for implementing ContainerFactoryPluginInterface and then we will cover the constructor briefly.

Previous versions of Drupal were often strongly coupled: hardwired function calls were the norm. In Drupal 8 a lot of functionality is provided by so called services. There is a service for all sorts of things: working with entities, logging information, installing modules etc. The container itself is an object and the most used method of it (by far) is get as visible on line 46. You can find the services provided by core here. Because the container provides so many things it is not a good practice to pass and store the container in an object. By doing so, it becomes harder to understand (and to test) a class as it can basically depend on anything. Instead only the static create method will get the container, it passes the necessary services to the constructor and the class itself now has clean dependencies.

By far the most commonly used service is the entity manager: the getDefinition method gives us the entity type object, the equivalent of entity_get_info in Drupal 7. The getStorage gives us the storage object, which in turn can query and load entities of a particular type. (Then the entity objects can save themselves.) If we are not coding a nice little plugin then the entity manager can also be accessed at \Drupal::entityManager(). The Drupal class has methods for most common of the functionality. Most of these methods are just wrapping a $container->get() call so this list is also useful as a list of services. See more on services.

So the create method grabs the taxonomy term storage object and passes it to the constructor. The constructor in turn will call the base class constructor which initializes the common plugin properties, our constructor then initializes our own properties: most importantly the term storage is now available to every method in the class.

Entity Query

We have a getTermId helper method, not required by any interface -- it can not be as interfaces have public methods only. This method queries the term storage for the terms in the specified vocabulary. This perhaps looks familiar -- almost like a database query in Drupal 7. This, however, is for entities only and the condition method is extremely powerful, for example to find nodes posted by users joined in the last hour, condition(‘uid.entity.created’, REQUEST_TIME - 3600, ‘>’). Also, in general, already in Drupal 7 using SQL queries was discouraged but in Drupal 8 it’s safe to assume accessing the database is just doing it wrong.

The entity query returns a list of entity ids and then we load those terms. The following interesting tidbit is $term->name->value, this is one of the ways to access a field value in D8 but it’s mostly just for demo, using a proper method $term->label() is strongly preferred. This $entity->fieldname->propertyname chain can continue: we can write $node->uid->entity->created->value to get the created time for the node author.

The entity query condition closely mirrors this syntax: change the arrows to dots, optionally drop the main property , in this case value and you will get the previously mentioned condition('uid.entity.created', ... to query the same. The Entity API is a really powerful feature of Drupal 8.

Process Plugins

Finally we arrived to the transform method which is the only method required from a process plugin. Migrate works by reading a row from a source plugin then running each property through a pipeline of process plugins and then hand the resulting row to a destination plugin. Each process plugin gets the current value and returns a value. Core provides quite a number of these, a list can be found here. Most process plugins are really small: the average among the core process plugins is a mere 58 LoC (lines of code) and there is only one above 100 LoC: the migration process plugin which is used to look up previously migrated identifiers and even that is only 196 LoC (lines of code).

In our case the actual functionality is just one line of code after all this setup. Of course this doesn’t include error handling etc.

So there you have it: in order to be able to run this single line of code, we needed to put a file in the right directory, containing the right namespace and classname, implement the right interfaces, get a service from the container and run an entity query.

Planning for Friends and Family at DrupalCon

Posted by DrupalCon News on June 16, 2015 at 3:59pm

As part of our extended Drupal family, many Drupalistas bring their spouse, significant other, friend or children along to DrupalCon. As we know, the Con is always jam-packed with sessions, BoFs and sprints that keep us busy; Barcelona will be no different. After the Drupalers have drained our brains at the convention center, we jaunt off to group dinners, sponsor parties or the coder lounge to continue getting our Drupal on.

A Tale of Two Devsigners

Posted by ThinkShout on June 16, 2015 at 12:00pm

It’s June, which means Devsigner is just around the corner so, naturally, we’ve got design on the brain. What’s Devsigner? Well, I’m glad you asked. Devsigner is a conference held here in the Pacific Northwest geared towards front end developers and development-minded designers. Sessions focus on the relationship between design and web development, bridging the gap that separates the design from the code. The math looks like this: developer + designer = devsigner.

ThinkShout’s own devsigners Josh Riggs (User Experience Lead) and Eric Paxton (Front End Engineer), will be speaking at this conference at the end of the month. I sat down with Josh and Eric to learn a little bit more about their design process, and how we work with our nonprofit clients to ensure that their sites don’t just work, but that they also deliver a fantastic user experience.

You two make up the dynamic design duo here at ThinkShout. What do your respective roles entail? How do you leverage your different skill sets?

Josh: My role as the UX lead right now is handling all aspects of user experience and visual design. I’m responsible for interpreting site maps and requirements, plus things like client/user needs and creating a user interface out of that. That starts with wireframing and ends with a visual design layer.

Eric: My role as Front End Engineer is very much in the implementation phase. Though I do advise in the discovery and budgeting phase, just so we can be sure that we can actually implement what the client wants. It’s nice because in the past, before joining the ThinkShout team, I’d done the whole gamut. From the requirements gathering phase to wireframing, and then the implementation. Here at ThinkShout, I’ve found my sweet spot. I do occasional wireframing, but I get to focus on lots of implementation. I also implement Josh’s designs. I write a lot of Javascript and Sass, basically.

Josh: Eric is like the alchemist. He takes the metals - the designs from me - and turns them into websites. There is actually a large spectrum in between where my responsibilities stop and Eric’s begin. We still talk about things like, how do we go from an idea being on a screen, to that idea being a functioning website? We’re constantly thinking about how to best utilize our respective skillsets, always reevaluating our process to improve upon it.

What’s a recent project that you’ve really enjoyed working on?

Eric: The SPLC (Southern Poverty Law Center) microsite. I thought that was very well done. Josh did a lot of the front end work on that and I came in and did the site optimization, which is what I’ll be talking about at Devsigner. I thought that went really smoothly because at that time, all the work he’d done in the browser went directly to implementation. We were able to take exactly what he’d designed and just build off of it.


Can you talk a little bit about what the design process for the SPLC microsite was like, Josh?

Josh: We happened to be working on that right around the same time as I was doing wireframes for the upcoming SPLC main site that we’re redesigning. We were already doing a lot of thinking about their content and what their needs were. Because the Selma: Bridge to the Ballot movie was coming out on the anniversary of the Selma March, we wanted to have this ready to go in time for that day. There was no way we were going to launch the whole SPLC site along with it - we were too early in development for that - so we decided to split that project up and give them a campaign microsite that would be easy to build while we continued to work on their main site.

A lot of that meant working with their team to define their content needs. I began with basic wireframes in Sketch, and uploaded them into Invision to give them interactivity. As SPLC came up with more fidelity to what their needs were, we solidified the visual designs. Luckily, they already had a lot of assets that their really great internal design team had created for the movie, so I was able to go off of that style. I took their visual style and applied it to the wireframes and at that point, I went to Eric for a consultation and said, "Ok, if we’re going to build this in Jekyll, what’s the best way to do this as far as the architecture goes?" Eric was a huge help in regards to file structure. He wrote a great rake script to automate all the Jekyll, Sass, and Javascript components. That’s when I jumped in and rebuilt what I’d done in Sketch, and added more fidelity with HTML and Sass. I then passed it onto to Eric so he could do his unicorn magic.


Eric: And that’s a nice part about where our skills overlap: we can get closer to what we want. He’s a better designer than I am. My strengths lie in the code. I’ve designed when I had to, but it’s not my forte, so it’s nice to have Josh’s expertise. So these skill sets compliment each other. I feel comfortable handing over my implementation to design and saying, "Hey, can you polish the nav? Or the design?" Things like that.

What design trends do you want to see more of? Or less of?

Eric: I think flat design is getting boring. I’m starting to see a little bit more texture in the things we’ve done. Like patterns, not just flat design for the sake of flat design. There’s texture strategically used to make things look better. For instance, in the Capital Area Food Bank of Texas site, there’s a bit of a pattern in the footer. It’s not just a flat blue background with text. I really like patterns that are used to call out different sections of a design. It adds to it and brings something out of the page. It used to just be that admin interfaces were this flat. But now everything reflects that. Lots of rectangles. I personally like shapes and textures and patterns.


Josh: It’s tricky to know when to add life to what’s a very flat trend right now. I come from the old school world of web design, which was about how cool can you make your shadows look in Photoshop, how three-dimensional can you make things appear. Now that’s kind of like wearing skinny jeans in the late nineties, when you wouldn’t be caught dead wearing them. Or neon colors. So I think what’s happening is that it’s not just that flat design is popular. If you look at other design mediums, like automotive or architecture, there’s a phase with extreme ornate elements. You know, crazy fins, details, lights, every car had a custom badge. All that stuff. And then you have the modern era after that where everything gets streamlined and simplified. It’s more about the function over the form, and the function drives the form. You see the opposite in the Victorian era. Go walk along the St. Johns bridge and look up at a lamp. You’ll see these ornate, twisted little embellishments along the lamps. But the purpose of a lamp is to provide light. Those embellishments do nothing to support the function. They’re just there to make it look pretty.

I think we’re seeing a lot of that in digital design as it matures. We’re getting rid of the stuff that doesn’t support the function and focusing more on the intent of the users. While we’re taking that ornate-ness out of it, we’re also adding a lot more micro-interactions and animations. Things that actually help you do what you’re there to do. At first, I was kind of against that. But now that I think about it as post-modern design for the web, it makes more sense to me.

How do you advise nonprofits on this? Do these same trends benefit nonprofits as much as they do for-profits?

Eric: I think knowing your end user is what determines your path. A lot of nonprofits have similar goals as for-profits when it comes to their websites - they’re trying to tell a story and engage their users. But the main thing is, do the organizational goals reflect what the user is coming there for? For instance, we work with the LA Conservancy. They work to preserve historical buildings in LA. We didn’t just look at them, and then try to make their website look like a pretty building. But we also had this discussion in LA about form versus function. But I wonder, where does that meet in the middle? That’s what I struggle with. Because I do think there’s value in ornate elements like that. They set a mood. So I think that’s part of function - that ornateness sets the mood you want to present to your users to help them feel the connection to the organization’s cause.

Josh: Nearly every major design phase, whether it be automotive, architecture, art, whatever, there’s always a backlash to those current trends. So there will be backlash to flat web design. It may be a subculture, it may take over. But whenever something gets to be ubiquitous, there’s always someone who wants to do something totally different. It’ll be interesting to see what that is.

I feel like that’s the nature of creativity… We see something, we make it part of our process, plus a spark of something new.

Eric: We all have things we’re influenced by. To me, Google stands out. They’ve really led in the trends that people are using. There’s a level of depth to their designs that make me feel like I can reach out and grab it. It’s flat in some ways, but yeah, there’s definitely some depth.

Josh: Yeah, I think Google’s done a really great job. And you can see this happening in the app world. The current trend is also getting ubiquitous.

Devsigner is at the end of the month and you both are leading your own sessions. Can you tell us a bit about them?

Eric: My session is called "Optimization is User Experience." I think this is something everybody can use, which is why it’s listed as a beginner talk. We learn web design, we learn app design, we release these things to the world where we don’t have control over devices and users’ bandwidth, so it’s important to know that this beautiful thing you’ve created can be experienced correctly regardless of what device it’s viewed on.

Josh: So my session is based on something I’ve noticed. I worked on a lot of projects where there’s limited time, budget, or resources. Maybe there isn’t any resource for stock photography, or there’s just a really small team working on it. I’ve always had to find ways to be creative with what I have and with a small budget. I signed up to speak at Refresh Portland and I figured this might be a shared struggle and that other people could learn from my experience: how to stay under budget and still come up with a great, workable design. It’s called "Ballin’ on a Budget."

Want to dig deeper into design with Josh and Eric and pick their brains? Come to Devsigner, which takes place during June 27-28 at the Pacific Northwest College of Art in Portland, Oregon. Check out the full session schedule on the Devsigner site. You can also follow Josh and Eric on Twitter at @joshriggs and @epxtn.

Best Drupal Video Player Modules

Posted by InternetDevels on June 16, 2015 at 11:47am
Drupal Video Player Modules

Greetings to all who want to add video integration to their Drupal website! Drupal module development never stops, offering us a large number of various modules for working with videos. I have hunted through a huge amount of Drupal video modules for you.

To begin with, you need to decide where you want to store your video, how you want to display it, etc.

Let's discuss the pros and cons of each method. Here we go!

Read more

Mitigating Apache Internal Dummy Connection issue

Posted by KnackForge on June 16, 2015 at 4:00am

This is one of the bothering issues we had lately in our project. I'm summarizing the list of causes and possible ways to fix / mitigate the same. So what is Apache's Internal Dummy Connection is all about? Official Wiki page explains it better. See snip below,

When the Apache HTTP Server manages its child processes, it needs a way to wake up processes that are listening for new connections. To do this, it sends a simple HTTP request back to itself. This request will appear in the access_log file with the remote address set to the loop-back interface (typically or ::1 if IPv6 is configured). If you log the User-Agent string (as in the combined log format), you will see the server signature followed by "(internal dummy connection)" on non-SSL servers. During certain periods you may see up to one such request for each httpd child process.

#1: VirtualHost

As mentioned, Apache makes a call to itself. If your default VirtualHost is configured to serve dynamic database driven site like Drupal, it will certainly result in increased resource utilization. Changing the same to serve static index.html should make the dummy http request faster and less resource intense. Even if you have directory listing, symbolic links and/or AllowOverriding turned on, it is suggested to disable them.

#2: .htaccess Rewrite Rule

If default VirtualHost couldn't be changed for some reason, with mod_rewrite you can prevent request hitting the Drupal with rewrite rule. 

Thank You Pantheon

Posted by NYC Camp News on June 16, 2015 at 4:00am


Subscribe with RSS Subscribe to Drupal.org aggregator - Planet Drupal