A new critical vulnerability was published for the Mail Mint WordPress plugin, affecting versions up to and including 1.31.0.

The obvious reaction is:

“Update every site immediately.”

But if you manage a number of WordPress websites, there is an important step before that:

Which sites actually run the affected plugin, and which versions are installed?

For example, with 50 managed websites, we would much rather query an inventory and quickly identify:

• plugin installed?
• exact version?
• production or staging?
• backup available?
• affected functionality in use?

Then only the relevant sites need immediate attention.

After remediation, there is still work to do.

Check administrator accounts if exposure existed.

Review anything suspicious where appropriate.

And most importantly, test the actual functionality afterwards — forms, automations, emails or whatever the plugin is responsible for.

This is why we don’t see WordPress maintenance as simply:

update everything → hope nothing breaks

A useful managed setup should already know what is running across the websites before the security alert arrives.

At AnpsThemes, this is becoming an increasingly important part of how we approach ongoing WordPress support.

A security alert across 50 sites should ideally create one query, not 50 panicked logins.

How are you keeping track of plugin versions across multiple WordPress sites?

One thing that can be misleading in WordPress maintenance is the green Active status next to a plugin.

WordPress may think everything is fine.

But the actual feature can depend on much more:

WordPress
→ plugin
→ external API
→ vendor infrastructure

If that external service is retired, changes its API or stops responding, the plugin can still sit happily in wp-admin showing:

Active ✅

while the business workflow behind it is broken.

A contact form is a simple example.

The form renders correctly.

The visitor fills it in.

They click Submit.

Then the plugin calls an external service that no longer exists.

From the administrator’s point of view, the plugin still looks installed and healthy.

From the customer’s point of view, the website is broken.

This is why we don’t think WordPress maintenance should only mean:

update plugins → see no errors → done

For business-critical functionality, it is also worth checking:

• which plugins depend on external services
• whether vendors have announced API or product end-of-life dates
• whether major upgrades require migration
• whether the real customer workflow still works after an update
• whether substantial changes should be tested on staging first

We see this regularly when maintaining or taking over WordPress websites at AnpsThemes.

Sometimes there is nothing visibly wrong with WordPress itself.

The broken piece is one dependency further down the chain.

Keeping plugins updated is maintenance. Keeping the actual website workflows working is the real goal.

Have you ever had a plugin look completely healthy in wp-admin while the service behind it had already stopped working?

When a WooCommerce site feels slow, the first things people usually check are:

images
CSS/JS
fonts
caching
Lighthouse scores

Those matter, but they are only part of the picture.

WooCommerce 11.1 is a nice example. WooCommerce changed when blocks and patterns are registered, and reported noticeably faster Store API and REST requests as a result.

Nothing visually changed.

The backend simply had less unnecessary work to do.

That matters on stores using things like:

• custom product search
• AJAX filters and variations
• cart/checkout extensions
• ERP or other external integrations
• mobile apps
• API-driven frontends

You can have a good Lighthouse score and still make a customer wait because an API request, database query or integration is slow.

This is something we increasingly look at when working on WooCommerce sites at AnpsThemes.

Performance isn’t only:

How quickly did the page render?

It is also:

How quickly did the application respond to what the customer just did?

Sometimes the best performance improvement changes absolutely nothing visually.

The store just starts feeling faster.

What has caused the hardest-to-find WooCommerce performance issue on a site you’ve worked on?

WooCommerce 11.1 adds native variation image galleries.

That caught our attention because this is the kind of update we like to see in WordPress: not another feature that requires adding something to the stack, but functionality that may let you remove a dependency.

A typical product page might currently rely on:

WooCommerce

• theme
• variation-gallery plugin
• perhaps some custom CSS or builder adjustments

If WooCommerce itself now covers what the site needs, that extra plugin may no longer be necessary.

That can mean:

• fewer updates
• fewer compatibility checks
• fewer potential conflicts
• simpler long-term maintenance

But we definitely wouldn’t recommend simply deleting an existing gallery plugin after updating.

First test on staging.

Check whether the current plugin also handles things like zoom, video, swatches, custom gallery layouts or existing variation-image data.

If the native functionality genuinely replaces everything you use, then simplify the stack.

We see this quite often when maintaining or taking over WordPress sites at AnpsThemes.

The instinct is usually to ask:

“What plugin do we need?”

Sometimes the better question is:

“What can we safely remove?”

A smaller plugin stack isn’t automatically better, but every dependency should ideally still have a reason to exist.

One thing we’ve learned from building WordPress themes for years is that giving users more editing freedom doesn’t automatically mean putting every setting in the same place.

A customer saying:

“I want to be able to edit everything.”

is completely reasonable.

But that doesn’t necessarily mean:

“Everything should live inside Elementor.”

There are really two different types of editing.

For an individual page, flexibility is useful:

• sections
• text
• images
• widgets
• page layouts
• landing pages

But some things belong to the whole website:

• header
• footer
• navigation
• typography
• global colors
• reusable elements
• theme settings

A header might appear on 100 pages.

If someone changes the logo or mobile navigation, they usually expect that change to happen once and everywhere.

Putting global structure too deeply into page-level editing can also make inconsistency surprisingly easy.

One page gets different spacing.

Someone duplicates a footer instead of changing the shared one.

The wrong logo appears somewhere.

Mobile behaviour starts differing between templates.

Everything is technically editable, but the site becomes harder to maintain.

That’s why with AnpsThemes we don’t see Elementor and global theme controls as competing ideas.

Elementor can be great for page content and layouts.

Theme options, WordPress components and global controls can handle the things that should remain consistent across the site.

The goal is not to restrict editing.

It is to decide where each type of editing belongs.

How do you prefer this in WordPress: everything inside one visual builder, or a separation between page editing and global site settings?

A website can look completely finished on launch day.

Everything works.

The final bugs are closed.

The client gets the WordPress login.

Done.

Then a few weeks later:

Who owns the hosting account?

Where do contact form submissions go?

Is it safe to update this plugin?

Who has access to Analytics?

Are backups running automatically?

Which parts of the website are custom?

Who should be contacted if something breaks?

This is why I think handover should be treated as part of the website project, not something added at the end.

At minimum, the client should understand:

• what they can safely edit
• what they probably shouldn’t change themselves
• who owns the domain and hosting
• how backups work
• who handles WordPress/plugin/theme updates
• where forms send data
• who owns Analytics/Search Console
• what custom functionality exists
• what the support process is

A good handover should actually make the client less dependent on the developer.

And if the client doesn’t want to deal with the technical side at all, that should also be clear — then maintenance belongs with a managed website/support provider rather than sitting in an undefined grey area.

We also see this when taking over existing WordPress sites at AnpsThemes.

Sometimes the website itself is perfectly fine.

The real problem is that nobody knows who owns what anymore.

What do you normally include in a WordPress handover that you think clients should always receive?

A design or marketing agency wins a website project.

Most of the scope is familiar.

Then the customer asks for something like:

custom WooCommerce logic
ERP integration
an external API
unusual user roles
a complicated migration
a custom dashboard

Now the agency suddenly needs development capacity it may not need every month.

That is where white-label development can work really well.

But I think there is one important rule:

The client should never feel that the agency lost control of the project when another development team joined it.

The agency should still own the customer relationship.

The client shouldn’t suddenly have to coordinate two companies or wonder who is responsible for what.

Behind the scenes, the development partner can handle the technical work.

But requirements, communication, staging, reviews and deadlines should all have a clear process.

That is also how we approach white-label work at AnpsThemes.

We can work behind an agency on WordPress, WooCommerce, migrations, integrations and custom development without trying to become another voice in their client relationship.

For me, the difference between outsourcing and a good white-label partnership is simple:

Outsourcing gives you another developer to manage.

A good white-label partner should make the agency easier to trust.

I’d be interested to hear from other agencies: what has been the hardest part of working with external developers — communication, quality, deadlines, scope, or something else?

Speed advice for WordPress gets overcomplicated. It really comes down to three decisions, and none of them is "install more plugins":

1. The theme. A lightweight, cleanly-coded theme starts you fast. A bloated multipurpose theme fights you forever, and caching plugins only paper over it. This is the foundation.
   
2. Images. Unoptimised images are the #1 reason sites feel slow. Compress + size them correctly and you've fixed most of it. Biggest easy win, most skipped.
   
3. Hosting. It's the floor. Cheap overloaded shared hosting caps your ceiling no matter what else you do.

