Skip Navigation

[Resolved] Fatal error message on frontend after activating Toolset Blocks or Views

This support ticket is created 4 years 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.

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)

Tagged: 

This topic contains 10 replies, has 3 voices.

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

Assisted by: Christian Cox.

Author
Posts
#1911401

I am trying to:
install and activate Types, Forms, and Blocks

Link to a page where the issue can be seen:
(dev site)

Instead, I got fatal error message:

Fatal error: Uncaught Exception: Serialization of 'Closure' is not allowed in /code/wp-includes/functions.php:599 Stack trace: #0 /code/wp-includes/functions.php(599): serialize(Object(WP_Hook)) #1 /code/wp-includes/option.php(406): maybe_serialize(Object(WP_Hook)) #2 /code/wp-content/themes/parallelus-salutation/framework/theme-functions/filters-and-actions.php(707): update_option('public_content_...', Object(WP_Hook)) #3 /code/wp-includes/class-wp-hook.php(287): save_public_content_filter('') #4 /code/wp-includes/class-wp-hook.php(311): WP_Hook->apply_filters(NULL, Array) #5 /code/wp-includes/plugin.php(484): WP_Hook->do_action(Array) #6 /code/wp-settings.php(557): do_action('init') #7 /code/wp-config.php(87): require_once('/code/wp-settin...') #8 /code/wp-load.php(37): require_once('/code/wp-config...') #9 /code/wp-blog-header.php(13): require_once('/code/wp-load.p...') #10 /code/index.php(17): require('/code/wp-blog-h...') #11 {main} thrown in /code/wp-includes/functions.php on line 599

--
Note:
I could activate Types and Forms plugins, but Blocks or Views gives me the fatal error soon as I activate it. Looks like it comes into conflicting of the site theme being used. I need both the current theme and Toolset to work together. Possible fix?

Thank you
Steven

#1911629

Nigel
Supporter

Languages: English (English ) Spanish (Español )

Timezone: Europe/London (GMT+00:00)

Hi Steven

Could you please briefly switch to twentytwentyone theme to confirm that the issue occurs because of a conflict between your existing theme and Views/Blocks?

If that is the case, I don't recognise the theme, it would expedite things if you could zip the theme and share it with us via dropbox or similar for testing. (Such links are hidden.)

#1911911

Hello Nigel -
I tested the site with the alternative theme per your suggestion. Blocks runs fine with alternative theme, so the test points the trouble to the site original theme.

You can download theme Zip file there:
hidden link

It would be greatly appreciated if you can resolve this soon as I'd need Toolset to accomplish a task on the site for my client.
Thank you.

#1912367

Hello, thank you for providing a link to download the theme. I was able to download and install it on a local test site, and reproduced the error you experienced. I see the error is thrown by this line of code in the theme:

update_option( 'public_content_filters', $wp_filter['the_content'] );

Let me escalate this issue to our second tier support team for further analysis. Since it seems to be a compatibility issue, we may need to collaborate with the theme author to come up with a working solution. Can you provide an email address for contacting the authors of the Salutation theme?

#1912701

Hello Christian ~
For immediate remedy as I need to keep the project moving and the fatal error is a major problem, I have removed that part of the code from the affected theme file. Toolset Blocks seems to be running ok with that piece of theme code removed. I don't know yet if the missing code can debilitate some essential functionality until I run into it.

And for the right fix, it maybe a good idea to contact and work with the theme author. Below are references.

This is their profile page on Themeforest:
hidden link

Their official website:
hidden link

Hopefully you are able to get in touch with them and work it out and provide me an update.

Thank you.
Steven

#1913275

Hopefully you are able to get in touch with them and work it out and provide me an update.
I was hoping to receive an email address for direct contact with their authors because it looks like their support system requires a paid membership. Their site's support link goes here:
http://para.llel.us/support/
That page directs me to their ticksy support platform:
https://parallelus.ticksy.com/
To create a ticket I need the Envato registration info or a theme purchase code plus registration in their support system.

I think it would be best if you create a ticket in their support system asking their support team how Toolset's developers can contact theirs directly to collaborate on a compatibility issue between Toolset Blocks/Toolset Views and Salutation. As a paid customer, I suspect you'll have better luck than me.

Since I don't have immediate access there, I tweeted @parallelus from my personal account to ask for the same information, so hopefully someone will respond soon.

#1920393

Our lead developer has reviewed the situation here and concluded that our software is doing nothing wrong by registering filters on the_content, and that the Salutation theme is storing those callbacks in a way that seems like overkill:
On every frontend page load, they collect the callbacks added to the the_content filter, and store those callbacks in an option. This is where the thing fails: callbacks can be methods and, in our case, the class holding that method is big and loaded. An option should not hold so much data: even without us, 200 lines is too long for an option entry, in my opinion. The database schema might support it, but I find it odd.
This option is stored without an autoload flag set to false, so even if it gets stored (without Views/Blocks), it will be autoloaded on every page load, backend and frontend. Oh my.
This option is only used once in a single admin page, to let users select the callbacks on the the_content filter that would be applied by post type. To print and store the selected items, the theme reduces the data it gathered (and stored!), and uses and saves only the callback name (the function name, or the class and method names). It literally ditches everything else, which is kind of a lot.
As I said, I find this mechanism wrong. If you are going to use only some pieces of the data, do not store the whole object where the callback is defined as a method, just store the class name and method name.

We suggest you contact the theme authors and explain the situation. If they would like to speak to our developers directly, I can provide an email address for them to contact in a private message.

#1921035

Thanks for the update and insightful info, Christian.
I will pass this on to the theme author.
You guys are awesome.

/ Steven

#1921043

No problem, I'll stand by for your update. Let me know if you need anything else from our side.

#1921111

Christian,

I contacted the theme author and got their response that this theme does not support block editor. This explains why the error when Toolset Block is activated. It doesn't sound like they would update the theme (been around for a few years) to be more compatible. So I guess we have reached the end of the rope here. For now I can get by using the theme with part of the code taken out as noted in one of my previous posts above. And eventually I would have replace this theme for my site with something compatible with current standards.

Thank you for all your support.
Steven

#1921727

Understood, thanks for the update.