SQL and JS errors with Yoast SEO

[enricobattocchi]

Running Yoast SEO on Playground is currently impossible due to some errors:

Javascript errors

When editing a post with Yoast SEO active, the metabox is not rendered correctly (only the tab headers are present). This likely caused by the errors you can see in the browser console:

Uncaught SyntaxError: Identifier '__playground_readBlobAsText' has already been declared 
    (at block-editor.js?ver=e5a33cfc15f28fed4770:1:1)

Uncaught TypeError: window.yoast.initEditorIntegration is not a function
    at HTMLDocument.<anonymous> (post-edit.js?ver=19783a5bd770749a31a0:24:6786)

The first one seems to be caused by a double injection of the __playground_readBlobAsText code not just into the WP Core, but also in the plugin's block-editor.js file since unfortunately it shares the last part of the path that's used to identify where to inject that code. Could the path matching be made more unique to make sure only WP core and Gutenberg are targeted?

From what I can see, the second error is triggered by the first one preventing the correct initialization of the window.yoast object, so fixing the above would restore the metabox functionality.

SQL errors

On plugin activation some DB queries fail due to unsupported syntax. It seems that some of them should be supported by SQLite according to the documentation, while others are legitimate MySQL queries that may require to be translated. They are:

• ALTER TABLE <table> ADD <column>, while ALTER TABLE <table> ADD COLUMN <column> seems to be working (docs)
• ALTER TABLE <table> CHANGE <column> which doesn't seem to be supported in SQLite (docs)
• ALTER TABLE <table> CONVERT TO CHARACTER SET which doesn't seem to be supported in SQLite (docs)
• CREATE INDEX <index> and CREATE UNIQUE INDEX <index> (docs)
• SHOW KEYS FROM <table> which doesn't seem to be supported in SQLite

Actually these queries are related to our custom Indexables tables, which are usually disregarded in non-production environments. We may make sure that they are unused in Playground too, but some of the queries may run and return errors: in this scenario, though, they would not be relevant. Would there be a way to silence those errors or let those queries fail gracefully?

[bgrgicak]

Hi @enricobattocchi, thank you for reporting this. I can take a look at the __playground_readBlobAsText issue, but I'm not sure if we will be able to get to the SQL errors in time for WCEU.

Would it be possible to skip the indexing for the Playground Puzzle? If yes would you be able to update the Yoast blueprint with the missing code. Or share the code with me and I can make the change.

Would there be a way to silence those errors or let those queries fail gracefully?

We don't have a way to do it today.

[enricobattocchi]

Thanks @bgrgicak! I think we can use the blueprint to disregard the indexing, just setting WP_ENVIRONMENT_TYPE to anything different from production (I think local might make sense) should prevent it. As I said, though, it would only get rid of the major part of the SQL errors: you would get the initial ones that are intended to set the custom tables up, but then you should not get others while using the plugin.

Would it be enough for you to unblock Yoast SEO?

[bgrgicak]

I think we can use the blueprint to disregard the indexing, just setting WP_ENVIRONMENT_TYPE to anything different from production

Unfortunately we can't do that. It might mess up other plugins. Is there a hook we can remove to disable indexing?

[bgrgicak]

This PR should fix the JS issue https://github.com/WordPress/wordpress-playground/pull/1460

[enricobattocchi]

Unfortunately we can't do that. It might mess up other plugins. Is there a hook we can remove to disable indexing?

I see! Then this should do the trick:

add_filter( 'Yoast\WP\SEO\should_index_indexables', '__return_false' );

[bgrgicak]

Thank you! I will add this to the blueprint.

[enricobattocchi]

@bgrgicak do you think Yoast can be added to the Puzzle project with these fixes?

[bgrgicak]

@bgrgicak do you think Yoast can be added to the Puzzle project with these fixes?

Yes, we printed it. I just need to update the blueprint.

What would be a good way to skip onboarding in Yoast? Because people will only casually explore the site we want to avoid any onboarding flows with puzzle pieces.

[enricobattocchi]

Thanks @bgrgicak! :tada: Let me get back to you about that later today

[enricobattocchi]

@bgrgicak if I launch https://playground.wordpress.net/?plugin=wordpress-seo I'm not redirected to our onboarding page... I see instead that this blueprint is listing that page as the landing one, maybe you just need to remove it from the blueprint?

[bgrgicak]

@enricobattocchi I wanted the onboarding to load if only Yoast is installed. But if we have multiple puzzle pieces I want to skip it. When I open WP-admin, it redirects to the onboarding and I would like to prevent that redirect. https://playground.wordpress.net/?plugin=wordpress-seo&url=/wp-admin/

[bgrgicak]

@enricobattocchi I tried adding add_filter( 'Yoast\WP\SEO\should_index_indexables', '__return_false' ); but it didn't work for me.

Would you be able to help me build a blueprint that disables indexing and onboarding?

Here is what I built.

{
    "landingPage": "/",
    "steps": [
        {
            "step": "writeFile",
            "path": "/wordpress/wp-content/mu-plugins/wp-seo.php",
            "data": "<?php add_action('init', function() { add_filter( 'Yoast\\WP\\SEO\\should_index_indexables', '__return_false' ); } ); ?>"
        },
        {
            "step": "installPlugin",
            "pluginZipFile": {
                "resource": "wordpress.org/plugins",
                "slug": "wordpress-seo"
            },
            "options": {
                "activate": true
            }
        }
    ]
}

[enricobattocchi]

Sure, I'll have a look

[enricobattocchi]

hey @bgrgicak:

• about the indexation, your blueprint seems to have disabled it as expected:
• about the onboarding, I cannot seem to find a way to set the option to disable it. I've tried to add this, but I get a spinning wheel forever, definitely triggered by the update_option call:

  {
    "step": "runPHP",
    "code": "<?php require_once '/wordpress/wp-load.php'; $option_array = get_option('wpseo'); if ( $option_array && is_array( $option_array ) ) { $option_array['should_redirect_after_install_free'] = false; update_option( 'wpseo', $option_array ); }"
  }

[bgrgicak]

Thank you! I got it to work with this blueprint. I assume your code ran before Yoast was installed and the plugin overwrote the variable.

{
    "landingPage": "/",
    "steps": [
        {
            "step": "writeFile",
            "path": "/wordpress/wp-content/mu-plugins/wp-seo.php",
            "data": "<?php add_action('init', function() { add_filter( 'Yoast\\WP\\SEO\\should_index_indexables', '__return_false' );  } ); ?>"
        },
        {
            step: 'writeFile',
            path: '/wordpress/wp-content/mu-plugins/disable-yoast-onboarding.php',
            data: "<?php add_action( 'wpseo_activate', function() { $option_array = get_option('wpseo'); if ( $option_array && is_array( $option_array ) ) { $option_array['should_redirect_after_install_free'] = false; update_option( 'wpseo', $option_array ); } }, 1000 );",
        },
        {
            "step": "installPlugin",
            "pluginZipFile": {
                "resource": "wordpress.org/plugins",
                "slug": "wordpress-seo"
            },
            "options": {
                "activate": true
            }
        }
    ]
}