MarCom changes, and how we’ll keep moving forward

Posted by Drupal Association News on August 31, 2016 at 12:47am

This post is part of a series about recent changes at the Drupal Association.

Like each of the Drupal Association teams, Marketing & Communications (MarCom) has a broad range of responsibilities. Our job is to persuade and sell, but also to inform and educate. About our work. About yours. About what it’s like to be part of this community.

We contribute to more than 20 Association programs and products, like Membership, Supporter Program fulfillment, and DrupalCon support. Day-to-day community engagement—via Zendesk, Twitter, Facebook, issue queue, etc.—is part of each of those.

It’s a feat that’s always been impossible without help from community members like you. There’s the work Dave does in the content issue queue. What Paul and Alex do on our social accounts. And what Jess, catch, Gábor, David, Michael, and many more do to coordinate releases. There’s more than we can count.

But it’s also a feat we used to have more staff to handle. A year ago, we were a team of five. After retrenchment and reorganization, we’re a team of two. As we support and advance the Association’s initiatives to increase Drupal adoption, we have to make hard choices.

First, an apology

We’re sorry. This isn’t just business; our work is for you. We think about the impact it has every day. Having to stop doing some of that work—even the work some may consider little things—isn’t something we take lightly.

If we don’t have a sticker shipping budget, it may impact the energy you create at a meetup. If we don’t support Global Training Days, maybe the next would-be contributor in your region isn’t inspired to learn Drupal. And if we don’t share stories of grant recipients, maybe you don’t know that your membership dues make an immeasurable difference in people’s lives. (They do, by the way.)

So, if we let you down, we’re sorry. Your trust is invaluable to us. We try to earn it every day.

But we must decide


The Association has two priorities:

  • Create sustainable financial health
  • Get more organizations with large, complex digital ecosystems—government agencies, publishers, universities, etc.—to choose Drupal

This means prioritizing revenue-generating initiatives. It means changing, or adding to, some of the user experience on—to better present Drupal as an answer to the questions our new primary audience has. And it means amplifying stories that persuade that audience to make Drupal part of their systems.


We have a lot of work to do. And we won’t be able to do it alone. For those reasons and more, we need to make a promise about the content we publish.

We started on the following content strategy statement based on insight from our leadership. It describes our goal, methods, and primary audience in relation to each other.

Slides available on Google Drive

Clarity gives us the best chance to be efficient, effective, and consistent. So, we’ll keep narrowing that statement. It’s an important step toward giving the content we create—or ask others to create—a chance to live up to a shared potential.


What can two people do or coordinate well? What can we complete and sustain?

A team that churns out content but doesn’t, for example, regularly pause to evaluate each thing it creates—that doesn’t turn that knowledge into insight for what it makes next (or doesn’t)—isn’t doing its job well.

Our decisions about what work we will and won’t do aren’t just about what we can somehow make happen. They’re about what we can turn into sustainable growth.

What we’ll do

There are products and programs that are critical to our identity. We’re not a membership association if we don’t have a membership program, for example. Then there are mission-critical initiatives. (D.o) is an incredible platform, so promoting Drupal without using the site would undercut our mission. And there are fiscal health requirements, like DrupalCon ticket sales.

So, most of our work will stay on our to-do list. It’ll just be prioritized differently. These are the areas of work that either stay mostly as-is or grow:

  • Drupal marketing and communications (e.g., release support)
  • D.o content management of promoted areas (e.g., the planned homepage refresh and “Drupal for industries” content)
  • DrupalCon marketing and communications, and sponsor and partner fulfillment
  • Membership (for people and organizations)
  • Supporter Program fulfillment
  • marketing and communications
  • Camp engagement (we’ll create a 2017 camp kit before January; promise)
  • Elections support
  • Association communications, generally (e.g., writing and editing posts like this)
The work we won’t

To make the work we’ll do possible, there’s work we can’t give as much attention.

There’s work we, unfortunately, won’t do at all.

  • Help build new D.o Sections (the initiative Tatiana led is paused for now)
  • D.o content management of areas that aren’t being promoted
  • Support the Drupal Store (its inventory will be liquidated)
  • Share Community Spotlights
  • Manage content (the subdomain will be phased out)
  • Promote our webcast series

