Planet Drupal

Subscribe to Planet Drupal feed - aggregated feeds in category Planet Drupal
Updated: 10 min 26 sec ago

Annertech: Case Study - Performance Testing a Drupal Website

Tue, 25/08/2015 - 12:02
Case Study - Performance Testing a Drupal Website

At Annertech, there are three things we take very seriously: website/server security, accessibility, and website load times/performance. This article will look at website performance with metrics from recent work we completed for Oxfam Ireland.

We use a suite of tools for performance testing. Some of these include Apache Benchmark, Yahoo's YSlow, and Google's PageSpeed Insights. Our favourite at the moment is NewRelic, though this does come at a cost.

Categories: Elsewhere

KnackForge: Drupal Moodle user integration

Tue, 25/08/2015 - 07:20

Moodle is a free and open-source software learning management system written in PHP and distributed under the GNU General Public License. Moodle is used for blended learning, distance education, flipped classroom and other e-learning projects in schools, universities, workplaces and other sectors.

Our main objective is that we wanted to manage all the users from Drupal i.e., use drupal as the front end for managing users. For this purpose, we have a moodle plugin and drupal module. Drupal services is a moodle authorization plugin that allows for SSO between Drupal and Moodle. Moodle SSO provides the Drupal functionality required to allow the Moodle training management system to SSO share Drupal sessions. 

In order to make SSO work, we need to ensure that sites can share cookies. Drupal and moodle sites should have url like and As mentioned earlier, sites should be able to share cookies. To make sites use shared cookie, we need set the value of $cookie_domain in settings.php file on the drupal site. In our case, the site urls was something like and For these type of sub-domains, the cookie_domain value can be set like the below one:

$cookie_domain = "";

Note: The dot before "" is necessary.

Let's start with the steps that need to followed for achieving SSO between drupal and moodle:

1. Moodle site

Categories: Elsewhere

KnackForge: Configure & Import SOLR data

Tue, 25/08/2015 - 06:44
If you are planning to import data from database (MySQL, PostgreSQL) download the required database connector,   For PostgreSQL, you can download here   First step, configure the data source file in SOLR. To do this add the new file in SOLR home directory solr/<core>/conf/data-import.xml <?xml version="1.0" encoding="UTF-8"?> <dataConfig> <dataSource
Categories: Elsewhere

KnackForge: Slideshow in Drupal

Tue, 25/08/2015 - 06:20

This post explains about creating slideshow in drupal. There are many ways and plugins available to create slideshow in drupal and I am going to discuss some methods which will be very efficient and useful.

1) Using Views slideshow module

2) Using jQuery cSlider plugin

3) Using Bootstrap carousel

1. Using Views slideshow module:

The modules required for this method are:

  1) Views

  2) Views slideshow

  3) jQuery cycle plugin ( Download here and place it at sites/all/libraries/jquery.cycle/)

Enable the added modules. To create views slideshow, create a new content type for instance "Slideshow" with an image field which can be used as slideshow image.

Add multiple slideshow nodes with images. Then, we have to create a view block with slideshow content. Select "slideshow" as required format and configure transition effect in the Settings link.


After saving this view, place this view block at neccessary region at admin/structure/blocks.

2. Using jQuery cSlider plugin:

1) You can download this plugin from here. There is also a demo file in this plugin which can be used as a reference.

Categories: Elsewhere

Drupal Association News: 2014 Drupal Association Annual Report and Financials

Tue, 25/08/2015 - 01:54

One of our key values at the Drupal Association is communication:

We value communication. We seek community participation. We are open and transparent.

One of the ways that we try to live this value is by making our numbers -- both operating targets and financial -- available to the public. The monthly board reports share basic financial numbers and all our operational metrics. Once a quarter, we release full financial reports for the previous quarter. You can access all this information at any time on the Association web site.

