Skip to main content
Commonmark migration
Source Link

I am currently in the course of migrating site content from an old pre 4.1 site to a new setup and hitting an issue with the rounding error issue of #18532 and the corresponding fix.

To summarize this fixed a long standing rounding misbehaviour on the side of WordPress:

Imagine we upload an image with 693x173 and scale it to a width of 300:

  • pre 4.1: 300x74
  • post 4.1: 300x75

##The issue

The issue

Generally this doesn't cause any issues because existing files and <img> aren't touched.

But when you regenerating thumbs or importing attachments from a WXR file they get generated differently in the filesystem leaving all <img> in post_content dead.

##Looking for a solution

Looking for a solution

I have been thinking of various solutions:

###Going back to the bad old times

Going back to the bad old times

Changeset 30660 introduced a new filter wp_constrain_dimensions which can be used to just plug the old behaviour from before 4.1 back in. This does fix the issue. But I am wondering if this might cause issues later on and generally I'd like to have the fix so although this works I'd deem it non-ideal.

###The Times They Are a-Changin'

The Times They Are a-Changin'

So this leaves us with another goal: Clean up the DB and replace all references to the old files with references to the new files. The question I am actually asking here now is how to do this. I am looking for an effective and generally-applicable solution as I suspect this issue does and will affect a lot of people

My current idea is this:

  1. Import, regenerate or whatever which leaves us with the new files and broken tags.
  2. Create a list A from all resized files in the filesystem or alternatively getting this information from the database
  3. Parse this list and create a second list B with filenames all offset by one pixel as it would look before 4.1
  4. Do a search&replace over the whole database replacing all occurences of B with the relating entry in A

I am just not sure if this is the most smart and efficient way to handle this situation. It also feels a bit too brute-force. So before implementing it I just wanted to check with the infinite wisdom of the WPSE crowd ;)

[edit] Having read ck-macleods answer (thanks!) I think a fix should solve this once and for all so you do not need to constantly keep this issue in the back of your head. [/edit]

[edit2] I just found a related ticket on Trac. Adding for reference. [/edit2]

I am currently in the course of migrating site content from an old pre 4.1 site to a new setup and hitting an issue with the rounding error issue of #18532 and the corresponding fix.

To summarize this fixed a long standing rounding misbehaviour on the side of WordPress:

Imagine we upload an image with 693x173 and scale it to a width of 300:

  • pre 4.1: 300x74
  • post 4.1: 300x75

##The issue

Generally this doesn't cause any issues because existing files and <img> aren't touched.

But when you regenerating thumbs or importing attachments from a WXR file they get generated differently in the filesystem leaving all <img> in post_content dead.

##Looking for a solution

I have been thinking of various solutions:

###Going back to the bad old times

Changeset 30660 introduced a new filter wp_constrain_dimensions which can be used to just plug the old behaviour from before 4.1 back in. This does fix the issue. But I am wondering if this might cause issues later on and generally I'd like to have the fix so although this works I'd deem it non-ideal.

###The Times They Are a-Changin'

So this leaves us with another goal: Clean up the DB and replace all references to the old files with references to the new files. The question I am actually asking here now is how to do this. I am looking for an effective and generally-applicable solution as I suspect this issue does and will affect a lot of people

My current idea is this:

  1. Import, regenerate or whatever which leaves us with the new files and broken tags.
  2. Create a list A from all resized files in the filesystem or alternatively getting this information from the database
  3. Parse this list and create a second list B with filenames all offset by one pixel as it would look before 4.1
  4. Do a search&replace over the whole database replacing all occurences of B with the relating entry in A

I am just not sure if this is the most smart and efficient way to handle this situation. It also feels a bit too brute-force. So before implementing it I just wanted to check with the infinite wisdom of the WPSE crowd ;)

[edit] Having read ck-macleods answer (thanks!) I think a fix should solve this once and for all so you do not need to constantly keep this issue in the back of your head. [/edit]

[edit2] I just found a related ticket on Trac. Adding for reference. [/edit2]

I am currently in the course of migrating site content from an old pre 4.1 site to a new setup and hitting an issue with the rounding error issue of #18532 and the corresponding fix.

To summarize this fixed a long standing rounding misbehaviour on the side of WordPress:

Imagine we upload an image with 693x173 and scale it to a width of 300:

  • pre 4.1: 300x74
  • post 4.1: 300x75

The issue

Generally this doesn't cause any issues because existing files and <img> aren't touched.

But when you regenerating thumbs or importing attachments from a WXR file they get generated differently in the filesystem leaving all <img> in post_content dead.

