The monthly Drupal core bug fix release window is scheduled for this Wednesday. However, there haven't been enough changes to the development version since the last bug fix release three months ago to warrant a new release. A Drupal 7 bug fix release during the March release window is likely instead.

Did you know that DrupalCon isn’t just for developers? The community survey we conducted at the end of 2014 turned up some interesting facts, including the fascinating statistic that only about half of DrupalCon attendees self-identify as developers? With project managers, C-level executives, and Drupal sales and marketing experts in attendance, DrupalCon is a great place to meet a wide array of passionate Drupal users and advocates.

So, who goes to DrupalCon? Check out the infographic below for a more complete picture of who attends the biggest Drupal conference on earth.

So you are taking the plunge into learning Drupal 8 for the purpose of developing sites, modules, themes, etc. You're a great Drupal 7 developer, familiar with many drupalisms but you don't have tons of experience for modern PHP frameworks, principles and practices. Well, Drupal 8 still includes many of the old drupalisms but still attempts to keep in line with times and modernise itself.

In this article I want to outline 6 steps I believe you should take to get started learning how to develop custom modules and/or themes in Drupal 8. On top of these 6 builds everything else.

The first three are PHP related in a more general fashion, while the last three target aspects of Drupal 8 itself.

1. Learn Object Oriented Programming

One of the biggest difference between Drupal 7 and 8 for developers is the way code is written. It's still PHP but it's now much more object oriented. Global procedural functions are still in place but most of the logic happens in classes.

In case you don't have much experience with Object Oriented Programming in PHP, this is the first thing you need to learn, brush upon or revise (depending on your level). There are many resources available out there, all scattered as hyperlinks in this section. There are also courses you can take, both free and paid.

Without quite a solid OOP foundation, you won't be able to understand much of how Drupal 8 modules are built.

2. Learn how to use Composer

One of the consequences of modernizing PHP has been the introduction of the Composer package manager. Projects are no longer built without it as it does a great job of installing, updating and managing in general the external libraries and dependencies of your project. Not to mention its very helpful autoloader.

Drupal 8 uses Composer to manage external PHP libraries and dependencies (such as Symfony components, Guzzle, etc) and there is talk about the ability to handle also contrib modules. So make sure you know how Composer works and even start using it in non-Drupal projects.

3. Get familiar with Symfony

One of the main points of contention (back then) in the Drupal 8 development cycle was the introduction of Symfony components. Some people didn't really agree with this great shift from they Drupal way, but others embraced it wholeheartedly. I am in the latter group as I love Symfony and used it even before developing anything in Drupal 8.

Drupal 7 developers are often being told that knowing Symfony is not required in order to develop in Drupal 8. While technically true, you still end up learning a lot of it through the Drupal experience. That being said, I strongly recommend learning some Symfony before. It is a great modular framework and knowing its concepts will really help you out in understanding how Drupal 8 is built (for the components it uses I mean). Once you can build a small website in Symfony, you'll enjoy developing in Drupal 8 that much more because concepts will be similar a lot of the time. Not too mention that you can use Symfony to build apps on its own.

4. Routing and controllers

Just like with Drupal 7, when starting to learn Drupal 8 you need to create the obligatory hello world module (creating a page with a parameter in the URL( usually world) that displays the text Hello + parameter). This example introduces you to many important things:

Module folder structure

Routing (no more hook_menu) through routing.yml files that map to Controller methods

Controller classes which have various methods that can be mapped to routes

Access arguments for these routes

Rendering markup to the page inside the Controller methods

etc

So I really recommend giving this a go.

5. Plugins

Another important concept you'll need to get familiar with is Plugins. Admittedly, this not the easiest to grasp, but it is super important because it's everywhere. Not to worry though, it's not rocket science.

Many old Drupal 7 implementations of various concepts have been transformed to plugins: info hooks, blocks, field formatters, views handlers, etc. Understanding plugins is therefore also very important for being able to extend default Drupal functionality.

6. Dependency injection and the service container