And there’s work we’ll reduce or others will lead.

  • Global Training Days (we’re setting up a community working group to coordinate it)
  • Advertising content production (we’ll depend on designers we trust)
  • Email newsletters (we’ll send fewer than the four we do now)
  • Sticker distribution (we’ll bring them to DrupalCons, but won’t ship them around the world)

This process will be fluid. As we adjust to these changes, these work lists may change again. If so, we’ll let you know.

How can you help?

If you help the Engineering and Events teams by giving back in ways Tim mentioned or contributing as Rachel suggested, you help us too. But there are things you can do to help MarCom specifically.

  1. Become a member. The revenue helps, of course. But it’s also one of the best ways to advocate for community programs.
  2. Refer friends and colleagues. Ask people you know at organizations that aren’t using Drupal to contact us. We need to know how these organizations make their decisions, and why they haven’t decided on Drupal.
  3. Support Global Training Days. Join the group at and add your 2016 events there. And if you want to know more about the working group we’re organizing, email Lizz.
  4. Contribute in the content issue queue. Especially for case studies, services listings, and training listings.
  5. Submit even the non-DrupalCon surveys. It’ll help us make decisions based on what you like, appreciate, value, and actually do.


Picture of Bradley FieldsAbout Bradley

Bradley Fields joined the Drupal Association in March 2015 as Content Manager. He now leads the content team as Marketing & Communications Manager.

When not at his desk, he’s curating Spotify playlists, watching an animated Disney movie, on the hunt for great whisk{e}y, or reading Offscreen magazine. He lives in Portland, OR.

From Intern to Employee: What to Expect in the Transition

Posted by Palantir on August 30, 2016 at 5:59pm
From Intern to Employee: What to Expect in the Transition brandt Tue, 08/30/2016 - 12:59 Matt Carmichael Aug 30, 2016Photo of Matt Carmichael sitting at table with other Palantiri

Internship experience is extremely valuable, especially in web development. So what can you expect in the transition from coursework to client work?

In this post we will cover...
  • The benefits of having an internship
  • What learning challenges you can expect

Want to work at Palantir?

Send us your resume!

The transition from student to full-time programmer can be intimidating. The days of submitting buggy and poorly-tested code that is just good enough to get a passing grade are over. Every line of code is just as important as the last, and even the smallest mistakes could lead to catastrophic problems for your team and your client. But trust me, it's doable!

I was lucky enough to have an internship at Palantir the summer before becoming a full-time employee. The opportunity to dive into the professional side of development without having quite the expectations of a full-time employee is priceless in my opinion. It gives you a chance to focus more on the learning experience of being a developer, without stressing as much over productivity and results. 

The most prominent takeaways from my time as an intern were learning and engaging in the process of collaborative programming with a team and also understanding the importance of code quality. In school a majority of the projects are done individually and you rarely have to rely on anyone else to get the job done. This is one of the biggest adjustments to make, as the workplace is the exact opposite. The members of your team need your code to be correct, verbose, and understandable in order to do their jobs. That being said, coding standards cannot be stressed enough in a team environment and doing things ‘your way’ is not going to cut it. 

At Palantir, I was introduced to an extensive Github repository devoted to documenting our code standards and development process. Familiarizing myself with the workflow, documentation, and code style expectations seemed like a full time job in its own right. Every line of code is submitted in a pull request which is inspected by a senior engineer and tested against the standards that are laid out in the developer documentation. 

Issues as seemingly trivial as the size of an indentation and documentation formatting are sent back to the programmer for revisions. Once the code has been through the critique and revision phase and is cleared by the engineer, the code is finally merged into the master branch and is ready to go into production.  This level of attention to details that seem trivial at a glance, but are vital for code consistency and readability, is in place to ensure the best product for the client.

Once you get past the logistics of teamwork, and the code standards become second nature to you, it's all uphill from there. As I settle in and become more confident in my role I realize how exciting worklife is. The opportunity to work with people of all backgrounds and skillsets and to see a project come together from start to finish is what makes it all worthwhile. 

