Daniel Iser

Quality feedback.

• This reply was modified 2 years, 2 months ago by Daniel Iser.

Thanks for the solid review, that said we may start breaking things here soon, in a good way of course :). We are pushing some much needed love this way and adding some super valuable new features as well as improving the tooling and code quality even further.

@reneyoung – you can also try exporting it and reimporting it. Might get the kinks out of whatever data is missing or malformed.

Check it in the list, the bulk actions includes an export option. Then there is an option to import when no items are checked.

@soyshinoda – Can you submit a support ticket on our site and possibly grant us support access so I can take a look and track this down for you?

@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.

@ildomandatore – The problem with any solution like that is its not cacheable, the avg wordpress server would not like that.

To clarify, in order to filter by device in the query level (pre rendering in template), it would require detecting browser details in PHP. This would mean 0 caching could be used, no page caching, no cloudflare etc.

The only way to do device checks, and the way we do it with block controls is via CSS media queries or front end JavaScript.

That means the content is on the page, your just hiding it.

If that is the way you want to go you probably don’t even need a plugin.

1. Tag each item with proper device type.
2. Ensure that each item renders the device type tag as a class on its container element. Likely can filter post classes for this in some way.
3. Add some CSS that hides mobile tagged posts on screens larger than X.

If you are looking for actual device rules, like iPhone/iPad vs Desktop vs android phone tc, you would likely need to rely on JS based checks.

If you are already using our plugin you could render your list of games separately as blocks in gutenberg, then add rules to hide/show each based on device (screensize).

Hope that helps.

@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 ww.wp.xz.cn 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.

@robin-labadie – How many restrictions do you have set up? What kinds of rules are on each?

The only performance penalties should be from comparison of conditions against content. These checks are cached for each peice of content, but can add up.

That said there are several places that could happen, each with varying number of tries.

• Main query, tries once against the global page.
• Post query, checks every post in a loop to make sure they should be there.
• Tax query, checks each tax against rules.
• Rest API queries, checks the global query and items within.

I’ll be honest and say we have attempted to cache much of this on a per page load basis. But If you have object caching, we can look at saving rule processing for each user/content in that cache for a day or 2, saving even more performance.

I’d really need to know more about your situation, and how your discerning the performance implications.

For the most part though, 95% of our checks require no extra loading of data, and test data that’s already there, so it must either be tons of checks on different content on each page, no caching support, or using the 5% of rules that might be getting extra data

Definitely start a new thread, or better yet, email our support.