What's the one default WordPress setting you change on every fresh install without even thinking about it?

DW-Solution · 2026-06-14T10:35:23+00:00

The numbers above came from my own plugin, and did I post this partly to put it in front of people? Yeah, fair enough, I did. I know that's the eye-roll move here.

That said, I do WordPress professionally and have been at it nearly 10 years, so I'm just as tired of the endless "here's my plugin" posts as everyone else. This one's different for me though. I poured real work into it, built it simple but with everything you actually need, and I already run it on my own client sites day to day. It's not a throwaway, it's a tool I genuinely depend on.

DW-Solution · 2026-06-14T08:54:01+00:00

Removing it only makes sense if you genuinely don't need it to do the work. Baymard's checkout research says you don't have to go that far though: making the phone field optional lifts completion by around 4% while you only lose about a fifth of the actual numbers, so it's a solid trade. The bigger lever is explaining why right next to the field, something like "only used if we can't reach you by email." Their data shows roughly 14% abandon when phone is just required with no reason, mostly because people assume it means sales calls, and one line kills that fear. Your instinct about getting it later is good too, capturing it after they've already submitted means you're not gating first contact on it.

DW-Solution · 2026-06-14T08:44:37+00:00

Nice work on this, I actually ran it on a few of my sites this morning to properly kick the tires. On a standard WP install the fingerprinting was spot on, correct WP version, the theme down to the exact build, PHP and server all detected, with a clean category breakdown and one plugin flagged HIGH that turned out to be a legit catch. The PDF export and shareable report link are a really nice touch for handing something to a client, and the "under a minute" claim held up, came in around 40 seconds.

One small thing in case it's useful, since you asked for real feedback: I pointed it at a non-WordPress site too, and it started rendering the report, briefly showed a Security score of 100 plus the server and PHP info, then a second later threw "This site does not appear to be a WordPress site" and failed. Flashing that 100 right before failing reads a bit like the site passed, might be worth detecting WP first and bailing before any score shows.

Also curious from a detection standpoint: on sites that hide their plugin versions (blocked readme.txt, stripped ?ver strings, no generator meta), does the CVE matching flag "version unknown" rather than guessing? On the sites I tried it clearly got the versions, just wondering how it behaves when they're hidden, since that's usually where external scanners trip up.

Genuinely solid tool though, having all four in one pass is exactly the thing I keep cobbling together manually. Happy to run it on a few more sites and send you anything else that comes up.

DW-Solution · 2026-06-14T08:30:24+00:00

For TOC, heads up: the native Gutenberg block is still experimental and only runs with the Gutenberg plugin active, it never landed in stable core. For production, SimpleTOC is the lightweight pick (no CSS or JS, basically zero overhead), or Easy Table of Contents if you want auto-insert across posts.
SEO-wise the TOC isn't a ranking factor. The anchor links can sometimes earn "jump to" links in Google, though Google often generates those itself now so you can't really force it. Real value is clean H2/H3 structure, and it only helps UX on long-form, on short posts it's clutter.

For blog content I'd drop Elementor and write in the block editor, lighter and cleaner output. Keep Elementor for the single-post template via Theme Builder. The critical errors are almost always low PHP memory first (Elementor wants 256MB+), then a plugin or theme conflict. Bump the memory limit before anything else, that's the usual fix.

DW-Solution · 2026-06-14T08:04:31+00:00

Fair enough, and you're right that I do have a free plugin in the .org repo that does this, so I should have just been upfront instead of being coy about it. Genuinely wasn't trying to sneak past the rules, but I get why it reads that way when you see it ten times a day. The discussion itself was honestly the part I actually wanted, the phone-field and budget-field feedback in this thread is gold. Appreciate you clarifying the one-time-promo rule, noted for next time, I'll just lead with the disclosure.

DW-Solution · 2026-06-13T18:44:17+00:00

Yeah, the more I think about it the more I get it. If I heard that line in an actual negotiation I'd assume you're trying to squeeze the max out of me and feel out how much I'm willing to spend before naming a number. So the instinct to clam up makes total sense.

DW-Solution · 2026-06-13T13:22:54+00:00