Stay connected with the latest news on web strategy, design, and development.

Sign up for our newsletter.

Drush SQL Sync Alternative: SQL Sync Pipe

Posted by Chromatic on August 30, 2016 at 5:56pm

Using Drush to sync databses (drush sql-sync) is a valuable tool, but it is not always an efficient choice when dealing with large databases (think over 1GB). SQL Sync Pipe (drush sql-sync-pipe) is a Drush command that provides an alternative for drush sql-sync that streams the database dump directly from the source to the destination as opposed to sql-sync saving the database dump, transferring it via rsync and then importing the dump file. As an added bonus it excludes cache tables by default.


Below are examples from the command's README, syncing the same 1.05Gib database using the two different methods:

drush sql-sync

Command:            drush sql-sync @alias.sandbox --no-cache
Transfer size:      88.1MiB (compressed using rsync)
Import size:        1.05GiB
Total time elapsed: 46 minutes 47 seconds

drush sql-sync-pipe

Command:                 drush sql-sync-pipe @alias.sandbox --progress
Transfer size:           88.1MiB (sent compressed using gzip)
Import size:             1.05GiB
Import & transfer time:  27 minutes 05 seconds
Total time elapsed:      30 minutes 35 seconds

What are you waiting for? Download and install SQL Sync Pipe and get started!

drush dl drush_sql_sync_pipe --destination=$HOME/.drush && drush cc drush

Documentation overhaul

Posted by blog on August 30, 2016 at 4:11pm

One of the biggest content areas on—and one of the most important assets of any open source project—is documentation. Community-written Drupal documentation consists of about 10,000 pages. Preparations for the complete overhaul of the documentation tools were in the works for quite some time, and in the recent weeks we finally started to roll out the changes on the live site.


Improving documentation on has been a part of a larger effort to restructure content on the site based on content strategy we developed.

The new section comes after a few we launched earlier in the year. It also uses our new visual system, which will slowly expand into other areas.

Goals and process

The overall goal for the new Documentation section is to increase the quality of the community documentation.

On a more tactical level, we want to:

  • Introduce the concept of "maintainers" for distinct parts of documentation
  • Flatten deep documentation hierarchy
  • Split documentation per major Drupal version
  • Notify people about edits or new documentation
  • Make comments more useful

To achieve those goals, we went through the following process:

First, we wrote a bunch of user stories based on our user research and the story map exercise we went through with the Documentation Working Group members. Those stories cover all kinds of things different types of users do while using documentation tools.

We then wireframed our ideas for how the new documentation system should look and work. We ran a number of remote and in person usability testing sessions on those wireframes.

Our next step was to incorporate the feedback, update our wireframes, and create actual designs. And then we tested them again, in person, during DrupalCamp London.
Incorporated feedback again, and started building.

The new system

So, how does the new documentation system work exactly? It is based on two new content types:

  1. Documentation guide: a container content type. It will group documentation pages on a specific topic, and provide an ability to assign 'maintainers' for this group of pages (similar to maintainers for contributed projects). Additionally, users will be able to follow the guide and receive notifications about new pages added or existing pages edited.
  2. Documentation page: a content type for the actual documentation content. These live inside of documentation guides.

Documentation guide screenshot
Example of a new documentation guide

All of the documentation is split per major Drupal version, which means every documentation guide or page lives inside of one of a few top level 'buckets', e.g. Drupal 7 documentation, Drupal 8 documentation.
It is also possible to connect guides and pages to each other via a 'Related content' field, which should make it easier to discover relevant information. One of our next to-do’s is to provide an easy way to connect documentation guides to projects, enabling 'official' project documentation functionality.

More information on various design decisions we made for the new documentation system, and the reasons behind them, can be found in our DrupalCon New Orleans session (slides).

Current status

Right now, we have the new content types and related tools ready on
We are currently migrating existing documentation (all 10,000 pages!) into the new system. The first step is generic documentation (e.g. 'Structure Guide'), with contributed projects documentation to follow later.

While working on the migration, we are recruiting maintainers for the new guides. If you are interested in helping out, sign up in the issue. Please only sign up if you actually have some time to work on documentation in the near future.

