Brian Coogan
Forum Replies Created
-
Forum: Fixing WordPress
In reply to: Query Caching with ProxySQLThis is a very dangerous approach to caching – there’s almost no way to know which queries will need to return updated results.
If you want to make your site fast there are two techniques I’d use, instead.
1. Use a premium cache like WP Rocket. It solves many problems instantly, automatically, and at install time (see below though).
2. Tune your MySQL to have larger buffers, which will mean that it will hold much of the database in memory.
And a free third tip:
Move to Litespeed or Open Litespeed with Litespeed cache (and remove Rocket). This is probably faster than #1 above.Also make sure you’re using PHP 7, it’s much faster than 5.6.
I know these recommendations are very specific; these are just what has worked for me very consistently over time.
Oh – and delete that dangerous broken plugin!
Cheers
BrianForum: Fixing WordPress
In reply to: Missing a temporary folder errorI had this error happen and the problem was an old theme. I temporarily switched theme to one of the default WordPress themes (‘twentytwentyone’) and the error disappeared, at least in my case. I could see a whole bunch of JS errors in the browser console log (F12 in Chrome).
I did check out the temporary folder stuff above, but it didn’t seem to be key for me. Worth noting that my theme was VERY old and VERY broken (ie: PHP 5.6 days!), but just mentioning this in case someone else like me has tried everything else!
Forum: Plugins
In reply to: [WPS Hide Login] error link when accessing wp-adminWe also have this identical error from Divi and WPS Hide Login.
Disabling the WPS Hide Login plugin solved the issue immediately, though we’re also chasing Divi for a proper fix.
It would also be nice if WPS Hide Login fixed their side of this as no doubt it’s a clash caused by recent WordPress changes, and I suspect it will affect more and more people.
Cheers,
Brian
Also interested in this feature. Nobody seems to have it.
I think it could be accomplished by some current sliders that use posts to contain their images as featured images, but that’s clumsy for users. I’d prefer to stick with a plugin like Meta Slider that is popular and well maintained.
Any chances of getting this included?
I’m wanting to avoid updates to a specific plugin. Toying with the idea of creating a .hg folder in the plugin as it sounds like that would be enough to stop automated updates for now (which I want to allow).
Gary,
Does that mean the filter auto_updater_plugin_updates no longer works?
Cheers,
Brian
Forum: Hacks
In reply to: Plugin generating virtual pages, issue with the_content not runningOK – as posted above, the solution of providing a dummy post via a filter for the_posts was the working solution I ended up with.
I’ve documented this in full gory detail at:
I ended up using part of Xavi Esteve’s solution to allow me to trigger the virtual page as well as allowing the page template to be overridden.
None of the solutions out there at the moment seem to work without warnings or errors; I suspect WordPress has evolved since they were originally published.
Forum: Hacks
In reply to: Plugin generating virtual pages, issue with the_content not runningI guess there are two parts to the actual task:
1) ability to use a different template other than the page template, using template rules and child theme awareness.
The solution to this appears to be the above code, replacing the include with a call to get_template_part().
2) ability to fool the loop into running and outputting the_content.
A solution to this seems to be achievable by using the_posts filter, at least I have a solution more or less working at the moment.
At the moment I can’t see anything other than a hybridization of these two working.
It looks like Scott Sherrill may have been the first to write about this originally in 2007 and multiple people have picked up that work, including the current clearest article I found:
http://davejesch.com/wordpress/wordpress-tech/creating-virtual-pages-in-wordpress/A comment is displayed if $wp_query->current_comment is set to -1, the fix being to set it as shown to a null string.
$wp_query->current_comment = ''; // -1 shows a comment sometimes??
This behaviour is particularly weird as current_comment is usually -1 for a normal page!In any case, a combination of these two seems so far to be working, although it’s early days.
IMO it would be nice to see WordPress stepping up to the mark and providing a simple interface for this, as it appears they are regularly breaking other options. Such an interface would provide ability to specify a template, content and title. This sort of functionality is required when items may not be reflected in the post structure, for instance, product pages, credit card acknowledgement pages, and many other page applications that may be completely dynamic. It seems like this is being requested regularly on stackoveflow and on here and nobody has been capable of providing any answer to nearly all the posts.
Thanks to the generosity of bcworkz for providing some crucial clues to solving the issue!
Forum: Hacks
In reply to: Plugin generating virtual pages, issue with the_content not runningThanks for your input, that’s really helpful.
Is there a way to simulate content so the loop fires? I can probably research this on my own.
I hate to alter a running theme, even a child theme, seems to violate various “keep it clean” principles.
Aaron,
Haven’t had time to follow this in detail, but it sounds like a nice piece of work! Thanks for following through on this, I’m sure many users (and hosts!) will enjoy the results!
🙂
Ross, when the account is hacked they can disable the SymlinkIfOwnerMatch setting in the local .htaccess file; not 100% sure whether the host would have been able to make the setting forced on. I’m afraid all the stuff after “As for the permission model…” is just not relevant in this case. And regardless, there is a reliable race condition that can be used to exploit the server even if it has SymlinksIfOwnerMatch set!
In any case, for it to be used to hack your account, they don’t need to change the setting in .htaccess as they only need to use one account on the server to hack all the others – it’s used to read the wp-config.php file and the details from that file are used to hack your site’s database.
So, long and short of it is, change your wp-config.php to mode 600 and change your database password after doing that (again if you had already done it!).
And you could helpfully pass this info on to the host. Most hosts don’t understand this, so they’re totally not alone!
ps: even if apache is fully protected, there are other ways to read any file on the server. openbasedir can be avoided in a wide variety of ways. Now this style of hack has started, you can guarantee that clever hackers will mutate it fast. Change your wp-config.php file mode now to avoid the rush!
rossagrant, the point the host is conveniently ignoring is how the language got changed to UTF7. If that’s the default, then there’s no issue and you should stop reading this now.
However, I suspect the database was changed to change the language, then the database was changed to enable the widget exploit.
Your protection against this is to make your config file mode 600 as described above, and then to change your database password through cpanel and save in the newly protected file.
It seems that about 50% of hosts are not protected against this, and the “Badi” character seems to have been using this Apache symlink exploit elsewhere as well, from what I’ve read.
Kyunuga — you really should have had your own backup, and blaming the host and the developer doesn’t change that. Yes, they both should have had backups, but so should you! Strongly recommend automating a backup of your site to an off-server machine, given the lack of your hosts’ understanding of security. (speaking as a host)
ps: Installing the free version of the Wordfence plugin may also help slow down these exploits, as it should block the majority of the SQL exploits.
Based on what you folks are saying, there are some factors here that are consistent with this being the Apache-symlink-cross-user exploit that has remained unpatched largely due to cPanel and Apache both being unwilling to step up to the plate and solve this one.
The factors that lead me to think this is consistent symptomatically are:
- no (or few) visible file alterations
- more than one account hacked on same server
- plain HTML sites not getting hacked (as they have no databases)
The hack works by exploiting another account on the server somehow, probably through outdated or insecure scripts. Once that is done, the symlink exploit is used to read the database username and password for other sites on the same server (ie from your wp-config.php files) and use that to attack your WordPress installations. Joomla sites and anything with a guessable db config filename are also being attacked.
There are two fixes to this, both of which need to be put in place. The first is an Apache patch, which needs to be installed by the host at the server level, requiring root access. The patch makes it much harder to exploit the symlink issue, although there is a way around the fix via a race condition. The second part of the fix is to change permissions on all .php files to mode 600, which prevents the cross-user part of the symlink attack from working. It’s actually sufficient to change mode of your wp-config.php file to 600.
Warning: Some servers run Apache and PHP in DSO mode under a single shared user. If this is the case with your host, it’s fundamentally insecure and this patch won’t work. However, the server is already insecure anyway and doesn’t need symlink exploits as the config files can just be read. If your website stops working when you change your wp-config.php file to mode 600, then you have this problem and you either need to get your host to address it, or move hosts.
Summary – change the mode on your wp-config.php file to mode 600, and change the password on your database and, if the hack is via this method, you should be protected.
For hosts, I have a brief discussion and more details on the fix at http://whmscripts.net/misc/2013/apache-symlink-security-issue-fixpatch/
Sorry to be so very slow to respond to this.
I had a look at the code, but without diffs or some idea what you’d done it was hard to follow.
What needs to be done is to schedule the cron jobs at the time the next post needs to change. That way you get as near exact granularity as you can while not wasting CPU cycles (and getting blogs running your plugin into trouble with hosts like myself! :)). More seriously, many hosts these days measure excess CPU users and kick blogs off if they are violators.
If you like, you could schedule an hourly check for cron being set correctly, it’s only when stuff polls every minute that you’ll run into trouble.