r/ProWordPress

I’ve audited probably 150+ WordPress sites in the last few years, and the pattern is almost always the same: bloated page builder, 40+ CSS files, render-blocking scripts, and a homepage that takes 6-8 seconds to load on mobile. Elementor isn’t evil, but the way most people use it (stacking add-ons, unused widgets, no cleanup) turns a simple 5-page site into a 3MB monster. I’m not saying “switch to hand-coded HTML,” I’m saying: if your site takes longer than 3 seconds to load, the builder isn’t your problem — how you’re using it is. Curious what others think. Anyone actually measured the speed difference between builders vs. custom themes on similar sites

Been looking into WP-to-headless migrations (Sanity/Strapi + Next.js) lately and the thing that keeps coming up as the biggest time sink isn't the content migration itself, it's redirect mapping. Years of slug history with duplicates, chains, and loops apparently eats way more time than anyone budgets for.

A couple other things I've seen bite people:

• Preview workflow parity for content editors (WP's preview-on-save is apparently sorely missed post-migration)
• SEO metadata (og:title etc.) not migrating cleanly, causing ranking dips that only get noticed days later

For those who've done this migration for a client or your own site: how did you handle the redirect mapping specifically? Custom script, existing tool, manual spreadsheet triage? Curious what's actually worked vs. what ate more time than expected.

I manage a few WordPress sites, and I find myself checking the dashboard multiple times a day just to see if there's a new WooCommerce order, a form submission, or a booking.

I'm curious how everyone else handles this.

Do you just rely on email notifications?

Do you check the dashboard periodically?

Do you use any monitoring or automation tools?

Is this something you've solved, or do you just live with it?

I'd love to hear your workflow and whether it's ever been a pain point for you.

I’ve been building increasingly complex plugins lately, and I’m hitting the wall with the traditional WordPress architectural patterns.

The standard approach of scattering add_action and add_filter everywhere, relying on global state, and tightly coupling logic to WordPress core functions gets incredibly difficult to test and maintain as the codebase grows.

I’ve been experimenting with bringing modern PHP practices into my plugin development—specifically:

Dependency Injection (via a DI Container) to handle instantiation and testing.

Strict routing and controllers for REST APIs and admin-ajax, rather than dumping logic directly into closures or fat classes.

Middleware pipelines for requests (auth, validation, etc.).

Domain-Driven Design to separate the business logic entirely from the WordPress presentation layer.

Every time I build this way, the code is vastly cleaner and easier to reason about. But it also feels like I'm swimming against the current of how WordPress "wants" to be written.

For those of you building enterprise or highly complex plugins: Are you implementing SOLID and modern architectural patterns in your WP projects? Have you found a good balance, or do you feel it ultimately creates too much overhead and friction with WP core?

WordPress has no single machine-readable place where an AI agent can discover what a site is capable of. Today an agent has to piece together the REST API, plugin-specific endpoints, SEO metadata, llms.txt, security.txt, and whatever conventions individual plugins invent. Every agent ends up implementing its own discovery logic, and every plugin has to integrate with every agent separately.

So I drafted WP Discovery — a proposal for a machine-readable capability registry for WordPress. Plugins declare intent (for example commerce.products.read) separately from the endpoint that implements it, and an engine aggregates everything into a single document at /.well-known/discovery.json.

A plugin opts in with a single hook and no hard dependency:

add_action( 'wpdiscovery_register', function ( $registry ) {
    $registry->register( [
        'id' => 'acme-bookings',
        'title' => 'Acme Bookings',
        'type' => 'scheduling',
        'capabilities' => [
            'scheduling.availability.read',
            'scheduling.booking.create',
        ],
        'endpoints' => [
            [
                'url'  => '/wp-json/acme/v1',
                'type' => 'rest',
                'auth' => 'apikey',
            ],
        ],
    ] );
} );

If no discovery engine is installed, the action never fires and nothing breaks.

One design goal is that plugins integrate with WordPress—not with individual AI agents. The discovery engine is responsible for aggregating, normalizing, and publishing capabilities, while site owners decide whether to expose them publicly.

This is still an early proposal (v0.1.0), not an adopted standard. The only implementation today is my own reference plugin, so I'm posting it here because I'd genuinely like experienced WordPress developers to poke holes in it before I invest more time.

The questions I'm most interested in are:

1. Is separating capabilities from endpoints actually useful, or is this just OpenAPI with extra steps?
2. Is there a better WordPress-native way for plugins to expose capabilities to AI agents?

Links

• Spec: https://heera.github.io/wp-discovery-protocol/
• Reference plugin: https://wordpress.org/plugins/agentimus/
• Example output: https://heera.it/.well-known/discovery.json

This isn't a commercial project. The specification is licensed under CC BY 4.0, the hook is vendor-neutral, and I'm primarily looking for honest technical criticism.

Salve a tutti ho intenzione di creare un plugin che installi tramite WordPress un gestionale , in questo caso specifico per fotografi di nome D20 Keep che serve per caricare servizi , permettere la scelta o l acquisto delle foto e gestire i clienti. Secondo voi può essere un idea fattibile. Invece di avere una piattaforma esterna il gestionale rimarrebbe sul sito wp del fotografo , chiaramente con i limiti di spazio e prestazioni hosting del proprio sito.

Però i clienti non uscirebbero dal sito del fotografo utilizzando altre applicazioni e la gestione sarebbe molto controllata.

Il gestionale utilizza il db del sito wp ma in effetti la cartella di tutto il gestionale rimane fuori dall installazione wp.

Qualcuno ha qualche riflessione da fare per aiutarmi a capire aspetti che magari non sto considerando ora?

This comes up constantly, so I'll write it once.

You rename your login slug, and minutes later you're still seeing failed login attempts. The instinct is "the secret leaked, something's compromised." Almost always, it hasn't.

Two things are usually going on.

1. WordPress has more than one login. /xmlrpc.php exposes a method, wp.getUsersBlogs, that takes a username and password and validates them with no login form involved. system.multicall even lets a bot batch hundreds of guesses into a single request. Renaming /wp-login.php does nothing to that endpoint, so the attempts keep coming and it looks like your new URL got discovered. It didn't. The bot was never using it.
2. If the attempts come from constantly changing IPs, rate limiting and per-IP lockout can't do much. They count failures per address, and a rotating-IP botnet sends each try from a fresh IP, so the counter never trips. You can drop the threshold to 2 and nothing changes.

What actually quiets it down:

• Change the login path at the rewrite layer (nginx/apache config), not just with a slug plugin, so a request to /wp-login.php returns 404 before PHP loads. No process starts, so the rotating IPs stop mattering.
• Disable XML-RPC if nothing you run needs it (Jetpack and some old mobile apps are the exceptions), or at least block the auth methods.

None of this replaces a security plugin for 2FA and monitoring, those still earn their place. It just moves the brute-force defense to a layer the bots can't walk around by swapping an IP or an endpoint.

For those of you who renamed the login and still saw attempts: did you ever check your access log for /xmlrpc.php hits? Curious how often that's the real source versus something else.

I posted an article stipulating the importance of keeping a wordpress site up to date, and it was removed for "self promotion"

Id like to know WHO decides when an article is self promotion or not... because the article I posted was simply advise...

For years I built almost everything in Elementor Pro. It was fast, clients could edit content themselves, and it covered 90% of what most projects needed. But over the last year I've been quietly moving away from it and I'm curious if others are doing the same.

The reasons piled up slowly. Sites got heavier even with optimization. Clients would "edit" something and accidentally break a layout. Updates occasionally introduced regressions that I had to fix on multiple sites at once. And the database bloat on bigger sites became real, especially when clients had been editing pages for a year or two.

What I've been doing instead is building with the block editor and ACF for custom fields, plus a lightweight starter theme. More upfront work, but the sites are faster, the code is cleaner, and clients can still edit text and images without touching layout. When something breaks it's almost always something I can actually debug instead of a builder issue I have to wait for the developer to patch.

The tradeoff is real though. Some clients specifically want the visual drag and drop experience and won't accept anything less. And for very small projects the builder is still faster end to end.

What I'm trying to figure out is whether this is just me getting tired of builder maintenance, or if there's a broader shift happening. Are you still all in on Elementor, Bricks, Breakdance, or has the block editor matured enough that you're moving back to it for serious client work?

Also curious if anyone's gone the opposite direction, started with native blocks and moved to a builder because clients demanded it.

I'm investigating a strange WordPress issue and would appreciate any guidance.

Environment:

• WordPress
• Elementor + Elementor Pro
• OceanWP
• Hostinger hosting

Problem: A page called "DACOR Indica" (/conteudos/) used to display a large list of posts.

Suddenly:

• The page became empty.
• Posts are still published in WordPress (200+ posts).
• The page itself still exists and is published.
• Sometimes Elementor shows the content, sometimes it disappears.
• Revisions do not restore the page correctly.

Plugin behavior:

• Xpro Elementor Addons OFF = page loads (but empty)
• Xpro Elementor Addons ON = critical error

Additional findings: I found these files in public_html:

wp-security.php wp-server.php wp-contt.php cm-prepend.php cm-serve.php agent_renew.php tester.php tester2.php .cm-cfg

These do not look like standard WordPress files.

I also received PHP errors related to Complianz GDPR mentioning database command synchronization issues.

Actions already performed:

• Restored website files from Hostinger backup
• Tested Xpro on/off
• Checked that posts still exist
• Checked Elementor revisions
• Installed Wordfence (not yet deeply analyzed)

Questions:

1. Do these files look like malware/backdoors?
2. Could malware corrupt Elementor's _elementor_data?
3. Is Xpro likely the cause or just exposing another issue?
4. What would you inspect first:
   • _elementor_data
   • error_log
   • .user.ini
   • suspicious PHP files
   • database

Any advice is appreciated.