This week, the DrupalCon Austin sessions have been posted, and I'm thrilled to have one of my session submissions (in the DevOps track) selected: DevOps for Humans: Ansible for Drupal Deployment Victory!.

The session will go over how Ansible can be used to realize faster, easier, and more successful Drupal deployments, as well as Ansible's ability to make sure that every environment is 'like production', so you don't ever have surprises when you deploy code to its final destination.

Part 1 of 2 - I spoke with Richard Miller and Tom Kitchin, software engineers at SensioLabs UK and its parent company Inviqa respectively, via a Google Hangout on Air recently. I wanted to learn more about PHP and Symfony from their perspective and how they think the Drupal 8 and Symfony2 are going to affect each other. In part 2, I learn the inside story on one of the first Drupal 8 sites online, www.sensiolabs.co.uk, what their goals were and how they built it and have kept it running since May 2013, and how Drupal 8 will change the way they design applications for clients going forward.

It's been a year since I quit my job to work on Drupal and play with Jack. Many amazingly special things have happened to me. I still remember falling off my seat when Dries asked me to be a committer and lying awake all night with excitement whilst I "slept on it".

Without the Drupal community's support I would have had to return to work much earlier. With everyone's donations through gittip, two companies' financial support and my own savings, I've been able to continue working full time on core. However my savings are diminished and the corporate sponsorship only lasts until 18th April. Fundraising month to month is more than a little stressful when a family is involved. Therefore I plan to take some form of employment. Hopefully I will be able to find some interesting work starting at the beginning of May.

Whatever type of job I take it is important to me that I have the ability to continue to contribute as much as possible to Drupal 8 and have time for my family. What will happen to my gittip? This depends on the type of job I take. If I take a contracting job where I work less than a full work week I will reset my target so that it'll amount to extra time I will work on core. If I take a full time job that allows me to work on core I plan to create a gittip team called "Drupal Core" to which I will transfer all my gittip earnings to this. Obviously, people are free to redirect their gittips as they see fit.

Fundraising and Drupal

There are companies using Drupal that are willing to contribute to core even though the immediate benefits are not tangible. One of the companies that has funded me since December is a Drupal user, but not at all focussed on Drupal development. The only condition for receiving the money is that I do not disclose their name. This is because it is not easy from an accounting perspective for a company to donate money to an individual.

We all know that core is more complex than ever and the interests in Drupal larger. Sustaining Drupal core development is a key challenge for the community. I think we need to seriously consider extending the Drupal Association's remit to be able to coordinate the collection and distribution of funds from major Drupal users for Drupal core development. If this is impossible then this does not mean we should not still try to solve the problem.

Thanks

Feel free to contact me if you have an interesting job offer - especially if it involves Drupal 8.

Lastly, thank you to everyone for your wonderful support.

Tags:

• Drupal

This tutorial will guide you through all the steps required to replicate the Commerce Marketplace demo site on your own server, and then explain how its behaviour differs depending on various configuration settings.

It's been a week now since I demoed my proof-of-concept for an automated theme generator at the Drupal show and tell event so I thought I'd collect together the feedback I've received so far and post an update.

Wrong Approach?

Almost unanimously positive feedback. In fact, it seems other people have been thinking along similar lines:

@mothersele dude! just saw http://t.co/GyV2m41eUe This is something that @jenlampton, @mortendk, @Cottser and I have discussed for 8.x twig!

— Mark Carver (@mark_carver) March 29, 2014

The one opposing view I have encountered wasn't actually against any of the ideas in the theme generator, but suggested that taking over Drupal markup was wrong and that we should be working with what Drupal provides. I know there are arguments for this, and if you want to go this route then you will need some other mechanism for documenting the conversion of your design to Drupal theme. If you want to argue this case, I'd suggest first try having that discussion with Morten, as I'm going to assume that we're all OK with the concept of taking complete control of (completely rewriting) Drupal's markup output.

Annotation

In an earlier prototype I had started working with annotations inside HTML comments but I found these increasing harder to parse as the extractions became more sophisticated. Someone in conversation brought up ideas from KSS and suggested looking at CSS comments as an alternative.

I'm still proposing this as a possible approach (see Docblock), but for now I'm going to continue to annotate the markup (not the CSS) with x- attributes, as no one has had an issue with this, and at this stage it's easier to work with QueryPath to create the extractions based on these attributes. It seems that annotating the markup with x- attributes will be acceptable as long as they are stripped from the markup during the build process.

@rootwork @illepic @micahgodbolt @EvanLovely @mothersele Interesting! Do the data attributes get stripped out during the build step?

— Brad Frost (@brad_frost) March 28, 2014

It was great to get feedback from Brad Frost as his work on Atomic Design has been influential in the development of this process.

In code, or config

In this first proof-of-concept, the generated theme is held in memory, well actually it is persisted as a Drupal variable containing a single object that holds the result of all the 'extractions' from the source. The original intention was that this would actually be a ctools exportable, so that it could be exported and managed as part of the configuration management process for the site.

