WordPress.org

Make WordPress Core

Tagged: plugins Toggle Comment Threads | Keyboard Shortcuts

  • 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.

  • Ryan McCue 2:12 am on April 14, 2014 Permalink
    Tags: , , plugins, symlinks   

    Symlinked Plugins in WordPress 3.9 

    One of the cool little features included with 3.9 is the ability to symlink plugin directories. While it has been possible to symlink plugins in the past, functions such as plugins_url() return the wrong URL, which causes breakage in most plugins.

    In #16953, r27158 and the followup r27999, we corrected this with the help of a new function: wp_register_plugin_realpath(). This function is called automatically during the plugin loading phase, and registers which plugin directories are symlinked, and where they’re symlinked to. This functionality is then used by plugin_basename() (the core of plugins_url(), along with other
    functions) to reverse symlinks and find the correct plugin directory.

    This enhancement means that you can symlink individual plugin directories, or even the whole plugins directory itself.

    For anyone who’d like to use this, keep in mind that there are a few caveats:

    • Single-file plugins are not handled by this code. Any plugins you’d like to symlink must be in subdirectories of the main plugins folder. This restriction is due to the way these paths are registered.

      You can still symlink single-file plugins, however any use of plugin_basename() will be as broken as it was before 3.9. This is not a huge issue, as the main use of this is in plugins_url(), which is not frequently used in single-file plugins.

    • Must-use plugins cannot be symlinked. For the same reasons as single-file plugins, mu-plugins are not handled.

      For anyone using the common pattern of subdirectories within mu-plugins with a common loader file, you can use wp_register_plugin_realpath() directly to ensure that your subdirectories are handled.

      The following example code demonstrates how to use the function:

      <?php
      $plugins = array(
      	'my-mu-plugin/my-mu-plugin.php',
      );
      foreach ( $plugins as $plugin ) {
      	$path = dirname( __FILE__ ) . '/' . $plugin;
      
      	// Add this line to ensure mu-plugins subdirectories can be symlinked
      	wp_register_plugin_realpath( $path );
      
      	include $path;
      }
      

      Hopefully this change is as helpful for you as it was for me! One of the great advantages to this is that plugin developers can keep their plugin separate from their WordPress installation. This is a boon for developers with multiple installs who want to test compatibility; keep in mind that you can symlink the entire plugins directory if you’re testing multiple!

      If you have any questions about this, please leave a comment on this post and we’ll be happy to help you out!

     
    • PeterRKnight 2:29 am on April 14, 2014 Permalink | Log in to Reply

      This is super handy

    • Mike Schinkel 4:25 am on April 14, 2014 Permalink | Log in to Reply

      Kudos Ryan for pushing that feature through.

    • Julien 6:50 am on April 14, 2014 Permalink | Log in to Reply

      That’s great news! Thanks!

    • Fab1en 7:36 am on April 14, 2014 Permalink | Log in to Reply

      Thanks for this Ryan !
      I was using a custom plugin that tweaked `plugin_basename` to make it work with symlinked plugins. Thanks to you, I will not need this plugin anymore !

    • klihelp 12:37 pm on April 14, 2014 Permalink | Log in to Reply

      Thanks for the post.

      >> This is a boon for developers with multiple installs who want to test compatibility
      Tell me more about this.
      Could I read as a multiple WP installs uses the same plugin directory, so you don’t have multiple copies of the plugins?

      • Fab1en 3:42 pm on April 15, 2014 Permalink | Log in to Reply

        yes, that is what you can read ! Just add a symlink to a shared plugins directory in each WP install wp-content folder, and your installs will share the same plugins copy.

    • hinnerk 3:06 pm on April 14, 2014 Permalink | Log in to Reply

      Thanks a lot! Great enhancement! Makes my developer live much easier!

    • Frank 3:18 pm on April 14, 2014 Permalink | Log in to Reply

      Really useful, reduce the custom work.

    • Brian Layman 3:44 pm on April 14, 2014 Permalink | Log in to Reply

      This is a neat little thing. We’d experimented with symlinking the files back in b5media days with our 350ish sites, but there were enough little oddities to make it not the right choice for a poor man’s MU option.

    • Primoz Cigler 5:33 pm on April 14, 2014 Permalink | Log in to Reply

      Very important and useful update. But I have a question: is something like this possible with the themes as well? Would make perfect sense for the same reason, if you are a theme developer: “One of the great advantages to this is that theme developers could keep their theme separate from their WordPress installation. This is a boon for developers with multiple installs who want to test compatibility; keep in mind that you could symlink the entire themes directory if you’re testing multiple!”

      • Ryan McCue 2:12 am on April 17, 2014 Permalink | Log in to Reply

        But I have a question: is something like this possible with the themes as well?

        I can’t think of any issues with allowing this; file a ticket on Trac! :)

    • Primoz Cigler 5:34 pm on April 14, 2014 Permalink | Log in to Reply

      This is very important and useful update. But I wonder if something similar would be possible with the themes too? For the same obvious reasons as for plugins.

    • hinnerk 7:25 am on April 15, 2014 Permalink | Log in to Reply

      I had to add Options +FollowSymLinks to my .htaccess in order to remove a 403 Forbidden on all pages (using symlinks in plugins directory).

    • hinnerk 7:27 am on April 15, 2014 Permalink | Log in to Reply

      I had to add Options +FollowSymLinks to my .htaccess to remove a 403 Forbidden on all pages (using symlinks in /wp-content/plugins/).

    • Todd Lahman 8:45 am on April 15, 2014 Permalink | Log in to Reply

      This is totally awesome!

    • elimc 7:00 pm on April 16, 2014 Permalink | Log in to Reply

      I’m a bit confused about what this future does. Does this allow me to define a constant on my local server that links to the plugin directory on remote sites, thereby, preventing the need to duplicate the same plugins on both the local and remote server?

      • Ryan McCue 2:13 am on April 17, 2014 Permalink | Log in to Reply

        This doesn’t allow you to share plugin files across HTTP, no. It does allow you to have certain plugins live outside of your WordPress content directory, which means you can share the same code between multiple installations on the same server.

    • experiencedbadmom 11:39 pm on April 17, 2014 Permalink | Log in to Reply

      Total newbie here. I blog as a hobby. I do not know code. I updated to 3.9 today and now ALL I get is this error message:

      Fatal error: Call to undefined function wp_register_plugin_realpath() in /home/content/92/8889792/html/wp-settings.php on line 213

      I can’t get to my login page or see my blog anymore. I found this thread by searching “Fatal error: Call to undefined function wp_register_plugin_realpath()”. Any advice would be greatly appreciated to restore my blog! Thank you.

    • satimis 6:14 am on May 1, 2014 Permalink | Log in to Reply

      H all,

      I encountered similar problem on moving a website on Godaddy Deluxe hosting plan to Ultimate hosting plan (the website still works without problem on the former plan)

      On preview after moving
      Fatal error: Call to undefined function wp_register_plugin_realpath() in /home/gopublic2014/public_html/cuisine/wp-settings.php on line 213

      wp-settings.php
      line 213 wp_register_plugin_realpath( $plugin );

      but I couldn’t resolve where to enter;

      <?php
      $plugins = array(
          'my-mu-plugin/my-mu-plugin.php',
      );
      foreach ( $plugins as $plugin ) {
          $path = dirname( __FILE__ ) . '/' . $plugin;
       
          // Add this line to ensure mu-plugins subdirectories can be symlinked
          wp_register_plugin_realpath( $path );
       
          include $path;
      }

      How to change ( $path ) ?

      Please help. Thanks

      satimis

    • styledev 11:39 pm on May 11, 2014 Permalink | Log in to Reply

      I have a local multisite setup and I am symlinking in the entire plugins directory. When I network activate Advanced Custom Fields and go to one of my sites’s ACF Custom Fields page the resource files are still loading in as

      http://oc.flocers.dev/Users/dbushaw/Dropbox/Parapxl/Wordpress/plugins/advanced-custom-fields/css/global.css

      Instead of

      http://oc.flocers.dev/wp-content/plugins/advanced-custom-fields/css/global.css.

      I thought WordPress 3.9 fixed this like you note above?

    • ThreadPasser 10:41 am on June 15, 2014 Permalink | Log in to Reply

      How about when I decide to “remove” the plugin from one install but I want to keep it in the other… will that remove just the symlink (affects only this install) or the entire directory (affects all installs)?

      How about updates which require database changes? Will all this work or is this all very experimental? Or is this just meant to be used by developers and for temporary setups?

      • Ipstenu (Mika Epstein) 4:29 pm on June 15, 2014 Permalink | Log in to Reply

        If you remove the symlink from one install, it won’t impact the others.

        DB changes… should be fine, since the plugin would detect in each install where it’s called what needs to happen.

    • ThreadPasser 6:44 pm on June 15, 2014 Permalink | Log in to Reply

      Thanks for your response, that’s clear (about the DB changes).

      About the symlinks: if an unaware client clicks “uninstall plugin” from backend (just making up a possibly bad scenario), does the wordpress framework automatically detect that it’s a symlink or does it completely uninstall the targetted directory?

    • ScreenfeedFr 3:10 pm on June 25, 2014 Permalink | Log in to Reply

      I’m trying this out and this is great.

      For MU Plugins with the loader file, there’s still a problem: `plugin_dir_url()` won’t work :(

  • Jen 10:44 pm on August 18, 2012 Permalink
    Tags: , , plugins   

    In the better late than never category: notes about plugins from core team meetup in December! https://make.wordpress.org/plugins/2012/08/18/93/

     
  • Andrew Ozz 3:50 am on August 11, 2012 Permalink
    Tags: plugins   

    A bunch of unused images were removed from core in changeset 21498. Several of them were background gradients that were replaced with CSS 3 gradients. The rest have been unused in core for few releases.

    However there are some plugins that use a few of these images and would need updating. Best thing to do would be to copy the images locally as that makes a plugin independent from core changes. If the images were gradients, best would be to use CSS 3 gradients (example).

     
  • Andrew Nacin 3:33 pm on May 21, 2012 Permalink
    Tags: , plugins   

    On Saturday, Matt posted to the WordPress Blog that the plugin directory has been refreshed.

    Also also posted to our new P2 at make.wordpress.org/plugins: what this means for developers. @otto42, @coffee2code, and I go through the changes in detail. They include:

    • The new Developers and Support tabs for plugins
    • Subscribing to commit emails (Hint: see the Developers tab)
    • Following and managing support threads
    • How the new support statics are calculated

    (Sidebar: We hope to use make.wordpress.org/plugins for announcements and resources for plugin developers. This blog will also move to make.wordpress.org soon. More to come.)

     
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