Skip to Content

Drupal

Acquia: Acquia Certification Program Ready to Turn 1!

Planet Drupal - 24 February 2015 - 5:55am

After many years of discussion and debate in the Drupal community, Acquia launched the Acquia Certification Program in March 2014. This past year, there were three exams published and offered on a global basis with participants from over 45 countries and several hundred earning credentials. The exams focus on real world experience and the overriding comments we've heard this past year are the exams are tough but fair. There is now a registry posting successful candidates as well.

Most credentials have been earned with the first exam, Acquia Certified Developer, a core exam which cuts across Web Development, Site Building, Front-end and Back-end topic areas. This exam demonstrates an ability to work across these key areas, which in turn helps make successful developers and great team members.

The two following exams, the Acquia Certified Developer - Back-end Specialist, and Front-end Specialist, demonstrate an even deeper grasp of a specialization. Professionals working with Drupal 7 have been testing out successfully as well.

While the current exams are Drupal 7 focused and will continue to be available, we will also have Drupal 8 exams in the coming year.

There is also a new Acquia Certified Drupal Site Builder exam just made available.

Listen to Richard Jones, CTO at i_KOS, talk about his recent experience taking the exam while at DrupalCon Amsterdam, and what it means to him personally, as well as for his business.

Keys to Success: Building Scenario-based Exams

All the Acquia Certification exams are almost entirely scenario based. In this manner, you are testing skills and knowledge instead of just memorization. You are also testing for comprehension in a timely manner, and real world experience is validated through a well constructed and well written scenario-based exam pool.

The scenario for each question is challenging to write, and the test writers draw upon their experiences to do so. The information provided in each scenario is required to answer the related question properly.

To have an exam almost entirely scenario-based is a great accomplishment. We have had an outstanding group of subject-matter experts craft these exam questions based on job task analysis research and they follow sound psychometric best practices.

The latest effort for the Acquia Certified Drupal Site Builder certification exam is no exception.

The Exam Writing Workshop

This month, the Acquia Certified Drupal Site Builder exam was created and the Acquia Certified Developer exam was updated in one combined exam writing workshop. The exam writing workshop is a very intensive and focused effort. The latest effort had a great cross section of the company represented for the workshops, which I facilitated, with Jeff Beeman, Erik Webb, Alex Ward, Adam Malone, Kenny Carlile, and Jonathan Webb serving as Subject Matter Experts.


The exam writers, Subject Matter Experts, are put through a rigorous workshop to write items with supporting documentation. They must agree as a team that each item is relevant, technically accurate and readable.

Several rounds of tech reviews are conducted throughout the workshop and each item must be able to stand up to scrutiny. Test writers have reported that they even dream of test items at night during the course of an intense multi-day workshop, as total immersion to the process is needed to be successful. Team dinners usually end up turning into great debates on something from earlier in the day.

Happy testing!

About Peter

Peter Manijak @PeterManijak: Peter is an experienced Certification and Learning Professional, responsible for creating and managing successful global programs.

Tags:  certification acquia drupal planet cert developers drupal
Categories: Drupal

.VDMi/Blog: Lifting the weight of your website with Kraftwagen

Planet Drupal - 24 February 2015 - 5:33am
This blog/tutorial explains how to convert your website to a Drupal profile which can be deployed using Kraftwagen. This will help you create and maintain a professional website and optimize your workflow.What?

Kraftwagen is a drush extension containing a set of Drupal modules enabling you to get a tighter grip on the distribution and subsistence of your (or your customer’s) website.

With Kraftwagen you can easily set up multiple environments like development, staging and production. It also lets you store configuration settings in your code instead of your database saving you a vast amount of time setting up a new environment. This feature enhances the use of version control so every update can be traced or restored.

Another great feature is the ability to maintain third party code like modules and libraries. You tell Kraftwagen which modules you need and it will download and install them for you. New version? No problem, just change the version number.

How does it work?

Your entire website is stored in a profile. Forget Drupal core and the sites folder. This profile contains your custom modules, your theme and configuration settings. So far nothing new on the horizon.

