Divi PHP Code - WordPress Plugin

Guide to Configuring and Safely Using Divi PHP Code

Divi PHP Code is not meant to replace full-scale development. It is designed for targeted output of PHP-generated results inside a Divi layout. In this guide, we will look at how to use the plugin without unnecessary risk: where it fits into Divi sections, rows, and modules, what to check before installation, how to add your first PHP block, how to debug the output in Visual Builder, and where the line is between convenient page-level code and something that belongs in a child theme or a separate plugin.

The product's key feature is that it adds a dedicated PHP Code module to Divi Builder. Unlike the standard Divi Code Module, which is intended for HTML, CSS, JavaScript, and short inserts, this module executes PHP when the module itself is rendered. So this article is not about "paste in any code and forget about it." It is about a practical working approach: restrict access, write a safe snippet, verify the output, style the result with Divi tools, and quickly understand where to look when something goes wrong.

One important point up front: PHP inside a page layout is a powerful tool. It can output dynamic data, a table, a form, the result of a WordPress query, or data from an external API, but it can also break the page, slow down loading, or expose information that should stay hidden if the code is written carelessly. That is why the guide puts so much emphasis on validation, rollback, output escaping, permission limits, and troubleshooting.

When a PHP Module in Divi Is Actually Useful

Divi builds a page from sections, rows, columns, and modules. In most cases, that is enough: text, images, buttons, forms, galleries, and other blocks can all be assembled visually. The issue appears when a specific place in the layout needs not static text, but the result of PHP logic: a post count, data from custom fields, a small HTML block from a WordPress query, a simple table built from an array, a conditional message for a logged-in user, or a diagnostic output block for an internal page.

The standard Divi Code Module does not solve that directly because it does not execute PHP. It is useful for HTML, CSS, JavaScript, and shortcodes, but PHP inside that kind of block does not become server-side logic. Divi PHP Code fills that exact gap: it gives you a module you can place exactly where you need it in the layout and get a server-side result where the visual editor normally expects a standard module.

Typical Use Cases Where the Product Fits

The plugin works best in situations where the result needs to appear in one specific spot on the page. For example, on an agency page you might display the number of published case studies, on an author page the number of posts, in an internal team area an integration status check, or on a landing page a small table built from WordPress data. That kind of code does not have to live in functions.php if it is only needed as a visible block inside one specific section.

• Dynamic text inside a Divi design. The module works well when you need to display a short PHP-generated result next to regular Divi blocks and style it with the same design settings.
• Internal utility blocks. On restricted pages, you can display status checks, counters, simple query results, and editor notes.
• Small tables and lists. If the data is already available in WordPress, PHP can assemble the HTML markup while Divi handles the outer container styling.
• Rapid prototyping. A developer can test an idea inside the layout before moving the solution into a dedicated plugin or child theme.

That said, the product should not be treated as a universal way to store all business logic for the site inside pages. If the code needs to run on many pages, hook into early WordPress actions, register post types, change routes, add global filters, or manage permissions, it belongs in a separate plugin, a child theme, or a snippet manager.

Where the Boundary Is Between a Child Theme and Code Snippets

The distinction is straightforward: Divi PHP Code answers the question "how do I output a PHP result at a specific point in a Divi layout?" Code Snippets and a child theme answer the question "how do I add logic that should work independently of any single page module?" If you need to register a shortcode, add a filter to the_content, change WooCommerce behavior, load a script site-wide, or execute code in the admin area, a Divi module is simply too late in the execution flow.

The main checkpoint before using it: if the result needs to appear as a visible block on the page, Divi PHP Code is a good fit. If the code needs to change how WordPress behaves before the page is generated, use a separate plugin, a child theme, or Code Snippets.

What to Check Before Installing It on a WordPress Site

This plugin works with PHP, so preparation matters more here than it does with a normal visual module. You should not install it directly on a live page and start experimenting with arbitrary code. A sensible workflow is: create a backup, use a staging copy of the site or at least a draft page, review user permissions, decide who will be able to edit Divi layouts, and have a rollback plan ready in advance.

Technical Compatibility and a Safe Working Environment

The developer page states compatibility with Divi 4 and Divi 5 and specifically highlights support for Visual Builder. Even so, you still need to test it on your own site, because the real outcome depends on the theme, active plugins, caching, editor permissions, and the PHP code itself. WordPress documentation on plugin management also recommends checking compatibility and having a backup before updates. For a product that executes code, that advice becomes a mandatory working habit.