There is a lot of work to be done post-migration (both by guide maintainers and regular readers/editors). The content is being migrated as-is, and it needs to be adapted for the new system. This means almost every single page needs to be edited. New fields (such as Summary) filled out with meaningful text (to replace text automatically generated by the migration script). A lot of pages include information for both Drupal 7 and Drupal 8, but this content needs to be split, with Drupal 8 information moved to pages in the appropriate version of the guide. These are just some of the steps that need to happen once the documentation has been migrated into the new system.

Next steps

As staff, we have a few follow-up tasks for minor improvements to the content types and tools. However, the bulk of the work is editing and improving the actual documentation, as I described above. This is in your hands now. Not only do we not have enough staff members to edit every single documentation page in a reasonable amount of time, we are also not subject matter experts for many of the topics, and so can't provide meaningful edits. The tools are ready, now it is up to the community to pick them up and write great documentation.

Documentation page screenshot
Example of a documentation page

Thank you

Lastly we want to say thanks.

Thanks to all the community volunteers who wrote those 10,000 pages over the years. Thanks to the Documentation Working Group members for their expertise, insight, and patience.

And, of course, thanks to staff. Unfortunately due to recent changes for the Engineering team, this will be the last section we'll have resources to work on for a while. This was a fun and important project to work on, and we are glad that we got to finish it. It is a beautiful legacy of the work we did together with some of our former colleagues: DyanneNova, japerry, and joshuami. Thank you!

"It starts with something small" Next Gen Drupal Themes From 1.0 To 2.5 In a Single Year

Posted by Sooper Drupal Themes on August 30, 2016 at 4:00pm

Just over a year ago I started with something small. I combined some existing technologies to create a drag and drop builder/theme. A combination of jQuery UI, CKEditor, Bootstrap 3 and Drupal. The result was far from perfect but interesting enough to get a bunch of people excited and involved in helping me find out how to improve the product.

Above: our Glazed main demo. Click to view full demo.

Glazed Construction Design, Product Updates

Today's blog celebrates the new Construction design that is available today to all SooperThemes members. We've been working towards this release for nearly a year and the reason it took so long is that the core of the Glazed framework theme and drag and drop builder needed to be 100% up to the job. The reliability, sophistication and flexibility of our framework theme and drag and drop builder are lightyears ahead of the minimum viable product we released 14 months ago. To our customers who joined us in the beginning and are now renewing for the second year: Thank you so much! 

Our construction theme (click to view demo) is not the prettiest design I've ever created but that's not really the point. The point is that it looks like a construction theme all the way. It doesn't look like a generic theme that was customized to look a little bit more "heavy industry". Our Glazed framework theme allows you to completely design every aspect of your Drupal site from typography, to colors, grid design and navigation. Combine this with our drag and drop builder and everything you need in a business website can be designed and developed in the browser. From a blank canvas all the way down to the pages, views and forms everything in this demo was created in the browser, without writing a single line of code

No templates were edited, no CSS was written, not even a single hand coded HTML tag was needed to build this unique 40 page Glazed demo.

For more details about todays products updates check out the Glazed Changelog and Carbide Builder Changelog.

Why WordPress Is Taking Turf From Drupal 

It's simple economics. You can buy a WordPress theme for $59,- USD and a few days of customization and content editing later and your client is impressed and your project is comfortably on schedule and on budget. WordPress themes have become a major source of innovation in recent years, offering drag and drop builders, and niche-specific features for magazine websites, directory websites and all sorts of small business websites.

Themes are becoming more sophisticated and crawling into Drupal territories like for example education, magazines and community websites.

10 years ago I moved away from WordPress and Mambo because I simply felt Drupal was better, and I still feel that way. While these WordPress themes are loaded with features, they lack Drupal's modularity, coding standards and interoperability. I sincerely believe Drupal can be a better platform for all these themes. After all, Drupal has built in support for content types, relations, versioning, configuration management, and superior user management and access control.

