Drupal Planet

• Read more

Search API has been my go-to module for building search pages for the last two years. Even if the client doesn't ask for anything fancy, I still download and install Search API, use Database Search for the index and Views for the page.

If you start with Search API from the beginning, then it's easier to customise later on. The core Search module, on the other hand, is easy to setup but hard to modify.

Recently, I had to create a search page that highlighted the keywords in the results. If you search using a particular keyword, then the word is highlighted.

Wow!!! As I think about the week spent in Amsterdam, I am in awe of the entire experience. This beautiful place has a very long and eventful history dating back to the 12th century, and was the perfect setting for DrupalCon Amsterdam 2014. As I think back upon the week, so many words come to mind that reflect emotions I felt while there: festivity, jubilance, liveliness, pride and treasure.   Having only been with Commerce Guys for a short 3 months, I wasn’t sure what to expect. I’ve been in the world of technology for over 13 years, and I’ve been around the block more than once with emerging technologies within the word of digital commerce. This experience for me personally will be one that I will forever treasure.     I said on many occasions that I felt like a fish out of water just trying to get some air. I consider myself fairly smart – I realized in Amsterdam with these magnificent people that any hopes of me getting an invite to be part of Mensa International most likely will never happen. Their kindness and willingness to welcome me to the world of Drupal was more than I could ever ask for.   Henry Ford once said, “Coming together is a beginning; keeping together is progress; working together is success.” The amazing group of people whom I refer to as the “Drupal People” (all 2,370 of them in attendance) embody this quote by Henry Ford. These are some of the most amazing, generous and intellectually aware people I have ever had the experience to associate with.    There was something rare and unique about this group of “Drupal People”. I believe that rareness is their desire to work together for one common goal…it’s what sets them apart from so many others. That goal is to serve the customer, and to provide the best of the best when it comes to a solution that is cost effective, manageable and scalable. From small startup business to full-blown enterprise organization, we have a solution that will work. Whether you are a current Drupal customer or are looking to make a change over to Drupal, I am here to tell you that the “Drupal People” truly are working together in a spirit of togetherness that will make Drupal the platform of the future (if they haven’t already).     I mentioned in the first paragraph some adjectives such as festivity, jubilance, liveliness, treasure and pride. There are two that stand out above all the rest: pride and treasure. I can’t be more proud of the company I have the privilege of working for and the people I have the opportunity to work with. Each and every team member of Commerce Guys brings to work a sense of pride that can’t be explained; only witnessed. Many sleepless hours are spent building the best of the best and ensuring that our customers know only one name: and that name is Drupal, a rare treasure.   I am excited about the next DrupalCons in Bogota, Los Angeles and Barcelona in 2015. As always, Commerce Guys will be there loud and proud supporting Drupal Commerce, Platform.sh, our partners, and the great people who are advocating the vision and future of Drupal.     Cheers to the beautiful city of Amsterdam, the fine people of Amsterdam, and each and every one of you who make what we do possible.   Thanks again for welcoming me to the Drupal Community in Amsterdam, I will be back!!!  

Drupal and many of the people who work with it are moving toward a configuration in code model of site development. One of the advantages of a config in code approach is that the code you add, share, and modify works for all the members of your team and across environments. Instead of everyone syncing databases (or passing around notes on how to update their environment because something changed), everything stays up-to-date with the latest code in your version control system. This essentially provides a known, common state for everyone to work against.

Configuration only gets you part of the picture, though. Modules like Features and configuration initiatives for Drupal 8 separate configuration from content. Configuration is sharable settings; content is the information that site stores/uses. This separation makes sense in organizing your code or site, but leaves a big gap in your ability to build and test a project. If I'm working on a project locally, I can't share a link to the article node I'm having trouble with because it’s a combination of configuration and content that exists only on my local machine.

You need standardized content to test against and to provide a common ground to review variations with your team. But what do you do when you're starting on a project and you don't have content from a client yet? You still need to develop code that uses content and you still need to style the site.

Luckily, we can use a common approach for bringing in content from another source, the Migrate module, to help create content we can share and test against. Additionally, the content can be updated, version controlled, and contributed back as the project rolls forward. And – this is very important for development content – when we're finished with dev content we can remove it with Migrate's rollback functionality. Content created with some modules like Devel Generate and even manually created development content aren’t easily removed when you're finished. At Aten, we commonly had many nodes with "DELETE" in the title to make it "easy" for us to find and remove it later, which is less than ideal.