The last step I am going to mention here is dependency injection. Drupal 8 uses the Symfony dependency injection container to manage service instantiation and injection into classes that need them. This helps decouple functionality and increases testability.

However, many people are scared of this concept, mainly because they don't grasp it. I wasn't super comfortable either before understanding it. But you should definitely learn what it means, why we use it and how we use it. Because it is a very simple concept that is used all the time in procedural code as well.

You can already find many tutorials out there on Drupal 8 that load services statically through the \Drupal class. It is much faster to write so people (me included) prefer it when writing about D8. I usually also tend to make a note that using dependency injection is preferred in theses cases.

Not understanding what the service container and dependency injection is will easily let you fall into the habit of just statically requesting services and coupling your code like it was procedural. Once you are clear on this point, this will hopefully not happen any more and the sight of a \Drupal::get('some_service') will make you think twice.

Conclusion

There you have it. What I think are the first 6 steps you should take when learning Drupal 8 for the first time. Of course there are many other important things to learn and do but I believe they build on top of this foundation. Of course, this is me writing so others may have different opinions (very much welcomed in the comments). So let's discuss.

You have built an application where there was a taxonomy or options field with more values defined in them than what was really being used after release. And these fields are being used as exposed filters in a View. This basically means that you end up with an option in an exposed filter that yields no results when selected. Not a good UI behaviour, and confusing for the end user.

It’s a great time to be part of the Drupal Association. We’ve done some amazing work in the last few years, and we’re in a great position to work with the community to continue to improve and grow fully into our mission. As a Drupal Association At-Large Director, you’d be in the center of the action. The At-large Director position is specifically designed to ensure community representation on the Drupal Association board and we strongly encourage anyone with an interest to nominate themselves today.

The Board of Directors of the Drupal Association are responsible for financial oversight and setting the strategic direction of the Drupal Association. New board members will contribute to the strategic direction of the Drupal Association. Board members are advised of, but not responsible for matters related to the day to day operations of the Drupal Association, including program execution, staffing, etc. You can learn more about what’s expected of a board member in this post and presentation.

It’s a great time to be part of the Drupal Association. We’ve done some amazing work in the last few years, and we’re in a great position to work with the community to continue to improve and grow fully into our mission. As a Drupal Association At-Large Director, you’d be in the center of the action. The At-large Director position is specifically designed to ensure community representation on the Drupal Association board and we strongly encourage anyone with an interest to nominate themselves today.

The Board of Directors of the Drupal Association are responsible for financial oversight and setting the strategic direction of the Drupal Association. New board members will contribute to the strategic direction of the Drupal Association. Board members are advised of, but not responsible for matters related to the day to day operations of the Drupal Association, including program execution, staffing, etc. You can learn more about what’s expected of a board member in this post and presentation.

Here is a known fact - it's really easy to break the sites you are building. One wrong line of code, and a page is returning a 503 error.

Here is a known secret - (almost) nobody is doing QA. Since I'm not into arguing about this, I'm willing to soften it a bit to "most companies, don't do proper QA".

The reasons are pretty clear - not enough time and not enough budget. This post isn't going to be about the importance of QA - that point is clear to everybody, but rather give realistic tips and tools that will allow you to start improving the quality of your projects, and actually even save you some time and money.

When I first wrote Ubercart's Cart module, we knew we were going to support both anonymous and authenticated shopping carts and checkout. The decision came at a time when there wasn't consensus around the impact of forced login on conversions, but we knew we wanted it to be optional if at all possible. Additionally, for authenticated users, we wanted to preserve items in their shopping carts so they would see the same items when logging in from multiple devices or across multiple sessions.

This resulted in a small conflict that we had to figure out how to deal with: users could have items in their authenticated shopping carts but browse the site anonymously, create a new shopping cart, and then log in. What should happen to the items in their authenticated carts vs. the items in their anonymous carts?