There are three files that make the magic happen:

  • The make file (your_site.make), which defines all the contrib modules and libraries you want to download. Drush handles this, so still no Kraftwagen involved here.
  • The info file (your_site.info), which defines what modules must be enabled. Just a standard Drupal file.
  • In addition to the previous files, Kraftwagen adds the build.make.tpl, which provides a template for your make file. It defines your profile and Kraftwagen directory, which Drupal version you want to use and optionally which patches you want to apply to it. 

If all files are in place and you are satisfied with your configuration, you just give the build command and wait. Drupal core will be installed along with all your modules and settings. When the build is done, all you have to do is give the update command and you’re good to go.

Easy as pie.

How to start?

Visit http://kraftwagen.org/get-started.html and install Kraftwagen. You’ll also find some instructions here on setting up a new project or update an existing project.

But what if you want to convert your existing non-Kraftwagen site to a Drupal profile? That’s what we will be covering in the following paragraphs.

To Kraftwagen and beyond!

First, create a new Kraftwagen folder because we will create a fresh installation of your site. Now, run the drush command drush kw-np (or drush kw-new-project) inside that folder and enter a human name (like Your Site) and machine name (like your_site). You can just press enter when asked for a skeleton and branch.

You’re folder structure should look like this:

kw/
 src/
   cnf/
   modules/
   themes/
   tools/
   translations/
   .gitignore
   README.md
   your_site.info
   your_site.install
   your_site.make
   your_site.profile

We’ve got ourselves an empty Drupal profile here. Time to merge your existing site in here.

Specify your desired Drupal core version in tools/build.make.tpl in this line:

projects[drupal][version] = "7.23"

Congratulations! You’ve just upgraded your site!

Next, copy all your custom modules to modules/custom/. Now, assuming you don’t know all the contrib modules you’ve been using from the top of your head, we will generate a list from your existing site.

Go to the root directory of your existing site and run drush make-generate. Drush generates a make file with all the modules you have installed. Open it and copy this list into your_site.make in your Kraftwagen folder. Notice that there are already some modules prefilled. If you don’t need them, you can erase all modules except the Kraftwagen modules (starting with kw_).

Next up is checking which modules are enabled in your existing site. Again, go the the root of your existing site and run drush pm-list --type=Module --status=enabled.

Unfortunately, this list is not as user friendly as the generated make file. Copy it and paste it into your_site.info in your Kraftwagen folder. Convert every line to:

dependencies[] = modulename

Preferably grouped and sorted by core, contrib, custom and optionally features. You may remove the prefilled dependencies except for the Kraftwagen ones. You’ll notice there are also env_dependencies, these enable the given module only when the defined environment (like development or staging) is set.

Now the modules part is done, copy your theme folder to src/themes/.

As the final part of the setup, navigate to the src directory and run drush kw-s (or drush kw-setup). When you navigate to the parent directory, you’ll find two new folders: builds and cnf.

Every time you make a build, it will be stored in the builds folder. The foldername always matches the date and time of creation, for example: 20150125-135919 (2015-01-25 13:59:19). Every build gets it’s own directory so remember to remove some old builds in a while to save some space.

The cnf folder holds your settings file and files directory. The environment file defines in what kind of environment you’re working, this would be development, staging or production. Open up settings.local.php and set your database info. Also make sure the files directory is writable and has the correct ownership and permissions. The Drupal handbook provides a useful script which handles this for you, you’ll find it at the bottom of this article: https://www.drupal.org/node/244924.

Build it!

Duplicate your database so we don’t overwrite the existing one. Always make a backup of your database before you make a new build.

Navigate to the src directory and run drush kw-b (or drush kw-build). This will download Drupal core and all contrib modules specified in the make file and copy your custom stuff in site/profiles/your_site/.

It also creates symlinks in site/sites/default/ to the settings.php and files folder in your cnf directory. When the build is finished, a symlink build is created to the newly created build in the builds folder so you don’t need to remember the full build name (20150125135919) and to switch easily between build folders if necessary.

So when the build is successful, you can find your profile in an entire Drupal installation in kw/build/.

Adapt your database

Making a build is not enough. We need to tell our database some major stuff is going on in here. Navigate to kw/build/. Normally, drush kw-u (or drush kw-update) would be sufficient. This enables the modules specified in the info file, executes module updates, reverts all features and runs manifests. All in one command.

However, since this is the first time we’ve made a build from a converted website, we need to do some more.

