Dayne Mentier
Forum Replies Created
-
Glad it’s working again, and thanks for reporting back. One thing worth checking: since you restored a database from a week ago, anything added in that week (posts, comments, orders, form entries) won’t be in it. If anything is missing, UpdraftPlus can restore just the database from a newer backup now that PHP is fixed.
For anyone who finds this later: in your Fixing WordPress thread you mentioned that switching off ModSecurity on the server fixed it.
That fits. Elementor saves the whole page as one request, and ModSecurity has its own request-body limits, separate from PHP’s (
SecRequestBodyNoFilesLimitdefaults to 128 KB). A long Elementor page passes that easily, and ModSecurity then answers 413 even though PHP’s settings are fine.Rather than leaving the whole firewall off, I’d turn ModSecurity back on and raise that limit in its configuration, e.g.
SecRequestBodyNoFilesLimit 2097152(2 MB; also check
SecRequestBodyLimitis at least as large), then reload the web server and save the page again. The error log entry for the 413 names the exact limit that was hit, if you want to raise only that one.A dedicated server with no web application firewall is a bigger risk than the 413, especially this week with the PHP vulnerabilities being exploited.
The error says PHP can’t find
mb_strtolower(), which comes from PHP’s mbstring extension. So the 8.3.36 build on your server almost certainly has mbstring switched off. Elementor isn’t broken; the new PHP is missing a module the old one had. (WordPress only ships fallbacks for a few mb_ functions, and mb_strtolower isn’t one of them, which is why Elementor is where it shows up first.)To confirm: switch to 8.3.36 and open Tools > Site Health. The Status tab lists missing recommended PHP modules, and mbstring should be among them. A phpinfo page shows the same.
The fix is to enable mbstring for 8.3.36. Your paths (C:\home\…\wwwroot) point to a Windows host. There, mbstring is
extension=mbstring(php_mbstring.dll) in that PHP version’s php.ini, followed by a restart of the site’s app pool. On shared Windows hosting that’s usually a ticket: “please enable the mbstring extension for PHP 8.3.36, as it is on 8.3.33”. While they’re at it, ask them to compare the other extensions too (intl, gd, curl, zip). A freshly built PHP often loses more than one.I wouldn’t stay on 8.3.33 for long: 8.3.36 is the release that fixes this week’s critical PHP vulnerabilities. Getting the module enabled is worth chasing today rather than rolling back.
Forum: Plugins
In reply to: [Contact Form 7] Contact Form 7 Error After Updating to Version 6.2.2Something that may help narrow this down: “There was an error trying to send your message” is what Contact Form 7 shows when WordPress’s mail function reports a failure. So the actual reason is usually recorded on the mail side, not in CF7.
– WP Mail SMTP (free version too) logs failed sends under WP Mail SMTP > Tools > Debug Events. Look at the entries around the times users saw the error. The message there (authentication failed, rate limit exceeded, connection timed out, recipient rejected) tells you which problem you have.
– When an SMTP setup works most of the time and fails sometimes, it’s usually one of these:
– a sending limit at the provider (Gmail and Microsoft 365 both throttle per hour and per day);
– a slow or timed-out connection to the SMTP server;
– with the Gmail/Google mailer, an OAuth connection whose Google Cloud app is still in “Testing” mode, which expires every 7 days until you reconnect.
– Note whether failures cluster at busy times (points to limits) or follow a reconnect pattern (points to OAuth).If you install Flamingo (by the same author), every submission is stored in wp-admin, so no enquiry is lost while you track it down.
Forum: Plugins
In reply to: [Contact Form 7] Going to spamAdding to Jairo’s suggestion, because one small typo there would make things worse:
1. The SPF mechanism for an IP address is
ip4:, notip:. Edit the existing record (don’t add a secondv=spf1record, two records break SPF) so it reads:
v=spf1 include:spf.simply.com ip4:93.191.156.64 ~all
This matters on your domain because its DMARC policy isp=reject, so mail that fails both SPF and DKIM can be refused outright, not just filed as spam.2. In the form’s Mail tab, set From to an address on your own domain, e.g.
Hammel Tennisklub <wordpress@hammeltennisklub.dk>, and put the visitor’s address under Additional headers asReply-To: [your-email]. If From is the visitor’s own Gmail or Hotmail address, the receiving server sees “Gmail” mail coming from your web server and treats it as spam whatever your SPF says.An alternative to step 1 is to send through your host’s mail server with an SMTP plugin and a real mailbox on your domain. That mail is already covered by
include:spf.simply.com.To see exactly which check fails, send one form message to the address mail-tester.com gives you. It scores SPF, DKIM and DMARC separately.
Gmail showing SPF, DKIM and DMARC all as PASS is the real test, so your mail is already authenticated. The warnings don’t mean delivery is broken.
Some background that should make this safe to tidy up without touching Outlook:
– The MX and SPF records Resend asks for go on a subdomain (by default
send.yourdomain.com, listed under Domains in Resend), not on the root domain. That subdomain is only the bounce (return-path) address. Adding records there never changes the root domain’s MX records, which are what deliver your client’s Outlook mail.
– If a check wants SPF on the root domain, do not add a secondv=spf1TXT record there. A domain may only have one SPF record, and two make SPF fail for everything, Microsoft 365 included. If something ever needs adding to the root SPF, edit the existing Microsoft record and add it inside that one line.
– Before changing anything, compare the records Resend’s Domains page lists with what a DNS lookup tool returns forsend.yourdomain.com(MX and TXT). If both are there and Resend shows them verified, the warning is most likely the checker querying a different hostname than the one Resend uses. The WP Mail SMTP team can confirm which name their domain check looks at.Forum: Plugins
In reply to: [WooCommerce] Checkout fails at paymentBefore reinstalling (it’s unlikely to help, because pages and settings stay in the database), find out who is redirecting:
1. Add a product to the cart, open your browser’s developer tools → Network tab, tick “Preserve log”, then click the checkout button. The first response is a 301 or 302. Look at its headers for
x-redirect-by: WordPress adds it, and it names the code that redirected (“WordPress”, “WooCommerce”, “Yoast SEO”, a redirect plugin…). That alone usually solves it.2. Since support saw checkout working but you don’t, suspect caching or sessions. If the cart looks empty to the server, WooCommerce sends you away from checkout. Make sure your caching plugin, host cache or CDN excludes /cart/, /checkout/, /my-account/ (here /winkelwagen/ and /afrekenen/) and any URL with wc-ajax. Then test in a private window.
3. Check the button’s own link: Elementor’s cart and mini-cart widgets let you override the checkout button URL in the widget settings.
4. A multilingual plugin (WPML, Polylang, TranslatePress) needs the translated checkout page assigned too, or the Dutch button can point somewhere else.
5. Settings → Permalinks → Save (no changes) refreshes rewrite rules. It’s harmless, and occasionally the fix.
If the
x-redirect-byheader names something unexpected, post it here.