tomacpace

Terrific, thank you Bcworkz for your response. I will look further into that! Although I’d looked at the sanitize function already, I will look at it again.

And your note acknowledging the usability concern is encouraging. I am glad it’s something others may consider too. The team I’m part of is dealing with a collection of seniors for usability tests, and we’re making headway with our particular designs.

Something we’ve come to, which isn’t wordpress specific but could influence design for seniors in the future, is a default font across the site that is at least 20 px. Light-strength (rather than weak) passwords, are unfortunately a like-to-have, wish it was a need-to-have. I have considered an immediate pass-through, as soon as registration is complete, the auto-authentication of the user, so they can get into the site and begin using without actually logging in… but still restricting most user-specific content to post-authentication.

There are probably a dozen or more senior-citizen-specific design considerations.

I ran into this same problem and followed the recommendations by esmi. This was after I had already updated to the latest WP version, and the site was still working. I thought it may have been due to a plugin I was working on. But I’m just learning how to work with the entire WP plugin architecture. So my database was up-to-date.

However, the first point:

– switching to the default theme by renaming your current theme’s folder inside wp-content/themes and adding “-old” to the end of the folder name using FTP or whatever file management application your host provides.

… doesn’t cause WP to automatically revert to the default theme. It didn’t for me, in any case.

After applying all of the suggested steps, the error went away but the site was totally blank. So, I removed the “-old” suffix on my theme folder, and voila! the site is fixed.

I am not a master WP engineer, and I appreciate the suggestions esmi. Awesome stuff.

Last night I found this thread… I’ve been hunting for the solution to this problem for months. I’m a bluehost customer too, with a single SSL on my root domain and wp blog on an add-on domain, and found comfort knowing people on bluehost were in almost the exact same situation.

The setup I have is basically:
myrootdomain.ca (ssl secure)
https://www.mywpblog.com

I was hacked a couple months ago, and I think either because one of my FTP accesses was sniffed or just logging into the wordpress blog one-too-many times insecurely.

https://www.mywpblog.com caused big warnings in browsers, saying it was being misrepresented as myrootdomain.ca..
https://myrootdomain.ca/mywpblog/ would partly work, but unresolvable errors occured with logging into https://myrootdomain.ca/mywpblog/wp-admin

So finally I logged into the account using https://www.mywpblog.com/wp-admin insecurely, and found the two url fields in Settings, changed the WordPress address (URL) field to https://myrootdomain.ca/mywpblog and the miracle happened, everything works perfectly now. I don’t care what the URL is for administering the site, and I don’t have anyone log in to post comments, so this works for me.

Granted, there is no other WP blog in another subdirectory or on the root domain, but since myrootdomain.ca/mywpblog is the same directory as https://www.mywpblog.com, perhaps I was simply complicating things, trying to work .htaccess rewrites and such.

This may or may not help anyone, but it’s a solution that has worked for me as an SSL owner on bluehost.