rklrkl

The function s() in download-moniitor/vendor/symfony/string/Resources/functions.php uses the “??=” operator, which was introduced in PHP 7.4, hence this fails in PHP 7.3.

The exact PHP versions I tested with Download Monitor 5.0.0 were:

7.3.33 – fails with the error message I mentioned

7.4.33 – works

8.0.30 – works

8.1.29 – works

8.2.22 works

8.3.10 works

Except that the https://www.ads-software.com/plugins/cloudflare/ page says “tested up to 6.2.5” and this has triggered a warning banner on that page about not being tested on the last 3 major WordPress versions. I suspect this oversight has put off a lot of people from installing the plugin, so it really needs to be fixed!

We deal with a large number of commercial WordPress plugins (and their free equivalents) and your plugin may be the only one we’ve seen that has the same name/install dir for its free vs. paid plugins, so the de facto standard for this appears to be to have separate names/install dirs, which you unfortunately ignored when you launched your paid plugins.

I can understand your reticence to change the paid plugin names for fear of deactivating the plugin, but couldn’t you release an interim version with the original paid plugin name first that looks for a deactivated renamed paid plugin and if it finds one, deactivates the originally named paid plugin (i.e. the one running this checking code) and activates the renamed paid plugin, then exits the code (not sure if a plugin is allowed to do this in WordPress though – might be considered a privileged operation that could be used to sabotage other plugins…).

Note that one of the sites we have the Plus paid plugin installed on has got itself “stuck” on 2.6.5.12 despite having a valid license key and the “SUPPORT” section of the plugin claiming (today) that 2.6.5.12 is “up-to-date” (it clearly isn’t – 2.6.5.28 was out recently). I suspect you had a bug in that 2.6.5.12 release w.r.t. version checking – you can’t update it either from anywhere in the WP admin interface or WP-CLI.

We haven’t filtered any of the logging or changed the default 60 day expiry period. We had to click on “Clear log now” 2 days ago to reset the tables (which brought their .ibd sizes down to 128K each).

2 days on, wp_simple_history has 150,000 rows and simple_history_contexts has 1.35 million rows! There’s over 8,000 WordPress users in the DB and most of those login every weekday – it’s a very busy site as I said and I’m not seeing a lot of failed logins in the tables either.

I think what’s needed is some control over what is actually logged – I’m seeing a lot of entries related to valid logins which I’m not that interested in and would like to disable logging for (because it doesn’t change the site). I sent in a feature request about that last year:

https://github.com/bonny/WordPress-Simple-History/issues/204

Having control over what Simple History logs would allow us to filter out stuff we’re not interested in and reduce the size of the DB tables. It still concerns me that we’re seeing over 600,000 DB entries added to the simple_history_contexts table in a single day, which is somewhat “bonkers”.

“Show search options” link on the search page of Simple History expands to include a Users filter text box, in which you can add multiple users (does some on-the-fly user string matching too).

Any words searched for will then be restricted to those users only (leave “Containing words:” field blank to get all the records of all of those users).

• This reply was modified 4 years, 11 months ago by rklrkl.

Just a note that WP 5.0.2 with Yoast SEO 9.3 enabled still breaks both the TinyMCE *and* Gutenberg editors – they both lose their editor icons and all the text in their main editing areas when in visual mode.

Now another user in this thread has confirmed the bug, this has become quite a serious issue for all IE11 users. Sadly, our clients don’t want to or can’t switch away from IE11, so we’ve actually had to disable the Yoast SEO plugin on their sites until this rather major bug is fixed!

Yes, I was going to suggest that too – moving the “Tested up to” info onto the www.ads-software.com site instead of inside the .zip file. Another thing I don’t like about the .zip files is that there’s no rigid file naming scheme for them (e.g. plugin-name-version.zip or something like that) – some .zip filenames have the version numbers, some don’t, some use separators between the plugin name and version and some don’t…

WP-CLI’s new “plugin verify-checksums” has been highly illuminating indeed. I’ve found a site we host that is using a plugin that’s completely undownloadable from www.ads-software.com any more (so no checksums to check!). Another useful feature is to detect if one of our devs has modified plugin code (yes, I found one that been modded – turns out that was the only way to use it – directly hack a line in the plugin PHP code!).

I think the WordPress core team need to think about this one!

Whilst you’ve followed “best practice”, it leaves the door wide open for abuse of .zip updates of the same version with code changes (not just readme.txt updates). I’ve now counted at least 6 plugins on wordpresss.org that have actually changed code (and one even included new png’s in the .zip!) and kept the same version for the plugin on a subsequent .zip upload.

Even your minor change to readme.txt will never be picked up as an udpate for anyone with an “older” 1.1.0 installed (never mind the plugin checksum issue I’ve mentioned).

Personally, I think the only safe way is to increment the version number for *any* .zip contents change, even if it’s just one line in readme.txt to say it’s been tested on a later WP release. Then www.ads-software.com can simply refuse to upload a .zip file that contains a plugin with the same version as one that’s already uploaded. It will also make sure that everyone who has “1.1.0” has *exactly the same* “1.1.0” as everyone else!

It may have been the default “feature” of the plugin since day one, but that doesn’t mean that the default was ever correct. I don’t expect *any* WordPress plugin, no matter what its function is (maintenance or not), to take my site offline immediately the first time it is activated.

