Your plugin works. Congratulations. Unfortunately, that was merely the entrance exam.
There is a wonderful moment in plugin development when you finally stop finding things that are broken.
The module loads. The settings work. The front end behaves itself. Nothing catches fire when you resize the browser. You zip the plugin, look at the finished product and think: Right. Time to submit this to the Divi Marketplace.
This is an adorable moment.
Because building a Divi plugin and preparing a Divi plugin for the official Marketplace turn out to be two quite different projects.
“It works” is only the beginning
We had already done the part most developers naturally think of as the job. We had designed the product, built the functionality, tested it, refined the interface and dealt with the usual collection of small problems that appear whenever software meets the real world.
Then we started looking seriously at what Elegant Themes actually expects from a Marketplace product.
The short version is that they are not simply checking whether your ZIP file installs without producing smoke.
Elegant Themes says Marketplace submissions are reviewed against its developer and design guidelines. Its current Creator FAQ describes a process that can include design review, QA testing and a line-by-line code audit. Suddenly the definition of “finished” becomes considerably more ambitious.
Your plugin can be perfectly useful and still not be Marketplace-ready.
That distinction matters. A plugin built for your own website can operate in a controlled environment. A commercial Divi extension is going to land on websites you have never seen, beside plugins you did not choose, running configurations you did not test while developing the original idea.
That is where the checklist starts earning its keep.
Security gets very specific, very quickly
Security is one of the clearest parts of the official developer guidelines. Elegant Themes expects untrusted input to be sanitised, output to be escaped appropriately, requests to use nonces where required, and privileged operations to check the current user's capabilities.
None of this is exotic WordPress development. Much of it is established WordPress practice. But there is a difference between generally knowing that and preparing a product while imagining somebody inspecting the code line by line.
You start asking different questions.
Did we sanitise this because it was obviously a form field, but overlook another value because it arrived through a REST request? Are we checking that the user can edit this particular post, rather than merely checking a broad capability? Is every value safe at the point where it is actually output?
That is not glamorous work. Nobody buys a plugin because the product page says, “You should see our nonce verification.” But it is exactly the sort of invisible engineering that separates software you can demonstrate from software you are prepared to distribute.
Your plugin has to live with everybody else's plugins
Then comes compatibility.
The Marketplace guidelines call for compatibility with current Divi and WordPress releases, appropriate backwards compatibility, supported PHP versions and testing alongside common plugins and themes. Elegant Themes also recommends testing across browsers and watching both PHP logs and the JavaScript console for errors.
In other words, “works on my machine” is not considered a particularly compelling certification programme.
This changes the way you test. You stop clicking through the happy path you already know works and start behaving like a customer who has absolutely no respect for the assumptions you made while building it.
What happens if they change this setting first? What if the module is placed in a narrow column? What if another plugin loads something unexpected? What happens on mobile? What happens after an update? What happens if somebody enters something you would personally never dream of entering?
Software has an extraordinary ability to discover users more imaginative than its developer.
Then the designer gets inspected too
Being a designer as well as a developer makes this part particularly interesting.
Elegant Themes does not want Marketplace extensions to feel as though an unrelated application has been bolted onto Divi. Its design guidelines emphasise interfaces that are responsive, intuitive and consistent with Divi's existing behaviour. Familiar controls should behave in familiar ways. Settings should have clear help text. Custom interfaces should add functionality without unnecessarily fighting the surrounding builder.
That creates an unusual design problem.
You want your product to have an identity, but inside the Divi Builder it also needs to be a good citizen. Your branding cannot wander into the interface wearing a sandwich board and shouting about itself.
For us, that is actually a useful constraint. Delicious products can still have their own personality in their dedicated administration screens, documentation and product presentation, while the parts that live inside Divi should feel comfortably at home there.
The best integration is often the one a user barely notices.
Even the marketing images have rules
At some point you may think, “Fine. The code is secure, the interface behaves, surely now I can just make a nice product graphic.”
Of course you can.
Here are the dimensions.
The current Marketplace design guidelines specify formats and dimensions for product artwork, including a 1426 × 796 pixel JPEG for the featured image and a 500 × 500 pixel JPEG for the square product image. Module extensions also have requirements for their SVG icon so they sit consistently beside native Divi modules.
This is the point at which submitting a plugin begins to feel faintly like preparing luggage for an airline with an unusually enthusiastic baggage-measuring department.
Again, though, the logic is sound. Marketplace pages need to remain visually coherent, and a tiny module icon has to work as an interface element rather than as a miniature advertising campaign.
And now, please account for everything in the suitcase
Licensing deserves its own special mention because it is easy to underestimate.
Elegant Themes requires Marketplace products to be GPL licensed, and its current licensing requirements call for a correctly formatted license.txt that identifies third-party material included with the product. That can include code, CSS, JavaScript, photographs, illustrations and other externally sourced assets.
So “I found this image online” is not a licensing strategy.
The Marketplace licensing page even identifies popular image sources whose licences are not accepted for Marketplace products. If your product includes third-party assets, provenance suddenly matters just as much as appearance.
This is one of those jobs that feels unnecessarily bureaucratic right up until you remember that you are proposing to sell somebody else's work inside your own product.
Then it feels rather less unnecessary.
The update system is not yours anymore
Another important difference is product updates.
Elegant Themes' developer guidelines say Marketplace products should not ship their own custom update system. Marketplace updates go through Divi's ecosystem, allowing new versions to be reviewed before reaching customers.
That means a plugin originally designed around your own licensing or update assumptions may need architectural adjustment before submission.
It is a good example of why Marketplace preparation should not be treated as the final ten-minute job after development. Distribution affects architecture. Support affects architecture. Updates affect architecture.
The shop counter is connected to the workshop whether you like it or not.
Passing review is not the finish line either
Suppose the product passes review and appears in the Marketplace.
Excellent. You are finished.
Except, naturally, you are not.
Marketplace sellers are responsible for maintaining their products as Divi and WordPress evolve. Elegant Themes also requires sellers to support customers through the Marketplace support system, with its current seller guidance requiring responses to support tickets within 48 hours and encouraging responses within 24.
That is an important reality for anyone looking at plugin development as passive income.
The ZIP file may be downloadable while you sleep. The customer who installed it at 11:47 pm and discovered an interaction with three other plugins has unfortunately not agreed to become passive.
What we learned from preparing a real product
The biggest lesson for us was not that the Marketplace has a long list of rules. You would expect a curated software marketplace to have rules.
It was how many different disciplines suddenly converge at the point of submission.
You are no longer only developing. You are doing security review, compatibility testing, interface design, documentation, licensing, release engineering, product presentation and support planning.
And every one of those areas exposes assumptions that were perfectly comfortable while the plugin lived on your own development site.
That has changed the way we think about Delicious software generally. Even products that are not destined for the Divi Marketplace benefit from being treated as though somebody else is going to inspect the details.
Because eventually somebody will.
It will probably be a customer.
The irritating thing is that the process works
It would make for a much more satisfying rant if the submission requirements were simply pointless obstacles.
Unfortunately, many of them force exactly the questions a commercial plugin developer should be asking anyway.
Is the product secure? Does it behave properly outside our own test site? Does it respect the platform it extends? Can we legally distribute everything inside it? Can we maintain it? Can we support the people who buy it?
By the time you have worked through those questions, you probably have a better plugin than the one you originally intended to submit.
Which is deeply inconvenient when you were hoping to complain about the whole experience.
So yes, getting a Divi plugin working is an achievement. Just don't mistake the entrance exam for graduation.
Official Marketplace requirements referenced in this article were checked against Elegant Themes' current Developer Guidelines, Design Guidelines, Product Licensing Requirements and Marketplace seller information.