How does this all work? This is our internal workflow:

• Create a resources folder in your project. Typically we now have a "root" level that has resources, a public_html folder (which has the Drupal files), and other project files.
• Inside of the resources, we create a content directory and add content files like YAML files, CSVs, etc. (more on that in a minute)
• We have started to use gulp and we have a task that will convert the YAML files to JSON.
• We create a custom module in the project for migrate and add migrate classes for each of the content files we need to import. Typically this will be something like "project_content". For dev specific content, we name the migrations with "Dev" on the end. When we have production content (which is awesome to have early in a project), we leave that suffix off the class name since that content isn't something we need to rollback later.
• We've created a script that is shared in the project that enables/disables modules, enables and reverts features, runs the migrations, updates various other things related to the project setup. If I add a new migration, I update that script's configuration to include it for others working on the project. I hope to share more about this script soon.

Creating Test Content

Now we need to create the content. Typically this requires some insight provided by our Drupal architecture document, but I have also created a couple of tools to help out with this process which help me stay in code:

• drush typeinfo
• drush taxonomyinfo

The typeinfo commands allow you to inspect content types/entities on the site. For example, if you are going to create content for an Article content type, you would run:

drush typeinfo article

That will output the content type's fields, field types, and some other information. Often this provides a good overview of what pieces you will need to create in your content file. If you have a taxonomy or entity reference field in that content type, you can also get more information about that via another typeinfo command:

drush typeinfo-field field_article_type

This will return a few specifics that may show you the taxonomy that field uses. And now we can use the taxonomyinfo command to list terms in that vocabulary:

drush taxonomyinfo-term-list article_type

We can also extend this functionality to automatically stub some of the content (à la devel-generate) by creating another drush command. This command lets us get the YAML with some data populated for us:

drush stub-content article --include-id --include-title --count=5 > resources/content/article.yaml

An example of this command is here: https://gist.github.com/robballou/a7aa247aa7bdfb3a1b2c

The stub content functionality makes some really rudimentary content and you can expand that with content from your favorite ipsum replacement or other sources.

We can migrate from a variety of sources: from CSV files, JSON files, or even other databases. CSV files are a popular choice because you can collaborate on a spreadsheet (especially via Google sheets) and export that data. JSON is another nice solution because the data can match the destination closely. In some of our projects we have even used YAML and converted that to JSON since the readability of YAML is slightly better than JSON — which means we can have people write content who don't know the ins-and-outs of JSON!

Some systems may have access to a PHP YAML library and it could be used to create a Migrate YAML source class. This would eliminate the need to convert files but may rely on that YAML library to be available on local, staging, and production servers. We've used the node.js/gulp approach because it can be shared between environments and projects that may not have this PHP support built in. Migrating and Removing Test Content

This article won't get into the details of creating your Migrate code, but the next step in the process is creating and testing the code to get this content into Drupal. When this is done, commit this to your version control system to share with others working on the project or with other systems.

As an example, we'll say we created a migration called ArticlesDev which has a handful of articles in it. The content uses a variety of the fields in the content so we can make sure all the functionality works and includes several nodes so we can test lists of various sizes. We can import the content into any system with:

drush migrate-import ArticlesDev

If the article content type changes down the line, you can update the content files and re-run the migration, updating the existing content (or adding new content):

drush migrate-import --update ArticlesDev

Development-specific content may never get imported on shared systems, but if you do want to use that content for client acceptance testing or for any other case, you can easily remove this content with:

drush migrate-rollback ArticlesDev Content in Code

If you're working in a team or if you need a client to review functionality, development content can be very handy. Building on this workflow, you can get a set of content in place early in the process, update it as things change, and get rid of it if you don't need it anymore. Your team and your clients have a common ground when discussing the project. As a bonus, your development migration code can be used as a basis for creating or importing live content as you get it from the client.

In this quick tip, we’ll be installing a local instance of Drupal 8, beta 1. By the end, you’ll have a copy of Drupal that’s not only ready to be extended with Symfony bundles and other packages, but also ready to accept content and display it to end users.

