You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
create a sub-directory multisite (e.g., with main site URL https://example.test)
add a post to the main site that contains a gallery block (with "Link To: Attachment page")
add an image to the gallery
save the post
duplicate the main site (e.g., with new site URL https://example.test/new-site)
examine the post_content in the new site and you'll see that while the img/@src has been correctly replaced, the a/@href (and @img/@data-link) has not!
Note: this problem is not a result of plugin/theme custom tables in the main site not being duplicated.
For example, given post_content in the main site such as:
As mentioned, this has to do with the way MUCD::replace() is written. What happens is the following:
MUCD_Data::db_update_data() calls MUCD_Data::update() which eventually calls MUCD_Data::replace( 'the post content', 'https://example.test/wp-content/uploads', 'https://example.test/new-site/wp-content/uploads/sites/2 )
That replacement happens correctly
MUCD_Data::db_update_data() calls MUCD_Data::update() which eventually calls MUCD_Data::replace( 'the post content', 'https://example.test', 'https://example.test/new-site' )
That replacement does not happen correctly
the reason is that MUCD::replace() notices that the $val already contains 'https://example.test/new-site' (because of the previous replacement) and so does not do the replacement
this particular problem can be fixed in MUCD::db_update_data() by changing the order of the strings in $string_to_replace, putting $from_blog_url => $to_blog_url first
that works since $to_blog_url will be shorter than $to_upload_url (unless a site has done something really weird with changing the location of their uploads folder), and therefore, it is much more likely that $to_upload_url will not already exist in the post_content
however, I haven't tested enough to know whether changing the order of the replacements causes other problems
The text was updated successfully, but these errors were encountered:
Essentially it is just a plugin which sorts the replacement values so that it replaces the shortest ones first. This does mean the database prefix is the first replacement to run but it also means you don't need to hard-code the source/destination URLs and can just add it to /wp-content/mu-plugins/ so it does the replacement for you everywhere.
A very simple way to replicate the problem is:
https://example.test
)https://example.test/new-site
)post_content
in the new site and you'll see that while theimg/@src
has been correctly replaced, thea/@href
(and@img/@data-link
) has not!Note: this problem is not a result of plugin/theme custom tables in the main site not being duplicated.
For example, given
post_content
in the main site such as:it should result in
post_content
in the new site such as:However, the actual
post_content
in the new site is:As mentioned, this has to do with the way
MUCD::replace()
is written. What happens is the following:MUCD_Data::db_update_data()
callsMUCD_Data::update()
which eventually callsMUCD_Data::replace( 'the post content', 'https://example.test/wp-content/uploads', 'https://example.test/new-site/wp-content/uploads/sites/2 )
MUCD_Data::db_update_data()
callsMUCD_Data::update()
which eventually callsMUCD_Data::replace( 'the post content', 'https://example.test', 'https://example.test/new-site' )
MUCD::replace()
notices that the$val
already contains'https://example.test/new-site'
(because of the previous replacement) and so does not do the replacementMUCD::db_update_data()
by changing the order of the strings in$string_to_replace
, putting$from_blog_url => $to_blog_url
first$to_blog_url
will be shorter than$to_upload_url
(unless a site has done something really weird with changing the location of their uploads folder), and therefore, it is much more likely that$to_upload_url
will not already exist in thepost_content
The text was updated successfully, but these errors were encountered: