Hi everyone from Howidivit! Today we are going to talk about a lot of things concerning Divi and the Divi module customization. In the last Series post we have seen how to create a brand new custom module with Divi 3.1.
Now we are going to deepen the React component of our new Divi module in the first part of this post; then we will show you, in a second part, how to add new custom settings to an existing Divi module, the Audio one in our case.
So, let’s jump right in!
A QUICK LOOK AT REACT
In the last post we have seen how to create a custom Divi module perfectly working in the Divi Builder and in the rendering when published; however we just scrape the surface about the live rendering of our module in the Visual Builder.
All the code we are interested in goes in the ‘render()’ function of our .jsx file. So the first thing we can do is to write some variables into which we will store our settings values thanks to the ‘this.props.[here-the-setting-name]’ method:
Now that we have our values stored in ‘constants’ (or ‘variables’) we can pass to the return() statement in which we will use a <Fragment></Fragment> syntax – that is a part of a React Component in which we can render more than one html element – with our Html structure inside wrapping all our constants in curly braces:
The code above is just an example rendering only the Title of our Audio, the Artist and the Album and finally the Cover Art Image. We will use, then, Css classes (using the ‘className’ attribute) for styling our elements.
HOW TO CUSTOMIZE DIVI MODULES
Let’s give a look now at another way we have in order to add features to our Divi; we can, in fact, customize existing Divi modules. This is not a common practice and – as we will see below – can raise some problems; however has the great advantage of inheriting all the settings of a module saving us a lot of time. Essentially we can do it simply using some Divi filters:
For now we will focus on the first one and the third one. The ‘et_pb_all_fields_unprocessed_$slug’ (where $slug is the slug of the module) allows us to filter the module settings, adding essentially all the options we need; then thanks to the ‘et_module_shortcode_output’ we can render the Html output on our published posts.
LET’S WRITE OUR NEW SETTINGS
So let’s dive into the code. We can do all that we need just with a couple of functions and filters in our main plugin file. We will write our first function in which we set our custom $fields and then, at the bottom of the function we will merge these ones with the existing module $fields:
So we added several fields like the Image Width (in Content->Image), the Margin of the Audio (in Content->Audio) and a lot of styles about the color of buttons, timer and sliders, the size, color and border-radius of the handle, all wrapped in a new ‘Audio’ toggle in the Design tab. Then we simply add the proper filter:
Next we will write another function in which a) first check for the slug of the module, b) we store our field values (thanks to the $module->props[‘field_value’]) and c) we will modify our Html output:
In our case we ensure that each field has been set and then filter the output adding a <style> with the needed Css inside. Obviously as final step we have to add the proper filter:
That’s all! Now we are able to get a result like this.
However, a couple of things to note. The first is that our custom fields will appear properly in the Visual Builder but these ones don’t render in VB; then another issue in our case has risen from the add <style>s to our module: this seems to cause a display error in the VB on refreshing the page without affecting anyway our Html output in published posts.
NEXT TUESDAY POST
Ok. We added a lot of fields to our custom Audio module just using a couple of filters in our main plugin file. In the next Series post we will see how to finish our plugin, adding custom design touch to our custom module and fixing some issues if possible.
Let us know in the comments if you have experienced something similar.