This is how the Panels flexible layout builder works. It has one parent layout plugin that programmatically declares child layout plugins based on the layouts you define using the layout builder tool. These child layouts are stored as exportable objects, so they can be exported using Features. The current Hyde theme generator approach is similar, except that the parent plugins (for layout or styles) programmatically declare child layout and style plugins based on the result of each extraction from the HTML source design.

Storing the result of the build in configuration or database raised some concerns, mainly over capturing the results in version control. These tweets summarise the issue:

@mothersele interesting implementation. But I believe that should definitely generate theme in code, not just DB @mcjim @MattFielding

— Tom Bamford (@waako) March 28, 2014

@waako If a prototype is always in sync with a Drupal theme, the markup *is* all in code right? // @mothersele @mcjim

— Matt Fielding (@MattFielding) March 28, 2014

Matt picks up on my original intention, in that the design/theme would be captured in code and be version-able because the translation is automatic from the design's HTML/CSS/JS.

The difficulty is in managing any changes that happen to the generated code once it becomes a Drupal theme. This is exactly the problem that using the theme generator is trying to solve. That it provides a documented, repeatable conversion process, so that design can become part of the (agile) development workflow.

However, it is going to be unavoidable that some tweaking will be needed. This covers a couple more issues that were raised at the Drupal show-and-tell event:

• How to manage logic in template files?
• How to capture Drupal's pre-process functions?

The approach I am looking at to solve this, is one I've seen practised by other tools that involve code generation. For example, have you seen BDD using Behat? When define a test scenario in Behat it generates stub code for any unrecognised steps in your tests. For example, if you say "Given I am in a directory", you would get the generated stub code:

/** * @Given /^I am in a directory "([^"]*)"$/ */ public function iAmInADirectory($argument1) { throw new PendingException(); }

I think the theme generator could do something similar for elements marked as requiring pre-processing in the template file. This needs some further thought and perhaps a couple of experiements.

Terminology

Still struggling with naming conventions. If this is going to be a more general tool then need generally understandable terms (like 'component'). But, need to avoid overloading terms even more, as it's already quite confusing having SMACSS modules, Drupal modules, panels, blocks, boxes, styles, layouts. urgh!

Next steps...

@mothersele @mark_carver I love it. Also love that it works w/ panels! Q: Are the layout plugins placed in the theme? @mortendk @Cottser

— Jen Lampton (@jenlampton) March 31, 2014

So, I'm going to revise the current proof-of-concept and produce a second prototype. This time as a Drush command that generates an actual Drupal theme. Rather than holding the extracted theme in configuration it will generate a theme folder, that will include all the usual Drupal theme files, plus any plugins for Panels layouts, styles, display suite etc, and the CSS/JS copied across from the source design.

This will allow Hyde to generate stub code for pre-processing or other programmatic tweaks that are needed to get Drupal's output to match the design markup. I also think people will be more accepting of this approach as it's probably more like how it is expected to work.

My worry is that people will then hack the generated theme, it will go out of sync with the source design markup, and that will break the whole process.

If you want to get involved, please drop me a line. I need input from designers, themers, and developers. In particular, I'd be interested to speak to anyone else already using Atomic Design and/or SMACSS on Drupal projects.

In Drupal we use object-oriented page and form callbacks to ease our programmning burden This is a nice improvement that allows us to encapsulate the functionality of one or many page callbacks into objects, with all the benefits that brings. Is it possible for us to us object-oriented page callbacks in Drupal 7? With a few tricks, yes it is. This article shows you how.

This is part of a continuing series of using Drupal 8 programming techniques in Drupal 7.

I’ve been recruiting many Drupal developers. The process is usually a mixture of random in-depth questions, a drupal.org profile review and pure intuition on the applicant’s fit for our company.

That’s why I felt genuinely interested in the recently published Acquia Certification program. Could a single test provide a trustworthy distinction between a seasoned and an unexperienced Drupal developer? I got to test myself a couple of days ago.

The Acquia Certified Developer Exam promised to analyze a testee’s knowledge of Drupal as well as web development skills in general. The covered areas are so overly wide that it is pretty hard to cover all corners with 60 multiple choice questions. Drupal was naturally present in most them while some of the other development topics were covered only by one or two.

The test time was limited to 90 minutes which I spent completely. The most time consuming part was reading the questions themselves.  I would have made the answer options tricky, not the questions. The questions were  quite lengthy, trying to mimic a real life case of an freelancer. An entreprise level questions would have had more focus on testing, scalability, deployment and documentation - not to mention drupal.org participation.

My overall feeling about the exam was positive. Althought I would have preferred the test being split into more specialized, separate tests, the certificate test gives what it promises. After completing my test, I got the results which reflected in my mind quite well my personal skills.

For sure one cannot pass the test only by guessing so the certificate is a valid testimony of prior in-depth Drupal experience. That’s why having a Acquia Certification in your CV will give you additional credibility and personal ROI. It will grow from personal ROI to corporate ROI when becoming an acknowledged selling point as well as a decision criterion in tendering processes.

 