Starting from today I will focus on offering as many niche designs for small businesses, large businesses, NGOs, governments, educators and online magazines. I hope that you will join and help us with our mission to show the world that Drupal is capable of doing what WordPress does and more. 

Our mission as SooperThemes is to promote Drupal as the #1 platform to author content on the web and at the same time to remain the #1 provider of designs and design tools for Drupal. See our roadmap for more details. The way to make Drupal the number one choice again is through the same economics that made WordPress so big, so our initial focus is to disrupt the market with a 90% decrease in costs of building and running a Drupal website.

Enjoying The Ride 

The past year has been a big adventure but also a lot of grinding, bug fixing, technical debt problems and all the things that new products face when they enter the market. However it has mostly been fun and exciting to develop these new technologies for the Drupal community and the reception of our updates is really motivating and powering our new developments.

Allthough pioneering in the area of next gen (drag and drop) Drupal themes meant facing a steep learning curve it can be said that Drupal is actually easier to build on in the long term. Our Drag and Drop builder is very similar to a frontend framewor that uses the CMS as an API. This is somthing that needs hooks and AJAX capabilities. Something that Drupal provides out of the box.

If you are reading this as a prospective customer: please join Sooperthemes and enjoy the ride with us. To our existing customers: keep your eyes open for exciting new features and designs. 

Becoming an Appnovator

Posted by Appnovation Technologies on August 30, 2016 at 3:21pm

Drupal 6 Long Term Support is My Favorite Feature of Drupal 8

Posted by Tag1 Consulting on August 30, 2016 at 3:04pm
rfay Tue, 08/30/2016 - 08:04

Long Term Support for Drupal 6 might be my favorite new feature included in Drupal 8. (I know, that might be stretching things for the fundamentally awesome step forward that Drupal 8 is, but bear with me.)

Collection of great free responsive Drupal themes 2016

Posted by InternetDevels on August 30, 2016 at 12:53pm
Collection of great free responsive Drupal themes 2016

According to the best practices of responsive web design, a website neatly adapts to whatever screen it is viewed on. And according to the best practices of our blog, we make collections of free responsive Drupal themes for you to use.

Read more

Hang Out With Some Cool People-- We Are Hiring!

Posted by LevelTen Interactive on August 30, 2016 at 5:00am

Are you looking for a job in the tech world? Have you ever worked at a company that practiced Agile Methodology? Then this is the job for you! 

Who We Are:

We’re a small web development and marketing agency near Southern Methodist University in Dallas, Texas. We like the occasional ice cream socials and NERF gun battles, but most of all, we enjoy making Drupal websites and helping client's businesses grow. 

The Position:

PT Technical...Read more

Join Us for the New DevOps Summit

Posted by DrupalCon News on August 29, 2016 at 9:33pm

We added a new summit to the DrupalCon line-up this year: the DevOps Summit, on Monday, 26 September. It's a day filled with keynotes, an industry leaders panel, open discussions, and networking.

DevOps is a popular part of DrupalCon. There are 12 sessions dedicated to DevOps topics like continuous integration and serverless architecture. But we're excited to add more programming for DevOps fans far and wide. With the summit, we've dedicated time and space to offer networking and collaboration activities.

Bean vs. FPP - Structured content outside of nodes

Posted by Fuse Interactive on August 29, 2016 at 9:12pm

One of the issues I had with Drupal when I first started working on it was how to handle the one-off pages or sections of a site that didn’t fit into something like a Node. Nodes work for repeated pieces of content that will share the same structure, but as soon as we have complicated, one-off pages or sections, we start to need something more.

Internal API Design for Distributed Teams

Posted by Lullabot on August 29, 2016 at 4:00pm

My first real project with multiple distributed teams and a timeline measured in weeks (not months!) was the launch of The Tonight Show with Jimmy Fallon. With six weeks to go from nothing to a CMS, a website, and multiple apps, we were forced to figure out the best way to keep all the teams always moving. I wrote then about Legally Binding your Web APIs, but I think it’s time to clarify and update some of it’s points for maximising your team’s productivity.

Introduce the teams