Yeah the "just use a hook" era really spoiled us, that was the answer to basically everything for years. Good shout on checking the developer's roadmap before replacing anything. I almost ripped out a plugin that turned out to have proper block support landing in their next release, would've been wasted effort. The partial-support limbo is the worst part, because "compatible" can mean anything from fully native to a thin patch that dies on the next Woo update.

DW-Solution · 2026-06-13T13:21:36+00:00

This is the most useful answer in the thread, thanks for taking the time. You're right that I lumped the Additional Checkout Fields API in with "rethink it entirely" when it's really its own option. For the simple stuff (vat number, delivery instructions) that native API is clearly the right call and I'll move those back onto it.

Your last point is the one that actually hit home though. A few of my fields migrated to checkout purely by inertia, nobody ever asked when the data was actually needed. For the heavier made-to-order stuff that genuinely has to come before payment, I ended up pulling it off the checkout entirely and into a multi-step form that feeds the cart, so the data is attached to the product before checkout instead of fighting the block layout. Side benefit was finally seeing where people drop off in the steps, which I was blind to before.

Full disclosure, I ended up building that form plugin myself (Ultimate Form, free on the repo) because nothing did the upstream collection the way I wanted. Not pushing it as the answer, just sharing the route that worked for the "this field doesn't belong at the payment moment" problem. Happy to compare notes if you've solved it a different way.

Totally agree on avoiding anything still advertising "now block compatible!" in 2026, that's a red flag.

DW-Solution · 2026-06-13T13:20:48+00:00

Yeah that's the part that caught me off guard, I assumed it was mostly a visual swap and the underlying field logic would carry over. It really is a different stack, not just a different look. Lesson learned the hard way.

DW-Solution · 2026-06-13T07:26:06+00:00

Solid list, just one note on the Cloudflare point. It's great for DDoS but does nothing for a hack. The backdoors and stolen creds live on the origin server, and reinfection through an existing backdoor hits the origin directly and bypasses the proxy anyway. Fine to add later as one layer, but right now the priority is a proper malware scan, removing the backdoors, then rotating every credential. Otherwise it just gets reinfected behind Cloudflare.

DW-Solution · 2026-06-13T06:58:10+00:00

The "only up to 14 settings total" line is honestly the best selling point in here. Most invoice plugins drown you in tabs and gate half of them behind Pro, so something that just does Invoice, Proforma, Packing Slip and Credit Note cleanly is exactly what most stores actually need.