Who Should Not Be Given Access to the Module

Even if a user knows how to work with Divi, that does not mean they should be allowed to execute PHP. A content manager can safely edit text, images, and block structure, but PHP runs on the server and has access to WordPress functions, the database through standard APIs, the current user, requests, and the site environment. For that reason, access to the module should be part of your technical policy, not just another editor-level privilege.

The Divi PHP Code developer states that the product integrates with Divi Role Editor and includes code integrity checks. That is an important safety concept: code should run only when it has been added through the visual interface and passes validation. But that protection does not remove responsibility for the snippet itself. If the code outputs unescaped data or accepts user input without validation, the risk is still in your code.

How to Prepare a Draft Page

Create a separate page that is not linked in navigation, add a simple Divi section, and use it as a safe test lab. On that page, you can verify whether the PHP Code module appears in the library, whether basic output runs, whether the design settings work, and whether the visual editor conflicts with caching. After that, move the verified module into your real layout through the Divi Library or by copying the block.

Do not start with code that calls external APIs, processes forms, or runs complex queries. Your first test should be short and reversible: output one line, then a WordPress variable, then a simple data array.

Installation and the First Module Check

The plugin is installed the standard way for WordPress plugins: by uploading the ZIP archive in the Plugins section or using whatever standard method your site relies on. There is no need to modify theme files or manually wire PHP into templates. After activation, the user's job is to confirm that Divi Builder can see the new module, that its settings open correctly, and that the simplest possible code can run inside Visual Builder.

What to Check After Activation

1. Open a draft page in Divi Visual Builder.
2. Add a section, row, and column if the page is empty.
3. Open the module library and find the PHP Code module.
4. Add the module to the required column and open its settings.
5. Paste in a minimal test output and save the module.
6. Run the preview in Visual Builder if your version of the module includes a run button next to the PHP Code field.
7. Open the page as a regular visitor and compare the result.

You do not need complex PHP for the first test. A safe string output is enough. If it appears in both the visual editor and the normal page view, then the basic chain of "module - PHP execution - rendered output" is working. If the string is visible only in the editor or only on the public page, check the cache, the draft state, and whether the layout was saved correctly.

<?php
echo esc_html( 'Divi PHP module is working' );
?>

This example uses esc_html() right away. For such a simple string, that may look excessive, but it is a good habit: any data that ends up in HTML should be prepared for output. WordPress documentation clearly separates input validation, data sanitization, and output escaping. In a module that executes PHP directly inside the layout, it is better to build that habit from the very first test.

Why You Should Compare Visual Builder and Normal Page View

The official product page mentions previewing and debugging in Visual Builder. That is convenient, but it does not replace checking the page in its normal state. The visual editor runs in a special mode, while the public front end may pass through caching, optimization tools, Divi display conditions, security plugins, and role-based restrictions. So after every meaningful change, check the result in two places: inside the editor and in a normal browser window, ideally while logged out.

Post-Install Setup: Access, Debugging, Design, and Cache

The main configuration for Divi PHP Code does not happen on a separate settings page. It happens in the operating workflow around the module itself: who can use it, how debugging is enabled, how the output is styled, when cache should be cleared, and how to avoid turning a Divi layout into a storage room for unreviewed snippets. This is exactly the section you should work through before the first real deployment.

Restrict Access Through Divi Roles

If multiple people edit the site, start with permissions. Divi Role Editor lets you control which Divi capabilities are available to different roles. The Divi PHP Code developer states that the module respects Divi Role Editor permissions, and by default this kind of code execution should remain an administrator task. In practical terms, that means you should not grant access to the PHP module to any role you would not trust to edit functions.php or install plugins.

Recommended Access Model

• Administrator or developer creates and verifies the PHP module.
• Editor may change the text near the module but should not edit the PHP code itself.
• Author and content manager should not receive PHP execution access, even if they know how to work with Divi.
• Client access is best limited to visual editing of safe modules.

After changing roles, open a test account with the relevant role and check whether the user can see the module, open its settings, and access the PHP Code field. Do not rely on theoretical permissions alone: the Divi interface and third-party modules sometimes need to be verified manually.

Use Debugging Only Where It Should Be Seen

