brbrbr

WordPress-core rebuilds the taxonomy structure after a switch_to_locale and restore_previous_locale for posts using the change_locale action. Otherwise, the same issue would occur with posts in the block editor.

I still think it’s a omission in this plugin. but hey, it’s your plugin and it’s a bit of a speciale situation that triggers the fault. So I happily forked your plugin.

Steps:

• default WordPress install set to en_US (default)
• installed?Contact Form 7?and?Pages with category and tag
• created page with contact form: editing works
• switch language to Dutch (nl_NL)
• the editor now gives a (javascript) message as soon as the sidebar is active: https://wp.projecten.dev/vid/

As I said, it’s a special situation.

The issue is not caused by another plugin, switch_to_locale is part of wordpress

I have to admit the problem is quite an edge case in usage, but I think it is an ommision in your plugin.

Look at the filters in wp-includes/default-filters.php for create_initial_taxonomies and create_initial_post_types both are execute for ‘init’ and ‘change_locale’

To stop using a plugin is not a solution for a plugin that is activity used.

Hi,

I found the problem. CF7 is not the problem, just triggering it.

register_taxonomy_for_object_type is not persistent with change_locale

thanks for your time

https://wp.projecten.dev/contact/

Steps:

• default WordPress install set to en_US (default)
• installed Contact Form 7 and Pages with category and tag
• created page with contact form: editing works
• switch language to Dutch (nl_NL)
• the editor now gives a (javascript) message as soon as the sidebar is active.

it’s in the backend. It is in editor.js while fetching categories. I added the errors from the console below

I could send the login credentials.

Furthermore, I tried to reproduce the error on a blank WordPress website. And wasn’t able to.

So I investigated a bit more

The problem only occurred on older forms. A newly created one did not trigger the error.

Finally, I found the difference. My website is in Dutch (nl_NL), however the form has a meta_key _locale set to en_GB.

That mismatch triggers the error, changing the _locale manually to nl_NL resolves the problem.

The _locale mismatch does not trigger an error in posts, only on pages with categories enabled.

editor.js?ver=ef18ccc…:18142 Uncaught TypeError: Cannot read properties of undefined (reading 'indexOf')
    at treeHasSelection (editor.js?ver=ef18cc…d0cd84bb34:18142:15)
    at termOrChildIsSelected (editor.js?ver=ef18cc…d0cd84bb34:18151:27)
    at Array.sort (<anonymous>)
    at sortBySelected (editor.js?ver=ef18cc…d0cd84bb34:18165:15)
    at editor.js?ver=ef18cc…d0cd84bb34:18276:84
    at updateMemo (react-dom.js?ver=18.3.1:16437:21)
    at Object.useMemo (react-dom.js?ver=18.3.1:17077:18)
    at useMemo (react.js?ver=18.3.1:1640:23)
    at HierarchicalTermSelector (editor.js?ver=ef18cc…d0cd84bb34:18276:77)
    at renderWithHooks (react-dom.js?ver=18.3.1:15496:20)

