WordPress.org

Ready to get started?Download WordPress

Make WordPress Core

Tagged: plugins Toggle Comment Threads | Keyboard Shortcuts

  • Andrew Nacin 7:11 pm on August 21, 2014 Permalink | Log in to leave a Comment
    Tags: plugins, upgrade install   

    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 | Log in to leave a Comment
    Tags: plugins   

    Improving the Plugins Page: Follow-up 

    Following up on this earlier post: http://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/http://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: http://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 (http://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 | Log in to leave a Comment
    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 http://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 Mylo 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! http://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.)

     
  • Andrew Nacin 2:57 am on June 22, 2011 Permalink
    Tags: plugins, ,   

    Plugin committers now receive svn notify emails with every commit to their plugin. This is something we’ve been planning to do to assist with collaboration, but we added it today without extra things like being able to sign up for other plugins. (Look for that soon, though.)

    And not to sound like the PA in a subway or at an airport, but if you see something, say something. Say things to security@wordpress.org.

     
  • Andrew Nacin 12:10 am on June 22, 2011 Permalink
    Tags: plugins, ,   

    Commit access has been restored for plugins. If you get a 403 error, you need to go reset your password. Please, to something new.

     
  • Samuel Wood (Otto) 10:18 pm on December 22, 2010 Permalink
    Tags: , plugins,   

    It was pointed out to me that I never mentioned it anywhere when I made this change last month, but the plugin search engine at http://wordpress.org/extend/plugins/ has been much improved. So now when you search for things like “buddypress”, you should get what you’re looking for on the first page of results more often.

    It was a minor adjustment, so it didn’t occur to me to tell anybody. Sorry about that. :)

     
    • Valentinas 10:45 pm on December 22, 2010 Permalink | Log in to Reply

      Well try to search for ad-minister. Other search strings to test: wp-e-commerce, wp-ad-manager, basically anything that has wp prefix will produce the same search results. And you know there’s plenty of plugins with that prefix.

      • Otto 10:58 pm on December 22, 2010 Permalink | Log in to Reply

        The search engine treats dashes as search operators. Meaning foo-bar searches for items containg foo but NOT bar.

        Leave out the dashes when searching, for now.

        • Jane Wells 5:03 am on December 23, 2010 Permalink | Log in to Reply

          Maybe drop a text instruction to that effect on the plugins search page? People search for wp e-commerce all the time.

        • Otto 12:25 pm on December 23, 2010 Permalink | Log in to Reply

          Jane: I was planning on just fixing it so it didn’t do that, actually. Nacin’s idea was the same one I was planning on implementing.

        • Otto 1:05 pm on December 23, 2010 Permalink | Log in to Reply

          Done. Hyphens now get escaped properly for the search when they don’t have spaces around them. So “e-commerce” will actually search for that as a word instead of considering it to be a control character. You can still use a hyphen in front of a word for exclusion, as long as it doesn’t have some other word character in front of the hyphen.

      • Andrew Nacin 12:03 am on December 23, 2010 Permalink | Log in to Reply

        We can probably make it convert hyphens into spaces if the hyphen isn’t preceded by a space. I’ll check it out.

    • Bill Erickson 12:49 am on December 23, 2010 Permalink | Log in to Reply

      When I search for Contact Form 7, the plugin shows up on the second page, even though I search for its exact name. This has been bugging me for about a month :)

      • Otto 1:47 am on December 23, 2010 Permalink | Log in to Reply

        Yep. But, that’s a pretty generic title too. I didn’t say it was perfect, just better. :)

        • Jane Wells 5:03 am on December 23, 2010 Permalink | Log in to Reply

          Actually, I think it used to come up as one of the first results, so for that one it looks like a loss. There are a couple I can’t find by searching now. What was changed to the search/what’s it searching now? If there are things we can do to the plugin metadata or readme files or whatever to make them more findable with the new search, we can publicize it.

        • Otto 12:29 pm on December 23, 2010 Permalink | Log in to Reply

          Basically, I added extra weighting to the title, gave the tags a bit more weight, and turned on the “extended” matching mode, which makes it actually use the weights. Before it was in a simple text-only keyword search mode, which didn’t use any relevance or closeness matching at all.

          The thing is that “Contact Form” is a fairly generic name, and while it does give the title a lot of boosting, every single one of the results on the first two pages has “Contact Form” in its title.

        • Sergey Biryukov 3:25 pm on December 23, 2010 Permalink | Log in to Reply

          Perhaps if there’s an exact match, it can go first?

      • Valentinas 10:37 pm on December 23, 2010 Permalink | Log in to Reply

        Yes, I wanted suggest the same as Sergey, exact match should definitely be the first.

        • Otto 10:52 pm on December 23, 2010 Permalink | Log in to Reply

          Well, that’s not the easiest thing to do in the world. The question is what do you define as an exact match?

          The Sphinx search engine works based on phrase matching. Now, in the particular case of “Contact Form 7″, the 7 is pretty much being ignored because it’s too short. So we’re really talking about “Contact Form” here. Note that it doesn’t much matter even if we were talking about the full “Contact Form 7″ because several of the other plugins above it also have “Contact Form 7″ in their titles as well.

          And that’s the trick. The whole thing is based on a weighting algorithim. I gave titles a lot of weight specifically in order to push title matches up to the top, but in this case, all the ones that show up in the top 20 results have “Contact Form” in their titles. Several of them have “Contact Form 7″ in their titles as well, because they’re addons to it or what have you. So how is the search really supposed to know that “Contact Form 7″ is more important than “Contact Form 7 Addon”? Sphinx doesn’t give extra weight to “whole” titles.

          I also give a bit of extra weight to tags, which is probably why some of those are coming up a bit higher than others. The relevance scores are all pretty close right there.

          Basically, doing exact whole-phrase matches in Sphinx is kind of a hacky PITA, involving adding extra data to the database using delimiters for before and after and such. I’d prefer to get the 90% solution where people are searching for keywords and titles and having it get close-enough rather than adding a ton of extra data just to cover that one particular case. Especially when the case involves a really generic title like “Contact Form”.

          So Protip for code authors: Come up with a unique name to be listed higher in searches. This is not specific to our search engine.

        • Matt 10:57 pm on December 23, 2010 Permalink | Log in to Reply

          We’re not really discussing matching, but ranking. I think it’s fair to, given the results that Sphinx returns, re-order based on a metric like popularity or bump exact match (search == title) to the top.

        • Otto 10:59 pm on December 23, 2010 Permalink | Log in to Reply

          Popularity ordering is already there if somebody wants to use it: http://wordpress.org/extend/plugins/search.php?q=Contact+Form+7&sort=popular

        • Matt 11:01 pm on December 23, 2010 Permalink | Log in to Reply

          I guess it’s odd to me that popularity and rating are not part of relevance — if you think outside of the strict-matching sense of relevance, they’re all really one and the same. Whichever provides the best results to the most people should just be the default.

        • Otto 11:11 pm on December 23, 2010 Permalink | Log in to Reply

          Ordering by rating is already there too: http://wordpress.org/extend/plugins/search.php?q=Contact+Form+7&sort=top-rated

          But I find the other side of this odd, really. It doesn’t make a whole lot of sense to me that popularity and rating have anything to do with relevance. Relevance is really more a measure of how well the plugin’s description/name/tags/whatever fits the keywords/phrase you’re searching for. In other words, relevance is about the plugin itself and your search query, not about user-generated meta data about the plugin like popularity or ratings.

          Could we include rating and popularity as a metric? Probably, but I’d have to investigate Sphinx in more depth. Those fields are not stored in the Sphinx database right now for sure, so it can’t include them in the relevance matching algorithm.

        • Otto 11:14 pm on December 23, 2010 Permalink | Log in to Reply

          Scratch that, they are in there (rating and downloads over the last week), so they can be used. I’ll do some testing, see if it makes any difference.

        • Matt 11:16 pm on December 23, 2010 Permalink | Log in to Reply

          I don’t think most people think of relevance that way. The core bug is you type in the name of one of the top ten most used plugins in the world and it doesn’t come up in the first page.

          Type “akismet” and Akismet is #5.

          Type “stats” and you see a page with 2 results, and 40 pages. (The counting/paging bug mentioned.)

          My goal is to not give people multiple ranking options for the plugin search, just to have one that always gives you the results you’re looking for.

        • Otto 11:19 pm on December 23, 2010 Permalink | Log in to Reply

          Yes, but everything is a tradeoff. At what cost do we bump more popular plugins? The cost is that less popular, but possibly better or more useful, plugins get bumped down.

          Moving exact whole-title matches to the top is one thing (technically tricky, actually, but doable), but counting popularity and rating in seems different to me.

        • Andy Skelton 11:25 pm on December 23, 2010 Permalink | Log in to Reply

          Stats and Akismet are good test cases. Almost any plugin can legitimately use the word “stats” in its description and many could reference Akismet, but a title including such words indicates extreme relevance. Titles are always more relevant than descriptions.

        • Otto 11:27 pm on December 23, 2010 Permalink | Log in to Reply

          This is the problem with generic phrases. “stats” has 591 results over 74 pages, and the first several dozen (at least) have the word “stats” in their titles.

          I’m doing more testing/tweaking to it now.

        • Otto 11:29 pm on December 23, 2010 Permalink | Log in to Reply

          Also, the title of the plugin is actually “WordPress.com Stats”, so an exact matching check wouldn’t help it out there for “stats” anyway. Slugs are not included in the search system at all.

        • Otto 12:13 am on December 24, 2010 Permalink | Log in to Reply

          Still looking at how to bump an exact title match to the top (this requires bypassing the search engine results to make it work), but after looking at the weights, I can at least tell you some specifics of why you see the results you see.

          Akismet is 5th because the other 4 above it include “Akismet” as a tag. So they get bumped for that.

          WordPress.com Stats: Same problem. The ones above it have tags with “stats” in them.

        • Andy Skelton 1:19 am on December 24, 2010 Permalink | Log in to Reply

          WordPress.com Stats has “stats” as a tag.

        • Valentinas 3:33 am on December 24, 2010 Permalink | Log in to Reply

          Some thought on why akismet should be first:

          Download count (maybe take into account how many copies were downloaded recently). So up to 10.000 downloads – 0%, 10k-100k: 0.1%, 100k-1m: 1%, 1M-10M: 10% and so on..
          Vote count (probably the same as download count, just different numbers, 100 votes – 1%, 500 votes – 10% and so on)
          Vote value (only take into account if has 50 or more votes): 1 star: -10%,2: -5%, 3: 0%, 4: +5%, 5L +10%.

          compactability (also only take into account if 10 or more votes)….

          and so on..
          I think these properties are good way to tell if the plugin is good or not. So by combining them with relevance you should be able to get good results. Of course this kind of stuff requires fine tuning..

          As Matt mentioned, you should test the search engine with top plugins. also do you have analytics running on plugins directory? would be a good idea to look at what keywords brings people to certain plugins and test with them.

        • Peter Westwood 7:53 am on December 24, 2010 Permalink | Log in to Reply

          To me the preferences for sorting would be:

          1. Exact Match in Title
          2. Order by install count / rating – download count is meaningless to me as it is too easily affected by having 100s of plugins release versions for minor buglets

        • jb510 8:57 am on December 24, 2010 Permalink | Log in to Reply

          Thinking a little outside the box, Otto is right each search category (rel, new, upd, pop, rating) is there, but what I really want is the ability to combine those types of search. I want the radio buttons to be check boxes so I can search for “relevance” AND “popularity”.

          Also, I wonder if you couldn’t add the abilty to search for exact name matches by entering the plugin name in quotes, ie. “Contact Form 7″?

        • Valentinas 9:23 am on December 24, 2010 Permalink | Log in to Reply

          jb510, that would be useful for advanced user, but what i’d like to have is something like Google (I think we can agree, that Google is an example of good search :) ). You don’t have any “popularity” or “relevance” or anything in Google, all you do is enter the name ( like before mentioned “contact form 7″) and you get the result. Google sells their search engine ( http://www.google.com/enterprise/search/mini.html ), but that may be not an option for WP, since it’s quite expensive (starts from $3000).

          Other than that idea about ability to search for exact name sounds pretty good (maybe even with a fallback to regular search informing the user about that – “we couldn’t find exact match for your query, but here’s some similar results”).

        • Otto 11:11 pm on December 29, 2010 Permalink | Log in to Reply

          Exact name/slug matches (or fairly close) now get bumped to the top of search results.

          In doing this, I discovered a case where results can be duplicated as well. it’s been there a while, but nobody noticed. That will take more time to figure out how to clean up.

        • Otto 10:30 pm on January 4, 2011 Permalink | Log in to Reply

          Duplicate search results removed. These were rare, but they’re gone now.

    • Rich Pedley 8:15 am on December 23, 2010 Permalink | Log in to Reply

      either the number of search results is still incorrect, or we are missing page links.

      • Otto 12:38 pm on December 23, 2010 Permalink | Log in to Reply

        The page links code was slightly off. It didn’t have the correct number set for its “per_page” count, so it had the wrong number of pages. I’ve corrected it.

        • Rich Pedley 3:26 pm on December 23, 2010 Permalink | Log in to Reply

          nope still broke. search for eshop:
          Showing 1-6 of 10 plugins with 6 displayed
          page shows 9-9 of 10 plugins , and only 1 displayed

          and why 6 per page, seems a weird amount.

        • Rich Pedley 3:28 pm on December 23, 2010 Permalink | Log in to Reply

          sorry that should have been page 2 shows 9-9etc

        • Otto 3:30 pm on December 23, 2010 Permalink | Log in to Reply

          I don’t know what you’re seeing, but for “eshop” it shows me 1-8 out of 10, with 2 pages. Works properly.

        • Otto 3:33 pm on December 23, 2010 Permalink | Log in to Reply

          Ahh, okay, actually you’re seeing different results because you are not an admin who can see the hidden plugins. Basically those are plugins that have been entered and approved but which no code has been uploaded for them yet. So they are getting removed from your display, but not from the total count.

          I’ll look closer at fixing that. But the normal display is 8 per page. If you see less, then the search is finding “unfinished” plugins then hiding them.

        • Rich Pedley 10:59 am on December 24, 2010 Permalink | Log in to Reply

          Yeah that would explain it – but won’t help others ;) Majority of people searching are not admins.

          and even so, 8 per page seems weird, can’t you bump it to 10? or is there some reason that octal rather than decimal is being used? Or even better a drop down selection to show 10/25/50 per page.

        • Rich Pedley 12:59 pm on January 3, 2011 Permalink | Log in to Reply

          a search for directorypress is returning this in the results:
          http://wordpress.org/extend/plugins/directorypress/
          but that plugin no longer exists, so I’m guessing it got removed. But it’s still being found when searching.

        • Otto 7:51 pm on January 3, 2011 Permalink | Log in to Reply

          Fixed. Numbers for searches are still going to be a bit off though. Working on it.

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