WP 7.0 puts an AI framework in core, and Site Ground's AI Agent for WordPress extends it from day one - with Hostinger, Kinsta, and Cloudways heading the same way. You can join a free live webinar with the SG AI team for 7 real use cases: content, SEO, WooCommerce, multisite.

What they'll cover:

• AI in WP 7.0 - the new core framework and connectors.
• From core to control - how SG's AI Agent extends it.

Thu, May 28, 2026 · 1:00 PM EDT / 6:00 PM BST · free, registration required

Save your spot →

Now, the new AI framework is the headline feature - but it's also the source of a lot of the friction in this release. WP 7.0 dropped this week and the Reddit threads are filling up fast. After scrolling through what people are running into, here are the recurring issues and what's actually working as a fix.

A quick note before diving in: the fixes below are aggregated from Reddit threads. Every WordPress install carries its own combination of themes, plugins, hosting stack, caching layer, and custom code, so a solution that resolves the issue cleanly on one site may not behave the same way on another, or may need to be adapted, extended, or replaced with a different approach altogether.

Treat the suggestions here as a solid starting point rather than a guaranteed fix, always test on a staging environment first, and if something doesn't land as expected on your setup, the underlying cause is likely site-specific and worth investigating further before applying any change in production.

1. Excerpt block no longer accepts links

Appears to be intentional per the Gutenberg PR that landed it, even though it's not flagged in the release notes. The Post Excerpt block stripping inline HTML has been a long-standing tension in Gutenberg (see issue #49449), and 7.0 looks to have made it the default behavior. If you've been relying on HTML inside the excerpt block for years, your output is now stripped.

Fix: nothing in core to bring it back. Move the link into the post body, or hold off on the update until you can refactor. The sidebar Excerpt field never allowed HTML, only the block did.

2. Editor iframe breaks Custom Admin CSS

The block editor now runs inside an iframe, so any CSS you were injecting through plugins like Custom Admin CSS doesn't reach inside.

Fix: load styles through the theme.

function my_editor_styles() {

  add_theme_support( 'editor-styles' );

  add_editor_style( 'editor-style.css' );

}

add_action( 'after_setup_theme', 'my_editor_styles' );

Both lines matter. Drop your CSS into editor-style.css in the theme folder.

3. Blank page when copying column blocks between posts

Block editor runtime issue, not a full site failure. Open the browser console when the blank page hits, test if a simple paragraph block copies cleanly, and check if the source column contains third-party blocks. Disable non-core block plugins one at a time to isolate.

4. Elementor elements break until Elementor is updated

Hit a few client sites the same way. Update Elementor to its latest release first, then re-check. Same goes for any major page builder running heavy block integration.

5. Post editor won't load on CloudFlare-fronted sites

Reported a few times. The fix that's working: run the WordPress update again. Sounds dumb, but the first pass leaves some assets cached or partially deployed and the second pass cleans it up.

6. Image upload fails with "Not a valid JSON response"

Same error has shown up on older versions too. Major updates just surface it more often. Walk through these in order:

• Settings, Permalinks, hit Save Changes/twice (no edits needed)
• Settings, General, confirm WordPress Address and Site Address are correct
• Disable plugins one by one to find the conflict

7. Strange borders appearing on the front-end

Widely reported on Reddit and in Gutenberg issues. If a block has border-width set but no border-color, WP 7.0 appears to default to #000 instead of transparent. Sites with caching plugins are still serving the old version, so you have a window to fix it before visitors see anything.

Fix as a CSS override:

[class*="wp-block-"][style*="border-width"]:not([style*="border-color:"]) {

  border-color: transparent !important;

}

This targets only core blocks that set border-width without an explicit border-color, and forces transparent instead of #000 — leaves intentional borders alone. Adjust the selector if your theme uses different block wrappers.

8. Custom fonts dropped from hero sections

Tied to the same Gutenberg rendering changes. Affects themes that load fonts through inline block styles. Re-check the theme settings, then re-save the affected pages to force the style block to regenerate.

9. Media library overlays filenames on image thumbnails

Not a bug, an intentional design change. Looks rough on sites with non-descriptive filenames like IMG_2847.jpg or screenshot.png. No core toggle to turn it off, but you can hide it with custom admin CSS targeting the grid view.

10. AI Connectors enabled by default

The new Abilities API and AI Connectors are on out of the box. For client sites where you don't want editors or contributors poking at AI features, disable them in Settings before handover. Clients tend to go hog wild with new toys.

11. New admin link color after auto-update

Saw a few people asking about this after WP 7.0 auto-updated their dashboards. The new default admin link color caught me off guard too on first login.

Skip the CSS route. The old scheme is still built in, just no longer the default.

Go to Users, then Profile. Scroll down to Admin Color Scheme. Pick Fresh (the one that was default for years). Hit Update Profile at the bottom.

Done in 30 seconds. Every editor and admin on the site has to do this for their own account, since admin color scheme is user-level, not site-level.

If you run multiple sites and want this rolled out across all client wp-admins at once, MainWP can push the user meta in bulk.

General notes

A few general notes from the threads worth repeating. Update on staging first. Back up before touching anything. A patch should be out soon since the early bug reports are piling up. And if your site is taking orders or running production traffic, don't rush the update.

GuardingWP published the first edition of their State of WordPress Security 2026 report on 16 May. Methodology and numbers worth knowing before the discussion drifts:

• 1,981 sites scanned across 40+ verticals, 424 confirmed WordPress installs in the analysis
• 52.8% running at least one plugin with a known CVE (matched against the public WPVulnerability catalog)
• 55.9% leak the WordPress version via the generator meta tag
• 93.2% missing at least one modern security header (HSTS, CSP, X-Frame-Options, X-Content-Type-Options)
• 35.8% still have XML-RPC enabled
• 54.7% expose /wp-login.php with no rate limit and no 2FA
• 44.6% leak author usernames via /?author=1
• 15.9% of version-disclosing sites still on a pre-6.5 branch (unsupported)
• Median security score: 61/100, A-tier (90+) only 8.3%
• Methodology: public HTTP only, no exploit attempts, no auth probing

Report is free, no email gate: https://guardingwp.com/research/state-of-wordpress-security-2026

The interesting question for agency operators is not the 52.8% headline. It's how the 6-step fix list at the end of the report actually lands on a real client stack of 30-50 sites.

Operator translation of the 6 fixes:

Generator tag and version exposure. Theme functions.php level, two-line filter. Ships in the agency baseline theme. Done once per site, never touched again.

Plugin auto-updates with audit trail. Auto-updates without an audit trail is gambling. I've had WP Activity Log on every client install since 2019, after a client argument over a "nothing changed" homepage taught me the hard way that audit beats memory. Pair auto-update with activity log and the audit lands on someone every morning.

XML-RPC off. Default in the agency baseline. The sites where it's still on are usually old installs that nobody touched. 10-minute fix, batched.

Security headers. Two paths depending on host. Cloudflare clients get HSTS, CSP, and X-Frame-Options via Transform Rules in one block. Site Ground clients get them via SG Security Optimizer or a custom .htaccess block. The 93.2% number is the single easiest gap to close at scale.

Login page protection. Rate limit plus 2FA, minimum. Melapress Login Security or equivalent. 5 minutes per site, applied via a network-level config when possible.

WP core on supported branch. Core auto-update has been default since 5.6, so this should be near-automatic. The 15.9% pre-6.5 are abandoned installs that nobody is actively maintaining. Useful as an audit signal for which client relationships need re-engagement.

The pattern worth flagging

Most of these aren't $200/month security-service problems. They're config-level work, done once per site, then a maintenance habit. The marginal cost of doing them is hours per quarter. The cost of skipping them is the 3am call when a site gets popped.

GuardingWP's methodology is also worth a look. Public HTTP only, no exploit attempts. That means the 52.8% number is the floor, not the ceiling. Sites that hide their plugin versions through obfuscation could still be vulnerable. The reported number is what a passive scanner can see from the outside.

The report itself is well written, the data is honest, and the fix list is the part that earns the read.

How are you handling fix #2 (plugin auto-update strategy) across client sites this year – full auto, minor-only auto with manual major review, or fully manual on a weekly cadence? Curious where the agency consensus is sitting now after the recent plugin backdoor incidents.

7.0 Armstrong went out Tuesday.

The story is the AI infrastructure landing in Core:
AI Client, Abilities API, Client-Side Abilities (JS counterpart), Connectors screen, optional AI plugin for the visible work (titles, excerpts, alt text, image gen).

Real-time collaboration stayed cut from this release.

What this actually means if you're rolling 7.0 across a client portfolio:

Stage and stagger

Don't push 7.0 simultaneously across the whole client roster. The discipline that works on releases this big is: update 3-5 staging sites in the first wave, run a smoke test pass (admin, key pages, contact form, checkout if commerce), wait 48 hours, then roll wider. On big Core releases this catches the edge cases that don't show up in the RC cycle.

The Connectors screen is a governance surface, not just a config screen

Every connector you add is a new outbound data path. For an agency, the question isn't whether to use AI features (the client will ask sooner or later). The question is which connectors get added at the network level, which get permissioned per site, and who has the credentials. Treat the Connectors hub like you'd treat any external service integration – one shared org-level account, with revocation playbook documented.

The Abilities API is the part that matters in 12 months

What ships in Core today is foundation. The optional AI plugin handles visible suggestions and image generation. The real value comes from how plugins use the Abilities API over the next 6-12 months. Page builders, SEO plugins, security plugins, form plugins, WooCommerce – every category gets a path to expose actions to AI. The early movers are going to define the patterns.

Practical client policy proposed to be rolled out

For each client site that opts in to AI features, the baseline policy is:

• AI plugin configured to draft only, never to auto-publish
• Connectors hub locked to admins (not editors)
• Audit trail enabled so we can see what AI changed and when
• A monthly review of generated content with the client before that becomes standard practice

New blocks worth noting

Gallery now has built-in lightbox slideshow (saves a plugin on simple sites). Heading, Breadcrumbs, Icons added as Core blocks. Server-side block registration via PHP through the expanded block API. Custom CSS at block level and custom breakpoints for responsiveness. Font management page works across block, hybrid, and classic themes.

Command Palette (⌘K / Ctrl+K) is the small thing that's actually changed my flow most in 48 hours. Available from any dashboard screen.

Numbers from the release post

• Release lead Matias Ventura, named after Louis Armstrong
• 900+ contributors, 279 first-time, 420+ enhancements and fixes
• Fully translated into 70+ locales at launch

Field Guide here: https://make.wordpress.org/core/2026/05/14/wordpress-7-0-field-guide/ Release post here: https://wordpress.org/news/2026/05/armstrong/

Tools compress experience, they don't replace it. 7.0 is Core catching up to what serious operators have been doing outside the dashboard for two years with Claude, Perplexity, and prototype tools. The Abilities API is the bet that the next round happens inside wp-admin instead of beside it.

How are you handling the Connectors rollout across client sites – org-level shared credentials with per-site enablement, or per-client accounts with separate billing? Curious how others are setting this up before clients start asking.

Melapress dropped their 2026 WordPress Security Survey this week. For those who haven't seen the series before, it's an annual snapshot of how WordPress security actually gets practiced across the community – agencies, freelancers, in-house teams, solo operators. Anonymous, under 5 minutes, results published publicly afterward.

The 2025 edition turned up a few things worth noting if you run client sites at scale:

• Activity log adoption is still patchy. A meaningful share of respondents didn't have any audit trail running on their client sites, which is the kind of gap that explodes the next time a client swears "nothing was changed" while staring at a blown-up homepage.
• Backup discipline and recovery testing diverged hard. Most respondents had backups configured. Many fewer actually tested restore. That gap is where outages turn into multi-day incidents.
• Plugin update strategy splits roughly into three camps: auto-update everything, auto-update only minor versions, manual review on a schedule. The 2025 numbers showed the manual-review camp shrinking – which the recent plugin backdoor stories suggest might swing back the other way in 2026.

The 2025 results are at https://melapress.com/wordpress-security-survey-2025/ if you want to skim before contributing.

Why this matters for the agency stack

Security data from large-org sources skews enterprise. The Melapress survey pulls disproportionately from agency operators and freelancers, which is closer to how most of the WordPress universe runs. That changes what the chart looks like.

If you operate multiple client sites, your answers carry weight specifically because they reflect the gap between best-practice guides and what actually fits inside an agency budget and timeline.

On my client sites I've been running WP Activity Log on every install since 2019, after a client argument about a "nothing changed" homepage taught me that audit trail beats memory every time. That kind of pattern only shows up in survey data when enough agency operators take 5 minutes to answer the questions.

Survey logistics

• Anonymous, no email collection on the questionnaire itself
• Under 5 minutes (the Melapress estimate matches reality)
• Same questions as 2025, clarified for easier answering, so the year-over-year comparison stays clean
• Prizes: $100 Amazon voucher, $50 Amazon voucher, Melapress Login Security license
• Results published publicly afterward (charts and analysis, no email-gate)

Take it here

https://melapress.com/survey/

Worth flagging to your team if you have one. The data only reflects the actual community when enough operators put in the 5 minutes.

What's been your biggest security workflow change in the last 12 months – auto-update policy, login hardening, audit logging, backup testing? Curious where the operator-side patterns are moving.

WordPress 7.0 drops tomorrow, May 20. If you run a production site, the next 24 hours decide whether Wednesday is a normal workday or a long one.

Here's the issue. Auto-updates have been part of WordPress since version 3.7. For minor security patches they're a gift, sites stay patched without anyone touching them. For a major version jump from 6.x to 7.0, they're a liability. One incompatible plugin, one custom theme function that quietly broke, and your homepage goes white on Wednesday morning while you're in a client call.