At the close of each year, we take the opportunity to have our financials reviewed (and sometimes audited). The review process ensures that we've represented our financials properly. This work takes some time. Though our fiscal year closes on 31 December, it takes six to eight weeks to get the final bits and pieces handled in our financial systems. The independent review or audit adds another 8+ weeks to the process of closing out our year. Then we have to review the findings with the Finance Committee and the full Board before we share them publicly. That's why it's August and we're just now sharing the 2014 reviewed financial statements with you.

In 2014 we also began tracking our progress towards several operational goals for the first time. Though we share those numbers every month in the board report, we pulled some of our favorite stats and stories together into an Annual Report to share the work that our financials represent.

What happened in 2014?

2014 was an investment year. Per our Leadership Plan and Budget for the year, our key focus was building an engineering team to first address technical debt on and then take on actual improvements to the site. We purposely built a budget that anticipated a deficit spend in order to fully fund the team. The intent was to also build some new revenue programs (like Drupal Jobs) that would ramp up and eventually allow us to fund the new staff without deficit spending. And that's what we did. We went from two full time staff focused on to ten.

The investment has been paying off. We spent a lot of 2014 playing catch up with technical debt, but also managed to improve site performance markedly while also increasing the portability of our infrastructure. On top of that, staff worked with community volunteers to release new features related to commit messages, profiles, and Drupal 8 release blockers. Most importantly, staff and the working groups prioritized upcoming work and published a strategic roadmap for improvements to

We held two huge DrupalCons, one in Austin and one in Amsterdam, and planned for a third. Our very small team of events staff and a crew of remarkable volunteers hosted over 5,500 people across our two events, all while planning our first Con in Latin America. We had some stumbling blocks and learning opportunities, and have been applying what we learned to the three 2015 DrupalCons.

We launched Drupal Jobs. This was something the community asked for very clearly when we conducted a 2013 study. We’ve seen steady growth in usage since our quiet launch and will continue to refine the site, including our pricing models, so that it is accessible to Drupalers around the world.

We diversified our revenue streams. DrupalCons used to be 100% of our funding. Not only is this a risky business strategy, it puts undue pressure on the Cons to perform financially, leaving us little room to experiment or make decisions that may be right for attendees, but could negatively impact the bottom line. As we increase the funding sources for the Association, we can make more and different choices for these flagship programs and also grow new programs with the community.

We introduced branded content including white papers, infographics, and videos. These materials have been widely used by the community and have helped us understand the audience in a better way. You can see a lot of this work on the Drupal 8 landing pages, where the key content pieces were downloaded thousands of times in 2014.

We released new vision, mission, and values statements for the Association. These tools are really useful in defining the focus of the organization and helping to guide how we get our work done. Working in a community of this size and diversity is extremely challenging. There is no choice we can make that will include everyone’s ideals, but our values help us make those decisions in a way that allows for transparency and open dialogue with the community. It’s something that we try to honor every day.

What about money in 2014?

As anticipated, we ran a deficit in 2014. However, we did manage to grow our overall revenue by about 6% from 2013 to 2014. This trend has continued into 2015, though not at the rate we had hoped. Still, we are now on track to support the investment we made in 2014 into the future. Another key win in 2014 is that we grew non-DrupalCon revenue to 21% of our total revenue. Diversifying our revenue streams reduces our financial risk and takes the pressure off of Cons, allowing us to experiment more.

I want all the details

Excellent! You can check out:

Categories: Elsewhere

Larry Garfield: Just how insular is the PHP community?

Mon, 24/08/2015 - 22:21

Periodically, there is a complaint that PHP conferences are just "the same old faces". That the PHP community is insular and is just a good ol' boys club, elitist, and so forth.

It's not the first community I've been part of that has had such accusations made against it, so rather than engage in such debates I figured, let's do what any good scientist would do: Look at the data!

read more

Categories: Elsewhere

OSTraining: Drupal 8: What do Site-Builders Need to Know?

Mon, 24/08/2015 - 21:41