Looking for a solution

I have been thinking of various solutions:

Going back to the bad old times

Changeset 30660 introduced a new filter wp_constrain_dimensions which can be used to just plug the old behaviour from before 4.1 back in. This does fix the issue. But I am wondering if this might cause issues later on and generally I'd like to have the fix so although this works I'd deem it non-ideal.

The Times They Are a-Changin'

So this leaves us with another goal: Clean up the DB and replace all references to the old files with references to the new files. The question I am actually asking here now is how to do this. I am looking for an effective and generally-applicable solution as I suspect this issue does and will affect a lot of people

My current idea is this:

  1. Import, regenerate or whatever which leaves us with the new files and broken tags.
  2. Create a list A from all resized files in the filesystem or alternatively getting this information from the database
  3. Parse this list and create a second list B with filenames all offset by one pixel as it would look before 4.1
  4. Do a search&replace over the whole database replacing all occurences of B with the relating entry in A

I am just not sure if this is the most smart and efficient way to handle this situation. It also feels a bit too brute-force. So before implementing it I just wanted to check with the infinite wisdom of the WPSE crowd ;)

[edit] Having read ck-macleods answer (thanks!) I think a fix should solve this once and for all so you do not need to constantly keep this issue in the back of your head. [/edit]

[edit2] I just found a related ticket on Trac. Adding for reference. [/edit2]

replaced http://wordpress.stackexchange.com/ with https://wordpress.stackexchange.com/
Source Link

I am currently in the course of migrating site content from an old pre 4.1 site to a new setup and hitting an issue with the rounding error issue of #18532 and the corresponding fix.

To summarize this fixed a long standing rounding misbehaviour on the side of WordPress:

Imagine we upload an image with 693x173 and scale it to a width of 300:

  • pre 4.1: 300x74
  • post 4.1: 300x75

##The issue

Generally this doesn't cause any issues because existing files and <img> aren't touched.

But when you regenerating thumbs or importing attachments from a WXR file they get generated differently in the filesystem leaving all <img> in post_content dead.

##Looking for a solution

I have been thinking of various solutions:

###Going back to the bad old times

Changeset 30660 introduced a new filter wp_constrain_dimensions which can be used to just plug the old behaviour from before 4.1 back in. This does fix the issue. But I am wondering if this might cause issues later on and generally I'd like to have the fix so although this works I'd deem it non-ideal.

###The Times They Are a-Changin'

So this leaves us with another goal: Clean up the DB and replace all references to the old files with references to the new files. The question I am actually asking here now is how to do this. I am looking for an effective and generally-applicable solution as I suspect this issue does and will affect a lot of people

My current idea is this:

  1. Import, regenerate or whatever which leaves us with the new files and broken tags.
  2. Create a list A from all resized files in the filesystem or alternatively getting this information from the database
  3. Parse this list and create a second list B with filenames all offset by one pixel as it would look before 4.1
  4. Do a search&replace over the whole database replacing all occurences of B with the relating entry in A

I am just not sure if this is the most smart and efficient way to handle this situation. It also feels a bit too brute-force. So before implementing it I just wanted to check with the infinite wisdom of the WPSE crowd ;)

[edit] Having read ck-macleodck-macleods answer (thanks!) I think a fix should solve this once and for all so you do not need to constantly keep this issue in the back of your head. [/edit]

[edit2] I just found a related ticket on Trac. Adding for reference. [/edit2]

I am currently in the course of migrating site content from an old pre 4.1 site to a new setup and hitting an issue with the rounding error issue of #18532 and the corresponding fix.

To summarize this fixed a long standing rounding misbehaviour on the side of WordPress:

Imagine we upload an image with 693x173 and scale it to a width of 300:

  • pre 4.1: 300x74
  • post 4.1: 300x75

##The issue

Generally this doesn't cause any issues because existing files and <img> aren't touched.

But when you regenerating thumbs or importing attachments from a WXR file they get generated differently in the filesystem leaving all <img> in post_content dead.

##Looking for a solution

I have been thinking of various solutions:

###Going back to the bad old times

Changeset 30660 introduced a new filter wp_constrain_dimensions which can be used to just plug the old behaviour from before 4.1 back in. This does fix the issue. But I am wondering if this might cause issues later on and generally I'd like to have the fix so although this works I'd deem it non-ideal.

###The Times They Are a-Changin'

So this leaves us with another goal: Clean up the DB and replace all references to the old files with references to the new files. The question I am actually asking here now is how to do this. I am looking for an effective and generally-applicable solution as I suspect this issue does and will affect a lot of people