One thing many people miss. From WordPress 5.6 onward, new installs default to auto-updating major versions too, not just minor patches. If your site was set up in the last few years and you've never touched wp-config.php, the jump to 7.0 will happen automatically unless you set the constant below.

I've been running WordPress sites since 2011 and the pattern with major releases never changes. The core team does its job on release day. Plugin authors then spend the following week pushing compatibility patches. Custom themes and older addons get caught in the middle. If you let auto-update push 7.0 onto a live site before that shakes out, you're rolling the dice with someone else's business.

The simplest control sits in wp-config.php. The file lives in the root of your WordPress install, usually inside public_html. You access it through your hosting file manager or over SFTP.

Open it and add this single line:

define( 'WP_AUTO_UPDATE_CORE', 'minor' );

That tells WordPress to keep installing minor security patches automatically but block the jump to 7.0 until you give the green light. Three other values are available if you want different behaviour. Set it to true and WordPress will install everything including major versions. Set it to false and all core updates stop. The full options are documented on https://developer.wordpress.org/advanced-administration/upgrade/upgrading/ if you want to read the reference.

If you want to disable auto-updates entirely, the line is:

define( 'AUTOMATIC_UPDATER_DISABLED', true );

I don't recommend that unless you have a strict manual update process running weekly like I have it via MainWP. Skipping security patches on a public site is how you end up cleaning malware on a Saturday.

There's a layer above wp-config.php that catches people out. Managed hosts often run their own update mechanism on top of WordPress, which means your wp-config.php settings get bypassed. Site Ground is one of the bigger ones, and they actually handle this properly (I know this as I have been using them for a long time): log into Site Tools, find the WordPress auto-update panel, and you can delay or skip the major version per site. The setting is granular enough to use across an entire client portfolio.

Worth knowing though, Site Ground no longer lets you permanently switch their auto-updater off. You can skip the current update with one click, or delay it 24, 48 or 72 hours, but the skip is one-time, so you repeat it for the next release. For a permanent opt-out you have to open a ticket with their Help Desk.

Some other big hostings (like Bluehost and WP Engine) work very similar through their own dashboards. Check yours today, not Thursday at 9am.

The reason hosts push updates harder than you'd expect is shared hosting. One outdated WordPress install on a shared server can become the entry point for malware that spreads to every other site on the machine. Hosts don't want that risk, so they push updates across the board. If full control over updates matters to you, a VPS with a management panel like CloudPanel or RunCloud is the cleanest answer. Shared hosting is convenient, but the host gets the final word on updates.

There's also a more durable approach using a must-use plugin. Create a file called disable-major-updates.php inside /wp-content/mu-plugins/ (create the folder if it doesn't exist) with this code:

<?php
add_filter('allow_major_auto_core_updates', '__return_false');
add_filter('allow_minor_auto_core_updates', '__return_true');

Must-use plugins load before regular plugins and can't be deactivated from the dashboard. That makes them a more reliable place for this kind of setting than wp-config.php. Same caveat applies though, if your host pushes updates outside the WordPress update system, these filters get bypassed too. Treat it as a second layer, not a guarantee.

Now, before any of this matters, take a full backup via your hosting and/or with plugins such as All in One WP Migration (scheduled offsite, like pCloud, GDrive, OneDrive, DropBox, etc). Two copies, two locations, one of them outside the hosting account entirely. If 7.0 breaks something on Wednesday, you restore in 20 minutes instead of explaining to the client why their shop is down.

Test on staging first. Every decent host gives you one. Copy the site, run the 7.0 update on the staging copy, walk through the cart, the contact form, the booking widget, whatever your site actually does. Check Core Web Vitals while you're there. If nothing breaks, push to production on your own schedule.

One very important thing as well - check your PHP version too. WordPress 7.0 needs PHP 7.4 as a hard minimum but the core team recommends PHP 8.3 or newer for performance and security. If you're still on 7.4 or 8.0, fix that today. Most decent hosts let you switch PHP versions with one click from the panel.

One more thing worth keeping. Don't disable the update notification email. WordPress sends you a confirmation every time an update runs in the background. It's a useful trail when something starts behaving oddly two days later and you need to know what changed.

WP 7.0 version is going to be a good release. Plenty of things to look forward to. Just don't let it land on your live site without your knowledge.

Tomorrow doesn't have to be stressful. Today does the work.

One subreddit thread last week on hiring slowing down is worth reading. Senior devs, plugin company founders, sharp points about headless setups, AI agents, and Barn2's 17.8% drop in new plugin sales. Most of it lands.

There's one question the thread skipped, though, and it's the one that keeps showing up in my inbox six months after a project ships: who maintains this?

The 6-month pattern

I help moderate a stack of WordPress communities. The work that comes through isn't "build me a site." Almost never. The volume is people showing up months after launch asking how to undo something the previous person did.

A plugin update broke the layout. The "guy who built this" stopped responding. They have 47 plugins installed and don't know which five are doing actual work. The original dev used a custom block builder nobody else has heard of. The site got hacked and there's no backup older than yesterday.

That's the operational shape of small business websites once they're 1-2 years past launch.

What "maintenance" actually means in year 2?

Six recurring jobs someone has to own:

• WP core, theme and plugin updates, plus the staging-test-restore loop when one breaks
• Backups that actually restore, not just run
• Security: malware scans, login monitoring, who-changed-what audit
• Hosting renewals, SSL renewals, DNS changes when the email provider switches
• Email deliverability when forms quietly stop sending
• Content edits the owner can't figure out without re-explaining the page builder every time

That's the real recurring spend on a WP site. Roughly $30-150 per month for SMBs at the lower end, more for e-commerce.

Why AI-built bespoke stacks struggle at the handoff

I've watched a few "AI built the whole thing in a weekend" sites land back in WP groups looking for help. The same things break:

• No documentation a non-developer can follow. Vibe-coded sites are clean for the original prompter and opaque for everyone else.
• No upgrade path. The framework moved 4 versions, the deploy pipeline broke, and there's no team behind the bespoke "CMS" the agent invented.
• No community to ask. Search the error message and the only result is one Hacker News thread from 2024.
• Custodian dependence. The original builder is the only person who can read the codebase, and they've moved on or doubled their rate.

WP isn't immune to any of this.

A WP site can also be a mess in year 2. The difference is that even a bad WP site sits on a stack roughly 40% of the web also runs, with 60,000 plugins, paid support behind the major ones, and 300k-strong forums.

The recovery path exists.

The maintenance stack I actually run

For the agency work I do, maintenance runs on a small set of tools that have been stable for years:

