ebeighe

4.8.1 works for me except now my jetpack is disconnected from my wordpress account;
When i “connect jetpack” it says it works (“jetpack is now connedted”) but in my dashboard it appears as though jetpack is still not connected.

FTP: it might be easier to use your host’s control panel, in cPanel there’s a function called “file manager”.
You would find your wp-content/plugins folder and in there there will be a folder called jetpack.

ok. i think i see what’s going on here…

I have W3 Cache plugin turned on —
much to my amazement, what seems to be happening is if there’s a valid page cached in w3tc, it gets served, even if in maintenance mode.
If the page doesn’t happen to be in the cache, or if it’s expired, I do see the maintenance mode page.

my pages, i think, all got invalidated at 6:34a today — this is, probably not coincidentally, when my wp-cron runs.

I had disabled wp-cron in the hopes of reducing server load, e.g. i did this:
https://www.inmotionhosting.com/support/website/wordpress/disabling-the-wp-cronphp-in-wordpress
And I put in a cron job to run wp-cron at 6:34 once a day.

Why did my pages all get invalidated?

Here are the browsercache.html settings from master.php:

"browsercache.html.compression": "1",
    "browsercache.html.last_modified": "1",
    "browsercache.html.expires": "1",
    "browsercache.html.lifetime": "3600000",
    "browsercache.html.cache.control": "0",
    "browsercache.html.cache.policy": "cache_public_maxage",
    "browsercache.html.etag": "0",
    "browsercache.html.w3tc": "0",
    "browsercache.html.replace": false,

The a copy of entire w3tc master.php settings are here:
https://pastebin.com/d5QK2zLi

well i can’t figure it out.
After making the change noted above, my pages are expired after less than a day.

Thanks, so i found this message in the page cache settings:

– The TTL of page cache files is set via the “Expires header lifetime” field in the “HTML” section on Browser Cache Settings tab.

Then, in the HTML&XML section is has this setting, which is unchecked by default:

– Set the expires header to encourage browser caching of files.

So I ticked that one and set it to 3600000 seconds ( i think that’s 1000 hours).

Is that the right setting?

Just a little follow up:

I re-did everything (on another hosting account) and everything worked as I expected it to, which is to say:
wordpress doesn’t really care where it’s files are located (if the url changes, you have to make sure that in the database the home and url in the options table reflects the change)
—-

In thinking back on what might have been wrong to cause an Internal Server Error; i’m guessing (guessing because I’m not able or sure about how to go back and reproduce the error) it was something wrong with my .htaccess file.

Yes, agreed, it’s nothing in particular to do with wordpress.

In my mind i connected the two because i was setting up wordpress ??

i understand that i can buy my way out of any difficulties — but that seems unnecessary, after all i’m talking about a site that has perhaps 5 to 10 vistors per day. In other words there must be a smarter way to approach it. Paying more for more resouces so i can service more hackers (or whatever you want to call them) just feels wrong to me. It’s like letting “them” win!

As i mentioned, i had already (but just 2 days ago) locked/restricted wp-login.php to my IP address.

I keep looking around cPanel but i really don’t feel like i can find/monitor the information i would need to see how many resouces i’m using. It’s not like there’s a bucket of resouces per month (or whatever) that get used up.
Another thing i think i notice is that the different hosting companies provide all sorts of diffent tools… for example the provider i started using a few days ago (siteground) has something the called “HTTP CPU usage statistics” in a cPanel group called “1H Software” (is there a way to attach a screenshot in this forum?); it has a table and graph of
Realtime Usertime systime Executions Ave Secs
hour-by-hour. Is that what i should be looking at?

This current host, siteground seems to be running just wonderfully; but maybe i am just one tick away from being suspended… how would i know?

Some deeper background:
I’ve been chasing similar problems around for quite some time; but is seemed to ebb and flow, and now i’m finally seeing a pattern (i’m slow!)
I initially set up the wordpress blog for this domain over a year ago on an account with Godaddy. This was a very old-style type of account (pre-cPanel). At some point i complained/noticed slowness. When i talked to them they suggested moving to a cPanel account; claiming that would fix my problems.
It did, at least for a couple of months. Then when i noticed problems and complained their only solution was to pay them more money for more resouces — which seems patently ridiculous for a blog that gets zero to 10 total hits per day.
At that point i migrated it to Hostgator for a month as a test and that worked fine

So the progression was:

Godaddy “pre cPanel” — eventually problems
Godaddy cPanel — problems
Hostgator — worked fine but i was only on it for about a month
Webhost.pro — worked fine for 6 months, then got suspended
siteground — working fine, but it’s only been 3 days ??

All accounts were more-or-less whatever the entry-level was offered.

This all makes some sense: i.e. i’m using too many resouces but don’t know it, and eventually they (the provider) “catch up” with me?
But why/wouldn’t millions of people — people with self-hosted wordpress sites at budget providers — have the same problems? Googling around seems like the 508 Resouce Limited, and performance in general, is a problem but not a huge problem; especially among people who have minimal traffic.

marked resolved

ah, of course, the .htaccess file is involved with permalinks. I knew that (but forgot)! Thanks.

hey dwinden,
“Test by installing a clean…” yes, good idea. So i did install a clean/new/fresh WP and did not allow iTSec to update the .htaccess file (and i verified that iTSec did in fact not update it, it only has the usual WP stuff in it) and the hide backend feature still works, or i should say as far as i can tell everything appears to work.

Also, thanks for pointing out the security hole in this feature — it’s a rather gaping hole!

One question:
if i put this url into chrome it works as you should expect, that is it returns a not_found:
https://mysite.com/wp-login%2ephp
if i put it into firefox, it does indeed open up the wp-login.php dialog and anyone can log in without ever knowing the “secret” address.

Why do the two seem to behave differently?

hey dwinden, you said: “Clear the browser cache after commenting out the rewrite rule … you will see that the secret login page no longer works after clearing the browser cache …”
That sounds logical, but that’s not the case for me. I even went to another computer and tried it — still can access the secret page.
I don’t have any other proxy or cache (that i know of!), perhaps the rewrite rule is unnecessary and is handled elsewhere?