htrex

Hi,
the plugin is already the latest released version 4.7.2 running on WordPress 6.6.2.
There’s anything I can do to help you debug this issue?

Thank you for your paying attention to this support channel.
Best regards

Hi Andrew,
regarding this issue, the new 1.45.1.1-beta seems to work nicely, I’m not seeing errors while trying the bug reproduction steps above.

Thank you

Alessandro

Hi Andrew,
unfortunately I’m getting the same error:

Uncaught TypeError: i.find is not a function
    validateFields [...removedUrl...]/wp-content/plugins/so-widgets-bundle/base/js/admin.min.js?ver=1.45.1-beta:1
    <anonymous> [...removedUrl...]/wp-content/plugins/so-widgets-bundle/base/js/admin.min.js?ver=1.45.1-beta:1
    jQuery 7
    updateWidget [...removedUrl...]/wp-admin/js/customize-widgets.min.js?ver=6.1.1:2
    jQuery 8
    updateWidget [...removedUrl...]/wp-admin/js/customize-widgets.min.js?ver=6.1.1:2
    t [...removedUrl...]/wp-admin/js/customize-widgets.min.js?ver=6.1.1:2
    Underscore 3
    _setupUpdateUI [...removedUrl...]/wp-admin/js/customize-widgets.min.js?ver=6.1.1:2
    jQuery 2
admin.min.js:1:24823

Let me know what else I can do to help with this issue.
Thanks

Alessandro

Magic Weston,
I can confirm that removing the prefer bento flag did the trick!
I’ve also removed the mu-plugin workaround with add_filter('amp_enable_ssr', '__return_false'); and it still works.

I’ll need to check it again on the next AMP plugin update to see if the patch will be merged already.

Thank you Weston, I’ve compared the sources between the working and non working version. In sandbox mode, it seems that when a 1.0 version exists, the libraries are updated to it, while the difference with the libraries and SSR on/off seems to be the use of js modules (.mjs).

When SSR is on I’m getting that error.

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

Hello @milindmore22
I wasn’t sure it was an AMP script compatibility issue and tried some changes to the code before contacting AMP JS libraries support.