The product page mentions a built-in Debug setting and control over error display. That is useful when you are tracking down a syntax error or checking a result. But debugging messages should not be visible to visitors on a live page, because they may expose file paths, function names, data structures, and other technical details. So enable error display only on a draft page or in a staging environment, and keep a clean fallback output on the public page.

A Safe Debugging Sequence

1. Test the code on a draft page first.
2. Enable Debug only while diagnosing the issue.
3. Fix the problem and confirm that the public output is now correct.
4. Turn off error display before publishing.
5. If the error persists, check the WordPress log or the server log instead of exposing details to the visitor.

WordPress debugging documentation stresses the difference between logging errors and displaying them publicly. That matters even more with Divi PHP Code: the error lives inside a module that visually looks like part of the page. A visitor should not see a stack trace where they expected a table, a status line, or a form.

Style the Result with Divi, Not with Extra CSS Inside PHP

The official product page notes that output can be styled through Divi design settings. That is one of the strongest parts of this approach: PHP handles the data and markup, while Divi handles the visual container, spacing, borders, background, shadow, responsiveness, and module visibility conditions. There is no reason to paste a large chunk of inline styles into PHP if the appearance can be controlled through the Design and Advanced tabs.

Keep the PHP as clean as possible: generate HTML with classes, then apply styling in Divi or in safe CSS if you truly need it. That makes the module easier to move, review, and edit. If the design changes, you do not touch the server-side logic. If the logic changes, you do not break the layout.

Check Cache After Every Change

The module's PHP code runs when the page output is generated, but visitors may still be seeing a cached version. If the result depends on time, the current user, database content, an external API, or a post status, cache can easily produce false conclusions. During testing, temporarily disable aggressive caching for that page or clear cache after saving the module. For personalized output, consider whether the task would be better handled through a shortcode, a separate plugin, or a dynamic block with controlled caching.

How to Write PHP for the Module Without Unnecessary Risk

Divi PHP Code gives you a place to execute PHP, but it does not make every snippet automatically good. Safety and reliability depend on what you actually put into it. Inside the module, it is best to write small, clear, tightly scoped tasks. If the snippet starts growing, creates functions, registers hooks, processes forms, loads external libraries, or gets reused across multiple pages, that is a sign the code should move into a proper development layer.

The "Input - Logic - Output - Verification" Chain

Before you paste in a snippet, walk through a short chain. What is the input? Where does it come from? How does the code validate it? What does it output? How will a user know the result is correct? What happens if the data is missing? That kind of discipline helps prevent a common mistake: code works in one happy-path example but fails when the array is empty, the field is missing, or the current user is different.

Minimal Structure of a Safe Snippet

• Limit the task. One module should do one clear thing: output a counter, list, table, status, or data block.
• Check whether the data exists. If the post, custom field, or query result is missing, display neutral fallback text.
• Escape the output. Use esc_html() for text, esc_url() for links, and esc_attr() for attributes.
• Do not trust user input. If data comes from a form, the URL, or an external source, it must be validated, sanitized, and protected against repeated submission.
• Do not run heavy queries on every page load. For expensive operations, cache the result or move the task into a separate architecture.

This logic follows general WordPress rules: validate input, sanitize data, escape output, and check permissions when an action depends on the user. The module itself does not replace those rules. It simply gives you a place where the PHP result can be rendered inside a Divi layout.

Example of Safely Outputting a Post Count

Below is a small example you can use as a learning template. It outputs the number of published posts and does not accept any user input. A snippet like this makes sense in a "site stats" demo block or on an internal team page. Before adding it to a live site, make sure the user actually needs that counter and that it is not there just for decoration.

<?php
$counts = wp_count_posts( 'post' );
$published = isset( $counts->publish ) ? (int) $counts->publish : 0;

echo '<div class="dfx-php-stat">';
echo '<span class="dfx-php-stat__number">' . esc_html( number_format_i18n( $published ) ) . '</span>';
echo '<span class="dfx-php-stat__label">' . esc_html__( 'Published posts', 'default' ) . '</span>';
echo '</div>';
?>

After inserting it, check three things: the number matches the Posts section in the admin panel, the block shows no technical warnings, and the HTML does not break neighboring Divi modules. If you need to change the label text, do not modify someone else's theme or plugin. It is simpler to replace the text inside your own snippet or present the label through a regular Divi text module next to the PHP module.

