Before making a Divi module global, ask three questions

A small request exposes the problem. One page needs a different price, and the price sits in a global row that twelve product pages share. Change the row and all twelve change. Change only one page and the twelve no longer agree. Both outcomes are the feature working as designed.

This is analysis, not a review. Nobody at WPSifero has installed or built a site in Divi, and nothing below comes from opening the builder. Every statement about the product is taken from Elegant Themes' own published pages and cited where it appears. The maintenance argument follows from what the feature is for, and it can be checked against a site's own content without installing anything.

The tension is about ownership, not design. A global item states that a fact is the same wherever it appears. That is true for a footer's opening hours and false for a price negotiated per customer. The feature cannot tell the difference. The person who makes the item global has to.

A global item is defined by sameness, and sameness is a claim about the future

Elegant Themes' documentation describes a global library item as a Module, Row or Section that appears the same on whatever pages it is added to. The same documentation states that editing the item changes every page that uses it. The second sentence is the mechanism, not a side effect.

A global item is a single source, and every page that adds it depends on that source. One edit reaches twelve pages because there is only one thing to edit. The twelfth page cannot quietly disagree because it does not have its own copy. Benefit and cost are the same property, viewed from different months.

The right use is a fact that belongs to the organisation rather than the page. Opening hours in a footer are the clean example. A studio has one set of hours, the footer appears everywhere, and if the hours change every footer should change. Content and scope are the same thing, so a global item fits.

The wrong use is a fact that belongs to the page but happens to look the same today. A price is the obvious case. Two products can share a price this month and diverge next month, or a legacy bundle can keep an old price after the catalogue moves. A global price row is a bet that they will never diverge, placed when the row is created by someone thinking about the current catalogue.

The definition also explains why this is hard to see in advance. A global item looks like a template, and templates are usually about layout. This one is about content. The pages can look different around it while the item inside is identical. That is a different promise from "these pages share a design", and it creates the debt.

Three questions decide whether a component should be global

Three questions are worth asking before a component becomes global. The third is the one that gets skipped.

Will every instance need the same change, forever? The word that matters is every, and the word that gets ignored is forever. List the pages that will use the item, then imagine a change. If any page would need a different value, the item is not global material. If every page needs the same value today but one page is likely to need a different one after a campaign or a product change, it is still not global material. The definition has no concept of "not yet". Repetition is a reason to consider a global item; sameness is the reason to use one.

Who else can edit it? A global item is a shared surface. If the people who edit pages can also edit the item, every editor has a key to every page. Ask the vendor whether the capability to edit a global library item can be separated from the capability to edit a page. If it cannot, treat the item as an administrator's surface. If it can, ask who holds the capability and whether that list is short enough for anyone to be accountable.

What happens when one page must differ? There are few honest answers. The page gets a separate, non-global copy. The page stops using the item. Or someone edits the global item and accepts that every other page changes too, which lets the exception win. The answer should be known before the item is created, because someone else pays the cost later. If the only workable answer is a copy, the item has a known exit cost. Record it.

The table records the answers the next editor needs. It is not a decision method.

When the answer is no, copy the component and budget for drift

When any of the three questions gets a no, the safe move is a local copy. A copy does not propagate, it does not create a shared surface, and it cannot break twelve pages in one edit. It is also not free. The two copies will drift, and the drift is not carelessness. It is the predictable result of two independent objects meant to stay in step.

The mistake is to treat the copy as temporary. A copy made for one page tends to stay for years. The next person who changes the price changes the row or the copy they know about, and the other becomes wrong. Drift will happen. The question is who notices, and when.

Make the copy visible in the handover. Record which page holds the canonical version, when the copy was made, and who owns the next change. A text file in the repository or handover folder is better than a fact that lives in one person's memory.

reuse-inventory.txt
footer-hours        global   owner: office manager   reviewed: 2026-10-19
price-row           copy     canonical: /pricing/    copies: 12
jurisdiction-note   copy     canonical: /legal/      copies: 4
registered-address  global   owner: operations       reviewed: 2026-10-19