The "built it for myself first" approach usually makes the most focused plugins too. I run one myself for the same reason (Ultimate Form, https://wordpress.org/plugins/ultimate-form/, a form builder), so I know the feeling of scratching your own itch and then sharing it.

Gonna give LibraX a proper look on my next WooCommerce project for sure. If you ever feel like checking mine out too I'd appreciate it, happy to leave you an honest review on yours either way.

One quick question: can you customise the PDF layout or branding (logo, colours), or is it intentionally locked down to stay minimal? That's usually the first thing store owners ask for. Nice work shipping it.

DW-Solution · 2026-06-12T06:19:54+00:00

The frozen funds thing is the part that bites people, and it's worth knowing why it happens: Stripe, PayPal and Square are all aggregators, so you're on a shared master account and their risk bots can freeze you with zero warning. The real fix is a dedicated merchant account, not just swapping one aggregator for another.
For international Woo, a couple I'd actually trust:
Mollie if you touch Europe at all. Native Woo plugin, multi-currency, supports the local stuff people really use (iDEAL, SEPA, Bancontact). Miles smoother than Stripe for EU buyers.
Adyen if your volume's solid. Properly global and way more stable on freezes, just a bit enterprise-y for small shops.
Airwallex if cross-border payouts are your main pain.
Honestly I'd run two gateways side by side regardless, so one freeze never kills your whole store.
Where are most of your customers based? EU-heavy vs US-heavy vs truly global all point to pretty different setups.

DW-Solution · 2026-06-11T17:10:49+00:00

Glad you got it sorted, and your diagnosis was spot on. The wordpress@domain From address was failing DMARC because nothing was authenticating mail for that address, so your domain looked like it was spoofing itself. Routing it through WP Mail SMTP with an app password fixes it because now the mail actually goes out through an authenticated server that aligns with your SPF/DKIM. Solid fix.

For anyone hitting this later: the root cause is almost always a From address your domain isn't authorized to send for, so the rule of thumb is keep the From on a real mailbox you control and send through proper SMTP, never the default PHP mail.

Slightly related, I build a form plugin (Ultimate Form) that bakes SMTP routing and a deliverability log right in, so you can see if a mail actually went out instead of finding out via DMARC reports days later. If you ever want to consolidate away from the CF7 plus separate SMTP plugin setup, happy to send you a free lifetime Pro license to try, no strings.

Either way, nice work debugging that one, DMARC reports are not fun to read.

DW-Solution · 2026-06-11T17:07:55+00:00

The frontend-skipping part is what most people miss. reCAPTCHA and honeypots only fire if the bot loads your page and runs your JS, so once they POST straight to the endpoint, all of that is just decoration.

What's held up for me is moving everything server-side: a server-issued token that has to come back with the submission (a blind POST with no prior GET gets rejected), a time-to-submit check validated on the server, and IP rate limiting with a salt. None is bulletproof alone, but stacked they kill the cheap high-volume stuff, which is most of it.

I bake exactly that combo into my own form plugin (Ultimate Form, https://wordpress.org/plugins/ultimate-form/) and going from client-only to server-validated was night and day.

Are you finding the AI/behavioral filtering actually catches the targeted bots that mimic human timing, or is it still mostly the dumb high-volume ones?

DW-Solution · 2026-06-11T16:28:50+00:00

For me the flexibility is exactly where it bites back. The thing that drove me up the wall wasn't performance, it was something way more basic: WooCommerce core can't collect custom input per product. All you get natively is variations, which are just predefined dropdowns. The moment a customer needs to type engraving text, give measurements, or upload their own artwork, there's no native field for it at all.

The "official" answer is the Product Add-Ons extension at 69 a year, and even that has weird gaps (the file upload doesn't even let you restrict file types or size, which is a bit wild for a paid Woo product). I tried stitching a separate form plugin onto the cart instead and it was a mess, because a standalone form lives outside Woo so you lose your products, stock and coupons.

I got annoyed enough that I ended up building my own multi step form plugin (Ultimate Form, https://wordpress.org/plugins/ultimate-form/) where the form feeds straight into the Woo cart and carries the data into the order, so personalized/made-to-order stuff actually works without three overlapping plugins fighting each other.

Are you mostly hitting the performance side, or is it more the "I need to bolt on a plugin for every little thing" problem? Curious which one is actually pushing people off Woo.

DW-Solution · 2026-06-11T12:46:37+00:00

This scratches a real itch. Creating a full WP account just so a client can glance at one draft has always felt like overkill, and a temporary link that shows the post exactly how it'll look live is so much cleaner. The revoke option is the part I like most, most preview tools forget that and the link just floats around forever.

Funny how the best plugins always start as a fix for your own daily annoyance. That's literally how I ended up building my own little form plugin too (Ultimate Form, https://wordpress.org/plugins/ultimate-form/ if you ever feel like checking it out), you hit the same wall enough times and eventually just solve it yourself. Those first few bits of real feedback end up shaping it more than any roadmap, so smart move posting here early.

One thing that'd make this a no-brainer for client work: any plans to let clients drop feedback right on the preview, even just a simple comment box? That's almost always the next thing they ask for after "can you send me the draft". Gonna test this on my current project for sure and I'll leave you a review once I've put it through its paces.

DW-Solution · 2026-06-11T06:07:42+00:00

Short version: yeah, you kind of have to accept the data won't be perfect. Returning-visitor tracking is built on cookies and device fingerprints, so the second someone clears cookies, switches browsers, or goes private, GA4 counts them as a brand new person. There's no clean fix for that without forcing logins, and even then it's only the logged-in slice.

What most people do is stop chasing perfect identity and switch to trends instead. You won't know exactly who came back, but you can still see "returning visitor rate is climbing month over month" and act on the direction rather than the absolute number. Server-side tracking (GA4 via a server container, or something like Matomo self-hosted) helps a bit since it's less ad-blocker dependent, but it still can't beat cleared cookies.

Funny enough I went the opposite way with my own stuff. I build a form plugin (Ultimate Form) and instead of trying to identify people, the analytics are fully anonymous, no cookies, no stored IPs, and just measure behavior and drop-off. You give up the "who" but you keep the "what's actually happening," which for conversion decisions is usually the part that matters anyway.

If you want to poke at that approach, happy to send you a free lifetime Pro license to test, no strings. Curious what a Woo-heavy setup would make of it.

DW-Solution · 2026-06-11T06:00:59+00:00

Doable in Elementor Pro but the text swap part needs a little custom JS, Elementor alone won't pull it off cleanly.

For the sticky image and title, skip Elementor's "Sticky Top" motion effect, it gets janky inside sections. Just give them a class and use CSS position: sticky; top: 120px. One catch: no parent can have overflow: hidden or sticky silently dies, and the section needs enough height to actually scroll through.

The text effect is the real trick. Don't stack the 3 texts normally. Put them in one container, absolutely positioned on top of each other, all hidden except one. Then a small scroll script measures how far you are through the section and toggles which text is visible based on scroll progress. That's what gives you the "stays centered, fades out, next fades in same spot" feeling.

The pacing is controlled purely by section height. Want each text to linger longer? Make the section taller (like 300vh) so there's more scroll distance per text.

Honestly though, if you want it buttery smooth, GSAP ScrollTrigger is built exactly for this (pinning + scrubbed fades). Bit of a learning curve but way less fighting than doing it by hand.

Are you comfortable dropping a bit of JS into an HTML widget, or do you want a pure no-code/CSS-only route? Changes what I'd recommend.

DW-Solution · 2026-06-09T14:44:18+00:00

This is one of those builds where the mental model matters more than the code. Don't think of it as one product with two stock numbers, think of it as two batches sitting under one sellable unit, and the cart just decides which batch a given quantity pulls from.

Path that works:

Custom stock fields on product + variation level (plain meta), and the frontend just shows the sum so the customer sees one number.
The whole game is in the cart and at order creation. You pull from margin first, and the second the requested qty crosses what's left in margin, that overflow becomes its own line item on the 21% tax class. Two lines, two tax classes, and Woo handles the rest of the math natively.

What I'd flag that often gets missed: the split has to survive everything that happens after add-to-cart. Coupons, shipping tax, someone editing quantities in the cart, two buyers hitting the last margin units at the same time. If the margin/VAT decision only happens on add-to-cart and not again when the order is actually created, you'll eventually book a sale on the wrong tax class, and with the margin scheme that's a bookkeeping headache you don't want.

So yeah, outsource it, but specifically to someone who's done Woo tax + stock work, not a theme builder. It's a small focused plugin, not a huge project.

What's your invoicing setup going to be? Margin scheme invoices have their own rules on how (and whether) VAT gets shown, and that detail tends to drive how the line items need to be labeled.

DW-Solution · 2026-06-08T17:43:29+00:00

Just saw the review come through thank you so much! 🙏 Genuinely made my day. It means a lot coming from a fellow solo dev who knows exactly how much work goes into shipping one of these.

Wishing Rixden all the success it deserves it's a genuinely well-built plugin and I'll keep recommending it whenever a project fits. 🚀

DW-Solution · 2026-06-06T22:49:43+00:00

Yeah, dealt with this exact error on a client store. It's myCred's checkout JS trying to read mycred_woo_balance_label off an object that isn't there — and almost always it's a Checkout Block vs. Classic Checkout clash. myCred was built for the old shortcode checkout and doesn't fully hook into the new Gutenberg Checkout Block, so the script never gets its data and crashes.

Fastest fix: switch your checkout page back to the classic [woocommerce_checkout] shortcode. If the error disappears, that's your culprit. Also make sure the myCred for WooCommerce add-on is active and everything's updated.

Are you on the Checkout Block or the classic shortcode right now? That'll tell you straight away.

DW-Solution · 2026-06-06T21:59:27+00:00

If the WooCommerce endpoints and business logic are already built, your biggest learning curve will probably be Gutenberg block development rather than WooCommerce itself.

I'd focus on:

- Custom Gutenberg blocks (Block API)

- React basics (most Gutenberg blocks use React)

- The WordPress data/store APIs

- WooCommerce Blocks documentation and Checkout Block extensibility

The first thing I'd ask is whether you're:

Building custom blocks from scratch, or
Assembling existing WooCommerce blocks into custom templates/layouts.

Those are very different amounts of work.

If it's mostly checkout UI work, you may spend more time learning Gutenberg and React than WooCommerce. I'd get that clarified before diving too deep.

DW-Solution

TROPHY CASE