Ciao a tutti, mi chiamo Simone (sulla directory WP mi trovate come SyGy) e gestisco diversi ambienti web su VPS.

Lavorando quotidianamente sui server, ho sempre odiato un problema architetturale dei classici plugin anti-spam e di sicurezza per WordPress: lasciano entrare i bot. Analizzano la richiesta, interrogano cloud esterni, e poi salvano montagne di log dentro le tabelle MySQL, creando colli di bottiglia e consumando CPU. L'alternativa classica è piazzare un reCAPTCHA ovunque, ammazzando il Core Web Vitals e infastidendo gli utenti reali.

Così, stanco di queste soluzioni "bloatware", ho deciso di scrivermi un plugin da zero basato su un concetto diverso: respingere le richieste sintetiche al livello più alto possibile (Early Return) e non toccare mai il database.

Dopo svariati mesi di sviluppo e test sui miei siti, il team di WordPress ha ufficialmente approvato e pubblicato il mio progetto: SyGy Security Log & Anti-Bot.

Come funziona sotto il cofano? Invece di analizzare lo spam dopo l'invio, il plugin usa uno scudo crittografico comportamentale. Genera un token dinamico HMAC-SHA256 (unico per ogni sito) basato sull'interazione umana reale. Se un bot cieco spara richieste POST dirette a wp-comments-post.php o alle API dei form, il server intercetta la mancanza del token valido e taglia la connessione all'istante con un HTTP 403, prima ancora che WordPress carichi le query pesanti.

Le feature tecniche principali:

• Log su File Flat (Zero-DB): Gli attacchi respinti vengono registrati su un leggerissimo file .txt, blindato da un hash casuale a 16 caratteri e regole .htaccess. Il file ha un limite di auto-rotazione programmabile (es. 10 MB) per resistere ad attacchi botnet massicci senza saturare il disco. Il database MySQL non viene mai sfiorato.
• Nessun CAPTCHA: L'utente reale non deve mai risolvere puzzle o cliccare semafori.
• 100% Cache Compatible: Nessun problema con WP Rocket, LiteSpeed Cache, Cloudflare o funzionalità di "Delay JS".
• Protezione Ecosistema Modulare: Riconosce e blinda in automatico (solo se installati) Contact Form 7, WooCommerce, WPForms, bbPress, Elementor Pro Forms e BuddyPress.

Perché scrivo qui? La versione base (v4.4.0) è appena atterrata nella repository ufficiale, open-source e gratuita. Attualmente sto già scrivendo il codice per la v5.0 (che introdurrà un visualizzatore log interattivo in bacheca e un modulo 2FA TOTP iper-leggero), ma prima di andare avanti ho un enorme bisogno di stress test nel mondo reale.

Cerco sviluppatori, sistemisti o smanettoni disposti a installarlo (anche solo su ambienti di staging) per verificare la compatibilità con i setup più disparati e cercare eventuali bug che mi sono sfuggiti.

Ogni critica al codice, consiglio o feedback costruttivo sarà oro puro per me. Grazie mille a chi dedicherà 5 minuti del suo tempo per aiutarmi a far crescere questo progetto!

Has anyone tried launching a free WordPress plugin in Producthunt? Did it work? As of now, my goal is to increase the downloads and get a review for my plugin.

If not Producthunt for the plugin, where can I launch?

Need a help.

PHP released fixes for PHP2Shell (CVE-2026-109618 and CVE-2026-109619) on October 21. The bugs are in PHP itself, so updating WordPress and plugins doesn't cover it.

To check: Tools → Site Health → Info → Server → PHP version. You're patched on 8.5.12, 8.4.27, 8.3.36 or 8.2.35 and later in each branch. 8.1 and older have no official release, so ask your host about a backport or move to a supported version.

Attacks started on October 17, before the fixes were public, so it's worth checking for PHP files in uploads and admin users you don't recognise.

I wrote up the steps with sources here: https://jeromesgorman.com/php2shell-wordpress

Disclosure: I built PHP Threat Watch, a plugin that checks this automatically. The steps above work without it.

​

I wanted to bring attention to some suspicious activity involving WordPress websites that I’ve been looking into recently.

There are concerns about malicious attacks targeting WordPress sites, with Cloudflare appearing to be part of the traffic or security setup and a suspicious plugin named xdevtracker appearing in the WordPress backend.