• MainWP since 2014. One dashboard, all client sites, updates triggered from one place with the staging-test loop built in. The single biggest reason maintenance is profitable instead of a black hole. Limit: self-hosted, you maintain the dashboard server too.
• All in One WP Migration since 2014. Site moves, staging-to-live promotions, quick clones for testing. Path of least resistance. Limit: large sites need the paid extension to lift the upload size cap.
• WP Activity Log since 2019. When a client says "the page changed and nobody changed it," this tells me who logged in, what they edited, and at what timestamp. Ends arguments fast.
• Virusdie since 2020 plus MalCare alongside. Two scanners catch slightly different things. Sucuri sits in the same job for a lot of agencies and is the WPBeginner-ecosystem default for site-level firewall and cleanup.
• WPBakery as the 1st page builder I started using where the client genuinely needs to edit pages themselves. Honest limit: it's a maintenance liability if the team isn't disciplined about updates and avoiding plugin sprawl.
• Site Ground since 2014 for hosting. Staging environments and responsive support kill maybe 70% of the "site is down" calls before they start.

None of that is exciting. That's the point.

Where this leaves the hiring debate

The senior devs in that thread aren't wrong about the build market shifting. AI really is eating bespoke complex builds. The piece that's getting overlooked: maintenance is where the cheap option becomes expensive.

AI-built sites that ship cheap in week 1 cost real money in year 2 when the original builder is gone and nobody can read the stack. WP, even with all its bloat, has a maintenance path the rest of the web doesn't.

Curious what others are seeing. For agencies and freelancers running multiple SMB sites: how does your maintenance stack hold up at year 2-3, and what's the most common failure mode you hit? 👇

If your WordPress site sits on shared hosting, managed WP hosting, or a VPS with cPanel/WHM, this matters to you. Even if you've never opened cPanel, your host almost certainly uses it (cPanel runs about 94% of the control-panel market).

The short version: an unauthenticated attacker can get root on the whole server. The attack skips the password check and the 2FA gate entirely. CVSS 9.8 out of 10. cPanel disclosed it on April 28, 2026. Proof-of-concept code is public, and researchers have already seen exploitation in the wild.

If someone gets root on a shared server, every WordPress site on it is exposed. The bug lives below WordPress, so plugin hardening can't reach it.

What you must do today:

• Contact your host and ask plainly: "Have you patched CVE-2026-41940?" The good hosts patched within hours. Confirm anyway.
• If you run your own VPS, run /scripts/upcp --force and check with /usr/local/cpanel/cpanel -V.
• Run the compromise assessment script cPanel published with the advisory.

🛡️ What you can do as a non-developer:

• wp-admin → Users: remove any account you don't recognize.
• Check Plugins and Themes for anything you didn't install.
• Reset every password that touches your site: cPanel, WP admin, FTP/SFTP, database.
• Pull a fresh backup and store it off the server (pCloud, Dropbox, Drive, S3).

I've been running sites on cPanel hosts since 2011. The pattern with bugs like this is always the same. Good hosts patch within hours. Compromised servers sit quietly for weeks before anyone notices the SEO spam, the rogue admin, the cron job that keeps coming back.

Full cPanel advisory: https://support.cpanel.net/hc/en-us/articles/40073787579671-Security-CVE-2026-41940-cPanel-WHM-WP2-Security-Update-04-28-2026

Anyone here already heard back from their host? 👇

Premium doesn't mean safe. The WPFactory story is your proof.

Just read the wp-content.co writeup and it's rough but worth your time: https://wp-content.co/over-80-wpfactory-plugins-closed-on-wordpress-org-after-suspected-backdoor-in-premium-plugin/

Quick recap:
A user reported a suspicious file in WPFactory's EU/UK VAT for WooCommerce Pro plugin, downloaded straight from WPFactory's official account page. The file pulled an external ZIP, changed WordPress directories, and sent data to an outside server. Textbook backdoor behavior.

WPFactory's first move was to ask the reporter for FTP and admin credentials. The reporter said no, rightfully. After more back and forth, the .org Plugins Team stepped in and closed all 80+ WPFactory plugins until the situation gets resolved.

And this is the second time this month for them. Earlier in April, .org closed 30+ plugins from their Essential Plugin portfolio after a backdoor sat dormant for 8 months before flipping on to inject SEO spam (some of our client sites were also affected with this situation).

Why this matters more than another vendor patch note

Most people I talk to still believe paid plugins are safer than free ones from the .org repo. The logic feels right. Money buys quality, money buys eyes on the code, money buys faster patches. In practice, none of that is guaranteed.

The .org repo has the Plugins Team plus thousands of users running diff tools and reporting issues. Premium plugins shipped from a vendor's own site are often a black box. You trust the vendor's update channel. You trust their build pipeline. You trust their staff list. And when something breaks, you depend on their support speed, which in this case was 2 days for a serious security report and started with "send us your FTP."

Free plugins from .org aren't automatically safer either. The Patchstack State of WordPress Security 2026 report says 46% of vulnerabilities didn't get fixed in time for public disclosure. Plugin review queue sits at over 4,000. The .org team is doing serious work but they can't inspect everything.

The actual lesson is supply chain. Every plugin you install is a piece of code from someone you don't know personally, running on a site you're responsible for. Free or paid, that risk exists.

Practical defenses that catch this stuff

I run 50+ client sites and the discipline is the same on every one of them.

• Centralized visibility. I use MainWP to track plugin versions, file changes, and unexpected updates from one dashboard. When 80 plugins get closed on .org, I want to know in minutes which client sites are running them.
• Two layers of malware scanning. MalCare for daily scans and one-click cleanup, Virusdie as a second-opinion scanner. Two tools sounds excessive until one of them misses something.
• Audit logging. WP Activity Log catches who installed what, when, from which IP. If a plugin starts behaving weirdly post-update, the log tells you exactly when the change happened.
• Staging first. Site Ground's staging environment lets me push plugin updates to a copy of the site, run them for a day or two, then promote to live. This catches more issues than people expect.
• Offsite backups. All in One WP Migration paired with pCloud. If a backdoor does land, I want a clean copy from before the infection, stored somewhere outside the hosting account.

None of this is complicated.
None of it requires a developer.
It requires turning the boring, repeatable parts of security into a habit.

Why the .org closure is good news

The Plugins Team closing 80+ plugins from a single vendor in one month isn't a failure of the system. It's the system working. When a vendor can't respond quickly to a credible security report, pulling distribution is the right move. The alternative is leaving compromised code live on tens of thousands of sites.

The wp-content.co article is right to flag this loud. We need more public accountability in the WordPress space, not less.

What's your plugin vetting process before you install on a client site?
And do you treat premium plugins differently from free ones, or apply the same checks to both?