Step 1: Prepare Environment

Continue reading %Quick Tip: Up and Running with Drupal 8 in Under Five Minutes%

Here at OSTraining we've given significant coverage to Drupal Commerce. You can watch a video class with nearly 30 lessons and download a book, "Building E-commerce Sites with Drupal Commerce".

However, Drupal Commerce is an enterprise-quality solution and a good number of OSTraining members have asked for simpler solutions.

For those members, we often recommend the Payment module which makes it easy to add e-commerce fields to your content.

Payment supports about half-a-dozen gateways (PayPal, Stripe, iDEAL, Authorize.net, Ogone, Rabo OmniKassa) and we'll use PayPal in this tutorial.

This post was originally shared on the Drupal Association blog.

DrupalCon Amsterdam has wrapped up, and now that we're over the jet lag, it's time to look back on one of the most successful DrupalCons to date. DrupalCon Amsterdam was the largest European DrupalCon yet, by far. Just to knock your socks off, here are some numbers:

• More than 2,300 attendees showed up to 120 sessions and nearly 100 BoFs
• 115 attendees showed up to the community summit and the business summit
• 146 training attendees, 400 trivia night attendees, and 400 Friday sprinters made the week a success
• …and through it all, we ate 1,200 stroopwafels.

The fun extended to more than just the conference -- with 211 transit passes and 56 bike rentals, attendees from over 64 countries were able to enjoy all the city of Amsterdam had to offer. What a success!
As with any DrupalCon, DrupalCon Amsterdam wouldn't have been a success without lots and lots of help from our passionate volunteers. We'd like to take a moment to send out a big THANK YOU to all of our track chairs and summit organizers:

• Pedro Cambra - Coding and Development
• Théodore Biadala - Core Conversations
• Steve Parks - Drupal Business
• Lewis Nyman and Ruben Teijeiro - Frontend
• Michael Schmid - Site Building
• Bastian Widmer - DevOps
• Cathy Theys, Ruben Teijeiro, Gábor Hojtsy and the Core Mentors - Sprints
• Adam Hill and Ieva Uzule - Onsite Volunteer Coordinators
• Baris Wanschers - Social Media
• Emma Jane Westby - Business Summit
• Morten Birch and Addison Berry - Community Summit

We also appreciate everything our core mentors did to make DrupalCon Amsterdam a hit — and it’s thanks to lots of hard work from our passionate community members that Drupal 8 is in Beta!
We hope you had as fun and exiting a time in Amsterdam as we did. For those of us who weren’t able to make it, and even for those who were, you can relive the fun on the flickr stream, or catch any number of great sessions on the Drupal Association YouTube channel.  And remember to mark your calendar for DrupalCon Barcelona in September 2015. See you there! Below is Holly Ross' set of slides from the Amsterdam closing session.

DrupalCon Amsterdam Closing Session from DrupalAssociation
Image credit to Pedro Lozano on Flickr.

To complete my series on multilingual Drupal, here are some mini-lessons I've learnt. Some of them are are to improve the experience for administrators & translators, others cover obscure corners of code. The first few don't require any knowledge of code, but the later ones will be much more technical.

Drupalcon Amsterdam: some (user) experience

DrupalCon Europe 2014 was all about a new era that has now began on Wednesday, October 1st with the official beta 1 release - the era of Drupal 8. Compared with the DrupalCon Europe 2013, this conference was more about business and development and less about UX related matters. However, UX topics and raised questions are definitely worth mentioning.

UX and Dev: We need to have a date!

One of the most frequent UX topics of last year was better user experience crafted for the end-users of a website together with the importance of user research as a business objective. Knowledge of how and why people use a product conveys better understanding where the areas of improvements that need immediate mitigation are. 