There are three basic resolutions: combine the shopping carts together so the user still has a single shopping cart, remove the items from the previous session and leave it up to the customer to find them again if desired, or retain the old shopping cart but ignore it until the customer has completed checkout for the current cart. In Ubercart, I chose to combine the items, but in Drupal Commerce I changed course to retain the old cart but, from the customer's point of view, treat that anonymously created cart as the current cart after login.

We got some push back for this decision, but ultimately I didn't change the default functionality of Drupal Commerce. We just made sure there was an appropriate hook (hook_commerce_cart_order_convert()) so developers could alter this behavior on a site-by-site basis as need be.

From the merchant's standpoint, the thinking behind combining carts goes that you don't want customers to forget they intended to purchase those products in the past. However, from the customer's standpoint, suddenly having additional items in the cart after logging in during the checkout process is quite jarring.

In fact, I've been bitten by this behavior when shopping online at Barnes & Noble. Weeks prior to placing an order, I had put a Wheel of Time novel in my shopping cart but eventually bought the book in store. When I came back to the site to purchase a gift for my wife, I used a login button on the checkout form to quickly reuse my previous addresses and payment details. Unbeknownst to me, the website combined my old shopping cart with my current one such that my "quick checkout" experience made me accidentally order a book I already owned! I then had to spend 30 minutes with customer service canceling the order and placing it afresh just for the book I actually wanted.

That experience confirmed in my mind we made the correct decision not to combine carts automatically. As eCommerce framework developers, we have no clue where a developer might like to integrate login during the checkout process. Best to let them decide if it's safe to do something with those previous cart items instead of silently making the decision for them.

That said, I believe we can improve the experience. Right now, Drupal Commerce retains the old shopping cart order, and after the customer completes checkout they'll see the previous shopping cart as their current cart. This can be confusing as well! My ideal situation would likely be a user interface component on the shopping cart page where customers can see items they had added to their carts in previous sessions, giving them the option to add those products to their current carts. If they decide not to, I don't see any harm in then just deleting those historical carts and moving on.

Sometimes, diving in to try and help work on something in an open source project can leave you feeling stupid, lost and confused. Generally, you'll find you are not alone. Sharing the problem, and the solution when you find it, can be helpful to build your own understanding, but also might help others too. So, just in case I'm not the only one feeling lost and confused about why the path / route / link issue in Drupal is so complex, I thought I'd share some of my confusion and a little ray of light that might help unravel this tangle of related terminology.

Can someone describe how drupal uses these terms? route, path, url, uri, link, menu item - or point me to a reference?

Angela Byron generously responded with a rough outline of definitions, which I've fleshed out a bit below with some references.

Route

"this URL goes to this PHP code, and can only be accessed by these kind of people."
As far as I can tell, this is a relatively new concept for Drupal with routing and controllers, replacing the hook-menu system we had previously. Here's a couple of references that might be helpful if you want to build a deeper understanding.

The path is like a pathway to find content eg. admin/content but because it can be an alias, it may not actually represent the location of a file on disk, which helps lead to some of the complexity under the hood in Drupal, and the confusion about when to use http://example.com/blog/yakshaving, /blog/yakshaving, or node/5

Link

<a href="/foo">foo</a> - This one seems pretty straightforward - it's the HTML markup used to point to a URI or path.

Menu item

A link in a menu - which could be pointing to a route, path or URI.

Hope that helps you, it certainly helps me to lay it all out like this. And, just in case you're wondering how I fell down this rabbit hole, this relates to a series of critical issues holding up the release of Drupal 8. If you can help, please get involved orbuy a ticket in my chook raffleto help fund the Drupal 8 Accelerate initiative.

The Drupal Association is thrilled to announce the addition of four new staff members. As part of our goal to increase Drupal adoption and provide the community with strong support and advocacy, the organization has been growing at a rapid rate over the past year. Now, we’re welcoming four new staff members into the fold. Please help us say hello to Elise, Lucia, Rachel, and Tim!

Elise Horvath, Operations Team, Operations Coordinator