An inventory also makes the migration cost visible. Elegant Themes' documentation on the Divi 5 Migrator says that supported modules are converted, while modules not yet supported continue to run wrapped in the Divi 4 framework. It states that a page containing one of those modules loads the Divi 4 framework for that page, which Elegant Themes says can affect performance. The caveat is theirs, and it concerns modules rather than global items. A copy is one more component to check; a global item is one component many pages depend on.

A global module is a shared surface with a permissions problem

The governance problem is separate from the content problem. In a client site, a global module is a shared surface: anyone who can edit it can break one thing and watch it break on twelve pages. The person who edits a page is often not the person who owns the site's facts. A marketing assistant updates a phone number because a local event has a temporary line. If that number is global and the assistant can edit it, the change reaches every page. A page-level intention became a sitewide edit.

The failure is a mismatch between the scope of the edit and the scope of the permission, not malice or incompetence. Page editors think in pages. A global item is a statement about the whole site. Hand those two scopes to the same person without a warning and the global item will eventually be edited for the wrong scope.

That is why ownership comes before content in a handover. Name the role that owns each global item. Put the item in the handover document with the pages it affects. Require a second pair of eyes for changes to it, not because editors are untrustworthy but because the blast radius is larger than the screen they are looking at.

The licence is a separate decision from the reuse rule, but it lands in the same handover. Elegant Themes' pricing page, as published on 2026-10-19, lists Divi, the theme and builder, at $89 billed yearly for unlimited websites, and Divi Lifetime at $249 as a one-time payment; prices change, so the page is the source and this sentence is a snapshot. If the site will be handed to an editor, the renewal date, if any, and the owner of each global item belong in the same document.

Some parts of a site should never be global

The rule for what should never be global is easier to state than to apply: if a page can legitimately need a different value, the component is not global material. The word "legitimately" is doing the work. It excludes the page that is wrong today and should be corrected. It includes the page that is right for its own reason.

Five categories fail that test often enough to be named. Prices and availability, because a catalogue changes per product and per market. Dates and deadlines, because a campaign ends on different days in different places. Legal and jurisdictional text, because the wording depends on where the reader is. Product-specific specifications, because the same-looking block describes different things. Page-level calls to action, because the next step on a product page is not the next step on a careers page.

Two tests make the rule usable. The misleading test: if a reader saw this value on another page and it would be wrong there, it cannot be global. The exception test: if you can name a page that must differ now, or is likely to need to differ later, copy rather than globalise. A global item with a known exception is a copy waiting to be made.

The parts that can be global are the organisation's facts: opening hours, a registered address, a brand statement legal has approved and that is genuinely identical everywhere, a sitewide notice that must appear or disappear everywhere at once. These are not page content. They are the site's identity or a sitewide instruction, and sameness is the point.

The hard case is the component that is mostly the same. The remaining difference is the reason to copy. By definition, a global item has no place to put the difference, so the difference goes somewhere else: a second copy, a special page, a manual exception the next editor does not know about. The cheap-looking option creates a hidden system. The copy is more honest because the difference is visible.

The decision rule is narrower than the feature

Make a component global only when three conditions hold at once: every current instance needs the same value; every future instance can reasonably be expected to need the same value; and the people who can edit the item are accountable for every page it appears on. If one condition fails, copy.

Write the rule down where the next person will find it. The failure mode is a team that inherits globals without knowing which ones are load-bearing. A list of global items, their owners and the pages they affect is the difference between a shared fact and a shared surprise.

Treating a global item as the default for anything that repeats is the problem, not the feature. Reuse works for identical facts; similar-looking pages are a different case. When the facts stop being identical, the global item does not become wrong gradually. It becomes wrong everywhere at once. A copy is the cheaper mistake, and it leaves a visible trail.