ChrisCree

This new “Live” badge needs to be easily disabled via settings and should have been disabled by default on existing live WooCommerce installations. It’s causing unnecessary confusion for my clients who have had stores up and running for years.

Basically any site that I had running PublishPress Blocks would crash with the below fatal error when I attempted to go into the Customizer. I suspect it was because I never set any Block Permissions in the settings and there was a null value for the $advgb_blocks_user_roles array. I don’t know if you can have the plugin set a default Block Permission that can be changed via the settings to avoid the error?

Anyway, here is the error I got when I set wp_debug to true:

Fatal error: Uncaught TypeError: in_array(): Argument #2 ($haystack) must be of type array, null given in /nas/content/live/sitename/wp-content/plugins/advanced-gutenberg/incl/advanced-gutenberg-main.php:2480 Stack trace: #0 /nas/content/live/sitename/wp-content/plugins/advanced-gutenberg/incl/advanced-gutenberg-main.php(2480): in_array(‘genesis-page-bu…’, NULL) #1 /nas/content/live/sitename/wp-content/plugins/advanced-gutenberg/incl/advanced-gutenberg-main.php(516): AdvancedGutenbergMain->getUserBlocksForGutenberg() #2 /nas/content/live/sitename/wp-content/plugins/advanced-gutenberg/incl/advanced-gutenberg-main.php(422): AdvancedGutenbergMain->advgbBlocksVariables(false) #3 /nas/content/live/sitename/wp-includes/class-wp-hook.php(307): AdvancedGutenbergMain->addEditorAssetsWidgets(‘widgets.php’) #4 /nas/content/live/sitename/wp-includes/class-wp-hook.php(331): WP_Hook->apply_filters(NULL, Array) #5 /nas/content/live/sitename/wp-includes/plugin.php(474): WP_Hook->do_action(Array) #6 /nas/content/live/sitename/wp-includes/class-wp-customize-widgets.php(704): do_action(‘admin_enqueue_s…’, ‘widgets.php’) #7 /nas/content/live/sitename/wp-includes/class-wp-hook.php(307): WP_Customize_Widgets->enqueue_scripts(”) #8 /nas/content/live/sitename/wp-includes/class-wp-hook.php(331): WP_Hook->apply_filters(NULL, Array) #9 /nas/content/live/sitename/wp-includes/plugin.php(474): WP_Hook->do_action(Array) #10 /nas/content/live/sitename/wp-admin/customize.php(123): do_action(‘customize_contr…’) #11 {main} thrown in /nas/content/live/sitename/wp-content/plugins/advanced-gutenberg/incl/advanced-gutenberg-main.php on line 2480

Hopefully that helps some.

Just want to say that I was getting a fatal error trying to activate the customizer with PHP 8 running plugin version 2.11.4 on WordPress 5.9 on WP Engine. I even disabled every plugin but PublishPress Blocks and activated the default theme, and still had the fatal error.

So I rolled back to PHP 7.4, and tried what was recommended above. I went to Blocks –> Block Access, clicked the Save Block Access button, and the issue was sorted. When I switched back to PHP 8, the error was gone. So glad I found this thread!!

Yes. Thanks from me too for the rapid response. I can confirm that added my text back to the <blockquote> tags in the feed. Looks like it will take a bit for that to actually show inside Facebook.

But that doesn’t surprise me. Facebook seems to cache stuff for 7 forevers.

I’m getting the same issue. All h3 heading tags and text for my articles are being stripped out of the instant article feed.

Just to follow up, I found that the wp-config.php file for my problematic site had both the WP_SITEURL and WP_HOME constants set with http URLs instead of https URLs.

It’s worth checking your Settings –> General settings to see what protocol those URLS are showing there. If they don’t both show https then it will likely cause issues with the new 4.4 responsive images.

Once I changed that I no longer needed the plugin because my images worked as expected.

I’m thinking this is either a problem in WordPress 4.4 or perhaps a compatibility issue with the way SSL is implemented on the server. I had the same issue with my main image being https as it was supposed to but all the srcset images having http URLs.

This plugin worked as a temporary patch until I can figure out what the real issue is: SSL Insecure Content Fixer With that plugin activated in the default configuration my images started working again.

It’s weird because I’m having this issue on one site, but not another on the same server even though both sites have SSL certs.

Instead of editing the plugin file you can add a priority to the comment_form_defaults filter in your theme so it fires before this filter line in the plugin. For example:

add_filter( 'comment_form_defaults', 'my_theme_comment_form_args', 5 );

Adding the comma 5 there fires adds the theme filter before the plugin filter and then the checkbox reappears.

Appreciate it Ben. You’ve got a really useful plugin here.

Yep. There’s an issue with the admin stats screens in WordPress 4.2 at the moment. Settings pages appear to work just fine though.

For some reason PuSHPress also started causing my media library to not display images in the grid view and also in the post Add Media area. List view in the media library worked though.

The plugin was disrupting my media library even though it was deactivated. I had to delete it from my install to get my media library working again.

For future reference, GitHub repository is here: https://github.com/jgalea/genesis-coauthors-plus

Just updated to your version 1.4. Very nice!

Had to make one minor adjustment to the CSS in our themes and now we’re back in business. Thank you for adding the generic CSS class back into the plugin output.

For anyone else reading this thread I also had to change the setting for the path to the gallery images under Slideshow –> Configuration. But that’s going to vary depending on server configuration. I had to go with absolute paths for the images. Also I updated all the shortcodes to the new [tribulant_slideshow] shortcode in case the old [slideshow] one ever stops working.

Not sure why this was marked as resolved. Changed that as I’m still hoping for an answer to my previous question.

Heya Antoine! I get what you are saying. The thing is that the folks who purchase our themes have a very broad range of technical ability. With many of the less technically inclined, asking them to add a div around your shortcode for something that we previously could just put in the theme’s style sheet will cause confusion for them, to say the least. Asking them to modify one of your plugin’s files is beyond many of their skill levels altogether.

Are you saying that you cannot simply either replace or add one generic CSS selector to your plugin’s content so we can provide a better experience for our customers by adding the necessary styling for them?