Over the last few weeks, we've been working really hard on preparing training for Drupal 8.

We'll release the training close to the actual launch date of Drupal 8, but before then we have a great video to get you started.

This is a webinar we did with Acquia called, "10 Things Site Builders Need to Know Before Leaping to Drupal 8".

I talked about the many user-friendly features in Drupal 8, including the mobile-friendly admin interface and the in-place WYSIWYG editor, plus improvements in theming and module development:

Categories: Elsewhere

Drupal Watchdog: Auditing, Ethics, and Drupal Sites

Mon, 24/08/2015 - 19:07

As web sites and applications have become more complex, the need for auditing – at multiple points in the lifecycle of a project – has become ever more important.

Before delivery, a web project can be audited to ensure the ability to meet business goals or compliance with regulations. After delivery, an audit can identify problems and propose remedies. In a possible merger or acquisition, an audit can help evaluate the project’s relative benefits and liabilities.

Website auditing has become similar to financial auditing (which is separate and distinct from accounting and financial activities). It is similar to the practices applied in auditing management systems (see “There’s a Module Standard for That” sidebar).

Website auditors must apply these four principles:

  • Judgment They must be able to choose the scope and granularity of the website, without wasting effort on discovering problems with no meaningful impact on the behavior and performance of the site; hence, a need for business acumen.
  • Expertise In order to determine whether or not best practices were followed by the original site developers, auditors must achieve a level of proficiency beyond that with which the site was delivered.
  • Objectivity Auditors cannot audit a site they themselves produced, or else risk selective blindness – the inability to see problems they missed the first time around.
  • Distance Auditors cannot operate on a website developed by a company – especially their own – with which they have any kind of commercial or personal involvement.
The Real World

Market studies show that site audits are often used as a loss leader by generalist Drupal agencies. Their objective: to set the stage for redevelopment and third-party maintenance work, where the main volume of business is done using “findings” from a short and low-cost audit to provide the developer with a technical advantage against competitors.

Categories: Elsewhere

Four Kitchens: REST Easy Part 4: The Tax(onomy) man!

Mon, 24/08/2015 - 18:09

It’s easy to add node endpoints to your RESTful API - but there’s more to Drupal than nodes. This week we’ll add an endpoint for a taxonomy vocabulary.

Categories: Elsewhere

Acquia Developer Center Blog: Training Your Team on Drupal 8: Balancing Classrooms and Individuals

Mon, 24/08/2015 - 18:03

Not every student learns the same way, so teachers consistently have to find a way to instruct a classroom while also reaching students individually.

We were reminded of a teacher’s greatest challenge when we trained dozens of Acquia employees on Drupal 8. As my co-author Kent Gale and I detailed earlier in this series on Drupal 8 instruction, we separated employees into groups of two, with one person having some knowledge of the new platform and the other having no knowledge. Once their instruction ended, they split up and each teamed with two other employees – our version of chromosomal mitosis.

Our approach to training was structured. We had goals to achieve. But we also had to stay flexible throughout. Because experience, knowledge, and skill set differed with each employee, we had to connect with them individually while maintaining the larger class structure.

We had people with deep programming experience. We had middleware folks. We had site builders. We had front-enders. Because of that, the training program had to present a lot of material, but not so much that individuals wouldn’t learn. We trained with the expectation that not everyone would, or even needed to, become experts.

Consider the training of our “explainers,” the employees who explain our products to the public. We had to figure out what they could easily learn in only one- to four-hours of training. They needed to know enough to promote and answer questions about Drupal 8, but didn’t need to know as much as a support person, who received anywhere from 40 to 80 hours of training. Figuring out what the explainers needed to learn took some effort, but there was ample material to help us determine which path to follow.

Speaking of paths, your team doesn’t have to follow ours. Mitosis worked great for us, but it may pose a problem for your program if you have fewer employees, less time to train, or other considerations.

