tuccimane

James,

Thanks for that link. Made me realize MYSQL Version is at 5.5.33, which is also “outdated”.

Without access to panels or a hosting account, and only an FTP and WP Login to work with, is there any way these can be upgraded without calling the host?

One last note:

I noticed that my server is using PHP Version 5.3.24

Should I upgrade that to 5.5.x?

Esmi,

You’ve been awfully helpful and I do appreciate your insight. I will take note of your comments and be sure to run a reinstall manually (or through the admin if I can get back in and it’s not crawling).

Sterndata,

Thanks for your response. You are right. My site was VERY fragile before the update. That is why I am insinuating that the update has caused even more need for admin memory usage, because how else would something that was so fragile and finally set in a good place where it was working quickly and efficiently too, come to its knees over just a simple security update?

More secure yes. But again, and as with most the updates over the past year or so, it requires more mmph from the server and it’s slowly tearing apart already ice-like sites.

No complaints, I guess I just wanted to warn other people who are away of their site’s fragile nature that they may want to hold off for 4.6 which is indeed on the horizon.

Also,

This is random, but I remember specifically checking something in the dashboard to set plugins, wordpress and themes to auto-update. Why is everything I’m looking up to disable this saying I need to input lines into wp-config.php or install a plugin?

Where is the option again that I so vividly remember using before in order to enable this feature?

Esmi,

I take it you are suggesting that I, a) reinstall 4.5.3 in case of a server hiccup that happened during the auto install, and b) downgrade to 4.5.2 if it’s still not working.

I say that for ‘b’ because I only have 10-11 plugins, and they are like BootStrap Shortcodes, Font Awesome, Ninja Forms. Very simple things. And then there’s like 3-4 that are specifically speed/optimization related. Basically I don’t have any plugins that I can toss or that are really “bad” besides MAYBE Facebook by Weblizar, that one I have no idea about, it could have been causing issues all along, but I really doubt it.

Then there is the theme…a huge issue on its own. Enlightenment is not a 4.5.2+ supported theme, but really what do you do about that? I can’t redesign an entire website just because wordpress has updates every month and the theme developer hasn’t in over a year. Honestly, any theme besides the core themes is going to have this issue in my opinion- and that’s because no developer is sitting there right now saying “I’m going to update this theme along with the wordpress trends for the rest of my life so that my users have a sure bet for the future of their websites!” Although, that would be the first developer I ever donated to if there was one with that mindset.

Your claim is only true if, and only if, the time it took to generate is changing.

By that I mean the plugin generates that line only when it first caches the page to tell you how long it took mainly for debugging purposes (if you see abnormally high times something may be happening when the pages are being generated and it could be a larger memory issue or something from broken code).

Functional explanation aside, it actually is supposed to appear every time; however, it should appear as the SAME time load stamp, along with the SAME date/time stamp. I.e. If it says it generated in 0.500s on X date at 00:00:00 hours, then your claim is only true if it DOESN’T say that on the next load. If it does, everything is working as intended. The page got generated, and it is the same page from the first time it got generated, and it is being served repeatedly until it expires; rather than a new one being generated repeatedly.

Do you see the debug functionality of it? If you see the generation time is changing or the date/time that the page was generated at originally is changing, then something is wrong. Perhaps your expiration is super short? I do know there is a little bit of broken code in the wp-cache-phase1.php and wp-cache.php (I believe it’s these two…) where for some reason the headers stay set as “max-age=3” and it generayes that into the wp-content/cache/.htaccess too. You can just manually change it to what your expiration is actually supposed to be, because that may be causing your pages to expire in just 3 seconds. Anywho, that’s why the setting for enabling these labels is in the debug tab and is on by default, because they help, a) to let you know it caching is even working, and b) to know if it is working but malfunctioning.

I have been running it without Cache Rebuild too and it was working at first, but now I’m noticing that my preload is generating every page cache EXCEPT the homepage.

Maybe it was just once though because it did have a hiccup because of a broken-ish page it couldn’t cache and then never got around to the homepage after that.

Anyway, may have to enter / directly as a cache page in the advanced settings if that keeps up.

Can anyone help explain why the plugin has such trouble writing the meta files though?
And how important is it that it does because my site is blazing fast and works just fine, I’m just wondering though if the meta files not being written is what is causing random crashes about once or twice a day?

When I’m preloading the cache, EVERY page gets generated like this:

23:49:05 13765 /contact-us/ Supercache Late Init: add wp_cache_serve_cache_file to init

23:49:06 13765 /contact-us/ Supercache Late Loader running on init

23:49:06 13765 /contact-us/ wp_cache_get_cookies_values: return: 

23:49:06 13765 /contact-us/ supercache dir: /****edited out*****/html/wp-content/cache/supercache/site.com/contact-us/

23:49:06 13765 /contact-us/ No Super Cache file found for current URL: /******edited out*****/html/wp-content/cache/supercache/site.com/contact-us/index.html

23:49:06 13765 /contact-us/ In WP Cache Phase 2

23:49:06 13765 /contact-us/ Setting up WordPress actions

23:49:06 13765 /contact-us/ Created output buffer

23:49:13 13765 /contact-us/ Output buffer callback