Before features are defined, APIs are designed, and work is started, it’s really important to have some sort of team introduction. This doesn’t need to be a long meeting. What’s important is to get at least one technical person who will need to create or use APIs from each distinct team introduced. At a high level, identify the API providers and consumers from a business perspective. Determine who owns the APIs and their specifications. Make sure each technical person understands the goals of the project. Then, unless you are one of those technical people, get out of the way! Leave the meeting, drop the call, and let those people get to work.

Lay the API Foundation

Every API makes assumptions - about the basic structure of data, about authentication, and about maintenance and updates. Before determining your core objects, figure these things out. Discuss if you’re implementing an RPC API or a REST API. Decide if you’re supporting JSON, XML, or both. For REST APIs, find a suitable specification that supports the Hypermedia Factors you need, like JSON API or HAL, and use it to structure your data and API to simplify client and server implementations. Decide on authentication protocols, like OAuth or HTTP basic. Decide on a versioning strategy such as versioned URLs or custom MIME types. Steal from existing internal implementations where possible. Finally, start writing code.

The problem with beginning implementations now is that there is no source of truth for the API. It’s easy for teams to start making bad assumptions, leading to rework and putting your launch at risk. Instead, use a tool built for managing API documentation like Apiary’s Blueprint or Swagger. Ideally, the tools will let you easily generate API stubs too. Doing so will unblock client implementations, as they won’t be dependent on the production API to start their work. Best yet, when there is disagreement between implementations, the docs become the arbiter of what is right. Sure, documentation can be wrong or miss key details, but it’s much easier to understand a spec than someone else’s code. Best yet, since the first API consumer will be an involved participant in writing the docs, your API will have docs ready to go when that second consumer comes along.

Now, your teams can start writing code, pulling in the core libraries for authentication and data structures.

Design API Objects

Now that you have the basic API details figured out, you can start to design objects (or in REST parlance ‘resources’). At this stage, you are modelling data, and not actions. Assume every object has a GET call, even if it’s not immediately clear that it’s needed. Letting your clients inspect the state of objects will help them to debug your API and their code without relying on expensive calls and meetings that suck up time from getting things done. Design the object schema to be as “obvious” as possible—don’t use ‘image’ in one object attribute and ‘picture’ in another, unless they mean different things. Use REST best practices such as using URLs as canonical identifiers of objects. A critical step many teams miss is determining who manages unique IDs. With the inherent concurrency and assumed unreliability of HTTP requests, identifying which systems manage which IDs is something not to forget.

Again, at this point you should have new documentation and stubs, but no code. Let your documentation continue to be the source of truth.

Design API Operations

Using your work to this point, API operations should start to have intuitive implementations, especially if you are using REST best practices. Map your various CRUD operations to GET / POST / PATCH / PUT / DELETE as required. Find good HTTP status codes to communicate the results of REST calls (my favourite new discovery is 409 Conflict).

One common mistake services teams make at this point is to create a “wide-open POST endpoint” that accepts arbitrary data, and then to reverse-engineer the data into an implementation. Remember, our goal is to keep any sort of dependencies between the teams to a minimum. This sort of development methodology maximizes the dependencies between the teams, and requires implementations that might be totally wrong. It makes what should be an explicit API contract implicit. When the API calls break, there’s no documentation to fall back on, forcing calls and meetings that block all the teams.

Implement All The Things!

All the work so far has been to get to this point of productivity. By now, there should be no hard dependencies between the teams. Stubs can be replaced by implementations as development continues. New APIs can be added quickly by following the existing patterns. API consumers can even make assumptions about how an API would likely be designed before they contact the API team. Questions and iterations can be focused on tickets and documentation comments, helping to preserve the feasibility of the launch date. Stakeholders, project managers, developers, all win.

Header image from The simplest foundation, a padstone

Waterwheel, the Drupal SDK Ecosystem

Posted by Acquia Developer Center Blog on August 29, 2016 at 3:56pm
actual waterwheel

As Drupal is increasingly widely used as a back end for application ecosystems, developers of wildly diverse backgrounds are now retrieving and manipulating data from Drupal in unprecedented ways. With Drupal 8 and core REST support articulating an API-first vision for the decoupled future, Drupal is eminently well-prepared to back a bevy of applications with divergent approaches. There's just one problem: non-Drupal developers don't know Drupal.

