Last month we launched Materialise.com, one of our biggest Drupal 8 websites so far. With a team of three back-end developers and a front-ender, we worked on the project for six months. As this wasn’t the first Drupal 8 site we had built, we already had a pretty good idea which contrib modules would be helpful when implementing the required features.
However, we encountered a few surprises along the way: there are some modules that might look promising, but you probably want to avoid them if you want to keep your site running smoothly.
In this blog, I’ll be listing a few modules along with our personal experience and the reason why you should avoid them. Of course, this information might become out of date in a while as modules get updated and bugs are fixed. That’s why I am also listing the module versions we used.
As the website would be very rich in content, our client asked for the possibility to clone entities so content could easily be reused. Since the options were very limited at the time, we chose to try out entity_clone, a brand new Drupal 8 module which aims to be able to clone any entity. Pretty cool!
Unfortunately there hasn’t been any real development since April thus the module still had some gaps in functionality. For example, we noticed some strange behavior on the website when our client started working on the content. Entities, images and files were disappearing and changing on random pages. It turns out that the entity_clone module doesn’t really support referenced entities yet when cloning, it just makes the clone point to the same attached entities.
That means if you clone a node, and for example remove the teaser image to replace it, that image is also removed from the original node since both nodes point to the same file ID. The same thing happened with field collections and other referenced entities. There is an active issue on drupal.org which addresses this problem. As this was a blocking problem for us, we considered the module unusable, and the website started behaving normal again after uninstalling entity_clone. We did have to check all cloned entities to see whether they were still referencing entities from their original versions.
Field Collections are great if you want to re-use groups of fields across various entity types. Unfortunately we discovered that field collections don’t support translations yet, see this issue. So if you are developing a multilingual site, stay away from the field_collection module until the 8.x-3.x branch has a stable release. If you do want to use field_collection, take into account that those fields won’t be translated when viewing your node in another language.
There are some alternative modules with similar functionality, but we prefer creating custom entities. When using Drupal Console, it’s pretty easy to generate those. Also, there is a development branch for a 8.x-3.x release of the module which will include multilingual support.
ECK is great in Drupal 7. The module enables the administrator to create custom entities on the fly straight from the UI. For a short while we used ECK in our Drupal 8 projects to achieve the same goal, but then we noticed some bugs when translating entities through an inline entity form on a node.
When looking for an alternative, we quickly discovered that Drupal Console offers the ability to generate custom content/config entities and custom bundles. These entities behave just like those from ECK, but they are provided by Drupal core. That means one less dependency and a smaller chance to encounter bugs. After the console generated the necessary classes you can easily alter them as you please, something that is less easy to do with ECK
So our advice for Drupal 8 is to leave ECK for what it is. You're better off building your own entities in code, or using the generate command.
We used this module to restrict the editable menus per role. This worked fine in Drupal 7, but recently we encountered some blocking issues when implementing the Drupal 8 version.
There is one issue in specific which makes the module unusable: drupal.org/node/2796537 (several bugs are described there). The main problem is that menu items get deleted in some cases or are being saved to the database with an incorrect key, causing them to disappear in the UI. Until this is fixed, we suggest sticking to the core permission “Administer menus and menu items”.
Composer Manager was useful for a while to download PHP libraries which were required by contrib modules. However, this approach has been obsolete since Drupal 8.1. You can now use Composer to download a contrib module, and it will automatically download the dependent libraries as well. You can find more information about this on the module’s page.
As Drupal 8 grows more mature, more modules will get a stable release and these problems will become less frequent. The community is working hard on porting modules and fixing the necessary bugs. We at Intracto try to help out by taking an active part in the community. It is important to let others know when you encounter problems with a module, but it is even more important to share your solutions to problems others might encounter. That is something we try to do during every project.
More Drupal 8? Read about clean URL's disappearing in in Drupal 8.