Last week, voices were raised to provide a clear statement that the new and shiny Drupal 8 and the further development of Drupal on both core and contrib levels, needs to get UX research and design involved. Some actions were taken during the last year. However, there is definitely more potential. In her talk "Engaging UX and Design Contributors", Dani Nordin makes it clear. All people who contribute to Drupal have a common goal to create a better, highly scalable and stable version of our content management system. And to do so, UX researches, designers and developers are bound to work closely together, listen to each other and actually apply results of user research. To make this happen, we have to take action within the Drupal community. For example, UX researches and designers should be more involved in the development processes and procedures. Sometimes, designers and UX professionals are treated, as if their contribution is not important, which leads to a decrease of their motivation to spend their spare time for the community. Raising this topic lead to a lot of discussions. This resulted in the UX sprint producing a list of goals and directions that the community should go for in 2014 & 2015.

It’s about interaction.

More and more discussions within the community were devoted to interaction design. The word “design” has a rather broad definition and can be understood differently. For example, “design” for the majority of people only means visual design or visual representation of the object.  UX researches and designers differentiate the visual and interaction design. The latter is about the workflows or concrete steps that users should perform to achieve the goal. No doubt, visual design is crucial for making people want to start an interaction with an object in the first place. However, the quality of interactions is the key for the product’s success. The best way to determine a user-friendly interaction is to actually attempt to accomplish a task, find the obstacles, redefine the workflow and test again before the implementation even starts. The best way to do so is prototyping. No matter how you create your prototypes, you can use HTML, as Roy Scholten suggests in his talk “Because it's about the interactions. (Better UX through prototyping)”, or a broad palette of other tools that do not require advanced programming skills. The most crucial point is to prove that interactions really work and they do so for real users.  

Don’t prototype in Drupal!

The topic of the importance of prototyping gained further attention in the presentation of Dani Nordin. Don’t prototype in Drupal is a strong statement, and it has a point. One of the most popular prototyping tools Axure can help with the design at different levels: high and low fidelity. Creating Axure-based prototypes is faster and cheaper than spending days or weeks on Drupal site building and coding. Prototypes allow, however, to ensure the directions of a project, make it possible to talk with stakeholders about tangible and interactive product before applying the development forces and, again, it’s the way to receive the user feedback. This insighs can be applied not only to the products built in Drupal, but to Drupal itself. This will improve not only the life of content creators, but can help developing more elegant solutions using the better design features of the Drupal core together with contrib modules. 

 

For a long time I’ve harboured the belief that too few in Drupal receive the recognition they deserve. I often wonder how many bright (young) stars fall through the cracks of our vast community, fade away and perhaps leave altogether. When the Drupal project was small if you did some heavy lifting, people noticed. Now our numbers have swelled beyond 1 million it is no wonder worthy effort goes relatively unnoticed.

Few of us are seeking the limelight but being noticed, that’s another matter. It’s not just recognition either. We should be mentoring emerging talent, supporting promising businesses and championing contributions from end users. But with such a vast and growing community, as Dries so eloquently put in his keynote, the status quo is unsustainable.

“Social capital and altruism is what we already do and I don’t think it is very scalable”

DriesNote

We should remember the material for the Dries keynote was crowd sourced and as he said we should “keep an open mind, don’t draw to conclusions”. Now is the time to debate openly, engage in constructive conversation and help invigorate Drupal.

What struck me at Amsterdam was that when the audience members having contributed to Drupal Core and contrib were invited to stand, surprisingly few remained seated. In many respects talking to DrupalCon attendees was preaching to the converted. The job is for us to reach the rest.

Understanding how our ecosystem works is a very important first step

I believe the path to a healthier community hinges on how we record contributions, not how we recognise them. Currently we track what individuals contribute and there is a fixation on code based contributions. How about documentation, organising camps, mentoring, community affairs, design and so many more valuable activitites. Introducing a way to differentiate between efforts made by individuals, agencies and end users and a move towards “Track all types of contributions” for me is a giant leap forwards. It couldn't happen sooner.

How we might use this new data is less important than the ability to "track how our community really works”. Most significantly it will bring to the surface things are not working. Who is funding what? Are we depending too heavily on small groups or certain individuals? Could specific areas do with more help? Achieving the tracking Dries would like, could happen within weeks. The Rankomatic? I like to think of it as Drupal Analytics, which is open for all to query. Expose the data like data.gov.uk and the community will surely hack insightful mashups and we will have something very empowering.

Is D.O ready for a reboot?