My current idea is this:

  1. Import, regenerate or whatever which leaves us with the new files and broken tags.
  2. Create a list A from all resized files in the filesystem or alternatively getting this information from the database
  3. Parse this list and create a second list B with filenames all offset by one pixel as it would look before 4.1
  4. Do a search&replace over the whole database replacing all occurences of B with the relating entry in A

I am just not sure if this is the most smart and efficient way to handle this situation. It also feels a bit too brute-force. So before implementing it I just wanted to check with the infinite wisdom of the WPSE crowd ;)

[edit] Having read ck-macleods answer (thanks!) I think a fix should solve this once and for all so you do not need to constantly keep this issue in the back of your head. [/edit]

[edit2] I just found a related ticket on Trac. Adding for reference. [/edit2]

I am currently in the course of migrating site content from an old pre 4.1 site to a new setup and hitting an issue with the rounding error issue of #18532 and the corresponding fix.

To summarize this fixed a long standing rounding misbehaviour on the side of WordPress:

Imagine we upload an image with 693x173 and scale it to a width of 300:

  • pre 4.1: 300x74
  • post 4.1: 300x75

##The issue

Generally this doesn't cause any issues because existing files and <img> aren't touched.

But when you regenerating thumbs or importing attachments from a WXR file they get generated differently in the filesystem leaving all <img> in post_content dead.

##Looking for a solution

I have been thinking of various solutions:

###Going back to the bad old times

Changeset 30660 introduced a new filter wp_constrain_dimensions which can be used to just plug the old behaviour from before 4.1 back in. This does fix the issue. But I am wondering if this might cause issues later on and generally I'd like to have the fix so although this works I'd deem it non-ideal.

###The Times They Are a-Changin'

So this leaves us with another goal: Clean up the DB and replace all references to the old files with references to the new files. The question I am actually asking here now is how to do this. I am looking for an effective and generally-applicable solution as I suspect this issue does and will affect a lot of people

My current idea is this:

  1. Import, regenerate or whatever which leaves us with the new files and broken tags.
  2. Create a list A from all resized files in the filesystem or alternatively getting this information from the database
  3. Parse this list and create a second list B with filenames all offset by one pixel as it would look before 4.1
  4. Do a search&replace over the whole database replacing all occurences of B with the relating entry in A

I am just not sure if this is the most smart and efficient way to handle this situation. It also feels a bit too brute-force. So before implementing it I just wanted to check with the infinite wisdom of the WPSE crowd ;)

[edit] Having read ck-macleods answer (thanks!) I think a fix should solve this once and for all so you do not need to constantly keep this issue in the back of your head. [/edit]

[edit2] I just found a related ticket on Trac. Adding for reference. [/edit2]

Notice removed Draw attention by CommunityBot
Bounty Ended with no winning answer by CommunityBot
add Trac Ticket
Source Link
kraftner
  • 5.6k
  • 1
  • 29
  • 46

I am currently in the course of migrating site content from an old pre 4.1 site to a new setup and hitting an issue with the rounding error issue of #18532 and the corresponding fix.

To summarize this fixed a long standing rounding misbehaviour on the side of WordPress:

Imagine we upload an image with 693x173 and scale it to a width of 300:

  • pre 4.1: 300x74
  • post 4.1: 300x75

##The issue

Generally this doesn't cause any issues because existing files and <img> aren't touched.

But when you regenerating thumbs or importing attachments from a WXR file they get generated differently in the filesystem leaving all <img> in post_content dead.

##Looking for a solution

I have been thinking of various solutions:

###Going back to the bad old times

Changeset 30660 introduced a new filter wp_constrain_dimensions which can be used to just plug the old behaviour from before 4.1 back in. This does fix the issue. But I am wondering if this might cause issues later on and generally I'd like to have the fix so although this works I'd deem it non-ideal.

###The Times They Are a-Changin'

So this leaves us with another goal: Clean up the DB and replace all references to the old files with references to the new files. The question I am actually asking here now is how to do this. I am looking for an effective and generally-applicable solution as I suspect this issue does and will affect a lot of people

My current idea is this:

  1. Import, regenerate or whatever which leaves us with the new files and broken tags.
  2. Create a list A from all resized files in the filesystem or alternatively getting this information from the database
  3. Parse this list and create a second list B with filenames all offset by one pixel as it would look before 4.1
  4. Do a search&replace over the whole database replacing all occurences of B with the relating entry in A

I am just not sure if this is the most smart and efficient way to handle this situation. It also feels a bit too brute-force. So before implementing it I just wanted to check with the infinite wisdom of the WPSE crowd ;)

