KZeni

@kasparsd Thanks a bunch for the fast response. I also noticed you updated the linter to better catch stuff like this per https://github.com/WordPress/two-factor/pull/605 which is definitely great to see!

Can confirm this new version doesn’t have the issue 0.9.0 had. Thanks again!

@sminozzi Wait, so does it work fully properly with PHP 7.4.30 in your testing?

WordPress having a recommendation of a PHP version of 7.4 or higher on their https://www.ads-software.com/about/requirements/ page (and then notified within the site admin for older PHP versions worth noting) doesn’t mean a plugin should just have the required PHP version it states not be maintained where it says it works with versions that it then has issues with.

If that supported PHP version within the plugin info is actually just being ignored in development & support in favor of just following the WordPress core’s recommended PHP versions, it should probably just have that required PHP version removed from the plugin’s info as it seems like it’s saying it works with PHP versions that currently have issues & just leads to confusion. Or, honestly, if development & support is currently just deferring to WordPress’ recommended PHP version, why not just update the plugin’s required PHP version to be 7.4 to match that?

@digbymaass What PHP version did you have when the log wasn’t working & what did you update to?

I ask since @sminozzi might want to update the plugin’s currently specified PHP version requirement of 5.6 or higher (which is quite old & generally shouldn’t be used by sites now anyway) to be at least newer than whatever PHP version you were using where the log wasn’t working due to PHP server errors (or update that functionality to work properly with PHP 5.6 as that technically would address it as well or even just give a message explaining why the log isn’t being shown when trying to view it so the rest of the plugin works as it does now on those older PHP versions while one is then informed of what they need to do to get that working) so others don’t get confused by this current behavior.

Simply put, the plugin’s info says it should be working due to saying it supports those older PHP versions when things in the plugin actually don’t work properly with those PHP versions currently & should probably be updated (then probably looking at implementing 1 of those 3 suggestions I just mentioned.)

As an aside, it also looks like the readme.txt file for the plugin is malformed (and technically was also malformed in previous version[s].)

You can see on https://www.ads-software.com/plugins/stopbadbots/ how the Changelog isn’t detected to show under the Development tab as it should/does for all other plugins (and weirdly shows the heading as “Stop == Changelog.txt”), the FAQ section doesn’t have the collapsable sections like it should, oddly has Additional Tags as a section to seemingly just spam keywords when the WordPress plugin directory has a policy to only allow up to 5 tags (while this plugin then only has 2 of 5 available tags being used for the actual tag setup WordPress wants developers to use), etc. That last one seems like it’s outside of WordPress’ plugin policies & guidelines and should really be cleaned up as nobody wants plugins to just stuff their descriptions with keywords due to not following best practices & instead using black/grey-hat techniques to gain visibility (Google doesn’t like that on websites & WordPress [which has already said you can only list 5 tags in their plugin guidelines/requirements] certainly doesn’t want that for plugins either.)

Hopefully, this can get cleaned up at some point too as it’s definitely not a good look for this plugin on top of just now releasing a version that breaks people’s site(s) after updating.

So much about this plugin looks to be in a broken, problematic, or nearly-broken state, right now. Spring cleaning of this plugin (and others from this dev) to tidy things up would be very welcome to see to warrant still trusting/using these plugins. Seriously, I feel that if this plugin, as it is now, were to be seen as a new plugin being submitted for plugin review it could legitimately fail to be approved, but the plugin team’s checks when it comes to updates made to already-approved plugins just aren’t done anywhere near that degree as when first submitting a plugin (which points to how these plugins should be reigned back in.)