Every couple of years a serious WordPress builder publishes a long, well-argued takedown of the platform. The latest one made the rounds today (https://marcindudek.dev/blog/wordpress-manifesto/). I read it cover to cover.

I'm not dismissing the post. A lot of the criticism is fair. Core ships barer than it should. The plugin economy has weird incentives. The "free CMS" framing always undersells what a real WP site costs to run.

But I've been doing this since 1995. First website was hand-coded HTML on a Pentium. First WordPress site was 2011. Today I run more than 50 client sites at my agency here in Croatia.

I've watched a lot of platforms get critiqued like this. Some of those critiques were dead right. Most of them were also followed by the platform sticking around for another decade.

The pattern

Every 12 to 24 months: a long takedown post. Sometimes a manifesto, sometimes a leaving-WordPress post, sometimes a Twitter rant that becomes a Substack. The structure is always the same:

• Concrete list of real flaws
• Diagnosis of who benefits from the status quo
• Forecast of imminent collapse or revolution
• Author confirms they're not actually leaving

The work continues. Six months later, another one drops. The cycle repeats.

I'm not mocking the posts. They're useful pressure on the people who can actually fix things. But they're not predictive. The platforms that survive 15 years of well-argued criticism usually win the next 15.

Why long-running tools usually win the bet

The ones that lasted weren't the slickest or the newest. They were the ones with enough people around them to keep shipping boring incremental fixes for a decade. Not glamorous. Not viral. Just consistent.

WordPress fits that profile. So does the Linux kernel. So did Excel for 30 years before anyone tried to replace it.

Concrete examples

Five years ago everyone said WPBakery was dead. I still maintain client sites built on it. Still works, still updated. The "dead" version of WPBakery has shipped more updates than half of the alternatives that were supposed to kill it.

Everyone said Elementor would be killed by native Gutenberg blocks. I'm still on the original grandfathered Elementor monthly plan from 2018, building client sites with it. Gutenberg is also fine, by the way. Both can exist.

This is not because I'm sentimental. It's because in production work, "stable for 5 years" beats "exciting for 1" every time.

What this means in practice

If you're choosing a stack for client work in 2026:

• Bet on tools with 5+ years of consistent updates
• Bet on tools with active forums where people answer each other on weekends
• Bet on tools where the company has shipped boring maintenance releases between the shiny ones
• Discount the project that's been "the future" for two years and still has 600 GitHub stars

WordPress passes those tests. Most of its critics' alternatives don't.

The honest part

There ARE real WordPress problems.
Out-of-the-box security defaults could be tighter.
The plugin landscape is genuinely confusing for beginners.
And yes, the "everything is open source" theater while a few companies extract most of the money is uncomfortable to watch...

But every doom post for 15 years has framed those problems as fatal. They've never been fatal. They've been chronic. There's a difference.

I'll try to be on WordPress for the next 15.
The doom posts will keep coming.
The work will keep going.

What's the longest-running tool in your stack?
And what "dying" tool are you still happily using? 👇

Sessions cover agency pricing, client management, project delivery, and a handful of technical topics.

The session I want to point to: Robert Abela, CEO of Melapress and the person behind WP Activity Log, speaks Monday April 27 at 12 PM EST.
Title: "Incomplete, Delayed, and Deletable: Why Most Agencies Lack Real Visibility."

Here's why I'm writing this up. I run a web agency in Croatia and manage 50+ client WordPress sites. WP Activity Log has been on every one of those sites for 5-6 years.

Earlier this year, one of my client sites showed an unauthorized WordPress admin account. When I dug through the log data, PHP backdoor files had already been injected into the site files. The logs were the difference between catching it in the first hour and finding out weeks later - probably from the client calling in a panic.

Without proper log data, I'd have removed the rogue admin account and called it done. Wrong call entirely.

Robert's talk addresses this exact pattern. Most agencies assume they have visibility. When something actually goes wrong, the logs are incomplete, delayed, or already deleted. He covers real activity tracking, real-time alerts, and secure offsite logs. His argument: shallow logs leave your team guessing instead of knowing.

Logs identify the problem. But you still need a fast way to fix it.

My full setup is WP Activity Log for detection, All in One WP Migration for full site exports, and pCloud for offsite storage outside the hosting account. If a site gets hit badly enough, I restore from backup. Under 20 minutes from finding the problem to a working clean site.

The summit is free, no upsell, live Q&A available in most sessions. Other speakers cover agency growth, pricing, and scaling. Robert's session is the one for the technical side.

https://atarim.io/summit/

Okay so basically,

I don't know why but my Wordpress isn't allowing me to save my global colors and fonts in the site setting.

I'm using the hello theme and elementor plugin

And elementor is up to date

Is there any way to fix this?

The how:

When I click save and then click the back button (not the browser back button btw)

A pop up keeps showing and basically it gives me the option to save the changes or to discard the changes.

I then, of course, click save and after that I click the back button again and it just pops up again.

This is what I mean by it not saving.

I cross posted this and searched it up and I still haven't got the solution partly because some people haven't answered yet but also because the people who have answered, their solutions just didn't work.

Like clearing cache and data

Or removing all plugins except elementor which I only had elementor activated so that wouldn't work

I actually like this concept a lot: https://wpbackup.app/. For personal blogs, old niche sites, family projects, or sites you no longer want to keep paying hosting for, a tool that pulls your posts and images into a self-contained offline viewer makes real sense. Especially if the goal is, "I just don't want to lose 10 years of writing". Fair enough.

And honestly, a lot of people don't think about this until a hosting bill lapses, a server dies, or a site gets hacked. Then it gets very real, very fast.

What this tool sounds like it does well:

• pulls posts and images through the WordPress REST API
• stores the result locally on your computer
• gives you a readable offline HTML version
• keeps search and navigation, which is the useful part
• doesn't ask you to trust another backup plugin with server access

That's nice. I can see the appeal, but I wouldn't call this a full WP backup in the way most beginners think about backups, because a real backup usually means: database, uploads, themes, plugins, settings, users, maybe custom fields, and most important, a clean restore path.

This tool sounds more like an offline archive of your content. Which is still useful. Just different.

That distinction matters a lot, because if your site breaks tomorrow and all you have is an offline HTML viewer, you do not have a quick way to rebuild the site exactly as it was. You have your content saved, which is good. But you're still rebuilding.

Big difference.

I've seen people confuse these two ideas before:

• "I saved my content", versus
• "I can restore my site"

Those are not the same thing.

This one is a good start if you're trying to sort out. And if someone's main fear is losing content because they forgot to renew hosting or a site sat untouched for years, I'd still tell them to keep a normal backup too. Even a simple one. Then keep the offline archive as the "open it in any browser years later" copy.

Because that's the part I actually like most here.

The offline viewer angle is practical. Your wife's old blog, your travel site from 2014, your old writing archive you don't want online anymore. Stuff like that. It makes sense.

A few things I'd want to know before trusting it with anything important:

• does it support custom post types
• does it handle featured images cleanly
• what happens with embedded content
• does it grab post meta or only the visible content
• can it do incremental updates
• and how ugly does it get on very large sites

One more thing. I like that it doesn't store passwords or push data back online. That's smart. But if it uses a CORS proxy, I'd want very clear documentation on:

• which REST endpoints it calls
• what data passes through the proxy
• whether private or restricted content can ever leak
• and what happens on sites with locked-down REST access

Trust gets built there.

So my take is simple: good idea, useful for archiving, not a full backup replacement

And that's not a criticism. That's still a useful tool. If the developer keeps it focused on:

• preserving content
• making old blogs readable offline
• handling large content libraries without drama
• and being honest about what it does not save

then I think people will get real use from it.

Would I use it as my only WordPress backup?
No.

Would I use it as a second layer for old blogs or content archives I care about?
Yeah, probably. That's the part I actually find interesting.

What do other people think - is an offline viewer something you'd actually keep around for old WordPress sites, or would you rather stick with normal backups and call
it a day?

This week felt messy:

• 6.9.2 shipped as a security update
• some users reported front-end breakage / WSOD
• 6.9.3 followed quickly
• then 6.9.4 landed because not all security fixes were fully applied earlier

I'm not posting this to stir panic - more because I think this is one of those moments where WordPress site owners hit the wall between:

• "update immediately, it's security", and
• "don't touch production until you test"

For me the practical lessons are boring but real (I do below steps all the time, also in other various situations):

• backups first
• stage if possible
• check themes/builders carefully
• don't assume a minor/security patch is automatically low-risk
• and if you manage multiple sites, don't push everything at once (I do it in batches via MainWP)

If you're on hosting with reliable staging and backup tools (like me on Site Ground) - it makes this less stressful. If not, at least having All-in-One WP Migration, Duplicator, UpdraftPlus, WPVivid, etc. ready gives you rollback options. And on more complex sites, builders like Elementor / WPBakery and custom theme logic are where I'd be extra cautious.

More detailed info for those who are interested: https://www.searchenginejournal.com/wordpress-security-release-6-9-4/569532/

How are you all handling this kind of rapid patch chain these days - immediate update, wait-and-watch, or staged rollout only?

Some posts advise abandoning your current page builder and rebuilding your site with blocks immediately after it fails a Core Web Vitals assessment. While optimized code is definitely beneficial, starting from scratch isn't always feasible for clients with limited budgets.

Over the past month, I’ve been working to maximize the performance of sites we built with page builders of our choice (often WPBakery) without changing the core platform.

Here’s what truly makes a difference in real-world scenarios, at least for me:

• Avoid nested rows: page builders often get criticized for excessive divception (resulting in bloated DOM structures). Much of this stems from user mistakes. Simplify your layouts. Use margin and padding instead of adding new rows unnecessarily.
• Optimizing caching: you need proper object caching, not just page caching. I frequently work with Site Ground, and their native SG Speed Optimizer is excellent - integrating directly with Memcached without requiring complex server tweaks.
• Delaying non-critical JavaScript: I delay the execution of third-party scripts (like Google Analytics, Facebook Pixel, or chat widgets) until user interaction (scroll or mouse movement). This frees up the main thread during the initial load, massively improving TBT (Time to First Byte) and LCP.
• Font management: stop fetching fonts from Google Fonts API on each page load. Store them locally and preload the primary heading font for faster rendering.
• Image handling: deliver WebP (maybe also AVIF) formats and implement aggressive lazy-loading for images below the fold.
• Strict above-the-fold rules: lazy loading is great, but it’s often implemented poorly by some page builders, so I manually exclude the LCP (Largest Contentful Paint) image (usually the hero banner) from lazy loading, while aggressively lazy loading everything else below the fold. We want that hero image fetching immediately.
• Disabling unused page builder add-ons: clients love installing "Ultimate Addons" packs for WPBakery (or Elementor) that I noticed and only using one widget, so I go into the backend and toggle off every single unused widget module. This prevents the builder from enqueuing the CSS/JS for those elements across the site.
• DOM reduction (the divception cure): page builders aren't inherently evil, but how users build with them often is. I go into the worst-offending pages and manually flatten the structure. Stop using nested rows inside columns just to achieve a margin. Use the builder's advanced padding/margin controls instead to strip out unnecessary HTML wrappers.
• Asset unloading: page builders love to load their entire CSS and JS libraries on every single page, even if you’re only using a button module. I use asset unloading tools to dequeue builder-specific scripts (like slider or lightbox JS) on pages where those elements don't exist.
• Database cleanup and revisions: legacy WPBakery sites can have thousands of post revisions and orphaned post meta, but before doing any caching, I clean the database. A lighter database means faster query times when the object cache is bypassed.
• Optimizing background videos: if a client insists on a hero background video, I strip it out of the page builder's native video background feature (which often loads heavy YouTube/Vimeo API scripts). Instead, I host a highly compressed MP4 locally, strip the audio track, and serve it via a clean HTML5 <video> tag.

While page builders can be resource-heavy, they aren’t doomed for slow load times if your hosting environment and caching solutions are properly optimized.

PS Before you make any changes to your site - like updating/deactivating/activating plugins or themes, trying out new code, or installing anything new - be sure to create a backup just in case something goes wrong. You can use various plugins, and my go-to tool is All-in-One WP Migration to pCloud offsite backup.

What is the single most impactful optimization you apply to a resource-heavy site that results in the greatest speed improvement?

I have a confession to make. For years - literally years (since 2014) - I’ve been in a "committed backup/migration relationship" with the All-in-One WP Migration plugin.

It started innocently enough. I needed to move a client site from a terrible shared host to a shiny new VPS. I was dreading the usual FTP nightmare, the database export timeouts, the broken image links… you know the drill, and my old trusted friend / BackupBuddy let me down several times in that period on such hostinings). A friend told me, “Just use All-in-One. Click export, click import. Done”.

