WordPress.org

Make WordPress Core

Tagged: plugins Toggle Comment Threads | Keyboard Shortcuts

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

    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.

  • Gary Pendergast 4:07 am on September 8, 2016 Permalink
    Tags: , , , Hooks, plugins   

    WP_Hook: Next Generation Actions and Filters 

    WordPress 4.7 introduces a significant reworking of action and filter iteration to address bugs that arose from recursive callbacks and from callbacks that changed the hooked callbacks on currently running actions/filters.

    What does this mean for you, the plugin or theme developer? In almost all cases, nothing. Everything should continue to run as expected, and this should fix a number of hard-to-trace bugs when different plugins are stepping on each others callbacks.

    Who is affected?

    If your plugin directly accesses the $wp_filter global rather than using the public hooks API, you might run into compatibility issues.

    Case 1: Directly setting callbacks in the $wp_filter array

    $wp_filter['save_post'][10]['my_special_key'] = array( 'function' => 'my_callback_function', 'accepted_args' => 2 );

    This will no longer work, and will cause a fatal error. $wp_filter['save_post'] is no longer a simple array. Rather, it is an object that implements the ArrayAccess interface.

    You have two options to work around. The first (and preferred) method is to use the add_filter() or add_action() functions.

    add_action( 'save_post', 'my_callback_function', 10, 2 );

    If, for some reason, you absolutely cannot, you can still work around this.

    if ( ! isset( $wp_filter['save_post'] ) ) {
        $wp_filter['save_post'] = new WP_Hook();
    }
    $wp_filter[ 'save_post' ]->callbacks[10]['my_special_key'] = array( 'function' => 'my_callback_function', 'accepted_args' => 2 );

    Case 2: Directly unsetting callbacks in the $wp_filter array

    unset( $wp_filter['save_post'][10][ $my_callback_id ] );

    This will fail for the same reason as case one. To work around, you can use the standard remove_filter() / remove_action() functions.

    remove_action( 'save_post', 'my_callback_function', 10, 2 );

    Or, if you absolutely must access the array directly:

    if ( isset( $wp_filter[ 'save_post' ] ) ) {
        unset( $wp_filter['save_post']->callbacks[10][ $my_callback_id ] );
    }

    Case 3: Checking if a hook is an array

    if ( isset( $wp_filter['save_post'] ) && is_array( $wp_filter['save_post'] ) ) {
        // do something
    }

    This will always return false. $wp_filter['save_post'] is a WP_Hook object. To check if a hook has callbacks, use has_action() or has_filter().

    if ( has_action( 'save_post' ) ) {
        // do something
    }

    Case 4: Moving the $wp_filter array pointer manually

    If you’re calling next() or prev() on the $wp_filter array pointer to manually manage the order that callbacks are called in (or if you’re doing it to work around #17817), you will likely be unsuccessful. Use callback priorities, add_action() / add_filter(), and remove_action() / remove_filter() appropriately and let WordPress manage execution order.

    Other Cases

    Almost all other cases where you might manipulate the $wp_filter global directly should continue to function as expected. The WP_Hook object implements the ArrayAccess and IteratorAggregate interfaces so that, while it’s not recommended, you may continue to iterate over callbacks in $wp_filter or directly retrieve priorities from the callback array.

    Props

    While there were many contributors of the course of this ticket, all of whom are listed in the changeset, I’d like to especially thank @jbrinley, for his work in architecting this solution, researching and testing potential compatibility issues, and for authoring the bulk of this post.

    What’s Next

    We’re confident in how solid the code is for the majority of sites, and for the major edge cases, so now it’s time to add the code to the nightly build, so all y’all can test it against your sites and plugins.

    This is being treated as an early commit of a feature project, so the final decision for whether this code will be kept in WordPress 4.7 will be made no later than beta 1, which gives us a month and a half to see how it effects usage in the wider world.

    The current nightly build contains this update, for your testing enjoyment.

    If you have any feedback on the code, please leave a comment on this post. Please post any bugs you find to Core Trac.

     
    • Aaron Jorbin 4:27 am on September 8, 2016 Permalink | Log in to Reply

      One additional thing to note is that if you were directly accessing the $wp_filter global in your advance-cache.php, this is no longer necessary as of 4.6. In 4.7, `ABSPATH . WPINC . ‘/plugin.php’` is included with `require_once`, so calling it before then such as in an auto-prepend file or an alternative entry path than index.php (such as what wp-cli uses), you can safely initialize the plugin API early.

      • David Anderson 9:21 am on September 8, 2016 Permalink | Log in to Reply

        I use an auto-prepend file on a shared-hosting server, where the users have a variety of WP versions. (I hook a function to muplugins_loaded, and then in there hook all the things I wanted to do – disable unused/problematic XMLRPC functions, add some SEO spammers to robots.txt, make heartbeat less aggressive – that sort of thing).

        The problem is, at the point that an auto-prepend file runs, you don’t know what version of WP is going to load… and in consequence, don’t know what’s right to put into $wp_filter. The old way had the big plus of being safe even if the .php file wasn’t even part of WordPress.

        I was about to suggest a solution… however…. now that I look at class-wp-hook.php, it looks like WP_Hook::build_preinitialized_hooks() is already doing what I was about to suggest, namely, seeing if $wp_filter has already got entries, and converting them when WP_Hook is available. So, am I right in thinking that a case like mine is already covered / should “just work” ?

        • Jonathan Brinley 12:42 pm on September 8, 2016 Permalink | Log in to Reply

          That is correct. If you set up hooks the old way before the WP_Hook class exists, then they will be converted. This was initially done as a workaround when advanced-cache.php (and also automated tests) loaded before `add_action` was available. But it also solves your case.

        • Aaron Jorbin 3:32 pm on September 8, 2016 Permalink | Log in to Reply

          I would encourage you to keep all the sites you host updated to the latest supported version of WordPress. This will prevent you from having any issue requiring plugin.php once 4.7 is released.

    • Thorsten Frommen 6:15 am on September 8, 2016 Permalink | Log in to Reply

      Why again is the class final without implementing a hook-specific interface?

      • Gary Pendergast 6:53 am on September 8, 2016 Permalink | Log in to Reply

        WP_Hook is a fundamental part of how WordPress works, so making it extendable in any way is something that we’d have to consider very seriously, particularly around maintaining backwards compatibility.

        Do you have a particular use case for such an interface? I’m not against either removing the final or adding an interface, but I would like to know what you had in mind.

        • toscho 8:00 am on September 8, 2016 Permalink | Log in to Reply

          Type hinting with the ability to use a mock or spy would be very useful. Just *never* declare something as `final` that doesn’t implement an interface. That’s always a bug in public code.

        • Thorsten Frommen 5:58 am on September 9, 2016 Permalink | Log in to Reply

          TL;DR: What toscho said. 🙂

          I didn’t think of a concrete use case here, but more in a general sense. The first thing that comes to mind, though, is indeed testing (or more specifically: mocking).

          Another thing, which I think might be true for several comments on several tickets/posts: just by making something important accessible doesn’t mean the world will eventually end because of that change. Yes, the concept of actions and filters is a fundamental part of WordPress’s internal behavior. Allowing someone to replace that behavior isn’t a bad thing, though. I mean, currently, any bad plugin can just do unset( $GLOBALS['wp_filter'] );. That has been, still is and always will be the case. If someone has access to some machinery they can do pretty much with that. If you don’t want this to happen, then you might have to prevent people gaining access. Something like $GLOBALS['wpdb']->query( 'DROP DATABASE;' ); isn’t anything you can avoid when someone has both access to the DBAL and authorization to perform such a query.

          Does this make sense?

        • screamingdev 9:43 pm on September 18, 2016 Permalink | Log in to Reply

          If you remove the `final` that would be great.
          I know WP_Post and some others are final too but once Nacin promised that the final statements of those will go away as soon as every post type has his own class.

          I saw a few commits and how they clean things up. Leave that `final` and every developer will thank you for that. In my case it is rather OOP / extending than testing. So, yes, an interface is always great if the class is injected somewhere.

          Hope to see no more final anywhere ^^ Cheers!

        • Martin Sotirov 10:27 pm on December 5, 2016 Permalink | Log in to Reply

          I don’t care much about the class being final but not having a proper interface is a problem for a future time when we might want to replace it with something actually good instead of this pile of procedural spaghetti code masquerading as OOP. Having an interface in place would make it easier to decouple from the rest of WordPress in the future. Otherwise, you’re not making it any easier to improve Core in time.

    • jadpm 7:37 am on September 8, 2016 Permalink | Log in to Reply

      Nice. This is going to help us remove some hacky code, or at least deactivate it from 4.7 on. Thanks a lot.

    • Amir Helzer 8:06 am on September 8, 2016 Permalink | Log in to Reply

      Folks, thanks a lot for announcing this in advance. This helps us (and others) get prepared on time. Highly appreciated!

    • Alex Mills (Viper007Bond) 9:23 am on September 8, 2016 Permalink | Log in to Reply

      I just wanted to compliment everyone who worked on this. What a monumental task this was. Great on you guys for having the perseverance to see it though! I ran into this bug countless times without realizing it and it’ll be very nice to have it resolved.

    • eddr 9:50 am on September 8, 2016 Permalink | Log in to Reply

      Great!
      Would be nice to have a good dociumentation of all the filters and actions, and/or an ordered list

    • Ahmad Awais 11:14 pm on September 8, 2016 Permalink | Log in to Reply

      Noice! Have reported it back to a few plugins.

      • Gary Pendergast 12:11 am on September 9, 2016 Permalink | Log in to Reply

        Have you noticed plugins that are not working correctly after this changeset? Or is a pro-active review of code that touches $wp_filter?

        If there are plugins that are not working, please send a list of them through – I’d like to make sure as many edge cases are fixed in core as possible.

    • Giuseppe Mazzapica 8:19 am on September 9, 2016 Permalink | Log in to Reply

      The only place where I touch the global directly is in some edge cases where I need to add action and filters _before_ WordPress has been loaded. I had no time yet to test against trunk, but looking at class code it seems that any content of $wp_filter is converted to new format when WP is loaded. Is that right? Will any code that fills $wp_filter before bootstrapping WordPress fail after this change?

      • Dion Hulse 5:18 am on September 10, 2016 Permalink | Log in to Reply

        That’s correct; Filters added to the globals BEFORE WordPress is loaded still works, it’s just upgraded on the fly.
        If you have a custom script, as explained in the comments here, you can also include `wp-includes/plugin.php` early to get access to the API properly.

    • Josh Levinson 1:51 am on September 14, 2016 Permalink | Log in to Reply

      To avoid confusion regarding `WP_Hook::build_preinitialized_hooks`, it may be worth better defining the scope in which it’s useful/can provide some degree of backwards compatibility.

      *`build_preinitialized_hooks` only “upgrades” hooks that are added *prior to the plugin API being loaded.*

      If any hooks are added in the style of the example given in Case 1 by OP _after_ the plugin API is loaded, _fatals will occur_. By then, `build_preinitialized_hooks` has already upgraded any filters that came before it.

      See https://github.com/Automattic/batcache/pull/73 for an example of this in the wild.

    • Matt Mullenweg 12:59 pm on November 2, 2016 Permalink | Log in to Reply

      How does it benchmark before and after?

      • Gary Pendergast 11:48 pm on November 2, 2016 Permalink | Log in to Reply

        Memory: The new method uses ~3% more memory than the old method (just loading the relevant code, not all of WordPress), which translates to around 10-20KB.

        For time, the new method is ~10% faster when a hook has 0 callbacks, 5-15% slower with 1-3 callbacks, then gets progressively faster as more callbacks are added – 25% with 100 callbacks, for example.

        This translates to a slight (1-2%, close enough to not really be statistically significant) performance improvement in actual page loads – on the front page of my test WordPress install with Jetpack and Twenty Seventeen activated, there are 3652 calls to do_action() and apply_filters(), 3301 of which have 0 callbacks, 327 have 1-2 callbacks, and 24 have 4+.

    • leemon 3:08 pm on November 25, 2016 Permalink | Log in to Reply

      I have a couple of plugins with calls such as: `add_action( ‘wp_enqueue_scripts’, array( ‘NameOfClass’, ‘my_enqueue_scripts’ ) )`. Since upgrading to 4.7RC I’m getting a “Deprecated: Non-static method NameOfClass::my_enqueue_scripts() should not be called statically” warning. Is there an alternative to using `array($this, ‘my_enqueue_scripts’ )`?
      Thanks

      • Gary Pendergast 4:44 am on November 26, 2016 Permalink | Log in to Reply

        Thank you for the bug report! That deprecation notice is coming from PHP 5.6 – can you confirm that you see the notice running WordPress 4.6 under PHP 5.6? If you don’t see if, please open a ticket on our bug tracker, so we can investigate it in more detail.

        • leemon 5:06 am on November 26, 2016 Permalink | Log in to Reply

          Yes, I’m seeing this running 4.6, too. Sorry. I have no idea why I didn’t catch it earlier.

          • Gary Pendergast 11:32 am on November 26, 2016 Permalink | Log in to Reply

            I’ve just been trying to test this, but I haven’t been able to reproduce it – I get the same notice under WordPress 4.6 as I do under WordPress 4.7.

            Could you please open a ticket on https://core.trac.wordpress.org, and attach a test case to reproduce it?

            • leemon 11:40 pm on November 26, 2016 Permalink

              Yes, that’s what I was trying to say, sorry. I’m seeing the same notice under 4.6 and 4.7, so this is the expected behavior and that means that I must change how I add hooks in my plugins. Thanks!

    • Paul Bearne 1:31 pm on November 28, 2016 Permalink | Log in to Reply

      Just reading the post I think some code that I look after is OK but just wanted to check

      “`
      // Remove all the_content filters so child posts are not filtered
      // removing share, vote and other per-post items from the live update stream.
      // Store the filters first for later restoration so filters still fire outside the update stream
      $stored_wp_filter_the_content = $wp_filter;
      $this->clear_most_the_content_filters();

      do some stuff

      // Restore the_content filters and carry on
      $wp_filter = $stored_wp_filter_the_content;
      “`

      and in the clear_most_the_content_filters();

      “`

      /**
      * Adjust the_content filter removing all but a handful of whitelisted filters,
      * preventing plugins from adding content
      *
      * @since 1.0.9
      */
      private function clear_most_the_content_filters() {
      global $wp_filter;

      // do we have the_content and is not empty
      if ( isset( $wp_filter[‘the_content’] ) && empty( $wp_filter[‘the_content’] ) ) {

      return;
      }

      // is it an WP_Hook class
      if ( ! is_object( $wp_filter[‘the_content’] ) || ‘WP_Hook’ !== get_class( $wp_filter[‘the_content’] ) || ! isset( $wp_filter[‘the_content’]->callbacks ) ) {

      return;
      }

      /**
      * Filter to allow to override the White list of the filters we want to preserve.
      *
      * @since 1.3.5.2
      *
      * @param array $whitelisted_content_filters White list of the filters we want to preserve.
      *
      */
      $whitelisted_content_filters = apply_filters( ‘whitelisted_content_filters’,
      array(
      ‘process_oembeds’,
      ‘run_shortcode’,
      ‘autoembed’,
      ‘wptexturize’,
      ‘convert_smilies’,
      ‘convert_chars’,
      ‘wpautop’,
      ‘shortcode_unautop’,
      ‘capital_P_dangit’,
      ‘do_shortcode’,
      ‘add_children_to_post’,
      )
      );

      // Iterate thru all existing the_content filters
      foreach ( $wp_filter[‘the_content’] as $filter_key => $filter_value ) {
      // Filters are in arrays by priority, so iterate thru each of those
      foreach ( $filter_value as $content_filter_key => $content_filter_value ) {
      $found_in_whitelist = false;
      // Loop thru the whitelisted filters to see if this filter should be unset
      foreach ( $whitelisted_content_filters as $white ) {
      if ( false !== strpos( $content_filter_key, $white ) ) {
      $found_in_whitelist = true;
      break;
      }
      }
      if ( ! $found_in_whitelist ) {
      remove_filter( ‘the_content’, $content_filter_key, $filter_key );
      }
      }
      }

      return;
      }

      “`

      any thoughts

    • moros1138 9:06 am on December 12, 2016 Permalink | Log in to Reply

      I made a quick function that I think does a very nice job of using the array directly, while utilizing the proper mechanisms to remove unwanted actions/filters. Previously, I just removed the unwanted actions/filters by using unset.

      Here it is, in case anybody else may find it useful.

      /**
      * filter_hook($hook_name, $allowed=array(), $output=false)
      *
      * Supply the hook name and an array of
      * actions/filters to keep
      *************************************************************/
      function filter_hook($hook_name, $allowed=array(), $output=false) {

      global $wp_filter;

      if(empty($wp_filter[$hook_name]))
      return;

      foreach($wp_filter[$hook_name] as $index => $callback) {

      // get action/filter names
      $hooks = array_keys($callback);

      foreach($hooks as $hook) {
      if(!in_array($hook, $allowed)) {
      // action/filter not allowed, remove.
      remove_action( $hook_name, $hook, $index );
      }
      }

      }

      }

      • moros1138 10:06 am on December 12, 2016 Permalink | Log in to Reply

        I made a mistake..

        foreach($wp_filter[$hook_name] …. should be foreach($wp_filter[$hook_name]->callbacks

        Here’s complete code for copy/pasters

        /**
        * filter_hook($hook_name, $allowed=array(), $output=false)
        *
        * Supply the hook name and an array of
        * actions/filters to keep
        *************************************************************/
        function filter_hook($hook_name, $allowed=array(), $output=false) {
        //$output = true;
        global $wp_filter;

        if(empty($wp_filter[$hook_name]))
        return;

        foreach($wp_filter[$hook_name]->callbacks as $index => $callback) {

        // get action/filter names
        $hooks = array_keys($callback);

        foreach($hooks as $hook) {
        if(!in_array($hook, $allowed)) {
        // action/filter not allowed, remove.
        remove_action( $hook_name, $hook, $index );
        if($output)
        echo “{$hook_name} – {$hook}\n”;
        }
        }

        }

        }

  • Thorsten Frommen 10:16 am on July 15, 2016 Permalink
    Tags: , , plugins,   

    Introducing admin_print_footer_scripts-$hook_suffix in 4.6 

    The admin_print_footer_scripts action hook is the last chance to localize admin scripts; but it is a generic one. If you ever wanted to do something for specific admin pages only, you would either have to hook into another dynamic action, or hook into admin_print_footer_scripts and check the $hook_suffix (which is not even passed, but that’s not an issue) yourself. The problem with the former is that there might be happening a lot between the chosen action and when your script gets enqueued (admin_print_footer_scripts); and maybe you need to be aware of what has happened. The problem with the latter is that you would have to register possibly a lot of functions, maybe check the current admin page inside several of these, and eventually bail most of the times. That’s why WordPress 4.6 brings the dynamic footer action admin_print_footer_scripts-$hook_suffix. See [37279].

    The following pre-4.6 code

    add_action( 'admin_print_footer_scripts', function() {
        global $hook_suffix;
    
        if ( 'some_admin_page' !== $hook_suffix ) {
            return;
        }
    
        // Whatever it is that you want to do...
    } );
    

    can now be simplified like this:

    add_action( 'admin_print_footer_scripts-some_admin_page', function() {
        // Whatever it is that you want to do...
    } );
    

    This change brings more consistency between wp-admin/admin-footer.php and wp-admin/admin-header.php, which already fires the generic admin_print_scripts and the dynamic admin_print_scripts-$hook_suffix actions.

    For more background on the change, see #34334.

     
  • Robert Chapin 8:05 pm on July 23, 2015 Permalink
    Tags: , 4.2.3, , plugins,   

    Changes to the Shortcode API 

    Earlier today, we released WordPress 4.2.3, which includes a relatively large security fix that affects the Shortcode API. Due to the nature of the fix – as is often the case with security fixes – we were unable to alert plugin authors ahead of time, however we did make efforts to scan the plugin directory for plugins that may have been affected.

    With this change, every effort has been made to preserve all of the core features of the Shortcode API. That said, there are some new limitations that affect some rare uses of shortcodes.

    Reminder: Never, under any circumstances, should you hack core files. This includes downgrading specific files. Doing so could have unintended consequences on your WordPress installation, including major security implications.

    Basic Shortcode Usage

    A brief explanation on the original purpose of shortcodes will help to explain the change. In a basic post, like this example, shortcodes are used to insert dynamic code:

    Here are my images. [gallery]

    Here you can see that the shortcode stands on its own as a dynamic element within the blog post content. This is the central premise of the Shortcode API: make it easy to insert blocks of dynamic code.

    Shortcodes with Filtered Styles

    In today’s release of WordPress 4.2.3, however, we’ve added some new limitations that affect some existing plugins. Take, for example, the following shortcode, which is no longer recognized:

    <div style="background-image: url('[shortcode]');">

    The shortcode in the example above appears in a context that is no longer supported. Further, this use of a shortcode stretches the imagination for how the Shortcode API was intended to be used. Fortunately, there are some workarounds still available, so that site administrators are not overly restricted in their use of HTML.

    Workaround

    The following example still functions as expected and is considered more acceptable:

    <div [shortcode]>

    Going forward, plugins implementing shortcodes for inline styles should output the entire style attribute rather than a bare value. Keep in mind that this workaround – just as the original example above – is only available to administrators and editors (i.e. only roles with unfiltered_html). Less-privileged users are still prevented from using shortcodes to output whole attributes in this manner. If a plugin is intended to work with author and contributor roles, we recommend that the plugin output an entire <div>.

    Shortcodes with Bad Quotes

    The following example is also no longer allowed:

    <a href="/[shortcode query="?ref="]">

    In the above situation, the shortcode is now properly recognized as HTML and it is rejected by the API. Apart from the example being confusing, WordPress cannot parse that shortcode.

    Workaround

    Instead, either of the following examples would be appropriate:

    Example 1: <a href="/[shortcode query='?ref=']">
    Example 2: <a href='/[shortcode query="?ref="]'>

    Administrators as well as lesser-privileged authors can continue to use shortcodes in this way, as long is it conforms to the usual HTML filtering rules. However, as explained in the first example, administrators are now somewhat limited in this situation in one case: if the content in this href attribute is generated by a shortcode that does not conform to the HTML filters, then the shortcode is rejected for all users.

    We do not make this change lightly and understand that it may affect some usecases. The above examples and explanations should help plugin authors make the modifications needed to support the Shortcode API.

     
    • Mickey Kay 9:30 pm on July 23, 2015 Permalink | Log in to Reply

      And. . . half our client sites just broke 🙂

    • Dave Navarro, Jr. 9:55 pm on July 23, 2015 Permalink | Log in to Reply

      may affect “some” usecases…

      LOL! How about, you broke half the internet without so much as a “howdy do”.

      And if it worked before, why exactly can’t it work now? I am still not understanding why it had to change. WordPress itself was not intended for many of its uses today, are you going to start forcing people back into blogging? Designers/developers made better use of it than you intended and you don’t like that?

    • arippberger 9:56 pm on July 23, 2015 Permalink | Log in to Reply

      Can we get a list of the affected plugins?

    • Dave Navarro, Jr. 10:07 pm on July 23, 2015 Permalink | Log in to Reply

      Every single plugin that adds shortcodes that could be used inside of an HTML element. Not because it’s a security issue, but because someone doesn’t like how we play with our toys in their sandbox.

    • kitchin 10:12 pm on July 23, 2015 Permalink | Log in to Reply

      The shortcode API has never been well-defined, as far as I know. What html is allowed in a shortcode, and how shortcodes are allowed in html tags has changed over time. Scanning for the use case above would be difficult since it would involve the help files and sample tags shown to users, which may be formatted with sprintf, etc.

      The API should be defined. The test cases are the de-facto definition, but they are ad-hoc and clearly not complete. It’s very complex, with nesting issues and all the rest.

      I don’t know the security bug, but I wonder if malicious uses could have been filtered out more directly as a short-term fix, until the API was rewritten.

      • kitchin 10:20 pm on July 23, 2015 Permalink | Log in to Reply

        As a further example of complexity, many people are not aware that < and > are legal characters in html attributes, and some authors use them, for instance in sample code in the jQuery plugin Cycle2.

        The shortcode API was never intended to contain a complete html parser, and never claimed to. But it also did not strictly limit html or quoting, as it should have. Really it should have allowed either tags in html or html in tags but not both. Too late now.

    • Braad 10:19 pm on July 23, 2015 Permalink | Log in to Reply

      We’re experiencing some major frustration as a result of this change, and now plugins like Toolset’s Types and Views are basically non-functional. There are a lot of confused and unhappy people filling up their support forum right now: https://wp-types.com/forums/topic/types-shortcode-breaks-after-wordpress-4-2-3-autoupgrade/

      Even if this was a necessary change, it’s one that has far reaching implications, and it would have been nice to get a heads up that this was coming so we could have prepared. A simple “Hey, the next update to WordPress will remove support for this use case for shortcodes, so update your sites and plugins now” would have been enough.

      We’re already seeing people on support forums tell each other to just replace the shortcodes.php file with the version from 4.2.2, which as Mark Jaquith has pointed out is not a good idea, but this will be what many non-developer users try when they find out that 4.2.3 broke their sites and they start googling…

      • chriscct7 10:49 pm on July 23, 2015 Permalink | Log in to Reply

        A simple “Hey, the next update to WordPress will remove support for this use case for shortcodes, so update your sites and plugins now” would have been enough.

        As stated above, this was not possible.

        but this will be what many non-developer users try when they find out that 4.2.3 broke their sites and they start googling…

        The majority of WordPress users who are not developers will not know how to replace a file on a remote web server.

        • Braad 12:31 am on July 24, 2015 Permalink | Log in to Reply

          Saying something like “Here is a use case for Shortcodes that will no longer be supported” is different from saying “Here is a security vulnerability and how you exploit it”. I have a hard time believing that some form of notice couldn’t have been given, even if it was only given a day before the update.

          But that said, the core devs who deal with this stuff are in a tough position and deserve a big thanks for their hard work. Hopefully they can find a way to keep supporting the affected shortcode use cases while still keeping things secure.

    • Angelika Reisiger 10:20 pm on July 23, 2015 Permalink | Log in to Reply

      Sorry, please delete my previous two posts. I could not post the complete code snippet.

      So here again:

      I tried to follow your recommendation in the article. But whatever I try, it does not fix the issue ticket #33097
      Below is the code:

      http://pastebin.com/8xvN2eb1

    • mvandemar 10:41 pm on July 23, 2015 Permalink | Log in to Reply

      This change is listed as “Improve the reliablity of shortcodes inside HTML tags.” It says absolutely nothing about this being a security issue. Do you have a link to the actual security issue this change fixed?

    • James Huff 10:44 pm on July 23, 2015 Permalink | Log in to Reply

      Thanks for doing this, both the security fix and the write-up!

      I appreciate that the concern was on security over functionality. Existing functionality can always be fixed, and sometimes a better way of doing things is found, but recovering from a security vulnerability is a *nightmare*.

      Thanks again for keeping us safe!

      • Dave Navarro, Jr. 10:56 pm on July 23, 2015 Permalink | Log in to Reply

        Nothing in this write-up says that this is a security issue. Nothing in the release notes say this is a security issue. This is about how they don’t like how shortcodes are being used, so they put a stop to it. And I guess if they don’t like it, they can change it. But if it’s not a security issue, why change it in a security release without any notification so that it breaks hundreds of thousands of web sites? Why not announce “in 4.3 your shortcodes aren’t going to work anymore” and release it then? Well, because someone messed up and merged the update into core prematurely. So rather than fix the mistake, just roll with it…

        • James Huff 11:00 pm on July 23, 2015 Permalink | Log in to Reply

          Nothing in this write-up says that this is a security issue.

          It’s in the very first sentence, “Earlier today, we released WordPress 4.2.3, which includes a relatively large security fix that affects the Shortcode API.”

          You’re welcome to form whatever theory you’d like to, I’m just reflecting the published facts.

          As far as I see it, the developers had to make a choice, security or functionality. They chose security over functionality, and I’m thankful they did. It’s the right choice.

        • mvandemar 11:01 pm on July 23, 2015 Permalink | Log in to Reply

          @Dave – the very first sentence in here says that it is a security issue:

          “Earlier today, we released WordPress 4.2.3, which includes a relatively large security fix that affects the Shortcode API.”

          You are correct though that nothing in the release notes, or the bug track that I can see, indicates that this is the case.

    • Curtiss Grymala 11:07 pm on July 23, 2015 Permalink | Log in to Reply

      First of all, I want to say that I do truly appreciate the quick security fix, and I fully appreciate how much work is going into keeping this codebase up-to-date.

      Granted, the original example I originally posted in my trac ticket (<a href="/[shortcode query='?ref=']">) was a bit confusing, but I don’t necessarily agree with the idea that this can’t be fixed just because it’s “invalid inout”. A perfectly reasonable example could have been something more like <img src="[post-thumbnail size="thumbnail" id=55]" alt="I want an alt attribute"/> (maybe an example where you want the user to be able to dynamically reference the featured image of another post) or something like that. I don’t see that example being confusing at all, but the results, for most users, will be terribly confusing.

      As someone else already mentioned, this had a major effect on the functionality of the Toolset (Views) plugin, but it also has major implications on a number of other plugins, and, due to the fact that these changes only occur inside of HTML tags (so things may not be visibly broken), it may be a long time before people fully realize how much of their sites are broken.

      Normal users will not understand why things don’t work; they’ll just know that they don’t work (as we have seen from all of the reports blaming the authors of Types & Views for these new issues).

      As plugin authors, we are now responsible for telling users that, if they want to use double quotes in their HTML tags, they have to wrap their shortcode attributes in single quotes. However, if, for some reason, they want to use single quotes in their HTML tags, then they have to wrap their shortcode attributes in double quotes. As if that’s not confusing enough; if we try to help our users out by building an MCE plugin that auto-inserts our shortcodes, we either have to build it to be smart enough to recognize whether there are single quotes or double quotes around the selection, or we’ll have to tell our users to change the tag because it won’t work this way.

      I, better than most, understand just how difficult fixing this issue can be without rolling back the fixes/changes that were released today, but I am not excited about the prospect of breaking so many existing implementations just because it’s tough to come up with a fix. I hope that some minds greater than mine will continue to look into possible solutions for this issue (not necessarily the background-image example, but at least the quotes-within-quotes issue), rather than just writing it off as a won’t-fix.

      • Ipstenu (Mika Epstein) 11:19 pm on July 23, 2015 Permalink | Log in to Reply

        For those playing at home, the trac ticket is https://core.trac.wordpress.org/ticket/33102

        • Curtiss Grymala 11:44 pm on July 23, 2015 Permalink | Log in to Reply

          Thanks, Mika. I probably should have included that link in my reply.

          Also, again, I want to make it clear that I’m not complaining about the security fix (I hope I’m not coming across that way). I agree 100% with @macmanx above, in that I’d much rather have to go through and fix code issues for clients (even if I have to do so for free) than have to deal with security intrusions.

      • Dave Navarro, Jr. 12:11 am on July 24, 2015 Permalink | Log in to Reply

        Custom Content Shortcode, Advanced Custom Fields, and hundreds of other plugins. This isn’t “just a few plugins” or “just a few sites”.

        And if it’s a legit security issue (I still don’t see it that way), then fine.. but handle it better. “We just couldn’t do it is a BS excuse.” And even if you couldn’t, you still should have posted a HUGE MONSTER post about the issue immediately so that there weren’t lost hours of trying to figure out the problem.

        Again, this was VERY VERY poorly handled and all I’m seeing are excuses.

    • mvandemar 11:19 pm on July 23, 2015 Permalink | Log in to Reply

      Actually, I see it now. The fixer of the XSS vulnerability is the same one who owns the bug ticket, namely miqrogroove. Someone just let me know that was where the actual issue was.

    • Mickey Kay 12:20 am on July 24, 2015 Permalink | Log in to Reply

      Third times a charm. . .

      Just to provide another example, in case it’s helpful, of the issue as experienced when using the Types & Views plugins (which seem to be a pretty huge use case based on feedback re: this issue).

      One example of how we might commonly use shortcodes within a Views template to output custom fields:

      <a href="[wpv-post-url]" title="[wpv-post-titlle]" rel="nofollow">[wpv-post-titlle]</a>

      If I had to guess, I would venture that we have upwards of 100+ sites we’ve built that use some form of the above example – all of which are now in theory broken.

      Just for clarification, can you illuminate how this is any more of a security risk than using PHP to spit out the custom field directly? Is it an issue of validation/sanitization? If that’s the case, then why is the decision being made to force a certain format, when validation and sanitization are the developer’s burden in all other cases (custom fields, theme options, customizer controls, etc)? Am I missing something?

      Thanks, and appreciate the open ears to all the feedback (however rough it might be getting at times 🙂

    • Mickey Kay 12:23 am on July 24, 2015 Permalink | Log in to Reply

      Goodness, this is ridiculous – tried 3 methods to include my code. How the heck do you include code in here? Not normal markdown?

      • Ipstenu (Mika Epstein) 12:49 am on July 24, 2015 Permalink | Log in to Reply

        It’s not markdown at all. Use code tags.

        <code>

      • Curtiss Grymala 12:49 am on July 24, 2015 Permalink | Log in to Reply

        You have to encode the angle brackets yourself (type the ampersand symbol, followed by either “lt;” or “gt;” – so, &lt; gets turned into <)

      • Samuel Wood (Otto) 8:52 pm on July 24, 2015 Permalink | Log in to Reply

        Perhaps unsurprisingly, we use shortcodes for that. The word “code” in square brackets will do the job for you on the make blogs.. Use “/code” to close the block.

        Example of code
        

        You can also use “php” for PHP code and “css” for CSS. Then it will have syntax highlighting as well.

        <div> html works too, it will encode the brackets for you </div>
        

        I fixed your most recent comment to have the correct syntax.

    • Dave Navarro, Jr. 12:23 am on July 24, 2015 Permalink | Log in to Reply

      So Gary Pendergast and others have convinced me that there really was a security issue, so my apologies for claiming it wasn’t. However, it still comes down to someone not taking the time to fix the security issue WITHOUT breaking so many live `web sites`.

      • Ipstenu (Mika Epstein) 12:49 am on July 24, 2015 Permalink | Log in to Reply

        Sadly that’s not always a tenable option.

        Once a security issue is known, it’s a mad race against time to get it patched before news gets out and people get hacked.

        • Dave Navarro, Jr. 12:56 am on July 24, 2015 Permalink | Log in to Reply

          Okay, well, I still think they could have make THIS post at the time the update was released and saved a lot of wasted time trying to figure out why sites didn’t work anymore…

          I’m gonna go see if I can find a snickers and if it will make me less cranky. I’ve bitched about this enough that someone on Facebook challenged me to do a better patch… Sadly regular expressions are a major weakness in my dev skills, but I’m gonna try anyway. There’s got to be a way to fix the security problem AND keep the prior functionality.

        • Timothy Jacobs 8:54 am on July 24, 2015 Permalink | Log in to Reply

          That is true in many cases, but not this one. The bug was disclosed in November of last year. Both were responsibly disclosed. And if you look at the trojan emoji security release, the core team has the ability to work on a patch for a long time. There simply wasn’t enough testing done before releasing this patch.

          • chriscct7 9:03 am on July 24, 2015 Permalink | Log in to Reply

            There was a heck of alot of testing done. However regardless of the amount of testing the way less than 1% of 1% of 1% of people use shortcodes makes it impossible not to break sites. For example: nested shortcodes inside of a single html attribute with mixed quotes.

            • Timothy Jacobs 9:23 am on July 24, 2015 Permalink

              I know not all bugs can be caught, but Views & Types seems to have quite a large user base… It just seems that the amount of testing done for this is much less than the trojan emoji bug.

    • mountainguy2 3:25 am on July 24, 2015 Permalink | Log in to Reply

      Downdate 4.2.3 broke my main site, took me 6 hours this morning to fix as I’m a total amature. These automatic updates are the height of lameness. It needs a one-click revert function, as well as a one-click revert that can be done somehow if admin access is broken, as happened to me.

      What is more, near as I could tell from reading, I was at risk for none of the vulnerabilities, I thus had my site broken for no good reason. Again the height of lame.

      MTN

    • codepage 4:42 am on July 24, 2015 Permalink | Log in to Reply

      this fix has broken easy 2 douzen websites of mine plus more of partners of mine. many plugins are broken. i’m working a lot with shortcodes and attributes in my designs. i have no idea on how to hack stuff where only the path is saved and i have for example an id as attribute. please fix this!

      • codepage 4:45 am on July 24, 2015 Permalink | Log in to Reply

        i use plugin OptionTree to make designs configurable. eg:
        <img src="[getoption">

        broke. how am i supposed to fix this? having the customer fill in the html code in a text field? that sucks.

    • lkraav 5:05 am on July 24, 2015 Permalink | Log in to Reply

      Following

    • Shailesh 5:51 am on July 24, 2015 Permalink | Log in to Reply

      Is this change also affect this case?

      <a href="[homeurl]/contact" rel="nofollow">Contact Us</a>

      In most themes I am using [homeurl] and [themeurl] to make dynamic url in links. So I don’t need to worry when I move site from local to live or sub directory to main.

    • Sam Rohn 6:04 am on July 24, 2015 Permalink | Log in to Reply

      here is an easy fix, this resolved WP 4.2.3 breaking some s2member shortcodes on one of my sites

      use single quotes ' for html attributes surrounding the shortcode, and double quotes " for the shortcode’s own attributes

      like this

      a href='[shortcode value="foo"]'

      NOT like this

      a href="[shortcode value="foo"]"

    • twinsmagic 6:39 am on July 24, 2015 Permalink | Log in to Reply

      I’m trying to get this to work:

      I also tried

      @Sam Rohn, your suggestion didn’t work for me unfortunately.

    • AmirHelzer 9:00 am on July 24, 2015 Permalink | Log in to Reply

      We are updating Views plugin today, so that we resolve all shortcodes before passing to WordPress to process content.

      This is a straight forward change, which takes us one day to complete.

      Would have been great to receive a heads-up about an upcoming change in WordPress, so we could do this change on time.

      We received a huge amount of support requests due to this, but this isn’t the issue. We can deal with a wave a support issues. This time it wasn’t “our fault”, but sometimes it is.

      What worries us, as mentioned above, is seeing our clients (folks who build WordPress sites for a living), losing their faith in the system. They feel like the system sees them as little ants and not as humans. People don’t like seeing their problems being dismissed.

      Many of them run hundreds of sites. They cannot afford to stop everything and fix content on so many sites. Especially not if they are currently away for their family vacation.

      What others have asked here and I would like to ask too, is to setup a mechanism that allows WordPress core developers to privately communicate such upcoming issues with plugins developers.

      We are your partners.

      Without WordPress (secure, stable and reliable), we would not exist.

      Without great themes and plugins, WordPress would not power 24% of the Web.

      WordPress core members already volunteer a lot of their time. I’m not asking for anyone to volunteer more time. Need help? Ask us. There is a huge community of developers who rely on WordPress. We would be happy to get involved and set up whatever is needed.

      Does this make any sense?

      • gfazioli 9:14 am on July 24, 2015 Permalink | Log in to Reply

        I agree!!

      • Mario Peshev 10:46 am on July 24, 2015 Permalink | Log in to Reply

        +1 – it’s not a one-time thing, it’s a process problem. And we had a late night urgent maintenance iteration due to a bunch of broken things for the same reason.

        It’s demoralizing for us and some of our clients don’t trust WordPress to be a stable and reliable platform that will run their business and let them sleep at night, without being afraid that things will break with zero changes on their end.

      • Rasheed Bydousi 2:10 pm on July 24, 2015 Permalink | Log in to Reply

        +1 You’re right. It shouldn’t be conducted in such a way. It is so annoying. Such changes shouldn’t be made arbitrarily. This isn’t a typical behavior pattern when it reaches to WordPress.

      • schutzsmith 2:50 pm on July 24, 2015 Permalink | Log in to Reply

        +1 Absolutely sums up how I’m feeling as well Amir! For instance, our digital agency runs on WordPress, we’ve built over 100 websites for clients on it, but as I tweeted this morning, this was the final nail in the coffin, we have to move away from WP because it’s literally killing our relationships with our own clients.

        I’m truly saddened by it because we’ve loved the community up until the last few months. It’s now at a point where we can no longer keep relying on WordPress to run a smooth and fruitful business.

      • Eliot Akira 3:03 pm on July 24, 2015 Permalink | Log in to Reply

        +1 – Thank you for articulating a sensible and constructive suggestion from the developers’ perspective. As someone who is one of the “folks who build WordPress sites for a living”, this issue has affected me greatly – spent most of the night trying to fix clients’ sites as well as doing the best to help plugin users. But more than the unexpected time and effort for support, as Amir states, the biggest worry for me is the loss of trust and reputation, both for myself as a developer but also for the clients regarding the reliability of the WordPress system.

        Last night, in a desperate attempt to find even a temporary solution, I made a plugin update which provided an option to patch one of the core files so that sites will be functional again. In hindsight, it was a poor judgement and bad mistake – but how the issue was handled was very disappointing. Apparently it was against the rules, and the plugin has been blocked from the official repository – without any warning or message to me. If someone had contacted me, I would have gladly removed the offending code. After all, I was only trying to help the situation. But now, I have no way to provide a reasonable update, and the users cannot access the support forum to get any information about why their sites are broken or what to do about it. Since there doesn’t seem to be any motivation to address the issue from the core side, we are all left hanging.

        “We are updating Views plugin today, so that we resolve all shortcodes before passing to WordPress to process content.”

        This seems to be the direction I need to take as a workaround solution, to resolve/render plugin shortcodes before passing to WP to process content. Just to note, in the original announcement are listed two cases (Shortcodes with Filtered Styles and Shortcodes with Bad Quotes) – but neither apply to the issue that I’m seeing across numerous sites.

        “What others have asked here and I would like to ask too, is to setup a mechanism that allows WordPress core developers to privately communicate such upcoming issues with plugins developers.”

        I agree with this. At the same time, I can also see why the update was rolled out so quickly without prior notice, due to its sensitive nature. Perhaps the reasoning for not informing plugin developers is that some of them might try to exploit it. Another reason could be that there was no clear way to determine which plugins would be affected – and informing thousands of developers about a security vulnerability would have defeated the purpose of the update.

        I’m glad to see someone suggesting a positive way to look at the whole situation – what can we as developers and users learn from this on-going situation, and how can we contribute to improve the reliability and stability of WordPress sites.

        P.S. If someone of authority can contact me regarding the blocked plugin, I would really appreciate knowing how to remedy it. Almost immediately after the problematic update,I have pushed another update which removed the change. Both myself and the plugin users are waiting for any information that could help us.

      • safesoundaudio 4:03 pm on July 24, 2015 Permalink | Log in to Reply

        Well said Amir! You speak for many hundreds of us in this wonderful WordPress community.

      • dmccan 4:32 pm on July 25, 2015 Permalink | Log in to Reply

        I appreciate that the core team addresses these security issues. At this point, the WordPress ecosystem is so large that it is difficult to ascertain the impact of core changes, so I agree with Amir that we need a better process.

    • Herre 9:14 am on July 24, 2015 Permalink | Log in to Reply

      I fully understand this is an issue… but isn’t this a weird way of updating… almost al our clients are calling / e-mailing us at the moment as their sites seem to be broken…

      Normally it would be better to announce such huge impact changed to the plugin and theme developers…

      This means I need to fully reschedule my agenda… which already is full during holiday season…

    • JesseHeap 1:26 pm on July 24, 2015 Permalink | Log in to Reply

      Wondering if someone could provide some advice for us as I’m having a little trouble understanding what needs to change with shortcodes to fix our particular issue.

      The simpliest example I can give is below:

      Use Case: We use a short code to pass the HTTP_REFERER as a hidden value in our form:

      SHORTCODE in PAGE:

      Code in Theme Functions:
      //pcbReferrer
      function pcbReferrer_func() {
      return(getenv('HTTP_REFERER'));
      }
      add_shortcode( 'pcbReferrer', 'pcbReferrer_func' );

      Based on my understanding of the above, I’m not clear what I would change since we aren’t using attributes for this short code. I have other short codes that do use attributes which I’m trying to fix as well, but that’s a different story.

      • JesseHeap 4:09 pm on July 24, 2015 Permalink | Log in to Reply

        Here’s the solve in case this helps anyone:

        –ORIGINAL SHORTCODE THAT WAS NOT WORKING–

        Page Shortcode Reference:

        Themes Function Code:
        //pcbReferrer
        function pcbReferrer_func() {
        return(getenv(‘HTTP_REFERER’));
        }
        add_shortcode( ‘pcbReferrer’, ‘pcbReferrer_func’ );

        –NEW SHORTCODE THAT IS NOW WORKING–

        To solve this I moved the HTML into Themes Function PHP file. So I changed my form page shortcode to just:


        [pcbReferrer]

        And modified the function to include the HTML that was originally in the page:

        //pcbReferrer
        function pcbreferrer_func() {
        $output = '';
        return ($output);
        }

        Less then ideal as it intermingles more of the HTML with the shortcode and I always try to maintain as much separation as possible.

        But I certainly do not understand the security concerns of the prior approach so I’ll just assume this is the new constraint that we’ll need to follow for the sake of security…

        • JesseHeap 5:57 pm on July 24, 2015 Permalink | Log in to Reply

          Sorry I thought the <code> tags would leave the HTML alone but they are still stripping it away… This commenting system is a little frustrating…

    • safesoundaudio 4:02 pm on July 24, 2015 Permalink | Log in to Reply

      The change to allowed shortcode usage has NOT just affected a few RARE cases of shortcode uses. It has affected the functionality of hundreds (maybe even thousands) of websites including my own commercial site. Aside from the disaster it has caused to hundreds of web designers who use the excellent Toolset plugins, it has destroyed the functionality of a large number of other plug-ins. The forum is just full of examples today.

      As far as I can tell there was no advance notice. SOMEONE should have stopped and thought, ‘best we tell the community what we are planning’ The folks at Toolset seem to have been given no notice and they are probably the biggest plugin designers of the now disallowed shortcode usage.

      We can debate for ever what should be allowed and not allowed with shortcodes but that misses the point. Most of us are in the communication industry and this update has been very sadly lacking in foresight and communication.

      PLEASE role back this disaster of an update. I am 100% sure it was well intended but PLEASE look at the reality of what has happened.

    • crazycanuck27 6:00 pm on July 24, 2015 Permalink | Log in to Reply

      So I’m trying to pass a User Shortcode [currentuser_iserid] as a variable in an iframe and what worked for v4.2.2 suddenly broke and working to recover.


      … used to work but now it passes the shortcode as text. The shortcode works on its own. So is this an issue with the iframe and trying to pass a shortcode .. or quotes, or something else?

    • Claudio Esperanca 11:03 pm on July 25, 2015 Permalink | Log in to Reply

      is removed by TinyMCE when switching between HTML and WYSIWYG views as it is considered an invalid attribute for the tag, so it isn’t a perfect workaround.
    • minderdl 8:55 pm on July 26, 2015 Permalink | Log in to Reply

      While I can agree that wrong quotations do not need to work (i.e. one should only use single quotes inside double quotes and vice versa) the change also killed wrapping shortcodes:

      [blockcode]
      <a href="[myurl]">[mytitle]</a>
      [/blockcode]

      The href attribute will be empty, only mytitle will be replaced.

      Is this also considered “wrong” use of shortcodes??? Wrapping shortcodes are used for conditions, loops, etc. by several plugins. And this could not be changed in the same easy way like just changing quotation 🙁

      With version 4.2.3 the part inside a wrapping shortcode is first processed by do_shortcodes_in_html_tags(). There all the replacement of the inner shortcode is done. Only afterwards, the result is passed to the wrapping shortcode callback. This has several problems: For wrapping shortcodes implementing a condition substitions will take place that might be completely unnecessary (ok, only a performance problem). But for wrapping shortcodes implementing a loop, the content will always be the same – i.e. the whole thing is completely broken.

      Did anyone thought about this?

    • FolioVision 9:53 pm on August 1, 2015 Permalink | Log in to Reply

      Surely 95% of the security issues could have been clamped with a minimal fix to be followed in next major version with a comprehensive fix – with proper warnings to all involved in shortcodes to clean up their act. Breaking people’s websites is always a bad idea.

    • Mav3000 7:23 pm on August 4, 2015 Permalink | Log in to Reply

      Hi, I am using a simple shortcode to output the URL of my site for use in URLs in my theme. e.g:

      <img src="[rs-get-site-url]/wp-content/themes/theme_1.0/images/icon_tick_2.png" alt="" />

      This is the shortcode code, in functions.php:


      add_shortcode('rs-get-site-url', 'rs_get_site_url_func');

      function rs_get_site_url_func() {
      return get_site_url();
      }

      Since the WordPress 4.2.3 update this has stopped working, but because I am not using bad quotes or variables, I don’t know why. How can I get this working in WordPress 4.2.3?

    • Mav3000 9:41 pm on August 4, 2015 Permalink | Log in to Reply

      In relation to my above post, I’m trying to use the shortcode in URLs like this:

      href=”[rs-get-site-url]/contact” and href=”[rs-get-site-url]/about” etc – these are critical to my site – how can I work around this problem?

      • Eliot Akira 2:31 am on August 5, 2015 Permalink | Log in to Reply

        @Mav3000,

        I believe the most forward-compatible way to solve it is to make the shortcode generate the whole link. That way you don’t need to use shortcodes in HTML attributes. A quick example based on your code above:

        add_shortcode('rs-link','rs_link_func');
        function rs_link_func( $atts ) {
        
          extract( shortcode_atts( array(
            'label' => '',
            'page' => '',
          ), $atts ) );
        
          $page = get_site_url().'/'.$page;
          return '<a href="'.$page.'">'.$label.'</a>';
        }
        

        Then you can use it like: [rs-link page="contact" label="Contact Page"]

    • syamkg 4:57 am on August 20, 2015 Permalink | Log in to Reply

      I am using a simple shortcode for random string generator function and it seems to be broken after recent WP Update 4.3.x

      function genTicketString() {
          $length = 8;
          $characters = "0123456789ABCDEFGHIJKLMNOPQRSTUVWXYZ";
          $string = '';
          for ($p = 0; $p < $length; $p++) {
              $string .= $characters[mt_rand(0, strlen($characters)-1)];
          }
          return $string;
      }
      
      add_shortcode('quoteticket', 'genTicketString');

      And this is how I was using to generate a reference number in contact form

      [dynamichidden ref_num "quoteticket"]

      It seems to have broken and I am new to WP & website development. Can someone please help me how to fix this,

      Thanks in Advance

      • syamkg 4:30 am on September 3, 2015 Permalink | Log in to Reply

        I figured out the problem, its not related to this issue of ‘Changes to Short Code API’. Problem was with coding issues.

    • slt-admin 10:19 am on August 20, 2015 Permalink | Log in to Reply

      Will there be a fix that website admins who don’t have understanding of html can use, and if so when might this be?

  • Helen Hou-Sandi 6:18 am on October 10, 2014 Permalink
    Tags: , , plugins   

    Scalable Dropdowns update 

    In our initial meeting on Wednesday (IRC log), we outlined some steps and a fairly aggressive timeline to get ourselves in a place where changes to wp_dropdown_users() (#19867) and wp_dropdown_pages() (#9864) are suitable for patch review.

    To that end, we’ve opened a handful of issues on GitHub for work and discussion, so that we can track completion. These tasks include evaluating various accessibility areas (touch, mobile, keyboard, screen reader), creating a JS wrapper, UI skinning, and page hierarchy representation. Please check them out and participate as you are able and willing. Let’s keep those issues task-oriented, however – any other questions or comments can go here.

     
  • Andrew Nacin 7:24 pm on October 8, 2014 Permalink
    Tags: plugins, ,   

    Ideas for plugin/theme install/update UIs 

    In the last few releases, the theme and plugin installers received new UI. But the actual procedure of installing a plugin or theme is still old-school: a JavaScript alert confirms you actually did want to install something, then you get taken an ugly screen that prints out sentences of “Downloading package,” etc. If there is an error, everything stops. If it succeeds, you can activate what you just installed or go back to where you came from.

    To say this is not the best experience is an understatement. We can streamline this entire flow while also adding some new functionality. Here’s the goal: Installing or updating a plugin or theme should not block you from continuing what you were doing. Secondarily: unnecessary and sub-par user interfaces should be eliminated.

    Some ideas:

    • You should be able to install a plugin/theme without leaving the installer screens.
    • You should be able to continue searching and browsing for other plugins (or themes).
    • Multiple plugins/themes should be able to be queued for installation at once.
    • Progress is shown directly inside the installer. Details are only shown if there is an error.

    How are we going to do this?

    • Once an install starts for an item, we can “lock” that item to the top left of the results, even if the user keeps browsing or searching for other things.
    • The plugin installer is not yet dynamic, so we’ll need to add infinite scroll and such to allow for continuous browsing (something we avoided doing in 4.0 due to time constraints).
    • We’ll need to come up with a UI for installing a plugin, such as a card-flip, a subtle progress bar, or button changes (“Install” “Installing…” “Installed!”).
    • Updating plugins, themes, and core (from the Dashboard → Updates, Plugins, and Themes screens) should be seamless and happen inline, which will be a completely different UI from installing.
    • We must make sure a user abort (leaving the page) is prevented and/or doesn’t stop the update. We must probably make sure that updates are queued (only one actually happening at once), as we have to take into account maintenance mode, conflicts, I/O operations, and such.
    • If the user is forced to enter FTP credentials, we can request it once in a modal, then send it with each Ajax request — much nicer experience.

    The tracking ticket is #29820. Thoughts, ideas, challenges, suggestions, questions welcome.

     
    • Rafael Ehlers 7:29 pm on October 8, 2014 Permalink | Log in to Reply

      Can we also please add Drag’n’Drop to the installer (upload case): https://core.trac.wordpress.org/ticket/24579

    • demoman2k10 7:47 pm on October 8, 2014 Permalink | Log in to Reply

      Replacing the Install display with a progress bar, or changes should also include an option to debug the install incase of error’s as well. So one does not end up with a Plugin that hasn’t installed and no details as to what went wrong and where to start working to fix it.

    • Radices 7:57 pm on October 8, 2014 Permalink | Log in to Reply

      I’d like to see the ability to delete plugins without having to deactivate them first (auto deactivate when deleting). I’d also like to be able to delete themes from the main screen without having to go into the details screen first.

    • Rene Hermenau 8:18 pm on October 8, 2014 Permalink | Log in to Reply

      > Multiple plugins/themes should be able to be queued for installation at once.

      Nice feature but could be dangerous for newbies who install all end everything. If only one plugin breaks the site, user do not know which one causes the issue.

    • WPMUDEV 8:43 pm on October 8, 2014 Permalink | Log in to Reply

      At WCEU there was a talk about options, and how each option is a decision that has to be made.

      Apologies if this has been covered before, one feature/update I’d love to see is getting rid of the separate theme and plugin upload area (not where you search for themes or plugins), the number of times I’ve seen end users complain that their theme doesn’t install and they get “The package could not be installed. No valid plugins were found.” or that their plugin doesn’t install and they get “The package could not be installed. The theme is missing the style.css stylesheet.” and that has been down to them using the wrong area.

      Those two upload areas are like options, it’s a decision on where to go and one a user has to make, to a new user they don’t always read the labels or know what theme or plugin is and how they differ. Seasoned users may roll their eyes when they see people make this mistake, and then we happily set them on track but this situation and choice could be avoided by having a single smarter upload that basically says:

      • This is a theme, unpack it in the themes folder.
      • This is a plugin, unpack it in the plugins folder.

      This way it’s one upload area, no confusion.

      Not sure how many times other companies see this, but we get this question in both emails and our own support forums a bunch of times each month.

      Thanks for reading 🙂

      • Timothy Bowers 8:46 pm on October 8, 2014 Permalink | Log in to Reply

        Sorry, I intended to post this under my own account rather than the company one. 🙂

      • Captain Theme 2:19 am on October 9, 2014 Permalink | Log in to Reply

        Strongly agree. In a support position I’ve seen this done countless times and it’s a very unpleasant experience for the user.

        Not sure the best way to approach it but even keeping things the way they are now but doing a check for if it’s a theme/plugin and then moving it to the appropriate location, etc. would be a huge improvement.

        • Timothy Bowers 12:35 pm on October 10, 2014 Permalink | Log in to Reply

          🙂

          You’re right, it is an unpleasant experience for end users, and the warning they get is also so meaningless, all they know is something isn’t working and in most cases I’ve seen them blame the plugin/theme developer.

          The main path to get there is the add button within the theme or plugin admin area, and from the menu. I was thinking it would be a case of changing those links to direct to one upload area that handles this but your idea would work just as well so it detects and passes it off as needed.

    • MRWweb 10:24 pm on October 8, 2014 Permalink | Log in to Reply

      While maybe the user-facing feature doesn’t make it into this work, I would hope that the technical foundation could be laid for the update-by-zip-upload feature as described in #9757. This seems like the right time to consider it again since it was first opened 5 years ago!

    • daveshine (David Decker) 7:43 am on October 9, 2014 Permalink | Log in to Reply

      Just yesterday, I released this plugin: https://wordpress.org/plugins/cleaner-plugin-installer/screenshots/

      I mostly tweaks the start page of the install admin page (?tab=featured) and replaced its content with a large search input field, among other little tweaks.

      Already got lots of feedback, that other developer & users like the approach of starting with a search box.

      • Netzialist 7:59 am on October 14, 2014 Permalink | Log in to Reply

        Thank you for this, David!
        I felt completely lost the first time I saw the new interface. I had a certain plugin in mind, but there was no searchbox. Instead I saw big bold icons cluttering my browser window. Stuff I didn’t need and I didn’t look for.
        From a usabilty point of view I consider the new interface as a big step back. WordPress desparately needs to become simpler. Much more simple as it is now.

        • virgodesign 10:57 pm on October 19, 2014 Permalink | Log in to Reply

          Plugins has grown so much in the years, and sometimes you can install and manage dozens. I would love the ability to group installed plugins using categories, just like posts with taxonomy. This will help admins having a better organized plugins page

    • Primoz Cigler 9:34 am on October 9, 2014 Permalink | Log in to Reply

      Maybe we could consider implementing the plugins/themes/core updates/installs utilizing the Web Workers (at least progressively enhance the experience for the users that use browsers that support that): https://developer.mozilla.org/en/docs/Web/Guide/Performance/Using_web_workers

      To be honest, I am not super familiar with the Web Workers, but I have a feeling that they would fit perfectly for that task being discussed. The support is very good among the browsers as well: http://caniuse.com/#feat=webworkers

      • Primoz Cigler 9:38 am on October 9, 2014 Permalink | Log in to Reply

        The main benefit would be (at least how I understand the web workers) that the user could even leave the install/update screen (for instance go wiring a new post) while the process will not be interrupted.

    • Cliff Seal 11:50 am on October 9, 2014 Permalink | Log in to Reply

      This isn’t fleshed out, but reading this brought at least one quick interaction to mind.

      Clicking the {refresh icon}{number} area in the admin bar could dropdown to show basic information:

      Plugin Name
      Current Version -> Available Version

      There could be a link to see details (where the user could choose what plugins to update, read descriptions, etc.) along with a link to just ‘Update All’. You could set the entire updating process in motion without leaving changing screens or anything else like that. And, instead of a fugly JS alert, you could add a cancellation timer: “Updating all in 10 seconds… [cancel]”

    • Hugh Lashbrooke 6:59 pm on October 9, 2014 Permalink | Log in to Reply

      Something that’s always stuck out in my mind is the fact that there are two separate actions for getting a new plugin running on your site: install & activate. In almost all cases, I would say that plugins are activated immediately after installing. To non-technical users, the differentiation probably doesn’t even make all that much sense.

      My thought is to rename the ‘install’ button and turn it into a 1-click ‘activate’ button. That way, after searching for a plugin, users simply click one button and the plugin downloads, unzips and activates. This gives the impression that WordPress and the plugin repo are all one cohesive system, instead of the segmented systems that they really are. Technical users would still know what’s going on of course, but the average user really wouldn’t care that now there is a new folder on their server with the plugin files in it – they just want it to work.

      Along with that and 1-click delete action like @radices suggested above – together that would go a long way to giving a much more cohesive and stable feel to WordPress itself and the plugin repo.

    • alexis_hancock 7:22 pm on October 9, 2014 Permalink | Log in to Reply

      I would really like to see some prompts around the errors that occur when a plug-in is unsuccessful. It’s very vague on what exactly went wrong and if error messages are provided, and sometimes they are, it would be nice to see prompts on how to debug for that message.

    • AMEEKER 11:56 pm on October 9, 2014 Permalink | Log in to Reply

      I don’t know if this is the right place to put this or not, but it’s related to the searching for plugins. When you type in or paste in a plugin name or query in the plugin search box, you have to hit ENTER to actually perform the search. There is no search icon anymore that allows you to click to complete the search. Can we add that back?

    • Josh Visick 8:48 pm on October 10, 2014 Permalink | Log in to Reply

      I think improving the experience and options available when something goes wrong with plugin updates is important. I’ve been thinking if it makes sense to have an easy revert to last installed version for plugin updates that happen to break a site. That could also possibly tie into an automatic support ticket for the plugin.

    • Graham Armfield 6:37 am on October 11, 2014 Permalink | Log in to Reply

      Some ambitious changes and additions to functionality listed here. Please can I ask that during the design and functional design stage that thought is given to how we can make this accessible.

      Every time there’s a change on the screen we need to be thinking about what feedback that screen reader users are getting. It’s important also to ensure that everything can be operated just by using a keyboard, and obviously that keyboard focus is always visible and that the tab order is logical.

      Thinking about accessibility at the design stage is a key step in ensuring that everyone can use the functionalty.

    • Matthew 1:06 pm on October 11, 2014 Permalink | Log in to Reply

      Add folders in the Media section.

    • owcv 8:40 am on October 14, 2014 Permalink | Log in to Reply

      Besides these layout changes, there are more essential questions I think.
      The plugin and theme installer of the future, should be able to completely deinstall a plugin or theme, not only the data on the webspace, but first and foremost all the stuff in the database (e.g. wp-options).
      In my opionion, this is a major problem of the plugin/theme-installer, because it can harm your wordpress site by bloating it with relics of deleted plugins/themes.

      • Timothy Bowers 12:46 pm on October 14, 2014 Permalink | Log in to Reply

        I’ve always been torn on this, whilst I’m favour of a better way to remove unneeded stuff from the DB, I’d worry about it’s use on the uninstaller where people simply deactivate, perhaps whilst testing for potential conflicts for example.

        I think if it’s implemented then it’s important to ensure it’s a conscious choice, something that forces the the user to acknowledge it’s irreversible. The number of times over the years I’ve seen users delete something that isn’t backed up, is custom, and they can’t get it back, even when a prompt asked “Are you sure?” and possibly even stated they can’t undo this action.

        With great power comes great responsibility. 🙂

        • owcv 3:27 pm on October 15, 2014 Permalink | Log in to Reply

          Of course and I’m very cautious when installing new plugins (testing them before and so on), but over the years, some times you change plugins for some reason and in worst cases you can’t ged rid of the old stuff. That’s why I think it would be great to have an app-like plugin and theme installer in WordPress.

  • Helen Hou-Sandi 2:53 am on October 8, 2014 Permalink
    Tags: , , plugins   

    Scalable Dropdowns and More, chat on 2014/10/8 

    In 3.9, I started taking a look at solving some long-standing scaling issues with dropdowns, notably those for users (#19867) and pages (#9864). I arrived at a conclusion about our mixed usage of autocomplete and autosuggest far too late to make it for 3.9, and did not add it to my plate for 4.0, but would like to tackle it again for 4.1.

    We can solve these issues smartly by using a combination of Ajax-powered autocomplete/suggest and smart defaults, e.g. users with the most content pre-loaded for quick access without having to run a search. As a brief overview of where I see us going with this – a roadmap, if you will: user dropdown, page dropdown, current instances of jQuery UI autocomplete (multisite users and new site), tags/nonhierarchical taxonomy UI, more built-in taxonomy UIs (#14877), and possibly more as we discover appropriate places. Not all of this will happen in 4.1 – think of this as not only a solution to long-standing, painful problems, but also a step in a series of many.

    To that end, we will be holding an initial chat at 19:00 UTC on 2014/10/8 to get things moving. @ericlewis and I have begun early development as a plugin – for more, see this particular branch, which experiments with using Select 2 as a JS helper library for the UI.

     
    • Jon Brown 7:03 am on October 8, 2014 Permalink | Log in to Reply

      I’m new and don’t know the history… I am not trying to reopen any debate. I’m wondering though if using Select2 is fairly settled? (Not because I have a personal preference between Select2, Selectize.js and Chosen, but rather I’d like to know how others wiser than me decided between them).

      • Helen Hou-Sandi 8:47 am on October 8, 2014 Permalink | Log in to Reply

        No hard decision has been made – that’s why it’s one branch in the plugin repo. Chosen doesn’t do Ajax/search on its own and Selectize is licensed Apache-only, though.

        • Jon Brown 2:19 pm on October 9, 2014 Permalink | Log in to Reply

          Ah… forgot APL2 is not compat with GPLV2 only compat with GPLV3. Anyway, was just wondering. I’ve used Select2 and Chosen a bunch in that past. Selectize looked like it had better tests and was lighter was all.

      • Dan Griffiths 10:33 am on October 8, 2014 Permalink | Log in to Reply

        Regarless of the licensing issues, Select2 has by far the best feature set of the three.

    • Max Bond 10:07 am on October 8, 2014 Permalink | Log in to Reply

      Don’t focus only on dropdowns!
      WordPress problem is wider – how to select wp data objects (post types entities, taxonomies, users) inside other objects.
      For example I have two custom post types: order and product. And I need to add product to order. Sounds simple, but there is no standard interface for such select! If needed to add user to order – the same interface should be used.
      Autocomplete/suggest – is good, but not enough. May be to use some kind of popup window (like media library)?

      • Helen Hou-Sandi 4:39 pm on October 8, 2014 Permalink | Log in to Reply

        We need to start with fixing long-standing bugs in existing functions, namely wp_dropdown_users() and wp_dropdown_pages() as linked in the Trac tickets above. As I said, there may be more possibilities as we take each step. If you have a citation for autocomplete/suggest not being good enough, I am all ears.

    • Gabriel Reguly 12:33 pm on October 8, 2014 Permalink | Log in to Reply

      I won’t be able to attend the chat, but would love if you do take into account the dropdown for sites in multisite installs.

      http://wpjourno.com/my-sites-toolbar-menu-wordpress-multisite/

      Cheers,
      Gabriel

    • Ben Hansen (ubernaut) 6:47 pm on October 8, 2014 Permalink | Log in to Reply

      sounds great!

  • Andrew Nacin 7:11 pm on August 21, 2014 Permalink
    Tags: , , plugins,   

    Introducing plugin icons in the plugin installer 

    WordPress 4.0 comes with a redesigned plugin installer. Just now we’ve added one of the finishing touches to this project — plugin icons.

    Plugin authors, If your plugin is compatible with WordPress 4.0, it only takes a few moments to change a readme “Tested up to:” value to 4.0. Compatibility information is prominently shown in the new plugin installer, so you’ll definitely want to update this value. For your plugin to stand out, you’ll also want to give your plugin an icon. Read on…

    Akismet

    Beautiful, auto-generated icons

    Default icons are generated using the GeoPattern library by Jason Long of GitHub. If you have a banner image, it is automatically sampled to determine the primary color for the pattern, using Tonesque from @matveb. (Cool, huh?)

    mosiac-2

    Making your own icon

    Plugin icons are 128 pixels square. HiDPI (retina) icons are supported at 256 pixels square. Like banners, these go into your /assets directory and can be either a PNG or JPG. So just create assets/icon-128x128.(png|jpg) and/or assets/icon-256x256.(png|jpg) and you have an icon.

    You also have another option: SVG. Vectors are perfect for icons like this, as they can be scaled to any size and the file itself is small. For an SVG file, you simply need an assets/icon.svg file.

    We may implement SVG-to-images fallbacks in core for browsers that don’t support them, so if you go the SVG route, I’d suggest also turning your SVG into a PNG. (SVG takes precedence.)

    Jetpack uses an SVG icon:

    Some tips when designing an icon

    • Keep it simple! The Android and iOS Human Interface Guidelines both have some fantastic design tips.
    • Avoid text, especially since these may be seen at smaller sizes in other contexts (and in languages other than English). And because this is an icon, not an ad.
    • Use the right image format for what you’re doing. Don’t use JPGs for simple designs; don’t use PNGs for photos.
    • Optimize your images! Use something like ImageOptim or your favorite web app, CLI tool, etc.
    • Please no WordPress logos. Come up with your own brand. (If you already have a banner image, you likely already have a head start here.)
    • If you haven’t worked with SVGs before, they’re pretty cool. Here’s a tutorial from Chris Coyier.
    • Keep in mind this is an icon for your plugin, not a display ad.

    Some examples

    Akismet, Jetpack, and Hello Dolly already have icons. You can see their assets directories herehere, and here.

    Thanks to the hard work of Alex Shiels (@tellyworth) for implementing this!

     
  • Mel Choyce 9:25 pm on June 17, 2014 Permalink
    Tags: plugins   

    Improving the Plugins Page: Follow-up 

    Following up on this earlier post: https://make.wordpress.org/core/2014/05/28/improving-the-plugins-page/

    After chatting a bit with Alex Shiels, Nacin, and Helen, I’ve put together a first pass at what an improved “add new plugin” page could look like:

    I based the new page off of the updated “add new theme” page. Instead of going with filters you can add together to search results, I’ve opted to use some broad categories. Filtering doesn’t really work with plugins, especially filters outside of different categories — if you check “backup” in security and “galleries” in media, you’re not likely to get any results. Clicking on a category would bring up results weighted by # of downloads, popularity, reviews, etc. If we did end up adding some additional filters, they could be for things like version compatibility or language.

    We’ve already talked a bit about how a visual might not be the best way to scan for new plugins, and how we need to highlight plugin descriptions more. We also talked a bit about the possibility of having a better landing page if you don’t have any plugins installed on your site, that would show a mix of featured/popular plugins and categories to browse through.

    This doesn’t affect installed plugin management — we were thinking that would remain mostly the same, maybe with some minor updates.

    One thing we really want to nail down is the average plugin install workflow: “I want WordPress to do X. It doesn’t seem to do X. Maybe a plugin can help me! Here’s how I would look for that plugin. Here’s how I would evaluate and compare the plugins returned by how I looked for them. Here’s how I would install it/activate it.” What does your workflow look like?

     
    • Dovy Paukstys 9:29 pm on June 17, 2014 Permalink | Log in to Reply

      Also want to show in the summary view number of downloads at a glance. That gives more confidence than stars. Also, perhaps, last updated to the right of the title too (float). That way we can know how recent it is.

      Perhaps (lastly) a little corner graphic showing if it’s tested to work with your version of WordPress or not, etc.

      All small changes, but can really reduce the effort a user goes through to evaluate plugins.

      • Dovy Paukstys 11:13 pm on June 17, 2014 Permalink | Log in to Reply

        Also, I REALLY would love for every version of plugin be backed up once. That way if a user deletes a version they need, or the new version destroys their site layout, they can rollback. It would be a simple act of backing up the directory before you delete. And it could easily be a setting for the system.

        This would go a long way in user support and 99% of plugin issues I’d say.

        • Dovy Paukstys 11:14 pm on June 17, 2014 Permalink | Log in to Reply

          What I mean, before you update or override a plugin, WP does a backup of the existing plugin and you can rollback your installed plugins from the plugins screen.

        • Jon Brown 1:04 am on June 18, 2014 Permalink | Log in to Reply

          This has been requested and discussed elsewhere. Plugin rollbacks are far too complicated to do reliably. Many DB changes are one way and there is no infrastructure in the WordPress API to handle that scenario.

          The “correct” way to do this is to freeze the site, backup the entire site including DB, update the plugin, test it works, unfreeze the site or restore from backup.

          Or test it on staging/development and then deploy live… either way you need a DB backup to reliably roll back.

        • Ipstenu (Mika Epstein) 1:16 am on June 18, 2014 Permalink | Log in to Reply

          Given that you don’t ever EDIT plugins (right? 😉 ) this would be better as a ‘revert to previous version’ if anything. Store the previous version from the readme in the DB, use that to install an old version. Sadly it depends on the plugin devs properly using SVN, which is pretty rare.

    • Casey Picker 9:30 pm on June 17, 2014 Permalink | Log in to Reply

      I’d be interested to know if there are there any guidelines or transparency around what plugins are “featured.”

    • Shane Pearlman 9:32 pm on June 17, 2014 Permalink | Log in to Reply

      I get popular and favorites (and would be curious to see how those algorithms get defined). What do you have in mind for featured?

      seconding Dovy’s comment – download count within a set window of time (like last 12 months). Full historical download count is super deceiving. Be even better if you could extract new downloads from updates, but I don’t think that is available from .org yet is it?

      • Jon Brown 1:07 am on June 18, 2014 Permalink | Log in to Reply

        Download count should be minimized in favor of “active install count”. Many have talked about this but it requires self-hosted sites reporting to .org what is being used… which is obviously a sensitive subject. I know wp.com stats collects this, but that seems like a small sample to base this off of.

        I suspect it’s still impractical, but a .org API for reporting on plugins that was opt-in would be killer.

        • Ipstenu (Mika Epstein) 1:17 am on June 18, 2014 Permalink | Log in to Reply

          They don’t have stats on active install, I don’t think. I know downloads/installs can be tracked via the API, but there’s no phone home allowed on activations, so how would you know?

          Simple to add? Sure/ Should we add that level of tracking? eeeeeeeeeeee I say no.

          • tomdryan 2:50 am on June 18, 2014 Permalink | Log in to Reply

            The plug in update function should be able to keep track how many unique plug in updates it serves. Also, don’t WP installs need to send the update server a list of installed plugins so that it can determine if there are updates available? This mechanism should be able to be modified to determined the number of active installs.

            This same mechanism could also be used to determine if a plug in is compatible with a particular version of WP, instead of the manual “is compatible with” function that no one seems to update.

            • Ipstenu (Mika Epstein) 3:34 am on June 18, 2014 Permalink

              Just because a plugin is updated doesn’t mean it’s ACTIVE though. Seriously, I look at hundreds of sites a day, people have inactive ones all over.

              don’t WP installs need to send the update server a list of installed plugins so that it can determine if there are updates available

              Kind of. The API query checks if the version installed is less than the one on wporg and pings for updates when needed. So .org only knows ‘No match’ and isn’t keeping a log of what version you have.

              And that’s still only going to tell you how many sites have the plugin installed. The yummy pie chart we used to have saying what version was on installed was horribly innacurate because of that 🙂

      • Syed Balkhi 11:57 am on June 18, 2014 Permalink | Log in to Reply

        Yup. I’d be interested to see if the featured list is going to to be heavily moderate and change regularly… the current one has barely changed since 2011

        https://web.archive.org/web/20111215022857/https://wordpress.org/extend/plugins/

        Looking forward to the new algorithm, but if we’re keeping everything the same then I feel that perhaps Popular should be the main tab instead of featured.

    • Charleston Software Associates 9:36 pm on June 17, 2014 Permalink | Log in to Reply

      Please bake in plenty of hooks and filters to allow themes or plugins to easily extend the interface. It would be great if the plugin system API on the server side of things were more accessible via documented API calls. I wrote a “Plugin Search Filter” called “Plugin Intelligence” that does a sort-of brute force interception of the plugin directory communications in an effort to show “only plugins with 4+ stars” or similar filters. This would be a LOT easier to extend the plugin discovery process with the hooks/filters and API changes.

      That will allow site admins to install a plugin that provides things like “download count”, “number of ratings / rating details”, and “hover for last 3 reviews” features without bloating core.

    • daveshine (David Decker) 9:36 pm on June 17, 2014 Permalink | Log in to Reply

      Looks easier to use!
      Wouldn’t that require that every plugin has a header image on .org? — Or at least add a *nice* placeholder for those that have a header image yet…!

      Also, when you’re at it, please add some kind of bulk installing plugins or some kind of “plugin cart” where I could collect for example 5 plugins from different searches and then install those 5 at once. PLEASE!

      Thanks a lot for this stuff!

      • daveshine (David Decker) 9:37 pm on June 17, 2014 Permalink | Log in to Reply

        I meant a *nice* placeholder for those plugins that have NO header image yet… 🙂

      • Michael Arestad 10:36 pm on June 17, 2014 Permalink | Log in to Reply

        It wouldn’t be tricky to just show the short description if no header has been added.

        I think a visual search can work well for plugins if the image is available. Even if it isn’t, using the short description would still be nice. My concern is how the header will be “cropped.” It might be better to add a second header with this in mind. Maybe something like header-alt.jpg…

        I would also have the name of the plugin at the very top as it’s the single most important thing when scanning through plugins.

        • Mel Choyce 4:42 pm on June 18, 2014 Permalink | Log in to Reply

          It wouldn’t be tricky to just show the short description if no header has been added.

          For sure — I’m think we should add a description for every plugin, actually.

          My concern is how the header will be “cropped.” It might be better to add a second header with this in mind.

          My goal with this particular set of wireframes was to keep it proportional to what exists now (for example: https://wordpress.org/plugins/buddypress/). There’s been some talk of adding a 100x100px image to use in plugin search results, which I’m personally not a fan of.

      • Mel Choyce 4:40 pm on June 18, 2014 Permalink | Log in to Reply

        Wouldn’t that require that every plugin has a header image on .org? — Or at least add a *nice* placeholder for those that have a header image yet…!

        Nah, was thinking we’d contain the plugin title on a grey background. It would hopefully incentivize plugin authors to include an image, but would be okay without.

        Also, when you’re at it, please add some kind of bulk installing plugins or some kind of “plugin cart” where I could collect for example 5 plugins from different searches and then install those 5 at once. PLEASE!

        This is out of scope for this current project (at least my involvement in it), but maybe for a future iteration?

    • demoman2k10 10:33 pm on June 17, 2014 Permalink | Log in to Reply

      I personally would find it useful to be able to sort plugin’s my the most recently UPDATED as well. So that we can quickly sort out those that are not keeping their plugin’s up to date with the latest Cord Updates.

    • Todd Lahman 11:00 pm on June 17, 2014 Permalink | Log in to Reply

      When sorting through plugins the existing format is perfect. Plugins are not at all like themes, so the big tiles makes it much hard to sort through a large number of plugins, and read the details about each. If the plugin page was meant to sell plugins, I could see the value of big tiles. I do however, like the search box and browse categories, since that can aid in finding a plugin faster.

      What does need improvement are plugin uploads.

      First, the media uploader needs to be applied to plugin uploads, so a plugin drag and drop upload would be possible. A lot of people do not understand how to find a .zip file in their local directory structure, but they might have the file sitting somewhere they can drag and drop it.

      Second, already installed plugins should be overwritten when a zipped copy of it is uploaded, instead of giving an error message.

      The Plugins page should be about user experience, and making important tasks like installation, easier to perform.

      I don’t think the current Plugins page format needs to be changed, but the plugin uploads needs work.

      • Dovy Paukstys 11:11 pm on June 17, 2014 Permalink | Log in to Reply

        Or at least ask the user if they want to override them when they are found, like a confirmation. I think that would make everyone happy.

        But I think if you override, you should always store a backup so you can fall-back.

      • Mel Choyce 4:49 pm on June 18, 2014 Permalink | Log in to Reply

        First, the media uploader needs to be applied to plugin uploads, so a plugin drag and drop upload would be possible. A lot of people do not understand how to find a .zip file in their local directory structure, but they might have the file sitting somewhere they can drag and drop it.

        Totally agree. Now that we’ve started doing that with media uploading, it would be cool to extend drag & drop to theme and plugin uploading. Not sure that’ll happen for this cycle (though it would be cool if it did! Any developers want to step up?) but I think it’s a logical next step.

        Second, already installed plugins should be overwritten when a zipped copy of it is uploaded, instead of giving an error message.

        How often do you find yourself doing this task? (Just curious, because I’ve never actually encountered this)

        • Ipstenu (Mika Epstein) 7:52 pm on June 18, 2014 Permalink | Log in to Reply

          When I’m de-hacking a site, fairly regularly.

          (I think wp-cli has a –force command for it)

        • Todd Lahman 3:50 am on June 19, 2014 Permalink | Log in to Reply

          When I need to replace a plugin that is not available as an automatic update, either from my site or from wordpress.org, and the plugin cannot be deactivated on the site because it serves a critical function, I have to put the site into maintenance mode, then delete, and replace the plugin using FTP or SSH. I’d use the plugin page to delete the plugin, but I may not want to delete the data when uninstalling. I’d like to see an upload routine similar to the automatic updates, with one exception. Allow the choice to reinstall if the plugin already exists, so the previous installation is removed, and the new .zip is installed without losing data.

          There have been automatic installations over the years that result in an empty plugin folder. Uploading a zip with the same plugin folder name results in an error. In this situation, that folder should be overwritten.

          The default behavior should be for the .zip upload to overwrite the existing folder or plugin installation. A dialog window could warn the uploader that the plugin already exists, but that same dialog window should not appear if the folder exists but is empty.

          When the user runs into a new situation, like one of the above, and WordPress just performs the task in a smart way, because we already built a solution for that into the core, the user walks away feeling like a genius, and is very satisfied with their experience. That’s good software.

          I deal with this regularly, sometimes several time in a day.

    • samuelsidler 12:58 am on June 18, 2014 Permalink | Log in to Reply

      I like these mockups.

      My only comment would be that I think it’s fine for you to not use plugin banners and instead create a new size of image for plugins to use. We would, of course, want to mirror that icon in the search results on WordPress.org as well. Banners take up a lot of space and it’d be nice to get more plugins per page on search results.

      • Jon Brown 1:08 am on June 18, 2014 Permalink | Log in to Reply

        Smaller banner/icons for sure. The banner is pretty, but it’s really unimportant information. I’d far rather see description excerpt and reviews.

      • Helen Hou-Sandi 4:10 am on June 18, 2014 Permalink | Log in to Reply

        I’m not super convinced that icon creation by plugin developers is going to go well; I for one would probably create something terrible. I am waffling between whether or not banners will actually be useful in a list context, though. The visual cue is very helpful, but it does encroach on space for other information that is just as or more helpful than the banner.

        • Ipstenu (Mika Epstein) 4:44 am on June 18, 2014 Permalink | Log in to Reply

          We can always try it with banners and kill them if they look ugly. But I know I won’t be able to design a meaningful small button either.

          • Mel Choyce 4:53 pm on June 18, 2014 Permalink | Log in to Reply

            It’s much easier to add a feature than to take it away, so I have a sinking feeling that if small graphics went in, we’d be stuck with them f-o-r-e-v-e-r

        • Mel Choyce 4:52 pm on June 18, 2014 Permalink | Log in to Reply

          I’m not super convinced that icon creation by plugin developers is going to go well

          I agree — at a small size like 100×100, which was suggested previously, plugin authors would face some serious design constraints. I’m having nightmarish visions of poorly set type on top of gradients.

          I’m also kind of waffling on banners, honestly. It might be easier to judge when mocked up, rather than just wireframed.

    • Helen Hou-Sandi 4:05 am on June 18, 2014 Permalink | Log in to Reply

      I typically find myself on one of two paths in the install plugin flow:

      1. I already know what I want, so I try to search for it in a way that will successfully get me the result I want up toward the top of the results. Sometimes I don’t actually remember the name of the plugin and it takes getting into the details box to figure out if it’s the one I’m looking for. Visual cues seem like they could be helpful here with quickly identifying a plugin you’re specifically looking for.

      2. I have something I want to accomplish that core doesn’t do, and I’m hoping a plugin will do it. Lately I have found myself searching on .org itself because more metrics are available there, and it is way easier to open a bunch of browser tabs with different plugins to compare details than the tedium of the details box in the WP admin. After finding the plugin I want on .org, then I essentially follow what I would do in the previous described path of looking for an existing plugin. In this case, a consistent visual cue (banner, icon, whatever) would be even more helpful in bridging between .org and the WP admin.

      Both of these paths center around search. I do not find myself browsing nor using favorites. I can definitely see value in both of those, the former for newer users and the latter for experienced ones. I think grouped and more curated categories would make the browsing experience much more useful. I also think that the “add new” landing page could better guide into various paths visually and with words – it’s pretty terrible right now. I’d also rather just put the uploader right there on that screen and stop separating it off into its own world. It does not take up a lot of room.

      For other filters, I think it would be useful to have simple checkboxes for showing plugins that are available in your language (possibly on by default, depending on i18n efforts) or labeled as working with your version of WP (also possibly on by default). There may be more that we’re not thinking of at the moment.

      In evaluating plugins, I look at changelogs / updated dates, contributors, and screenshots in particular. I also check out reviews, not just the stars and content, but also the relative volume, knowing that overall review volume is low and that drive-by complaints are pretty typical in any review system. Reviews and contributors are not currently available in the admin, and changelogs are not standardized in any way (I think they should be, FWIW), so it can be a crapshoot. For comparison, I do almost exactly the same thing when perusing the iOS App Store, and heavily rely on reviews on Amazon.

      As mentioned in IRC and on that original post, I think it would be really interesting to try a browse-details mode for a results list the way themes does. Having data at a glance is important too, but if I’m doing more than quickly searching for and installing a specific plugin I already have in mind, I want to do more detailed comparison between them and being able to quickly navigate between detail views seems like it would be helpful.

      Other flow thoughts, not all necessarily for right now:

      • When searching installed plugins and nothing is found, prompt the user to run the search on the plugins repo.
      • “Add New” language feels super wrong here, even though it’s consistent with other things in the admin.
      • Install in place (AJAX).
      • Activate a plugin that’s already installed from the search results. Right now it just tells you it’s installed. If we did install-in-place, then you could also activate-in-place. 🙂
      • Todd Lahman 8:32 am on June 18, 2014 Permalink | Log in to Reply

        Search by … popular, featured, newest, relevance.

        Currently there are different screens for categories like popular. It would be useful if categories like popular could be searched for key words like “SEO” for example. This way you would be searching for what you’re already looking for to narrow the search results further.

        More work should be done on the search algorithm to return more relevant search results. A search ranking system should be setup much like google. The ranking should include ratings, links to the wordpress.org plugin pages, if the plugin title contains the searched for words, etc., to create a fair and relevant search result, even if search for popular the ranking algorithm should be applied. The ranking system should apply different weight to different items. For example, ratings may not always reflect a plugin’s relevance, so that weight should be 0.1, but links to the plugin page, depending on what type of site is linking, would hold a higher weight to help determine the relevance of the plugin in the search results.

        • Helen Hou-Sandi 2:46 pm on June 18, 2014 Permalink | Log in to Reply

          Work is being done on search results on the .org side – see the previous post from @tellyworth. As far as sorting of search results goes, typically I like having lots of controls, but I think I’d rather start with a smart default (that is, better search results). As it is, newest is kind of meaningless.

    • Tareq Hasan 7:46 am on June 18, 2014 Permalink | Log in to Reply

      I like the current listing the way it is. Displaying themes like this is okay, but plugins? NO.

    • Nashwan Doaqan 7:48 am on June 18, 2014 Permalink | Log in to Reply

      I really liked the new UI .. it’s more modern and interactive! but..

      1- The plugins cover image is not very helpful!, I think it’s more important to show more information like Description, Update Data, Downloads Count..etc

      Maybe it’s a good idea for the “Featured Plugins” but when I perform a search query I prefer to see many results as fast as possible.

      2- I can’t see the “Newest” plugins tab?!

    • Stagger Lee 9:14 am on June 18, 2014 Permalink | Log in to Reply

      I have few suggestions.

      • Make Favorites in plugin page searchable. (saves time if you have many favorites)
      • Give us option to bulk disable all marked plugins, but also one option to enable them back (same marked plugins). Some sort of option that remembers last change. This mainly for developing. How many times people have some conflict and dont have easy option to disable all (or marked) plugins to test on clean install. Disable/enable one by one doesnt work if that situation is on live server (difficult on localhost either).

      So you see, if we need to make non functional live website to check if it is some plugin conflict, give us option to make it less painfull and with less risk any visitor will see it for that so short time (few seconds).

    • Junko Nukaga 9:57 am on June 18, 2014 Permalink | Log in to Reply

      I like the new UI.
      I want to display date updated. I think it is important.

    • michalzuber 1:47 pm on June 18, 2014 Permalink | Log in to Reply

      Could be switchable, for default would be this layout with images, but could switch (https://i.imgur.com/b0JwUtL.png) back to the old one? Bulk actions could be a missing feature with this new layout.

      • Helen Hou-Sandi 2:39 pm on June 18, 2014 Permalink | Log in to Reply

        As noted in the post, this would be for installing plugins, not management. The management screen would largely stay the same. Bulk actions are not available for installing plugins.

  • Alex Shiels 10:56 am on May 28, 2014 Permalink
    Tags: plugins   

    Improving the Plugins page 

    The WordPress Plugins page has barely changed in 5 years or more – compare WP 2.7.1 with 3.9.1.

    The very first page seen by a new user who clicks on the Plugins tab is a list view showing two installed plugins. The main thing thing that has changed since 2.7 is that the way to find and install new plugins has become less obvious.

    Similarly, the plugin-install page has barely changed in that time: WP 2.7.1 and 3.9.1.

    The default page is very much geared towards maintenance by established users. The most common interaction is probably deactivating and reactivating plugins for troubleshooting – certainly a necessary task, but I think it misses a good opportunity for helping people to find and use the plugins they need.

    There are a number of improvements that could be made with relatively minor changes:

    Improve the experience for new and infrequent users.

    • The obvious fix here would be to make the path for discovering and installing new plugins much more obvious than the “Add New” link. Perhaps even go as far as making plugin-install.php the default page.
    • The Search Installed Plugins box on plugins.php is easily mistaken for a plugin directory search. Either make it less confusing, or use a unified search.
    • When searching for plugins in the directory via plugin-install.php, tailor the results to the current WP version. Give more weight to those that are compatible with the current version, and/or filter out those that are likely to be incompatible.

    Help users to discover the plugins they need, especially the most robust and well-maintained.

    • On the Add New page, the most common tags in the cloud are “widget”, “post” and “plugin”. It’s next to useless. Replace it with a well-defined list of categories more in line with common needs: “contact forms”, “image galleries”, “security” and so on.
    • Improve the quality of plugin directory search results generally. Incorporate things like ratings, support stats, age, usage stats, and update frequency in the relevancy scores.
    • Augment or replace version compatibility votes with stats based on active installs per WP version.
    • Re-evaluate the tabs on the Install Plugins page. Is “Newest” helpful? Should “Popular” or “Featured” have a summary on the main page?
    • Improve the algorithm used for averaging ratings, to smooth out errors for plugins with only a handful of ratings.
    • Change the columns displayed in Search Results. “Version” doesn’t need a column; but compatibility and age ought to be shown.
    • Also show compatibility for installed plugins #27699
    • Improve the ordering and filtering possible in the plugin search API #12696 and #27316

    Improve the way detailed information is given about plugins.

    • Either eliminate the thickbox for the plugin details, or make it more consistent with the theme browser (allow next/prev)
    • Add a Details view for installed plugins #17902
    • Show reviews in the detailed view #22599
    • Show contributors in the detailed view #19784
    • Show the plugin’s banner in the detailed view, and generally make it more consistent with what’s on the web site.

    Help and encourage developers to publish and maintain their plugins.

    • Support screenshots, logos, or banners in the search results, installed plugin list and plugin directory.
    • Do a better job of handling ratings, reviews, updates, and support stats, especially when determining search ordering and popularity.
    • Improve the profile page to list version compatibility, support stats, and other useful info for all your plugins.
    • Add a version requirement check and/or upgrade prompt #26909 and #27323

    And finally there are some other tickets suggesting improvements and fixes that could use a second look:

    • #28085 – Recently Updated plugins view (recently updated installed plugins)
    • #20578 – allow delete without uninstall
    • #27110 – allow filtering the plugin list
    • #26202 – bugfix for thickbox title truncation
    • #27623 – search results for a single space
    • #27994 – handling of automatic plugin deactivation in the event of an error

    I’m working on the API side, starting with improvements to search quality. There are tickets above for many of these items already. If you’d like to help out, keep an eye on the Plugins Component in trac, open and help with tickets. Or leave a comment here with your suggestions if you’re interested.

     

     

     

     

     

     
    • chriscct7 11:12 am on May 28, 2014 Permalink | Log in to Reply

      One thing that would also be really cool is if you could do like an ecommerce style cart in the plugin area. So an example would be I search for SEO plugins, find one I like and “add to basket”. Search for caching plugin, find one I like, add to basket. Search for cat shortcode plugins, find two I like in the results, add both to basket. Then at the end, I click an “install all plugins in basket”.
      This would solve an issue I have with the plugins area which is it takes forever to install more than say 4 WordPress plugins, because you have to either have a 4 tabs of plugin-install open to do them simultaneously, or go back to back to back to back which takes forever. Just a thought.

    • Ajay 11:17 am on May 28, 2014 Permalink | Log in to Reply

      I don’t think making the “Add New” page as the default is a good option. You’re more likely to visit the plugin page to view / disable / access links of the existing plugins rather than install new plugins.

      It would be good to have a single column with rating, no. of downloads, age, etc. rather than separate columns in order to give more width to the Description section.

      • chriscct7 11:19 am on May 28, 2014 Permalink | Log in to Reply

        I agree with Ajay. I don’t think Add New as default is a good idea

      • Brad Touesnard 12:02 pm on May 28, 2014 Permalink | Log in to Reply

        +1

      • Chip Bennett 3:33 pm on May 28, 2014 Permalink | Log in to Reply

        +1. The default Plugins page should be installed/active Plugins.

        If anything, the default Plugins page should aim toward facilitating Plugin management. Things I would like to see:

        1. Plugin Settings page link added by default
        2. Plugin categorization

        • Torsten Landsiedel 3:09 pm on May 30, 2014 Permalink | Log in to Reply

          +1 for default to installed plugins (to be consistent to other pages UI)

          +1 for adding the settings link by default

          and another +1 for categories for plugins 🙂

        • Torsten Landsiedel 3:23 pm on May 30, 2014 Permalink | Log in to Reply

          Speaking of plugins: What about making it possible to connect the support tab of a plugin with the international forums like xx.forums.wordpress.org instead of wordpress.org/support to make local/translated support possible. Or better: Make the whole plugin page multilanguage. This would be an huge enhancement for the plugin page in WP too.

      • michalzuber 4:21 am on May 29, 2014 Permalink | Log in to Reply

        +1

      • daveshine (David Decker) 3:01 pm on May 29, 2014 Permalink | Log in to Reply

        +1

      • The Portland Company 6:59 pm on May 29, 2014 Permalink | Log in to Reply

        That’s subjective. As a developer; sometimes I am deactivating, other times I’m installing. My customers are usually installing. And I’m sure there are other people groups with different applications as well.

        The most ambiguous model would seem to be an Option in the Screen Options (or Settings, whatever) that allows the User to configure the default page to their liking. Then, apart from that, it will remember what section/tab they were on so when they navigate away and then back again they can continue.

    • camu 11:23 am on May 28, 2014 Permalink | Log in to Reply

      Two words: plugin dependencies 🙂

      https://core.trac.wordpress.org/ticket/11308

    • Jacob N. Breetvelt 12:12 pm on May 28, 2014 Permalink | Log in to Reply

      I would like to add a feature request: the possibility of re-install without delete, i.e. forced update with the same version no.

      • crzyhrse 1:55 pm on May 28, 2014 Permalink | Log in to Reply

        +1

      • Ipstenu (Mika Epstein) 5:05 pm on May 28, 2014 Permalink | Log in to Reply

        https://wordpress.org/plugins/baw-force-plugin-updates/ can do that so it SHOULD be addable to core.

      • Dovy Paukstys 8:23 pm on May 28, 2014 Permalink | Log in to Reply

        +1

      • David Lingren 10:42 pm on May 28, 2014 Permalink | Log in to Reply

        Great idea. I would also support “forced update with the current stable version”. I have had a few occasions (my fault, of course) when I posted a new version, found a bug and reverted to the previous version. There are always a few folks who got the new version before I could recall it, and they are stuck with the higher version number.

        In addition, it might be useful to have a “go back to the previous version” option when an update causes a problem or just isn’t wanted.

        I realize both of these can be complicated by database changes, etc. but they are worth considering.

        • The Portland Company 7:03 pm on May 29, 2014 Permalink | Log in to Reply

          +1

          Furthermore we really need to require developers to clean up after their Plugins after an uninstall. I understand that sometimes Users want to keep their data but delete the Plugin to reinstall it, so developers don’t delete files/databases but, at the same time, there’s no option to delete everything when Users DO want EVERYTHING deleted. Leaving unnecessary files and such.

          A simple API for developers to hook into to PROVE they’re Plugin delete’s everything upon Delete – plus a “go back to previous version” option could solve the problem for both parties.

    • TheHandOfCod 12:25 pm on May 28, 2014 Permalink | Log in to Reply

      I think the main thing that would help is to improve the search. If you do a search on ‘Form’ for example the first plugin shown has a lower star rating then plugins displayed later in the list. As mentioned above the Tag Cloud leaves a lot to be desired also.

      Another idea could be to allow installed plugins to be associated with custom categories on the installed plugins page? And allow bulk activate/deactivate by category? Paging would be good as well, with the ability to change the number plugins seen per page. This would help with not losing the menu when scrolling through more than a few plugins.

      I think the ecommerce style approach could be confusing as it might look to ‘new’ users as though they were buying plugins rather than installing free plugins from the repository. However I do like the way that Pippin Williamson displays extensions for EDD https://easydigitaldownloads.com/extensions/, and maybe taking direction from this style could be a good idea.

    • earnjam 1:19 pm on May 28, 2014 Permalink | Log in to Reply

      Something else I’d like to see related to the plugins page is some discussion on #14569

      In multisite it’s pretty confusing having themes and plugins operate in different ways (activate vs network activate vs enable vs network enable). Any patch that deals with that would involve modifications to the plugins page. But well before that, I think there should be discussion about the merits of it and how it would be handled in the first place.

      • Ipstenu (Mika Epstein) 1:23 pm on May 28, 2014 Permalink | Log in to Reply

        That said, plugins and themes are vastly different on multisite in how they behave. If you network activate a theme, it’s available on all sites for possible use. If you network activate a plugin, it’s ON for all sites. But I would suggest this is out if scope for a plugin page cleanup.

        • earnjam 4:23 pm on May 28, 2014 Permalink | Log in to Reply

          That’s my entire point. WHY should they even be acting differently? If you can make themes available to only certain sites, why not make plugins function the same way?

          I agree that it’s beyond the scope of what was in the OP above (no mention of multisite), but as long as we’re talking about changes to the plugins interface, and we really want to pay more attention to multisite on this release cycle (as has been stated a few times), I think that this would be a valid discussion to have. Maybe not here, maybe IRC or trac, but definitely somewhere.

          • Ipstenu (Mika Epstein) 4:33 pm on May 28, 2014 Permalink | Log in to Reply

            WHY should they even be acting differently?

            Because… a theme is not a plugin. But the issue is language, not behavior here 🙂 We have a trac ticket on this I thought, but can’t find it.

            You can only have ONE theme active on a site at a time, right? So a ‘Network Actived’ theme is actually a ‘Network available’ theme.

            On the other hand, you have 50 plugins on a network, and 10 should be permanently on for all sites (network active) and the other 40 should be available.

            So I feel it’s outside the scope of enhancing the plugins pages, because I feel the issue lies not in the activation and handling of plugins, but in the terminology used 🙂

            • earnjam 7:34 pm on May 28, 2014 Permalink

              Oh, I definitely agree that the language could use some improvement. I’ve seen that ticket somewhere too. Maybe the discussion on #18301 ?

              But I think seeing this only as a language problem is a narrow way of viewing it. Just because you have 50 plugins installed on a network doesn’t mean you want all 50 to be available to all of the sites. Just as if you have 50 themes installed, doesn’t mean you want all 50 themes available to all sites. With themes, you can enable their availability for activation on an individual or network-wide basis. With plugins, once they are installed, they are all available for activation all the time.

              Again, I agree it is outside the scope of the original post here, but I don’t agree that it is outside the scope of general enhancements to the plugins page because this pertains to what plugins are available for activation…which is exactly what shows on the plugins page. 🙂

            • Ipstenu (Mika Epstein) 8:30 pm on May 28, 2014 Permalink

              Ahh so you’re thinking the granual control.

              https://wordpress.org/plugins/plugin-commander/ type stuff?

              YES, that should be there. I thought you meant something else!

            • earnjam 8:39 pm on May 28, 2014 Permalink

              Yes! That’s what I’m talking about.

              https://wordpress.org/plugins/multisite-plugin-manager is a good example, though not a very nice UI.

    • Ipstenu (Mika Epstein) 1:24 pm on May 28, 2014 Permalink | Log in to Reply

      Have you seen the layout for Jetpack modules? That is nice and neat and would be kind of awesome. Imagine if a plugin could use the menu icon for the plugin page like that?

    • Paal Joachim Romdahl 1:45 pm on May 28, 2014 Permalink | Log in to Reply

      Sometimes I install plugins, activate them but they remain unused. When I want to clean up the plugins I wonder which plugins are not used and are alright to delete. It would be nice if there was a signal of some kind showing where and how a plugin is used.

      Also when a plugin requires other plugins or have add-ons it would be nice to add a drop down or something showing the connection of these “child plugins” in connection with the “parent” plugin.

      • michalzuber 4:20 am on May 29, 2014 Permalink | Log in to Reply

        +1

        • The Portland Company 7:07 pm on May 29, 2014 Permalink | Log in to Reply

          +1

          Though there is some serious consdieration that would need to go into how to identify that sort of thing. Maybe even an API required for developers to opt-into. There is such a variety of Plugins – many of which aren’t directly interacted with – that I can’t imagine a way we could measure their used-ness.

          But I agree!

    • Charleston Software Associates 1:49 pm on May 28, 2014 Permalink | Log in to Reply

      I think the API needs to be improved along with this effort. The info server should allow for results to be filtered and sorted. Sort by download count, last updated date. Filter by compatible with my version, etc. My initial investigation was that any filtering needs to first retrieve a search query THEN filter those results which is less than optimal.

      Helping users, whether newbs or WP gurus, find the right plugins would be a big step in easing “plugin frustration”. Anything that stops the typical plugin search pattern of “search, install, not what I needed/broken/insecure, uninstall, repeat” would be a BIG help for myself and many of my clients. Filtering and sorting searches from within the WP Plugin Add New page would be a step in the right direction.

    • hereswhatidid 2:05 pm on May 28, 2014 Permalink | Log in to Reply

      I’d like to see some classification of the plugins in the admin. Something like Front End, SEO, etc… Similar to the Tags list on .org but more generic. This is something that I’ve seen in a few other CMSs and it really helps with the UX when there are a lot of plugins/modules installed.

    • crzyhrse 2:09 pm on May 28, 2014 Permalink | Log in to Reply

      I’d like to see links on the WordPress Plugins page that go to each plugin’s WordPress plugin page. Most often as it is they go to the author’s web page(s).

      To make it easier to look for support, to rate, to donate, whatever…

    • Paal Joachim Romdahl 4:50 pm on May 28, 2014 Permalink | Log in to Reply

      (Originally posted by Spencer Hill https://make.wordpress.org/core/2014/05/06/summary-of-last-weeks-dev-chat-on-4/#comment-14298 )

      I’d (Spencer Hill) like to contribute to Plugin Installer enhancements with @nacin.

      More specifically I believe we need to rethink the visual architecture of that page. Here are a few examples of what I mean:

      Some Plugins *revise* Core features.
      Others *replace* Core features.
      Then some *extend* Core features.
      Others introduce entirely new features that will not, and should not, become apart of the Core.
      And, lastly, some *extend* or *revise* *Plugins* themselves. These are commonly referred to as Add Ons or Extensions (like WooCommerce Extensions).
      As a User, viewing the Plugins screen these all blur together and there’s no way to filter between them. I find myself accidentally installing Plugins with duplicate features. And there is no way to see the relationship between some Plugins like “Add On” Plugins (which are the ones that extend or revise Plugins themselves).

      I’ve prepared a mockup that can be viewed here: https://drive.google.com/a/theportlandcompany.com/folderview?id=0B8-MGuUsAa39dHdRa1I0SG9yZVE&usp=drive_web

    • Jon Brown 6:04 pm on May 28, 2014 Permalink | Log in to Reply

      Almost completely absent from this discussion seems to be “Getting better user feedback published back to the repo”.

      In order to “Help users to discover the plugins they need” we need better data published to .org.

      I’ve been pushing this for a while so realize there are auth issues in publishing reviews/compatibility reports directly from a .org install back to wordpress.org. However, I really think part of this push should be figuring out how to encourage plugin feedback or mining what data we can better. I do like the idea of reporting “Active Installs” for popularity instead of downloads, but we need to focus on this a bit and figure out what we can do.

      • Michael Beil 8:44 pm on May 28, 2014 Permalink | Log in to Reply

        I agree Jon.

      • The Portland Company 7:12 pm on May 29, 2014 Permalink | Log in to Reply

        +1 – @nacin mentioned he was responsible for this in an IRC a couple weeks ago.

        I don’t know how this could be done while respecting privacy, but I know that when I’m searching for a new Plugin I install, uninstall. Find a new one; install, uninstall. Find another; install, uninstall. Until I narrow it down to one or more. So if there was a way we could share that data with other users so they don’t waste time on crap-Plugins I think that would be valuable. But that may be beyond the scope of what we’re trying to do here and that’s understandable!

      • Andy McIlwain 9:20 pm on June 3, 2014 Permalink | Log in to Reply

        +1. I’m really interested in seeing some quantitative+qualitative feedback. Particularly if we can identify some standout pain points.

    • Arnan de Gans 7:10 pm on May 28, 2014 Permalink | Log in to Reply

      While I think there are some good points here, at the same time I’m also thinking the current listing of installed plugins doesn’t need fixing as it works perfectly fine as it is.

      • The Portland Company 7:16 pm on May 29, 2014 Permalink | Log in to Reply

        I have to disagree. I mean, it’s *functional* but has a few *major* issues relating to security and database optimization:

        • Many Plugins don’t clean up after themselves properly during Delete.
        • Users should know, on Delete, whether or not a Plugin is going to remove absolutely everything it created (database or files) or leave something behind.
        • – If it does Users need to be given the option to say “No, I want you to remove everything. Don’t force me to let you leave crap behind in my file structure and DB”.
        • Ipstenu (Mika Epstein) 3:11 pm on May 30, 2014 Permalink | Log in to Reply

          That is not all that easy. The way plugins clean up is via an uninstall script, and at this time, without a total overhaul of not just the plugin page but plugin install processes, it’s not feasable. Should we look to it long term? Maybe… It’s a messy idea, and that’s much of why we left it in the hands on the plugin devs.

          Sadly that’s also why it’s not as common as it could be.

          1) Plugins ALWAYS delete the plugin folder files on uninstall
          2) Plugins are ENCOURAGED to delete tables/options on uninstall
          3) Plugins RARELY delete the ‘other’ files it adds (like advanced-cache.php, extra uploads etc)

          Deleting the non-plugin-folder files is super messy and not something I’d want to see for all plugins. Like a gallery? Imagine if NGG nuked all your images on uninstall. You’d be livid 🙂 That’s always going to be a manual call there for sanity.

          Deleting the tables? Even then, it has to be thoughtfully done per plugin. Take those role editor plugins. You would, theoretically, want them not to delete but to reset on uninstall.

    • Dovy Paukstys 8:14 pm on May 28, 2014 Permalink | Log in to Reply

      I’d like to see a safety feature built in. When you update a plugin, move it to a store directory. A cron task is setup to delete it in say 8 hours. If the user is not happy with the update or it breaks something, you can restore to previous. That would help the user side of things.

      • Greenweb 9:19 pm on May 28, 2014 Permalink | Log in to Reply

        That would assume that any data and or data schema related to the old version was not changed on activation of the new plugin.

        • Jon Brown 1:24 am on May 29, 2014 Permalink | Log in to Reply

          +1 – reversion is complicated.

          If a user needed/wanted to they can download an older version from .org and manually install.

        • Ipstenu (Mika Epstein) 3:14 pm on May 30, 2014 Permalink | Log in to Reply

          That’s actually less complicated. Since DB/data changes usually happen with an intentional click after upgrade it could be safe ‘enough.’

          There are plugins that make major db structure overhauls, and yes, that would be problematic. Still, a file dump to flip to the last version requires one thing we don’t have 🙂 What was the OLD version?

          Copying the folder to a plugins-old or plugins-backup folder might do it, though we’d have to come up with a way to delete THAT after x time (NOT 8 hours, more like 5 days). Feasible, though. I’d love to see a plugin do that so we could experiment with it!

    • David Lingren 10:49 pm on May 28, 2014 Permalink | Log in to Reply

      I hope there will be a corresponding effort to improve the Plugin Repository as well. For example, a plugin-specific Support Forum “Search” facility that would only look at topics within the current plugin. The Repository-wide search is useless in many cases.

    • michalzuber 4:18 am on May 29, 2014 Permalink | Log in to Reply

      Would be cool to have Recommend (for example https://i.imgur.com/bLyfW4X.png from https://play.google.com/store/apps) showing what my friends favorited on WP.org

    • Dan Griffiths 8:10 pm on May 29, 2014 Permalink | Log in to Reply

      Agree with A LOT of the proposed changes… probably the single most useful I can think of would be the addition of native plugin dependency support. That said… we’ve already lost the install_themes_tabs filter (which I used)… please don’t lose the install_plugins_tabs filter too… or at least provide suitable replacements. It might not be common use, but there are valid reasons for needing to extend/modify the theme/plugin tab bars…

    • Josh Pollock 12:18 am on May 30, 2014 Permalink | Log in to Reply

      I had a user today report that my plugin couldn’t be installed via the theme installer since it didn’t have a valid style.css. This may seem silly to experienced users but how clear is the difference between plugins and themes to new users?

      It seems to me that as long as the plugin installer, should, if the uploaded file fails plugin validation, check if it passes theme validation and if so point the user to the right installer and the theme installer should do the same thing as well. This would take one pain point away from learning our platform and turn a frustration into a learning experience.

      • Ipstenu (Mika Epstein) 3:17 pm on May 30, 2014 Permalink | Log in to Reply

        The error message there should be a little better. “The zip you have attempted to upload does not appear to be a THEME.” and then possibly a check to see if it has plugin headers so we can correct people?

    • sffandom 10:29 pm on May 30, 2014 Permalink | Log in to Reply

      ” Incorporate things like ratings, support stats, age, usage stats, and update frequency in the relevancy scores.”

      That would be a very bad idea. If a new plugin is being frequently updated to compete with an older, more robust plugin, then the user would be misled into thinking the new plugin has an advantage.

      The same goes with ratings. How do you compare a 4-star rating based on 5 feedbacks with a 4-star rating based on 500?

      And given how some developers mark support threads as “Resolved” when they are NOT resolved, the support stats would be useless.

      You touched on this problem here: “Improve the algorithm used for averaging ratings, to smooth out errors for plugins with only a handful of ratings.”

      Yes, but ratings in general are an unreliable metric for quality, suitability, or matching user needs.

      Compatibility is really not very helpful in many cases. A lot of old plugins work just fine with the current version of WP. What would be helpful is a catalog of reported errors. If a plugin is really incompatible with a new version of WP there should be a way for people to report that and for the plugin dashboard to say, “400 users reported compatibility issues with this plugin from version X on up.” Not perfect, but much better than the current system.

      • Alex Shiels 5:48 pm on June 7, 2014 Permalink | Log in to Reply

        I agree that ratings are unreliable metrics. And that update frequency, download counts and active installs could lead to an undesirable feedback loop that unfairly promotes a limited subset of plugins.

        I’m not suggesting that any of those things be used as the sole metric for ranking search results. Merely that they be incorporated into the ranking algorithm provided that the end result does in fact improve search quality. We do have access to engines and expertise in that area.

    • Pete 11:09 am on July 25, 2014 Permalink | Log in to Reply

      The ability to categorise all my favorited plugins would be awesome. As it is now I have 10 pages of my favorited plugins with no ability to search/browse/categorise them in any meaningful way.

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