First, we need to tell our database what profile and theme should be used. This can be achieved by executing the following SQL queries:

UPDATE variable SET value = 's:9:"your_site";' WHERE name = 'install_profile'; UPDATE variable SET value = 's:10:"your_theme";' WHERE name = 'theme_default';

Note that the value is a serialized string, so the number in 's:9' should be the character count of 'your_site'. The same goes for 'your_theme'.

Manually clear the cache with:

TRUNCATE `cache`; TRUNCATE `cache_block`; TRUNCATE `cache_bootstrap`; TRUNCATE `cache_field`; TRUNCATE `cache_filter`; TRUNCATE `cache_form`; TRUNCATE `cache_image`; TRUNCATE `cache_menu`; TRUNCATE `cache_page`; TRUNCATE `cache_path`; TRUNCATE `cache_token`; TRUNCATE `cache_update`; TRUNCATE `cache_views`; TRUNCATE `cache_views_data`;

Then we need to update the registry by running drush rr (or drush registry-rebuild). This is necessary because all contrib and custom modules have moved from sites/all/modules/ to profiles/your_site/modules/.

Now, as finishing touch, we can run drush kw-u.

You may need to clear the cache (drush cc all), point your browser to kw/build/ and you’re good to go.

Conclusion

You’ve just turned your website into an easily manageable and deployable Drupal profile.

Need to add a new module? Just add it to your make file and make a new build. Module update? Just change the version number and make a new build. Or do you want to add a staging environment for your customer to check things out? Make a new copy of your Kraftwagen folder (or clone it if you’re using git), change the environment variable to staging and start building.

You should also notice that basically, the contents of kw/src/ folder are copied to site/profiles/your_site/, which means that if you are using git, you can happily code further in the profiles directory.

There are lots of useful things you can do with Kraftwagen. First get comfortable with the build procedure, then you should also check out manifests and the way patches are handled.

For now, as stated in the conclusion at Kraftwagen.org: Enjoy the ride with Kraftwagen...

Categories: Drupal

Cheppers blog: Rebuilding the Cheppers website with Drupal 8: Brave New World

Planet Drupal - 24 February 2015 - 5:01am

On February 9, 2015 the Cheppers team decided to start rebuilding the company’s website with Drupal 8. At the time, Drupal 8’s version was Beta 6 with 50+ critical issues, 10+ upgrade path blockers, and it was potentially going to be about a year before the stable version’s release.

Categories: Drupal

Aten Design Group: Fast Content Type UI

Planet Drupal - 24 February 2015 - 4:42am

A while ago I made a tool named Sheet2Module, which uses the Config in Code (CINC) module to allow Drupal site builders to make content types and fields directly from Google Spreadsheets. This made a lot of people interested in CINC, but I've found much of that interest was based on a misconception that CINC is focused on spreadsheets. So I recently spent a couple hours making another tool with CINC, to hopefully demonstrate how this is interesting beyond spreadsheets.

Fast Content Type UI is a simple module that lets you edit all your Drupal content types on the same screen. You can't change everything about a content type on that screen, just the things I've found myself adding and editing most often: display name, machine name, and comment status. When that's all you're editing, this is a better, faster UI. And if you need more than that, the standard UI is still there.

And Sheet2Module is also still there. So now you have three very different interfaces for managing your content types in Drupal, or five if you count YAML and PHP as interfaces. The interesting point here isn't really any of these interfaces, it's what these interfaces are hopefully starting to demonstrate: that you can use any interface you want to work with Drupal configuration.

Many of us in the Drupal community spend our days giving clients custom-tailored interfaces to suit their specific needs. Yet when we use Drupal, as administrators, we do our work entirely in the default interfaces. For most of Drupal's history it was a lot of work to create a new interface, because every module managed its configuration in a different way. That's no longer the case. Today it's easy to make your own UI for existing configuration. Fast Content Type UI is one example of that. We should have many more.

Categories: Drupal

InternetDevels: TOP Drupal modules for Views

Planet Drupal - 24 February 2015 - 2:03am

We can’t imagine Drupal without Views. It comes in fresh Drupal installation and new modules are being attached to it as the time passes. This additional modules affect the work of Views, extending the functionality and adding new useful features.

Here is a short review of modules that could be combined with Views successfully. If you’d like to get a detailed instruction about the installation of certain module, go to this module’s Drupal.org page and use readme. Hopefully, this article would be useful for you.

Read more
Categories: Drupal

Appnovation Technologies: Demo of a Free Drupal 8 Theme created with LibSass & Gulp

Planet Drupal - 23 February 2015 - 8:45pm

This post is more of a demo rather than a blog post. I have created a Free Drupal 8 theme called Monoset.

Categories: Drupal

Drupal Easy: DrupalEasy Podcast 145: Route vs. Root vs. Roots (New Tech Cities - Steve Burge)

Planet Drupal - 23 February 2015 - 8:05pm
Download podcast 145

Steve Burge (steveburge), founder of OSTraining.com joins Andrew, Ted, and Mike to talk about a new blog post series about cities transforming themselves into tech-friendly places with smart investment and forward thinking leaders. We also dive head-first into Drupal.org's content strategy, the evolution of Drupal.org forums, and various ways to pronounce the word "route". Picks of the week includes some free videos, BackDrop on Pantheon, and DrupalCon India.

read more

Categories: Drupal

Drupalize.Me: More Drupal 8 Insights

Planet Drupal - 23 February 2015 - 6:00pm

Last month, we posted a survey regarding your plans for learning Drupal 8. This was a follow-up to a similar survey we posted back in May, 2014. The responses we received in both instances were remarkably consistent, which is reassuring as we begin to publish our Drupal 8 tutorials. Here are a few big take-aways from our Drupal 8 surveys and some insight into our plans for Drupal 8 tutorials.

Categories: Drupal

Cheeky Monkey Media: Drupal Association Board of Directors - At-Large Position

Planet Drupal - 23 February 2015 - 4:48pm

This year the Drupal Association Board of Directors has an opening for a single director At-Large position. With this opening, the association reached out to the community to allow anyone to self nominate for the position. As of the closing of the nomination round, there were 24 candidates, from 14 different countries, which I think is an incredible testament to the community.

When I saw this opportunity, I decided to ...Read More

Categories: Drupal

Underscore

New Drupal Modules - 23 February 2015 - 4:29pm

This is an experiment

Categories: Drupal

DrupalCon News: Come Discuss the Future of Drupal at Core Conversations

Planet Drupal - 23 February 2015 - 3:42pm

Core Conversations is a place for people actively working on and contributing to Drupal core to meet, discuss and plan the future of Drupal.

Drupal 8 is very close to having a stable upgrade path, and the number of remaining critical issues is steadily decreasing. The timing of DrupalCon LA means that the focus on talks should be on the future of Drupal, either the short term of 8.1.x, or the future of 8.y.x, or even as far as Drupal 9.

Categories: Drupal

Dcycle: Continuous integration with Circle CI and Docker for your Drupal project

Planet Drupal - 23 February 2015 - 1:58pm

Continuous integration (CI) is the practice of running a series of checks on every push of your code, to make sure it is always in a potentially deployable state; and to make sure you are alerted as soon as possible if it is not.

Continuous integration and Drupal projects

This blog post is aimed at module maintainers, and we'll look at how to use CI for modules hosted on Drupal.org. I'll use as an example a project I'm maintaining, Realistic Dummy Content.

The good news is that Drupal.org has a built-in CI service for hosted modules: to use it, project maintainers need to click on the "Automated Testing" tab of their projects, enable automated testing, and make sure some tests are defined.

Once you have enabled automated testing, every submitted patch will be applied to the code and tested, and the main branches will be tested continually as well.

If you're not sure how to write tests, you can learn by example by looking at the test code of any module which has automated testing enabled.

Limitations of the Drupal.org QA system

The system described above is great, and in this blog post we'll explore how to take it a bit further. Drupal's CI service runs your code on a new Drupal site with Drupal 5.3 enabled. We know this by looking at the log for a test on Realistic Dummy content, which contains:

[13:50:02] Database backend [mysql] loaded. ... [simpletest.db] => [test.php.version] => 5.3 ...

For the sake of this article, let's say we want to use SQLite with php 5.5, and we also want to run checks from the coder project's coder_review module. We can't achieve this within the Drupal.org infrastructure, but it is possible using Docker, CircleCI, and GitHub. Here is how.

Step 1: get a local CoreOS+Docker environment

Let's start by setting up a local development environment on which we can run Docker. Docker is a system which uses Linux containers to run your software and all its dependencies in an isolated environment.

If you need a primer on Docker, check out Getting Started with Docker on Servers for Hackers (March 20, 2014), and A quick intro to Docker for a Drupal project.

Docker works best on CoreOS, which you can install quite easily on any computer using Vagrant and VirtualBox, as explained at Running CoreOS on Vagrant.

Step 2: Add a Dockerfile to your project

Because, in this example, we want to run tests which require changing things on the server, we'll use the Docker container management system to simulate a Ubuntu machine over which we have complete control.

To see how this works, download the latest dev version of realistic_dummy_content to your CoreOS VM, take a look at the included files ./Dockerfile and ./scripts/test.sh to see how they are structured, then run the test script:

./scripts/test.sh

Without any further configuration, you will see tests run on the desired environment: Ubuntu with the correct version of PHP, SQLite, and coder review. (You can also see the results on CircleCI on the project's CI dashbaord if you unfold the "test" section -- we'll see how to set that up for your project later on).

Setting up Docker for your own project is just a question of copy-pasting a few scripts.

Step 3: Make sure there is a mirror of your project on GitHub

Having test results on your command line is nice, but there is no reason to run them yourself. For that we use continuous integration (CI) servers, which run the tests every time someone commits something to your codebase.

Some of you might be familiar with Jenkins, which I use myself and which is great, but for open source projects, there are free CI services out there: the two I know of, CircleCI and Travis CI, synchronize with GitHub, not with Drupal.org, so you need a mirror of your project on GitHub.

Note that it is possible, using the tool HubDrop, to mirror your project on GitHub, but it's not on your account, whereas the CI tools sync only with projects on your own account. My solution has been to add a ./scripts/mirror.sh script to Realistic Dummy Content, and call it once every ten minutes via a Jenkins job on my personal Jenkins server. If you don't have access to a Jenkins server you can also use a cron job on any server to do this.

The mirror of Realistic Dummy Content on GitHub is here.

Step 4: Open a CircleCI account and link it to your GitHub account

As mentioned above, two of the CI tools out there are CircleCI and Travis CI. One of my requirements is that the CI tool integrate well with Docker, because that's my DevOps tool of choice.

As mentioned in Faster Builds with Container-Based Infrastructure and Docker (Mathias Meyer, Travis CI blog, 17 Dec. 2014), it seems that Travis CI is moving towards Docker, but it seems that its new infrastructure is based on Docker, but does not let you run your own Docker containers.

Circle CI, on the other hand, seems to provide more flexibility with regards to Docker, as explained in the article Continuous Integration and Delivery with Docker on CircleCI's website.

Although Travis is a great, widely-used tool (Drush uses it), we'll use CircleCI because I found it easier to set up with Docker.

Once you open a CircleCI account and link it to your GitHub account, you will be able to turn on CI for your mirrored project, in my case Realistic Dummy Content.

Step 5: Add a circle.yml file to your project

In order for Circle CI to know what to do with your project, it needs a circle.yml file at the root of your project. If you look at the circle.yml file at the root Realistic Dummy Content, it is actually quite simple:

machine: services: - docker test: override: - ./scripts/test.sh

That's it! Commit your circle.yml file, and if mirroring with GitHub works correctly, Circle CI will test your build. Debug any errors you may have, and voilà!

Here is the result of a recent Realistic Dummy Content build on CircleCI: unfold the "test" section to see the complete output: PHP version, SQLite database, coder review...

Conclusion

We have seen how you can easily add Docker support to make sure the tests and checks you run on your code are in a controlled environment, with the extensions you need (one could imagine a module which requires some external system like ApacheSolr installed on the server -- Docker allows this too). This is one concrete application of DevOps: reducing the risk of glitches where "tests pass on my dev machine but not on my CI server".

Tags: planetblog
Categories: Drupal

Orbital Cache Nuke

New Drupal Modules - 23 February 2015 - 1:30pm

orbital_cache_nuke
Dependencies

Autoslave

Version / Author
1.0 Justin Slattery Justin.Slattery@mlssoccer.com

Description
This module allows asynchronous remote cache invalidation between replicated Drupal environments. Available for Drupal 7.

See this blog post for details on how it works and integration.

