Note: There has been updates to the Divi theme that make some changes to the code. This tutorial was written about pre-Divi 3.0.45, but having said that, ET was careful to update in such a way that old code still maps nicely. That means that these tutorials are still germane (at least as of May 13, 2017), but we will see what future updates bring! I will be writing new tutorials to introduces the new features of Divi soon!
This is meant to be a quick intro to the structure of Divi Modules and mostly a discussion of the back-end builder (not the visual builder on the front-end). I intend for it to be the first in a series of articles discussing the programming behind the Divi theme. I need to start with the warning that all of this information is simply based on me deconstructing the fine work that the people at Elegant Themes (ET)(not an affiliate link) did in putting together the Divi theme. So, I could be completely and utterly wrong like eating gum and nuts at the same time.
The first step to modifying modules from ET to extend their functionality is simply understanding the module structure. All of the modules that are loaded into your builder screen for easy selection are located in Divi >> includes >> builder >> main-modules.php. Within this magic file, is a mix of php and HTML (actually technically still as php in sprintf(), but…) broken down into individual classes representing each different module with each class containing several repetitive functions.
So, if we open up the main-modules.php file as of early Divi 3.0, the first class we see is ‘ET_Builder_Module_Image’. Not surprisingly, this is the standard width Image module. The code for the fullwidth image module is located near the end of this file. All of the classes in this file begin with ‘ET_Builder_Module’, so you can usually find the module you are looking for by prepending this to the module name.
The structure of each of these classes is fairly simple. The first set of functions register the module and are focused on setting up what data is collected and written into your WP SQL database during the building of the page. The last function is typically focused on actually retrieving the data and building the page that the user sees.
Mostly, this is meant to be a big-picture overview of the modules, so I won’t break each function down completely, just introduce them. First up is the ‘init()’ function. This gives a name to this particular module and a way for the information about it to be retrieved. One note that we will come back to in the future when we start hacking these modules – your slug needs to have ‘et_pb_’ prepended for recognition by the page builder. Once the class is registered with Divi, the init function then registers all of the different fields it intends to collect from the user and store. These are listed in an array of ‘whitelisted_fields’. This can be expanded for your custom data. Next, if any of the fields have a default value, those values are entered into the array. Lastly, any advanced options are turned on, like fonts or background colors.
The next function that is typically called is ‘get_fields()’. This function defines how each of the white-listed fields is presented in the back-end. Basically, it sets up an array of stored values for each field that other functions within the Divi theme can interpret and present to the person building on the back-end. This includes at least a label, a type of field, and a description. In a future article, we will go through the types of fields and where they are defined. In addition to these base fields, there can be some conditional logic to only show the field if there a checkbox is ticked and an option to show the field only on one of the tabs besides the main tab.
The final function, called ‘shortcode_callback()’ handles the presentation in the browser. Basically, when the server retrieves a shortcode that has a call to this particular class (‘ET_Builder_Module_Image’) it uses this section to output the correct HTML. At the beginning of this function, all of the stored values from the database are assigned to variables. Following this, there is a series of conditional logic tests to determine if a value is set and if so, to modify the styling. Finally, there is a whole set of ‘sprintf()‘ functions used to construct the actual HTML of the page. Basically, a sprintf() function is a way to easily add variables into some HTML output. We will explore this a little more in a future article when we dive deeper into looking at the shortcode_ callback function.
So TL;DR, the first portion of each module is typically the back-end the last part is the browser view (I wanted to say front-end, but that has other meanings!). I hope this helps to start people down the road to further customization of their own Divi theme! As usual, make a comment or drop me an e-mail with any questions or if you notice an error you want to be rectified.