Hide "Add Media" for some post formats

[markjaquith]

"Add Media" doesn't make sense for some post formats. Notably: aside, and status.

We should consider hiding it to simplify the UI for these formats.

[saracannon]

+1 for this

I would also say we should consider putting some of the labels inside the text fields (like we do for the title) to simplify there as well

[SergeyBiryukov]

Replying to saracannon:

I would also say we should consider putting some of the labels inside the text fields (like we do for the title) to simplify there as well

Related: #23938, #23980.

[nadeemskv]

I have made the changes by adding some script,but being new to this I have no idea how to submit the patch,Can some one please help me out here.

[nadeemskv]

The files are present in the zip file

[wonderboymusic]

nadeemskv - love the enthusiasm, but you might want to read ​http://codex.wordpress.org/WordPress_Coding_Standards and ​http://codex.wordpress.org/Using_Subversion

[SergeyBiryukov]

See also ​http://make.wordpress.org/core/handbook/working-with-trac/submitting-a-patch/.

[nadeemskv]

I had to make changes in two files,one for the javascript and the other to add the javascript code from js file by enqueing. Is it possible to do this in same file,coz I had to create a new js file not knowing where to add my code(The appropriate place).

[aniketpant]

Patch for hiding "Add Media" button for selected post formats.

[aniketpant]

Added ​24013#1.diff as I feel that it is a much better implementation of the the patch previously provided.

[kovshenin]

24013.diff​ hides the Add Media button for asides and status posts via wp-admin.css.

[aniketpant]

Replying to kovshenin:

24013.diff​ hides the Add Media button for asides and status posts via wp-admin.css.

To make a new addition to the list of elements which don't require "Add Media" buttons, you will need to write CSS. Whereas in a JS implementation, you can just add a new element to the already existing list.

I wouldn't call it a very neat execution.

[markoheijnen]

Solution from kovshenin seems fine to me. New post formats can't be created by a developer and only by core. Also in your solution you maybe don't need to write CSS but you do need to write JS.

[aniketpant]

Replying to markoheijnen:

Solution from kovshenin seems fine to me. New post formats can't be created by a developer and only by core. Also in your solution you maybe don't need to write CSS but you do need to write JS.

I doubt that I can come up with a valid reason for supporting JS in this case but if it were me, I would keep all my default styles as it is. If there is any change which takes place due to a action, I would make it happen via JS and not by making it part of the default styling.

[aniketpant]

Fix for #24013 after revision 24036

[aniketpant]

​24013.2.diff introduces a new array like noUIFormats called noInsertMediaButtonFormats. Currently, noInsertMediaButtonFormats is only used to remove #insert-media-button from the Add New Post page. In the future, if there were the need to make more changes to these no media button formats, it can be easily carried out by making changes to the following code -

if ( -1 < $.inArray( format, noInsertMediaButtonFormats ) )  {
  $('#insert-media-button').hide();
} else {
  $('#insert-media-button').show();
}

[wonderboymusic]

Guys, can you pick another ticket to work on? As a general rule, never use JS for things that can be accomplished with CSS. kovshenin's patch is that one that will be used: 24013.diff​

[markjaquith]

In 24037:

Hide Media button for Status and Aside post types.

props kovshenin. fixes #24013.

[aniketpant]

Replying to wonderboymusic:

Guys, can you pick another ticket to work on? As a general rule, never use JS for things that can be accomplished with CSS. kovshenin's patch is that one that will be used: 24013.diff​

Thanks for clearing that out. Will keep in mind for future patches.

[mrwweb]

Replying to markjaquith:

"Add Media" doesn't make sense for some post formats. Notably: aside, and status.

Just coming across this now. I hate to raise this, but I personally think this is a bit of a rash decision. It feels presumptuous to decide that images/media could play no conceivable role in certain post formats (which I think is what this patch communicates).

There's no given rationale for why something "doesn't make sense" in certain formats, and I can think of perfectly acceptable uses of additional media in formats that currently don't have the "add media" button:

• A photo gallery of behind-the-scenes production shots accompanying a video format post.
• An audio track from the video in a video format post.
• A picture of a band playing their that accompanies an audio format post.
• An image that illustrates an aside format post.
• An attached PDF transcription of a video or audio format post.

I'm really excited about post formats getting bigger billing in the new version of WordPress but this strikes me as unnecessarily constrictive and something that people will chafe at. If someone really wants to make a case that media has no role in certain post formats, I think it needs to be made before launch as I'm sure I won't be the only person asking. I don't think that it's self-evident.

[SergeyBiryukov]

[24037] removed "Add Media" button for Aside and Status formats.

[24098] also added Image, Audio and Video to that list.

Replying to mrwweb:

There's no given rationale for why something "doesn't make sense" in certain formats, and I can think of perfectly acceptable uses of additional media in formats that currently don't have the "add media" button

Those use cases sound valid to me. A featured image could probably be used as a workaround for two of them.

[knutsp]

I think it's a good idea to remove "Add media" from formats that expects media to begin with. If you need all options, use the standard format. If you insist you can always change the post format to standard, add media, and change back to the desired format.

It's important that post formats is not only used to get different styling that the theme may provide, but bears some semantics. Ad the formats should really be different, or else the whole thing is just nothing or, at best, some style.

Ideally, gallery should also not have "Add media" on top of the content editor, but behave like the Image format, going directly to Create Gallery.

[mrwweb]

Replying to SergeyBiryukov:

A featured image could probably be used as a workaround for two of them.

That occurred to me too. However, particularly now that post formats aren't theme dependent, it seems that one can't rely on the theme always having the featured image configured to make up for the lack of the "Add Media" button.

[mrwweb]

Replying to knutsp:

If you insist you can always change the post format to standard, add media, and change back to the desired format.

I'm wary to advocate a workaround for what I really don't think is that fringe of a need. It seems to me that the post format semantically describes the primary piece of content/media in the post, but doesn't exclude auxiliary content/media in the post.

With post formats enabled for ALL users of WordPress, I think it's important that they remain flexible. If there's only one "right way" to use them—in this case, certain types can't have media in them—then many people who could benefit from using them will skip them for this one reason.

[knutsp]

I see your points, mrwweb. But is I see it, the standard format is the default and completely flexible one. It's kind of a point using other formats than standard, to constrain things a bit to the average user, while letting the advanced user have a workaround option.

[mrwweb]

Replying to knutsp:

the standard format is the default and completely flexible one.

If we drop the flexibility point, what about the specific examples raised above? Are those inappropriate uses of post formats? If they are, then that needs to be made clear. If not, then I don't think a workaround is appropriate.

Let's say that a theme beautifully handles the audio post format with a custom player, sweet design, etc. With this patch in place, we're essentially telling them "nope, you should use the standard post." In that case, it doesn't matter that the post is primarily about an audio file or that the theme intends its users to post them as audio format posts.

I stand by my interpretation of post formats as describing the primary content but not all content:

It seems to me that the post format semantically describes the primary piece of content/media in the post, but doesn't exclude auxiliary content/media in the post.

...but if there's a definition out there that supports excluding media, then I can live with that.

I just want to make sure that this restriction is put in place only after considering a full array of use cases.

[jb510]

Simple example... I want to post a gallery. I want to add a little intro paragraph about that gallery. In that paragraph I want to include a logo illustration I previously uploaded to the media library. If you remove add media you take away the only way most users are used to inserting media. Same could obviously be said about ever other post format as well.

As far as I'm concerned that Add Media button is intrinsically tied to the visual editor and ought to apear anywhere and everywhere the visual editor appears. It has nothing to do with whether something is or is not a structured post format.

Similarly users can insert images into the first few lines of a standard post and it gets striped out from excerpts. While I've never liked this behavior, I don't see a probably with media inserted into an aside/status not appearing in anything but the single view. Totally off-topic but I need to now go research how excerpts index views are handled for PFs because I have no idea.

[knutsp]

Replying to jb510:

Simple example... I want to post a gallery. I want to add a little intro paragraph about that gallery. In that paragraph I want to include a logo illustration I previously uploaded to the media library.

Such a post is a hybrid. You should then stick to the standard format, a format that supports any combination of text, an image or many images, galleries, audio, videos and whatever.

As long as the standard format exists, and is the default, any sane restriction to the other post formats is a good thing and reduces possible confusion, as long as the restrictions doesn't inhibit the main use of the said format.

If we remove all restrictions and usage hints to the other post formats then we are back to the current post formats approach, just a style hint to the theme.

The status post format, for example, is not the only format for posting a status, it's the format for posting a status only. Secondly, the gallery post format is not the only format to post a gallery, it should be the format for posting a gallery only. In addition, all formats, besides carrying the main content, let you add supplementary text content. And that should be it.

As of beta2 the gallery format does not remove the "Add media" button. It should. If you bump into restrictions you can always go back to the standard format to lift them, and no entered data is lost.

A typical car allows you to transport yourself, up to four passengers and five suitcases. You can tweak it to carry just one passenger and a refrigerator or the like. This is the "standard" vehicle on the road. If you want others types of vehicles, you buy a van, a pickup, a bus or a motorcycle. Don't expect them to be as versatile as the car.

[mrwweb]

Replying to knutsp:

It seems that we're talking past each other here. I see three main arguments, two in favor of leaving it in for all post formats, one against. They are:

Point 1. mrwweb:

[T]he post format semantically describes the primary piece of content/media in the post, but doesn't exclude auxiliary content/media in the post. [emphasis added]

Point 2. jb510:

[The] Add Media button is intrinsically tied to the visual editor and ought to apear [sic] anywhere and everywhere the visual editor appears.

Point 3. knutsp
Paraphased: Each post format is for posting something only of that format. e.g. A gallery should only be a gallery. A video should only be a video.

Points 1 and 3 are a disagreement about the intention of post formats. Point 2 is about the nature of the "Add Media" button editor. It seems that some people outside the three most-recent commenters (myself included) need to weigh in if this hasn't been decided already.

[jb510]

Replying to mrwweb:

Replying to knutsp:

It seems that we're talking past each other here. I see three main arguments, two in favor of leaving it in for all post formats, one against. They are:

Point 1. mrwweb:

[T]he post format semantically describes the primary piece of content/media in the post, but doesn't exclude auxiliary content/media in the post. [emphasis added]

Point 2. jb510:

[The] Add Media button is intrinsically tied to the visual editor and ought to apear [sic] anywhere and everywhere the visual editor appears.

Point 3. knutsp
Paraphased: Each post format is for posting something only of that format. e.g. A gallery should only be a gallery. A video should only be a video.

Points 1 and 3 are a disagreement about the intention of post formats. Point 2 is about the nature of the "Add Media" button editor. It seems that some people outside the three most-recent commenters (myself included) need to weigh in if this hasn't been decided already.

I think you summarize it well. I recognize this is more a philosophical discussion at this point than UI.

I would argue that in knutsp's interoperation we'd then end up removing the visual editor entirely from structured post formats or at least provide a greatly striped down version of it. For example it wouldn't make sense to allow ul/ol lists to be created in a link, status, image, gallery post format, etc. Further I'd start to question at that point, if the string that comes out of that multi-line field should really even be the_content with all the filters of the_content applied to it.

Regardless, that scenario sounds to me an awful lot like Custom Post Types and not what I think of as post formats.

I'm not claiming there is a right/wrong way to this, I just think both need to be fully thought through though.

[johnjamesjacoby]

We shouldn't hide the "Add Media" button when switching formats. Example: I went to post a Status update, and couldn't include an image from the media gallery. Considering what Twitter and Facebook have taught us about the ease of including media in status updates/asides, we should probably follow suit here.

WordPress/we should be providing users with ways to easily manage their content, not creating barriers to prevent them from accessing it sometimes but not other-times.

Based on existing user testing from the other ticket, users will experiment with different formats, mostly because there's no direct link to see why they'd pick one over any other (other than post-preview, which could maybe be more prominent too.) If users need to switch to Standard format to include an image, then switch back to Status, we've needlessly complicated the experience by several clicks.

Don't get me wrong... the idea of trying to reduce UI clutter is sound, and one I generally agree with -- but, the current iteration of the collective posting UI doesn't yield a net-gain by hiding/showing the vanilla WordPress UI elements in this regard.

Somewhat tangentially, I'd rather we not ever hide the Title field, and instead disable it and change the "Enter title here" text to say "Not used for this format" -- it will cut down on the jumpiness and unpredictability of hiding core fields that have been around for a decade, and isn't as jarring to existing users that need to learn a new UI at the same time.

(Edit: grammar, words, and added politeness.)

[mrwweb]

Replying to johnjamesjacoby:

Considering what Twitter and Facebook have taught us about the ease of including media in status updates/asides, we should probably follow suit here. WordPress should be providing users with ways to manage their content, not prevent them them from accessing it sometimes but not other times.

Hear hear! I really think sticking with this ticket is sending the wrong message for so many reasons.

Somewhat tangentially, I'd almost rather we not hide the Title field and instead change the "Enter title here" text to say "Not used for this format."

I like this. See: #24011.

[mrwweb]

I feel like I'm screaming at an empty room here. I'm sorry if this is unkosher to keep pushing this...

I have yet to see a compelling reason for why "'Add Media' doesn't make sense for some post formats" if there are multiple plausible reasons to place media in ALL post formats (see #comment:18). I don't think it undermines certain formats and it seems crazy to officially endorse a workaround of using standard and then changing the format later (which surely many will forget to do).

And in addition, I still really think jb510 has a point in #comment:25:

As far as I'm concerned that Add Media button is intrinsically tied to the visual editor and ought to apear anywhere and everywhere the visual editor appears.

What does it take to get this reconsidered? This feels like a big mistake that could rile up casual users and completely distract from the many great reasons to use post formats. I don't see how the small "benefits" of hiding the button outweigh that risk.

[jb510]

Replying to johnjamesjacoby

Don't get me wrong... the idea of trying to reduce UI clutter is sound, and one I generally agree with -- but, the current iteration of the collective posting UI doesn't yield a net-gain by hiding/showing the vanilla WordPress UI elements in this regard.

Somewhat tangentially, I'd rather we not ever hide the Title field, and instead disable it and change the "Enter title here" text to say "Not used for this format" -- it will cut down on the jumpiness and unpredictability of hiding core fields that have been around for a decade, and isn't as jarring to existing users that need to learn a new UI at the same time.

This is my feeling too. Reducing UI clutter is one thing (eg. the PF icons ought to be downsized BEFORE setting the format and rolled up after), but eliminating something fundamental like the Add Media button is just wrong and does not help users.

I feel like this is being done because the structured post format UI is confusing, but removing the Add Media button doesn't fix the confusing Post Formats UI. It's like taking the radio antenna off a Yugo to make it more streamlined.

I hate to say it but the longer I look at this the more of a UI disaster it seems to me. I think the people trying to get the structured post formats need to take a look at how Tumblr does it and really think hard about how this UI could better emulate that. I fully support the idea behind the structured post formats and was in favor of push 3.6 to get them right, but it's increasingly looking like that's the wrong way forward. At this poing I say punt ALL the user facing Post Format stuff to 3.7.

Again, if If a user WANTS to add media to the content they shouldn't be prevented from doing so. There are dozens of valid use cases that don't conflict with the idea of structured post formats.

Finally, if the approach to structured post was to wholly remove the visual editor from certain structured post formats I could get behind that, but a lot of work needs to be done to figure out what happens to that content information when a post format is switched. Why isn't THAT getting discussed.

[knutsp]

A good UI focuses on the task. The task the image post format is there to guide is posting an image, with an optional description or comment, and make the post look like an image post. An extra add image button for the description field is just confusing. The point of post formats in general, other than the standard format, is to reduce freedom, and guide the author in doing so.

Wanting to add an extra image upload button is like going "Yo dawg, I heard you like uploading images so I put an image uploader to your image uploader so you can upload an image while you upload an image".

A possible compromise would be to make the extra media button visible only after the "format image" has been added. This could satisfy both sides.

[jb510]

Replying to knutsp:

A good UI focuses on the task. The task the image post format is there to guide is posting an image, with an optional description or comment, and make the post look like an image post. An extra add image button for the description field is just confusing. The point of post formats in general, other than the standard format, is to reduce freedom, and guide the author in doing so.

It's not an image button. It's an Add Media button and it has MANY uses. What if I want to add a smiley to my status but the way I'm accustomed to inserting it is with the Add Media button to add it from my media library? Users USE the button for ALL sorts of things.

However, you bring up a great point which is how are users supposed to deduce that that big text area is for "an optional description or comment"? This has been my issue elsewhere, as it was entirely NON-obvious what each field does in each case. It's gotten much better, for example "Link" has become "Image click-through link", "Quote souce link", etc, but the_content box is still undefined. If the content SAID it was for a description users would know what to put in there and know that wasn't where the primary image was supposed to go.

Wanting to add an extra image upload button is like going "Yo dawg, I heard you like uploading images so I put an image uploader to your image uploader so you can upload an image while you upload an image".

By that we should then discuss eliminating many of the TinyMCE buttons as well as there is no reason have blockquote in a quote, or a link in a link. Perhaps we should just do away with the visual editor on post formats and make it a standard multi-line text area?

[helen]

Replying to jb510:

By that we should then discuss eliminating many of the TinyMCE buttons as well as there is no reason have blockquote in a quote, or a link in a link. Perhaps we should just do away with the visual editor on post formats and make it a standard multi-line text area?

It was discussed. See ​http://make.wordpress.org/core/2013/03/15/post-formats-ui-update-314/, bullet point 4. I never saw anything come of any experimentation regarding re-initializing TinyMCE or otherwise changing mode/buttons before I went on leave, and as far as I know we can't have two textareas with the same name. Note that my "best case" scenario for the experiment also involved moving the Add Media button to the TinyMCE toolbar for certain formats.

In fact, I would suggest generally reading that Make/Core update again (to everyone, not just you) to remind ourselves of where we were, how much has progressed, and what original intentions were. I cannot currently be around for any useful length of time, but my previous work stands.

[alex-ye]

Replying to jb510:

Again, if If a user WANTS to add media to the content they shouldn't be prevented from doing so. There are dozens of valid use cases that don't conflict with the idea of structured post formats.

+100

[zabatonni]

in my opinion it should be there, maybe more connected to editor. Lets imagine that some client will make image post "campaign" where in description he wants to add for example logo of designer who created campaign for him.

now he needs to create standard posts to add logos and description, then switch format to image and upload the main image for post.

i think that its up to theme designers and users whether they want to allow them upload secondary images in image post format.

same for video post.

[knutsp]

Replying to zabatonni:

now he needs to create standard posts to add logos and description, then switch format to image and upload the main image for post.

A hybrid post should go as a standard format. There you have the featured image and/or the first and top content image as the "main image". There is no restrictions to the standard post format, nothing you can't do there, but can in another format. All the other formats is there only to restrict and create focus.

[zabatonni]

Replying to knutsp:

Replying to zabatonni:

now he needs to create standard posts to add logos and description, then switch format to image and upload the main image for post.

A hybrid post should go as a standard format. There you have the featured image and/or the first and top content image as the "main image". There is no restrictions to the standard post format, nothing you can't do there, but can in another format. All the other formats is there only to restrict and create focus.

well, as a theme designer i see a benefit of using image post format instead of standard where there is only one featured image, so you have to use same in listings and in post. this idea is to use image post format in other way, where you can put bigger and more complex image to background for example, but in listings its not looking good so you will use another featured image.

so standard post is just standard, but image post could look more fancy.

[markjaquith]

Originally I'd just proposed hiding it for Status and Aside. But currently, it is:

noMediaFormats = ['status', 'aside', 'image', 'audio', 'video']

.3.diff makes it noMediaFormats = ['status', 'aside']

Reasonable compromise?

[zabatonni]

Replying to markjaquith:

Originally I'd just proposed hiding it for Status and Aside. But currently, it is:

noMediaFormats = ['status', 'aside', 'image', 'audio', 'video']

.3.diff makes it noMediaFormats = ['status', 'aside']

Reasonable compromise?

i like that idea.
status and aside is about text so no need for rich media there. in other formats its no really good idea to limit them just for one video or one image etc.

[aaroncampbell]

24013.3.diff​ works as expected for me.

[jb510]

I still really dislike the idea of hiding Add Media. However, I haven't seen the question about "other" things that get added to that space be addressed. Should be hiding those as well. Namely plugins like Gravity Forms adds an insert form button there, Soliloquy Slider adds an insert slider button, etc...

I tend to think noMediaFormats should really be noExtrasFormat.

[wonderboymusic]

RIP this .js file

[SergeyBiryukov]

[24388] / #24452