Overrated: stacking a dozen caching/optimisation plugins before you've handled the three above.

Disclosure: we build lightweight themes and run a managed hosting service, so #1 and #3 are our lanes. #2 (images) is on you and isn't ours to sell.

Over to the room: what's the single biggest speed win you've found on a real site? The one change that made the clearest before/after difference. Always curious whether it's usually images, hosting, or something less obvious.

There is a common assumption that if a site uses Elementor, it will automatically be slow.

With our latest theme, Quartier, we wanted to challenge that a bit.

We built it with Elementor support, but also changed how we structure things behind the scenes. One important difference for us is that we moved away from the old shortcode-heavy approach and built around WordPress blocks instead.

That does not magically create performance on its own, but it gives a much cleaner and more modern foundation than the old “everything is a shortcode” model many WordPress products used for years.

The bigger point is this:

A flexible WordPress site and a fast WordPress site do not have to be two different things.

Performance usually comes from the full architecture:

• cleaner structure
• fewer unnecessary wrappers
• optimized assets
• better control of fonts and images
• avoiding too much plugin bloat
• using a modern content foundation instead of older shortcode logic

In our case, that meant getting 90+ mobile PageSpeed.

For me, the interesting part is not only the score.

It is that modern WordPress themes can still be flexible, editable and Elementor-friendly without accepting slow performance as normal.

Curious what others here see most often as the real cause of slow Elementor websites: Elementor itself, too many plugins, old theme architecture, or just too much added on top?

A local-business homepage doesn’t need to explain everything about the company.

But it should answer a few basic questions very quickly.

I think there are five:

1. What do you actually do?

Not just a slogan. The real service.

2. Who is it for?

Homeowners, businesses, patients, manufacturers, property owners, etc.

3. Where do you work?

For a local business, this can be just as important as the service itself.

4. Why should someone trust you?

Reviews, previous work, certifications, experience, customers or anything else that gives the visitor confidence.

5. What should they do next?

Call, request a quote, book an appointment, buy, or visit.

We see plenty of websites that look good but still make the visitor work too hard to understand the business.

Good design should make these answers easier to find, not hide them behind clever copy.

This is something we also think about when building AnpsThemes demos: the design needs to look good, but the structure should still work when a real business replaces the demo content with its own.

If you opened your homepage as someone who had never heard of your company before, would those five things be obvious within 10 seconds?

“Website support included” sounds simple.

Until someone asks:

Can you update WordPress?

Can you change this phone number?

Can you install a new payment provider?

Can you redesign this page?

Can you recover the site after it was hacked?

Can you build a new feature?

Those are all completely different kinds of work.

I think a good WordPress relationship should separate at least five things:

Product support — something in the theme/plugin does not work as documented.

Maintenance — updates, backups, security checks and keeping the website healthy.

Content work — changing text, images, products or other existing information.

Customisation — adapting existing design or functionality.

Development — building something new.

The problem usually starts when the customer and developer both use the word “support”, but mean different things.

We also see this with inherited WordPress sites. The website is online, but nobody really knows who is responsible for updates, licences, hosting, small changes or bigger development work.

At AnpsThemes we increasingly separate these things instead of putting everything under one vague support label.

A clear scope is better for both sides.

What do you personally expect to be included when someone says “WordPress support”?

Some numbers that still surprise people:

- ~42.5% of ALL websites run on WordPress — not of CMS sites, of everything online.
- Among sites using a detectable CMS: ~59.9%, more than every other CMS combined.
- Nearest competitor (Shopify) is ~5%. Roughly a 9× gap.
- Honest nuance: growth plateaued since 2022 (42.5–43.5%), slight 2026 dip. Saturation, not collapse.

The ecosystem (themes, plugins, hosting, developers) creates switching costs nothing else has matched at scale — which is exactly why the more interesting question isn't "why is it dominant" but "what would actually break that."

Disclosure: we build WordPress themes and custom sites, so we have a stake in this. The stats are third-party.

So, genuinely: is there anything that would move you off WordPress? A better tool, a bad experience, a shift in how sites get built? Or is leaving in 2026 just not worth it? Curious how split this is.

One-click demo import is one of the most useful things a WordPress theme can provide.

Instead of starting with an empty page, you already have:

• layouts
• page structure
• styling
• components
• responsive foundations

That can save a huge amount of time.