That's where Waterwheel comes in. Waterwheel is an emerging ecosystem of software development kits (SDKs) built by the Drupal community which ease and accelerate development of applications in other technologies. If you will momentarily forgive the flawed metaphor, Waterwheel helps non-PHP and non-Drupal developers "speak" Drupal.

Tags: acquia drupal planet

undpaul, welcome to update management automation!

Posted by Drop Guard on August 29, 2016 at 11:45am

More and more, midsize companies are excited by Drop Guard, recognising the benefits and values of using this tool.

This time we want to present undpaul to you, a Drupal agency from Hannover, Germany, that is built by an enthusiastic team of Drupal developers. Eleven team members support Anja Schirwinski and Johannes Haseitl, founders and CEOs, in their daily effort to please the needs of their customers best.

In doing so, the whole company let Drop Guard support them and let it provide continuous Drupal and website security for their clients. We asked the undpaul about what changed since they started to use Drop Guard on a daily basis.


Drupal Drupal Planet SLA Interview Redmine JIRA Success Story

How To Reduce Your Cost Per Lead in AdWords

Posted by Cheeky Monkey Media on August 29, 2016 at 9:43am
How To Reduce Your Cost Per Lead in AdWords steph Mon, 08/29/2016 - 09:43

Running a campaign in AdWords can be a fantastic way to get more leads for businesses that rely on lead generation. It can also be an expensive money pit, if you’re not doing it right.

We’re going to share with you some fairly straightforward ways of reducing your cost per lead. Our PPC team recently reduced a client’s cost per lead by 178% while increasing the number of leads by 186%. Here is how we did it.


Add Keyword Negatives

Some people advise against using broad match terms altogether. They can be expensive and a big waste of clicks if done incorrectly. When done correctly, however, they can provide you with targeted keywords you might not have thought about (such as competitor terminology or industry slang).

Broad match terms can also provide you with an exceptional list of keyword insights that you can later use to organically optimize your site. This data is gold, so it's why I personally love using broad match terms (where appropriate) with lots of negatives.

Here’s how to find negative keywords to add:

Making a Bootstrap Carousel with Drupal Paragraphs and a Single Twig Template

Posted by Jim Birch on August 29, 2016 at 9:20am
Lego Uncle Jim at the Parthenon

Last week I wrote how to make a multi-column section with Drupal Paragraphs and Bootstrap.  This post describes how to take a similar approach to create a Carousel.  Creating this using Paragraphs allows your content administrators an easy way to add a Slideshow/Carousel to their pages.