Elise (EliseH1280) is joining the Operations team as an Operations Coordinator. She will manage key details of the Drupal 8 Accelerate program, will manage the Drupal Store, will assist Operations with any accounting needs, and will assist the board of directors by managing meetings and schedules and taking meeting minutes. Prior to joining the Association, Elise worked in logistics and operations for scrum training services. When not working, Elise enjoys spending time with her fiance, watching movies, cooking and baking, riding her bike, and going to Disney World whenever she has the chance!

Lucia Weinmeister, Revenue Team, Sponsor Fullfillment Coordinator

Lucia (lweinmeister) is the Association’s new Supporter Fulfillment Coordinator, and will be working with the revenue team to ensure that all our Supporting Partners, Hosting Supporters and Tech Supporters get the most out of their sponsorships. Lucia is one of three Austin, TX-based Association employees, and comes to the Association with a marketing and advertising background. Lucia was born and raised primarily in Mexico City, is fluent in Spanish, and enjoys reading, running, doing Crossfit, cooking, and chasing around her two sons, Bruce and Leon.

Rachel Rivera, Revenue Team, Junior Account Manager

Rachel (rayn1ta) grew up in the San Francisco area and spent four years living outside the US in Latin America, Asia, Africa and Europe. She has worked as a ski instructor, English teacher, and digital marketer. In addition to learning foreign languages, she enjoys yoga, hiking and scuba diving. As a Junior Account Manager with the Drupal Association's revenue team Rachel will focus on identifying and satisfying the needs of awesome Drupal Businesses.

Tim (timconstien) is joining the Association’s Community Programs team as a DrupalCon Sponsor Fulfillment Coordinator. In this position, he will be ensuring that DrupalCon sponsors enjoy all their benefits and receive top-quality service before, during, and after the convention. Tim is a graduate of Oregon State University, and most recently worked to support the sales and marketing departments at a national radio group based in Portland. In his free time, Tim enjoys exploring: Whether he is finding new pubs to shoot pool at, finding the new best food joint, exploring new tree runs to snowboard through, or road tripping to the next music festival, he is always on the go.

Please help us give a warm welcome to our four new staff members. It’s great to have you on board!

We're always on the lookout for great sites built with Drupal Commerce, our truly flexible software that's changing the face of eCommerce one site at a time.

Pam Kerr is one of New Zealand's leading independent jewelry designers. Her company - Pam Kerr Designs - had a Shopify site that served retail customers well, but it didn't meet their growing B2B needs. With the help of Blue Fusion, a New Zealand based web design and development chose Drupal Commerce for its flexibility, power and customizable user interface.

I quite often use Mollom to prevent spam submissions on contact and comment forms. It works pretty well, but some spam still gets through.

An alternative anti-spam technique is to require a Bitcoin dust transaction before an unprivileged user can POST a form. The value of such a transaction would only be about $0.001 USD. For a non-spammer this cost is fine, but for a spammer this is enough to make it totally uneconomical as they need to send out millions of posts.

I created a Spam Filter sub-module in my Coin Tools project for Drupal. It can be used to require a Bitcoin payment on any form on a Drupal website.

Coin Tools already has a Bitcoin payments system. When viewing a form, a new payment is created for the minimum amount possible. In the latest Bitcoin reference implementation the smallest output is 546 satoshis. However, many wallets still use the old value of 5460 so that is what is used.

The form's submit button is hidden with CSS (it still needs to be in the DOM for the form to function correctly) and a clickable QR code for the payment is put in its place. Coin Tools payments are BIP 70 compatible so a payment can either be satisfied by a direct POST from the wallet to the Drupal website, or the wallet can broadcast the transaction through the Bitcoin network (slightly slower).

Once Coin Tools has determined that the payment has been completed it will POST the form via JavaScript. If there are any validation errors the form will reload in the normal Drupal way. In this case, the submit button is no longer replaced by a QR code as it is recorded in the form state that the payment has been made.

When the form is submitted it is also verified on the server that the payment has been completed.

Of course, this technique requires that the user has a small amount of bitcoin. For a website not targeting the Bitcoin community it would not only prevent spammers it would actually prevent everyone from posting. As Bitcoin usage increases this technique will be able to become more commonplace.

