We’ve written at length about the many benefits of Drupal 8, but the most exciting feature of Drupal 8 is the Drupal community itself. We sat down with ImageX’s Lead Developer, Bryan Sharpe, who recently contributed the Field Defaults module to the Drupal community, to discuss his module as well as the Drupal community as a whole.
The module allows setting default values on fields for existing content. By default, Drupal only allows adding default values to future content. This leaves existing content with no reference to the field, which can sometimes cause errors in code or display if they’re expecting that field to have a value.
I was working on a large web store that needed some new fields to be added to a product for customer display. There were about 15,000 products, the site was multilingual, and in many cases the new fields needed default values according to the language. Normally you can use Views’ bulk update for this, but the amount of fields and them being multilingual was creating a challenge. I decided to see if there was another way as this seemed to be a fairly basic functionality. There was nothing I could find to accomplish this, so I starting building the module myself.
To me, it made sense to have a default value be present if no value is entered; however, this is not the case for existing content, so rather than change Drupal Core or create a module that simply overrides other values, it made the most sense to add an option that allows the user to decide and to optionally decide according to the language as well.
Any drupal.org user can create a module. But if you’ve never created one before, the process requires you to create a sandbox first and have the module vetted by the community. This makes for a lot less duplication, abandoned, or unpolished modules potentially being released. There’s a lot of information documented on the process here.
Once you’re approved, your module usually progresses through a series of releases such as alpha, beta, or release candidate (RC) in which the community tests the module for bugs, compatibility, better features, etc. until the module is ready for a stable release.
First, check to see that what you are trying to accomplish has not already been done. Drupal 7 has an abundance of duplicated or very similar modules which can lead to a lack of support or compatibility with other parts of the system. It is far more beneficial for you and the community to contribute to existing modules to achieve your goals rather than trying to re-invent the wheel.
Second, I would say that collaboration with co-workers or the Drupal community to try and figure out your end goal, timelines, and the ability to support a module are all within your capabilities. If you release a module, you should either be willing to support it or have a co-maintainer who can share some of that responsibility.
I am the maintainer for some other modules. Some will see end of life at Drupal 7 as the functionality is either outdated or already built into core. And others, such as Facebook Album, have also been ported.
I have also been actively contributing to the Drupal 8 port of Drupal Commerce to help get out a stable release.
Drupal 7 has had such a long life that it has allowed the community to really determine the needs and wants of its users and to bring some of the most used and common modules, such as Views and CKEditor, into core. This, along with things like RESTful Webservices and responsive mobile-first design built right into the core, makes Drupal 8 extremely powerful out of the box where its predecessor was not quite as strong.
I find that the change of Drupal 8 to Symfony really forces the community to rethink their approach to module development and prevents a lot of duplication of module functionality, kind of a bit of a “reset” from Drupal 7. Although this can slow the development (which we’ve even seen in core), I think it will make for not only a better product, but a more stable one in the long-run
I’ve also found that this has also brought a lot of new members to the Drupal community, as well as bringing some developers out of the woodwork that seemed uninterested or complacent in maintaining or contributing to Drupal 7.
It’s no secret that we’re strong advocates of Drupal here at ImageX, but it’s not just because of its technical features. It’s also because of the hundreds of thousands of developers who contribute code and support to the community, ensuring that the open-source platform will continue to evolve to respond to the needs of your business.