Skip Navigation

[Resolved] I think Toolset minimal requirement needs to be bumped to WP 5.0

This support ticket is created 3 years, 6 months ago. There's a good chance that you are reading advice that it now obsolete.

This is the technical support forum for Toolset - a suite of plugins for developing WordPress sites without writing PHP.

Everyone can read this forum, but only Toolset clients can post in it. Toolset support works 6 days per week, 19 hours per day.

Our next available supporter will start replying to tickets in about 2.41 hours from now. Thank you for your understanding.

Sun Mon Tue Wed Thu Fri Sat
8:00 – 12:00 8:00 – 12:00 8:00 – 12:00 8:00 – 12:00 8:00 – 12:00 - -
13:00 – 17:00 13:00 – 17:00 13:00 – 17:00 13:00 – 17:00 13:00 – 17:00 - -

Supporter timezone: America/New_York (GMT-04:00)

This topic contains 8 replies, has 2 voices.

Last updated by Christian Cox 3 years, 6 months ago.

Assisted by: Christian Cox.

Author
Posts
#2048699

In Toolset minimal Requirements it is stated that WP 4.7 upwards will work with Toolset.

However, Toolset makes meanwhile usage of functions like do_blocks() which was introduced in WP 5.0 only

I also confirmed this by testing Toolset on ClassicPress, which is basically a fork of WP 4.9, and I got a bunch of fatals, as well as dysfunctional content (searches, templates, etc etc)

It seems for example core Toolset function wpv_do_shortcode relies on do_blocks, making usage of Toolset on ClassicPress and any WP lower than 5.0 not possible.

At least, that was my finding on a test site I made for the purpose.

Let me know if I'm wrong 🙂

#2049475

Hi, I'll ask the team what we plan to do here. I installed WP 4.9.17 with the latest Types and Blocks, and was able to replicate a problem where Content Templates are not displayed with basic Posts. I was not able to replicate any fatal errors, but I'll ask the team if we plan to adjust the minimum requirements or if we plan to support those older versions with backwards compatibility fixes. I'll let you know what I find out.

#2051763

The initial thought from 2nd tier support is that we should address issues individually as they arise rather than bumping up the requirements. We have escalated an issue where Content Templates are not working as expected in WP 4.9 with the latest Blocks, and the developers will give us feedback on that issue shortly. For other issues, we will need steps to reproduce.

The wpv_do_shortcode shortcode does not seem to be completely broken so there may be some fallback in place for do_blocks support. For example, insert Views shortcodes in a page with WP4.9 and there are no errors. So if there are other issues we need to address, we'll tackle those on a case-by-case basis.

#2051771

Hmm, that’s an interesting turn

I’m pretty sure I saw fatal error due to do_blocks() not defined in WP 4.9

There’s no fallback for that method in code as far I saw either

The error for me happened on a existing site with rather complex archive and searches yada yada

I’ll see if I can find steps since they should be easy to replicate given the function doesn’t exist in older wp at all and wpv_do_shortcode() used it without a fallback as far I saw - but then I didn’t dig deep, just saw the error and moved on.

Perhaps this is because I actually tried to switch to CP from an existing WP install and who knows those *%+^^ „blocks comments“ in the source could be the cause!
Those wouldn’t be there on real old installs, and perhaps toolset somehow determines what kind of install it is by listening to those HTML block comments

I’ll check and let you know what I find.

Could you ask developers for how long they plan to play the „backwards compatibility game“ to start with?
Until official EOL of 4.9 arrives - that might be forever… so I’m not sure until when we could expect such (great) backwards compatibility anyway ?

Thank you!

#2052969

The easiest way for me to replicate the fatal error was this:

1. Install WP 4.9 from https://wordpress.org/download/releases/
2. Install Toolset Views last version (Blocks or Views does not matter)
3. Create a View that lists blog posts and insert at least a post title. Leave all settings default.
4. Insert that View to any page and view it in the front end.