Browser integration

It has been proposed before that web browsers should have Bitcoin SPV wallets built-in, e.g. for paywalls. If a payment is required an "HTTP 402 Payment Required" response would be generated. In that situation it would make sense for the browser to prompt the user before a payment is made. For the spam filter this could just happen automatically. The transaction could actually just be included as part of the POST to submit the form.

Burning Coins

Because the transactions are for such a small amount it may not be economic to spend the received funds as large miner fees would be required. It might be simpler to just generate a random Bitcoin address for each payment. This means that you don't have to have a wallet on the server and could just use Chain to check if the payment has completed.

Double-spends

If a double-spend on a comment submission was detected after it had been accepted, the post could be deleted. For email submissions, they could be delayed a few seconds to be sure there is not a contradictory transaction floating around.

Even without implementing these protections, double-spending wouldn't make sense for a spammer.

Could a spammer double spend and avoid paying the dust amount? No - double spending is extremely expensive so it would be even worse value for money than just paying the dust amount.

Could a spammer simultaneously broadcast many transactions that spend the same outputs to many different forms and websites? In theory this might be possible and some of the forms would accept the POST before realising the transaction is a double spend. Spamming multiple forms on the same website simultaneously would be impossible because the website would be connected to just one Bitcoin node. If this did become an issue the fee required to POST could just be increased to make it uneconomic.

Greater amount?

Of course, it may be desirable to actually charge a larger fee for the purpose of generating revenue. The admin interface could be extended to allow a configurable amount.

In this week's episode Addison Berry hosts Greg Anderson, one of the Drush maintainers, and Juampy Novillo Requena to discuss Drush. We start off by explaining why Drush exists and some cool things about it. One of the big hangups people have with Drush is installation, so we talk a bit about that, and how it is easier now with Composer.

This blog post is a short story of how I started working for a Drupal company, some of the things I've achieved during my first year in the industry and my impressions of working with a Drupal agency as a sysadmin.

Before I pelt you with details of my first year as a sysadmin, I think I should give you a little information about myself. I’m Emlyn, 23 years young and based in the UK...the West Midlands to be a little more precise.

I graduated from Coventry University with a 2:1 in Games Technology with the hope of becoming a games programmer. However, after graduating, I noticed my portfolio fell far short of other students on my course, and, I’ll be honest, that bummed me out.

That was when I was approached by my cousin, Jamie, who works as a Systems Manager for Code Enigma, with the prospect of training to become a Junior Sysadmin. I gave it some thought; I had always been interested in Linux systems and wanted to know more about them. In fact, one of my modules at University was Operating Systems Security and I thoroughly enjoyed the assignment we were given where we had to create a shell script that provided the ability to display working processes, navigate a directory, list online users, amongst a few other things. So, I accepted the offer of a three month internship, which started in October 2013, which then turned into a permanent position in January 2014, and I really haven’t looked back since!

Training

As with every new job in a new field, training is required. For me, this was two weeks in Cardiff with Jamie, trying to learn as much as possible before working from home by myself. It was daunting, I’ll be honest. I knew there was so much to learn in a very short space of time. Perhaps I put too much pressure on myself; no one expected me to become an expert in just two weeks!

On the very first day of my internship, I was given the task of ‘building’ a new server which would serve as an internal server. So, my first lesson was in Puppet and how to use it to provision a new server semi-manually. This blew my mind! A few simple-ish (well, now I think they’re simple-ish) steps and Git pushes later and a new, usable server was up and running. Let me go back on myself, my first lesson was in Puppet and Git. One interlinked the other, and vice versa.

In a sense, I was thrown in at the deep end, given tickets to work on myself. Jamie pointed me in the right direction and gave me hints and tips that aided me in my work. In all honesty, his method of training me was brilliant, perfect. I’d try the work assigned to me first, and ask for help when I needed it.