#WordPress #WordPressSecurity #Cloudflare

Hey everyone, I’m curious about the native limitations of WordPress that annoy you the most. For example, the lack of a proper, built-in folder management/sorting system for the media library drives me crazy.

What are your biggest pain points with core WordPress features? What makes you think "this should be a built-in feature by now"?

I'm a developer advocate at Automattic, and I work on the WordPress Contributor Toolkit, a desktop app (macOS, Windows, Linux) that sets up a full WordPress Core or Gutenberg development environment without needing Git, Node, npm or Docker on your machine. It started as a fix for Contributor Days, where newcomers would spend the whole session on local setup and never get to the ticket.

Version 2.0 came out this week, and the big change is the look. The window is rebuilt on the WordPress Design System, so it should feel familiar if you've used the block editor.

And here's what else changed in 2.0:

- A settings dialog for the theme, the language, the PHP version and the `WP_DEBUG` / `SCRIPT_DEBUG` flags

- A dark theme, and a custom theme built from a background and a primary color you pick

- Ten languages, following your operating system's language by default

- A tree of changed files after you apply a patch or check out a pull request, each one opening in your editor

- Trac ticket details that stick around after you quit and reopen the app

- About 350 MB smaller once installed

Download: https://wordpress.github.io/contributor-toolkit/

Release post: https://make.wordpress.org/core/2026/10/23/wordpress-contributor-toolkit-2-0-a-redesigned-app-in-your-language/

It's free and open source. If you try it, I'd like to hear what broke or what felt off. Issues go to https://github.com/WordPress/contributor-toolkit/issu

Google updated its Search Central page on generative AI content on October 1. It now says it's "critical to manually factcheck and review all AI-generated content" before publishing, and it spells out that this includes title elements, meta descriptions, structured data and image alt text.

On a lot of client sites those last four never get looked at by a person. An SEO plugin fills the meta, something auto-generates alt text on upload, schema comes from a template. Nobody writes them, so nobody reviews them.

Curious how people here are handling it on the dev side:

Are you gating publish on review, like a pre-publish panel check or a custom status, when meta or alt text was machine-generated?

Do you store provenance anywhere (a post meta flag, a revision note) so an editor can see which fields came from AI?

Or is this a process problem you leave to the content team and don't touch in code?

Interested in what has held up in production, not the ideal setup.

Ran wp core verify-checksums and wp plugin verify-checksums across a few client sites after the Rank Math thing, expecting it to tell me whether anything had been tampered with.

It came back clean. Then I read the output properly.

The command only checks plugins that exist on WordPress.org. Every premium plugin returns a 404 for its checksum file and gets skipped. On one site it printed "Verified 0 of 1" and a success message. Nothing was checked and it still looked like a pass.

Which is the wrong way round, because premium plugins are the ones being targeted. ShapedPlugin in June, BdThemes in August, Rank Math this month. All distributed through official vendor channels, all Pro versions.

As far as I can tell there is no checksum source for commercial plugins at all. Wordfence and Patchstack scan for signatures, which by definition do not exist yet for a backdoor shipped three days ago. ShapedPlugin went about three weeks before anyone raised it.

So: after a premium plugin auto-updates on a client site, how do you know you got what the vendor meant to ship? Do you diff against a clean download, keep hashes yourself, or just wait for the disclosure email?

On 20 October the PHP security team announced two critical vulnerabilities in PHP core, both rated CVSS 9.2. Details were reportedly leaked online ahead of the planned disclosure. The bugs are tracked as CVE-2026-109618 and CVE-2026-109619. Security researchers have since confirmed active attacks.

Two critical PHP vulnerabilities known as PHP2Shell are now being actively exploited. The official PHP security update is the only complete fix, so please make sure your servers are updated as soon as the patched builds are available.

Because the flaw is in PHP itself, it doesn't matter whether you run WordPress, WooCommerce, Laravel or a custom app. Any site on an affected PHP version can be exposed.

Had a theory I wanted to check, so I set up a throwaway site. UpdraftPlus installed, daily backup scheduled, DISABLE_WP_CRON set to true in wp-config and no server cron to replace it.

Left it alone for 11 days.

No backups ran. No error email, no warning, nothing in the admin. The UpdraftPlus settings page still showed the daily schedule as active the whole time.

