ispreview

Yep fixed.

So I spent a bit of time and tracked this down to the class-gnpub-compat.php file, specifically these lines (around line 32):

	public static function init() {
		add_action( 'plugins_loaded', array( 'GNPUB_Compat', 'seo_plugins_strip_category_base' ), 20 );
	}

I think I’ve fixed it by tweaking the add_action line to use ‘init’ instead of ‘plugins_loaded’ because the latter fires immediately after all plugins are loaded, but before WordPress has finished loading translations, rewrites, and most plugin setup:

add_action( 'init', array( 'GNPUB_Compat', 'seo_plugins_strip_category_base' ), 20 );

The conflict now seems to be solved because moving this compatibility check to ‘init’ ensures that when GN Publisher checks WPSEO_Options::get(), Yoast is fully ready — no premature translation loading. Thoughts?

Any response?

I’ve created a video, but as it exposes some secure information, then I can’t post it in public here. Where should I send it?

I’m not a PHP coder, but I got so tired of waiting for you to fix the most basic stuff that I’ve learnt and done it myself:

/wp-content/plugins/wordpress-seo/vendor_prefixed/symfony/dependency-injection/Container.php on line 60

Change:

    public function __construct(\YoastSEO_Vendor\Symfony\Component\DependencyInjection\ParameterBag\ParameterBagInterface $parameterBag = null)

To This:

    public function __construct(?\YoastSEO_Vendor\Symfony\Component\DependencyInjection\ParameterBag\ParameterBagInterface $parameterBag = null)


/wp-content/plugins/wordpress-seo/vendor_prefixed/league/oauth2-client/src/Provider/AbstractProvider.php on line 416

Change:

    public function authorize(array $options = [], callable $redirectHandler = null)

To:

    public function authorize(array $options = [], callable|null $redirectHandler = null)

/wp-content/plugins/wordpress-seo/vendor_prefixed/guzzlehttp/guzzle/src/Client.php on line 181

Change:

    public function getConfig(string $option = null)

To:

    public function getConfig(?string $option = null)


/wp-content/plugins/wordpress-seo/vendor_prefixed/guzzlehttp/guzzle/src/ClientInterface.php on line 77

Change:

    public function getConfig(string $option = null);

To This:

    public function getConfig(?string $option = null);

So I did a bunch of testing and identified that the cause of the problem is this new code in /src/shortcode/posts.php:

        if ( is_numeric($ajaxify) ) {
            $load_via_ajax = (bool) absint($ajaxify);

If I change that back to what it was before (as below)..

        if ( isset($attributes['ajaxify']) && is_numeric($attributes['ajaxify']) ) {
            $load_via_ajax = (bool) absint($attributes['ajaxify']);

..then I never have to see that ugly loading bar 🙂 and the list loads instantly. I am not skilled enough with PHP to know why the modified code under 7.3.2 is so much slower and showing the bar, while the 7.3.1 code does not and works well.

FYI – Tested with latest wordpress release, as well as both PHP8.3 and 8.4.

• This reply was modified 12 months ago by ispreview.

I’ve done some more testing and noted that something similar does occur on my beta install too, where it sits for a few seconds and then loads. My beta install isn’t using cache though and I’m also only calling ‘range’ => ‘daily’, rather than the last 7 days. Overall it seems like the plugin is now taking longer to pull the summaries on first load (under 7.3.1 it was instant), which might explain why my public install sees this constantly (i.e. so slow to pull summaries from the past 7 days due to more content, so WP Super Cache only ends up storing the loading bar screen). But I’m guessing.