Over the course of the two weeks, Jamie never showed any impatience or annoyance at what I was doing, even if I did something completely wrong or didn’t understand what had to be done. He taught me an important part of being a sysadmin: patience, especially patience towards clients. I had to understand that the client may not know as much as me, even though I’d only been in the industry for two weeks myself!

Over the course of my three month internship, and in fact the following nine months, my training never really stopped. I was learning new things every single day, all the while fine-tuning my newly acquired skills. Another important lesson I learnt during my first year as a system administrator was that I will never know everything there is to know in being a sysadmin, there will always be something new to learn.

Working from home

Being given the chance to pursue a totally new career and develop new skills was fantastic and an opportunity I couldn’t turn down, but what put the icing on the cake was that I’d be working from the comfort of my own home. However, I realised that I was going to have to be very disciplined, even more so than I normally would. It dawned on me that my fellow colleagues would be trusting me to work efficiently and I did not want to let them down by being slack just because I was working from home.

Working from home has its advantages, as you can imagine. No suit and tie and no long commute to work every morning. So there’s not a mad rush in the morning and I don’t have a busy office environment around me to distract me from my work. However, I am alone (as are my colleagues), which means not being able to walk up to them should I have a question or concern and not being able to go for a drink or food after work. But, these disadvantages, I feel, are out weighed by the advantages of working from home.

Running a distributed company can be quite challenging. My boss, Greg, is currently working on a series of blog posts in which he goes into detail about being Spread About. It's well worth a read.

What was I expecting?

I’ll be honest, I didn’t know what the job was going to be like! All I knew was that I was going to be learning a lot in a short space of time. From the email conversation I had with Jamie before starting, I had a feeling it was going to be all hands on deck. A lot of the time, I’ve been kept busy all day dealing with several different clients, all wanting different things done. Other days, it’s been a little less busy and I’ve been able to spend a bit more time on each task.

Surprises! Of all kinds of variety

I’d be lying if I said I hadn’t been surprised by anything. I think what surprised me the most in my first year, and what still baffles my mind today, is the sheer number of tools and software available to a system administrator. For example, we use Percona as our database of choice, but we could use MongoDB, or MariaDB. Then there are multiple database caching systems to choose from, numerous HTTP accelerators, web servers and continuous integration tools! My point is there isn’t a short supply of tools available; in hindsight, I’m not sure why that surprised me, but it did.

Top five things I’ve learnt

A year ago, I knew very little to nothing about being a system administrator. I could be very lazy and just list the top five things I’ve learnt in my job, but I’ll try and be a bit more descriptive. In no particular order of importance:

Patience is actually a virtue! I’ve learnt that when dealing with a task, be it for a client or a personal task, to be patient with it. Getting frustrated and angry (perhaps covertly when dealing with a client) will only make matters worse and lengthen the time it takes to solve the problem. Clients who are not as technically knowledgeable appreciate patience; as I described above, Jamie was incredibly patient with me during my training, which helped me to understand the problem at hand more easily.

Security is important. Very important. I deal with client data on a daily basis, so being proactive in keeping my workstation and computer secure at all times is important. I’ve learnt to be vigilant when transferring data to a client or a colleague; rather than send them a sensitive document over plain text email, I’ll upload it to a server the recipient has access to so they can grab it from there themselves. I’d GPG encrypt an email to them, but ever since the people who make the GPGTools plugin for the OSX mail app have started charging for the service (shakes fist), I’ve opted to use other means. We at Code Enigma like FOSS! Over the last year, Code Enigma have become ISO 27001:2013 certified, which meant I had to learn and understand how to handle data and documents properly.

Workflow is also important. I learnt about the simple, yet very effective, workflow used by Code Enigma in the first couple of weeks of joining the company. It’s as straightforward as this: master -> stage -> production. Push changes to the master branch first, then merge them through to stage after some initial testing. Once the client is happy and has signed off the changes, push them through to production for deployment to the live site. Simples! However, before I joined CE, I didn’t know or think like this. When I ran an online game with my brother (not in Drupal), I’d make changes to the code locally, with no local setup running, and FTP (ew) the updated files directly to the server, which affected the live site. Horrendous. Now, when I start work on a personal project, I have an exact workflow I want to follow.