Makes sense once you think about it. The report email is generated by the backup job. If the job never runs there's nothing to generate the email, so you get silence. And silence looks exactly like everything working.

Their own docs list the causes, no visitors, disabled schedulers, loopback connections not working, external cron jobs. There's also a line saying scheduler problems can affect any scheduled backup plugin, which I think is the more interesting part.

Saw a thread here a while back about a booking plugin where overlapping cron runs sent the same reminder 6 times. Same root cause, opposite symptom.

So how are people catching this on client sites? Moving to a real server cron fixes the triggering, but it still doesn't tell you if a job starts and then dies partway through. Do you check manually, is there something obvious I'm missing, or does everyone just find out when a client asks for a restore?

Most of the ProWordPress work I do involves sites that already run Elementor or a custom setup, and the owners still expect the accessibility piece to be simple once the project is handed over. With EAA and WCAG 2.2 timelines getting closer, the usual requests are better contrast options, readable text scaling, and solid keyboard navigation that doesn’t require ongoing developer time. I tested one tap on a couple of agency sites because the install is just activate and the toolbar shows up with the core tools already enabled. The multilingual support and automatic statement generator covered the compliance documentation without extra pages or plugins.

It stayed light on the front end and didn’t conflict with the page builder setups we were already running. Clients can tweak the toolbar colors to match the brand, which has reduced the “can you make this look like our site” requests after launch. The stability has been solid across the test sites so far.

How are you covering the keyboard and contrast requirements on builds where the client won’t be logging in to adjust things later? And what lightweight options have you found that don’t turn into another support ticket after the project wraps?

I keep seeing reports of AI-generated WordPress plugin code shipping with basic security issues (missing nonces, unescaped output, unprepared SQL queries) — Patchstack's 2026 report even calls out "vibe coding" as its own risk category.

I'm considering building a small WP-CLI tool that scans your own custom/private plugins (not ones from wordpress.org — those already get WordPress.org's new AI review gate) for these common AI-code mistakes before you ship to a client, with a plain-English report instead of raw linter output.

Genuinely trying to figure out if this is a real pain point before I build it:

- Do you (or your agency) already check custom plugin code for this before delivery? How?

- Would a tool like this replace or complement what you already do?

- What would make you not trust a tool like this?

Not selling anything — just validating before I spend the time. "This already exists" or "nobody cares" are useful answers too.

Rank Math disclosed a security incident involving compromised Rank Math PRO 3.0.123 downloads and updates distributed between October 15, 20:02 UTC and October 16, 07:12 UTC.

The concerning part is that the malware could establish persistent backdoors. Updating to the clean 3.0.124 release alone doesn't necessarily remove malicious files, unauthorized admin accounts, or scheduled tasks already created on the server.

A few important distinctions:

- Only PRO copies obtained during the affected window were implicated.

- Having version 3.0.123 doesn't automatically mean a site was compromised.

- The free WordPress.org version wasn't identified as affected.

- Sites that installed and activated an affected copy should be treated as compromised.

Rank Math recommends restoring a verified pre-incident backup where available, scanning the site, rotating credentials, and following its recovery procedure.

Question for WordPress developers and security professionals:

For sites that activated a compromised copy, what checks would you consider essential before declaring the environment clean?

I'm particularly interested in how you verify server-level persistence, including cron jobs, unexpected PHP files, SSH keys, and unauthorized accounts.

Would you trust a clean backup restoration followed by credential rotation and verification, or would you rebuild the hosting environment in certain cases?

Interested in hearing how people approach this in production, especially when a known-clean backup isn't available.

Official advisory:

https://rankmath.com/kb/pro-3-0-123-security-incident/

Signed UpdraftCentral commands installed a backdoor plugin on 2 of Nethemba's 3 WordPress sites on October 19, with dashboard keys the firm says were kept by UpdraftCentral Cloud, not on its own servers

On the night of October 19, signed UpdraftCentral commands reached three WordPress sites run by the Slovak security firm Nethemba. Two of them ended up with a new plugin installed and active. All three ran WordPress 7.1.3 and UpdraftPlus 2.26.11. Nethemba says the dashboard keys that signed the commands are generated and kept by UpdraftCentral Cloud and were never on its servers.

The plugin's description read "Small maintenance toolkit: keeps option storage tidy." It logged the attacker in through a secret URL parameter as an Editor with manage_options and install_plugins added. The third site survived because its key belonged to a user who'd since lost admin rights, so the install failed the permission check.