What word is conspicuously missing from the D.O homepage? Contribute, yup, seriously. How can we expect more people to do so if we don’t clearly signpost how? When Dries talked about “Free riders” I reflected on how long (years) it took me to find a niche in Drupal. I existed on the fringes under employed. It was only when I was noticed by Isabel Schultz during DrupalCon London that things really flew for me. We need more "talent scouts". Why is Get Involved buried in the footer and not somewhere more obvious? Are many “free riders” just looking for a way to engage?

Rewarding contributions through enhanced visibility, leading by example will certainly help. Encouraging companies who don’t contribute to start doing so via subtle design changes to user and marketplace profile pages has merit. Will invigorate the contributors themselves to even greater heights? That's certainly how I roll.

What Dries suggests is sweeping change. In this respect the cynic in me worries about the glacially slow speed of change on Drupal.org (D.O). 5 months ago I created an issue proposing the community spotlight feature on the homepage of D.O. It had unanimous support but nothing ever happened. Maybe I did something wrong? Perhaps I don't understand the process?

The good news is the Drupal Association has hired staff whose role is to deliver these kinds of enhancements. It also feels like a more measured and strategic approach is being taken. I hear talk of user personas. The concept designs by During his TED Talk Harish stated companies that will thrive in the future are those who "play their role in terms of serving the communities who actually sustain them”.

Drupal is a platform having a community that sustains many thousands of businesses. Drupal has strong evidence that Harish’s hypothesis is already true. Drupal shops, even end users who contribute to the project tend to be the ones enjoying the best outcomes. The problem is we operate in a bubble, where everyone is hooked on open source. Out in the real world people’s thinking is years behind and the principles of open source sound quite peculiar even alien. Those coming to use Drupal need introducing to the benefits of taking a benevolent role.

We know who Lullabot, Palantir, Phase2, Wunderkraut are. The various Drupal shops are contributing, often in bucket loads. What we actually need is more companies like that. Indeed we need more end users contributing back too. Like how Oxfam, The Whitehouse, Sony have been instrumental in developing significant contributions to the Contrib space. Again Dries’s advertising model could help to champion these organisations, communicating why they chose this path and the benefits they have reaped over time. It’s not about penalising “free riders” it is more about persuading them to engage with Drupal, to start contributing.

“If everybody that used the commons contributed a little bit things would be perfectly fine”

Dries talked about The Tragedy of the commons - overgrazing in Drupal translates not to the software rather the "Free riders" are depending too much on people’s generosity, personal time or indeed time which they should be running their business. I’ve seen situations where people have neglected their business for the benefit of Drupal. This goes way beyond the well known plight of Alex Pott, I assure you. I'm sure the few examples I have seen are a small fraction. Here everyone loses.

Time for change

As Dries said “An imperfect solution is better than no solution”. We’ve tried for some time to encourage those who sit on the sidelines to start contributing. Now is the time for a small revolution. Recording, recognising, rewarding code and non code contributors on D.O is simply a way of scaling how it has always been. And if that sounds too radical, how about we try it out on beta.drupal.org? We need to take a leap. After all, aren’t we the round pegs in the square holes? We are the ones who think different. It’s way overdue we took some of our own medicine.

Further information: Outlandish Josh's Thoughts on the DriesNote: Towards Drupal "Contribution Credits"Watch the Dries KeynotePhoto credit - Steffen Rühlmann

At the recent DrupalCon Amsterdam sprints something amazing happened, people from all corners of the globe assembled to sprint on DrupalCI. DrupalCI is an initiative born out of the requirement for new testbot infrastructure. Our goal is to implement a brand new Continuous Integration (CI) workflow that can not only be used for Drupal but anyone wishing to run a CI infrastructure / Automated tasks. Until this point we had only corresponded via a weekly hangout and IRC.

While this was keeping us on track with building out some of the components, the conference gave us an opportunity to sit down in the same room and perform an end-to-end architectural review to ensure we didn't have any gaps. A modular design approach has been used to ensure that many of the following components could be used as a standalone entity in any infrastructure.

As part of the Google Summer of Code, I began work on getting CiviCRM and the upcoming Drupal 8 working together nicely. I made an update about midway through and it's time for another update.