Originally published March 26 on NTEN.org

Learning a new technology can be incredibly intimidating, especially if you’re going at it alone. There’s great comfort in knowing that you’re not the only one with those particular questions or having this recurring, frustrating problem. Stranding yourself on a technological island is so unnecessary, especially given how accessible learning resources are these days. This is the beauty of the modern technology communities.

Specifically, the Drupal community. It’s everywhere, it’s friendly, and it’s full of helpful people excited to share their expertise and bring new talent into the fold. I spent the last four months preparing for Drupal Day, a Drupal-centric, day-long workshop that ThinkShout coordinates as part of NTEN’s Nonprofit Technology Conference (NTC). I didn’t quite understand the scope of this community until those months finally culminated in the big day.

The process was an interesting one for me especially, as it was not only my very first Drupal Day but also my first experience at the NTC. How do you create a one-size-fits-all day for a large group of people, both nonprofit professionals and technologists, with a wide range of technical competency levels?

It may not be a perfect fit, but so long as there are options, your attendees remain in control and are able to choose the sessions relevant to their interests. With the collaborative efforts of our sponsors and nonprofit feedback, we were able to put together a day jam-packed with content.

My experience with Drupal Day left me with a few key takeaways for those looking to dive into Drupal:

1. The Drupal community really is awesome.

Drupal.org is only the beginning, but it’s a fantastic beginning full of answers. There are forums, an archive of resources, and even a live chat if that’s more your speed. There’s a wealth of information available to you online, all of it curated by the people that know and love Drupal best. This community isn’t purely digital, either. If you live in a large city, chances are there’s a Drupal meetup near you. If you’d prefer to meet face to face, you can, whether it’s through a local event, full-blown DrupalCon, or nonprofit summits at NYC Camp, and BADCamp. You can also access paid training on BuildAModule, but the best part is that you can meet Christ Shattuck, the BuildAModule instructor, in person at a ton of these events. You’re going to start recognizing people quickly, and it’s going to be more helpful than you might think.

2. Learn from others’ stories and share your own.

One of the draws of Drupal Day is that it’s a great opportunity to hear from nonprofit decision makers about their experiences with Drupal. This year, every single one of our speakers represented a nonprofit with a successful Drupal story and each came from different technological backgrounds. We chose speakers that we believed had great, impactful stories that Drupal Day attendees could learn from. This year, Erin Harrington from The Salmon Project, Jess Snyder from WETA, Porter Mason from UNICEF, Milo Sybrant from the International Rescue Committee, and Tony Kopetchny from Pew Charitable Trusts joined us to share their experiences. You can learn more about their projects by clicking through to their websites.

3. Every question is a good question.

There really aren’t any dumb questions, especially when it comes to Drupal. The community embraces newcomers and fosters a great environment for learning. No matter your technical competency level, they’ve got an answer for you. This is why we structured Drupal Day 2014 the way we did: nonprofit speakers in the morning talking about their personal accounts of their organization’s experience with Drupal, followed by an afternoon of twelve breakout sessions covering a variety of topics, where guests could move from classroom to classroom easily. We collaborated with our developer sponsors and nonprofit attendees to determine what information was most relevant to nonprofits. We crafted a day around the topics they wanted to learn about. Everything from Google Analytics to content creation had a place at Drupal Day.

The Drupal community is one that needs to be experienced to truly understand its value. It’s a wonderful stage for nonprofits, no matter where their organization is at technology-wise. Drupal Day is a prime example of that, but there are many more events on the horizon, which I highly recommend if you’re on the fence about diving into Drupal. Of course, I also encourage everyone to come out to Drupal Day at the next NTC and see just what exactly it feels like to be part of this fantastic community.

Today, someone in IRC asked how to add the current date to a View they were working on. Seemed simple enough, and I offered to help, thinking it was just a matter of sticking a token in the View header. And it was...sort of. Incredibly, Google searches turned up only code-based solutions. Overkill. Here's a UI-based approach.

To add the current date to the top of a View, follow these steps:

On Drupal Dev Days I gave a talk about how we work with Vagrant and Puppet with development, here are the slides from that talk.

If you have any questions, please comment.

 

While planning site architecture with a large amount of materials, developers often face such issue: how to implement a flexible materials sorting, or how to make the most interesting articles not to be lost among the new content?

Here we will describe the solution we have implemented while handling this kind of task.

Read more

Sage Pay is one of the world’s most trusted payment solutions providers.

Our brief was to create a platform which could be used to build and maintain a website for each of the countries Sage Pay operates in, supporting existing customers and promoting Sage Pay services in those countries.

Background

Sage Pay has earned a reputation for security and good service. From startups to major brands, fifty thousand business of all sizes relly on Sage Pay to succesfully processes customer payments.