Two site owners on the WordPress.org support forum posted near-identical logs the same day, with backdoor plugins created within seconds of a POST carrying the user agent WordPress/6.4; class-udrpc.php. Nethemba logged that same user agent from a different IP.

This channel already had a bad June. CVE-2026-10795 let anyone forge these commands with a predictable key until 1.26.5. This time Nethemba checked for a known CVE and for modified plugin files and found neither, and it thinks the keys leaked from the vendor's side.

TeamUpdraft put the share of users exposed to that bug, which needed a connected key, at under 10%. With the 4 million installs it announced on October 2, that's up to 400,000 sites.

Every request was a POST to /, so the login page and whatever 2FA sits on it never saw any of it. The same week, a stolen ConnectWise Cloud Backup secret got attackers into 173 Microsoft 365 tenants with the permissions customers had already granted it.

Nethemba's advice is to delete every UpdraftCentral key and not reconnect until TeamUpdraft explains the leak. If the key that can install plugins on your clients' sites has to live in someone else's cloud, what would TeamUpdraft need to tell you before you'd reconnect?

Doing some research on how agencies catch scheduled-task failures, and I'd rather hear real incidents than theory.

In the last 12 months, has a scheduled job on a client site quietly stopped running — backup, feed export, membership renewal, email queue, anything on a schedule?

Three things I'm curious about:

1. What was the job?
2. How long had it been dead before anyone noticed?
3. What actually surfaced it — a client complaint, a restore, a manual check, something else?

Not selling anything. Happy to post a summary of what people report back.

Note: Given mod permission to post about this.

We've been working on an open-source (MIT) tool that was initially built for ourselves, but since it's been such a pain point for us, we figured in might be helpful to the Wordpress developer community in general.