I had separated the project into a number of milestones. Phases 1, 2 and 3 dealt with varying aspects of the core CiviCRM module functionality. This work has largely been completed and there are pull requests pending into CiviCRM core, though the front end user experience is still a bit rough (for example, the CiviCRM menu bar doesn’t sit well alongside the Drupal menu).

The installation process is quite different with Drupal 8: civicrm now installs as if it were any other Drupal module — simply by clicking enable. It's no longer necessary to use the CiviCRM installer before enabling the module. This handles the most common use case where CiviCRM is installed in the same database as Drupal itself. Custom options can be configured by adding configuration settings to Drupal's settings.php. For example, if Drupal is configured with a second database named 'civicrm', it will install civicrm there instead.

The next big milestone was Views integration. This went ahead quite smoothly, and I managed to reduce the code count from approximately 15,000 lines of code to under 2,000 by automating a lot of the discovery of the CiviCRM database. In general, when new fields appear in CiviCRM it should only be necessary to explicitly declare how the field is related to other data types (eg. as joins or relationships).

One quick nice-to-have was integrating Drupal's entity reference field with CiviCRM Contacts — mostly by creating a bare-bones Drupal entity. A similar technique may prove to work with Drupal's Rules module, but unfortunately time did not allow this yet.

Finally, for the first time, the module comes with a few simple integration tests (using Drupal's SimpleTest module) which will hopefully become more fully fleshed out with time. With a judicious set of tests, this should allow a more stable experience as future versions of CiviCRM are released.

Drupal 8 has finally released its first beta just over a week ago. Now that it has stabilised somewhat, we need to update the CiviCRM module to resolve breaking changes and we can then release an alpha version that the community can test, experiment with and help get into a stable state.

Drupal 8 repo: https://github.com/torrance/civicrm-drupal

• GSoC
• Drupal

The fifth class of our Drupal career training program is just about at the halfway mark, and our students are eager to put their new skills to work. The six Drupal Career Online students will be ready for junior-developer-level work in mid-November, and we're looking for forward-thinking organizations willing to help our graduates on the next leg of their Drupal career journey.

As we've done for the past five classes, (we've had more than 60 graduates so far) we're looking to make introductions between our upcoming graduates and organizations looking for people with Drupal site-building and development skills. Our Work Experience Drupal (WE Drupal) program is designed to provide students with valuble experience in internship-type settings. WE Drupal host companies are asked to make a 6-10 week commitment to one or more of our students, provide them with guidance, mentoring, and the professional experience that is so difficult to come by for new Drupal site builders and developers. In return, you get the efforts of a well-prepared, super-eager Drupal novice to help you lighten the task-load for your staff.

-->

read more

When we launch a site at Stanford Web Services, we open the doors and roll out the red carpet for the search engines to index the site. However, before launch we like to keep the content under wraps and ask the search engines not to index the site. To do this, we use a module called Stanford MetaTag NoBots.

DrupalCon Amsterdam Keynote by Dries was interesting and different.

This how-to guide describes how to set up automatic machine-based translations for content on a Drupal site. Whenever a node is created, translation jobs will be created for every language specified, and depending on how you set up your translator, you should be able to completely automate the translation process. For this project we are using SDL, but you should be able to use other translators.

1. Download and enable the translation management modules. This can be done through Drush or through the modules interface in drupal.

Where on this planet as a pedestrian you can be hit by bicycle and… be guilty for it? Amsterdam, you are just awesome! :)

DrupalCon is over and its attendees are in the relaxed process of event reminiscence. True drupallers are never tired of sessions, code-sprints, workshops and just fuss between these events; and yes, this year’s Con has provided all of these! But you know what? You can read about this stuff in dozens of other materials. And here we have gathered those moments and snapshots, which made our days at DrupalCon!

Read more

Dozens of useful contributed modules for building Drupal 7 sites.

There are many really useful contributed modules to take your site beyond the basics of Drupal core. There are modules to improve, allow, and/or help with everything from accessibility to workflow, from images to input formats, and beyond.

This session will be of interest to beginner and intermediate Drupallers, as well as those who manage or hire Drupallers or who are just trying to decide whether to use Drupal.

read more

This screen share walks you through why you might want a more powerful way of making blocks and why Codit: Blocks is a good candidate if you need lots of custom blocks.

• Read more about Codit: Blocks a video introduction to making custom blocks