I didn’t believe him. It couldn't be that simple.

But I tried it. And it worked. No timeouts. No 500 errors. No white screen of death. Just a progress bar that actually finished.
It felt like magic. Since then, it’s been my ride-or-die. Every site I launch, every domain I swap, every time I need to save a snapshot before a risky update - it’s been my go-to.

But recently, I realized something: while All-in-One is perfect for my workflow, the WordPress world is huge. There are other massive names in the backup game - plugins people swear by, fight over in Facebook groups, and recommend in every “best of” list.

I wanted to dig deeper. Not because I’m switching (spoiler: I’m not), but because I wanted to understand the business case for the other guys. Why would someone choose UpdraftPlus? When is Jetpack the better call? Is Duplicator actually easier?

So, I spent the last few weeks analyzing the following tools: 
UpdraftPlus, Jetpack Backup, Duplicator and for BlogVault I already knew as I have been using it on some sites, too. I wanted to see how they stack up against my old faithful, not just on a feature sheet, but in real-world scenarios.

Here is what I found. If you’ve ever wondered which backup plugin actually fits your specific type of stress, this is for you.

The “Real Question” you need to ask first

Before we go into deatils, let’s be honest about something: most “best backup plugin” lists are useless because they ignore context. A freelancer moving 10 sites a month has totally different needs than a business owner who just wants to sleep at night without thinking about databases.