Sage Pay approched Code Positive to re-build the main corporate platform from which all Sage Pay country websites are built and maintained. The objectives were to present fresh new branding and make it possible for Sage Pay customers, partners, and developers to more quickly find solutions and information.  

Code Positive provided consultancy, project planning, project management, development, and on-going support for the project.

Drupal was used to implemented the project, and hosting was provided by Acquia.

Site Highlights Marketing

The Payment Solutions section features visually rich explanations of the advantages of Sage Pay products, step-by-step guides on how to switch to Sage Pay, and information for statups and corporates. Each page has a clear call to action to connect the visitor to the sage Pay sales team.

The Partner and Developer section of the site provides information on becoming a partner, and helps partners and developers find developer resources and information about 3rd party integrations. Similar to the Solutions section, navigation is visually driven and there is a good balance of imagery and content on the pages with strong call to actions in the form of buttons, teasers with icons and customer logos linked to case studies.

Customer and partner case studies highlight how different Sage Pay solutions have solved problems and met the needs of customers and partners - two different audiences for Sage Pay. The case studies grab the attention of the reader with quotes and logos from prominent customers and partners. Case studies are promoted throughout the site with case study carousels and lists of linked logo thumbnails.

Support

The support section makes it quick and easy for Sage Pay’s various audiences to find the help that they need.

It features support articles on various topics, integration guides explaing how Sage Pay products can be used with other applications, online shoppers FAQ for anyone making payments through Sage Pay services, and contact details for 24/7 support services through which clients and partners can get more information.

Also available in the support section are logo downloads that can be added to a website to show it’s using Sage Pay services, a beta testing programme registration, a glossary with definitions of termnology used on the site, and explanations of error codes and their suggested solutions.

One of the most important features of the site is the system monitor which provides up to the moment information on the status of Sage Pay services.

The support section has a search facility, including the option to search specifically in error codes so that integrators can quickly diagnose problems and find solutions.

The Sage Pay forum is hosted externaly on Stack Overflow. which has excellent tools for technical support and a large and active developer community.

Content Strategy

The client’s brief had two almost contradictory requirements for the site’s content strategy:

1. Flexibility to add a completely different mix of content to each page
2. Rigidlly defined content fields that would guide staff in entering content

A flexible content system would enable the marketing department to create whatever message was appropriate for each page. Rigid content fields would maintain consistency across the site, and allow content parts to be re-used on other pages, or hidden on mobile devices.

We squared this circle by analyzing the content that would be added to the site and found common repeating patterns, we then implemented each of the patterns as component types that could be added to any page in any order. Options were also added so the client could control the position and styling of each component as it was created.

We met this challenge by analysing the planned site content to find common repeating patterns. We then built a component for each of these patterns, that could be used to add structured content to any page in any order. The components included flexible configuration options that empowered Sage Pay to control the layout, styling and order of the content as it is added to a page.

Most of the components were developed to have a one-to-one relationship with the page they would be added to, and we also provided a few components that could be re-used on multiple pages.

After a few weeks of use, feedback from the client enabled us to refine the user interface of the component system, to provide a system that is flexible, powerful, and easy to use.

Tokens

One of the challenges was to make it easy for Sage Pay to manage and maintain lots of pieces of information, like telephone numbers and prices, across multiple pages.

To solve this problem, we implemented a token system that enable the client to use place holder tokens anywhere in their copy, which are automatically filled in with information before being displayed on the web page.

The client can easily create new tokens as required, and updating the information associated with a token updates the information across the website.

Media Management

The website makes extensive use of images, videos, and downloadable documents as part of it’s marketing and support features.

We used Media module to implement a media management system that enables the client to add media to the site’s asset library, re-use them across multiple pages, and track which pages each asset is used on.

The system also allows the client to update a media asset, such as a new image of a product, and have the site display the new version everywhere it used the old version.

Drupal Contributions Node View Mode

Provides a field that can be used to select a view mode on each node.

Node View Mode The Results

The site has exceeded the client’s expectations for flexibility and ease of use in adding content. Sage Pay’s marketing and support teams are excited about the positive feedback from customers, developers and partners.

Drupal ConsultingDrupal DevelopmentDrupal Maintenance

At DrupalDevDays Szeged, skipyT, fgm and myself made tremendous progress with writing the MongoDB drivers. All the override mechanisms work as expected and things in general, work. Most importantly, we have an entity storage backend and a significant percentage of the entity storage query tests pass (it is not expected all ever would pass, for example relationships are not supported). I have also managed to get the "add aggregator feed" test pass (going in ABC order among entities), this hit a snag where a recent rewrite of the testing framework broke overriding services during testing and I am not allowed to fix this so automated testing will require a small core patch. Otherwise we would need to create a mostly empty testing class for every test, this is clearly not desirable. Also at DDD, Ricardo Amaro and Jeremy Thorson have made significant strides in creating a more modern testbot based on Docker, I intend to run an instance at home and see how MongoDB fares with all the tests. I am reasonably confident by the time the beta happens, you will be able to run it solely on MongoDB.

