krikke

Hi @johnnyj56 I do not use BuddyBoss on any website.

Hi @seinomedia there is no noticeable difference between the websites. We use the same plugin stack. Since the issue was not workable, I backed up the website using a WordPress plugin, removed the website from my host, reinstalled, restored backup. That restored functionality.

I will mark as resolved, even though the root cause is not fixed. As I worked around the issue and it no longer presents, I cannot help in fixing.

Hi @seinomedia

Thank you for the reply.

Yes, I regenerated numerous times.

Since 1/3 websites works as expected without issue after the migration (using the same process), I would be surprised if the host is the root cause of this issue.

Kristof

Thank you for the quick response @mahesh901122

I can now see you implemented an initial conditional logic. could not verify the fixes due to a couple of issues:

• Cannot select individual pages/posts in conditional logic
• It appears the gutenberg block has dissapeared, I cannot find a way to add it to a page

Unfortunately, I can not share a link. It was on various client websites & I had to remove the plugin.

I can tell you I use a Gutenberg stack (kadence theme, kadence blocks, …)

Thank you for the swift response @mahesh901122

I understand that’s the design decision you took. I would challenge that decision as it would be better from a user POV to keep the options open when/where to use the plugin & not impact page speed unneeded. There are ways to change when scripts should be loaded based on certain use criteria. In most use cases, the plugin is only used on very select pages (like a contact page).

Furthermore, your reply does not answer my second point.

• It should not load back-end block editor JS files on the front end. Examples: block-editor.min.js, editor.min.js, etc. loaded on all pages. While they should generally not be loaded at all on the front-end.

Those files should not be loaded on the front-end even with the stated design decisions. Furthermore, disabling all your js/css files sitewide does not unload these files. Disabling the plugin immediately unloads all of these files. So it is not based on plugin usage, but rather the plugin being activated.

Anyhow, I hope this feedback is useful to you to improve the plugin. I will no longer be able to use it on mine or my client sites

Kristof

• This reply was modified 7 months, 4 weeks ago by krikke.

Experiencing the same issue. clicking on “no thanks” makes it come back after a couple of hours.

Thanks for the quick action & update @azimkhan123 , appreciated!

Just to check, has the css/js update been pushed yet? Updated base & pro, I’m on V2.8.9 and V1.4.8 respectively. But I still see the css/js on non-postx pages.

style.min.css?ver=2.8.9 & ultp.min.js?ver=2.8.9

Example on https://dev.ysquared.consulting

Thank you!

Thank you for the feedback @azimkhan123 !

I tried enabling srcset (it was not enabled previously), it might have reduced some warnings/tips, but does not (significantly) improve the pagespeed. I’m still around 78-79. It is still enabled now on https://dev.fusico.digital/blog/ so you can see for yourself.

Kristof

Hi @azimkhan123 ,

Thank you for the prompt action & response!

I’ll gladly give you some indication to the pagespeed impact. Here are 2 (before/after) screenshots of a page on which I have PostX enabled & disabled. That is the only change.

PostX pagespeed impact

To give you an Idea of the complexity of this postgrid: it is just 4 images, text, filter.

https://dev.fusico.digital/blog/

Kristof

Hi Benjamin

Thanks for helping me out!

After inserting the code in the place like you described, unfortunately still the same issue. with what I believe to be the same stack trace:

Fatal error: 
Uncaught TypeError: array_keys(): Argument #1 ($array) must be of type array, null given in /wp-content/plugins/seopress-for-mainwp/inc/class-main.php:214 
Stack trace: 
#0 /wp-content/plugins/seopress-for-mainwp/inc/class-main.php(214): array_keys() 
#1 /wp-includes/class-wp-hook.php(307): SEOPress\MainWP\Main->remove_mainwp_post_types() 
#2 /wp-includes/plugin.php(191): WP_Hook->apply_filters() 
#3 /wp-content/plugins/wp-seopress/src/Services/WordPressData.php(41): apply_filters() 
#4 /wp-content/plugins/wp-seopress/src/Actions/Admin/ManageColumn.php(41): SEOPress\Services\WordPressData->getPostTypes() 
#5 /wp-includes/class-wp-hook.php(307): SEOPress\Actions\Admin\ManageColumn->setup() 
#6 /wp-includes/class-wp-hook.php(331): WP_Hook->apply_filters() 
#7 /wp-includes/plugin.php(476): WP_Hook->do_action() 
#8 /wp-settings.php(598): do_action() 
#9 /wp-config.php(81): require_once('...') 
#10 /wp-load.php(50): require_once('...') #11 /wp-admin/admin.php(34): require_once('...') #12 {main} thrown in /wp-content/plugins/seopress-for-mainwp/inc/class-main.php on line 214

Hi Benjamin,

Not to hijack the thread, but I also get a fatal error (wordpress default error page)

This is the report email I get:

Error Details
=============
An error of type E_ERROR was caused in line 212 of the file /wp-content/plugins/seopress-for-mainwp/inc/class-main.php.
Error message: Uncaught TypeError: array_keys(): Argument #1 ($array) must be of type array, null given in /wp-content/plugins/seopress-for-mainwp/inc/class-main.php:212
Stack trace:
#0 /wp-content/plugins/seopress-for-mainwp/inc/class-main.php(212): array_keys()
#1 /wp-includes/class-wp-hook.php(307): SEOPress\MainWP\Main->remove_mainwp_post_types()
#2 /wp-includes/plugin.php(191): WP_Hook->apply_filters()
#3 /wp-content/plugins/wp-seopress/src/Services/WordPressData.php(41): apply_filters()
#4 /wp-content/plugins/wp-seopress/src/Actions/Admin/ManageColumn.php(41): SEOPress\Services\WordPressData->getPostTypes()
#5 /wp-includes/class-wp-hook.php(307): SEOPress\Actions\Admin\ManageColumn->setup()
#6 /wp-includes/class-wp-hook.php(331): WP_Hook->apply_filters()
#7 /wp-includes/plugin.php(476): WP_Hook->do_action()
#8 /wp-settings.php(598): do_action()
#9 /wp-config.php(78): require_once('...')
#10 /wp-load.php(50): require_once('...')
#11 /wp-admin/admin.php(34): require_once('...')
#12 {main}
  thrown

I am running PHP 8.0.23.

Does that help?
Kristof

Hi Thomas,

That makes total sense. Thank you. Certainly not super urgent more of a nice to have as not many will look in the console randomly.

Thanks for the clarification.

Kristof

Thank you Benjamin, that solves my issue indeed.

So for the others facing my problem, like Benjamin mentioned, going into the “Titles & Metas” > “Archives” menu and enabling noindex on the “Search archives” does alleviate this problem.

Kristof

Fixed indeed, great! Thank you Daan.

It seems this causes the unnecessary styles to load in init.php:

Line 76: 'style' => 'bod-modal-block-style-css',

Update: I may have fixed it, could you please confirm and if validated include in the release branch?

Fix as follows, all in init.php:

Removed on line 48: trailing , at the end of the line
Removed line 49: array( 'wp-editor' )
Added on line 57: 'wp-editor' in array( 'wp-edit-blocks', 'wp-editor' )

Seems to have fixed it for me and still enqueues the styles in the back end, but I don’t know the exact impact.

• This reply was modified 3 years, 4 months ago by krikke. Reason: possible fix