You need to find out what works best and that, as we’ve mentioned, takes time and effort, success and failure. Some employees like to be lone wolves and learn everything on their own, for example, so our process may not work for them.

Tools that track progress will help you ascertain what works and what doesn’t. Every company, no matter how large or small, faces time constraints, so these tools will guide you through the unknowns.

We used training as a key performance indicator (KPI) for employees. Shared ownership in this big Drupal 8 training project made sense if we all had to make a big leap together in understanding the new platform. Sometimes employees will sweep training under the rug because they believe putting out other fires is a priority.

We knew learning Drupal 8 would be a significant commitment; it’s a significant change, after all. But we couldn’t delay training. Drupal 8 was coming out and there was no time for delay. KPIs helped motivate and get everyone on the same page. There was a vested interest in making progress.

Blog series: Organizing to Rock with Drupal 8Workflow: PendingFeatured: NoTags: acquia drupal planetDrupal 8 related: YesAuthor: Thomas Howell
Categories: Elsewhere

Sooper Drupal Themes: 8 Common Customer Service Complaints All Drupal Developers Will Deal With

Mon, 24/08/2015 - 10:51

Every Drupal developer heard stories of 'clients from hell' and collaborations that turned into nightmares. And, it’s true… you’re going to come across some extremely difficult clients. No matter you do, no matter how hard you work…you’re going to have problems with them. 

Remind yourself: “I am not alone!”

All businesses – no matter what kind of company it is...

Categories: Elsewhere

KnackForge: Clear views cache when insert, update, delete node in Drupal 7

Mon, 24/08/2015 - 06:10

   This blog describes how to clear views cache while inserting, updating and deleting a node. If we want to improve site performance, then views caching is one of the options.

   For example, let's consider that there is a view that display list of records and it will be updated occasionally. Then we can render views data from cache rather than server by setting up cache for views. We can set views cache at Advanced section of its settings page. Drupal supports time based caching by default. We can cache the views until 6 days. If you want to cache the views over 6 days, then you could select 'Custom' option and fill number of seconds in 'Seconds' textbox. 

   Suppose you have cached views for 30 mins. Then it won't display updated data until 30 mins, even if new node is added to that views. It displays updated data only after 30 mins because the views is cached for 30 mins. In that situation, the user can't view new data in cached views. So we need to clear views cache when we add a new node. Then only we can see new data in views and also data is rendered from cache. 

   Lets see how to clear views cache while inserting node:

Categories: Elsewhere

PreviousNext: Boosting performance of a complex Drupal 7 project with

Mon, 24/08/2015 - 01:49

Earlier in the year we worked with a household Australian name to help them build a next-generation more-performant version of their energy-comparison site.

We used to optimize the critical elements of the site.

Read on to find out more about our experience.

Categories: Elsewhere

Mark Koester: Using Rules to Periodically Change a Your Drupal Site Configuration and Variables

Sun, 23/08/2015 - 15:45

Wouldn’t it be cool if you could use Rules to periodically set, change or modify certain Drupal site configurations and variables?

Yeah, it would be cool and nowit is totally do-able with "Rules Set Site Variables”

Below is my use case and a simple recipe on how to use Rules (and a few helper modules) to change site configurations periodically. I imagine you can use it for all kinds of other craziness on your Drupal site.

Use Case: Modifying Node.Js Host Configuration Variable on Schedule

We are huge fans of Drupal and Node.js and use it on multiple integration projects. Combined together, Drupal provides powerful information handling and Node.js handles real-time scalability.