Meanwhile, migration got stalled by an unrelated core issue, it's close to a resolution now. Other core changes broke many migrations but by now we should be back on track and again, I am reasonably sure by beta time the Drupal 6 to Drupal 8 path will be there to test. Will Drupal 7? I hope too but nothing is certain.

What's new with Drupal 8?

The past three weeks saw some exciting progress on Drupal 8, in part due to the hard work of everyone who went to DrupalDevDays 2014 in Szeged, Hungary. It also saw the release of drupal-8.x-alpha10.

Drupal Developer Days Szeged

DevDays Szeged was a landmark for the Drupal 8 release cycle. Participants marveled at how productive and well-organized the event was, and core maintainers commented they'd never seen such momentum in the RTBC queue. During the week-long sprint, 19 beta blocking issues were fixed (with three more RTBC) and every single missing change record was written. Outside core, sprinters also made significant progress on everything from the Search API module for Drupal 8 to Drupal.org itself. A robot doll, chocolates, bunny ears, stickers, and Drupal-ified Hungarian folk music also made it the event of the year. (Szeged slide show)

Alpha 10 released; Alpha 11 due Apr. 23

Alpha 10 was released on March 19th, just before Drupal Dev Days. Some notable changes include:

• Drupal now requires PHP 5.4.2 or higher.
• modules and installation profiles only require .info.yml files
• the logo, site name and slogan have been converted from special theme variables into a block

... for the full list of changes, see the alpha 10 release notes.

These alphas are provided to give you something more stable to work off of than having to chase HEAD every day.

Where's Drupal 8 at in terms of release?

Core momentum increased again in March, with a new all-time record of 51 criticals fixed over the month. In fact, we've nearly recovered to the level of known technical debt we had as of feature freeze a year ago. :P There's still a long ways to go, so help us focus on the most important issues and on releasing a sound Drupal 8 beta.

Our steady progress toward that first beta release continues as we divide the outstanding beta blockers into actionable sub-steps. Among March's fixed criticals were over 30 beta blockers, more than half the total, showing the community's tight focus on unblocking this milestone.

Note that the number of beta target issues (which are issues that would be good to resolve for the beta, but are not critical enough to block it) continues to increase. As we get closer to beta, it's important to also pay attention to these issues, so we'll be highlighting beta targets more in the coming weeks.

Last week, we fixed 25 critical issues and 24 major issues, and opened 15 criticals and 29 majors. That puts us overall at 118 release-blocking critical issues and 486 major issues.

16 beta-blocking issues were fixed last week. There are still 28 of 142 beta blockers that must be resolved before we can release a Drupal 8 beta.

Where can I help? Top criticals to hit this week

Each week, we check with core maintainers and contributors for the "extra critical" criticals that are blocking other work. These issues are often tough problems with a long history. If you're familiar with the problem space of one of these issues and have the time to dig in, help drive it forward by reviewing, improving, and testing its patch, and by making sure the issue's summary is up to date and any API changes are documented with a draft change record.

• At Szeged, we had an important Developer Experience (DX) discussion about Drupal 8's use of request attributes (#2124749) and its impact on frequently used public APIs. To move forward, we need more feedback on the recent discussion (see @effulgentsia's writeup in comment #32).
• For the D8 Menu system, the most critical critical issue is #2227179: Step 2: Wrap the existing logic of accessing menu links into a plugin manager, part of finalizing the API for declaring default menu links. This is the #1 API that contributed modules interact with, since most modules add links to their administration pages, and therefore it's very important to get the developer experience and architecture right. Help review the current patch and the overall proposal.
• In the Configuration system, Add a separate module install/uninstall step to the config import process is the next step to making Configuration synchronization stable and reliable. The patch needs review.
• And, finally, much of the remaining beta-blocking work in the Entity Field API hinges on Introduce StorageFieldDefinitionInterface in the Entity Field API.

More ways to help

Love Drupal and want to help out, but not a coder or unsure where to start? From breaking things (for science!), to designing things; from summarizing issues to writing documentation, there's lots of ways you can contribute! And, there are more than 125 mentors willing to help you!

Our current priority is updating the documentation for Drupal 8. Rich, helpful documentation for Drupal 8 is incredibly important: it's a great way to market Drupal to potential clients, it saves you from writing as much documentation for your existing clients, it empowers new users, site builders, developers, and themers to learn and solve their problems; and, with all the changes that have happened since Drupal 7, it's pretty useful for seasoned Drupal veterans as well!

The documentation team is working on updating:

• the Core module handbook,
• the help module's pages, and
• the new developer documentation on the api.drupal.org landing page for D8.

... for more information, visit the #drupal-docs channel on IRC or jump into the documentation issue queue.

As always, if you're new to contributing to core, check out Core contribution mentoring hours. Twice per week, you can log into IRC and helpful Drupal core mentors will get you set up with answers to any of your questions, plus provide some useful issues to work on.

Notable Commits