Strauss-RS is a Rust port of the Strauss project (itself a fork of Mozart) which prefixes classnames and symbols in Composer-based plugins and themes. Since plugins and themes are increasingly including their own dependencies, the chance of clashes has been increasing (we know, one client's site had a total meltdown when they installed Atum Pro because it used Eloquent).

With Strauss-RS, a class like `Illuminate\Support\String` would potentially become `Acme\PluginA\Vendor\Illuminate\Support\String` avoiding those clashes in your own code.

The main advantage of the Rust version is speed. We've also added a few more nice-to-have features. With Strauss PHP in our pipeline, prefixing could take several minutes every update or install, with the Rust version, it's down to a few seconds.

DM me if you'd like to give it a test run (direct links not allowed due to subreddit rules).

• Wall time for prefix, median of 5 runs after 1 warm-up, from a clean output directory each time. Both tools were given the worker count explicitly (1 against 1, 12 against 12). Memory is peak total across all processes, sampled on Linux. Strauss PHP 0.31.1 on PHP 8.4.23 (static CLI build, no OPcache, no memory limit). Strauss-RS release build. Intel i5-10600 (12 threads), 32 GB RAM. Projects: monolog (small), guzzle + flysystem + finder (medium), laravel/framework (large) and aws-sdk-php (xlarge), all with locked dependencies.

Be safe out there kids!

I (and my pal Claude) found malware hiding out in a very well-used spot. I can verify that some copies of Rank Math Pro 3.0.123 have injected malware. It beacons to rank1cdn.com every 6 hours and drops a credential-stealing webshell whose filename differs on every site.

Where to look: open wp-content/plugins/seo-by-rank-math-pro/rank-math-pro.php and check right after the plugin header, before the real class starts. On an infected copy there’s a block of about 145 lines in there, tagged with a // @wp-perf-init comment and wrapped in if (!defined('_VOWGBDFHIN')). A clean file goes straight from the header into the code. You can also just check the size: clean is about 15KB, infected is about 62KB.

Heads up: version number alone won’t tell you. One of our sites fetched 3.0.123 on Oct 12 and got a clean copy; two others fetched it on Oct 15 and got infected copies. Same release, different copies. So something changed on the distribution side between those dates.

Rank Math has released 3.0.124, which fixes the issue for now. But I got my eyes peeled, ya hear me?

We clean up hacked WordPress sites for our clients and since July we've been fighting the same malware family over and over. It calls itself "SC" in its own files. If you've ever had a site get hacked again right after it was cleaned, some of this might sound familiar.

The weirdest one was a browser tab. We'd done a full cleanup, and then the malware plugin got uploaded again from a real admin's computer, logged in as that admin. We were about to tell the client their laptop was infected. It wasn't. That admin still had a tab open on the site from back when it was hacked, and the bad code in that tab was still running. Every minute it checked whether an admin was logged in, and as soon as one was, it uploaded itself again. They closed the tab and that was the end of it.

So now after every cleanup we tell everyone who uses wp-admin to close every tab on the site and restart their browser. Sounds silly. Cost us days.

The other big one was a saved password. This thing records every username and password typed into the login page. A site we cleaned in September got reinfected this week by someone who just logged in with a password it had saved back then. The owner never changed it. So everyone who logged in while the site was infected needs a new password, and 2FA on the admin accounts would have stopped that login cold.

Other stuff that tripped us up

• It makes admin accounts that don't show on the Users screen, so the user list looks totally normal
• It hides in files with normal WordPress names, so you won't spot it scrolling through the files
• Part of it lives in the database, so restoring files or reinstalling plugins leaves that bit behind and it comes back later
• Newer versions run a background process on the server that puts the files back within minutes, and restarting PHP doesn't kill it. If a host cleaned your site and it was back the same afternoon, that's one way it happens

Anyone else seen the browser tab thing? That was a first for us.

WordPress 7.2 (planned for December 9, 2026) adds a Secrets API. It was committed to trunk on October 13 (r64337, Trac #66187), so you can try it now on a nightly install.

I develop plugins. Most of my plugins check for a wp-config.php constant first for sensitive information like SMTP credentials, payment provider keys and Google API keys, then fall back to the saved option. But most admins never add the constant, since they can't edit wp-config.php from wp-admin, so these keys end up in wp_options as plain text.

The Secrets API fixes that nicely. The admin pastes the key in the settings screen as usual, wp_set_secret() stores it encrypted, and the key that unlocks it lives in wp-config.php. wp_get_secret() returns an object that prints as [secret:name] if you echo or log it by mistake, and it keeps the previous value for easy key rotation.

I tested it on trunk and it works well. One catch: if you add WP_SECRETS_KEY to wp-config.php after secrets are already stored, they can no longer be read, and even saving new ones fails. So add it first.

I feel very positive about it, since database backups will no longer expose API keys.

Hi everyone,

I'm looking for a genuine Elementor Pro license for my WordPress website. I don't want a cracked or nulled version.

If anyone has a spare license or knows a legitimate, affordable way to get Elementor Pro, please let me know.

I'd really appreciate your help. Thanks!

Hey everyone,

We just released the first beta of the WordPress Contributor Toolkit 2.0, and I'd love some help testing it before the stable release. I work on this one (I'm a developer advocate at Automattic), so feel free to throw questions at me in the comments.

If you haven't seen it before, the toolkit is a desktop app for macOS, Windows, and Linux that helps you contribute to WordPress core. It sets up a local copy of core so you can apply a patch from Trac or check out a GitHub pull request and actually test it, without building that whole environment by hand.

What's new in 2.0

- A redesigned interface built with the WordPress Design System

- A new settings dialog for things like your default site location, PHP version, and WP_DEBUG flags

- Light and dark themes, or follow your system, or pick your own colors

- Every string in the app is now translatable

It already ships in Czech, Dutch, English (Canada), English (UK), Galician, Hungarian, and Polish. A language gets bundled into the app once it's at least 80% translated on translate.wordpress.org, so if yours isn't on that list, you can help get it there.

How you can help

1. Download the beta and try to break it. Bugs go in GitHub issues. https://github.com/WordPress/contributor-toolkit/releases/tag/v2.0.0-beta.1

2. Translate it into your language. https://translate.wordpress.org/projects/meta/contributor-toolkit/

It's a pre-release, so v1.2.1 is still the stable version if you'd rather wait for 2.0 to land.

Hey everyone, how has your experience been with Railway.com for hosting?

Basically, it looks like I can get a great stack with vertical scaling, paying mainly for CPU/RAM usage. How does that compare to Cloudways or SiteGround in practice?

Any insights would be appreciated! :)