I am going to assume that you are including Bootstrap CSS and JS in your theme, and that you have the Paragraphs module installed and have a few Paragraphs already set up.  Go to Structure > Paragraph types to click the Add paragraphs type button.  Add a Paragraph bundle called Slideshow (Also could be called Carousel, Gallery, or Slider depending on you or your company's nomenclature).

Add a field called Slides.  We will use this to add items to the the carousel.  I like to use a reference field to other paragraphs, so we can select Image Paragraphs, Simple Paragraphs, Video Paragraphs, even the Multicolumn paragraph I wrote about last week where it can have additional Paragraphs.  Yes, that would be a Paragraph in a Paragraph in a Paragraph!  All is fair in love and Entity References.

On the Add field screen, in the Add a new field dropdown, select Paragraph under Reference revisions.

Add a field to a Paragraph

Read more

Drupal 8.2.0-rc1 on the week of September 7 and what it means for 8.1.x

Posted by Drupal core announcements on August 29, 2016 at 7:45am
Start:  2016-09-06 12:00 - 2016-09-09 23:55 UTC Event type:  Online meeting (eg. IRC meeting)

Drupal has adopted semantic versioning and a scheduled release cycle starting with Drupal 8.0.0. This means that it is possible within a major Drupal version to add new functionality in a backwards-compatible way, and there is no need to wait for Drupal 9 for improvements.

The second such version, Drupal 8.2.0, is going to be released on October 5th 2016, including the following new experimental modules: Content Moderation (to manage content review workflows), Outside-In (for editing configuration without leaving your frontend), Place Block (to add blocks directly to the page), and DateTime Range (to store end dates on date fields).

To prepare for Drupal 8.2.0, we released three beta versions in August. Announcements for beta1, beta2, and beta3 detail the significant changes made for Drupal 8.2.x. Now, we are getting ready to create Drupal 8.2.0-rc1, the first release candidate, the week of September 7, 2016.

This means several things in terms of support for Drupal 8.1.x versions and allowed patches in Drupal 8.2.x:

  • Starting with the RC, the 8.2.x branch will be subject to release candidate restrictions, with only critical fixes and certain other limited changes allowed.
  • To ensure a stable and timely release candidate, a commit freeze for the 8.2.x branch will begin Tuesday, September 6 at 1200 UTC.
  • The week of September 7 is also the final scheduled patch release window for 8.1.x, and it will not receive further development or support after that date aside from its final security release window on September 21 (which will not include bug fixes). Site owners and module or theme authors should prepare to update to 8.2.x.
  • As a consequence, all outstanding issues filed against 8.1.x will be automatically migrated to 8.2.x after the final 8.1.x patch release. Future bug reports should be targeted against the 8.2.x branch.
  • 8.3.x will remain open for new development during the 8.2.x release candidate phase.

See the Drupal core release cycle overview, Allowed changes during the Drupal 8 release cycle, and Drupal 8 backwards compatibility and internal API policy for more information.

Minor versions like Drupal 8.2.0 may include changes to user interfaces, translatable strings, themes, internal APIs like render arrays and controllers, etc. (See the Drupal 8 backwards compatibility and internal API policy for details.) Developers and site owners should test the release candidate to prepare for these changes.

Drupal Meetup Bangalore – August 2016

Posted by on August 29, 2016 at 6:22am
This month's Drupal meetup was held at Srijan Technologies office in Bangalore on August 27, 2016. This was the first time we had a Drupal meetup in Kalyannagar, or even so far north in Bangalore and as such, we had a lot of new faces. There were around 20 attendees out of 32 RSVP's which is just about the attendance ratio in meetups in Bangalore.

Is Ubercart still relevant now that Drupal 6 has reached EOL?

Posted by d7One on August 28, 2016 at 9:11pm

In this day and age where Drupal 8 is all the rage and while contemplating an end-of-life Drupal 6 Ubercart Store upgrade to Drupal 7 or 8, I wondered if Ubercart was still a relevant alternative? Because if it was, then Ubercart 6.x store owners wishing to upgrade would not have just one but two options to choose from, two chances to find the right fit.

Drupal Commerce logo Ubercart logo

My initial thought was, let's go with the flow and migrate to Drupal Commerce. The main reason behind my sheepish logic: Commerce is the de facto go-to e-commerce platform.

Then, another side of me argued that Commerce's dominance is somewhat artificial and really stems from the fact that commerce-talk dominates the techno buzz channels, grabbing most of the spotlight and in so doing is casting other potential solutions in the gloomy shadows of quasi-oblivion...

In this article, I will share my experience about a recent project for a small town hockey association which, for the past 5 years, has been relying on a Drupal 6 Ubercart 2.x website to automate seasonal registrations for its 350 hockey players. With Drupal 6 now defunct (EOL) and no security team* to provide the required assurance that credit card transactions would be safe, there was little choice but to upgrade at least to Drupal 7 before registration could start.

Drupal Logout Message

Posted by Jay on August 28, 2016 at 3:02am

I recently noticed in Drupal that although there are modules that let you display login messages such as "Log in successful for @username." (LoginToboggan) or "Welcome back, @username." (Persistent Login), there's no easy way to display logout messages.

So after doing some research, I found a patch for Drupal 7 that I just updated to work on the recently released Drupal 7.50. Let's take a quick look at the simple code changes in the modules/user/ file (lines 194 - 214):

1) Before:

* Menu callback; logs the current user out, and redirects to the home page.
function user_logout() {

Tags: Drupal 7Drupal Planet


Subscribe with RSS Subscribe to aggregator - Planet Drupal