Make WordPress Core

Opened 3 years ago

Closed 3 years ago

#22123 closed defect (bug) (fixed)

Issue with image turning into spinner graphic

Reported by: raggedrobins Owned by: koopersmith
Milestone: 3.5 Priority: low
Severity: major Version: 3.5
Component: Media Keywords:
Focuses: Cc:


I've picked up an issue with images being replaced when switching between TinyMCE and Text editor. Here are the steps:

  1. Insert html into text editor. e.g.

<img class="alignnone size-full wp-image-21710" src="http://en.support.files.wordpress.com/2009/02/appearance_menu1.png" alt="" width="154" height="231" />

  1. Switch to visual editor. Image isn't displayed - get spinner graphic instead.
  1. switch back to text editor and html src, width and height is replaced with "undefined" e.g.

<img class="alignnone size-full wp-image-21710" src="undefined" width="undefined" height="undefined" alt />

Whenever I remove "wp-image-21710" the image displays properly.

Change History (6)

#1 @markoheijnen
3 years ago

  • Milestone changed from Awaiting Review to 3.5

#2 @lessbloat
3 years ago

By adding in "wp-image-21710" I think you're telling WP that this is an existing media attachment with the ID of 21710. When you switch to the visual editor, it's (unsuccessfully) trying to look up that attachment.

I think the solution, as you mentioned is to simply leave "wp-image-21710" out when the image you're adding isn't actually associated with attachment 21710.

I may be missing something else here...?

Last edited 3 years ago by lessbloat (previous) (diff)

#3 @nacin
3 years ago

  • Priority changed from normal to high
  • Severity changed from normal to major

Some backstory: That content came from en.support.wordpress.com, which was imported into make.wordpress.org/support as starter content.

The attachment 21710 doesn't exist on the new site, but the post does indeed have that class in there. Attachments were not copied over in this case. Even if they were, while we would attempt to rewrite the URLs to make them local, there's no guarantee the ID would match, as it may already be used.

So, this is a pretty big problem. Perhaps we could make the importer map attachment ID classes as a nice enhancement. But the important part is we need to add some sanity checking to ensure this doesn't break. We will probably need to make sure that the URL matches the attachment data found via the ID before considering it an attachment we can turn into a view.

#4 @alexvorn2
3 years ago

I think the problem is when using an image from external location

Last edited 3 years ago by alexvorn2 (previous) (diff)

#5 @nacin
3 years ago

  • Priority changed from high to low

Removing views, see #21813 (comment 30), should resolve this for 3.5.

#6 @koopersmith
3 years ago

  • Owner set to koopersmith
  • Resolution set to fixed
  • Status changed from new to closed

In 22567:

Media: Restore 3.4 editor behavior and remove TinyMCE views.

  • Reactivates the wpgallery and wpeditimage TinyMCE plugins. Deactivates the wpviews TinyMCE plugin.
  • Moves still-relevant logic from mce-views.js to media-upload.js and shortcode.js.
  • No longer include wp-includes/js/mce-views.js. This code will not be used in 3.5, and should be considered unstable.
  • Currently, this is the real 3.4 experience; as such, editing triggers the old modals. Changing this is the next major step.

When reassessing views, we should look over all of these tickets and anticipate these bugs accordingly.

fixes #21813, #22123, #22155, #22161, #22257, #22266, #22318, #22407, see #21390.

Note: See TracTickets for help on using tickets.