Drupal...well, a small amount. A very small amount. Primarily, I’m a sysadmin, so I do a lot regarding setting up Drupal sites and debugging server issues relating to Drupal. I did a small amount of Drupal development at the start of my employment, so learnt a little bit about it which has fared me in good stead when it comes to dealing with simpler Drupal issues.

Linux. Well, obviously not all of it, but I have learnt a lot in my first year. Obviously there are some things I’ve learnt that I need to improve on, but that’s a given with most operating systems, especially Linux. I knew a little bit about Linux before joining CE, but only rudimentary stuff from using Ubuntu as my main OS for a little while. During my first year, I picked up some really useful tips and tricks, learnt of different command line tools and how to use them, such as Drush and learnt how to read system and access/error logs. That’s just to name a few Linuxy things I’ve learnt.

What I hope to do/learn in the next year

There’s so much out there to learn that appeals to me, I could probably write a separate blog post just about that! But what I really want to learn, that I think will benefit me as an individual and my role in Code Enigma, will both be time consuming and difficult: MySQL multi-master replication and DRBD, to assist our Australian sysadmin with server cluster issues, and Drupal 8. I’ve a head start (ish) on Drupal 8 in that I know a bit about PHP, but I’ve been made aware the PHP I know and have programmed in is archaic and old-fashioned. It’s time to delve into Object-oriented programming!

It would be great (for me at least) to get a text-based, role-playing game up and running in Drupal, be it 7 or 8. But seeing as I want to develop my D8 skills, it makes sense to develop the game using the latter of the two. As I previously mentioned, I used to run an online text-based game with my brother, which used a very poorly written engine now that I look back on it. I’ve not seen many, if any, games of the sort created using Drupal. Even if no one plays the game, it’ll still be an achievement in my eyes as I’ll have improved my Drupal knowledge.

MySQL multi-master replication will be an important concept to understand and know how to use because we have a handful of clients that have a high availability layout setup with us, which include two application servers and two database servers, at least. If there’s a blip in the network, replication between the servers can be affected, which requires manual intervention to put right. If this happens, our Australian sysadmin is woken up through the use of his batsignal, but if I could solve any replication issues and save him being woken up in the early hours of the morning, then it’s a win-win for both of us; I’ll have bolstered my knowledge and Mig won’t be woken up abruptly.

What are my impressions after my first year?

My impressions after my first year as a system administrator for a Drupal agency are very high; the other sysadmins in our team are incredibly knowledgeable and can adapt to every situation and issue thrown at them. This has given me inspiration to develop my skills and knowledge to reach their level and some day leave the same kind of impressions on a future junior sysadmin.

My impressions for working for a Drupal agency are just as high. My colleagues are all very clued up in their area of expertise, from Drupal magic to content strategy to finance management. Everyone does their part for the company, be it providing bespoke tools for a website (such as the ones used for this very site) or by providing top level training to new, or old, Drupal agencies. It's an honour to be part of such a fantastic team!

Main image by Wendy Seltzer, released under the Creative Commons Attribution 2.0 Generic license.

In my last blog post I explained what the Panels Suite is and does. I explained how Panels itself is a User Interface on top of hook_theme() and theme(). That technical explanation of Panels underlines what I think is its main conceptual virtue:

Panels encourages a mental model of pulling data into a specific design component

At Palantir we're working with Design Components that are created in static prototypes. Design Components are the reusable pieces of front-end code that compose a design system. Design Components should not know about Drupal's internal implementation details. We're not alone in this thinking. (Inside the Drupal community, and outside of it).

The task of "theming a node" is now "print this node so that it renders as this design component." Unfortunately Drupal core does not have <code>hook_design_component()</code>. It has <code>hook_theme()</code>. Some of the entries in <code>hook_theme()</code> from core are essentially design components.