react-dom.js?ver=18.3.1:18714 The above error occurred in the <HierarchicalTermSelector> component:

    at HierarchicalTermSelector (https://test.logze.nl/wp-includes/js/dist/editor.js?ver=ef18ccc…:18228:3)
    at wn (https://test.logze.nl/wp-content/plugins/seo-by-rank-math/assets/admin/js/gutenberg.js?ver=1.0.235:1:38592)
    at FilteredComponentRenderer (https://test.logze.nl/wp-includes/js/dist/components.js?ver=490baf0…:68438:9)
    at div
    at UnforwardedPanelBody (https://test.logze.nl/wp-includes/js/dist/components.js?ver=490baf0…:61822:5)
    at TaxonomyPanel (https://test.logze.nl/wp-includes/js/dist/editor.js?ver=ef18ccc…:20536:3)
    at PostTaxonomies (https://test.logze.nl/wp-includes/js/dist/editor.js?ver=ef18ccc…:20442:3)
    at PostTaxonomiesCheck (https://test.logze.nl/wp-includes/js/dist/editor.js?ver=ef18ccc…:20506:3)
    at panel_PostTaxonomies
    at div
    at ContextProvider
    at ScopedContextProvider
    at ContextProvider
    at ContextProvider
    at ScopedContextProvider
    at ContextProvider
    at ContextProvider
    at ContextProvider
    at ScopedContextProvider
    at ContextProvider
    at ScopedContextProvider
    at ContextProvider
    at ContextProvider
    at ScopedContextProvider
    at https://test.logze.nl/wp-includes/js/dist/components.js?ver=490baf0…:3576:59
    at https://test.logze.nl/wp-includes/js/dist/components.js?ver=490baf0…:14024:47
    at TabPanel (https://test.logze.nl/wp-includes/js/dist/components.js?ver=490baf0…:71330:3)
    at div
    at UnforwardedPanel (https://test.logze.nl/wp-includes/js/dist/components.js?ver=490baf0…:61749:3)
    at div
    at div
    at MotionComponent (https://test.logze.nl/wp-includes/js/dist/components.js?ver=490baf0…:16523:46)
    at PresenceChild (https://test.logze.nl/wp-includes/js/dist/components.js?ver=490baf0…:26778:26)
    at AnimatePresence (https://test.logze.nl/wp-includes/js/dist/components.js?ver=490baf0…:26898:28)
    at SlotComponent (https://test.logze.nl/wp-includes/js/dist/components.js?ver=490baf0…:33416:5)
    at Slot
    at UnforwardedSlot (https://test.logze.nl/wp-includes/js/dist/components.js?ver=490baf0…:33976:5)
    at ComplementaryAreaSlot (https://test.logze.nl/wp-includes/js/dist/editor.js?ver=ef18ccc…:9578:3)
    at div
    at https://test.logze.nl/wp-includes/js/dist/editor.js?ver=ef18ccc…:9868:3
    at div
    at div
    at div
    at InterfaceSkeleton (https://test.logze.nl/wp-includes/js/dist/editor.js?ver=ef18ccc…:9958:3)
    at EditorInterface (https://test.logze.nl/wp-includes/js/dist/editor.js?ver=ef18ccc…:27627:3)
    at BlockRefsProvider (https://test.logze.nl/wp-includes/js/dist/block-editor.js?ver=6d9093f…:27718:3)
    at Provider (https://test.logze.nl/wp-includes/js/dist/components.js?ver=490baf0…:33991:3)
    at https://test.logze.nl/wp-includes/js/dist/block-editor.js?ver=6d9093f…:36994:5
    at https://test.logze.nl/wp-includes/js/dist/block-editor.js?ver=6d9093f…:36538:3
    at BlockContextProvider (https://test.logze.nl/wp-includes/js/dist/block-editor.js?ver=6d9093f…:37057:3)
    at EntityProvider (https://test.logze.nl/wp-includes/js/dist/core-data.js?ver=3461264…:6996:3)
    at EntityProvider (https://test.logze.nl/wp-includes/js/dist/core-data.js?ver=3461264…:6996:3)
    at https://test.logze.nl/wp-includes/js/dist/editor.js?ver=ef18ccc…:24581:3
    at https://test.logze.nl/wp-includes/js/dist/editor.js?ver=ef18ccc…:21973:3
    at Editor (https://test.logze.nl/wp-includes/js/dist/editor.js?ver=ef18ccc…:29356:3)
    at div
    at ErrorBoundary (https://test.logze.nl/wp-includes/js/dist/editor.js?ver=ef18ccc…:11688:5)
    at SlotFillProvider (https://test.logze.nl/wp-includes/js/dist/components.js?ver=490baf0…:33829:3)
    at provider_SlotFillProvider (https://test.logze.nl/wp-includes/js/dist/components.js?ver=490baf0…:33927:3)
    at Provider (https://test.logze.nl/wp-includes/js/dist/components.js?ver=490baf0…:33991:3)
    at Layout (https://test.logze.nl/wp-includes/js/dist/edit-post.js?ver=dfe4443…:3116:11)

React will try to recreate this component tree from scratch using the error boundary you provided, ErrorBoundary.

As a side note. Even if the ‘url’ wasn’t replaced incorrectly, the content would be effected by the encoding issue because of the \u0026

Not just SEO plugin FAQ’s. Any block with the tokens ‘<‘ ‘>’ ‘\”‘ or ‘&’ within the block attributes is encoded. And will cause issues if the content is not properly escaped when sent to wp_update_post.

wp-includes/blocks.php: serialize_block_attributes

• This reply was modified 3 months, 2 weeks ago by brbrbr.

I have an wordpress (youtube) embed and a broken link on a page:

before:

<!-- wp:embed {"url":"https://www.youtube.com/watch?v=tZWWD3HEYCc\u0026ab_channel=WayOutWest-WorkshopStuff","type":"video","providerNameSlug":"youtube","responsive":true,"className":"wp-embed-aspect-16-9 wp-has-aspect-ratio"} -->
<figure class="wp-block-embed is-type-video is-provider-youtube wp-block-embed-youtube wp-embed-aspect-16-9 wp-has-aspect-ratio"><div class="wp-block-embed__wrapper">
https://www.youtube.com/watch?v=tZWWD3HEYCc&amp;ab_channel=WayOutWest-WorkshopStuff
</div></figure>
<!-- /wp:embed -->

<!-- wp:paragraph -->
<p><a >A Broken Link</a></p>
<!-- /wp:paragraph -->

after replacing the example.com/broken link via the cloud, I get a ‘Block contains unexpected or invalid content.’ in the editor and the content looks like:

<!-- wp:embed {"url":"https://example.com","type":"video","providerNameSlug":"youtube","responsive":true,"className":"wp-embed-aspect-16-9 wp-has-aspect-ratio"} -->
<figure class="wp-block-embed is-type-video is-provider-youtube wp-block-embed-youtube wp-embed-aspect-16-9 wp-has-aspect-ratio"><div class="wp-block-embed__wrapper">
https://www.youtube.com/watch?v=tZWWD3HEYCc&amp;ab_channel=WayOutWest-WorkshopStuff
</div></figure>
<!-- /wp:embed -->

<!-- wp:paragraph -->
<p><a >A Broken Link</a></p>
<!-- /wp:paragraph -->

the broken link is fixed, but the ‘url’ too. And the generated HTML is not fixed ( causing the ‘Block contains unexpected or invalid content.’)

• This reply was modified 3 months, 2 weeks ago by brbrbr.
• This reply was modified 3 months, 2 weeks ago by brbrbr.

AFTER the test above, I did change app/broken-links-actions/processors/class-main.php

return wp_update_post(
//quick type cast - now WP will slash the content
(object) array(
'ID' => $post_id,
'post_content' => $new_content,
)
);

And did a replacement on a different page. Now the content is not mutilated anymore, the link in the generated(!) HTML is updated but not in the block-settings. So I still get a message ‘Block contains unexpected or invalid content.’ in the block editor, as the stored generated HTML does not match the settings anymore.

As the HTML is re-generated from the settings when the page is loaded on the front end, the broken link is still visible on the front end.

So for blocks with links in generated HTML, the cloud checker can detect broken links but not fix.

Hi,

Thanks for your reply.

I’m using the free version of Rank Math SEO.

However, I think the problem affects any wp-block that has encoded HTML in the json setting.

I saw the same issue with Yoast SEO, although the problem is less visible since Yoast stores the settings differently

I recreated the issue on a blank WordPress site:

https://wp.projecten.dev/sample-page/

If you are slightly familiar with the database tool on your site, you might find the links there.

There is a table with all links of the local BLC checker.

For the cloud version: both the Yoast as Rank Math SEO tools collect all links on a website.

Would need a join to get the related posts.

I think the settings is saved as well, didn’t think of that. I think the bubble is nice. Doesn’t impact my site too much since I don’t have a zillion links. Still, I found that adding a proper index to the table helped:

ALTER TABLE {prefix}_blc_instances ADD INDEX lpc (link_id, parser_type, container_type);

To disable the bubble change line (location depend on version, but it should be the line 414 from your log).

$broken_links = 0; #$blc_link_query->get_filter_links( 'broken', array( 'count_only' => true ) );

Or remove the if block around that line completely.

(actually I think the line if (WPMUDEV_BLC\Core\Utils\Utilities::is_subsite() ) {could / should be moved to the top of that function. But I didn’t untangle the Cloud / Legacy / Local parts complety)

In older versions the menu showed a broken link count bubble.

The query that slows down your site is used to calculate this count. However the the count is never ever shown.

The related option 'show_link_count_bubble' can not be changed from the settings menu. But you could change it in legacy/init.php (around line 103).

fair enough,

would be quite impossible to include all eccentric needs into a single plugin. The api is quite a beast of possibilities.

The fix in rel=nofollow solved my actual problem as well.

regards