Drupal News

Recently, I had the special fun of migrating a new client’s site over to a new host. Everything was going smoothly and quickly until I got to the Files folder. It contained a 4-gigabyte hodgepodge of images, thumbnails, pdfs, known site backups and unknown site backups (Yes, unknown! I don't count the WordPress version of the site from six years ago as a "known about" backup). It got me thinking about one part of Drupal that I think many take for granted: The Files system. Drupal is three-part system: Database, Code and Files. When planning a site architecture, often the Files folder gets treated like the red-headed step child of the three; forgotten, neglected and rather ignored.

However, that’s not the way it should be. Drupal is a content management system. No matter what type of content, whether doc, image, or a PowerPoint on how many kittens and puppies it takes to make a good calendar, Files are just as much content as the text describing said cute kittens and puppies. And this type of content is much easier to manage then most people think.

I’m not talking about the Media module, a hopeful dream of the Drupal world that I still believe in and could still use some more loving. I’m just talking about what comes after "sites/default/files/..." When writing new content, we often upload files and images along with our post about how our cat fell asleep in the kitchen sink. Instead of just having all those images and files placed first level in the Files folder, why not have them go into a "blog" folder or a "fluffy" folder. That way we don’t need to look at 10,000 images upon opening the Files folder.

When adding a file upload field to a content type, you can set a default path to house the files that will be uploaded. Using tokens, you can create default path structures that handle all the folder architecture for you. I like to separate folders by content type, year/month/day uploaded, taxonomy term, and/or type of file. An example token setup for a default path may look like this: [node:content-type]/[node:created:short] or [node:content-type]/[node:nid].

The benefit is that whenever I go into the Files folder, I have instant information about the files contained inside. An image with the name of 348jkdldhisoj.png is not helpful to me, but if it’s located at say "sites/default/files/blog/may2013/img/cat_photos/348jkdldhisoj.png," then I have a good idea of what that image is. If you are naming a folder without the use of tokens, be descriptive as to what that folder actually contains. Don’t label it “images” and expect the world to know what that universally means.

The point I’m making is you don't have all of your files on your computer located on your desktop, do you? No, you have them in human-readable, ordered folders. When I’m looking for my legally downloaded episodes of Family Guy, I don't want to have to look through a folder that also contains clips of my sister’s cat getting scared by his own image in the mirror (although that one always makes me laugh when I come across it). So put the same thought into your Drupal sites/default/files folder. Your site, the cats of the web, and your local Drupal support guy will appreciate it.

On a current site in development I am using Ubercart to provide a renewable subscription service. To make the user experience clean, I wanted to protect the user from going 'shopping' to add their subscription. To do this I decided to use a rule to add the product to the user cart when the user is created by an administrator or when the subscription is cancelled or fails payment. I tried the Ubercart Rules module, but this is mainly for dealing with orders and not carts, and did not contain the needed add to cart rule.

read more

I've been looking at various LiveChat modules for Drupal sites and after testing a number out I finally found one I liked, Zopim LiveChat.

It's slick, quick and provides all the basic requirements plus a few neat additional things such as user stats, history, visitor lists, customisable sounds. If you wanted you could have unlimited chats for $11.20 a month or the full version for only $20 a month!

read more

Drupal's editorial experience has improved considerably over the past several releases, and Drupal 8 promises to be even better. However, it's still easy for writers and editors to collide with each other when they collaborate. If two people edit the same piece of content at the same time, one user's changes are inevitably lost. Fortunately, the Content Locking module is ready to help.

Drupal's editorial experience has improved considerably over the past several releases, and Drupal 8 promises to be even better. However, it's still easy for writers and editors to collide with each other when they collaborate. If two people edit the same piece of content at the same time, one user's changes are inevitably lost. Fortunately, the Content Locking module is ready to help.

AttachmentSize dcgbrg.jpg550.49 KB drupalcamp-gothenburg-2013.png929.38 KB gothenburglogo.png80.91 KB

Adam Evertsson is the head honcho behind DrupalCamp Gothenburg two years in a row, member of the Swedish podcast Drupalsnack and always fond of the community, both locally and globally. He really came for the code and stayed for the community. 

After visiting a DrupalCamp in 2011, I set off with a mission - to arrange a DrupalCamp in my hometown of Gothenburg. This became a reality only 5 months later and with the experience from that said camp of 2012 we set off to make the next one even better.

And at the time when drupalers from all over the world started their journey back home from DrupalCon Portland, or stayed for the sprint weekend, a similar, but much much smaller event took place some 7700 kilometers away. That event was DrupalCamp Gothenburg 2013.

I took the role of project manager again and together with 12 others, we arranged a great DrupalCamp - or should I say, a Drupal Weekend!

A Drupal weekend in Gothenburg

We turned our DrupalCamp into a real Drupal weekend, starting with a kickoff at a local pub. There, a number of us started (and ended) Friday night with discussions covering Drupal, PHP, Symfony and Swedish things like surströmming and, of course, the sunny weather. As a Swede, you always discuss the weather.

Friday turned into Saturday and in the morning we opened the doors of our venue of this year’s DrupalCamp Gothenburg, Folkets Hus - the House of the People, a community area with many rooms, perfect to hold sessions in.

This year, we were glad to present a full schedule, 15 sessions, that covered the whole day. The keynote was held by Tobias Sjösten, a well-known voice in both the Drupal and Symfony community in Sweden, and covered the symbiosis of Drupal and Symfony.

The sessions consisted of very diverse things, from web accessibility to Drush, via Git and Drupal 8. A whole session was dedicated to inform about Drupal Association and community-based work in Gothenburg.

After the sessions (and a lot of coffee) we headed upstairs to the restaurant in the same building where we dug into a buffet provided by the restaurant at the venue. With a beer in our hands we continued the evening with mingling, networking and enjoying ourselves. The sunny weather invited us to sit outside and when the place closed later that night, some of the attendees headed off to a club downtown.

Sunday came around and whilst we who arranged the DrupalCamp gathered for a well-deserved lunch together, others gathered at the office of Kodamera where there was a code sprint to help get rid of more bugs from Drupal 8.

From start to end, a 48 hour ride with Drupal as the common denominator, that was the final of some six months planning and work.

Tips and tricks for organizing a camp

When we arranged our first DrupalCamp in 2012 we ended up with a long list of things to improve. This year, all of the things on the list was improved, and we ended up with another list of things to improve for future DrupalCamps. With these kind of iterations, we learn and make better DrupalCamps in the future.

So what did we improve this year? What advice can I give to all you out there planning or arranging DrupalCamps all over the world?

The most important is to listen. Listen to your visitors, sponsors and session speakers. Ask them about their ideas and their feedback about your camp. Use that information to plan and improve your camp next time. If you’re a first time camp-organizer, then seek this kind of information from your local Drupal community, or post a thread in groups.drupal.org

When the camp is over, send out a survey to get feedback from all of those that you didn’t have time to talk to.

Second most important is to have fun. Make place for fun. Our camp is 100% community-driven so besides the experience, fun is an important ingredient to make all this work.

Look in the calendar and see what’s going on. Choose a date when your camp doesn’t have to compete with other major Drupal events. In our case, we ended up very close to another camp in Sweden, and of course, DrupalCon Portland. Date-wise, we didn’t really have a choice when to have our DrupalCamp before the summer would be here, and we ended up paying for it with less visitors.

Another thing is to launch a website early, and try to set a schedule with sessions early. That attracts both visitors and sponsors.

My last tip for all you out there: Avoid growing pains by growing slowly. Start off with a one-day event, then add a code sprint next time, after that perhaps a kickoff the following and then start experimenting with business days connected to your DrupalCamp. For us, we are somewhere in the middle, we have a great camp, and in the future we’ll explore the many possibilities a DrupalCamp can offer.

  Personal blog tags: drupalcamps

Adam Evertsson is the head honcho behind DrupalCamp Gothenburg two years in a row, member of the Swedish podcast Drupalsnack and always fond of the community, both locally and globally. He really came for the code and stayed for the community. 

Personal blog tags: drupalcamps

DrupalCamps are to DrupalCons what Small Colleges are to Universities. The same great education, the same outstanding curriculum...but in a smaller, more intimate setting.  At a small college, students have more direct contact with their professors — at Camps, attendees get face-time with Drupal experts.   That's why we love to participate in camps.     We make a habit of attending as many camps as we can, and often contribute talks and sponsorships when we are able. So when DrupalCamp Paris was announced, we couldn't miss the opportunity to submit as many talks as we could... considering it was in our own backyard!   We've assembled a large crew of Commerce Guys to attend, as well as invited some of our Marketplace partners to meet the Drupal community in person. We'll be available throughout the camp June 21, 22 & 23 to answer questions about Drupal Commerce, Commerce Kickstart, Commerce Mobile... and if you ask really nicely, we'll even show you Commerce Platform, our new cloud based platform solution for smarter development.   For a full schedule of the camp and to get registered, visit: http://paris2013.drupalcamp.fr/   Here's where you find us over the three days:   Time Title Speaker Friday, June 21 11:00 10 steps needed to start your eCommerce store with Kickstart! Augustin Delaporte & Jonathan Sacksick 12:00 Agility: How SCRUM and Drupal are made ​​for each other Julien Dubois 12:00 Know and Master your tools! Nicolas Meyer 12:00 Round Table "eCommerce Payment Solutions" Speakers TBD 14:30 To make your store a good shop Jonathan Kuma & Anne-Sophie Picot 15:30 Introducing Drupal 8 Leon Cros & Shannon Vettes 17:00 Why and how to contribute to Drupal 8 Leon Cros & Shannon Vettes 17:00 eCommerce Delivery "Round-Table" Speakers TBD Saturday June 22 9:45 UNLEASH Drupal! Use of Drupal concepts and magnify your backend Laurent Chardin & Julien Dubois 16:20 Twig Olivier Pierre & Julien Dubreuil Sunday June 23 10:00 Code Sprints All Day

 

Our Speakers
Augustin Delaporte
Jonathan Sacksick
Julien Dubois
Anne-Sophie Picot
Shannon Vettes
Nicolas Meyer
Julien Dubreuil

 

 

 

Tags: Planet DrupalDrupalcamp

• Français

drush aliases allow you to run a drush commands on your local server but actually execute the command on a remote server. This is a real time saver when working locally and then you want to do something on the remote server. Your specific workflows will depend on your particular setup but, as an example on Acquia dev cloud, how about pushing code up to your remote dev server and running updatedb in two commands.

$ git push origin $ drush @site.dev updatedb -y

Setting up your local computer to use an alias needs a little configuration. Alias configuration files can go into a .drush folder in your home directory. You can add as many alias files as you like here with the naming convention:

sitename.aliases.drushrc.php

Each file can contain any number of aliases descriptions which are just entries in a multi dimensional array, the key of which is the subitem for that alias. For example, an alias file called mysite.aliases.drushrc.php with one dev entry like this ...

$aliases['dev'] = array( 'parent' => '@parent', 'site' => 'mysite', 'env' => 'dev', 'root' => '/var/www/html/mysite.dev/docroot', 'remote-host' => 'example.myserver.com', 'remote-user' => 'mysite', );

... gives one alias which is accessed via the @mysite.dev drush argument. For example,

drush @mysite.dev status

There is also a drush command to get you started on producing an alias drushrc file:

drush sa [uri] Holy Cow! What else can I do with drush aliases?

I am glad you asked. How about download the remote db in one command ...

drush @mysite.dev sql-dump > /tmp/dbdump.sql

Note: don't use --result-file here as that will put the sql file on the remote server!

How about bring all the remote files down to your local system? From the root of the site on your local install run ...

drush rsync @mysite.dev:sites/default/files/ sites/default/files/

Note: Run drush help rsync for help with this one!

Notes on Acquia and Drush aliases

We often use Acquia dev cloud to host our client's sites. On Acquia hosted sites setting up local drush aliases are made very simple. Under the cloud menu on the subscription tab there is a utility link which describes exactly how to add the alias files to your local computer.

Acquia executes drush commands using drush 4 by default. To use drush 5, you'll need to edit your alias files in the .drush folder and for each environment add a path-aliases entry which describes which drush script to execute. The precise syntax is shown below.

$aliases['dev'] = array( 'parent' => '@parent', 'site' => 'mysite', 'env' => 'dev', 'root' => '/var/www/html/mysite.dev/docroot', 'remote-host' => 'mysite.com', 'remote-user' => 'mysite', 'path-aliases' => array( '%drush-script' => 'drush5', ), ); Other reading

This link shows all the goodness that can be put into a sites drushrc file ... http://drush.ws/examples/example.aliases.drushrc.php

Read moreDrupal, Drush aliases and how to use themBy John Ennew | 10th June 2013

It sometimes seems to me, that there are two different types of Drupal module maintainers: the ones who create a stable 1.0 release as soon as any code is working; and those who leave their modules "unstable" for years until they finally pluck up the courage to go 1.0. (I guess there also have to be some with the right middle approach, but those propably just don't catch one's eye as much.) There are actually projects in the top 10 of contrib module usage without a stable 7.x release (although there may of course be good reasons for that).
Anyways, in that pattern I'm definitely one of the latter group. I have only recently gotten to eventually creating stable releases for a number of modules (though some of them already had several thousand users) – Search API Database search (over 11k users) and Search API Pages (almost 3k users) are still waiting – and the 1.0 release of the Search API itself also took extremely long (by which time it also already had over 2000 reported* users).

In that context, it is kind of a milestone that there is now finally a 1.0 release of the Search API Solr Search module. (If you are not familiar with it, it's pretty self-explanatory: it allows you to use Apache Solr with the Search API.) As with the other modules, it had already been production-ready for quite some time, and currently has almost 5000 users.

In the case of the Solr Search module, though, there were several good reasons to wait with a stable release – foremost, the Apache Solr Common Configurations project, though definitely a good thing, changed the configuration files quite drastically when the module was otherwise stable. We also managed to add numerous feature (like location search support) and fix a lot of bugs, but those would have probably worked as well in subsequent minor releases. There were some other major refactorings, though, (foremost the effort to get rid of the external library dependency) whose inclusion in the 1.0 release is definitely beneficial.

Additionally, for the Solr Search module the 1.0 stable release is also kind of a promise: with it, I'm saying that I'm now confident that no major changes to the config files will be necessary anymore, so that there won't be the necessity for re-indexing the content for future new (minor) releases. Time will tell whether I'll be able to keep that promise but, as said, I'm quite confident.

So, if you shied away from giving the module a spin in the past, due to its missing stable release: it has been ready for quite some time now, but now it's official!
For all existing users: upgrade to the new stable release and see if there are features or bug fixes that help you out (or, hopefully not, any bugs you can report)! Recent additions include support for SSL, field collapsing, Solr 4.x and location-based searches.
(Also, check out the new documentation, if you haven't done so already!)

* By the way, is there any data or estimations out there on what percentage of users the Drupal.org usage statistics actually capture?

Image credit: Sergey Melkonov

Tags: Search API SolrPlanet Drupal

Jared Ponchot and Jeff Robbins chat with Josh Higgins about his work as Design Director of the Obama 2012 Campaign. They discuss managing large creative teams, the importance of culture and lots more fascinating insights about the political campaign process.

• JoshHiggins.com
• BarackObama.com
• Shepard Fairey
• Illustrator Rafael López
• Designing Design Teams - Martin Ringlein

Josh Higgins on the Obama 2012 Campaign, managing creative teams, culture and more

When was the last time your website had a facelift or you audited your Drupal modules, site security, SEO, etc?

We believe website redesigns fundamentally fall into two categories: the right and the wrong.

The right way delivers true value to an organization and the wrong way just consumes time and money for window dressing—which does nothing for your bottom line. 

Recently a few of our teammates gathered our thoughts around Drupal website redesigns. As we talked through the different areas we coach our customers on, we decided to put them into one eBook.

"Preparing for a Drupal Website Redesign" is a collection of important suggestions your organization should consider before embarking on your next website design. Suggestions such as:

Hi!

We are working on https://github.com/antistatique/capdrupal for some months now. This is a capistrano recipe to deploy drupal website. It works with multistage...

It's far from perfect but feedback more than welcome, please use the issue at github.

Following on from the first blog post in this series, An Introduction to Test Driven Development, Chris introduces the test harness so strap yourself in!

My first experience of work "in the real world" came through work experience. I was lucky enough to get one of only two placements with IBM at Havant and my assigment was to build to specification the wiring loom used to connect the IBM 3745/3746 communications controller to its test harness. These units had to be regularly and thoroughly tested throughout production and so periodically each unit was hooked up to a test harness by means of the aforementioned wiring loom so that a range of tests could be executed against the unit and pass/fail reports and data collated. My time at IBM provided a fabulous insight into engineering/testing and firmly cemented in my mind the concept of a test harness.

In software development, a test harness provides exactly the same functionality, it provides a means of executing tests against software and giving feedback on whether the software is behaving as expected.

The specific test harness you choose will likely vary from project to project and is dependant on a number of factors, the coding language of the project and experience of the developers and test engineers involved may have an impact on the decision making process, a Google search for "test harness for language x" will no doubt turn over a number of options for each language and whilst there’s no hard and fast rule that your test suite and project code language must match, the skillset of the team surely will play a part.

Another major consideration should be around the types of test you want to execute, (unit, integration, system, acceptance etc) as some test harness frameworks lend themselves more towards one or a subset of types. You can of course use more than one test harness if it makes sense for your project with each providing different elements of a test plan strategy: unit tests running on every build and full smoke and functional tests running on release for example.

Consideration also needs to be given to the development methodology being applied - perhaps PHPUnit is a best choice if a purely Test Driven approach is adopted, on the other hand, Behat is a clear winner for Behaviour Driven Development.

I'll leave the last key point for consideration till the end! First, let's briefly review 4 popular test frameworks.

SimpleTest

For those of us working with PHP (and specifically Drupal), there are a number of options. Coupled closely with Drupal is SimpleTest which was moved to core in Drupal 7. It's modeled on the open source SimpleTest unit test framework so those familar with its suite of assertions will be comfortable and will get the extra benefit of helper methods such as drupalLogin(), drupalLogout(), drupalCreateNode() and drupalCreateUser() for establishing fixture[1].

Here's an example of a user login test in SimpleTest taken from the user module and modified slightly for clarity:

<?php /** * User login test. */ class UserLoginTestCase extends DrupalWebTestCase { public static function getInfo() { return array( 'name' => 'User login', 'description' => 'Ensure that login works as expected.', 'group' => 'User', ); } /** * Test that a user can login. */ function testUserLogin() { $user = $this->drupalCreateUser(array()); $this->drupalLogin($user); } }

As you can see, tests are expressed in PHP code and SimpleTest provides a number of assertions that can be used.

I won't go into much detail here about SimpleTest as many good blog posts already exist about its use and limitations (duration of test run being a major issue which SimpleTest Clone seeks to address, some have had success with switching to MyISAM for tests and others, along with Drupal Quality Assurance have adopted ramdisk with a mixed outcomes it seems.)

Code Enigma offers high performance Drupal hosting with built in support for running automated tests, see our http://hosting.codeenigma.com/faq for more information or get in touch if you'd like to talk it through.

PHPUnit

PHPUnit is a popular open source PHP test framework created and maintained by Sebastian Bergmann which, from its name, is a good choice for unit testing although you can combine it with other libraries, Guzzle and Selenium Server for example enabling browser automation for functional and acceptance testing.

I personally find PHPUnit invaluable and use it on a daily basic, tests are easy to read, write and are quick to run if you're actually doing true unit testing. Of course, that in itself raises a challenge when working with Drupal where dependencies are commonly requested rather than injected. Drupal 8 is heading in the right direction with Mark Sonnabaum leading the introduction of PHPUnit tests in the upcoming release. I recommend watching the video of his recent Drupalcon Portland session on the subject.

A really basic example PHPUnit unit test:

<?php /** * Adds two numbers and returns the result. */ function add($a, $b) { return $a + $b; } class AddTest extends PHPUnit_Framework_TestCase { public function testadd() { $this->assertSame(3, add(1, 2)); } }

Once again, tests are expressed in PHP code with PHPUnit providing perhaps a slightly richer set of assertions than you get with SimpleTest.

Behat

Created by Konstantin Kudryashov, Behat is the PHP Behaviour Driven Development enabler for PHP projects - it enables composition of human readable tests (in Gherkin) that Behat turns into executable acceptance tests. This is the beauty and strength of BDD (and Behat), together they provide a means whereby business owners, developers, project managers and testers can frame requirements in a common language, the language of the business domain and from there derive a suite of acceptance tests that indicate delivered value.

The DrupalExtension module provides additional step definitions for some of the basic operations normally performed on a Drupal site, in addition it provides support for regions defined in the theme layer for more accurate querying of the user interface.

I recently gave a talk about BDD and Behat at the North West Drupal user group - you may find my slides and code helpful.

An example feature and scenario:

Feature: Login As a visitor I want login So that I can manage my account Scenario: A user enters their credentials and logs in successfully Given I am on "/" And I fill in "admin" for "name" And I fill in "letmein" for "pass" When I press the "Log in" button Then I should see "My account"

Expressed in a structured language called Gherkin, Behat along with the Mink extension can take this feature and turn it into an executable acceptance test without the need to write any PHP code.

Codeception

Codeception is a PHP framework created and maintained by Michael Bodnarchuk. It enables acceptable, functional and unit testing which are created by expressing context, actions and expected behaviour in simple expressive PHP code.

At the time of writing, Codeception has switch on module support for a number of PHP projects such as Symfony, Laravel, Yii and ZF but unfortunately no-one has written the equivalent for Drupal yet. Keep an eye on Mike Bell and Paul Byrne who have both written very good blog posts about Codeception, Testing with Codeception and Drupal Projects and More testing with Codeception and Drupal projects

An example Codeception test:

<?php $I = new WebGuy($scenario); $I->wantTo('ensure that frontpage works'); $I->amOnPage('/'); $I->see('Home');

Tests are composed in simple expressive PHP code.

Conclusion

It's perhaps now apparent that whichever test framework you choose, the end result is much the same: tests are executed either directly against code (unit testing) or against the site itself (functional/acceptance testing through browser automation) and the failures are reported in some way. The key variant these frameworks offer, and in my book, the most important element for consideration is the input. Answering the following pivotal question helps:

How best can tests be expressed for this project and the people involved in its delivery?

Although not explicit, you might want to include the client when you consider the people involved!

Footnotes

1. A fixture is a known application state which tests will run against, establishing a fixture is the work you do to get to that know state, perhaps the creation of a user for example.

Related Service Areas: DevelopmentTeaser: TDD is a daunting prospect for the newcomer, but Chris Maiden explains it's not so hard to get goingCategories: CommentConsultancyDevelopmentDrupal PlanetPrimary Category: DevelopmentTags: test driven developmentagiletestingsoftware qualitysoftware engineeringtdd

An essential feature of a dynamic site would be to let its users add some contents to it. Often this is done using HTML forms. Drupal offers a rich and relatively simple way to use API for building forms for its Developers. In Drupal parlance it is referred as Form API (or FAPI).

Google Plus One Linkedin Share Button Tweet Widget Facebook Like

Responsive Navigation is a cool Drupal module that incorporates the responsive-nav.js plugin into your site. In this article I am going to show you how to install and use this module.

TL; DR:

Good documentation helps both a module's maintainers and its users, and is quintessential for the success of at least more complex modules. That's why you, as a module maintainer, should not put this (admittedly rather unpopular) task off any further but write some helpful documentation rather sooner than later.

On a related note, I just set a good example by finally expanding the handbook documentation for the Search API, and adding some for the Solr search module as well. Go check it out!

Why good documentation pays

When we talk about documentation, there are of course two sub-categories: documentation for users (site builders/administrators) and for developers. There are different reasons for having both types of documentation:

User documentation

User documentation is very important as a first step because it lets you both attract new and keep old users. Users who first hear of your module and take it out for a spin will usually have little tolerance for things not working as expected or for having to figure out everything by themselves. Sure, supporting such (potential) new users in the issue queue and on IRC help, but having a clear "How to" tutorial, maybe with a list common pitfalls, just makes it so much easier for new users. If someone just wants to try out your module, not sure whether they would have any benefit from it, there will be little incentive to actually try to find help if things go wrong, or if they cannot easily find instructions on what to do after enabling your module.

As a nice side effect, proper documentation will lead to less support requests in the issue queue or on IRC, thus even saving you time in the long run. If you keep the documentation up to date with support requests you've seen more often, users should find what they're looking for there in most cases – and if they don't find the documentation and still create a support request, a simple link to the documentation will suffice.

In some cases, there is already some documentation directly in the source code, either as a README.txt or as Advanced help integration, maybe even plenty of it.
Still, in terms of being able to find it and, e.g., also using it before downloading a module to see what you can do with it, handbook pages on Drupal.org still have the advantage. Furthermore, having documentation in the handbook significantly lowers the barrier for users of your module to get involved and extend the module's documentation (or to keep it up to date).
As long as there is no handbook documentation of your module at all, I'd wager the chances of someone else going and creating some are rather slim.

Developer documentation

Just like user documentation, developer documentation helps you attract new and keep old developers. Developers, who can help with patches in the issue queue, implement new features or create and maintain extension modules of your module. In my case, with the Search API being primarily a framework for creating search-related modules, this is of course especially important – but having people active in the issue queue who can fix the bugs they discover and implement the features they request themselves, who can review your more complex patches, etc., is quite valuable for nearly any module out there. Just by someone else reading through your code (if it's a more complex module), a few rough edges will pop up which would sooner or later have led to problems for someone (perhaps you yourself, as the one who then should fix them).

For developer documentation, naturally, source code comments, a proper .api.php file, etc., are very important. Still, none of these can really give new developers the “great picture” of how your module works. They just document single functions, methods, classes and hooks, but there is no general place for documenting how it all fits together. For that, again, I think handbook pages are the way to go.

New/Improved Search API documentation

So, after all the grand words, have I myself lived up to them? Well, no, or at least only very recently. For several years now, there was only some basic documentation for the Search API in the handbook, for the first year or so there was none at all.
However, being asked the same questions over and over in support requests, and recognizing all of the above arguments, I finally got round and significantly expanded the existing documentation:

• There are now a Common pitfalls and a Frequently asked questions section, listing support requests I've received more often over the last years.
• The developer documentation section is completely new. There's still a lot to add, but the two (in my opinion) most important parts are covered: an in-detail explanation of the Search API's architecture and workflow, and documentation about adding custom item types / data sources.
• I moved some of the text from the project page into the handbook – concretely, the extension modules and the related materials. This allows others to easily add to those lists as well, and additionally brings down the length of the project page to just a little over two screen pages.
• Lastly, there is finally also some handbook documentation for the Search API Solr search module, including advice on how to customize the Solr configuration.

Of course, good documentation is hardly ever finished, and there is still a lot to be added, but I do think that this is at least a sound base now so that most users will find what they want to know.

Help still wanted

While, as the creator and maintainer, I'm certainly quite knowledgable concerning all Search API-related topics, I'm also for the very same reason one of the worst people to judge what needs documenting, what could be unclear, how things are best explained, etc.
Therefore, if you have dealt with the Search API on any level in the past or – better still – want to look into it in the near future, please take a look at the new (and old) documentation, see if everything is clear, what might be missing, etc., and tell me your thoughts in the issue queue.

Or, of course, just jump in and edit or expand the documentation yourself! It's a great place to start contributing, helping others avoid potential problems you've encountered.

Some more documentation projects I have in mind for the nearer future include creating an example module for implementing a custom datasource (possibly by integrating Search by Page with the Search API); and maybe creating a new, up-to-date version of the old Search API screencast. If you've got other suggestions, please leave them here as a comment or create an issue for them.

Image credit: Johannes Jansson/norden.org

Tags: Planet DrupalSearch APISearch API SolrDocumentation

There are a lot of great things happening! Let's first see those that are already in: the config system got back to a saner track by removing the partial import capability and only allowing import of full config trees. This removed manifests which, honestly, I never truly grokked. Also, config import and sync were converted to pluggable services earlier so if someone can figure out how to do partials better then they can do. There was an epic profiling effort made by the Twig team to get the conversion committable -- and then Alex Pott honored them by committing patches one by one instead of rolled together to give them credit. Same with the views rename method patches. Big, big kudos to Alex for this!

Database connections are now serializable. As MongoDB doesn't use PDO, this is only important to us in the way the Database class has been refactored to allow for this.

Entity controllers now can have their dependencies injected (what about entities themselves? see below). Although batch v2 didn't happen, the batch storage is now pluggable (and soon the batch specific tables will be gone completely as msonnabaum points out that the expirable keyvalue storage is fit for it).

On a performance front, let's note that contextual links are now AJAX, making them compatible with render caching. The issue was filed in 2010 and I filed it as "this will never be done although it's rather necessary", so big kudos to everyone fixing it.

Firing hooks during major upgrades were always a problem and we discouraged it but now this will throw an exception (this was mostly my work). This is the second cornerstone on making the Drupal 7->8 upgrade path way more resilient than before, the first one are tests for use cases that were untestable before. Probably it'd been better if migrate happened this cycle, but it didn't so we cook with whatever ingredients we have.

The evented branch of the entity refactor is now dead and won't happen but a lot of that code now lives in the widely accepted "let's move as much logic as possible from storage controllers to entity classes" patch. It even passed once but due to the user entities conversion to the next generation controller it currently fails but I expect it to be fixed this weekend and it's possible it'll get committed soon. This will make replacing entity storage controllers much easier and supporting contrib entities much easier too.

Meanwhile, entity classes themselves are being changed to not be plugins. This makes some sense because, well, there's not much pluggability here you would want to do. I believe this leads to dependency injection of plugins which will be useful now that most of the logic is moving there.

Ps. Let me congratulate two people here. You can't even find msonnabaum among the Drupal 7 contributors core and he is rapidly becoming one of the shaping architects of Drupal, quite for the better. Tim Plunkett of the Views in Core team, the unstoppable coding machine, who can somehow balance like five ongoing patches over 100kb, had only 23 core mentions in the Drupal 7 cycle. I am so glad to see others taking lead.

No one likes repetitive tasks. Integration between your website and CRM is an important step in sales automation. Our weapons of choice are Zurmo CRM and Drupal. The zurmo.module for Drupal uses the webservices of Zurmo to avoid copy-paste your valuable webform submissions.

Zurmo is the open source, gamified, mobile and social Customer Relation Management suite, build on top of YII PHP Framework and RedBeanPHP. The development is test driven and has a fast release cycle. Zurmo is feature rich, without overloading your screen with options. The best part of Zurmo is that it is gamified, you earn points while doing your work. That makes the usage of Zurmo fun... you simply want to use it... and that solves one of the most heard complains from management of a company: "We have an expensive CRM, but no one uses it".

A Drupal Module

We developed a Drupal module to integrate the Drupal Webform Module with Zurmo. The module can be downloaded from the Zurmo project page on the Drupal website. The module builds a connection between Drupal and Zurmo, that utilize the webservices in Zurmo. With a sub-module you can send your webform submissions to Zurmo and create Contacts or Leads in Zurmo. In Zurmo you can send emails with the workflow tool to notify the right employee that a new Lead has come in.

The module is currently in development state. That means that it can be used, but is not complete yet. The Webform sub-module works and is tested in reallife. It needs more testing, more documentation to be released in Beta. In the comming months we will develop further to integrate Commerce (webshop) and Feeds (fetch any object from Zurmo and import it into Drupal).

Contribute!

You can help with the development of the Zurmo module by:

• Test the modules.
• Write documentation.
• Develop a sub-module.
• Supply patches.

Use the Drupal Issue Queue for this project to add your work to the module. You can also request to become co-maintainer for the Zurmo module for Drupal. Help us and let us build together a stable module, so that no one ever needs to copy/paste data!

Subsequent to my earlier blog on installing and setting up the commercial InnoCompany Drupal 7 theme, it is now time to do something useful - set up the Piecemaker 3D slider which is based on Flash animation, with an XML configuration file. Thankfully a lot of the work has already been bundled into the InnoCompany theme and there isn't that much to do. Principally the slider images, captions and links are included in theme configuration, and there are 10 available placeholders which means the carousel may have up to 10 images.

read more