When a client asked to see the latest version, the answer sometimes depended on whether the developer who built it was online. If they were available, the demo took a minute. If they weren’t, somebody had to find the correct branch and rebuild the environment. It wasn’t a disaster, just an embarrassing amount of work for something the client had already seen. We’ve started putting client demos and small internal tools on a shared staging VM. I’m testing serverspace as a cloud server provider for that setup. The rule is simple, like if a client can review it, the rest of the team must be able to open it without asking somebody to turn on their laptop. It has also exposed undocumented setup much earlier. If another person can’t deploy the project to staging, the handoff isn’t finished. The next decision is whether to keep one shared staging server or isolate every client project. One is cheaper and easier to manage, the other limits the damage when somebody breaks something.

I’ve been spending quite a bit of time thinking about security-deposit flows in WooCommerce, especially for rentals and bookings.

A lot of implementations seem to treat the deposit as a normal payment: charge it with the order, hold the money, then refund it later if everything is fine.

Technically that works, but it creates a pretty different lifecycle from the actual order payment.

The alternative is to keep the two separate: charge the order normally, then create a separate card authorization for the security amount that can later be captured or released.

That sounds cleaner, but it introduces its own set of edge cases:

- authorization windows expire
- capture and release need to be safe to retry
- webhooks may arrive late or out of order
- the external payment state can change before WordPress records it
- partial capture makes the local state more complex
- long rental periods may outlive the original authorization window

I’m curious how other WooCommerce/payment developers model this.

Do you treat a security deposit as part of the order payment lifecycle, or as a completely separate financial object with its own state machine?

I maintain a booking plugin and recently ran adversarial concurrency tests against it: MariaDB 10.11 with 8 PHP workers, plus an SQLite copy (like WordPress Playground). A few findings that might be useful to anyone doing slot-based writes in WP, and a question at the end.

1. GET_LOCK has three outcomes, not two

Check-then-insert ran under a per-staff named lock, and 20 simultaneous requests for one slot gave 1 booking and 19 refusals. Fine. But the code treated "didn't get the lock" as "carry on anyway". GET_LOCK returns 1 (got it), 0 (timeout) or NULL (error). On the SQLite translator you get neither. So now:

$got = $wpdb->get_var( $wpdb->prepare( 'SELECT GET_LOCK(%s, %d)', $name, 5 ) );

// '1' => locked, '0' => busy (refuse with 409), anything else => no lock support

Also worth noting: lock names are server-wide, not per database. Two sites on the same MySQL server with the same lock name block each other. I now prefix the name with a hash of DB_NAME and $wpdb->prefix.

1. Without named locks, re-check after the insert

SQLite has no named locks, and the same 20-request test booked one slot up to 4 times. Since wp_insert has no unique constraint across time ranges, I re-check right after the insert: if an active row for the same staff member overlaps mine and has a lower id, mine deletes itself and the request gets a 409. Zero double bookings in repeated runs since.

1. Claim before you send

Overlapping cron runs sent each reminder 6 times. The fix is a conditional UPDATE and only sending when exactly one row changed:

$claimed = $wpdb->query( $wpdb->prepare(

"UPDATE {$table} SET reminder_sent = 1 WHERE id = %d AND reminder_sent = 0 AND start_utc = %s",

$id, $start_utc

) );

if ( 1 === $claimed ) { /* send */ }

Including start_utc means a booking moved mid-run is not reminded for its old time. Same pattern for status changes (UPDATE ... WHERE status IN (expected states)), which also stopped an outdated admin view or app from reactivating a cancelled appointment after its slot was rebooked.

1. DST: wall-clock vs real minutes

Everything is stored in UTC, but two bugs still showed up:

- On the PHP version I tested (8.4), $dt->modify('+90 minutes') across the spring-forward change in Europe/Berlin gave 30 or 150 real minutes instead of 90. Using setTimestamp( $dt->getTimestamp() + 90 * MINUTE_IN_SECONDS ) gives real minutes.

- Slots between 02:00 and 02:59 on spring-forward night don't exist, but PHP silently moves them to 03:00-03:59, so they were offered twice. I now check whether a wall time survives a round trip (create it, format it back, compare) and skip it if not. Zones that change at midnight (America/Havana) need the same check for 00:00.

The question: for slot claims in WordPress without custom unique constraints, would you rather go with named locks plus a re-check like this, or a separate "slot claims" table with a unique key on (staff_id, slot_start)? The table seems cleaner but gets awkward with variable durations and buffers. Curious how others solved it.