We use Heroku to handle our free, node.js Chatroom Demo site. Unfortunately, Heroku is ending its policy of forever free dyno and moving towards a limited free usage of 18 hours per day. It’s an understandable, business change. For our free Drupal, Node.js chatroom demo, this means I’d need to pay $7 per month to keep the site up and show the [amazingness of Drupal and Node.js]( OR shut down the site.

So, instead of paying this (I’m cheap), I decided to setup two Heroku, Node.js instances and simply use a Drupal cron process to flip my node.js server twice a day.

The end result is that twice a day my Drupal site will change which node.js server it is using and thus prevent me from overusing my free, 18 hour daily limit.

Technically, I could have written some custom code, but being a lazy Drupal developer and site builder, I figured there had to be some way to do this with Rules.

Unfortunately there wasn’t at the time. The only similar solution was Conditional Variables, which would only set a session variable and not a permanent change to the configuration.

My solution was to create "Rules Set Site Variables”, which provides a custom reaction where you set any Drupal site variable. You can read more about that module in "Announcing: Rules Set Site Variables Module.”

In order to solve my use case to switch Heroku Node.js server, the final solution involved using Rules, Rules Once Per Day and "Rules Set Site Variables” as well as a couple of site and rules configurations.

Let’s take a look at how.

Which Modules? Rules, Rules Once Per Day and Rules Set Site Variables

In order to accomplish this task of periodically changing a site configuration, I used three modules (besides whatever else I’m using for Node.js and other parts):

I could have used a different triggering method but Rules Once Per Day was the easiest. Rules Once Per Day creates a Drupal event, which you can control and set to a specific time and which you can use as the triggering event with Rules.

Using "Rules Set Site Variables”, you then have the option of creating a Rules Reaction to set a Drupal variable.

After enabling these modules, there were only a few simple configurations.

Cron and Rules Once Per Day

In order for this to work you are going to need a functioning cron task on your server. This article won’t go into how to configure cron. But essentially for this to work, your server needs to run cron periodically in order to trigger rules and other things. In general you want cron to run every few minutes.

Rules Once Per Day provides a simple configuration setting page where you can configure when you want it to run according to your site time. This means that once a day this event will be triggered and your rules accordingly.

In my case, I use Rules Once a Day to change the site configuration to one of the Node.JS servers, create a future scheduled event in 12 hours and send me an email that the whole thing happened.

Configuring Rules to Change a Variable

Once you have created the event side of the rule, your next step is configuring the relevant action in this case “Set Drupal Site Variable”:

As you can see there are just two parts here: pick the variable you want to change and what text it will be set to.

Setting Up an Additional Rules Scheduled Component

Since I need to have this change every 12 hours, I need two scheduled events. The first scheduled event is from Rules Once a Day. The second event gets scheduled from the first one via a Rules Component.

A Rules Component is basically a conditional action you create that can then be trigger by other things. In this case, it gets scheduled via our original rule.

In order to add this to our original rule, we first need to create a new component and add your reaction events. In this case, I created another “Set Drupal Site Variable” action and another reaction to send me an email.

Packaging it all together

Using Rules, Rules Once a Day, Rules Components and Rules Set Site Variable, the final result is a series of configurable items that work together to switch my heroku node.js site server twice a day.

The rule configuration looks like this:

Conclusion: You can use rules to change site configuration

With "Rules Set Site Variables”, you change site configuration according various site events. In our case we use scheduled cron events to switch our heroku server and save some money.

On a wider level, any site builder can now use rules to modify their site’s configuration. Using a bit more configuration and some helper modules, you can make these changes according to a set schedule.

Live long and prosper Drupal Site Builders.

Tags: drupalDrupal PlanetPlanet DrupalNode.jsRulesSite Builder Mark Koester @markwkoester Mark has worked on Drupal since the early days of D6. He is passionate about open source as well as entrepreneurship. When he isn't building, he enjoys traveling and speaking one of his many foreign languages. Chengdu, China
Categories: Elsewhere

Frederic Marand: Logging for MongoDB

Sat, 22/08/2015 - 19:51

One nice thing during Drupal 7/8 development is the ability, thanks to the devel module, to get a list of all SQL queries ran on a page. As I've been working quite a bit on MongoDB in PHP recently, I wondered how to obtain comparable results when using MongoDB in PHP projects. Looking at the D7 implementation, the magic happens in the Database class:

// Start logging on the default database.
define(DB_CHANNEL, 'my_logging_channel');

// Get the log contents, typically in a shutdown handler.
$log = \Database::getLog(DB_CHANNEL);

With DBTNG, that's all it takes, and devel puts it to good use UI-wise. So is there be an equivalent mechanism in MongoDB ? Of course there is !

read more

Categories: Elsewhere

flink: Install Apache Solr 5 and Drupal Search API on your laptop in minutes

Sat, 22/08/2015 - 04:46

We recently had to debug a site for customer who was using Apache Solr and that wonderful Drupal module combo that goes with it: Search API and Search API Solr.
We were pleased to find that these components have continued to evolve over the past years, much to the benefit of their users . Setting up Apache Solr for Drupal is now easier than ever before, whether you use the command line or the newish Solr user interface.

In the steps below we've gone mostly for the point and click install.

1) On the Solr site, hit the download button. This redirects you to a page with a number of mirror sites from which you can download the .tgz. Or the .zip if you prefer.

