There is a joke about the Drupal learning curve that relates it to the Drupal learning cliff. And while the graph generally gets things confused (by placing time on the x-axis instead of the y-axis), the sentiment is understood. Until a person is able to get her/his head around how Drupal does things, it's quite possible to spend a great deal of time to accomplish very little. Even worse, it's possible to spend a great deal of time developing really bad habits.
Drupal 8 was released just over two months ago. Is it time yet for you to start using it on your production sites?
You'll need to consider the state of the modules you typically use to build your sites, the state of the themes you typically use to build your sites, the nature of the site, the budget for the site and your own skill set.
There are, without a doubt, sites that are being launched on Drupal 8 already. And, at the same time there is this:
So, there is obviously still work to be done.
In the post on making output themeable I discussed the example of overriding a template file for a flag. The template file I overrode was a generic definition of the markup for all the flags on a site. I can create a template file that overrides a specific flag.
In Drupal an alter is intended to provide a way to modify an object during a point in the execution of a certain event or process. Alters are defined within individual modules. Those modules then give the opportunity for other modules to "alter" an object by calling drupal_alter at the appropriate time.
The whole point of creating a custom theme is to get a website to look the way you want it to. So, it's important for the output that modules generate to be themeable.
I will give a simple example of modifying the markup that is used to display some links. The Flag module provides a mechanism to do things such as "liking" a post or reporting a post as spam. A post may have a link for each flag that is associated with it.
In Drupal a hook is intended to provide a way for actions to be triggered during a point in the execution of a certain event or process. Hooks are defined within individual modules. Those modules then give the opportunity for other modules to "hook into" their processing by calling the hook at the appropriate time.
Collaboration is an important part of the Drupal community. The principle of collaboration applies equally to how people in the community engage with each other and to how modules are written.
I mentioned the Libraries API in a spearate post when I discussed creating a slideshow. The specific example was that you would use the Libraries API and you would also use the jQuery cycle plugin as part of creating a slideshow.
When creating a module for Drupal it is important to write the module so that it is extensible by other modules. I will talk about ways that it is possible to do this in other posts.
I mentioned a couple of examples of extensibility in the Modularity post. In my example of adding a slideshow to a Drupal site I said that you would likely use Views, Views Slideshow, custom content types and custom fields.
I mentioned in a previous post that Drupal is a modular framework. The idea is that modules should be designed to do one (small) thing well. This is in contrast to the monolithic approach that plugins employ in other content management systems.
For example, if you want to add a slideshow to a WordPress website you can download a single plugin from the WordPress official site. When I visited the WordPress site and searched on slideshow I got over 500 results!