I mean, checking the last version of 8.x (and earlier) of this plugin’s readme.txt (https://plugins.trac.www.ads-software.com/browser/stopbadbots/tags/8.07/readme.txt) showed this plugin didn’t start spamming tags in the description nor had malformed headings for things like the changelog, etc. until versions 9.x through this latest version & it apparently just hasn’t been caught by the plugin review team yet.

An added bonus would be to get this plugin listed on GitHub for better community support & proposed fixes/improvements (then adding that GitHub link to the plugin description so potential users of this plugin can know this may be more open to those community features.) Also, that’s one way one gets better plugin visibility… not by spamming keywords in a plugin description.

What’s interesting is that the /wp-content/plugins/stopbadbots/functions/functions.php file has //debug2(debug_backtrace()); on line 5348 so it’s been commented out elsewhere in that same file whereas debug2($stopbadbots_is_human); is on line 5291 uncommented & is resulting in that fatal server error.

– Proposed Fix –

Taking a hint from the other debug2 call in this same file, I commented out that debug2($stopbadbots_is_human); call on line 5291 while keeping everything else about the version 10.12 release as-is. That looks to have fixed the fatal server error (looks to be back to working as expected.)

Hopefully, 10.12.1 can be released as soon as possible with that one debug2 function call commented out (or just put it in a conditional statement where it just checks if that function exists before calling it if it still serves a purpose when available [ex. developer might have it as an internal testing/debugging tool for themselves while it then should just make sure to not try to be called as part of the public release with the function_exists conditional statement making it so they don’t need to worry about commenting/uncommenting these calls upon release/etc.]) so fewer sites encounter this release that has a fatal server error.

@digbymaass Ah, yeah, it’s rather hidden when it can sometimes be one of the most useful resources for a plugin (definitely odd that it then shows as a tab when viewed and then isn’t a tab when viewing any of the other plugin details & is relegated to that link in the right sidebar… oh well, at least it’s there, hah.)

Yup, I’m getting an error of:

Fatal error: Uncaught Error: Call to undefined function debug2()
in /wp-content/plugins/stopbadbots/functions/functions.php on line 5291

after updating this plugin.

I’m really surprised to see something like calling an undefined function as I’m left unsure how this would be working for anyone at that point (did they get the debug2 function to be loaded within their PHP/site environment for a less-than-common setup while then not having it check to see if the debug2 function exists before calling it…? Or was the debug2 function expected to be included in the plugin & somehow didn’t upon release…?)

The error seems to be encountered when trying to view the public web pages of the site (thankfully accessing the site admin doesn’t encounter a fatal server error with this.)

This seems like something that needs an immediate fix and/or have an immediate re-release of the 10.11 version as 10.12.1 so that’s seen as the latest version & the buggy 10.12 release stops being deployed to sites as soon as possible (if fixing the issue with this 10.12 release properly will take a fair amount of time.)

@digbymaass While I’m glad your backups worked, it does look like https://www.ads-software.com/plugins/stopbadbots/advanced/ does have past versions available (always check the “Advanced View” link [found in the right sidebar] of a plugin’s listing for past versions that were tagged in the plugin’s svn repository [which is also then linked to via the “Browse the code” and “SVN repository” links within the Development tab of the plugin details which then has direct access to the tags folder of those past versions & other assets]) so it seems curious why rollback didn’t work for getting a past version for you.

Sounds good to me! Thanks!

I’d imagine something like Gutenberg has styles where they’re much more likely to be unique to one particular page where it being inline then makes more sense (I’ve also seen block editor devs mention how further performance optimizations to consolidate & serve up styles in a more optimal way is a goal after multiple people brought up how too much inline styling can be detrimental for performance.) That said, CSS that’s largely/entirely the same across all webpages would have much less of a need/reason to be inline on every single page. Certainly, we’re not about to make all theme & plugin CSS entirely inline on all pages, right? With that in mind, I feel this plugin is more akin to a theme’s site-wide CSS rather than something like Gutenberg’s block styles where block(s) and/or their styling could be entirely unique for a given page.

It’s certainly a balance. Yes, it’s 1 more network request to grab the CSS file, but it’s however many KB of that CSS then not needing to be loaded on every single webpage while that CSS file really only makes that 1 additional network request once per browser caching then holding onto it for however long (some sites then having their CSS files not expire in browser cache for something like a year.)

I’m certainly not the one to make the decision, but I’m curious how you see the balance of 1 more network request that only happens for however long the browser cache lasts to then be instantly loaded by all webpages being visited after that compared to however many KB that CSS is then always being loaded across all webpages ever visited.

Don’t want to forget about plugins that combine/minify CSS where that concern of 1 additional network request goes away entirely as it’s simply bunched together with other CSS for the website/page. So, I’m not sure if there’s any downside to the file approach at that point while then still getting those assorted improvements.

Also, I’m not 100% in the know on how unique this plugin’s CSS can get given different settings across various pages. If it actually is rather dynamic depending on what page one’s on, then inline can certainly make more sense… while it being the same across all pages really makes it more akin to theme CSS where I’m thinking having it be a file has the potential to be a solid performance optimization.

• This reply was modified 10 months, 1 week ago by KZeni.

Come to think of it, it could potentially just be a single CSS file that’s simply updated when settings are changed (no need for timestamped files nor cleaning up old files after a max age) as long as it has a timestamp added as a URL parameter (probably the version parameter, right?) when loading the file that then is the timestamp the settings for the plugin was most recently saved.

That would get browser caches to look to load the latest version of the CSS while then any that might have the webpage cached server-side from before a settings change will still load the CSS (then just making sure to get the new version once that page’s cache expires.)

That seems like an approach that’d be just as effective as what I mentioned above yet way more straightforward to implement & maintain.

I’ve also posted about this at https://github.com/fontsplugin/plugin/issues/38 for better visibility just in case there are others also wondering about this that might look in one place but not the other and/or better facilitate discussion/updates in the more appropriate place.

I’m glad this was asked about as I also miss having the full listing of favorited plugins. I do fully understand why it was set to be truncated after a certain plugin count, though.

That said, I do wish it would then have a link to https://www.ads-software.com/plugins/browse/favorites/?favorites_user=*username* (didn’t know about that favorites_user URL parameter until now, super helpful) at the very end of the plugins listing on a user’s profile if it did hit that 250 plugin limit to then take one to the spot where the full favorites list can be browsed. Kinda like a “View All” link being at the end of a listing that doesn’t show all of the content it has to offer. It’s a bit odd where it currently just cuts off without really pointing to where one would be able to actually see all of the favorites of a user (without otherwise needing to turn to the plugin install interface as a site admin.)

@cschwoertzig I would venture to guess they meant the latest version of both plugins (ex. currently Download Monitor v4.9.5 and Email Before Download v6.9.7.)

Are you using the latest version of both plugins and still having issues? If so, I might suggest you open up a new support forum topic on the support forum that corresponds to the plugin you think it’s more likely to relate to (ex. this particular issue was more on EBD’s side of things than DLM’s while visibility to both support forums can be helpful if others might be experiencing it) and provide the details on the issue(s) you’re encountering to get it resolved (steps taken leading up to the issue, what the issue is, and ideally having WP_DEBUG and/or error message output for the issue if it’s an error like this one was.)

I say this since multiple people have reported that updating both plugins to their latest versions available now has found this particular issue is no longer happening (seems to be resolved) so you still having issues might be something unique to your site/setup/etc. that wasn’t the same as what was discussed & fixed here (though hopefully just updating to the patched plugins has things working better for you like it has for others.)

Marking this as resolved as version 6.9.7 of Email Before Download was released about 5 days ago to address this issue and https://www.ads-software.com/support/topic/invalid-uid-after-upgrade-to-4-9/#post-17291883 has confirmed this update fixed the issue (thankfully I had notifications turned on for that topic in the Download Monitor support forum as I otherwise wouldn’t have known there was an updated version made available of EBD to fix this issue [having disabled EBD to avoid this issue in the meantime.])

Side note, it still sure would be nice if EBD were to get added to GitHub (then linked to in the plugin description so it’s easily found) to help facilitate these community-based potential fixes, etc. Also, I see these new versions still aren’t being tagged via the WP.org SVN (https://plugins.trac.www.ads-software.com/browser/email-before-download/tags) to be able to have a history of past versions being available (see the “Previous Versions” section & dropdown on https://www.ads-software.com/plugins/email-before-download/advanced/ as it’s missing any/all version 6.x releases), if/when needed.

Also, for those curious about what needed to be updated, here’s a link to this latest EBD release’s changeset: https://plugins.trac.www.ads-software.com/changeset/3010606

@wilsonmarc There’s good news on this front as https://www.ads-software.com/support/topic/plugin-conflict-ebd-breaks-download-links-when-using-download-monitor-4-9-x/#post-17269602 shows the Email Before Download plugin developer knows about the issue and is actively working on the fix (which is certainly great to see as I was unsure how involved they still are given their limited activity in the last year or so on their support forum & elsewhere.)

I agree that having an add-on that has 10k+ active installs (unofficial or not) be left to break all links for downloads out of nowhere on sites after an update isn’t something that should be allowed to happen without making some effort to avoid it.

While DLM cannot be held responsible for ensuring unofficial add-ons keep working indefinitely whenever an update is made (especially when it might be the add-on that was built in a way where it’s more fragile than it should be [ex. did the official Email Lock add-on need to be updated with this recent update? If not, what about EBD was fragile enough to break after the update?]), there are ways to help avoid a situation like this that could/should be considered on Download Monitor’s end of things (especially given how widely used some of these unofficial extensions are… simply put, DLM has grown into being somewhat of its own platform & with that comes some added responsibility.)

@cristianraiber-1 To address this more systematically (make it so issues like this are less likely to occur while the DLM devs don’t need to be checking/updating any/all 3rd party add-ons themselves), it might be good to have it where any substantial update to DLM that could potentially break plugin compatibility is always first given an RC pre-release on https://github.com/WPChill/download-monitor before the official release where that then highlights any items that could be compatibility-breaking with add-ons (as well as having the full commit history, etc. available to check for the add-on devs as needed.) That way, any/all unofficial plugin devs (and/or users of those unofficial add-ons) can check the RC release and raise any red flags if anything comes up that needs to be addressed before release (then likely proceeding with the official release a week or so after the RC if no issues are pointed out [since one shouldn’t be prevented from releasing an update if a 3rd party dev/community is not being responsive] or potentially delaying the official release if a serious issue comes up with that release candidate.)

Putting a system like that in place for DLM would make it so EBD & others that have tens of thousands of combined active installs which could potentially have an issue come up have a chance to do their responsibility of ensuring their add-on will work with the upcoming release (the add-on devs & users then being able to have notifications of releases [add-on devs should really have those notifications turned on at that point] so they can check an RC release when one is made available.) Definitely better than having a release be made where it simply breaks stuff with no prior chance for the add-on devs to make any necessary changes to avoid issues. Meanwhile, if an add-on needs additional time to fix things, they can give a minor update to their add-on that adds a notification to the site admin stating that one should hold off on updating the main Download Monitor plugin and/or halt having DLM check for updates (the latter being rather aggressive, but it would help avoid auto-update or accidental updates from occurring) until the new version of that add-on is released to address its compatibility issue found in the RC of Download Monitor (then having the patched version of the add-on simply no longer include that warning message nor have it disable DLM updates.)

It seems like Download Monitor has effectively evolved into being in a similar space of something like Yoast SEO where the main plugin is certainly widely used while also having a fair number of add-ons/integrations (both official & unofficial) that are widely used as well, and things shouldn’t be left to suddenly break for any of those (they should be given a chance to check things & fix things accordingly before the official release.) One can see on https://github.com/Yoast/wordpress-seo/releases how Yoast has been making RC pre-releases for its upcoming official releases. Now, DLM probably doesn’t need to have RC pre-releases to the extent of Yoast, but having it do something like this to some degree before notable updates would be beneficial for both the users of Download Monitor & the ecosystem surrounding it.

@mandsconsulting This is fantastic news! Thanks for giving this a look!

@phil192 This is a duplicate topic. https://www.ads-software.com/support/topic/plugin-conflict-ebd-breaks-download-links-when-using-download-monitor-4-9-x/ is already discussing this issue (with the plugin author having just replied to state they’re working on a resolution.)