Entries like <code>‘item_list'</code> and <code>'table'</code> are design components. They are conceptually based around their HTML rendering. They make sense independent of Drupal. To use them as a Drupal Developer you need to get your data organized before you call <code>theme()</code> (directly or otherwise).

On the other hand, much of the Drupal core usage of <code>hook_theme()</code> is not at all design component minded. <code>'node'</code>, <code>'user'</code>, <code>'comment'</code> all have entries in <code>hook_theme()<code>. In these elements you don't have to organize your data before calling <code>theme()</code>. You can give <code>theme()</code> a node object and after that <code>template_preprocesss_node()</code> has to do a ton of work before hitting the template.

It's no coincidence that the design component-ish <code>hook_theme()</code> entries have minimal preprocessing or no preprocessing whatsoever. The design component-ish entries like </code>‘item_list'<code> know what the HTML will look like but have no idea what your data is other than you were able to get it into a list. The non-design component entries like node know exactly what the Drupal-meaning of the data is but know very little about the markup they will produce on most production sites.

Panels unites the two mindsets. It knows what the incoming data is (A node context, a user context, etc) and it knows what design component it will print as (the layout plugins.) If you put a debug statement inside of </code>panels_theme()</code> you will see the names of layouts and style plugins. These </code>hook_theme()</code> entries are more of the design components-ish <code>hook_theme()</code> entries. They know what their markup will be. And the part of Panels most people pay attention to, the drag-and-drop interface, is where you control how the data of a node is going to prepare itself for the design component.

And here is where the admin UI of Panels might set up a confusing mental model.

The next time I get into a discussion about Panels at a meetup, DrupalCamp, or DrupalCon, think I'll first ask, "Does Panels let you think about building websites the way you want to think about building websites?" I like to think about passing variables into encapsulated configuration associated with a specific design component. I prefer that mental model to the "show and hide based on globals" mental model of Core's Blocks or the "just call theme() on a node and figure out the overrides later" mental model encouraged by node--[content-type].tpl.php. As the Drupal community asks itself again how it wants to do rendering, let's also ask "how do we want to think about rendering?"

The rise of design component thinking in the wider Wweb development world is not turning back. Web Components and modern front end MVC frameworks encapsulate design components. They do not care about every single implementation detail and layer of a node object. They care about getting variables ready for printing and updating. Panels module may fall out of the picture once Web Components fully mature. Until then, Panels allows for us to think in ways we will need to think for Web Components to work with Drupal.

Drupal 8 has been all about pushing the boundaries, so why should help content be any different?

With the release of Drupal 8, we will also ship with tools to complement hook_help() entries: if you, the developer, are providing a documentation page for your module, why not also provide an interactive step by step guide on how your module works as well?

The idea of Tour isn’t a new one; it has been maturing over the past two years. It all began after the release of Drupal 7 when we decided to move the help passage from the front page to the help page. This meant that users new to Drupal would not see this text, and would have to struggle through with no guidance.

In light of that issue, the below was suggested;

How about creating a “Welcome” message that pops up in an overlay with that same information that continues to appear until either the user checks a box on the overlay saying to dismiss it or the user creates a piece of content on the site?
- Vegantriathlete, August 10, 2011

With tour.module committed to Drupal 8 core, we now have context-sensitive guided tours for Drupal’s complex interfaces, and developers have a new way to communicate with the user. It doesn’t stop at core either: contrib modules can ship with tours to describe how users can take full advantage of their modules. Distributions can also ship with tours on how to get started. Imagine a tour in the Commerce distribution that took the user through setting up products: That would be amazing! It would enable users to discover the pages they are looking for and take the guesswork out of finding pages.

Nothing keeps Drupal tourists from spreading the word! We are passionate for Drupal and IT, so enjoy meeting like-minded people very much! Despite the cold winter weather, Ternopil welcomed us with warmth and friendliness. How was it? Our blog post will tell.

We were getting ourselves ready for the ride for almost a month. Our brandy Drupal van wanted to make nice impression too, that’s why the journey hit off from the car wash :)