A Small CSS Enhancement for Cleaner Output

If the Divi settings are enough, you do not need separate CSS. But sometimes it is more convenient to assign the module its own class in the Advanced tab and add a short style adjustment in the child theme or another safe location for custom CSS. This does not modify WordPress core, the Divi theme, or the plugin itself. The change is reversible: remove the class or the CSS, and the block goes back to its normal appearance.

.dfx-php-stat {
  display: inline-flex;
  align-items: baseline;
  gap: 0.5rem;
  padding: 0.85rem 1rem;
  border: 1px solid rgba(91, 73, 255, 0.22);
  border-radius: 8px;
  background: rgba(91, 73, 255, 0.06);
}

.dfx-php-stat__number {
  font-size: 1.8rem;
  font-weight: 700;
}

.dfx-php-stat__label {
  font-size: 0.95rem;
}

The check is simple: refresh the page while logged out, make sure the block does not stretch the column, overlap nearby modules, or look broken on mobile width. If the result is not right, remove the CSS and the class from the module. Do not add complex JavaScript for a visual effect if the task can be handled through Divi settings.

Execution Details: What Happens During render()

One of the most important facts from the developer page is that the code runs inside the module's render() function. In practical terms, that means WordPress, Divi, and active plugins have already been loaded, so the snippet can use their functions and classes if they are available. But many early WordPress events have already passed. Code inside the module is not suitable for tasks that must run before page generation begins.

What You Can Do at the Module Output Stage

At this stage, it is convenient to gather data and output HTML. For example, you can get the current user, check whether posts exist, build a section link, output a custom field value, display a clean notification, build a small table, or return the result of a simple API request with caching. All of that is closely tied to the display location and can be verified visually.

What Is Already Too Late

If you need to add add_action() or add_filter() to an event that fires before the module is rendered, that code will not behave as expected. The same goes for registering post types, taxonomies, routes, global scripts, or logic that must affect response headers or early queries. In those cases, Divi PHP Code may still be useful for displaying the result, but the logic itself needs to live elsewhere.

This boundary helps prevent overusing the product. A good Divi PHP Code module behaves like a tidy output widget, not a hidden mini-plugin containing half the site's logic.

Practical Example: A Dynamic Stats Block Inside a Divi Section

Let us walk through a scenario that shows the product's value without risky actions. Imagine the site has an "About" page built with Divi. In one block, you need to show the live number of published posts so the editor does not have to update it manually. That is a good fit for Divi PHP Code: the data already exists in WordPress, the result is only needed in one specific section, and the code does not change the site's global behavior.

Goal

Create a small visual block with a large published-post count and a label. The block should sit next to normal Divi modules, follow the page design, and never expose technical errors to the visitor.

Preparation

• Open a test page in Divi Visual Builder.
• Make sure Divi PHP Code is active and the module is available in the library.
• Create a section with one or two columns.
• Prepare a short text module next to it to explain what the number represents.
• Clear the page cache after saving if optimization is enabled on the site.

Steps

1. Add the PHP Code module to the required column.
2. Paste in the wp_count_posts() snippet from the previous section.
3. Run the code in Visual Builder using the available preview button, or save the module and refresh the view.
4. In the Design tab, adjust the spacing, background, border, or shadow of the container.
5. In the Advanced tab, add a CSS class if you are using a separate visual style adjustment.
6. Save the page and open it in normal viewing mode.

Checking the Result

Compare the number with the Posts section in the admin panel. If it matches, update one test post or create a draft and confirm that only the correct data changes. Drafts should not count toward published posts. If the number does not refresh, clear the page cache first, then review the PHP snippet itself.

A Detail That Often Causes Confusion

The visual editor may show the current result while the public page still shows the old one. That is not necessarily a Divi PHP Code bug. More often, the cause is page caching, an optimizer, or the CDN. So for dynamic blocks, decide up front whether the result can be cached or whether it must stay personal and always current. If you need personalized output for each user, a simple PHP module inside a cached page may be the wrong architecture.

Ways to Use It Without Turning the Page Into a Code Warehouse

It is easy to overestimate this product: once you can execute PHP anywhere in the layout, the temptation is to move lots of small tasks into it. A better approach is the opposite - use it only for cases where the visual connection to a Divi section actually matters. Here are a few ideas that respect that boundary.