The best of git log --after=2014-03-12 --pretty=oneline (253 commits in total):

Amazing work on the configuration system's architecture and dependency management, notably:

• Issue #2080823 by alexpott, swentel, Wim Leers: Create API to discover content or config entities' soft dependencies and use this to present a confirm form on module uninstall.
• Issue #2030073 by alexpott: Config cannot be imported in order for dependencies.
  You can now declare dependencies for configuration entities, so you can ensure their dependencies are met before importing them.
• Issue #2219499 by Berdir, alexpott, Gábor Hojtsy, vijaycs85, swentel: Generalize language config override responsibility.
  This patch simplifies the way that language-specific overrides work and significantly reduces the amount of code that needs to run on sites with only one language.

And, we resolved some of the menu/routing issues that had been causing headaches for developers:

• Issue #2178725 by pwolanin, crowdcg, effulgentsia, Sutharsan: Make all core menu link machine names and the corresponding route names match.
• Issue #2226903 by pwolanin, dawehner, tvn, martin107, jessebeach: Step 1: Move static menu links to yml files.
  Now, default menu links are declared the same way as local tasks and local actions. (The next step is to finalize the underlying architecture for this change.)
• Issue #2207893 by dawehner, pwolanin, jessebeach, Boobaa: Convert menu tree building to a service.
  This removes a whole bunch of the code in menu.inc, makes the menu-building code unit-testable and decouples it from other subsystems. It also unblocks beta-blocking work on the Menu Link API.

In the "things that always annoyed you about Drupal" category,

• Issue #318975 by sun, Bojhan, linclark: Remove confirmation page after installation.
  When the installer is finished, it drops you on the front page of your new site!
• Issue #340723 by ParisLiakos, sun, Berdir, glennpratt, Cottser, swentel, tstoeckler, Xano, tim.plunkett, BassistJimmyJam: Make modules and installation profiles only require .info.yml files.
  That means no more empty .module and .profile files! DX FTW!
• Issue #2122693 by jayeshanandani, YesCT, sun, alexpott, BMDan: Installer does not work on a completely empty settings.php.
  This had been possible in D7.

Other notable commits:

• Issue #2188613 by Berdir, Xen, andypost: Rename EntityStorageController to EntityStorage.
  This 600K patch was added to make it easier to distinguish between Entity storage classes and Routing controllers.
• Issue #2213451 by andypost, bdone, benjy, penyaskito, chx, claudiu.cristea, damiankloip, gregboggs, InternetDevels, jessehs, jhedstrom, marvil07, mikeryan, pcambra, Xano, YesCT: Update Migrate API in core.
  This huge update to the migrate API adds support for requirements/dependencies; adds migrations for passwords, URL aliases and config entities; improves entity, bundle and field support; adds lots of Drupal 6 migrations; allows you to set the MigrateSource and MigrateDestination using annotations; and improves documentation. Awesome work Migrate team!
• Issue #1194136 by Berdir, damiankloip, Wim Leers: Re-organise core cache bins.
  This groups cached items by the type of data (e.g.: rendered HTML, data, entity), rather than the type of item (e.g.: node, block, etc.). This will make cache bins for frequently-requested items (like configuration) smaller with less-frequent updates, which makes it easier for query caches. And, it allows you to tune performance by choosing the most-efficient storage engine / storage location for the type of data (for example, putting the configuration cache table in RAM or on an SSD).
• Issue #2211553 by andypost, Berdir: Allow usage of entity_reference field widget and formatter for base fields.
  Entity reference fields are being used in core, but there had been no way to use it's widget and formatter.

You can also always check the Change records for Drupal core for the full list of Drupal 8 API changes from Drupal 7.

Drupal 8 Around the Interwebs

Here are a few notable blog posts about Drupal 8 in the past few weeks:

• Last Call Media explains the lessons they learned when upgrading their website to Drupal 8.
• Justin Harrell interviews Bojhan Somers and Lisa Rex about making it easier for designers to contribute to Drupal
• Drunomics wraps-up Drupal Dev Days Szeged.
• Pixelite Magazine posted a tutorial on Upgrading PHP to 5.4 on Ubuntu 12.04 LTS to support Drupal 8
• OSTraining introduces Twig and the new, simple Drupal 8 render pipeline.
• larowlan starts a series on Writing Drupal 7 code with an eye towards Drupal 8 by explaining the benefits of writing PSR-0 code in your Drupal 7 modules now.
• Jeffrey McGuire inteviews Lukas Smith, Symfony contributor and Fabrice Bernhard, co-founder of Theodo (a Symfony SaaS provider) about the benefits of Symfony and Drupal working together on episodes 129 and 130 of the Acquia podcast respectively.

Drupal 8 in "Real Life"

If you would like to get away from the computer, meet other Drupal users, learn about Drupal 8, and have fun at the same time, you can look forward to:

