9 October 2019
If you’re using Magento 2 Open Source, you’ll be relying on developers to setup a way for you to edit your content. You can often be at the mercy of time and budget constraints, which can hamper the robustness of the development work. This is particularly important for sites that need to explain how their products work, promote their brand offerings, or simply add content to their site that is not product data related
The simple approach is to use the CMS Blocks to simply paste HTML directly into the admin. This saves on development time, but it makes editing the content in the future much more hazardous, particularly if the user doesn’t understand HTML or the Magento 2 editor strips some HTML classes or tags.
In a perfect world the client would receive a page builder in the admin to control the layout of their content blocks and landing pages, which is the case with Magento Commerce. However not all budgets can accommodate this.
The next best step is to use custom Magento widgets to populate the blocks of content. These do take development time however and depending on how many bespoke content sections your costs can climb quick quickly.
Since we believe that, for stability and ease of use, HTML content should generally not be entered directly in the admin, our approach is to create widgets for all blocks of editable content.
To reduce costs we’ve developed an extension to the core Magento widgets.
The widgets include the following possible fields (The bold items were added in our module):
These fields are simply additional areas which give us more flexibility when creating useful widgets.
The main time saver for development time is in the custom repeating of fields. Often content on the frontend might be repeating. For example there might be four columns, each with an image, title, copy and link. This becomes an issue when developing widgets as the XML that generates all of these fields in the admin has to be coded by a developer. For every repeated item in the widget, a developer has to add the XML to generate it.
To improve this we extended the widget module in order to add some basic repeating functionality. This now means that we can, for example, build a widget for a slider which has fields for an image, title, copy and link. Then set the number of times the fields should be repeated, which in essence is the number of slides the slider widget can hold. If for any reason this needs to be increased in the future we just need to change one number and the fields simply repeat further.
We also extended the naming convention of the widget XML fields. When you call fields in the view templates with a normal widget you would usually just call the field name directly in order to render the value.
For example, if the field name was items_title, then we would use the following to fetch the cd value:
We’ve added two alternative ways to name and retrieve the data from widgets.
Firstly, you can define arrays using dots in the field name and if required, the key character N. In this example the field name becomes items.N.title. N is replaced by the number of the loop when the fields are being repeated.
To retrieve the array that’s been created we can now use the following:
getItems()): ?> $item): ?>
Secondly, you can create objects using colons in the field names. This can be combined with the above array functionality. If we change the field name to items.N:title we can now use the following to render the values:
getItems()): ?> $item): ?> getTitle() ?>
This helps to reduce the clutter in the widget view templates, further increasing the speed at which the template is initially coded or updated by a developer.
While the custom built widgets are not as fancy as a full page builder, they are a cost effective way to construct very bespoke layouts of editable content.
Most importantly in our opinion is the widgets greatly reduce the risk of the layouts being broken by a client while they update or create new content.