Dynamic Metrics and Status Blocks

For internal pages, landing pages, and team pages, you can display values from WordPress: number of posts, comment count, the last updated date of a selected item, a data-availability status, or a link to the latest post of a specific type. This should not become critical business logic. If the block disappears because of an error, the page should still make sense.

Output from Custom Fields

If the site already uses custom fields, the PHP module can assemble a clean output where standard Divi modules are not flexible enough. For example, an event card might display a date, a location, and a short conditional note. But if you have many such cards, it is better to create a template, shortcode, or separate module, otherwise maintaining the same PHP across multiple pages will become awkward.

Simple Tables and Internal Reports

For restricted pages, you can build a table from a small data set. The main thing is not to run heavy queries on every view and not to output personal data without checking permissions. A table inside a PHP module should function more like a reference widget than a full reporting system.

Forms and Input Handling

The official product page lists custom forms as a possible use case. This area requires extra caution. A form is not just HTML fields. It also involves permission checks, nonces, validation, sanitization, submission handling, duplicate-submission protection, error messages, and data storage. For a simple internal prototype, the module may help, but public forms are better built with a dedicated plugin or a separate development solution.

If the snippet starts accepting visitor input, treat it like a mini-application: validate the nonce, check permissions, validate input values, escape the output, and design error handling in advance.

Verifying the Result After Publishing

Publishing a PHP module does not end when you click Save. You still need to confirm that visitors see what you intended, that the code does not reveal anything sensitive, that the page has not become noticeably slower, and that editors cannot accidentally break the block. The easiest way is to review a short checklist so obvious problems do not get missed.

Checking the Public Page

• Open the page while logged out. That lets you see the result the way a normal visitor sees it, not as an administrator.
• Inspect the HTML output. There should be no PHP warnings, file paths, array dumps, or internal diagnostic messages.
• Check responsiveness. The result should fit inside the Divi column on mobile width.
• Clear the cache and test again. This helps distinguish a code issue from an old cached page.
• Open the page with another role. If the result depends on the user, test at least as an administrator and as a normal visitor.

Performance Check

The mere fact that the module outputs PHP does not automatically slow the page down. What slows it down is the logic inside it: external HTTP requests, large database queries, missing caching, repeated calculations, or heavy loops. If the module does anything more expensive than outputting a ready value, consider storing the result in a transient, using a background refresh process, or moving the computation out of the page and into a plugin.

Rollback Check

Before final publication, make sure you know how to disable a problematic block quickly. The simplest option is to open the page in Divi, disable the module, or replace the PHP with safe fallback text. For more serious deployments, keep a copy of the working layout version in the Divi Library or in your backup system. If the page becomes unavailable because of an error, recovery should be a procedure, not improvisation.

How to Organize Work with PHP Modules on a Real Site

The most common problem with solutions like this usually appears later, not on installation day. After a few weeks, the site may already contain several pages with PHP modules: one counts posts, another pulls data from custom fields, a third shows an integration status, and a fourth was copied and slightly modified by someone else. As long as everything works, that feels convenient. Once an error appears, it suddenly becomes unclear where the current snippet lives, which version is safe, and who is actually allowed to change it.

That is why Divi PHP Code benefits from a little internal discipline. It does not require a separate development system, but it helps you keep control. Every PHP module should have a clear name, a specific purpose, an owner, and a simple way to verify the result. If the site is maintained by a team, put that in your operating instructions: who creates these modules, who reviews the code, who publishes the page, and who handles rollback.

Use Clear Administrative Labels

In Divi, modules can have an administrative label. For a normal text block, that is optional, but for a PHP module it saves a great deal of time. Instead of a vague name, use a purpose-based format such as PHP - About page post counter, PHP - internal page API status, or PHP - event table. That label is visible in the layout structure and helps distinguish an important snippet from an ordinary decorative module.

You should not hide all the meaning in comments inside the code. A page editor can see the layout structure before opening the PHP Code field. If the name clearly says the module outputs statistics, the person will check the right part of the page first instead of hunting for a random issue in a neighboring module.

Keep a Copy of Any Verified Snippet Outside the Page

