Make WordPress Core

Opened 12 years ago

Closed 12 years ago

Last modified 11 years ago

#22841 closed defect (bug) (fixed)

Media uploader has issues with defaults for align/link/size

Reported by: ipstenu's profile Ipstenu Owned by: nacin's profile nacin
Milestone: 3.5.1 Priority: normal
Severity: major Version: 3.5
Component: Media Keywords: has-patch commit fixed-major
Focuses: Cc:

Description

Source: http://wordpress.org/support/topic/image_default_link_type?replies=6#post-3533649

Action: Set the following in functions/plugin

update_option('image_default_link_type','file');

Expected Outcome: When uploading a file, it should link to 'file'

Actual Outcome: On existing media uploads, everything's fine. On new uploader, it's ignored.

The option is getting set in the DB, it just appears it's not being read.

Attachments (2)

22841.diff (3.9 KB) - added by nacin 12 years ago.
22841.2.diff (3.9 KB) - added by nacin 12 years ago.

Download all attachments as: .zip

Change History (21)

#1 @nacin
12 years ago

Interesting. It looks like we dropped the UI for these options a long, long time ago, in [10009]. We just left support for them all this time. I don't really mind that we're now ignoring them. It is all user setting-based now, so it involves a combination of usermeta and cookies.

Maybe we could re-introduce support for these in 3.5.1, but this doesn't sound like anything critical.
We ignore the options once a user's setting is set.

#2 @Ipstenu
12 years ago

That strikes me as reasonable. It's not a common thing, but it has a valid use-case on heavily managed sites.

#3 @nacin
12 years ago

  • Milestone changed from Awaiting Review to 3.5.1

#4 @nacin
12 years ago

#23068 was marked as a duplicate.

#5 @nacin
12 years ago

  • Severity changed from normal to major

Looking over image_size_input_fields() again, it seems that the user setting did *not* override the option, and rather the user setting was only consulted if the option was set and empty (which is the default).

That seems to be a bug in [10009] and related changesets, such as [12188]. Unfortunately, it looks like we just misread how 3.4 worked.

@nacin
12 years ago

#6 @nacin
12 years ago

How 3.4 worked:

  • image_default_link_type defaults to 'file' in the database. It seems that the urlbutton user setting then incorrectly defaults to 'post', though that doesn't often come into play because there happens to be a default value in the DB here.
  • image_default_align defaults to '' in the database, which is then converted to 'none', which is the align user setting default.
  • image_default_size defaults to '' in the database, which is then converted to 'medium', which is the imgsize user setting default. Notably, if the size is missing from the database entirely, "medium" is used and then overrides the user setting.

Neither 3.4 nor 3.5 is completely optimal. To make this behavior sane for 3.5.1:

  • Look at image_default_link_type (which would pretty much always be 'file') before looking at the urlbutton user setting, which should default to 'file' rather than 'post', and which would hardly ever be consulted anyway because of the image_default_link_type.
  • Look at image_default_align before looking at the align user setting. In practice, this means the user setting will be obeyed, unless someone puts a non-empty value into the option.
  • Look at image_default_size before looking at the imgsize user setting. If the size is missing from the database entirely, treat it as empty, thus allowing the user setting to hold, and not as 'medium', which does not. This means the user setting will be obeyed, unless someone puts a non-empty value into the option.

All of this behavior needs to be triple-checked in 3.4, in 3.5, and then with this patch.

#7 @nacin
12 years ago

From leedo in #23068:

In 3.4, with a per-user image preference of Medium, if I insert an image with only Full Size available (auto-selected), my user preference remains Medium. However, if I *click* Full Size (even if it is already selected) my user preference is updated to Full Size.

#8 @leedo
12 years ago

  • Cc lee@… added

#9 follow-up: @leedo
12 years ago

It seems to be that a large part of the difference between 3.4 and 3.5 is when the image size preference is saved. 3.5 appears to save it when it is inserted into the post, 3.4 does it on click. The nice part about the 3.4 behavior is that if the selected image size is modified due to dimension constraints, not by clicking, the user preference is not modified.

#10 @azaozz
12 years ago

Yes, I remember some discussions (long time ago) whether the defaults for image_default_link_type, image_default_align and image_default_size should be "user state", i.e. we reuse the last value the user has chosen, or should be shown as options in Settings -> Media.

At one point (around WP 2.5?) these were shown as options, then converted to user states, then changed to use the options when set (it's possible to set these with a plugin in newer versions).

Now that we have new workflow for most media actions, thinking we should choose one method and stick to it, perhaps making it easier for plugins to implement the other.

We can fall back to something similar to the 3.4 behavior but thinking we should empty the DB options for new installs (set all of them to ''). Then if any of the three options is non-empty, we always load the value from there as default. The user would be able to select another value in the UI but it will only be used for the current image (and not saved in "user state"?).

Alternatively the DB options can be deemed "plugin territory". To make it easier to implement we could have a var in JS that will turn off saving of user state for the three options so the defaults will always be used, and plugins can set these defaults in any way they want. This would change the 3.4 behavior a bit but only for the first use.

#11 @nacin
12 years ago

  • Summary changed from New media uploader ignores option image_default_link_type to Media uploader has issues with defaults for align/link/size

@nacin
12 years ago

#12 @koopersmith
12 years ago

Latest patch works wonders for respecting the DB options.

#13 @koopersmith
12 years ago

In 23261:

Media: Do not update attachment display user settings when a single attachment is inserted.

This is consistent with 3.4 behavior.

see #22841.

#14 @nacin
12 years ago

In 23262:

Media: Restore 3.4 behavior by consulting the old-school DB options for default align, size, and link properties.

This restores linking to media files as the default, over attachment pages. This 'default' cannot currently be changed by a user setting (per 3.4 behavior), due to the default database schema.

see #22841, for trunk.

#15 in reply to: ↑ 9 @nacin
12 years ago

Replying to leedo:

It seems to be that a large part of the difference between 3.4 and 3.5 is when the image size preference is saved. 3.5 appears to save it when it is inserted into the post, 3.4 does it on click. The nice part about the 3.4 behavior is that if the selected image size is modified due to dimension constraints, not by clicking, the user preference is not modified.

Fixed by [23261], please test!

#16 @nacin
12 years ago

  • Keywords has-patch commit fixed-major added

#17 @nacin
12 years ago

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

In 23272:

Media: Do not update attachment display user settings when a single attachment is inserted.

This is consistent with 3.4 behavior. (User settings are now only updated when the user makes an explicit change.)

Merges [23261] to the 3.5 branch.

props koopersmith.
fixes #22841.

#18 @nacin
12 years ago

In 23273:

Media: Restore 3.4 behavior by consulting the old-school DB options for default align, size, and link properties.

This restores linking to media files as the default, over attachment pages. This 'default' cannot currently be changed by a user setting (per 3.4 behavior), due to the default database schema.

Merges [23262] to the 3.5 branch.
fixes #22841.

This ticket was mentioned in IRC in #wordpress-dev by SergeyBiryukov_. View the logs.


11 years ago

Note: See TracTickets for help on using tickets.