WordPress.org

Make WordPress Core

Tagged: media Toggle Comment Threads | Keyboard Shortcuts

  • Ella Van Dorpe 1:22 pm on December 24, 2016 Permalink |
    Tags: , media, ,   

    Idea: Uniform Resource Identifiers as an alternative to Shortcodes 

    The idea is that any objects embedded in a post’s content have their own home and should be seen as separate resources. Data would be stored elsewhere.

    Examples

    • https://example.com/resources/contact-forms/email-ella/
    • https://example.com/resources/charts/php-versions-wordpress/
    • https://example.com/author/iseulde/
    • https://example.com/galleries/yummy-chocolates/
    • https://example.com/surveys/wordpress-editor-2016/
    • https://external.com/some-map-or-form/

    Object Types

    This approach could be good for:

    • Forms such as contact forms, surveys and polls.
    • Visualised data such as diagrams, charts, graphs and tables.
    • Lists of items such as a galleries, playlists and lists of posts.
    • Albums or manually composed collections of items where the presentation is uniquely different from a normal list.
    • Any content that needs to be reused or organised separately. Anything that can be re-sourced. 😉
    • Any external resources.

    This is not good for:

    • Layout.
    • Text conversions.

    Inspiration

    • External embeds work similarly in WordPress through oEmbed.
    • Images, audio and video are embedded by their URL in HTML.
    • Media have their own “attachment” post type in WordPress.
    • Many plugins already have a separate post type to store their data.
    • I’ve seen some news media do this already for things for like graphs (post, resource).

    Benefits

    • A URL (or “link”) is a concept that is already familiar to many users.
    • URIs are designed for these sort of things. Think about images — it would follow the same paradigm.
    • The content is treated as a separate resource, and can be reused, just like shortcodes, but it forces separation.
    • WordPress allows you to create “pretty” semantic URIs, so the resource can be described for a better experience.
    • A cool side effect is that others could embed these easily on their site through oEmbed. WordPress already supports this.
    • If there’s a problem, the URL will act as a fallback.

    Implementation

    A quick way to implement this for WordPress 4.4 and higher is registering a new post type. This will handle most things, you just need to provide a custom embed template with the template_include filter. An external resource can be filtered with the Embed API and TinyMCE View API, even if it doesn’t support oEmbed.

    Challenge: Variants and Settings

    Either each variant of an resource needs its own ID, or settings could be passed with a query string. I think the use of settings should be minimised — for example, columns for a gallery object may be better set per ID. Settings can certainly be useful for things like autoplay, for example YouTube allows you to set the start time.

    Challenge: Alignment

    This is great if the URL is added on a separate line, but aligning the object is not evident. This is a challenge for shortcodes too. At the moment the core galery shortcode does not allow you to allign it, and the caption shortcode has an attribute for it. Similarly the URl could have a query parameter for alignment, but that doesn’t sound ideal. Alternatively the paragraph could be floated, or it needs to be wrapped in a `div` element to float mid-text. Another approach is to always wrap the URLs in a (custom) tag that can have display information. Again, think about how images are embedded in HTML.

    Challenge: Namespace

    Shortcodes would have a similar problem, though slug clashes are probably more likely. Ideally plugins should use their own prefix, but this may be seen as ugly. Another way to avoid clashes with other post types is a sub type for “attachments” or “resources”.

    Challenge: Extra Queries

    I don’t see this exactly as a challenge, as it’s the nature of the concept, but it may be used as an argument against it. Many shortcodes already make use of custom post types to store data and embedding media (or anything else) also requires extra queries. If and how this should be cached is another problem.


    I would love to hear your thoughts on this alternative, especially from those who use shortcodes for this type of objects in the post content. If you already use a custom post type, why not take advantage of embedding instead of creating shortcodes? If you want to embed external resources, why wrap it in a shortcode?

    If you have other alternatives, I’d love to hear about those too!

     
    • Celso Bessa 1:37 pm on December 24, 2016 Permalink | Log in to Reply

      At first glance, seems like a great idea. I am kind of exploring a similar concept in a new product project. +1

      As for the extra queries, taking as certain that 1) those objects will be used in several posts and 2) they probably won’t change often; maybe leveraging query and response caching will be requirement for this type of object/post.

    • Martin Sotirov 1:39 pm on December 24, 2016 Permalink | Log in to Reply

      I like this idea but the title is misleading as these are two separate use cases.

      Shortcodes CAN be used to embed things but I think that’s a kind of misuse. I try to use them only to enable the user to change the layout without knowing anything about HTML.

      • Ella van Dorpe 2:09 pm on December 24, 2016 Permalink | Log in to Reply

        Sure, and then lots of plugins are kind of misusing them, even core. 🙂

      • Jon Brown 3:55 pm on December 24, 2016 Permalink | Log in to Reply

        Some (me at least) would argue using shortcodes for things easily done with HTML is a misuse of shortcodes… that they were intended for when code needed to run, for example galleries, forms, etc,

        This proposal would do away with shortcodes primary purpose for existing. I like the proposal, just not sure feel it’s a shortcodes replacement proposal where shortcodes could be deprecated.

        • Mike Schinkel 10:13 pm on December 24, 2016 Permalink | Log in to Reply

          I think this proposal implemented and shortcodes could easily co-exist.

          However if after numerous versions of WordPress it becomes clear that shortcodes are now redundant and a less ideal solution then they could be deprecated then. But I personally doubt finding them redundant would ever be the case.

    • lkraav 2:34 pm on December 24, 2016 Permalink | Log in to Reply

      I’m using https://wp-types.com/home/views-create-elegant-displays-for-your-content/ to achieve this (or at least similar) embedding concept today. It does require building up templates for how you want the thing to display so really requires above-average user understanding. The process could certainly be simplified towards the concepts presented in this article.

    • PeterRKnight 3:47 pm on December 24, 2016 Permalink | Log in to Reply

      This idea overlaps a lot with developments around widgets (see for example https://core.trac.wordpress.org/ticket/35669)

    • Wayne Allen 4:29 pm on December 24, 2016 Permalink | Log in to Reply

      I can kind of see the point for things that are like external resources, but otherwise the usability seems low (lots more characters). Also I’m not sure what problem this is trying to solve.

    • Weston Ruter 4:40 pm on December 24, 2016 Permalink | Log in to Reply

      Yes, I like this. I’m hoping that a new iteration on widgets (e.g. #35669) can serve as the long-desired content blocks, and embedding an existing widget into a post would require a reference to that widget. It could be done with a new core `[widget]`shortcodes with an `id` attribute, which may work equally well here, but it could also be a URL. It’s just for a widget I’m not sure there would/should be a permalink to that individual widget (there should certainly be a REST API endpoint nonetheless).

      Note that oEmbeds get cached in postmeta so these “shortcode URLs” could also be cached similarly. Nevermind when to invalidate 🙂

      A lot of shortcodes can’t be standalone and thus shouldn’t have a discrete URL. But I suppose this is not what the proposal is trying to address and it wouldn’t replace shortcodes altogether but rather provide an alternative syntax.

      • Ella Van Dorpe 11:33 am on December 25, 2016 Permalink | Log in to Reply

        Yes, this is not a complete replacement for shortcodes, but only an alternative for some types. Do you have any shortcodes in mind that can’t stand alone and are not layout or text conversions?

        • Weston Ruter 7:15 am on December 26, 2016 Permalink | Log in to Reply

          @iseulde I suppose a widget would be an example of something that couldn’t stand alone. Then again, pretty much anything could be served standalone if there was a wrapper page around it. Attachments are envelopes for media and the permalink for an attachment wraps the media in a template. Something similar could be done for other such internal post type oEmbeds.

          • Ella Van Dorpe 9:29 am on December 26, 2016 Permalink | Log in to Reply

            What kind of widgets? 🙂 I guess I would see widgets more as content in content areas where each “block” is something more specific.

            • Weston Ruter 8:05 pm on January 3, 2017 Permalink

              @iseulde All widgets I guess. I mean, would it make sense for there to be a standalone page that just displayed a single Meta widget, for example?

    • J.D. Grimes 4:43 pm on December 24, 2016 Permalink | Log in to Reply

      I think this is a great idea, but it would be most usable if it was accompanied by a “resource picker” UI on the edit post screen. And also the ability to create a new resource of a particular type right there. I say this because I’m coming from the perspective of using shortcodes to display tables of aggregated data, not so much a post type that can already be created on another screen and then the URI grabbed and embedded.

      However, as others have said, I don’t think this is an idea that can completely replace shortcodes, because they are also used for formatting and to display very small bits of data (like one piece of metadata for a user), which isn’t worth the resource fetch, IMO.

      Although perhaps one way to reduce the need for fetching the resources with oEmbed would be to detect when they could be created locally to the current request, by simulating the query for the object.

    • iLen 5:07 pm on December 24, 2016 Permalink | Log in to Reply

      It seems to me a good idea, the external web or internet should send the construction attributes of the html type shortcodes – in turn an embed. This with the embed and embed appendix of wordpress could do. I see a lot of use in this.

    • Ricky Lee Whittemore 5:30 pm on December 24, 2016 Permalink | Log in to Reply

      This seems like a great path forward and a picker UI for Visual mode seems logical. Would love for widgets to be moved to post type as well. I prefer the Component/Content Block nomenclature but I can see an argument to use widget as namespace or naming convention.

    • LewisCowles 5:36 pm on December 24, 2016 Permalink | Log in to Reply

      Oh… seems I mis-read it the first time (when I shared to social media), this isn’t replace shortcodes with oEmbed, it’s add oEmbed along with shortcodes and possibly communicate the difference, the situations etc. It’s a lovely idea!

    • FolioVision 6:07 pm on December 24, 2016 Permalink | Log in to Reply

      John Godly came up with the core of this a decade ago with his Sniplets plugin. Sniplets didn’t categorise the content particularly deeply so there could be more done with a content library. I see Sniplets never took off but there are more recent versions of the Sniplets concept which are quite popular and well thought of (@artstorm). That covers the simple uses for me.

      After that there are also shortcodes for the more complex programmatic enhancements. I have trouble differentiating between what you are suggesting Ella and shortcodes. This seems to me to introduce additional complexity to WordPress with only modest benefits. I’m a great advocate for keeping things simple.

      Maybe I’m missing something. If you have time to post a simpler list of benefits to restructuring WordPress in this way, perhaps it would help.

    • Mike Schinkel 10:15 pm on December 24, 2016 Permalink | Log in to Reply

      LOVE, LOVE, LOVE your idea. What’s so beautiful about it is its elegance and how it reuses existing solutions.

      Some feedback that assumes your proposal is for inclusion in core vs. how to write a plugin to do the same:

      Implementation

      It would seem that post types are a perfect fit for this. So much that adding an `’embeddable` => true` argument when calling `register_post_type()` could be used to specify that a post type is embeddable _(unless we wanted all custom post types to be embeddable by default then `’embeddable` => false`)_

      This could be extended to allow the `embeddable` argument to accept an array containing default settings for all embeds of that post type.

      Further, rather than require use of `’template_include’` why not extend the template hierarchy and look for template with the name format of `embed-{$post_type}.php` but default to `embed.php` when no specific embed template is available?

      Namespaces
      This can be dealt with in one of two way; one simple and the other powerful:

      1. Follow the lead of post types; use the rewrite slugs and ignore namespacing as custom post URLs currently do
      2. Use the rewrite slugs and create an Embeds configuration page in the WP admin where all `embeddable` post types are listed and the admin user can change their namespaces and their default settings. This would in some ways be similar to the Widgets configuration page.

      Come to think of it, allowing admin users to change slugs for post types should probably be associated with URLs in general so admin users can use post types from different plugins that have conflicting slugs?

      Alignment
      This could be handled using default settings, and on a one-off basis with a URL parameter (more on URL parameters below.)

      Variants and Settings

      While I agree that many aspects should be handled per ID — because they are facts about the object being embedded — it is not uncommon to have aspects that are related to how the embed is being placed in the document, such as height, width, alignment, etc.

      So I would really hate to see these embedded URLs be required to be wrapped by `

      ` tags; that would destroy most of the elegance of the solution and revert back to a hacked-up extension. URL parameters are tailor-made for creating variants of a URL.

      Embed URL + Variants Edit Dialog
      But I agree that URLs with parameters can be off-putting for less technical users. To address I think we could embrace the fact that WordPress will be able to recognize these URLs when editing able wrap them with on-hover controls for editing the URL and its URL parameters.

      The `embeddable` argument for `register_post_type()` could easily include a list of available URL parameters and their data type so the variants edit dialog could display field formatting and helpers, as appropriate.

      Having an edit dialog would make it easy for non-technical users and it would also act as a training aid to allow them to learn how the URL parameters worked as they would see the URLs being embedded with the same information they typed.

      Matching URLs that should display as URLs

      I did not see this addressed; I think wrapping in a `` with a class like `wp-no-embed` would handle this nicely.

      Extra Queries

      A reasonable caching strategy could easily address this concern. Caching the embed’s HTML into a post_meta field that can be updated when the post type that it points to is updated.

      And let me say again, LOVE the idea!

    • Samuel Wood (Otto) 3:18 pm on December 25, 2016 Permalink | Log in to Reply

      Not really seeing this as a replacement for shortcodes. It fills some of the same gaps, but not really.

      However, the underlying notion of expanding embeds, and possibly even making internal-only embeds (bypassing the extra http overhead with oEmbed) is a very worthy idea. Especially if you extend it beyond the current iframe level.

      But ditch the idea of shortcode replacement therapy. It doesn’t really fit for most cases where shortcodes properly make sense in the first place. It does fit for cases where shortcodes have been misused, which is indeed legion, but not for “correct” use of shortcodes.

      • Pascal Birchler 12:56 pm on December 29, 2016 Permalink | Log in to Reply

        Internal-only embeds already bypass the HTTP overhead, see `wp_filter_pre_oembed_result()` and `get_oembed_response_data()`.

    • chatmandesign 4:55 pm on December 27, 2016 Permalink | Log in to Reply

      As others have noted, this is not a replacement for shortcodes, but Ella clearly didn’t intend it to be. This is basically a solution for handling content re-use within a WordPress site. There are a number of plugins that provide a similar feature currently (e.g., [Spots](https://wordpress.org/plugins/spots/)), and I’ve implemented some custom solutions on a couple sites myself; it seems to be a common enough need that standardizing a solution within core could be beneficial.

      I would tend to agree with J.D. that there should be a UI for picking a resource for inclusion. Currently there’s an shortcode that turns URLs into oEmbed iframes… Might something like an [import] shortcode be the most consistent way to implement this?

    • FolioVision 5:19 am on December 28, 2016 Permalink | Log in to Reply

      Tim, many people including you suggest using custom post types to store this content. Very often the content is a PHP fragment or something else which does not sit well in a normal post. By storing the snippet content as a custom post one is severely limiting its flexibility. Here’s how the author of Post Snippets describes his plugin:

      snippets of HTML, PHP code or reoccurring text that you often use in your posts and pages. You can use predefined variables to replace parts of the snippet on insert. All snippets are available in the post editor via a button in the Visual and HTML modes. The snippet can be inserted as defined, or as a shortcode to keep flexibility for updating the snippet. PHP code is supported for snippets inserted as shortcodes.

      This is a lot simpler than creating custom post types. Integrating an optional WYSIWYG editor would be a lot simpler than adding all the overhead of full custom posts to each snippet.

      Ladies and gentlemen, let us not over engineer WordPress. Simplicity of structure and ease of use should be our watchwords.

    • cavalierlife 9:40 pm on December 28, 2016 Permalink | Log in to Reply

      I’m with FolioVision. Snippet plugins already exist, and if core wants to integrate such a thing, fine, but let’s keep it simple.

    • Mike Glendinning 10:02 am on December 29, 2016 Permalink | Log in to Reply

      Agree that all embeddable content should be a first-class “object” but disagree strongly that URIs should be used to reference these for editing and content management.

      The URI for an object is a generated and changeable attribute, not a key and we already hard-wire too many such references within managed content, making it difficult to move sites between locations, implement some SSL environments, serve responsive images, make use of CDNs and so on. There are already dozens of tickets highlighting these sorts of issues.

      Better, I think that objects reference each other using their managed identity (e.g. post ID) which is then expanded dynamically to the appropriate URI when a page is rendered. Isn’t this sort of thing what a content management system is for? As well as providing much more flexibility, this also enables better context-sensitive editing (e.g. allowing pick-lists for objects and their allowed attribute values).

      • Ella Van Dorpe 12:37 pm on December 29, 2016 Permalink | Log in to Reply

        Yes, this is a valid concern. Thanks for bringing it up!

      • Ken Newman 4:35 pm on January 16, 2017 Permalink | Log in to Reply

        Alternatively, what if the embed link was a REST URI? Those urls would be less likely to change.

        The advantage is that the core templating system wouldn’t have to handle these embed requests, but instead the REST API endpoint would be created to handle an HTML response format (as opposed to a JSON or XLM request). Additionally, content that doesn’t need a public post type would be easier to handle this way (and use a pre-existing system).

        I haven’t dug into it, but much of this architecture should already be there for this. 🙂

        I do think it’s fine to resolve a pretty-permalink down to it’s object, using the normal handling of such, with all it’s failure points (i.e. changing slug), and if the object has configuration for HTML response via REST, return that, else the plaintext URI.

    • Mark Root-Wiley 3:45 pm on January 5, 2017 Permalink | Log in to Reply

      My first reaction is that I like this a lot. I also think most comments that raise specific concerns are quite valid.

      Rather than repeating anything that’s already said, I’ll just share one broad thought: With the new focus on *design*, this especially feels like a technical solution in search of a problem. I like the idea in the abstract, but right now, it’s hard to evaluate without a shared problem it’s attempting to solve.

      Similar to some other discussions I’ve seen lately, starting with data storage doesn’t seem like the best way to approach something that absolutely needs a UI to function well. Developing a UI will almost certainly make clear what problems need solving. As the OP mentions, if a proposed UI frequently requires settings/customizations, then URIs aren’t an appropriate solution.

  • Joe McGill 9:20 pm on November 22, 2016 Permalink |
    Tags: , , media   

    Media Changes in 4.7 

    This post provides an overview of the changes to the Media component in WordPress 4.7. See a list of all the 4.7 media tickets.

    Two notable changes, enhanced PDF support in the media library and changes to the default fallbacks for alt attributes, are explained in separate posts.

    Enhanced PDF Support in WordPress 4.7

    Improving accessibility of image alternative text in 4.7

    Make media library searchable by file name (#22744)

    Before 4.7, if you uploaded a file to the media library and changed the title, it wasn’t possible to find that file again by searching for the file name. Now, attachment search queries will also include matches to the _wp_attached_file post meta value.

    Other enhancements and bug fixes

    • Added a $wp_error parameter to wp_insert_attachment() (#37813)
    • Fix Drag/Drop Ordering of Media in Chrome on touch enabled devices (#31652)
    • Avoid undefined offset notice in wp_prepare_attachment_for_js() when image_downsize filter in used in (#34437).
    • Improve docs for image_send_to_editor filter (#34823).
    • Use wp_get_attachment_metadata() instead of get_post_meta() where appropriate (#36246).
    • Ensure wp_get_attachment_link() output text for non-images (#37343).
    • Avoid undefined index notices when pathinfo() is used (#37608).
    • Improve alignment of inputs and button heights in media edit screens (#37806).
    • Set focus when closing the media modal (#38142).
     
  • Mike Schroder 6:12 pm on November 15, 2016 Permalink |
    Tags: , , media   

    Enhanced PDF Support in WordPress 4.7 

    WordPress 4.7 makes it easier to preview PDFs in the media library by generating image representations of the first page, which are now used throughout the media library and media attachment screens.

    If a WP_Image_Editor is available that supports PDF, the following sizes are generated:

    • Full size representation, rendered at 128dpi.
    • Thumbnail (without cropping)
    • Medium
    • Large

    The sizes generated can be modified, or the feature disabled entirely via the new fallback_intermediate_image_sizes filter, and are all stored in the sizes array in attachment meta.

    The preview images generated are used within the Media screen, Gallery, Attachment Details, and on the Attachment page for PDFs.

    Core support is provided through WP_Image_Editor_Imagick and requires Imagick, ImageMagick, and Ghostscript support. When not supported, or if the generation fails, WordPress falls back to previous behavior and saves the attachment without adding image previews to meta.

    For more context, see #31050 for the primary ticket and #38594 for the filter.

    Updated:

    Since this change requires having Imagick load only the first page of a PDF for performance reasons, this means that if you rely on core loading the entire PDF for your extension of WP_Image_Editor_Imagick, this will no longer function as expected (See: #38832).

    As a result, in [39303], the PDF setup code was moved to WP_Image_Editor_Imagick->pdf_setup(), which can be overridden to restore the previous behavior if needed.

     
  • Joe McGill 5:40 pm on November 11, 2016 Permalink |
    Tags: , , , media   

    Improving accessibility of image alternative text in 4.7 

    WordPress 4.7 includes a change to the way image alt attribute values are generated. Formerly, any time WordPress created the markup for an image with an empty alt value, it would attempt to use either the caption text or the image title—in that order—as a fallback value.

    In 4.7, we have removed this fallback behavior.

    To ensure your images having meaningful alternative text, you should make sure to set a value for alt text in your media library.

    How removing fallbacks improves accessibility

    The intent of the fallbacks were to ensure each image included alternative text. In practice however, this fallback behavior often resulted in poor user experiences for people using screen readers. As counterintuitive as that may seem, let’s take a look at some common examples.

    Consider a situation where we’ve uploaded an image named “edbc4ef7.jpg” without changing any additional information. WordPress will generate the image title from the file name as shown in the following screenshot of the insert media modal.

    Attachment details for an image shown in the insert media modal.

    Formerly, inserting this image in a post would result in HTML similar to this (simplified slightly for clarity):

    <img src="https://example.wordpress.org/wp-content/uploads/2016/11/edbc4ef7-1024x683.jpg" alt="edbc4ef7" width="700" height="467" />
    

    A person using a screenreader on this page would end up hearing the file name read to them, which is not the most helpful experience, and can be quite frustrating when the file name is lengthy.

    For another example, setting a caption value but no alternative text would result in markup that looks something like this:

    <figure id="attachment_1741" style="width: 660px" class="wp-caption alignright">
        <img src="https://example.wordpress.org/wp-content/uploads/2016/11/edbc4ef7-1024x683.jpeg" alt="This is a caption." width="660" height="440">
        <figcaption class="wp-caption-text">This is a caption.</figcaption>
    </figure>
    

    Notice that the alt value and the figcaption text are redundant? WebAIM describes two ways of presenting alternative text:

    • Within the alt attribute of the img element.
    • Within the context or surroundings of the image itself.

    The same article goes on to explain that an alt attribute value may be omitted when an identical figcaption is present, to avoid redundancy; but best practice when using a figcaption is to provide a separate and different alt attribute to describe that image to users of screen readers.

    In each case, omitting the alt attribute entirely may result in screen readers reading the file name from the src attribute, so WordPress includes an alt attribute with an empty value, i.e. alt="", whenever the alternative text hasn’t been explicitly set—a technique that is common when an image is decorative.

    This change will not affect content already published, but will be the expected behavior for any new content published after upgrading to 4.7. For more background on this issue, see ticket #34635.

     
    • Carrie Dils 9:52 pm on November 11, 2016 Permalink | Log in to Reply

      +1

    • bahia0019 7:48 am on November 12, 2016 Permalink | Log in to Reply

      One thing to bear in mind is that while WebAIM will take either figcaption or alt, search engines haven’t declared the figcaption as a identifier in image search, whereas the alt tag is still in play with Google, et al.

      So, the alt should definitely not be pulled from image file name, but if a caption is filled out, it may be redundant for WebAIM, but it’s not redundant everywhere.

      • Joe McGill 2:51 am on November 13, 2016 Permalink | Log in to Reply

        Thanks for bringing that up @bahia0019. According to Google’s image publishing guidelines, they take several factors into account, including the file name and context around the image, including captions and titles. So it would appear that captions are indeed read by Google.

        Also, to be clear, if you define an alt attribute along with a caption for your images, WordPress will still display both. What has changed is that formerly, including a caption and omitting an alt value would result in the alt attribute duplicating the text that was in your caption.

    • FolioVision 7:21 pm on November 15, 2016 Permalink | Log in to Reply

      Hi Joe,

      Bahia’s quite right in making a difference between what Google says and what Google does.

      One shouldn’t take Google’s guidelines to heart. We coded lots of schema.org into a recipe plugin following Google’s guidelines, passing Google’s structured data tests. That markup was ignored for years, while an older form of microdata actually worked.

      For SEO, we should still be duplicating caption data to alt. It would be even more helpful to include an option to include file names at alt (for those who do use explicit file names), with the option turned off by default as most publishers these days are too lazy and amateur to name their media accurately.

      • Joe McGill 11:07 pm on November 15, 2016 Permalink | Log in to Reply

        Hi @FolioVision,

        Thanks for sharing your experience. I agree that anticipating how Google will actually parse markup in their algorithms is fairly opaque.

        In this case, the changes we have made do nothing to inhibit people from crafting `alt` attributes in ways that optimize how Google ranks their content, if they so choose. At the same time, we are making the experience better for actual users in the process.

        I think the benefits outweigh the downsides for publishers who aren’t taking the time to include good `alt` values with their images.

    • Aaron Jorbin 10:06 pm on November 15, 2016 Permalink | Log in to Reply

      WordPress should always choose the experience that humans have when interacting with a site over an attempt at better search rankings.

      This is a great change. Thanks to all the people who helped make it happen.

    • Chuck Reynolds 9:23 pm on November 16, 2016 Permalink | Log in to Reply

      👍

    • blepharisma 8:55 pm on November 21, 2016 Permalink | Log in to Reply

      I think this is just Step #1 — Step #2 would be to prompt the user to enter ALT text when the field is left blank.

      I know that the regulations differ in different countries, but in many is is becoming law that public and private business meet certain accessibility standards. Having the ALT text present is in the first level, and a prompt would go a long way to training content creators to automatically include this very important information.

      In similar implementations, a check box is present if the image is decorative.

    • teamduce 7:43 pm on December 6, 2016 Permalink | Log in to Reply

      Happy to see accessibility continuing to be improved in each release. Keep it up!

    • folletti 1:35 am on December 10, 2016 Permalink | Log in to Reply

      Excuse me!
      But a simple solution when I have used the Title and not Alternative text?

    • Dan 2:18 am on December 28, 2016 Permalink | Log in to Reply

      I always have good alt text, because I always have good titles. But now, I have blank alt text everywhere. This might be helping screenreader users to use sites that are poorly managed, but good sites now have blank images and good authors need to do twice the work (writing a title then copying it into the alt). Thanks!

      Does anyone have a function for restoring the automatic alt?

    • Li-An 11:55 am on December 29, 2016 Permalink | Log in to Reply

  • Joe McGill 9:36 pm on October 19, 2016 Permalink |
    Tags: , media   

    Media Weekly Update (Oct 14) 

    This post serves to jump-start discussion before the weekly check in, which takes place in #core-media on Slack. The next meeting is Friday, October 21 at 17:00 UTC and agenda for these meetings includes moving priority tasks forward, providing feedback on issues of interest, and reviewing media focused tickets on Trac.

    Summary from last week

    The last meeting was Friday, October 14 at 17:00 UTC. You can read the entire chat log in the #core-media channel on Slack.

    Attendees: @mikeschroder, @karmatosed, @adamsilverstein, @paaljoachim, @mapk, @flixos90, and @azaozz.

    • Media organization improvements:
      • Last week, we chatted about starting up design for Media organization improvements. @paaljoachim and @flixos90 started sketching flows in GitHub.
      • @karmatosed mentioned focussing on documenting the current flows this week.
    • Add new core media widget (#32417) – No progress was made this week and it’s now too late for 4.7, but work should continue so it’s ready for a future release.
    • Rotate Full Size Images on Upload (#14459) – @mikeschroder planned to do additional profiling re: complete resize+rotate times for upload vs editing.
    • Better PDF Upload Management (#31050) – @mikeschroder is putting more attention on trying to get this in this release after chatting with @helen.
    • Drag/Drop Ordering of Media Does Not Work in Chrome on touch enabled devices (#31652) – @adamsilverstein noted that the patch to enable sortable on touch devices was ready to commit, which was handled in [38793] this week. Additional discussion about reducing reliance on `wp_is_mobile()` is happening on #33704.
    • Accents in attachment filenames should be sanitized (#22363) – @gitlost has been working on updates for this ticket, which is now closely related to fixing #24661 (`remove_accents()` is not removing combining accents”).
    • Usage of `image_size_names_choose` breaks JS attachment model attributes (#34981) – @azaozz suggests using srcset in the media library to make sure full size images aren’t used if a smaller image is available (as described in the ticket description).
    • Responsive images (srcset) can include images larger than the full size (#36477) – The latest patch, which utilized `Imagick::getImageColors` adds a significant performance concerns. @mikeschroder punted this out of the current milestone for now.

    Agenda for the next meeting

    This week, discussion will continue on priority projects for the 4.7 release. If you have specific tickets that you want to have discussed, feel free to leave a comment on this post or reach out on Slack in the #core-media channel.

     
  • Mike Schroder 6:26 am on October 12, 2016 Permalink |
    Tags: , , media   

    Media Weekly Update (Oct 7) 

    This post serves to jump-start discussion before the weekly check in, which takes place in #core-images on Slack. The next meeting is Friday, October 14 at 17:00 UTC and agenda for these meetings includes moving priority tasks forward, providing feedback on issues of interest, and reviewing media focused tickets on Trac.

    Summary from last week

    The last meeting was Friday, October 7 at 17:00 UTC. You can read the entire chat log in the #core-images channel on Slack.

    Attendees: @karmatosed, @joemcgill, @mikeschroder, @swissspidy, @flixos90, @desrosj, @azaozz, @paaljoachim, @markoheijnen, @adamsilverstein, @jorbin, @designsimply

    • Media organization improvements:
      • @joemcgill opened up conversation about a feature project to start work on this, explaining that we have the chance to take a UI/UX first approach.
      • @karmatosed is going to head up the UI/UX side of things.
      • @joemcgill thinks the likely first step is exploration of base taxonomy support, and a review on how it is currently broken with media.
      • @karmatosed asked all those interested in working on this to create sketches of their ideal media categorization flow for review by next week.
    • Add new core media widget (#32417) – @joemcgill noted that the runway for 4.7 is ending, but work can continue for a future release. @designsimply to refresh the current patch on the ticket by Monday (October 10), and may target images specifically as a first step (this is still missing a refreshed patch).
    • Rotate Full Size Images on Upload (#14459)@mikeschroder profiled this and found that while the clock time for checking and setting orientation is minimal, it took ~230ms for an iPhone 7-sized image to be rotated (total 5.6s resize time) on a shared test server. He thinks total resize time should be reduced before this is added, and that #37140 is a better step for 4.7. After discussion with @markoheijnen and @azaozz, consensus seems to be that benchmarking of upload vs manual rotation should be done to prove the UX case for #37140 over #14459.
    • Accents in attachment filenames should be sanitized (#22363)@joemcgill pointed out the new patch here from @gitlost, which looks promising. @swissspidy to take a look over the weekend (feedback is on ticket now, but could use more eyes).
    • Better PDF Upload Management (#31050) – Everyone likes this, but time running out for 4.6. @markoheijnen to target next patch by Wednesday (Oct 12) (this was moved out of the milestone, as it’s currently missing a refreshed patch).
    • Responsive images (srcset) can include images larger than the full size (#36477) – @mikeschroder didn’t have time to performance test the patch. To do so shortly and post feedback on the ticket (feedback is on ticket now).

    Agenda for the next meeting

    This week, discussion will continue on priority projects for the 4.7 release. If you have specific tickets that you want to have discussed, feel free to leave a comment on this post or reach out on Slack in the #core-images channel.

    Edit: Updated post per status on Wednesday, Oct 12.

     
  • Mike Schroder 10:51 pm on October 3, 2016 Permalink |
    Tags: , , media   

    Media Weekly Update (Sept 30) 

    This post serves to jump-start discussion before the weekly check in, which takes place in #core-images on Slack. The next meeting is Friday, October 7 at 17:00 UTC and agenda for these meetings includes moving priority tasks forward, providing feedback on issues of interest, and reviewing media focused tickets on Trac.

    Summary from last week

    The last meeting was Friday, September 30 at 17:00 UTC. You can read the entire chat log in the #core-images channel on Slack.

    Attendees: @joemcgill, @mikeschroder, @swissspidy, @flixos90, @azaozz

    • Unexpected change to media title behavior in WP 4.6.1 (#37989) – @joemcgill noted that @sergey found a fix for the remaining UTF-8 issues and it has been committed to trunk, but needs to be backported still. @joemcgill working on getting this done. Test please!
    • Downscale to only smaller images with srcset (#36477) – It looks like a true fix is not likely to land in 4.7, since this would have likely been part of changing the way WordPress handles full size images. @mikeschroder and @joemcgill to test the current patch for performance and SSIM.
    • Better PDF thumbnails (#31050) – @markoheijnen was not able to attend, but previously noted that he is continuing work on this for a week or two to try to make 4.7.
    • WordPress image’s title is not alt (#34635)@joemcgill chatted with the Accessibility team about this, and the suggestion is that WordPress should no longer guess at an appropriate alt if the user hasn’t explicitly added one. He notes that this shouldn’t be that difficult to patch, but the change will need to be well communicated.
    • image_send_to_editor filter is not fired when an Image is edited or replaced in TinyMCE (#34823) – Based on @adamsilverstein‘s feedback, it looks like the ticket should be closed, as there’s a different filter intended for this purpose.
    • Usage of image_size_names_choose breaks JS attachment model attributes (#34981) – Chatted about a bit of background. @azaozz took a look and posted a new patch for review.
    • Sanitize accents in attachment filenames (#22363) – From @gitlost’s comments, it looks like there are fixes in remove_accents() necessary that should happen first, and would likely fix the base bug here. His work on it is mostly in #24661. @mikeschroder to dig into the progress of Safari’s support of these filenames. Feedback from those who have strong knowledge in UTF/character encodings would be appreciated.
    • Rotate Full Size Images on Upload (#14459 and #37140) – Would rather not destroy EXIF/IPTC in full size images (with GD), so may be better to fix this in Imagick first. Needs performance testing. Comment left on ticket.
    • Add new core media widget (#32417) – No updates here. May not be 4.7 at this point, but @joemcgill reaching out to @designsimply for status.
    • Media organization improvements:
      • Make media library searchable by filename (#22744) – @joemcgill added a patch to fix a JOIN issue found by @flixos90. Please continue testing this, especially with large media libraries.
      • @flixos90 opened a GitHub repo to work on media taxonomies/UI, and is organizing a feature project around it. @joemcgill suggests an initial meeting with @karmatosed for high level direction, followed by changes in the plugin, or core directly where appropriate.

    Agenda for the next meeting

    This week, discussion will continue on priority projects for the 4.7 release. If you have specific tickets that you want to have discussed, feel free to leave a comment on this post or reach out on Slack in the #core-images channel.

     
    • simonrcodrington 10:44 am on October 4, 2016 Permalink | Log in to Reply

      Hey there Mike. Thanks for the update.

      I usually can’t make it to the slack meetings (they end up being really early where I am), but I’ve been meaning to push forward my ticket for inclusion into core: https://core.trac.wordpress.org/ticket/37535

      Basically, when you register a post type you can include the `description`. That description is never used anywhere by default. My idea was to output it right at the top of the post type listing admin page (where all your posts are displayed). The usefulness would be the description would be displayed in a practical place, with very few changes required.

      I’d be pretty keen to discuss this / put forward a pull request with how it would all work.

      Thanks.

  • Joe McGill 1:40 am on September 23, 2016 Permalink |
    Tags: , media   

    Media Weekly Update (Sept 22) 

    This post serves to jump-start discussion before our weekly check in, which takes place in #core-images on Slack. Our next meeting is Friday, September 23 at 17:00 UTC and the agenda for these meetings include moving priority tasks forward, providing feedback on issues of interest, and reviewing media focused tickets on Trac.

    Summary from last week

    Our last meeting was Friday, September 16 at 19:00 UTC. You can read the entire chat log in the #core-images channel on Slack.

    Attendees: @joemcgill, @paaljoachim, @markoheijnen, @helen, @flixos90, @afercia

    • Unexpected change to media title behavior in WP 4.6.1 (#37989) – This is a regression, which has been partially fixed.
    • Sanitize accents in attachment filenames (#22363) – @mike and @markoheijnen were planning to work on #22363 in person this past week and will decide on next steps.
    • Better PDF thumbnails (#31050) – @markoheijnen tested out plugins that claim to handle this and found that all suffer from the same “corrupted image” issues that have blocked this ticket. The strategy is to see if we can detect which PDFs will fail and fall back to a default PDF icon when that is the case.
    • Media organization improvements:
      • Make media library searchable by filename (#22744) – This was fixed in [38625].
      • We had a lengthy discussion about the potential for adding a default taxonomy to attachments, including identifying some related tickets that would need to be addressed (e.g., #22938)
      • @paaljoachim shared the results of some research into how non-WP image applications handle media organization in the form of this Google doc.

    Agenda for our next meeting

    This week, we will continue discussion on our priority projects for the 4.7 release. If you have specific tickets that you want to have discussed, feel free to leave a comment on this post or reach out on Slack in the #core-images channel.

    Priority Tickets:

    HTTPS Update: @johnbillion recently posted a call for an HTTPS Working Group on the make/core blog. Meetings will be on Fridays (time TBA).

     
    • djsteveb 6:33 am on September 23, 2016 Permalink | Log in to Reply

      Glad to see people improving WP’s image things.

      Hope we can get an easy option to set a default limit of how many media appear on the main /media uploads/ or whatever pages. Hope we can also choose to set a default ‘only user XXXX” at first, and perhaps view by user role in the future.

      Currently the browser window will freeze up with some WP installs I run with buddypress – as the default admin screen loads up with all the user’s images and thumbnails, taking a ton of time and memory.

      I mentioned this here:https://make.wordpress.org/core/2016/09/08/media-weekly-update/#comment-31163 but think I got the comment out there too late for anyone to see it.
      Maybe there is a better place to mention these things for future consideration in improvements with wp images ?

      Steve

      • Joe McGill 2:05 pm on September 23, 2016 Permalink | Log in to Reply

        Hi djsteveb,

        Thanks for the feedback. The best way to bring up enhancement requests or bugs is by filing an ticket on Trac (if one doesn’t already exist addressing the issue you’re experiencing). In this case, it sounds like you may be experiencing the same issue described in ticket #30401. If you could provide feedback on that ticket, that would be helpful.

        Cheers!

  • Mike Schroder 1:53 pm on September 15, 2016 Permalink
    Tags: , media,   

    Media Weekly Update (September 9) 

    This post summarizes the most recent media meeting, which takes places weekly in #core-images on Slack.

    Our next meeting is Friday, September 16 at 19:00 UTC and the agenda for these meetings include moving priority tasks forward, providing feedback on issues of interest, and reviewing media focused tickets on Trac.

    It was brought up that the current meeting time is not great for @swissspidy or @flixos90, and they’d prefer to meet earlier, which we would start next week at Friday, September 23 at 17:00 UTC or alternatively on Thursday, September 22 at 17:00 UTC. Please sound off in the comments as to whether you’d be able to make either of the above to help decide on whether the meeting time will change.

    Agenda for the next meeting

    This week, we will check in on the priority projects for the 4.7 release. If you have specific tickets that you’d like to have discussed, please leave a comment on this post or reach out on Slack in the #core-images channel.

    Recap of the last meeting

    Our last meeting was Friday, September 9. You can read the conversation log in #core-images on Slack.

    Attendees: @mikeschroder, @markoheijnen, @flixos90, @adamsilverstein, @swissspidy, @paaljoachim, and @achbed.

    Media library organization improvements

    • @joemcgill and @swissspidy are working on adding the ability to search the media library by filename (#22744).
    • Following the meeting, @joemcgill posted some great notes on his thoughts regarding process for forming a roadmap for these improvements. You can read them on Slack.
    • Separately, we would like to engage members of the design team in initial conversations about what UI/UX improvements can be made to the media library to make it easier for people to organize and find their media. It’s likely that any UI changes in 4.7 would be relatively light, but we want to begin planning now and focus work during this release on getting as much infrastructure in place as we can.

    Improved full size image optimizations (#37840)

    Good conversation around ways to solve or work around the issue of increased CPU time/HTTP failures for image resizing.

    • Proposed closing #36534, and creating tickets from the issues found. It was great for gathering information, but has become a dropbox for all HTTP Error related tickets.
    • This is related closely to the full size image task because we want to avoid making the timeout issue worse when adding another resize.
    • In addition to running additional profiling to find what’s now taking the most time, one thing @joemcgill and @mikeschroder discussed in particular is a “try again” or “continue” button as a first jump into making it easier to recover when these failures happen. At the moment, this isn’t a thing because WP only saves meta after creating all sizes is completed successfully, and also because the code doesn’t support creating “the sizes that are left” (related: #15311).
    • @mikeschroder would also like to see investigation into making the HTTP Error more specific, but this could be part of the above project or solved without users needing to know the details, when WP can recover by itself.

    Core Media Widget (#32417)

    No Update. Reached out to @designsimply and @fab1en.

    HTTPS fixes

    No Update. Reached out to @johnbillion to see what plans are for 4.7.

    PDF Thumbnails (#31050)

    No time last week due to travel. @markoheijnen to send update this week.

    Accents in attachment filenames should be sanitized (#22363)

    @gitlost provided great feedback on the ticket (thanks!), but it looks like it’s going to need additional work before an initial commit.
    @mikeschroder looking into this with @markoheijnen at WC Tokyo this week.

     
  • Joe McGill 4:11 pm on September 8, 2016 Permalink
    Tags: , media   

    Media Weekly Update 

    This post serves to jump-start discussion before our weekly check in, which takes place weekly in #core-images on Slack. Our next meeting is Friday, September 9 at 19:00 UTC and the agenda for these meetings include moving priority tasks forward, providing feedback on issues of interest and reviewing media focused tickets on Trac.

    Agenda for our next meeting

    This week, we will continue discussion on our priority projects for the 4.7 release. If you have specific tickets that you want to have discussed, feel free to leave a comment on this post or reach out on Slack in the #core-images channel.

    Recap of our last meeting

    Our last meeting was Friday, September 2. You can read the conversation log in #core-images on Slack.

    Attendees: @joemcgill, @mike, @kkoppenhaver, @lukecavanagh,@paaljoachim, @markoheijnen, @swissspidy, and @azaozz.

    Media library organization improvements

    • @joemcgill and @swissspidy are working on adding the ability to search the media library by filename (#22744).
    • @paaljoachim compiled a lists of WordPress plugins that exist to extend/improve media management and a document comparing features of these plugins.
    • Next step will be to compare the list of current plugins and decide on an initial approach for adding a default taxonomy structure for attachments.
    • Separately, we would like to engage members of the design team in initial conversations about what UI/UX improvements can be made to the media library to make it easier for people to organize and find their media. It’s likely that any UI changes in 4.7 would be relatively light, but we want to begin planning now and focus work during this release on getting as much infrastructure in place as we can.

    Improved full size image optimizations (#37840)

    No real update this week, should pick up once filename search is finished.

    Core Media Widget (#32417)

    @designsimply was traveling. We’ll plan on an update at the next meeting.

    HTTPS fixes

    @johnbillion is planning a make/core post outlining the plan for this release. In the mean time, the list of HTTPS related issues can be found in this report.

    PDF Thumbnails (#31050)

    @markoheijnen is reviewing the issue and looking into how plugins have addressed some of the remaining bugs.

    Accents in attachment filenames should be sanitized (#22363)

    @mike is reviewing feedback on this issue, but is planning on committing an initial fix soon.

    Rotate full size images on upload (#14459 and related #33051)

    @markoheijnen is looking at this issue for 4.7.

     
    • djsteveb 10:16 pm on September 14, 2016 Permalink | Log in to Reply

      No idea where best place to post about these issues.. let me know and I’ll add details.

      Attachments / media view crashes a lot for some of my wp sites when there is a lot of media.. think pages of images and video thumbnails loading when click on media -> library or whatever. Wish I could show you how painful it is to do this with a buddypress install, and a few users who upload – especially with rtmedia plugin making it easy to add media. sometimes the page takes forver to load, sometimes it fails.

      We need a way to limit how many media gets displayed by default, how much browser memory gets used when sucking in the thumbnails and such on these views.. and the tabs could be used to choose only to show media by certain users, etc.

      It’s also a major pain point in that in many cases users are able to see other user’s uploads when using buddypress. I used one setting with ‘press permit core’ plugin to fix this – but that’s overkill – and many don’t know about this and freak out when it comes to light.

      PASSWORD work around

      Recently discovered that having a secret image added to a page that is set as not public / passwrod required.. these are easily found when clicking next / next via themes’ image / media view.. certainly something should be done that says “if image is attached to page or post that is not public” – require password or admin account to view or something?

c
compose new post
j
next post/next comment
k
previous post/previous comment
r
reply
e
edit
o
show/hide comments
t
go to top
l
go to login
h
show/hide help
shift + esc
cancel
Skip to toolbar