mashbo

I know right, I did notice the visual difference but assumed there had been a rebrand.

Cheers for responding though

Dammit: ignore.

I’ve gotten confused between

https://www.ads-software.com/support/plugin/redirection/

and

https://www.ads-software.com/support/plugin/redirections/

Apologies for wasting your time

Dammit: ignore.

I’ve gotten confused between

https://www.ads-software.com/support/plugin/redirection/

and

https://www.ads-software.com/support/plugin/redirections/

Apologies for wasting your time

in this example, the prefix and the end of the urls are the same.

So on a single site with prefix /es, while saving a redirect from:

https://example.com/es/cobertura/nuestros-clientes

the url got trimmed to to

https://example.com/es/cobertura/nuestros-client

It isn’t stripped on initial input, the value remains correct up to the point where you save the redirect. However once the page reloads, you notice that the value has changed, and can confirm by checking out the value in the database as well.

That mapping with maybe_unserialized didnt fix it, shame.

Anyone from Nested Pages been able to look at this thread yet?

First stab at a potential fix:

wp-nested-pages/app/Entities/Post/PostCloner.php : function cloneMeta() // prior to calling add_post_meta

		$meta = array_map(
		    'maybe_unserialize',
            $meta
        );

That might sort it out.

Can confirm, we’ve run into this issue as well.

Its down to Nested pages sourcing the custom data without passing a key value.

wp-nested-pages/app/Entities/Post/PostCloner.php:116

This in turn gets passed as an empty string to WordPress’s get_metadata which then causes the array of values to be returned before any attempt to unserialize the stored fields happens.

wp/wp-includes/meta.php:504

	if ( ! $meta_key ) {
		return $meta_cache;
	}

	if ( isset($meta_cache[$meta_key]) ) {
		if ( $single )
			return maybe_unserialize( $meta_cache[$meta_key][0] );
		else
			return array_map('maybe_unserialize', $meta_cache[$meta_key]);
	}

You end up with a string of a serialized array in your returned $meta_cache variable, which then gets passed into add_post_meta / add_metadata.

This then hits
wp/wp-includes/functions.php:438

	if ( is_array( $data ) || is_object( $data ) )
		return serialize( $data );

Which should have been passed an array, before correctly returning the serialized version, but instead, skips it to hit:

	// Double serialization is required for backward compatibility.
	// See https://core.trac.www.ads-software.com/ticket/12930
	// Also the world will end. See WP 3.6.1.
	if ( is_serialized( $data, false ) )
		return serialize( $data );

	return $data;

Resulting in the serialized string being serialized before return. Repeat ad infinitum for each clone.

We’ve not hacked together a fix yet: we’ve not seen any hooks around getting or setting the data as part of the get/setmetdata functions.

But it is incredibly annoying.

It looks like there’s actually an MR already open waiting to be merged that might fix this:

https://github.com/magicstickuk/multisite-post-duplicator/pull/73

As of 3 months ago.

@mateuszgbiorczyk

I’ve got that information ready do send to you, what’s the best way for you to receive it?

Do you have an email (even something temporary) that I can use to send the archive over, probably via WeTransfer or the like.

The open graph tags are correct, but linkedin are using the oembed to create the embeded block and are saying the information needs updating in the oembed. Yoast is modifying the title in the html, adding the open graph tags, but leaving the oembed details untouched.

Anything that supports oembed is going to receive the wrong information for sharing. I would definitely class this as an issue for yoast to investigate.

edit: Just spoken to LinkedIn again, they are going to update the documentation to include information about the oEmbed JSON.

• This reply was modified 6 years, 6 months ago by mashbo.

I was having similar issues involving the title not being what was set in the og tags and no description. I reached out to linkedin, they purposefully do not display the description, wanting the users to write a description themselves but the title issue is caused by the oembed data generated by wordpress, it uses the page title from wordpress instead of yoast meaning everywhere else shows the intended page title, but linked in shows the page name (eg a “Home” page having a title like “Company Name – Company Slogan” but showing as “Home” in linkedin).

This feels like something the yoast plugin should be overwriting with the intended page title.

• This reply was modified 6 years, 6 months ago by mashbo.