At the end I’ve found that a mu-plugin containing add_filter('amp_enable_ssr', '__return_false'); solves the js error (https://gist.github.com/htrex/f63eedce5558ab4f08ddab37e14bc471), but that also disables important performance optimizations.

@westonruter can you please give me a few hints to debug this issue further?

I’ve removed it. You’re right, that condition isn’t needed when serving only an AMP invalid website in Standard mode with sandboxing loose mode.
I was trying to make it future proof, as some kind of mode checking will be needed again if and when sandboxing will be extended to the reader mode and a plugin or theme could include or exclude some scripts depending on the context (reader theme: Strictly valid AMP page, standard theme: AMP page with unvalid additions).

Now, it mostly works but I’m facing a show stopper. In some pages I’m using the <amp-selector> that’s included in a custom post type template.
In Standard mode with sandboxing loose mode active the <amp-selector> component doesn’t work, while in reader mode it does both when rendering the standard theme and the reader theme.

The issue comes from a js error, see:
https://gist.github.com/htrex/f63eedce5558ab4f08ddab37e14bc471

I don’t have a clue on how to debug it.

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

To enqueue AMP-invalid scripts my child theme uses a conditional:

if ( !function_exists('amp_is_request') || !amp_is_request() ) { ...

I had to remove that condition, otherwise even when using Sandboxing loose mode they wont get enqueued. Is there any function or trick to check is Sandboxing mode is active and what’s the sandboxing user selected level?

Hi Milind,
it seems the new sandboxing feature could be perfect for my use case, except it only works in standard mode.

To recap, I’ve a custom parent theme which is AMP native and used as reader theme, while a child theme adds some js to it for any page of the website and is used as standard theme.

As far as I understand, with sandboxing in loose mode I’ll not have a single AMP valid page on my website, because any page contains invalid JS.
In moderate mode every page will be AMP valid, but “progressive” JS will be stripped out.

In the documentation

Lastly, in future releases, we may allow the sandboxing levels to be used in non-Standard modes as well, in particular Reader mode.

is there any github issue to follow the development of this feature?

Hi @wfpeter,
as far as I can understand from your reply here https://www.ads-software.com/support/topic/amp-error-message-jquery-min-js/#post-14057380 the wordfence script enqueued for logged in only users is usefull to warn and eventualy whitelist false positives which could happen for admin ajax requests to the backend.

Disabling this Wordfence feature doesn’t seem optimal and I hope the next Wordfence version could have a better AMP compatibility.
If I understand correctly, enabling AMP compatibility should be as easy as adding “data-ampdevmode” attribute to scripts and styles added for logged in users only, please remark it to plugin devs.

Thanks

Alessandro

• This reply was modified 2 years, 9 months ago by htrex.

Hi Alex,
I can confirm that your beta version makes the notices disappear, should have seen myself how this condition looks weird!

$current_screen->base == is_object( $current_screen ) && 'widgets' ? 'wp-edit-widgets' : 'wp-editor'

Thanks for your support, I’m waiting for the public release!

• This reply was modified 2 years, 9 months ago by htrex.

Yes Andrew, those are just notices, sure they’ll go away with WP_DEBUG set to false.
It’s just that I’m developing a new website, I need debug to be on and they appear on every post edit screen as soon as I create a new post or edit an old one.

Something particular about my setup is that the only feature I use is the fantastic post loop widget included with Siteorigin Builder and enhanced by the Widget bundle. I don’t understand why the query feature of the post loop is only available installing the Widgets bundle, anyway, I’ve disabled all it’s widgets from it’s settings page, and I’ve also deselected all post types from Siteorigin Page builder settings page.

The only reasonable clue I can give you is that temporarily commenting row 33 on so-widgets-bundle/compat/block-editor/widget-block.php fixes the notices.

Hope this helps.

Hi Andrew,
yes, I can confirm the issue with every plugin deactivated except the Widgets Bundle and Twenty TwentyTwo theme.

This is the call stack as printed by xdebug:

( ! ) Notice: wp_enqueue_script() was called <strong>incorrectly</strong>. "wp-editor" script should not be enqueued together with the new widgets editor (wp-edit-widgets or wp-customize-widgets). Please see <a href="https://www.ads-software.com/support/article/debugging-in-wordpress/">Debugging in WordPress</a> for more information. (This message was added in version 5.8.0.) in /var/www/html/wp-includes/functions.php on line 5768
Call Stack
#	Time	Memory	Function	Location
1	0.0001	372456	{main}( )	.../post.php:0
2	0.0648	4208544	require( '/var/www/html/wp-admin/edit-form-blocks.php' )	.../post.php:187
3	0.2502	7396024	require_once( '/var/www/html/wp-admin/admin-header.php' )	.../edit-form-blocks.php:303
4	0.2701	7667856	do_action( )	.../admin-header.php:163
5	0.2701	7668232	WP_Hook->do_action( )	.../plugin.php:474
6	0.2701	7668232	WP_Hook->apply_filters( )	.../class-wp-hook.php:331
7	0.2701	7669360	wp_check_widget_editor_deps( )	.../class-wp-hook.php:307
8	0.2701	7669680	_doing_it_wrong( )	.../widgets.php:2090
9	0.2701	7670512	trigger_error ( )	.../functions.php:5768

( ! ) Notice: wp_enqueue_style() was called <strong>incorrectly</strong>. "wp-edit-post" style should not be enqueued together with the new widgets editor (wp-edit-widgets or wp-customize-widgets). Please see <a href="https://www.ads-software.com/support/article/debugging-in-wordpress/">Debugging in WordPress</a> for more information. (This message was added in version 5.8.0.) in /var/www/html/wp-includes/functions.php on line 5768
Call Stack
#	Time	Memory	Function	Location
1	0.0001	372456	{main}( )	.../post.php:0
2	0.0648	4208544	require( '/var/www/html/wp-admin/edit-form-blocks.php' )	.../post.php:187
3	0.2502	7396024	require_once( '/var/www/html/wp-admin/admin-header.php' )	.../edit-form-blocks.php:303
4	0.2701	7667856	do_action( )	.../admin-header.php:163
5	0.2701	7668232	WP_Hook->do_action( )	.../plugin.php:474
6	0.2701	7668232	WP_Hook->apply_filters( )	.../class-wp-hook.php:331
7	0.2701	7669360	wp_check_widget_editor_deps( )	.../class-wp-hook.php:307
8	0.2703	7669680	_doing_it_wrong( )	.../widgets.php:2103
9	0.2703	7670512	trigger_error ( )	.../functions.php:5768

I’m using WP 5.9 and seeing this error on the WordPress edit post interface.

Using the remove_theme_support( ‘widgets-block-editor’ ) has no effect, any fix please?

It’s easy and would be nice to see a plugin update with this feature and customizable labels using shortcode parameters.

For the moment you can overwrite your local js library
/wp-content/plugins/twenty20/assets/js/jquery.twenty20.js

with the version from
https://github.com/zurb/twentytwenty/blob/master/js/jquery.twentytwenty.js

then if you want to change the default before/after labels you can do it adding a couple of CSS rules in your styles

.twentytwenty-before-label:before { content: “NEW BEFORE LABEL”; }
.twentytwenty-after-label:before { content: “NEW AFTER LABEL”; }