[edit] Having read ck-macleods answer (thanks!) I think a fix should solve this once and for all so you do not need to constantly keep this issue in the back of your head. [/edit]

[edit2] I just found a related ticket on Trac. Adding for reference. [/edit2]

I am currently in the course of migrating site content from an old pre 4.1 site to a new setup and hitting an issue with the rounding error issue of #18532 and the corresponding fix.

To summarize this fixed a long standing rounding misbehaviour on the side of WordPress:

Imagine we upload an image with 693x173 and scale it to a width of 300:

  • pre 4.1: 300x74
  • post 4.1: 300x75

##The issue

Generally this doesn't cause any issues because existing files and <img> aren't touched.

But when you regenerating thumbs or importing attachments from a WXR file they get generated differently in the filesystem leaving all <img> in post_content dead.

##Looking for a solution

I have been thinking of various solutions:

###Going back to the bad old times

Changeset 30660 introduced a new filter wp_constrain_dimensions which can be used to just plug the old behaviour from before 4.1 back in. This does fix the issue. But I am wondering if this might cause issues later on and generally I'd like to have the fix so although this works I'd deem it non-ideal.

###The Times They Are a-Changin'

So this leaves us with another goal: Clean up the DB and replace all references to the old files with references to the new files. The question I am actually asking here now is how to do this. I am looking for an effective and generally-applicable solution as I suspect this issue does and will affect a lot of people

My current idea is this:

  1. Import, regenerate or whatever which leaves us with the new files and broken tags.
  2. Create a list A from all resized files in the filesystem or alternatively getting this information from the database
  3. Parse this list and create a second list B with filenames all offset by one pixel as it would look before 4.1
  4. Do a search&replace over the whole database replacing all occurences of B with the relating entry in A

I am just not sure if this is the most smart and efficient way to handle this situation. It also feels a bit too brute-force. So before implementing it I just wanted to check with the infinite wisdom of the WPSE crowd ;)

[edit] Having read ck-macleods answer (thanks!) I think a fix should solve this once and for all so you do not need to constantly keep this issue in the back of your head. [/edit]

I am currently in the course of migrating site content from an old pre 4.1 site to a new setup and hitting an issue with the rounding error issue of #18532 and the corresponding fix.

To summarize this fixed a long standing rounding misbehaviour on the side of WordPress:

Imagine we upload an image with 693x173 and scale it to a width of 300:

  • pre 4.1: 300x74
  • post 4.1: 300x75

##The issue

Generally this doesn't cause any issues because existing files and <img> aren't touched.

But when you regenerating thumbs or importing attachments from a WXR file they get generated differently in the filesystem leaving all <img> in post_content dead.

##Looking for a solution

I have been thinking of various solutions:

###Going back to the bad old times

Changeset 30660 introduced a new filter wp_constrain_dimensions which can be used to just plug the old behaviour from before 4.1 back in. This does fix the issue. But I am wondering if this might cause issues later on and generally I'd like to have the fix so although this works I'd deem it non-ideal.

###The Times They Are a-Changin'

So this leaves us with another goal: Clean up the DB and replace all references to the old files with references to the new files. The question I am actually asking here now is how to do this. I am looking for an effective and generally-applicable solution as I suspect this issue does and will affect a lot of people

My current idea is this:

  1. Import, regenerate or whatever which leaves us with the new files and broken tags.
  2. Create a list A from all resized files in the filesystem or alternatively getting this information from the database
  3. Parse this list and create a second list B with filenames all offset by one pixel as it would look before 4.1
  4. Do a search&replace over the whole database replacing all occurences of B with the relating entry in A

I am just not sure if this is the most smart and efficient way to handle this situation. It also feels a bit too brute-force. So before implementing it I just wanted to check with the infinite wisdom of the WPSE crowd ;)

[edit] Having read ck-macleods answer (thanks!) I think a fix should solve this once and for all so you do not need to constantly keep this issue in the back of your head. [/edit]

[edit2] I just found a related ticket on Trac. Adding for reference. [/edit2]

explain why I think an on-render approach isn't a good idea
Source Link
kraftner
  • 5.6k
  • 1
  • 29
  • 46
Loading
Notice added Draw attention by kraftner
Bounty Started worth 50 reputation by kraftner
Tweeted twitter.com/#!/StackWordPress/status/643396628645310464
edited body
Source Link
kraftner
  • 5.6k
  • 1
  • 29
  • 46
Loading
Source Link
kraftner
  • 5.6k
  • 1
  • 29
  • 46
Loading