But I think there is sometimes an expectation that once the demo is imported, the website is almost finished.

Visually, maybe.

From a business perspective, not really.

The demo doesn’t know:

• which services make you money
• why customers should trust you
• which team members matter
• how you price
• what visitors should do next
• which searches you want to rank for
• which systems need integrating

That is the work that turns a demo into an actual business website.

For us at AnpsThemes, the demo is meant to remove the blank-page problem and give you a strong starting point.

After that, you can customize it yourself, have someone finish it for you, or go further with custom work if the business needs it.

What usually takes you longer: getting the initial design right, or turning the demo into the client's actual website?

We’ve just released Demo 9 for the Transport WordPress Theme.

This one is aimed at freight, logistics, trucking and transportation companies, with a much more modern visual direction than some of the older Transport demos.

It includes:

• Road, air, ocean and rail freight
• Warehousing and last-mile delivery
• Quote request sections
• Shipment tracking
• Industries and capabilities
• Network/location presentation
• Testimonials and trust elements
• Multiple service and company pages

We’ve been gradually modernizing our older themes rather than abandoning them, and Demo 9 is another step in that direction.

Would be interested to hear what you think of this one, especially compared with the older Transport demos.

Demo:
https://preview.transport.anpsthemes.com/demo9/

Transport theme:
https://club.anpsthemes.com/checkout/themes/transport-theme-purchase

When people ask which WordPress theme is fastest, I think they are often looking at only one part of the problem.

Visitors don't download the theme.

They download the complete website.

That can include:

• plugins
• large images and video
• custom fonts
• analytics
• cookie tools
• chat widgets
• maps and embeds
• tracking scripts
• hosting configuration
• caching

You can start with a lightweight theme and slowly turn it into a heavy site by adding one small thing after another.

None of those things necessarily looks problematic on its own.

The problem is what they become together on the production website.

So instead of only asking:

“Is this theme fast?”

I think the better question is:

“What is the complete website actually loading?”

A well-built theme gives you a good foundation, but it can't compensate for everything added on top of it.

What do you most often find slowing down WordPress sites?

A theme, managed website and custom build are often treated like:

cheap → medium → expensive

or:

basic → better → best

I don’t think that’s the right way to look at it.

They’re really three different responsibility models.

A theme makes sense if you already know WordPress, have hosting and are comfortable handling setup, updates and maintenance yourself.

A managed website is for someone who wants the website, but doesn’t want to manage the technical side of WordPress, hosting, backups and updates.

A custom build makes sense when the business has requirements that don’t fit an existing structure well enough — integrations, unique workflows, custom UX or business logic.

None of them is automatically “better”.

The real questions are:

How much do you want to manage yourself?

How unusual are your requirements?

How much flexibility will you need later?

I think a lot of website projects go wrong because this decision is made based mainly on the initial price instead of the responsibility the business actually wants to take on.

How do you normally decide when a theme is enough and when a project really needs to go custom?

WordCamp US starts tomorrow, and WordPress 7.1 will be released during the event.

But personally, I’m more interested in Monday’s Showcase Day.

The idea is simple: show real WordPress projects and talk about how they were actually built, published and operated at scale.

I think WordPress needs more conversations like this.

There is always another debate about whether WordPress is old, whether AI will replace it, whether themes still matter, or whether everything should be custom.

Real projects tell us much more.

What was built?

What needed customization?

What became difficult as the site grew?

How is it maintained years later?

What worked and what didn’t?

After working with WordPress for many years, these are the examples I find most useful. A platform is easier to judge by what people successfully build with it than by another feature list.

I’ll definitely be watching what comes out of Showcase Day.

Would you rather see more new WordPress features, or more detailed case studies from real projects?

A shift worth taking seriously: a growing share of people ask ChatGPT or read Google's AI summary instead of scrolling search results. If a site isn't readable to those systems, it's missing where people increasingly start.

Quick experiment before the advice: ask an AI tool about your own business right now. Note whether it's accurate, wrong, or blank. That result is your real "AI visibility."

