BluehostSupport

@qry2000 One other thing you can check while you’re waiting on Themeco is whether there are any custom queries or conditions in your child theme that might be excluding products without you realizing. I’ve seen themes accidentally filter out products because of hidden visibility settings or by only querying certain post types.

On your staging site, try creating a brand new test product and assigning it to one of the empty categories, then see if it shows up. Sometimes older products have their visibility or stock status messed up and the theme doesn’t display them. Also worth double-checking that the categories themselves aren’t set to “hidden” somewhere in the theme options or a customizer panel.

Doesn’t fix it outright, but it might help pinpoint whether it’s just a template issue or also how the theme is querying products.

• This reply was modified 9 months, 3 weeks ago by BluehostSupport.

Hey @deedeekaye, it’s completely understandable to feel unsettled seeing all those login attempts, especially when they’re coming from different countries. It’s actually super common for WordPress and WooCommerce sites to get a ton of random login attempts, bots just love scanning for sites like ours and trying their luck. It usually isn’t anything personal or targeted, just the reality of running a site that’s visible online.

It’s great that Bluehost confirmed what you were seeing. Even though they can’t directly manage plugin settings, there are still a few things you can do on your end to keep things secure.

First, it’s a good idea to use a security plugin alongside your activity log tool. Something like Wordfence or iThemes Security can help block malicious IPs, limit login attempts, and give you alerts when things look suspicious. Just be sure to do your research on the best fit for your setup.

You can also enable two-factor authentication on your login page, which makes it way harder for anyone to get in even if they guess your password. Changing the default login URL with a plugin like WPS Hide Login is another easy step that helps reduce bot traffic hitting your site.

And of course, strong passwords are a must. If there are any extra admin users you don’t use, it’s smart to disable or remove them just to keep things tight.

It sounds like you’re already doing the right things by updating your PHP and staying on top of plugin updates. This kind of stuff can feel overwhelming, but once you put a few of these safeguards in place, it gets a lot more manageable.

You’re asking the right questions, and you’re on the right track.

Thanks for getting back with us on this. This sounds more like an email validation issue than an issue with Jetpack itself. Reinstalling won’t do much if the new email hasn’t been validated to replace the admin email. You may need to resend the validation email if you can’t find it. If you do, just cancel the pending change and try it again. 

These steps should help to resolve the issue:

1. Open WP dashboard
2. On the left hand side, click Settings.
3. Scroll halfway down to Administration Email Address and check for ANY pending changes to the admin email (Typically highlighted in green). 
4. There is a little message right above the Pending change message that states:
    If you change this, an email will be sent to your new address to confirm it. The new address will not become active until confirmed.
5. Go to the NEW email address and confirm the update. If the email cannot be found, cancel and restart the email update request in the settings.

Please let us know if this is successful for you or feel free to message us privately and we would be happy to assist further. We will be happy to work with you on this.

Happy to help where we can! If you only just updated the email for it it may be taking some time to update as Jetpack does. If you login your dashboard and take a peek at the settings it should indicate if the update completed as you’ll see the new email. If it’s still processing it’ll say that on there. If you have confirmed the updated hosted domain email is live on it, feel free to give our support team another try just in case it’s something we can identify and help with.

Happy to jump in as we work with a lot of Bluehost + WordPress sites and helps troubleshoot this stuff often:

1. Form Error: As the plugin team mentioned, embedding the form using the WPForms block is the #1 fix for the corrupted post data issue.
2. SMTP on Bluehost:
   If you’re using Bluehost’s built-in email (like email@yourdomain.com), you don’t actually have to use an SMTP plugin unless you’re running into deliverability problems (emails landing in spam, or not sending at all). WordPress can send through PHP mail by default, but sometimes hosts limit or filter this, so SMTP is a solid plan if you need more reliability.
3. Brevo as Mailer:
   If you do want to use Brevo (or any third-party email service), the main thing is to follow their setup instructions, including adding the right DNS records in your Bluehost panel. You don’t need to remove any existing Bluehost DNS records, but you do need to add the new ones provided by Brevo so mail sent by the plugin isn’t flagged as spoofed or spam.
4. DMX Records:
   If by “DMX” you mean DMARC, DKIM, or MX records, no need to delete the Bluehost ones, just add Brevo’s records as instructed. That way, both regular domain email and plugin-sent emails can work together.
5. Pro-tip:
   If you’re testing, try sending a form to an address outside your domain (like Gmail or Outlook). If it doesn’t arrive or goes to spam, it’s usually a DNS record or authentication tweak that’s needed.

Hope that helps untangle the mess! If you’re ever stuck on the Bluehost panel, their support chat can walk you through the DNS part too. Curious to hear if you get it working, SMTP setups are always a little more “fun” than they should be.

@zanduino

Hey, thanks for laying out what’s been going on with those 415 errors. Definitely annoying when everything works in your browser but a link checker flags it anyway.

This usually pops up when web servers get a bit picky about requests from automated tools like BLC, especially with certain headers or if the server’s running OpenResty or Nginx. On shared hosting, there’s not really a way to tweak the server config, and as far as I know, the local engine in BLC doesn’t let you customize request headers either. Marking the links as “not broken” when you know they’re fine seems like the most practical move right now.

You’re spot on with the VPN thing too, sites like Imgur definitely block some VPN endpoints, so testing without it can clear up weird errors now and then.

You’re not the only one to hit this kind of snag with automated link checkers, so you’re in good company. Manual checks aren’t the most fun, but sometimes it’s the best way to keep things tidy.

Always cool to hear if anyone else here has found a clever workaround for this on shared hosting.

Hey there, I totally get how frustrating this kind of issue can be. You’ve clearly put a lot of time into it, and it’s tough when things just won’t work no matter what you try.

Since your client’s email is with Outlook and the site is on Bluehost using Kubio, email deliverability might be hitting a few common snags. When contact forms fail to send, it’s usually related to how the site handles outgoing mail and how the email provider treats those messages.

One good step is setting up SMTP properly so your site can send emails more reliably. You’ll want to make sure the settings match your client’s Outlook account and that the SMTP tool is actually taking over the sending process for all messages from the site.

It’s also worth checking the domain’s DNS records. For email services like Outlook or Microsoft 365, the right SPF and DKIM records help prove that your site is allowed to send messages. You can usually update those in the domain settings wherever DNS is managed.

If the form plugin you’re using just isn’t cooperating, it might be worth switching to another option that works more smoothly with the builder you’re using. Some form plugins are more beginner-friendly and tend to work better right away with SMTP setups.

After setting up everything, try sending a test email from the site using your mail settings just to confirm messages are going out. That helps narrow down whether the issue is with the contact form or email delivery overall.

And finally, if the form is still throwing an error, check for any logs or error messages in your SMTP settings or your hosting dashboard. That extra detail can make a big difference when figuring out what’s going wrong.

You’ve come this far, and you’re closer than it probably feels. Happy to keep helping until it’s fully sorted.