2) Once downloaded unzip the .tgz or .zip and move it to your favourite application folder. I have fallen in the habit of abusing /Applications for this on my Mac, but you can use almost any folder that works for you.

3) Now cd into the epicentre of your Solr installation. When reading further documentation this is where it is assumed that you execute your Solr commands from:

cd /Applications/solr-5.2.1

4) A quick smoke test is to launch Solr in standalone (as opposed to cloud) mode

$ bin/solr start

Waiting to see Solr listening on port 8983 [/] Started Solr server on port 8983 (pid=10162). Happy searching!

Yay! Our Solr is up and running!

5) Let’s hook it up to Drupal by giving it a Search API configuration to work with. In your solr-5.2.1/server/solr directory create a new directory drupal-search and inside that a directory conf. Then drag all the files residing in /sites/all/modules/search_api_solr/solr-conf/5.x  into  drupal-search/conf.

Or using the command line:

$ mkdir server/solr/drupal-search
$ cp -r [DocumentRoot]]/sites/all/modules/search_api_solr/solr-conf/5.x server/solr/drupal-search/conf

6a) Now open a browser window and visit localhost:8983/solr and click the No cores available — Go and create one menu option in the bottom left. See the screenshot at the top of this article.

6b) Verify by picking "drupal-search" in the core selector drop-down. You should see something like this:

No errors? Great!

7) Revisit your Drupal site on the Search API config page, at admin/config/search/search_api and fill it out as shown below.

Press "Save settings" and you should see lots of green, like the screenshot below.
Check and tweak the configuration if necessary via the Edit tab at the top.

8) Made a mistake? You can delete your Solr core like so:

$ bin/solr delete -c drupal-search

Then try again from step 5) or 6).

* * *

File under: Planet Drupal
Categories: Elsewhere

Wuinfo: Should or Could a Drupal Developer Practice Like a Lawyer

Sat, 22/08/2015 - 00:50

For a small Drupal shop or an individual Drupal consultant, how to grow up? It seems that small Drupal shops face a glass ceiling when they want to move upward. They are not able to find a larger project because they not big enough. It is not trustworthy or not give the stack holder a confidence if there are not a team of developers. Should we solve this problem by working together in a partnership? The Drupal developer is a very technical intensive. Let us follow the way lawyers did in their practice. We get together and build a strong team.

What is the benefit to run a Drupal shop in a partnership?
1) It is easy to setup unless we want to form an LLP partnership. As a professional Drupal Freelance, we may have some client already. Initial partners sign an agreement and form a partnership with some existing customers already.

2) A good size team gives confidence to customers. It is going to be easier to win a bigger project.

3) Having a partnership formed, we can recruit more junior developers and train them.