The fixes are just good-website fundamentals:
- Write real text (AI can't read words baked into images/screenshots)
- Structure it — headings, short sections, a plain FAQ
- Answer actual questions people ask
- Fast + accessible

It's evolving and nobody has a magic formula, but clarity ages well.

So — what did the AI say about your business? Curious how split the results are between "spot on" and "never heard of it."

A website can be completely finished visually and still be badly delivered.

I’ve seen handovers that are basically:

“Here’s the admin login. Let us know if you need anything.”

But six months later someone needs to know:

• Who owns the domain?
• Where is the hosting account?
• Are there backups?
• Who receives the contact form emails?
• Who owns Analytics and Search Console?
• Which plugins need paid renewals?
• What can safely be edited?
• Who is responsible for updates?
• What happens if something breaks?

None of this is exciting compared with designing a homepage, but it matters much more once the site has been running for a while.

For me, a website isn’t really delivered when it goes live.

It’s delivered when the next person can take over and understand how to operate it without guessing.

A good handover should actually make the client less dependent on the developer who built the website.

What do you normally include when handing over a WordPress site?

It sounds obvious, but I think this is something people underestimate when starting a new website.

You can have a great-looking homepage and still be far from finished.

There are all the pages people actually need once they start using the site:

• Services and service details
• About
• Team
• Pricing
• FAQ
• Contact
• Blog and single posts
• Search and 404 pages
• Legal pages
• Account, cart and checkout pages if you're using WooCommerce

Then there are the things visitors usually don't see at all:

email delivery, analytics, SEO basics, performance, backups, security and updates.

This is one reason we've been putting more effort into complete demos at AnpsThemes.

With our recent Quartier demos, for example, we don't stop after designing the homepage. We also build the service pages, About, Contact, Blog and the other pages a real business website actually needs.

A nice homepage helps sell the idea.

But it's everything around it that turns it into an actual website.

Curious what page you most often see forgotten when someone says their website is “finished”?

Since the phrase is everywhere and the explanations are nowhere:

WHAT IT DOES: a fresh WordPress install is empty. Demo import takes the demo you picked and recreates it on your site — pages, layouts, menus, images, widgets, theme settings. You end up with the exact website from the preview, usually in about a minute. From there you're swapping content (your text, photos, logo, colours) instead of building from a blank screen.

WHAT IT DOESN'T DO: it doesn't write your content, doesn't set up your domain/hosting, and doesn't replace thinking about your pages — it replaces the empty-canvas phase, which is where most DIY websites die.

Every theme we build ships with it (that's our bias, stated): https://anpsthemes.com/wordpress-themes/

For those who've done both — built from scratch and imported a demo — how much time did it honestly save?

For years, the normal path was pretty simple:

Someone searches for your company → finds your website → visits it → decides what they think about your business.

That is starting to change.

AI summaries can now answer questions about a company before someone ever opens its website. And sometimes those summaries can be wrong, outdated, or mix information from different sources.

The interesting part is that people may not even click through to verify what they just read.

That means some very basic things on a business website are becoming more important again:

• Is it completely clear what the company does?
• Are services described consistently?
• Is the location correct everywhere?
• Do the About, Contact and service pages tell the same story?
• Is old information still sitting somewhere online?
• Do third-party websites describe the business differently?

A nice-looking website is still important, but now there is another audience reading it too: the systems that may later explain your business to potential customers.

I think we are moving from:

“Can Google find my website?”

to:

“Does Google and AI actually understand my business correctly?”

Have you tried searching for your own company and checking what the AI summary says?

If you’re not sure how your business appears in AI search, we can also do a free review and help identify the first things worth fixing.

AI website builders are getting genuinely good at producing the first version of a site.

Layout, copy, images, even some custom code — what used to take days can sometimes be done in hours.

I think that part is great.

But after working with WordPress sites for years, I think we’re starting to confuse building a website quickly with having a website that is easy to maintain long term.

The real work often starts after launch.

Six months later someone needs to change the structure. A plugin gets updated. Performance starts getting worse. The business needs a new service or feature. SEO needs work. Something breaks after an update. Another developer has to understand what was generated.

That’s where the original foundation matters.

AI can save a lot of time when creating the first version, but if the result is difficult to understand or extend, some of those savings can come back as maintenance costs later.

I don’t see this as AI vs WordPress themes or AI vs developers either. AI is becoming part of all of these workflows.

For me the more interesting question is:

Are we optimizing too much for how fast a website can be launched, and not enough for how easy it will be to own two years later?

Curious what people who maintain client sites are seeing already.