There will be a fatal error due to usage of has_blocks() in the is_cacheable() function, however I think this is replicable in other places too, and I am still positive I saw the same for do_blocks() but did not replicate this in this short (clean) test.
However it is pretty much expected that any function introduced above 5.0 will fatal, and it is expected that those functions are used since Toolset is a Blocks oriented plugin meanwhile. I don't think there will be (not sure if if even is possible) fallbacks for each and every blocks-related feature/method.
But anyhow, here's the error you'll see:
( ! ) Fatal error: Uncaught Error: Call to undefined function has_block() in /wp-content/plugins/wp-views/embedded/inc/wpv.class.php on line 1495

A few notes:
Instead of using WP 4.9 you could use ClassicPress which at least would allow you to use PHP 7.x - and it would show the same error
The duplicate here uses standard WP 4.9. Just make sure to enable PHP 5.x in order to use it or you'll get errors.
hidden link

Now, my doubt is in the decision to support versions below 5.0 if indeed the goal is to focus on Gutenberg?

*Don't get me wrong*, I would - of course - love to use Toolset on new ClassicPress projects but I think supporting lower than WP 5.0 (or in other words, ClassicPress) will kill resources for Toolset that are needed to make Blocks something useful, which is surely required.

If I can express my suggestion it is to bump version required instead of making a split balancing act between the two worlds.
However, of course that is just my opinion - and I know for a fact you'd be making some people very happy if we could use Toolset officially in pre-Blocks paradise (I mean ClassicPress).

Over to you...

#2053477

pre-Blocks paradise
LOL

I was able to replicate a fatal error in a clean site for the function do_blocks, when displaying a simple View of Posts with the Views plugin and Types active in WP 4.9 / PHP 5.6.40. In a quick test I could not replicate a has_blocks fatal error from a clean installation with Views and Types active, so I will dig into the clone tomorrow.

In WP 4.9 / PHP 5.6.40, I can't get the Toolset Settings page open because of another Fatal Error:

PHP Parse error:  syntax error, unexpected '::' (T_PAAMAYIM_NEKUDOTAYIM) in /path/to/site/wp-content/plugins/wp-views/vendor/toolset/common-es/server/Block/Style/ToolsetSettings.php on line 74

This means I can't activate the legacy Views editor from a clean start with Blocks active - infuriating. I am presenting issues to the team to see if we can get some answers to your questions about timelines for support, plans for backwards compatibility, etc.

#2054247

In WP 4.9 / PHP 5.6.40, I can't get the Toolset Settings page open because of another Fatal Error:

PHP Parse error:  syntax error, unexpected '::' (T_PAAMAYIM_NEKUDOTAYIM) in /path/to/site/wp-content/plugins/wp-views/vendor/toolset/common-es/server/Block/Style/ToolsetSettings.php on line 74

This turns out to be a problem with PHP 5.6.40, unrelated to WP 4.9. The same issue can be reproduced in the latest version of WP.

After reproducing the Fatal Errors when displaying basic Views and reviewing your comments, Nigel has asked to have the minimum supported WP version bumped up to 5.0 in our docs. We've submitted a ticket to the docs team and I expect they will update that pretty soon (they have been very quick lately when it comes to Toolset docs changes). Since we are bumping that minimum version requirement, I suspect that the 4.9 issue displaying basic Views will not be resolved soon (if ever). Thanks for the report.

#2054255

Thanks Christian, this is about as much as I expected and makes sense.

Supporting non-blocks world would be - while of course amazing - a true balancing act that makes somehow not much sense for a modern WP Plugin.

About the PHP error you mention last (Dashboard thingy), just remember that the minimal requirements say "PHP 5.6 and above".

Strictly speaking, that should then be a BUG to be fixed, or bumped as well upwards by a few releases (PHP 7.x being here the only choices).

Again just my opinion, since PHP 8 totally fails with Toolset, perhaps as well here the balancing act should be dropped in favour of efforts towards PHP 8 😉

But that's entirely other topic anyway, main question I had == solved.

Thanks!

#2054289

Strictly speaking, that should then be a BUG to be fixed, or bumped as well upwards by a few releases (PHP 7.x being here the only choices).
Agreed, the PHP 5.6.40 / Broken Toolset Settings page issue is still filed with the developers. You didn't report this one specifically so I just filed it as a separate issue I found during testing, without a parent forum ticket.