Never mind the added inherit benefits of being able to do things like entity specific permissions. This major difference is the primary reason behind creating an entirely new module and not attempting to "port" an existing one. No more blanket custom "Background Image" node bundle entities. This module implements a truly dedicated entity. Core just handles the bulk of what you need if you just configure it right. No need to depend on a contrib module or figure out complex database schemas. Entitiesĭrupal 8 brought with it many great and wonderful things, the least of which is being able to create new entities (out-of-the-box) in a very easy to implement way. This inherently and dramatically forces the responsibility toward needing a dedicated module to handle all of the intricacies required for properly displaying a background image provided by a user. In Drupal 8, themes now have very limited "power" in what hooks and plugins they are actually allowed to participate in. Sure, in Drupal 7, some of the modules used fields, but often times you still had to customize the output (usually in a theme) given your specific needs. I think one of the biggest challenges with this entire topic has always been "Whose responsibility is it to handle the UI and then output of said background image?" In the past, there has never really been a clear delineation of whether this responsibility specifically fell to a module or to a theme. One that eases the setup process and also brings an easier to use interface for your users. It was still time consuming to implement in a consistent fashion across all the moving parts (which is why a custom implementation was often easier).Ī solution in Drupal 8 can now be implemented in an entirely different way. This required the same type of field or formatter settings to be applied to every single entity/bundle you needed this functionality on. In Drupal 7, many of the "solutions" were primarily focused on using custom field types or field formatters. Now, you may be thinking "Great another module that does the same as another module, but only slightly different." You would be kind of right, but it's actually quite a bit different than any previous implementation. ![]() While this did take some effort to do it just right (using custom image fields and then preprocessing via a sub-theme), it was relatively easy enough to accomplish if you knew what needed to be done. However, much of time, it was simply easier to implement an entirely custom solution. In Drupal 7, there were several modules that attempted to do just that. Over the past month, I have attempted to solve a lot of problems in regards to displaying a user provided image (via Drupal's UI) on a rendered page in the form of background-image: url(.) ) in Drupal 8. ![]() If you're just looking on how to setup this module, you can skip ahead to the Installation section. If your site is designed around utilizing background images, then this module is for you! Whether you need a surgical implementation that only administrators/developers can implement or provide the ability to allow users to attach their own background images to entities, this module has you covered. Introducing a new, easy to use, Drupal 8 module for background images:
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |