u/Imaginary_Act8664

I do takeover audits for new clients. Every single time:

• 2-4 admin accounts belonging to people who no longer work there
• A "dev@" account with a password from 2019
• Some plugin author's support account still active from when they fixed something in 2022
• Sometimes an "Administrator" role added to a subscriber, which is just chef's kiss

Everyone talks about WAFs and Wordfence and hiding wp-login.php. Meanwhile the front door is wide open because nobody audits users.

What I do on every takeover now, before anything else:

1. Export the user list, sort by role, get the client to identify every admin/editor by name. Anyone they can't name gets demoted to subscriber (not deleted you want the audit trail).
2. Force a password reset on everyone remaining.
3. Kill all active sessions.
4. Set up a simple logging plugin so I can see who logs in going forward.

Takes maybe 30 minutes. Catches more actual risk than half the "hardening" checklists floating around.

What's your first move on a takeover?

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've been refactoring a site where the main content is centered with a max width, but certain sections like the hero, testimonials, and CTA banners need to stretch edge to edge with a background color or image. The content inside those sections still needs to align with the rest of the page.

The old way I used was negative margins on the section, something like margin-inline: calc(50% - 50vw). It works but breaks when there's a scrollbar, and feels fragile.

Lately I've been trying the grid approach where the parent defines named columns:

.layout {

display: grid;

grid-template-columns:

[full-start] 1fr

[content-start] min(1200px, 100% - 2rem) [content-end]

1fr [full-end];

}

.layout > * {

grid-column: content;

}

.layout > .full-bleed {

grid-column: full;

}

This feels much cleaner. No negative margins, no scrollbar issues, and the inner content of full bleed sections can still use the same content column if you nest another grid inside.

The downside is it's a bit harder to explain to other devs on the team, and nesting gets weird if you have full bleed sections that contain content needing the same alignment.

Curious what others are doing. Are you sticking with negative margins, using the grid pattern, or something else like container queries now that support is solid? Also wondering if anyone's hit edge cases with the grid approach I should watch out for before I commit to it across the whole site.

I was about to pull in a modal library for a small project and then realized HTML has a built-in <dialog> element that handles most of what I needed out of the box.

Here's the basic setup:

<dialog id="myDialog">

<p>Hello! I'm a native modal.</p>

<form method="dialog">

<button>Close</button>

</form>

</dialog>

<button onclick="myDialog.showModal()">Open</button>

A few things I didn't know:

• showModal() automatically adds a backdrop you can style with dialog::backdrop
• <form method="dialog"> lets you close it without writing any JS
• Pressing Esc closes it for free
• Focus is trapped inside the dialog while it's open (good for accessibility)

Browser support is solid now across Chrome, Firefox, and Safari.

Curious if anyone here is using <dialog> in production yet, or are you still reaching for libraries? Any gotchas I should know about before I use it for a real project?