There was a time when building anything beyond a fairly standard WordPress website meant assembling a collection of plugins to fill in the gaps. Need a custom post layout? Add a plugin. Want a carousel? There's a plugin for that. Need a mega menu, filtering, interactive content or something slightly outside the capabilities of the page builder? You get the idea.
Plugins aren't inherently a problem. WordPress was built to be extensible, and we use plugins on nearly every website we develop. But every plugin we add becomes another piece of software that needs to be maintained, updated and kept compatible with WordPress, the theme and everything else running on the site.
Divi 5 is changing how often we need to reach for one.
A growing number of features that previously required third-party plugins, add-ons or custom development are now available within Divi itself. For us, that doesn't just make development faster. It gives us an opportunity to build WordPress websites with fewer dependencies and make better decisions about which plugins actually deserve to be there.
Can Divi 5 Reduce the Number of WordPress Plugins You Need?
The quick answer: Yes, depending on the website. Divi 5 includes native tools for custom content loops, filtering, interactions, carousels, advanced navigation, responsive layouts and other functionality that previously required plugins or custom development. That doesn't eliminate the need for WordPress plugins, but it can significantly reduce the number needed simply to build the front end of a website.
That's an important distinction. We're not interested in eliminating plugins for the sake of having a smaller number on the Plugins screen. We're interested in eliminating unnecessary dependencies.
The Loop Builder Changes a Lot
The Loop Builder is probably one of the best examples of how Divi 5 changes our development process.
A loop is simply a way of telling WordPress, "Find this type of content and display each result using this design." Blog posts are an obvious example, but the same idea can apply to team members, projects, case studies, products, resources, events or just about any other structured content stored in WordPress.
Historically, creating highly customized versions of those layouts could mean using a specialty module, adding another plugin or writing a custom template. The design was often limited by whatever options that particular solution gave us.
Divi 5 approaches it differently. We can design the item we want to repeat, connect its elements to dynamic WordPress content and then use the Loop Builder to populate it.
For a client, the benefit is what happens afterward. A marketing team can add a new case study in WordPress, for example, and the website handles how and where it appears. They aren't rebuilding a card, copying an old page or trying to remember what font size we used six months ago.
The content and design remain separate, which is exactly how a scalable website should work.
Filtering No Longer Automatically Means Another Plugin
Divi 5 has taken the Loop Builder a step further with native Loop Filter modules. These allow visitors to search, filter and reorder looped content on the front end of a website.
Think about a resource library that needs to be filtered by topic, a collection of case studies organized by industry, or a directory that allows visitors to narrow what they're looking for. Those are fairly common website requirements, but they're also the kind of requirements that can quickly send a WordPress build looking for another plugin.
Being able to build that functionality within the same system we're already using for the content and its design gives us considerably more control over the finished experience.
It also means we aren't designing around the limitations of someone else's filtering interface. We can think about what makes sense for the user first and build around that.
Carousels Have Become Much More Useful
Carousels are another good example because there has never been a shortage of WordPress slider and carousel plugins.
The Group Carousel module in Divi 5 lets us create a carousel using groups of content rather than limiting us to a predetermined image-and-text format. Those groups can contain other Divi elements and can also work with dynamic content and the Loop Builder.
That changes what a "carousel module" actually means.
We can use the same underlying tool for testimonials, featured projects, team members, products, posts or another custom layout rather than installing a different specialty plugin every time a design calls for horizontally scrolling content.
It's more flexible for us during development and much easier to keep visually consistent with the rest of the website.
Interactions Let Us Add Function Without Adding More Software
Not every interaction on a website needs JavaScript written from scratch or a plugin controlling it.
Divi 5's Interactions system lets us connect an action to a trigger. Clicking, hovering or interacting with one element can change another element on the page. That opens up a fairly large range of possibilities for content reveals, custom navigation, popups, toggles and other interactive experiences.
This is an area where restraint matters. Just because we can make everything move doesn't mean we should.
What interests us is the ability to add interaction when it improves how someone uses the website without automatically increasing the site's plugin footprint. A well-placed content reveal or custom menu can make a complex amount of information much easier to navigate. That's useful. Making a headline fly across the screen because we found the setting isn't.
Navigation Doesn't Have to Come Out of a Box
Navigation is one of those areas where seemingly simple design ideas can become surprisingly complicated during development.
Divi 5 now includes Link and Dropdown modules, menu looping and expanded interaction controls that give us the pieces to create much more customized navigation inside the Visual Builder. That includes layouts such as mega menus, slide-in menus and other navigation systems that previously could have required a dedicated menu plugin or more custom development.
For us, the advantage is design freedom. The navigation can be treated as part of the overall user experience rather than a predefined module sitting at the top of the page.
It also keeps more of the site's visual system in one place. When navigation needs to change later, we're not sending a client into a completely different plugin interface with its own terminology, settings and styling controls.
Sometimes the Small Modules Save the Most Time
Not every useful addition needs to completely change the way a website works.
Divi 5 now includes native modules for things like breadcrumbs, tables of contents and SVG graphics. There are also newer modules for timelines, charts and other content types.
Individually, these may seem like fairly small additions. From a development standpoint, though, they're exactly the kind of features that can prevent a site from accumulating single-purpose plugins.
If we need breadcrumbs on a website, we'd rather add breadcrumbs than install and maintain an entire package simply because breadcrumbs happened to be included in it. If an article needs an automatically generated table of contents, having that capability within the builder gives us another option before looking outside the site's existing development system.
Multiply those decisions across an entire website and they start to matter.
Fewer Plugins Doesn't Automatically Mean a Better Website
This is where we think the conversation around WordPress plugins sometimes gets oversimplified.
A website with 10 plugins isn't automatically better than a website with 20. One poorly built plugin can cause more problems than a collection of well-supported ones, and some of the most valuable features on a WordPress website absolutely should come from dedicated software.
WooCommerce and Gravity Forms are both plugins that handle complex, specialized functionality, and there are plenty of good reasons to use tools like them. We’re not trying to build everything inside Divi 5 just to avoid using plugins. We’re simply more selective about adding plugins when the functionality we need is already built into the platform.
The better question is whether every plugin on the website has a good reason to be there.
If Divi 5 can natively handle a carousel, content loop, menu or interaction exactly the way we need it, adding another third-party dependency doesn't necessarily improve the website. It may just give us one more thing to maintain.
Native Doesn't Mean We Stop Writing Code
Divi 5 hasn't removed custom development from our process either.
We still write CSS. We still work with WordPress functionality outside of Divi. We still use custom fields, plugins and other development tools when the project calls for them.
What has changed is where we start.
We don't have to reach for custom code simply because the builder can't create the layout we designed. We don't have to install a plugin simply because we need content to repeat in a certain way. And we're less likely to find ourselves stacking workarounds together to create something that should have been relatively straightforward in the first place.
That gives us more time to use custom development where it actually adds value.
A Leaner WordPress Build Is Easier to Live With
The real benefit of all of this isn't that we can brag about using fewer plugins. Most clients will never know how many plugins their website has, nor should they need to care.
What they do care about is whether the website works, whether their team can update it, how much it costs to maintain and what happens when WordPress changes three years from now.
Every unnecessary dependency we can remove simplifies that equation. There are fewer separate interfaces for a marketing team to learn, fewer third-party products to keep track of and fewer places to look when something stops behaving the way it should.
Divi 5 gives us more native tools than we've had before, which means we can be more intentional about everything we add on top of it.
That's the part we're interested in. Not fewer plugins at any cost. A better reason for every one we keep.