If you insist on keeping this incorrect default, please state very prominently in all obvious places where you’d download (or activate) the plugin that your site will be taken offline immediately when you activate it for the first time. This is extremely unexpected behaviour for a plugin, so the end user needs to know in advance.

FYI, we’re no longer recommending this plugin to any of our clients because of this default behaviour – we’ve moved to other maintenance plugins (none of which take your site offline unexpectedly like this one does).

A colleague just installed the latest version of your Maintenance plugin (luckily not a live site) and was as equally shocked as I was that it *still* takes your site offline as soon as the plugin is activated for the first time.

I’m disappointed that in the 10 months since I raised this issue, this dangerous and unexpected behaviour remains the default for the plugin. I’m also puzzled how this topic is in “Resolved” status because it clearly isn’t. Can you name one user of the plugin (apart from yourself) who thinks that taking the site offline immediately upon first activation is a good idea (the fact it also uses a design for the maintenance page that you might not want either doesn’t help matters)?

> The reason why WP RSS Aggregator requires PHP 5.3.9 or higher can be found here.

That page states that “old-er, unsup-port-ed ver-sions of PHP no longer receive secu-ri-ty fix-es” being the main reason for dropping support. Unfortunately, this shows ignorance of Red Hat/CentOS’s backporting of security/bug fixes to older releases, but note that they don’t backport features from later PHP releases. Hence, “PHP 5.3.3” in CentOS 6 is actually “PHP 5.3.3 plus all security/bug fixes that could be applied to the 5.3.3 codebase from all later PHP releases”.

The second link to Coen Jacobs blog shows exactly the same lack of knowledge about RHEL/CentOS PHP backports – those backports are supported until November 2020.

CentOS 6 does have PHP (5.3.3 with the backports I mentioned) in its standard repos and is installed as part of a “Basic Web server” config. Rackspace do have an iUS repo that provides both PHP 5.6.X and 7.X, but this involves significant language changes that can break PHP 5.3.X-based sites (I tried the update on one of our CentOS 6 dev systems and several sites broke).

Yes, we are slowly migrating our CentOS 6 sites to CentOS 7 with the iUS repo (PHP 5.6.X), but it will be quite a while before that is completed. As I said, some PHP 5.3.X sites give us grief when even just going to 5.6.X. which is why compatibility with PHP 5.3.3 for WordPress plugins is important to us.

It should be noted that when other popular plugins have accidentally or deliberately broken compatibility with PHP 5.3.3, they’ve usually been accommodating when I point this out and will fix their changes to work with 5.3.3. Those that don’t force us to look for alternatives and also stop recommending the incompatible plugin to anyone running a long term Linux distro (which is what most hosters do!).

BTW, I only mentioned PHP 5.2.4 because that’s what core WP supports. For example, CentOS 5 only runs PHP 5.1.6 and clearly isn’t a candidate for plugin support (its backporting support stops next month anyway). There probably aren’t (m)any long term distros left that still run PHP 5.2.4, so I’m surprised WordPress haven’t raised their core code’s PHP minimum to, say, 5.3.3.

I do suspect that plugin devs like yourselves don’t run any long term Linux distro to do plugin testing on – unfortunately, as I said, these are exactly the distros that hosters run. I’d recommend throwing in the oldest supported LTS distros of SuSE/Ubuntu/CentOS into some VMs and test against them.

• This reply was modified 8 years, 1 month ago by rklrkl.

I would suggest looking at WP-CLI for this:

https://wp-cli.org/

Enable maintenance mode permanently and then you can use these commands to activate or deactivate the plugin (where “webuser” is the user the Web server runs as):

sudo -u webuser wp –path=/full/path/to/web/tree/root wp –path=/full/path/to/web/tree/root plugin activate maintenance
(would activate the plugin and switch on maintenance mode)

sudo -u webuser wp –path=/full/path/to/web/tree/root plugin deactivate maintenance
(would deactivate the plugin and switch off maintenance mode)

It’s a common misconception that core WordPress requires at least PHP 5.6 – that is actually the recommended version if you read this page:

https://www.ads-software.com/about/requirements/

Developers just see “5.6” and don’t read further down:

“WordPress also works with PHP 5.2.4+ and MySQL 5.0+”

It should be noted that CentOS 6, which has 4 years of support left, ships with PHP 5.3.3 (bugs/security fixes are backported from later PHP releases, but new features aren’t). A standard WP 4.6.1 install on CentOS 6 works perfectly, but some third-party plugins are starting to ignore the 5.2.4 minimum PHP requirement and it looks like Multiple Featured Images is yet another one.

As it stands, I’ve had to hold back updates for Multiple Featured Images so that it stays on version 0.3 (which is compatible with PHP 5.3.3 if not even older PHP releases). And, no, it’s non-trivial to upgrade PHP beyond 5.3.3 on CentOS 6 (I used the IUS repo to attempt this, but it broke a fair number of sites). It woould be nice if Multiple Featured Images could be updated to support pre-PHP 5.4 releases – after all, it did do so before version 0.4 came out!

Can I suggest that the next release of wp-share-buttons is accelerated ahead of schedule to include the fix mentioned in this thread? As it stands, popular hosting platforms like CentOS 6 can’t use version 1.3.0 of this plugin without hand-patching it.

Also note that WP core minimum PHP version is actually 5.2.4 and it’s probably best practice for plugins to follow the same minimum PHP version.