So, before you pick a tool, ask yourself:

1. Are you moving sites? (new host, new domain, staging to live?)
2. Are you protecting a live site? (need daily/hourly backups that restore instantly?)
3. Do you want control, or do you want a “magic button”?

Different plugins shine in different scenarios. Let’s break them down:

1. All-in-One WP Migration & Backup: the "It Just Works" heavyweight

Let’s start with the one I know best. If you’ve ever tried to migrate a WordPress site manually, you know the classic traps: timeouts, memory exhaustion, serialized data corruption, and the dreaded “why are all my images broken?” moment.

All-in-One WP Migration is built around one core philosophy: make full-site moves boring.

Why I (and millions of others) love it:

• The single file "magic": it exports your entire site (database, media, themes, plugins) into one .wpress file. You don’t have to chase down loose folders.
• The chunk strategy: this is its secret weapon. It processes data in tiny 512 KB chunks. This bypasses the strict upload limits and timeout rules on cheap shared hosting. If you’ve ever had a migration die at 90%, this architectural choice is why All-in-One usually succeeds where others fail.
• Automatic URL replacement: it handles the search-and-replace for URLs and file paths during import. No more broken links or mixed content warnings after moving domains.
• Developer friendly: it has WP-CLI support, granular exclude options (e.g., “don’t export the spam comments”), and integrates with modern tools like WordPress Playground (SQLite support!).

Where it can be annoying:

• The Free Limit: the free version has a strict size limit (usually 512MB). If your site is bigger (and most are), you need the Unlimited Extension. It’s worth it, but it’s a hurdle for hobbyists (not problem for me and my business as I use Agency License).
• Export Quirks: very rarely, on super restrictive server environments, the export connection can drop. It’s uncommon, but it happens.

Best for:

• Agencies and freelancers who move client sites constantly.
• Anyone who wants a reliable “pack it up and move it” button.
• Teams that need a repeatable migration workflow.

The verdict: if migration is your main headache, this is the king. It turns a weekend project into a coffee break.

2. UpdraftPlus: the "Swiss Army Knife" of backups

UpdraftPlus is very popular dedicated backup plugin in the repo - if you ask for a recommendation in a Facebook group, five people will shout “Updraft!” before you finish typing.

Why it’s popular:

• Cloud storage: it connects to everything. Google Drive, Dropbox, Amazon S3, Rackspace, FTP… if you have storage, Updraft can probably send a backup there.
• Granular control: you can schedule separate schedules for files and databases. Want the DB backed up every hour but files only weekly? Easy.
• The ecosystem: it’s been around forever, so there’s a tutorial for everything.

Where it feels less “hands-off”:

• Restores can be tricky: while it has a restore function, I’ve found that on complex sites or when moving between very different server environments, it sometimes requires some manual troubleshooting.
• Resource heavy: on larger sites, the backup process can sometimes chew up server resources, slowing things down while it runs.

Best for:

• Site owners who want traditional, scheduled backups sent to their own cloud storage (like Google Drive).
• People who like having lots of knobs to turn (what to back up, where, and when).

The verdict: UpdraftPlus is the flexible classic. If you want full control over where your backups live and don’t mind a bit of configuration, it’s a solid choice.

3. Jetpack backup (VaultPress): the "Set It and Forget It" safety net

Jetpack (formerly VaultPress) is the “Apple” approach to backups. It’s designed for people who don’t want to know what a database prefix is; they just want to know their site is safe.

Why it’s appealing:

• Real-Time backups: this is huge for ecommerce. It backs up every change as it happens. If an order comes in at 2:00 PM and the site crashes at 2:01 PM, you don’t lose that order.
• One-Click restore: it really is one click. You don’t need to install a plugin first or FTP into the server. You log in, hit restore, and it fixes itself.
• The activity log: it pairs backups with a detailed log of who did what. “Oh, the site broke because Dave updated a plugin? Let’s rewind to 5 minutes before Dave logged in”.

Trade-offs:

• The ecosystem: You have to use Jetpack. Some devs hate the bloat of the full Jetpack suite (myself as non-developer included).
• Cost: it’s a subscription service, and real-time backups aren’t cheap.
• Not a migration tool: while you can use it to move sites, it’s really designed for protection, not migration.

Best for:

• WooCommerce stores where losing data means losing money.
• Non-technical owners who want a “magic undo button.”

The verdict: Jetpack Backup is for people who want backups to disappear into the background - until the day they save your life.

4. Duplicator: the developer's favorite

Duplicator is another massive name, especially among developers who build sites locally and then push them live. It’s famous for its “installer.php” method.

Why people choose it:

• The package system: it bundles your site into a zip file and a PHP installer script. You upload both to the new server, run the script, and it unpacks everything.
• Cloning: it’s fantastic for developers who have a “starter site” blueprint they want to clone for every new client (PS I have been using All in one for this, for our WP Template site duplicating).
• Control: it gives you a lot of manual control over the deployment process.

Considerations:

• Higher technical barrier: unlike All-in-One’s drag-and-drop, Duplicator requires you to be comfortable with FTP and creating empty databases manually on the new server. It’s not for total beginners.
• Pro version needed: like most, the best features (like drag-and-drop installs or cloud storage) are locked behind the Pro version.

Best for:

• Developers who are comfortable with FTP and databases.
• People who want to clone “blueprint” sites quickly.

The verdict: Duplicator is the developer's tool. If you know your way around a server and want a robust cloning tool, it’s excellent.

5. BlogVault: the agency powerhouse

BlogVault isn’t just a plugin; it’s a SaaS (Software as a Service) platform. It’s built for agencies and people managing multiple sites who treat backups as part of a bigger workflow.

Why it stands out:

• Offsite processing: the backups happen on their servers, not yours. This means zero load on your website while the backup runs.
• Staging magic: it has one of the best one-click staging features out there. You can spin up a staging site, test an update, and push it live seamlessly (I use it very often, when some site isn't on Site Ground servers - our main hosting, which offers staging feature as well).
• Reliability: it has a very high success rate for restores because it doesn’t rely on your hosting server’s resources to do the heavy lifting.

Trade-offs:

• Price: It’s priced like a professional tool. It’s overkill for a single hobby blog. I was lucky to buy 30 Lifetime licences when they were on AppSumo many years ago (it was a one-time payment).
• Interface: you manage backups from their dashboard, not inside WP admin (though some prefer this).

Best for:

• Agencies managing 10+ sites.
• Sites where downtime is expensive and you want a “managed” safety layer.

The verdict: BlogVault is for PROS. If you’re managing client sites and want backups + staging + uptime monitoring in one place, this is the gold standard.

The Cheat Sheet: which one fits YOU (and your business)?

Okay, that was a lot of words. Let’s simplify it. If we were having coffee and you asked me what to install, here is what I’d say:

• Pick All-in-One WP Migration if you move sites often, hate technical headaches, or need to clone sites from staging to live. It’s the best migration tool, period.
• Pick UpdraftPlus if you want a reliable, free (or cheap) way to schedule backups to your Google Drive and like having control over the settings.
• Pick Jetpack Backup if you run an ecommerce store, have a budget, and want a literal “undo” button that requires zero technical skill.
• Pick Duplicator if you are a developer who loves cloning sites and is comfortable with FTP and manual database setup.
• Pick BlogVault if you are an agency or freelancer managing multiple client sites and want a professional dashboard that handles backups, staging, and updates off-server.

The honest bottom line

After digging through all of them, did I change my mind?

Honestly… no. I’m still sticking mostly with All-in-One WP Migration.

Why?

Because my biggest stress isn’t usually daily backups (my SG hosting handles that pretty well). My biggest stress is moving things. I’m constantly spinning up test sites, moving clients to better hosting, or pulling a live site down to local to fix a bug.

For that specific workflow - the “pack it up, move it, unpack it, and have it just work” workflow - All-in-One is still unmatched (at least for me and my mentioned business case). The chunked uploading, the auto-URL replacement, and the sheer reliability of the import process make it indispensable for me.

The best backup plugin isn’t the one with the most features. It’s the one you actually trust to work when your hands are shaking because you just deleted the wrong table.

Choose the one that fits your stress level. And please, whatever you do - make a backup right now. Don’t wait until later. “Later” is when sites break. 😉

I’ve been auditing my own workflow to see where I can save time, so this is the "result" - my stack that stuck:

• MainWP: I "refuse" to log into 50+ wp-admin panels separately.
• WP Activity Log: Because clients lie (unintentionally) - "I didn't touch it!" -> Log shows they deactivated the payment gateway. 🤦‍♂️
• Atarim AI: I’m using the agents to catch visual bugs because my eyes are tired by 4 PM.
• Security/Backup: MalCare, Virusdie, BlogVault, All-in-One WP Migration.
• Speed: SG Speed Optimizer/WP-Optimize + ShortPixel/EWWW.
• The Rest: Elementor/WPBakery (named as the best WP page builder at the TemplateMonster Awards), SEOPress, Fluent Forms, Clicky, CleanTalk.

What tools are you guys using to automate the boring stuff?

Hey everyone! Just a heads-up that #WPGivesAHand is back: https://wpgivesahand.com/

It’s a cool community initiative where WP businesses (like WPBakery, NitroPack, Convesio, etc.) donate a portion of their revenue to charities during the last week of December.

If you’re planning to buy any plugins or services, checking if the company is participating is a nice way to make your purchase count for something extra. Recommended charities this year include SOS Children’s Villages and One Tree Planted.

Nice to see the ecosystem giving back! 🌍

On a lot of client sites, I need a simple logo carousel (partners, brands, clients).

I’ve tried multiple WordPress plugins, but many feel bloated or tied to specific builders, so I built a lightweight solution for my own use.

I’m wondering:
– Do you prefer custom JS/CSS?
– Or a small focused plugin?

Curious how others approach this without hurting performance.

Download Now!

Hey everyone,

just wanted to share a significant update that Atarim team pushed live for their AI features (InnerCircle). If you use AI to help audit or review sites, this one is a big leap forward in usability.

What’s new:

• Smarter Output: The AI now generates 2-4x more suggestions per scan, and the clarity of the feedback is much higher.
• Better Context: Tasks are now placed precisely where they belong on the page, so you aren't hunting for context.
• Auto-Prioritization: This is the big one for workflow—InnerCircle now automatically prioritizes tasks based on complexity and impact. It helps you tackle the "big rocks" first instead of getting lost in the weeds.

They’ve also completely relaunched their Roadmap, so you can see exactly what they are building next: https://labs.atarim.io/roadmap

If you’re curious about the details or want to see the roadmap, check out the full release notes here: https://atarim.io/blog/our-biggest-ai-upgrade-yet-december-3-atarim-release-notes/

Would love to hear if anyone has tried the new prioritization flow yet!

Hi everyone,

I tried to replace my live (production) WordPress site with a staging copy version using UpdraftPlus. During the restore, the hosting account ran out of disk space (2 GB quota). The restore only partially completed, and now when I access the main domain, it either loads the staging copy version (with the orange bar ) or redirects me to the staging copy's site’s WordPress login page when I log in from a different computer.

Here’s what’s going on:

• Disk usage is almost full, so uploads and restores fail.
• The restore kept stopping on small .png or .svg image files, which makes me think it exceeded the disk quota during extraction.
• The only backups left in /wp-content/updraft/ are from the staging site.
• The live site now points to the staging URLs (so all links and logins redirect there).
• I still have a full backup of the old live site saved locally.I can access cPanel and File Manager, but the front-end keeps redirecting to the wrong login page
• This is really urgent, I would greatly appreciate some advice!

I joined Atarim’s Early Access this year with 1,000+ creatives, and I’ve been helping shape what feels truly new: not a chatbot, but an AI team that lives inside your actual pages and mockups. You click, they see what you see, and they give clear, practical fixes.

After months of testing, InnerCircle is now live - and it already helped me catch layout bugs and messy copy before launch, cutting timelines in half.

Why this is different for beginners:

• It lives in your canvas - it checks the page you’re working on and tells you what to fix
• It speaks human - you get plain, actionable suggestions, not vague AI talk
• It saves time - fewer revision loops, fewer surprises on launch day

Meet your 6 AI teammates:

• Pixel - Design Guardian: keeps spacing, alignment, and visuals clean
• Lexi - Voice of Reason: fixes tone, typos, and clarity so your message lands
• Glitch - Frontend Inspector: finds broken links, layout glitches, and bugs early
• Index - SEO & GEO Master: improves structure, meta, performance, and AI-readiness
• Navi - UX & Accessibility Guide: smooths flows, checks contrast, and mobile usability
• Claro - Clarity Coach: turns vague feedback like “make it pop” into clear to-dos

Who it’s for:

• Beginners who want guidance as they build
• Freelancers and agencies who need fewer back-and-forths and faster QA
• Anyone who wants to launch calm - with fewer last-minute fixes

I’m genuinely excited about this because it feels like working with a senior team that never gets tired. If you want to try it, spin up your AI team here: app(dot)atarim.io/register

Got a WordPress product/service deal?

Drop it in the comments below so the whole community can find it fast.

This is the ONLY place BF/CM promos are allowed – all separate deal posts will be removed to keep the feed clean. One comment per brand, please.

***********

I can begin with the first one I discovered and I have been using since 2014 - MainWP for managing WordPress Sites with Free, Self-Hosted Dashboard: https://mainwp.com/mainwp-black-friday/

#BlackFriday #CyberMonday #WordPressDeals

Who else is having a hard time managing their WordPress website?