The challenge here is we never did it before. We do may not have any ways to follow. A comprehensive partnership agreement is needed. Here are some important things that we need think through before we form a partnership:
1) Types of Partnerships (General Partnership or Limited Liability Partnership)
2) Governance and Decision-Making
3) Partner Compensation
4) Capital Contribution
5) Overhead and Liabilities
6) Parental Leaves and Sabbaticals
7) Retirement and Termination.

Professional Drupal developers will benefit by practicing partnership in professional service. A reputable good size team is capable of catch and deliver bigger and more profitable projects.

Drupal developers provide highly skilled professional service. Lawyers give professional service related law. Lawyers have lawyer office to provide their service in a decent way. Why not copy the way how they did it to provide our Drupal service.

Referred document:

Categories: Elsewhere

Acquia Developer Center Blog: Now or later? Weighing the benefits of early adoption for Drupal 8

Fri, 21/08/2015 - 17:36

If you’re considering a switch to Drupal 8, why not become an early adopter? Becoming an early adopter has some risks — and Acquia will work with you to mitigate those risks — but it also has huge benefits.

In this post, I want to talk to you about those benefits and also share with you my experience with Examiner and its early adoption of Drupal 7.

If you’re not familiar with it, Examiner is a news company powered by thousands of self-contributing writers. Currently, it’s read by 22 million people a month. But back in 2009, the company was having problems with its ColdFusion CMS, and those problems were hampering its growth.

Examiner decided to move away from the legacy homegrown platform to Drupal. So they acquired NowPublic, a citizen-journalism company I founded, for its Drupal expertise and leadership. That’s how I became the CTO of Examiner (I later joined Acquia in 2012).

Moving ahead, the big question we faced at Examiner was: Do we go with Drupal 6, a stable but mature technology? Or do we take a bold leap and implement the yet-to-be-released Drupal 7? Ultimately, we chose to become early adopters, going with Drupal 7.  

Here are the reasons that powered that decision:

1) You stay in front of the technology wave

While a good product at the time, there was no denying that Drupal 6 was closer to its end of lifecycle, while Drupal 7 was just taking off. We already understood the costs involved in supporting a legacy product. And we knew any extra investment early on would be offset by things like a longer lifecycle.

As a side note, unlike previous versions of the platform, Drupal 8 releases will come out every six months. So if you plan to become an early adopter of Drupal 8, not only are you taking advantage of the latest and greatest today — but you will continually upgrade to the latest features over the lifecycle of the product.

2) You differentiate yourself from the competitors

At Examiner, we wanted to set ourselves apart from the competition and we knew D7 would give us that edge. AOL was starting to invest in Patch at that time. And we felt that if we wanted to grow our audience and draw the best journalism to our site, we needed best-in-breed tools.  

3) You can attract the top talent

Great developers want to be on the cutting edge. Who wouldn’t want to jump on an opportunity to work full-time on their passion and be able to contribute back to Drupal? When we brought in a great platform at Examiner, we attracted the best Drupal developers in the world. Very quickly, we hired 15 of the top 50 developers in the Drupal community.  

4) You have the opportunity to shape your investment

Getting in on Drupal 7 earlier put us in the driver’s seat with the technology. That was important. We weren’t looking to adopt just any set of tools. We wanted an opportunity to shape the next generation of a platform. And we knew Drupal was going to meet our needs better than anything else out there. Plus, it’s a lot less risky than building your own CMS, because you are not going it alone. You’re going in as part of a community.  

5) It forces you to develop best practices

Being an early adopter forces you to use best practices with respect to software development. At Examiner, we were able to participate in the community and contribute code to the platform. So for us, being an early adopter forced us to do things the right way — and that set a standard within the company moving forward.

After a year of work, Examiner moved to a new platform built on Drupal 7. Thanks to Drupal 7, Examiner went from not being able to meet the needs of its users to exceeding them. We were able to deliver new features on a faster cadence. We had the best-in-breed platform, the easiest to use interfaces, and ultimately those features accelerated the growth of the company.

