And I’m not in the mood to fix it anymore. I used a heavily customized HemingwayEx ever since I started this blog, but it’s been unmaintained for the past 7 years and I noticed recently that my homepage is now all wonky. Plus sporadically people had been complaining about readability.
Since I don’t post that much anymore, I think it’s time to go to something more standard, so I just selected one of the wordpress defaults for now. Feeling cute, might change later 😀
Yea, baby, yea!
I have finally moved away from Dreamhost after 6 years of being a loyal customer. After barely being able to run a simple murmur server and 2 wordpress sites without multiple reboots per day due to lack of resources, even on a VPS, enough was very much enough.
So I have finally decided to make the jump into a different host which came recommended from a friend and until now I’m very glad I did so. Not only is my speed blazing fast compared to dreamhost, not only do I have 10 times the available resources, not only do I have full root access and ability to customize my sites fully, but I’m also paying less than 1/3rd of what I used to!
Now this is a significant difference and I really struggle to understand why I had to pay $15 extra a month just to get 300 lousy MBs of ram which was a also a hard limit that caused by whole server to reboot during each resource spike? Why indeed did 2 wordpress sites with no particular frills and a mumble servers with 5 users caused 1-10 reboots a day for years? Why couldn’t dreamhost support in troubleshooting this very worrying performance of their services?
In the end I really had myself to blame for a lot of it. I was far too lazy and a bit scared of going to fully rooted hosting and got very complacent and used to the user-friendliness of the dreamhost panel. It is all kinds of awesome how easy dreamhost makes it to set-up and maintain sites, emails, DNS entries, cro
n jobs and so on. It’s such a pity that their performance has been in the toilet for the past 2 years for me.
I could even have lived with the 2-5 seconds per page load, or the visible lag I has in a simple ssh connections to their servers. But 20 server reboots in a day while dreamhost support were telling me it’s my own damn fault for running vanilla wordpress, was just too much.
All that was part of the reason why I’ve been so inactive in blogging lately as well, aside for my newborn child and my new hobby in octgn development that is; it was just so frustrating trying to blog in a server that took second to load each panel and literally went down every time I hit “publish”.
I hope that I’ll start writing a bit more now that my snazzy new system doesn’t seem to be making it a chore to put two words together on the net 🙂
After squashing a showstopping bug, I’m finally ready to upgrade my theme to the newest version and hopefully jump start its development, on my own if necessary.
I’m finally preparing to upgrade my theme to the latest version (ie the next part in my ongoing attempts to upgrade) as I really should finally start using wordpress widgets. Unfortunately the theme seems to be unmaintained at the moment and the author MIA since April this year. Also the theme still hasn’t been moved to the shiny new official WordPress repository which tells me that Nalin must have lost all interest in it.
Hopefully I’m wrong. I’ve sent him an email and left a forum post asking to add to the repository and allow me to pickup the maintenance if he’s not interested anymore. If he doesn’t come back to me, I’ll unfortunately have to fork it in order to make it compatible with newer version of WordPress and to merge the changes I’ve made into it for others to use. We’ll see.
Some of the things I’m planning to add/modify are
And that’s for starters. Fortunately I see that the community around this theme is still alive so I’m guessing I’ll be getting more ideas for addition from there as well.
I’m still running my old theme since I managed to debug the suckerfish issue a few minutes before I left for work today, but now that my biggest hurdle is resolved, I’ll soon my changing into “fresh clothes” so to speak.
![Reblog this post [with Zemanta]](https://i0.wp.com/img.zemanta.com/reblog_e.png?w=980)
Transposh is a new shiny plugin that promises to make translating your wordpress blog to other languages a breeze. If you’ve gor a multilingual blog, you can’t afford to miss it.
Through NoState.com I’ve come to discover Transposh, a new WordPress plugin that promises to make the task of translating pages of your site to other languages very easy, and to also take reduce the personal effort required to do so by crowd-sourcing the task.And boy does it deliver!
You may have noticed that I occasionally write in other languages, particularly in my native Greek. That doesn’t happen so often because my audience is mainly international now but it still bugged me that my choice of language was in effect making it difficult for my friends and relatives from my birthland to follow and participate. However the task of replicating each post on another language was simply too much to bother.
However Transposh finally gives me an opportunity to fix this. I can much more easily do the task of translating my pages to my native language myself, since it utilizes google translate to get your text changed, transparently. That is, the text will switch to the google translation of the language you want and you can edit and fix it right there and then, without having to go through the dashboard or anything.
Not only that, but the elements of the page which exist in other locations as well, such as the title or the header, once corrected once do not need to be corrected in every other page of your site as well, but rather are intelligently cached and served.
Oh, and did I mention the crowd-sourcing part? This is my favourite bit. Transposh gives the opportunity for the blog author to not only allow other registered users to translate, but also for anonymous as well. This means that all interested parties can help improve your site. This might not be of much use for small fishes such as me, but for larger players with an international audience, it will certainly provide a lot more labour. Of course, there’ always the issue of vandalism, but much like any wiki, some solutions should be possible.
This crowd-sourcing now means that if you find an interesting article in a Transposh-enabled site, you can help translate to the language you wish (of those the author made available) and then send the link to all your friends whos’ foreign language skills are not so good.
For an Alpha version plugin, I’m impressed. Both at the quality of the code but also at the quality of the support. The main developer is lightning quick to respond and help with problems (although that’s bound to change as the plugin becomes more popular I guess). For example, my first and largest problem was that it seemed that the translation of each page was taking forever, sucking all my resources and that caching was not happening. However after some discussion with the developer, I discovered that by simply leaving the first translation to finish, everything became much snappier on subsequent attempts. That is because the general elements are translated once on the first time (which on an element heavy page like mine can take a while) but are cached once this is completed.
Oh, and did I mention that that it can also make nice permalinks for your translated articles that are indexable by google and cacheable by Hyper-Cache? (And I assume WP Super-Cache as well). For example, you can find the Greek translation of this article here.
So if you’re writing a multi-language WordPress blog or if you have an international audience, I think it’s time you give this plugin a go. Even if you don’t have the time to perform the task, you give the capability for others to read it easily (without having to go to visit google first) or even do the full job of translation themselves for the most interesting stuff.
For the Division by Zer0, I’ve now activated the Greek and German languages since I don’t expect people from other places to visit much. However if you’d like another option, simply let me know and I’ll enable it.
Sorry for the inconvenience. I’m beating the php gremlins as we speak.
My site has recently been trying to emulate a yo-yo. Apologies to everyone who’s been trying to access it and seeing either 404 errors or Internal Server Errors. Believe me, I’m more annoyed than you are by this.
This is a really tricky issue. I wanted to blame my host but I don’t think they are the cause. Something is corrupting one of my database tables which ends up causing php5 processes to hang and eventually consume all my RAM. I don’t know what it is and it’s not easy to find, particularly since I’m without internet at home and have to troubleshoot from work. That means no ssh terminal access and only a web-based ftp access and the php webadmin. Fortunately they were enough for the restore.
I am nevertheless getting mighty pissed off from all of this, particularly since this is not something easy to troubleshoot. I was lucky to get a quick reply to my question on the Worpdress fora but I haven’t received any more help on this. For some reason I suspect Intense Debate as it the one with the most common connections to the DB. Particularly since after disabling it and repairing the tables, the problem mostly went away. I was about the write a very exasperated support ticket to them but I wasn’t very sure so I left it for a bit.
I fully expect this to happen again soon and hopefully I’ll have a better idea where to look then (and hopefully some ssh access).
Still quite exasperated.
The site got compromised yet again. This time through a cross-site exploit. More aggravation follows. Some more information about what happened is discussed.
Has anyone smeared honey all over my site while I wasn’t looking? Once again I find out the Division by Zer0 has been compromised and spam links are being inserted invisible into my content. And that’s only 10 days after the last time. Argh!
This time I didn’t discover it through a google search but rather when someone from NoState.com contacted me through IM to let me know. This time the spam links were not hidden from the normal source but rather simply invisible in the normal page. This at least makes them much easier to find out and know when you’ve removed them. Nevertheless, this always feels like a very nasty violation every time it happens.
However the exploit was better hidden this time. It wasn’t just a few files hidden in my subdirectories but rather code inserted in my actual wordpress and theme files. This seemed to have been done through some kind of xss exploit but I have no idea how it managed it as I’m running the lastest WP version. Fortunately Adrian was good enough to point out a wordpress support thread for my exact issue which helped me locate and rip out the source of the spam quickly. This is why it pays to microblog your aggravation I guess 🙂
Btw, I also noticed that the previous malicious cache.php file had reappeared in my wp-content folder. This time I saved a copy before deleting it and now you can all see what kind of crap they put in your server. Notice the quite humorous note telling you that “modified republishing is restricted”. Or what? Are they going to take you to court?
At least this later crack forced me to finally go ahead and lockdown my site even more. Now the site root, wp-content and my theme directory are read-only from my user as well. Let’s hope this doesn’t create any issues. Unfortunately I cannot make the plugin directory read only as very often they need to write in there as well but I don’t think this was done through a plugin so I think I’m good.I’ve also finally changed the prefix for all my database tables to avoid any zero-day exploits which I’ve been meaning to do for a while.
I also tried to install one logging plugin I saw mentioned in the wordpress forum but unfortunately it didn’t work for me. What would be really great however is a way to monitor all your site files for changes and whenever any file is modified or added, an email would be dispatched to the admin. Sure, you might get notifications for when you upload a new plugin or add new images through wordpress’ builtin function but you could easily ignore those. But when you see a change in your index.php that you didn’t initiate, then certainly something needs to be checked.
On a more positive note, I’ve gone ahead and integrated with Google’s Friend Connect. You can probably see it already on my sidebar where you can add yourself as a “member” of the site, whatever that is. I used to have Facebook but that requires you to add a FB application which not everyone cares to do. Everyone and their mother has a a google account by now however so hopefully this may give me a better idea of how many people like the site enough to register themselves.
But I swear, if I get compromised again, I’m going for a complete wipe and reinstall. It can only mean that I’ve got a trojan that won’t stop making my life difficult.
Caching in Wordpress is the best way to increase your performance. This post reviews two new plugins, Hyper Cache and DB Cache and how they can work together
I hope you’ve recently noticed a significant improvement in the speed of the Division by Zer0. I’ve done some further testing and I think I’ve discovered the perfect combination of tools which, at least for me, has made everything much snappier.
Last time I was playing around with Dreamhost’s FastCGI option ((Since disabled as it seemed to cause more problems than it solved)) as well as trying out a few newer caching plugins since Super Cache didn’t really play nice. Specifically I was testing Hyper Cache and DB Cache and trying to decide which one is better to keep. Well, in the end I figured out that using both is even better, and now I’m going to tell you why 🙂
This one is one serious mutha. It basically does the same thing as Super Cache but without requiring you to edit your .htaccess or other such hassle ((And removing it is simple too, unlike Super Cache)). All you have to do is activate and go. And the results are really stunning. With it activated, I routinely get pages loading in sub-second speeds (whereas before the average was 2-6 seconds) on cached pages with very low overhead, which means I can withstand traffic spikes.
I was so impressed I spent an afternoon just reloading pages to admire how fast they loaded 🙂
Of course this plugin will not help with javascripts speed so if you have a lot of ’em, you will still notice your site taking a bit. However you should notice that the loading starts immediately and then waits for each javascript to download and run (so you’ll see the page appear in stages) instead of waiting a bit until it even starts loading (while it’s gathering prerunning the php and quering the DB). As such, if you have most of your javascripts loading at the footer (as you should), your content will appear immediately for your audience to start reading, and by the time they’re one the second sentence, the page will have finished.
My main problem was exactly that incidentally, that the content took up to 5 seconds to even appear. As long as the main text is there, I don’t mind so much how long it takes for the rest of the “bling” to load.
Another good thing about hyper cache is that it will not activate if you’re logged in to your wordpress installation. This means that in order to see the speed of your site as it appears to everyone else, you either need to use another browser (I keep a konqueror lying around just for this) or to clear your cookies. On the upside, it means that you almost always see the current version when you make non-content changes, such as editing your theme (as the cache will be automatically cleared if you make content changes.) This really helps if you like to tweak your site layout a lot.
One last (bad) thing I’ve noticed is that if I go ahead and clear all hyper cache. My site will die with an internal server error. I’ve tried this twice now. I do not know if that is because my site would die if hyper cache was not there or because once the cache is cleared, there some heavy duty function running to repopulate it or whatever. I know it happens though. I don’t have to do this anymore however so it’s not really a problem.
Overall, Hyper Cache is an absolute win for people hosting their own WordPress, especially if you’re on a shared hosting plan and even more especially if you’re using Dreamhost PS, as Super Cache is not an option.
This plugin takes a novel approach to caching. Whereas all the other that exist simply save the html output of your content and then serve it to avoid running PHP code each time a page is requested, DB Cache saves database query output to avoid making SQL calls to it.
This has a few significant benefits. First of all, it helps with Search Engine crawlers such as the google bot. Where a normal caching plugin really shines when a lot of people access one specific page, it actually harms you when one agent accesses a lot of pages, since you add the cache-saving to your load, on top of the normal page loading. DB cache on the other hand, by caching common Database queries, can fill exactly that hole which significantly reduces the juice you need to serve all the bots crawling you.
This is becauseeach page of your site, other than the main content and possible some post-related queries (ie similar posts), has basically the same calls. Your recent posts, your tag clouds and category lists, recent comments etc, depending on what widgets and theme you use. These generally don’t change from page to page but for a normal caching plugin on a new page, they still need to be called so that the full html page can be saved.
So by caching all these common calls, you seriously reduce the time one needs to wait on a blank screen before a page can even start loading the content. You also reduce the load when a crawler does his daily thing and you even increase the speed of the occasional visitor from a mobile. While DB cache will not give you the awesome speed hyper cache will on a single page load, it will certainly reduce your overall server’s CPU & RAM load (much more important than bandwidth and disk space for shared hosting) and make visits to uncommon pages quicker.
Another plus which I’ve discovered is when you are using Gallery2 through the wpg2 plugin. Gallery is imho a database chewer because people don’t simply see one image and then leave, but rather switch quickly among a lot of them. As a result, DB Cache is perfectly prepared to grab those common queries done through wpg2 and save them for later, increasing the overall speed.
Until now I’ve never mixed caching plugins as they all generally worked in the same or similar way. However the distinct way these two worked gave me the impression that they wouldn’t really conflict and might actually complement each other quite well. One of them is built for serving one page to lost of visitors in a short time period, while the other is perfect for serving many pages to one visitor. So I went ahead and activated both of them at the same time
And whatdayaknow, there was no explosion 🙂
What happens at the moment is that generally, a page always has at least a few queries cached by DB Cache. You can even see the cached queries increasing with each time it’s reloaded (when bypassing hyper cache). This in turn allows a non-hypercached page to load quicker which is then saved into hyper cache for further visitors.
So currently you see the results of this experiment. I’d like to believe that my speed at the moment is quite good and others who have followed my advice have experienced similar improvements. I really hope this is the last time I have to play with caches in the future and that the current speeds are not just an illusion.
Let me know of the results if you try the same combo on your own sites.
Did you know about the amazing potential of Wordrpess excerpts? This is a short description and a link to an excellent article explaining their utility.
I’ve always wanted to put the excerpt field provided by wordpress to some good use but I never really realized what the best way to go about it would be and/or why I should spend the time writing an extra piece of information for the post. Until now I’ve sometimes used them for replacing the frontpage snippet in case it broke due to not properly close html code and the like but nothing more than that.
In the end, the utility of the excerpts was so obvious that I had to slap my forehead for not thinking of it myself. Thankfully, someone else not only went to the trouble of explaining why excerpts were useful but also provided links and information for the tools you can use to utilize them best.
From: The manual Excerpt in WordPress. What, why, how, tips and plugins
WordPress excerpts, which are not excerpts, make a WordPress site easier to browse and its content easier to discover. In addition, when also used as META descriptions, good excerpts bring more and better traffic from search engines.
If you’re using wordpress, especially if it’s self-hosted, this is the kind of article you should be reading right now. The insights and improvement ideas would certainly make you rethink the way you utilize this underused feature and the concice and structured way this is presented makes the whole thing easy to go through and understand. As one commenter put it
Heard a cling and a thud ?
Well, it was my awesomeness-meter crashing !What a post. Dugg deep, very deep into something that’s insanely powerful, but not appreciated, the WP Excerpts !
As for me, I’m already going through my latest posts and adding descriptive excerpts to all. I’m not going to go back to all 3 years of blogging (almost 4 now 🙂 ) but I plan to go through the last year at least.
More attempts to improve the performance of my Wordpress site through new Caching plugins (Hypercache and DB Cache) and Dreamhost’s FastCGI.
Improving the speed of this and my two other sites has always been a major issue for me. Ever since I’ve switched to WordPress I’ve never been fully satisfied with the loading time and it seems I’ve been trying since forever to improve it. My main methods were through the use of caching plugins such a WP-Cache and later on WP-Supercache and through manual performance tweaking. For a while it seemed to have worked to a degree until again my performance started dropping without any apparent reason.
It was at this point that I jumped to the VPS offering in a desperate attempt to get a site which loads in this century. Again, for a while things looked to be working well but now and then I would get horrible site b0rks which would take me hours to troubleshoot and resolve. The latest one was the reason I discovered that WP-Supercache didn’t play nice with VPS and thus I had to find something else, or live with it in a state of half-on.
To my delight, it seems that now there are new caching plugins available which I can try. I already mentioned Hyper Cache last time and today I discovered DB Cache (h/t diTii.com) which seems particularly promising, especially because it works not by caching the fully loaded page, but rather by caching the Database queries themselves. This is an interesting take on caching since it now can improve performance for web crawlers as well as normal users. It also provides an extra benefit to me since I’m proving a gallery through the wordpress interface, and that means that the database queries for that are also cached.
So I ditched Super Cache from all my blogs and installed DB Cache on the Division by Zer0 and the Wesnoth Journals and Hyper Cache on the ACP. It’s of course always difficult to figure out how much difference a caching plugin has done to your site. As of now, I can’t say I notice a significant difference on loading times with DB Cache, however I did notice that the number of SQL queries that are made each time the page loads have dropped from >60 to about 15 which means that there some difference.
I have also noticed anotther thing. In the past it could take a few seconds before my site even started loading (I guess while it was running the SQL queries) but after that it would be displayed very quickly (especially if it had been supercached) whereas now, the site starts loading very quickly but it takes more time to actually finish loading the content, in effect loading in parts (first the header, then the content etc) but in a way that is much more exaggerated than before.
Another thing I also decided to do is to finally activate Fast CGI for PHP. I hadn’t done this before as it wouldn’t have made much difference when Supercache was in use but now that the code is executed every time, it seems like a good idea. There’s also the added bonus that for VPS, the Xcache opcoder is available which further improves php performance when on high load. I do not think it will make much of a difference as my problem is not one of traffic but it may come in handy for those rare reddit moments.
As of now, the performance seems comparable to SuperCache times and I am hoping that this time I will not have any more random Internal Server Errors. Unfortunately my WordPress admin panel is still quite slower than I’d like with loading times randing frmo 5 to 15 seconds or more on occasion. I honestly don’t know what I can do to fix that but at least the admin panel is not something that is used very often.
Next step will be to see if Hyper Cache is better than DB Cache and if they can both play well together for a combined improvement.
So what do you think of the current speed?
I’ve moved the site to Dreamhost’s VPS offering but my support experience since has been less than optimal. Are we on our own?
Another month, another total crapdown of my sites which are hosted at the moment in Dreamhost’s Virtual Private Server offering. Once again the story begins in the usual way, all three of my sites start puking Internal Server Errors all over the place which generally means that you are out of available RAM on your server. As I generally have about 180 Mb of availability, it would meant that either I have a huge amount of traffic that my Cache did not alleviate, or that something is going wrong on the server.
Going to the Resource Management, I am greeted by a classic figure
Having looked at my traffic already which had stayed steady in the last days, I know that this is certainly caused by some server/app malfunction. I know this from experience because the same goddamn problem happens to me so regularly, it’s not even funny anymore.
Since this happened while I was at work, I could troubleshoot it through the terminal as they have the ssh ports blocked so I had to wait until I came back home to investigate. Once I arrived, I fired up an ssh connection and checked what processes were running. As expected, it was PHP in CGI mode that was sucking my life’s blood.
Now mind you, I know all this because I’ve done it before where I had to google around and learn which commands to use to discover this info. The first time it happened, my ram usage was slowly creeping upwards in jumps of 30 Mb per week or so. After that, it simply happens all at once suddenly.
Now this is extremelly difficult to troubleshoot as you can have no idea what is causing this. A php5.cgi process can be anything under the sun that runs on PHP. Basically the whole wordpress interface or any of the dozens of plugins I have installed. You can kill the processes but this will not tell you what is happening and as it does not happen persistently, you can’t figure out which plugin might be causing it as shutting down a plugin does not stop the process and you don’t know when a process will get stuck again.
Unfortunately, and this is what is annoying me mostly, Dreamhost’s answer in the past has been that “It’s not our fault. Figure it out yourself”. A very unfulfilling answer as you might guess. But at least I know that I can expect very little help from them anymore so I avoid them.
So then I got to process killing. Unfortunately this time it seems that I had found a resistant strain of bug. As soon as I killed a process, 5 seconds later and a new one would be spawned, then another and another, until all my RAM was eaten up, no matter how much I increased my available. At this point I was fast reaching a deadend with my current skills as I couldn’t make the problem go away. I couldn’t even access my wordpress’ admin panel to disable plugins.
At this point, a former colleague suggested that this might be caused by a known PHP 5.2 bug which leaves processes hanging when done with them. I thought this might be a good thing to suggest to Dreamhost support to check so I fired up a support ticket.
A while later, I noticed that the RAM usage seemed to have dropped off so I thought that the problem had resolved itself. Unfortunately, while the main page was working the admin panel refused to work.
In desperation I did a quick server reboot and this was the point where the universe b0rked. After the reboot the whole site was off and my memory usage was stuck at around 20Mb which means that basically the whole thing failed to load. I fired a new ticket to support and waited.
I had to wait until today for an answer which basically told me that they managed to get the sites running again but advised me that my RAM usage was high so I should be checking that and no, they still can’t help me. Thanks Sherlock…
Looking around the interwebs however, I did stumble on a page in the dreamhost wiki where there was a note under supercache under caching that warned not to utilize the “super” part of WP Super Cache as it may drive resource use up on Private Servers. Gee, it would be nice if I knew of this a bit before. It would also be nice if Super Cache was not installed as part of the standard one-click installation of WordPress by Dreamhost which makes people assume that if anything, this plugin will be working well.
So I disabled Supercache on the Division by Zer0 and on the Wesnoth Journals and killed the remaining php processes. Lo and behold, no more processes were spawned. Unfortunately I was lucky that I could access the admin panel of these two sites after I increased my available resources to some ungawdly amount (1.5Gb of RAM or so). Unfortunately I was not so lucky in the Antichristian Phenomenon where not only I could not access the admin panel (never finished loading) anymore but the php processes kept spawning repeatedly and fast.
I tried deleting the plugin directory which led to my whole page being turned off. I tried fixing the .htaccess file. Nothing. Anything I tried, I couldn’t get the site to work properly. So I did the only thing I could do, renamed the whole wordpress directory and reinstalled again. At least this gave me an opportunity to finally rename the prefix of my database tables which helps avoid zero-day exploits by script kiddies. After a few hours, the site was back online.
Unfortunately the latest ordeal has really disillusioned me about Dreamhost’s PS and their support of those. From the 3 times I’ve contacted them about issues in randomly increasing resources, their reply has been “Deal with it yourself” because apparently now I control everything on the server and if anything goes wrong, it must be my own scripts or whatever. Seeing as I only use standard software like WordPress and Gallery this reply does not help me much.
Basically what seems to be happening is that when one decides to go to a PS in order to get a bit more speed (since shared hosting seems at time to be powered by hamsters) you’re on your own. If you’re not a (quite) techical user and have made the grave error of installing wordpress plugins on your site, you’re fucked. It seems that as far as Dreamhost is concerned, you shouldn’t be running plugins in the first place. Just vanilla WordPress for you.
Luckily for me, I know a few UNIX commands and how to use an ssh shell to do some troubleshooting. However even for me this kind of response is definitelly inferior. It would be nice if I could expect the Dreamhost support to ask questions like “Are you using WP Super Cache?”, or something similar. It would be nice to expect the support people to know of a few issues that generally might cause this kind of trouble. Is this is all too much to ask? Is it too much to ask to expect some attempt to help your users?
Last time I was delighted when the support tech gave me a simple command to help me trouble shoot but since then, all replies have been to explain me that it’s my own damn fault and this is very disheartening. To everyone considering the Private Server offering, if you’re not very technical and open to spending a few hours now and then to troubleshoot random issues that occur without you changing anything, then stay away from it and stick to simple shared hosting.
As for me, now my sites are all in the classic WP Cache mode and I’ve used Hyper Cache for the ACP to see how it goes. If all goes fine, I will switch everything to Hyper Cache and drop Super Cache altogether. ‘Till next time my site craps down…