Fix intermediate images paths on backend editor

[TheCrowned]

Photon does not run in the post editor. For this reason, if an intermediate size image path is used, it will not be parsed in any way, it will just point to something that does not exist. This is an issue when client migrate to VIP Go from a platform that used intermediate images normally, and will break all their images in the backend editor.

Solution, part one

The best solution I can see is load full size images in post editor by stripping intermediate images suffixes from all images. This can be done by combining `strip_dimensions_from_url_path()` (which we already use in the frontend) with parsing the content for images and replacing the relevant paths.

This is likely the ideal solution, because we are stripping intermediate images paths (which do not exist on Go) and it is future-proof, in the sense that the link to the full size image will always exist. Also, this will not impact the frontend workings of Photon, because it grabs image size from style or width/height attributes.

Post HTML in database at time zero <img src="https://tumbleweed.simonwheatley.co.uk/wp-content/uploads/2018/06/funny_mustache_and_sunglasses_face_classic_round_sticker-r1ab2fe2fbae04a4d8ddc960835afbafa_v9waf_8byvr_324-660x344.jpg" width="660" height="344" /> Post HTML shown in the editor <img src="https://tumbleweed.simonwheatley.co.uk/wp-content/uploads/2018/06/funny_mustache_and_sunglasses_face_classic_round_sticker-r1ab2fe2fbae04a4d8ddc960835afbafa_v9waf_8byvr_324.jpg" width="660" height="344" /> Expected behavior Image is displayed correctly. Post HTML after post is saved: <img src="https://tumbleweed.simonwheatley.co.uk/wp-content/uploads/2018/06/funny_mustache_and_sunglasses_face_classic_round_sticker-r1ab2fe2fbae04a4d8ddc960835afbafa_v9waf_8byvr_324.jpg" width="660" height="344" />

Solution, part two

If we really wanted to be extra careful and mindful, we could try to revert these changes on `post_save`, but I am not sure how difficult this would be.

Post HTML in database at time zero <img src="https://tumbleweed.simonwheatley.co.uk/wp-content/uploads/2018/06/funny_mustache_and_sunglasses_face_classic_round_sticker-r1ab2fe2fbae04a4d8ddc960835afbafa_v9waf_8byvr_324-600x300.jpg" width="660" height="344" /> Post HTML shown in the editor <img src="https://tumbleweed.simonwheatley.co.uk/wp-content/uploads/2018/06/funny_mustache_and_sunglasses_face_classic_round_sticker-r1ab2fe2fbae04a4d8ddc960835afbafa_v9waf_8byvr_324.jpg" width="660" height="344" /> Expected behavior Image is displayed correctly. Post HTML after post is saved: <img src="https://tumbleweed.simonwheatley.co.uk/wp-content/uploads/2018/06/funny_mustache_and_sunglasses_face_classic_round_sticker-r1ab2fe2fbae04a4d8ddc960835afbafa_v9waf_8byvr_324-600x300.jpg" width="660" height="344" /> Advantage To us, none. To the client, if they migrate again somewhere else, and intermediate images are required, they can regenerate them using some tool and their posts would already be using them with no action needed.

--

For more context, see https://vipsupportp2.wordpress.com/2018/06/27/intermediate-images-on-vip-go-sites/

[TheCrowned]

I am going to put my code here for future reference, but part two of the solution is really a useless effort. Images on existing sites already have Photon querystring appended to the filenames, and trying to revert the changes after saving a post is very difficult to get right, and apparently quite useless.

For example, see this post: <amp-img class="lazyautosizes lazyload amp-wp-enforced-sizes" src="https://i1.wp.com/www.mercurynews.com/wp-content/uploads/2017/03/miss-manners.jpg?w=620&amp;crop=0%2C0px%2C100%2C9999px&amp;ssl=1" srcset="https://i1.wp.com/www.mercurynews.com/wp-content/uploads/2017/03/miss-manners.jpg?w=620&amp;crop=0%2C0px%2C100%2C9999px&amp;ssl=1 620w,https://i1.wp.com/www.mercurynews.com/wp-content/uploads/2017/03/miss-manners.jpg?w=210&amp;crop=0%2C0px%2C100%2C9999px&amp;ssl=1 210w" alt="Judith Martin" width="612" height="441" layout="intrinsic"></amp-img><figcaption class="wp-caption-text">Judith Martin </figcaption></figure>

Here is my code to revert changes on post save:

/**
 * Reverts Photon-like URLs when saving a post.
 * Replaces image.jpg?resize=300%2C400 with image.jpg.
 *
 * @param array $data Post insert data
 * @param array $postarr Post data, unsanitized
 */ 
function revert_editor_image_paths( $data, $postarr ) {
	$content = stripslashes( $data['post_content'] );

	$images = Jetpack_Photon::parse_images_from_html( $content );
	foreach( $images['img_url'] as $index => $url ) {

		// Look only in img src as it may be different from link href, and we care more about the img.
		// For ex, img could have a src like ?resize=300%2C&ssl=1 but link only ?resize=300%2C.
		// Looking in $tag would catch the link href as it comes first, and we wouldn't be able to rebuild the other querystring properly.
		preg_match( '/([\?|&])resize=(\d+)%2C(\d+)(&*)/', $url, $matches ); 

		// Need to account for all situations

		// were there other query args after our match?
		// ?force=1&resize=300%2C400&ssl=1 --> ?force=1&ssl=1
		$query_string_after = empty( $matches[4] ) ? '' : '&'; 

		// ?force=1&resize=300%2C400 --> ?force=1
		// ?resize=300%2C400 --> (empty)
		//$query_string_before = $matches[1] == '&' ? '' : ''; // was this at the beginning of the querystring?

		// ?resize=300%2C400&ssl=1 --> ?ssl=1
		if( $matches[1] === '?' && $matches[4] === '&' ) {
			$query_string_before = '?';
			$query_string_after = '';
		}

		// Replace URL that in image tags, then replace that in content (don't want to replace other, possibly legitimate parts of content)
		$new_tag = str_replace( $matches[0], $query_string_before . '' . $query_string_after, $images['img_tag'][$index] );
		$content = str_replace( $images['img_tag'][$index], $new_tag, $content );
	}

	$data['post_content'] = addslashes( $content );	
	return $data;
}
add_filter( 'wp_insert_post_data', 'revert_editor_image_paths', 10, 2 );

[github-actions[bot]]

This issue has been marked stale because it has been open for 60 days with no activity. If there is no activity within 7 days, it will be closed.

This is an automation to keep issues manageable and actionable and is not a comment on the quality of this issue nor on the work done so far. Closed issues are still valuable to the project and are available to be searched.