23:49:13 13765 /contact-us/ wp_cache_get_cookies_values: return: 

23:49:13 13765 /contact-us/ Anonymous user detected. Only creating Supercache file.

23:49:13 13765 /contact-us/ wp_cache_get_cookies_values: return: 

23:49:13 13765 /contact-us/ wp_cache_get_cookies_values: return: 

23:49:13 13765 /contact-us/ Writing non-gzipped buffer to supercache file.

23:49:13 13765 /contact-us/ Renamed temp supercache file to *********edited out*******/html/wp-content/cache/supercache/site.com/contact-us/index.html

23:49:13 13765 /contact-us/ Sending buffer to browser

23:49:13 13765 /contact-us/ wp_cache_shutdown_callback: collecting meta data.

23:49:13 13765 /contact-us/ Did not write meta file: wp-cache-83e73c0537c6715e9340639f724c1b63.php *1* *1* *1*

23:49:14 13666 /wp-cron.php?doing_wp_cron=1466120925.4499359130859375000000 wp_cron_preload_cache: fetched https://site.com/contact-us/

I have done tons of tweaking with this plugin, and i came across an older post today that kind of answered this question directly.

It prompted me to do this:

– Go to /plugins/wp-super-cache/wp-cache-phase2.php
-Open wp-cache-phase2.php and search for the following using the find function:

prune_super_cache( $dir, true, true );

There are two line like that, and you will be commenting out the SECOND one.

-Therefore, replace this line:

wp_cache_debug( "wp_cache_post_id_gc clearing cached index files in $dir.", 4 );
		prune_super_cache( $dir, true, true );

with this instead….

wp_cache_debug( "wp_cache_post_id_gc clearing cached index files in $dir.", 4 );
//prune_super_cache( $dir, true, true );//Comment out this line to prevent all cached files being deleted when a single post id updated

That will effectively comment out that little bit of code, plus it gives a comment reminder in the code of WHY you did this.

Does it work? I honestly don’t know yet because I haven’t tested it with the debug log, but it seems that it has because I updated some pages and before it was crashing my site and causing temporary 500 errors because the cache was all deleting at once and it was just a heavy load on the server maybe?

Not sure, but try it out and see if it works for you! It certainly hasn’t HURT my site so far to have commented that out.

Why did changing RewriteEngine to Off in my /blog .htaccess suddenly stop the 500 errors and let me in to my admin (albeit with terribly slow loading rates)?

Edit: and then going in and saving permalinks broke everything again.

This is something to do with my caching plugin I have a feeling…

Is there an easy way to just reinstall my site to the root so I can stop trying to work around all this. This is just insane trying to get things to work with a setup like this. It works until you try to optimize things, then everything gets jumbled and breaks.

I don’t think the people who develop all these plugins really have setups like this in mind. They ultimately develop so it works with a root install and the rest is just updating bit by bit trying to assist people with sites setup uncommon ways, but they aren’t dedicated to it like they are to making things work for the simple people who just install into the root.

For anyone wondering what I ended up doing:

If you have a WordPress Site like https://www.Example.com/blog/ with WP installed into the /blog subdirectory, but you are pointing everything to https://www.Example.com properly using permalinks and the codex guide, then you are going to want to know the right way to set up .htaccess for a plugin like WP Super Cache.

The trick? Do nothing.

WPSC gives a notification that confuses the hell out of you, but let me assure you, nothing needs to be done IF you have the same setup as described above.

The plugin will write to the ROOT .htaccess and will include all the proper pathing rules.

DO listen to the notification if you have WP installed in a subdirectory but AREN’T permalinking it to your root domain. Otherwise, disregard.

Also, do NOT copy the rules into your other .htaccess (the one in your WP install directory), or even post any rules there for that matter.

I have a BLANK .htaccess in /blog and my site operates just fine.

*Remember this is for sites that have WP installed into a subdirectory but permalinked to the root.

As far as any other problems, I could write a book on how to solve a ton of them, but this is the answer to this question and that’s what I’m leaving it at.

Frank,

I guarantee this is something on my end, but it’s just so hard to debug.

Thank you for the clarification. Between the two plugins, when my site isn’t busting, I am getting amazing page speeds and everything is wonderfully optimized.

I don’t want to find a different way to cache and optimize as I have found that using these two plugins with WPSC not compressing and activating WP Performance Score Booster as well, creates an incredibly fast site.

I’m not sure if anyone else cares, or you or the dev for WPSC cares (Donn someone right?), but I have went through a world of trouble figuring out how to configure this all for a site with WP installed into a subdirectory and properly permalinked to the root.

That and all the little kinks I have worked out between these three plugins working in union – between it all I could write a pretty comprehensive guide on what does what and what breaks what and what code changes need to be made because of dev errors (the max-age thing was really effing up my expiries and preloading – and the ob_start thing was yet another little thing that had to be worked out by adding bits of code or changing this and that).

Anyway.

Thank you again. Is what I really was saying.

If I have any questions it’s really nice to know you and other devs are so timely with your responses.

Staartmees,

This is a good start.

At least now I can mull my way around and figure out what the hell is going on.

Before I didn’t even know where to look.

I’m very adaptive and versatile at learning, but when I have no starting point it’s extremely difficult to wrap my head around something.