• NYC Camp on April 10-13: you can get Twig training, there are 13 accepted Drupal 8 sessions, 10 sprints scheduled and there's even a Core summit!
• DrupalCamp Frankfurt 2014 in Frankfurt, Germany on April 12 and 13; with 8 proposed Drupal 8 sessions on everything from Twig to the Configuration Management Initiative.
• Drupal Camp Japan 2014 in Kyoto on April 12, featuring an introduction to Drupal 8.

Whew! That's a wrap!

Do you follow Drupal Planet with devotion, or keep a close eye on the Drupal event calendar, or git pull origin 8.x every morning without fail before your coffee? We're looking for more contributors to help compile these posts. You could either take a few hours once every six weeks or so to put together a whole post, or help with one section more regularly. If you'd like to volunteer for helping to draft these posts, please follow the steps here!

So, I wanted to do the Acquia Certified Developer exam. But I got into trouble before I even start taking the exam.

What got me into Drupal from the beginning were that it is open source, I love open source and what we could together with open source, and I do my daily work on an Ubuntu powered laptop. Why am I writing about that right now? I registered for taking the exam online at www.webassessor.com, and after I set a date and time for the test, I was told to download a piece of software called Sentinel. Sentinel is going to be used when I take the exam, to check me through the web cam, checking it is me doing the test, and I don’t have colleagues helping me out. Fair enough.

I clicked the link, and it was a installer for Windows. Something must be wrong somewhere. I searched the site. It seems that the program I need to install only is available on Windows and Mac. WTF! So I tried to install it with Wine (with that some Windows programs could be run on Ubuntu). Did not work, but I could figure out it was some kind of Flash software.

So I am stuck. I need to have a proprietary OS, I need to install proprietary software to take an exam for an open source system. All this seems totally wrong. Some bad decision has been taking on the road for this exam.

Story will continue (hopefully).

Sometimes you need to display a field that have no input, like a static text or image on each node, or a Facebook like button, or whatever that does not have an input, but you still want to display it as a field, for that you have the hook hook_field_extra_fields.

To display a psuedo field you just need two functions (these functions I added to a custom module called wk_extra_fields)

<?php
/**
* Implements hook_field_extra_fields().
*/
function wk_extra_fields_field_extra_fields() {
  $extra = array();
    // Just adding the psuedo field to the page node type.
    $extra['node']['page'] = array(
      'display' => array(
        'wk_foo' => array(
          'label' => t('WK: Foo'),
          'description' => t('A foo field.'),
          'weight' => -5,
        ),
      ),
    );
  return $extra;
}

/**
* Implements hook_node_view().
*/
function wk_extra_fields_node_view($node, $view_mode, $langcode) {
  // The field is showed in when using full view mode and on page node type.
  if ($view_mode == 'full' && $node->type == 'page') {
    $node->content['wk_foo'] = array(
      '#markup' => '<div class="wk-foo">Foo!</div>',
    );
  }
}
?>

So we use the function wk_extra_fields_field_extra_fields() to create the psuedo field for the page node type, after that we can activate it in the display tab, and choose where to show the field.

When we view the node, the function wk_extra_fields_node_view() is called and the content is displayed.

Image: "Air Guitar Championship" by AxsDeny. Attribution-NonCommercial-NoDerivs License

The biggest step forward since From Commerce Store to Commerce Marketplace, my previous blog post in the Commerce Marketplace series, was added initial support for parallel payments.

You may not be able to control when Drupal 8 is ready. But you can control when you are ready for Drupal 8. Attending DrupalCon Austin is a great way to start.

A few months ago I posted about how to create a custom Panels pane, a critical reference for anyone who uses Panels layouts. The other part of the toolkit for quick and awesome layouts is the Display Suite module. With DS you can create new “Display modes” for your content, to be reused around the site. For example, on one recent site I had four standard ways to display my nodes: Full, Teaser, Mini-Teaser, and Search Result. DS made this configuration a cinch.

But just as in Panels you sometimes need a pane that isn’t provided out of the box, in Display Suite you sometimes want to add a field that isn’t really a field on your content. In a recent site build, I used this capability to include information from the Organic Groups a user belongs to on his profile as it appears in search results.

DS offers some ability to create this kind of custom field through the UI, but I’m talking about more complicated outcomes where you need/want to use custom code instead. This is actually even easier than custom panels panes.

In our example, we will display the user’s name, but backwards. Obviously you can do much more complex things with this, but it’s nice to have a simple example!

Declare your fields

First we have to tell Display Suite about our new custom field. We do this with hook_ds_fields_info().

mymodule.module1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 <?php //@file: Add a custom suite to display suite for Users. /** * Implements hook_ds_fields_info(). * Declare my custom field. */ function mymodule_ds_fields_info($entity_type) { $fields = array(); if ($entity_type == 'user') { $fields['backwards_username'] = array( 'title' => t('Backwards Username'), 'field_type' => DS_FIELD_TYPE_FUNCTION, 'function' => 'mymodule_backwards_username', ); return array($entity_type => $fields); } return; }

Any guesses whathappens next? That’s right, we have to write our render function under the name we just declared. You can put anything here, really anything renderable at all.

mymodule.module1 2 3 4 5 6 7 8 /** * Render function for the Backwards Username field. */ function mymodule_backwards_username($field) { if (isset($field['entity']->name)) { return strrev($field['entity']->name); } }

That’s it. So simple, you’ll wonder why you ever did it any other way!

Drupal 8 Lessons for Developers

A couple months ago, we decided to rebuild our company site on Drupal 8.  We had two goals in mind when we were planning the project.  First, we wanted to expose our developers to some real life scenarios in working with Drupal 8.  We had all been involved in the Drupal 8 development cycle in one way or another, but building a production site is very different from setting up a development instance.  Our second goal was to prove that it was possible to launch a feature complete Drupal 8 site without any contributed modules.  In my opinion, we succeeded on both counts.  There were certainly some snags in the process, but overall it was an enjoyable experience for everyone.  I’d like to share our major take-aways from the project with you.

1.  Stronger division between the “themer” and “module developer” roles  
The switch to object-oriented programming for all of the core subsystems has been talked about quite a lot.  And yes, it is a big transition.  Some crazy high percentage of our core code has changed or moved.  As a module developer, it’s going to be up to you to learn all about Routes, Plugins, Event Listeners, and more just to do the same things you used to use hooks for.  I don’t think anyone will argue that the new way is simpler for module developers.  But I was ready for that.  I transitioned from Drupal 6 to Drupal 7.  I remember that feeling of firing up the new version for the first time and feeling like you’re walking into your house after your mother-in-law dropped by for a visit - you know everything’s there, but you just don’t know where it is anymore.  
What caught me by surprise is how little has actually changed at the theme level.  Sure, there’s Twig, but when you get right down to it, Twig doesn’t even feel that different from raw PHP templates.  Once you learn the basics, my guess is that most people working with Twig will feel more comfortable there than in PHP code.  So, what’s really changed from the themer’s perspective?  Not a whole lot.  In fact, right now it feels like a conscious effort was made to keep things consistent at the theme level.  

2.  Fewer conflicts
I’ve been using and teaching Features for years, and there’s one question that always made me cringe: “How do I avoid conflicts/merge conflicts with my features?”  My answer would usually get very abstract and I’d be talking about packaging strategies and complex push/pull/revert commands.  Now that CMI is here, we have the tool we always wanted.  Instead of combining stuff into giant PHP files as Features does, CMI writes one file per configuration object.  While this sounds really verbose, it prevents a situation where you’d get a conflict if you and a coworker change different views in the same file, since every view is in it’s own file.  In the two-month development cycle we had for our website, I think we may have ended up with a single merge conflict resulting from configuration changes.

3.  No more packaging nightmares
This goes along with my previous point about CMI, but trying to teach the right way to use Features involved a lot of abstract and hand-wavey concepts like semantic grouping and composition (and that’s just for the way I consider right).  Now that we have a true configuration management tool, we don’t need to worry about packaging at all.  Think that through for a moment.  There is no longer a need to bundle components into groups.  It all goes into one big bucket for your site.  For those of you who actually do use Features for bundling reusable components, don’t worry.  Features already has a dev release for Drupal 8 that focuses solely on grouping config into modules.  

4.  You need an editor that autocompletes
Sorry, Notepad++ enthusiasts, but you’re going to want a bona fide IDE to do any serious development on Drupal 8.   Now that we’re using a lot of OO code, you can have a documentation trail that might be spread over 5-10 parent classes/interfaces.  It is extremely nice to be able to command+click a method name to go directly to the definition and read the docblock.  It’s even better to have your editor autocomplete the method name for you.  Plus, there are a lot more types of code in core these days (YAML, JSON, and others), and it’s nice to have syntax highlighting.

5.  Think global, act local
In case you hadn’t heard, theme(), drupal_add_js(), and drupal_add_css() functions have all been removed from Drupal 8.  The new way of doing things is to always return a render array.  The short explanation for this is that rendering stuff involves adding assets (CSS/JS) to the page, and when you call theme(), those assets are just added to a global variable somewhere.  That worked fine for Drupal 7, but since we’re a bunch of forward-thinking folks, we want our pages to be able to work with subrequests, which are a way of rendering a page using multiple processes. And guess what?  Separate processes don’t share global variables.  So, when you return the HTML for your cute little teddy bear field formatter, you should return a render array with your CSS/JS assets specified using the #attached property.

In summary…
Diving into Drupal 8 was a lot of fun for our team.  Yes, that’s right, I said fun.  We enjoyed it, partly because it’s the new stuff, and partly because it was our project.  Whereas we would have felt dangerously stressed doing our first Drupal 8 site for a client under a tight deadline, we were able to focus on learning the new workflows, contributing bugfixes, and developing best practices.  

We first posted about our Drupal 8 launch here.

Attached below are wallpaper ready versions of the image at the top of this post.