Categories: Drupal

Duplemail - Email Address Username Filtering

New Drupal Modules - 23 February 2015 - 12:16pm

The purpose of this module is to provide for duplicate email address checking for domains that allow extraneous characters to be placed inside usernames and be treated as different email addresses. For example:

mrbagnall@gmail.com
m.rbagnall@gmail.com
mr.bagnall@gmail.com

Categories: Drupal

tombola: Making a Drupal Distribution #1

Planet Drupal - 23 February 2015 - 8:59am

Recreating and simplifying a multiple site platform by creating a re-usable distribution.

#1 Getting started.

Categories: Drupal

valechatech: Hack Proof your drupal site

Planet Drupal - 23 February 2015 - 6:51am

Security of the Drupal website is a important stuff for the site owners, site developers.This blog post has my presentation at the Drupal Camp Mumbai that  intended for Drupalers who want to avoid security loop holes while writing code or architecting solutions. We delved into common security issues that ails custom code and has both vulnerable and secure code snippets.This is mostly about my encounters and experience after doing 50+ project application reviews and also a good guideline for new contributors.



Hack Proof Your Drupal Site from Naveen Valecha


Next article:  A guide to review Project Applications.
Categories: Drupal

Mark Shropshire: Charlotte Drupal Drive-in 2015 Wrap-up

Planet Drupal - 23 February 2015 - 6:49am

Last Saturday (February 21st, 2015), thirty-five Drupalers joined together at Classic Graphics for the sencond annual Charlotte Drupal Drive-in. The day was full of presentations, BOFs, and general chatting about Drupal and related web technologies.

The day-long, un-conference-style event was the brainchild of Thomas Lattimore. After CharDUG wasn't able to pull together the human resources to repeat the success of DrupalCamp Charlotte 2012, Thomas mentioned that he had an idea. Since he knew organizers had limited time to commit to planning and he wanted to host an un-conference-style event, allowing for simpler planning than a full-blown Drupal camp. You can learn more about his concept on the DruaplEasy Podcast.

The event started with breakfast goodies, a welcome to the event, a thank you to our sponsors, and session pitches. The list of pitched ideas quickly grew to enough items to easily fill the day with sessions. The organic nature of the event and Classic's space allowed for sessions to split into multiple rooms so individuals had great session options.


1 day ago by Mark Shropshire

The session schedule was planned for the day after all the ideas were pitched. The scheduled sessions included the following:

Lunch allowed attendees to chat about the morning sessions and meeting each other. Also, Design Hammer provided a $50 Amazon gift card to giveaway during the lunch break.

From my perspective, the event was a success. The format allowed for a relaxed atmosphere where beginner and seasoned Drupalers alike were able discuss their projects, ideas, and questions. While much of the group was from the Charlotte metro area, we also had attendees from Asheville and the Raleigh/Durham, NC area. I also count this event as a success when all of the event volunteers were able to attend the sessions and enjoy the event. Keeping the event simple is key to this success!


1 day ago by Mark Shropshire

I would like to thank Classic Graphics, Design Hammer, and our individual sponsors (@bayofodeke, @deetergp, and @shrop for supporting the Charlotte Drupal Drive-in. Also, thanks to all those who attended and led sessions. Looking forward to Charlotte Drupal Drive-in 2016!

Blog Category: 
Categories: Drupal

Event Data Store

New Drupal Modules - 23 February 2015 - 4:03am

This module is intended to log events, and aggregate the data so it can be displayed with Views.

It's features exportable, and allows for logging various events with the possibility to add custom ones via a hook.

Note for the aggregation of data to work your sites Cron must be working and configured to happen regularly enough to aggregate data as often as you want.

Categories: Drupal

Annertech: Create the WOW Factor with Drupal - Part 1 of 5

Planet Drupal - 23 February 2015 - 3:16am
Create the WOW Factor with Drupal - Part 1 of 5

Creating 'wow' is something we all need to strive for. It's that extra element of pleasure that someone derives from something we've done. The key to wow is in its unexpected nature. It's in the unexpected pleasure from stylish subtleties in a design that leaves you going "nice!". It's in those clever extra features a user discovers after a while using a site, which they now realise they just love. It's about delivering that little bit more.

Categories: Drupal
Syndicate content


Google+
about seo