works great, but slow down updates please

@willemb2 – Can’t agree more usually, but if there are fatal errors coming up for a fraction of our users, we can’t let them linger. Even if it only affects 1% of users, that is over 400 websites if everyone is allowed to update because we don’t want to push one for fear of update-fatigue.

v2.2.1 -> v2.2.5 covers various fatal errors, some that didn’t come up til others were solved, none came up in our testing. Those could easily have impacted 10’s of 1000s of sites left unchecked. Every hour counts pushing those fixes.

I assure you that if you were one of the users reporting those issues, you would be very satisfied that the fix came ASAP.

As for v2.2.6 -> v2.2.7.

I take full responsibility for the last 2. They were admittedly due to not well documented new feature of the www.remarpro.com repo. We were shown a notice to add a test site blueprint to the plugin after uploading the last real update, but the docs on doing so led us to believe we had to add the files into a place that required changing the version number. And those 2 were pushed out within a minute of each other at ~2am so very few would have actually seen them both, rather only the latest this morning.

I hope this clarifies our position and you will consider adding back that extra star to support those users who’s sites were breaking and needed our help as fast as possible.

@willemb2 – Missed your comment on beta testing, will add I wish that were useful these days, we have a dedicated beta testing mailing list for our larger plugin Popup Maker (~800k users), the list has 130 emails on it. Percentage of them who verify they tested it on new versions ahead of time, less than 1%.

Extrapolate that to 40k users (Content Control) and that is less than 1 person reporting back.

We do offer it, nobody cares typically til its a feature they want early, or until after its released and a bug is found that affect them.

Its unfortunate, we built entire setups for testing betas for Popup Maker and were very disappointed at the results.

We do a lot of internal testing, lots of automated tests and strict coding standards applied before commits, but sample WooCommerce stores rarely reveal much compared to a fully functional and complex live shop.

Sometimes you just aren’t gonna find edge cases til its in the wild. Being responsive to those cases is the most appropriate path given the lack of enthusiastic testers.

This is how the people from Ninja Forms do it: they publish a link to the beta (pre-release copy they call it) right in the support topic here on www.remarpro.com. The users affected by ‘fatal errors’ or other severe issues are always eager to test and report back their results, usually within a few hours. If no negative side effects are being reported, the fix is published as a new release 3-5 days later. Example.

@willemb2 – We did similar for several of those bug releases, posted the code solution, waited for one of the reporters to say they tried it and it worked before I pushed the final release button. This happened in minutes btw.

I’ll note the Ninja Forms link you posted was for a one user issue, we had dozens of users chime in within an hour or 2, not quite the same scale/scope.

The other errors there was no need to wait for confirmation, an error like Warning: Attempt to read property “term_id” on int is pretty clear, add a proper type check to ensure only objects with that property are accessed that way and I don’t have to guess if its solved.

I’ll also point out that the above error can’t really be tested for without ever seeing someone break it that way. $wp_term_query->terms is always an array of term_object as is documented in WP core documentation.

Only if another plugin/custom code changed it to an array of integers, which they shouldn’t, would this error be possible.

I appreciate your feedback, and typically agree, but our track record doesn’t represent that at all. We go 4+ weeks without updates regularly, but when there are issues in a new release, they must be addressed rapidly.

So I must respectfully disagree with your premise that multiple or fast updates are always a problem. In fact they are a necessity when applied correctly.

As a typical suggestion and hopeful way to make this a constructive conversation, these would be my suggestions for a live/production site.

• I never auto update anything, terrible idea from the start, shouldn’t have been added to core in such a dynamic ecosystem. Hard enough getting site admins to read changelogs as it is, with that on would it even matter if we listed breaking changes?
  
  Now if auto updater had an option for security releases only, that might be better, but even then admin discretion should be taken into account.
  
  I do however recommend auto updates for lots of things such as network firmwares and such, but that is much different than WP plugins.
  
• Outside of security updates, there is no rush to update every time one is available. If a new minor or major release comes out, no shame in waiting for a few patches or a couple days to pass before updating to it. This is typically best practice for IT professionals who wait until they know its been tested in the wild before deploying.

I’ll leave you with a simple question…

Would you propose we leave those Fatal WSOD (white screen) errors in the plugin for a few days? Keep in mind at scales of 40k+, minutes means potentially dozens or hundreds of additionally affected sites.