Examiner launched on Drupal 7 six months before the official release of the platform. We started developing on it almost a year and a half before the release. So we were really early adopters. Examiner faced tremendous risks, because at that time, Drupal 7 was nowhere near as put together as Drupal 8 is today, but we still decided to do it — and it paid off.  Today, Examiner is a top 60 website.

Being an early adopter is definitely an investment. It will cost more to be an early adopter of Drupal 8, but as Examiner has demonstrated, those costs are set off by several factors. And if you are concerned about the risks, keep this in mind: more than 400 sites are already running Drupal 8. And Acquia has already announced we are ready to support anyone with Drupal 8.

What are your thoughts? Do you have any experiences on being an early adopter of Drupal 7? And how do you feel about the risks/benefits of being an early adopter for Drupal 8? We’d love to hear back from you and get the conversation going.

Workflow: PendingFeatured: NoTags: acquia drupal planetDrupal 8 related: YesAuthor: Michael Meyers
Categories: Elsewhere

ThinkShout: Relaunching the Southern Poverty Law Center's Website

Fri, 21/08/2015 - 17:00

When projects get hectic around the office, we remind ourselves “We’re just pushing pixels.” We’re geeks. We sit in an air-conditioned office and play with cutting edge technologies on shiny MacBooks, drinking aeropress coffee. At the same time, we choose to work with nonprofit clients - experienced organizers and passionate advocates working on diverse issues in environmental protection, human rights, early childhood education, access to health care, and community building. We cannot do what they do; but it is wonderful to help them tell their stories and meaningfully engage their constituents online.

Over the last year, we’ve been particularly inspired to have had the chance to collaborate with the Southern Poverty Law Center (SPLC) on the redesign of its website. At the same time, our work with them brought further attention to our team about the many human rights challenges that our country has faced over the last year.

Our initial conversations with SPLC took place days before the death of Eric Garner. And over the year that we’ve been working with the Center, 16 unarmed Black people have been killed by police in the U.S. The Southern Poverty Law Center has been at the forefront of the national conversation about this issue.

If you don’t know SPLC, it is a leading advocacy and educational organization dedicated to fighting hate and bigotry and seeking justice for the most vulnerable members of society. Since 1971, SPLC has been using litigation to fight for civil rights. So hated by the Ku Klux Klan, SPLC’s offices were burned to the ground in 1983 by Alabama Klansmen. Then, in 1987 SPLC won a historic $7 million verdict against the United Klans of America for the 1981 lynching of Michael Donald - effectively bankrupting the KKK and crippling their organization.

In addition to its fight against hate and extremism, SPLC works on a range of human rights issues, such as children’s rights, immigrant justice, economic justice, mass incarceration, and LGBT rights. And so, fortunately, in addition to watching SPLC weigh in tirelessly on the police’s deadly use of force this year, we have also been able to celebrate with its staff over the landmark win over gay marriage bans, as well as the 50th Anniversaries of the March on Selma and the Passage of the Voting Rights Act of 1965.

Again, we have nothing to do with the success of this organization, but to collaborate with this team and to be close to their work has been incredible. We couldn’t be more proud of the website that we designed and implemented along with SPLC’s incredible communications team. Over the next few weeks, we will be writing about the many technical and process innovations we had the chance to implement with the SPLC team. In the meantime, we hope that you will take some time to explore their new site and to join us in celebrating and supporting their mission.

Categories: Elsewhere

Six Mile Tech: Making a Drupal 8 Contrib Module - The Movie: Raw and Uncut

Fri, 21/08/2015 - 16:44

As a contrib module developer that is starting to delve into Drupal 8 I wanted to share my experience working with Drupal 8. This is a video of me going through the process of re-creating the contrib module Token Conditions that I had created the week before. Along the way I delve into some new systems in Drupal 8 and give examples of how to figure out how to add functionality to this vastly changed version of Drupal.  

Categories: Elsewhere