A Divi layout is convenient for visual assembly, but it is not the best code archive. For every important snippet, it helps to keep a copy in the project's technical documentation, notes system, or repository if the team uses one. That does not mean the workflow has to become complicated. It is enough to record the page name, the module purpose, the current snippet, and the date of internal verification without placing that date in the article or on the page itself.

That copy becomes valuable when migrating the site, restoring from backup, or investigating an incident. If the module is changed accidentally in the visual editor, you still have a working version. If the logic needs to move into a child theme, you can see the original task and rewrite it cleanly.

Separate Prototypes from Permanent Solutions

Divi PHP Code is excellent for testing an idea: add a module quickly, output the result, show it to the site owner, and decide whether the block is actually useful. But a prototype should not automatically become the permanent solution. After a successful test, ask three questions: will this code be used elsewhere, does an important user flow depend on it, and does it need to be tested as part of development? If even one answer is yes, think about moving the logic into a separate layer.

For example, a post counter on one page can stay inside the module. A table used across several sections and built by complex rules is better moved into a shortcode or a mini-plugin. A form that submits leads, stores data, or affects revenue is almost always better handled by a specialized tool. That separation does not reduce the value of Divi PHP Code. It preserves the product for the use case where it is most effective - as a visual output point.

A Review Plan for Future Changes

Once a snippet is already published, any change should go through a small review cycle. First, update the code on a draft copy of the page or inside a temporarily disabled module. Then check Visual Builder, the public page, mobile width, cache, and behavior for the required user role. After that, document what exactly changed. If the site matters, do not edit several PHP modules at once: if something breaks, it will be much harder to tell which snippet caused it.

A practical rule: one published PHP module - one specific job, one responsible owner, and one clear way to verify the result.

Security: What the Module Protects and What Remains Your Responsibility

The Divi PHP Code developer describes several protective mechanisms: execution of code added through the visual interface, cryptographic integrity checks, and support for Divi Role Editor permissions. Those are important barriers against accidental or unauthorized changes to a snippet. But they do not make unsafe PHP safe. The code inside the module still runs with the capabilities of a WordPress site, so its contents must be reviewed just as carefully as code in a separate plugin.

What You Should Not Do Inside the Module

• Do not delete posts, users, files, or database tables from code that lives inside a page layout.
• Do not accept values from $_GET or $_POST without validation, a nonce, permission checks, and sanitization.
• Do not output personal data to visitors without strictly checking the current user.
• Do not store secrets, API tokens, or passwords directly in the module field.
• Do not include external files from an address that a visitor can influence.
• Do not use the module as a replacement for a full form system if the form is public and important.

How to Write More Safely

Use the least privilege and the smallest amount of data necessary. If the code outputs information to the current user, verify the role or specific capability through the WordPress API. If you output a link, use esc_url(). If you output text, use esc_html(). If you build an attribute, use esc_attr(). If there is a form, add a nonce and validate it during processing. WordPress documentation also makes it clear that a nonce does not replace permission checks: it helps protect against certain kinds of abuse, but access still has to be controlled through user capabilities.

For external HTTP requests, use standard WordPress functions such as wp_remote_get(), and always handle errors. Do not make an external request on every page load if the data can be cached. If the API is unavailable, the module should show a clear fallback message rather than a technical error.

How to Document Snippets

A visual module is easy to forget: months later, another administrator may see a polished block on the page but have no idea where the result is coming from. Add a clear Admin Label in the Divi settings and a short comment in the code. Do not write a full manual inside the PHP, but leave the essentials: what the snippet outputs, where the data comes from, and where to look if something goes wrong.

When Divi PHP Code Is the Right Choice

Divi PHP Code is worth using when you need a visible PHP-generated result inside a specific Divi section and you are prepared to treat it as code, not as a decorative block. The product works well for dynamic metrics, small internal utility blocks, output from the WordPress API, prototypes, and clean page-level solutions that do not require early hooks or global architecture.

Before deployment, review roles, backups, debugging, cache, and your rollback plan. Start with a small snippet, escape the output, do not store secrets in the module, and do not grant PHP access to people who are not responsible for the technical side of the site. If the task grows from one visible block into a system, move the logic into a separate plugin, Code Snippets, or a child theme.

If the use case still matches your site's needs after those checks, you can download Divi PHP Code, install it on a test page, and follow the first safe run step by step using this guide. That approach gives you the product's main advantage - PHP output exactly where you need it in a Divi layout without chaotic template editing.