WordPress.org

Ready to get started?Download WordPress

Make WordPress Core

Updates from April, 2014 Toggle Comment Threads | Keyboard Shortcuts

  • Helen Hou-Sandi 9:44 pm on June 1, 2014 Permalink | Log in to leave a Comment
    Tags: ,   

    Summary of 5/28 dev chat (IRC log):

    • @nacin and @tellyworth have been working on the .org API side for i18n and plugins page improvements respectively and should be ready for work on the core side soon. Be on the lookout for tickets and discussions.
    • @ericlewis has been working through the Media component in Trac and will be holding weekly scrub in #wordpress-dev alongside media grid chats, Fridays at 17:00 UTC.
    • @wonderboymusic has been evaluating various oEmbed endpoints as we add and remove them. Some services need some more evaluation: #28379.
    • Embed representations in wpview need an iframe sandboxing solution investigated to avoid script conflicts inside TinyMCE and the admin: #28249
    • The JSON REST API came a long way in the past week, especially on the documentation front, and is being placed onto the roadmap for the 4.1 release. From @nacin:

    1.0 is a great step in the right direction; let’s push it hard; let’s put it squarely, loudly, and officially on the 4.1 roadmap (I’m comfortable doing that); let’s get a lot of core contributors focusing on it for the final mile, especially when it comes to internals

    let’s get a lot of people to build things on it, including inside automattic, mobile apps, even wordpress.org stuff; let’s branch off 1.0 so we can decide paint and carpet colors on the master branch

    •  And finally, several people were added to various Trac components as component maintainers. You can be added at any time, or get on the road to becoming one by signing up for granular notifications on the components page.
     
    • Eric Andrew Lewis 10:35 pm on June 1, 2014 Permalink | Log in to Reply

      I think component maintainer gravatars should be surfaced to the components page, so we can see the core community at a glance rather than clickering into each.

  • Helen Hou-Sandi 7:16 pm on May 28, 2014 Permalink | Log in to leave a Comment
    Tags: , ,   

    Summary for 5/21, Agenda for 5/28 

    Summary of 5/21 dev chat (IRC log):

    General

    • Posts like the i18n goals one serve as a great model for anybody who has ideas for a feature or component roadmap, whether that’s within one cycle or longer term: a list of concrete goals that can be divided up into specific tasks.
    • The make/* blogs should be used as much as possible for discussions and progress updates. Teams that have been using separate P2s but should consider using the make.wordpress.org instead for wider reach and more active participation from the community.
    • Keep in mind that plugins are supposed to encourage rapid and possibly wild experimentation – please do not discourage that.
    • Think of meetings as blocked out times where you can more reliably get a group together and get unstuck as needed, but we should take advantage of async (Trac, P2) and adhoc (IRC outside of meeting) discussion as much as possible.

    Team Updates

    • i18n goals for 4.0 have been posted, @nacin is seeking people to help with a lot of it. @yoavf, @kovshenin, @iandunn, @coffee2code, and @otto42 have done or will do some of the i18n tasks.
    • JSON REST API was given another week to collate a detailed compare-and-contrast with the other available APIs, including the JSON API plugin and Jetpack/.com’s API, and proven client implementations.
    • Media Grid has a narrowed scope for 4.0 inclusion: something more visually driven than the standard list table, much like theme browser brought to themes and is being investigated for plugins in 4.0. Will also fix some long-standing issues that were brought in with 3.5.
    • Editor improvement ideas: @markjaquith and @avryl have put together a proof-of-concept plugin that we should smooth out and make a decision on.

    Agenda for 5/28:

    • Make final decision on JSON REST API.
    • One sentence updates from various groups – i18n, media grid, plugins, oEmbed, etc. Come prepared.

    Please propose any other agenda items in the comments below.

     
  • Alex Shiels 10:56 am on May 28, 2014 Permalink | Log in to leave a Comment
    Tags:   

    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.

  • Andrew Nacin 7:41 pm on May 21, 2014 Permalink | Log in to leave a Comment
    Tags: ,   

    Internationalization goals for 4.0 

    Every few releases we’ve made a major push for improved internationalization. In 3.7, that was laying the groundwork for plugin and theme language packs (more on that soon). In 3.4, it was reducing all of the customizations that many localization teams needed to make. (There’s a page on that here.) In 4.0, I’d like to close the loop on a lot of this. Here’s what I’d like to accomplish, and I’ll need a lot of help.

    1. The first step installing WordPress should be to choose a language. The rest of the install process would then be in that language.
    2. You should be able to choose/switch a language from the general settings screen, after which the language pack should be downloaded.
    3. You should be able to search from the dashboard for plugins and themes that are available in your language.
    4. All localized packages should be able to be automatically generated and made available immediately as part of the core release process.
    5. Localized packages should only be used for initial downloads from WordPress.org. Instead, language packs should be transparently used for updates.

    That’s the what. The how poses extensive challenges.

    1) Choosing a language when installing WordPress. The rest of the install process would then be in that language.

    osx-language

    Want.

    Split workflows: One issue that came up in #26879 (“friendlier welcome when installing WordPress”) is that setup-config.php is often not the initial entry point. A user installing WordPress through a hosting control panel is likely to be dumped onto the install screen (if not the dashboard directly).

    Thus, we need to keep in mind that either screen might be the “intro” screen. This introduces technical challenges: If the user’s first step is setup-config.php, we don’t actually have WordPress fully loaded at this point, which makes actually installing a language pack more difficult. The install step has WordPress loaded in full, just without database tables. We should look into making setup-config.php load “all” of WordPress to make these environments easier to code.

    Different approaches: There are two different ways to approach this: download language files immediately upon selection, or bundle barebones language files of the install screens for all supported languages. The latter is not the easiest thing to do (due to error messages and such, strings can come from all over) and also adds a delay to the adoption of new languages. The former would mean that we would want to pull a languages list from WordPress.org. (If we cannot reach WordPress.org, we would have no way of downloading the complete language pack, so this is not a big deal.) It’s still a bit of a challenge due to the split workflows problem.

    Recommending a particular language: WordPress.org already recommends a language based on the browser’s settings (Accept-Language header) as well as using a more rough lookup based on IP address blocks. (HTML5 location could be used, but unless we’re also going to use that to set the user’s timezone, it seems excessive for a “choose your language” for the moment, especially since location is not as preferred anyway.)

    Both would require the client to hit WordPress.org via JavaScript, versus a server HTTP request. We can do a server-side HTTP request to generate the list, then a client-side request to float recommended ones to the top. It’s possible to do it in two steps: the Accept-Language mapping can be done locally, while the IP-to-location table on WordPress.org has 2.9 million entries and would require a round-trip. Of course, if a user has downloaded a localized package directly from a local WordPress.org site, that would be the top recommendation.

    Note that by language or locale we also must consider other translation variants, as there may be a language like Portuguese available in multiple locales (Brazil, Portugal) and further broken down by formal and informal variants. Each of these would be listed as their own “language.” c.f. #28303

    2) You should be able to choose/switch a language from the general settings screen, after which the language pack should be downloaded.

    WordPress MU had this feature and it still exists in multisite (though it’s pretty broken in terms of how it handles locales, #13069, #15677, #19760). This however only worked for already installed locales.

    For single-site, the available languages should be fetched from WordPress.org and cached in a transient. (#13069 suggests using the GlotPress locale list, but as indicated above, we’d want to handle newly added or updated languages. This can then be displayed in a dropdown on the General Settings page. Upon selection and “Save Changes,” the language pack would be downloaded and enabled. We would likely use the oddly named “WPLANG” option since it’s what MU adopted and uses at both the site and network levels.

    If we can’t reach WordPress.org, or if a filter is applied, then only installed languages will be listed. (An untrusted multisite network will likely have a default filter in place, to match existing behavior.) We should try to cache failures to .org (generally — not just here) so things aren’t terribly slow when developing a site without internet. We could possibly lazy-fetch the list only when the user expands the dropdown (or clicks a “Change” link or something).

    Note this does not address two situations in particular: user-specific languages, or using the dashboard in English. These will be easier to do thanks to improvements in 4.0, but there still exist a number of edge cases where persistent translations can “bleed” into other situations. Examples include a comment moderation email being emailed to an English speaker but sent in the language of the logged-in commenter; or a string stored in the database like image metadata. When using a plugin, these are “edge cases.” When core adopts them, these become “bugs.” We will need to introduce a locale-switching method not unlike switch_to_blog() and also identify and work around any “persistence” issues. Not for 4.0, though we can get started on the groundwork.

    3) You should be able to search from the dashboard for plugins and themes that are available in your language.

    With language packs (more on that soon), plugins and themes will be able to be translated into any language. The goal would then be to have “localized” plugin and theme directories on the translated WordPress.org sites, listing just the plugins or themes available in their language. Note that even a plugin or theme without strings have a name and description that can be translated.

    The plugin and theme install screens in the dashboard should similarly gain this ability. In all cases, there would be an option to expand the search to plugins/themes available in any language, of course — along with the invitation to translate them.

    We will need to figure out how to make readme files translatable, which get parsed for the plugin directory (and eventually themes will gain these as well, possibly as part of these initiatives).

    4) All localized packages should be able to be automatically generated and made available immediately as part of the core release process.

    A localized package should merely consist of core WordPress plus a few translated files (the readme, the license, and the sample config file) and the PO/MO files. No other alterations should occur, which means translation teams will only need to translate, and builds can be automatically generated and made available immediately as part of the core release process.

    Local modifications. Before 3.4, every install needed to make modifications to WordPress as part of their localized package, whether by actually replacing core files or using a {$locale}.php file. By my audit, this now applies to only 14 locales.

    At the very least, we can allow the current system to work as-is for these locales. Ideally, though, we address the specific concerns of each locale and bring as many as possible into the fold. They include:

    • Some CSS modifications we can incorporate into core.
    • Workarounds for declension issues in a few locales, specifically regarding the names of months. #11226, also #21139, #24899, #22225
    • Adding major locale-specific oEmbed providers. #19980
    • Transliteration such as Romanization for Serbian. We can handle this by having two variants of Serbian, the way we have formal and informal European Portuguese. (But we’d automate these language packs, rather than forcing translations to happen twice.)
    • Significant changes in Uyghur (#19950), Farsi, Chinese, and Japanese (including the multibyte patch plugin).

    Additional concerns:

    License. Many locales also have an unofficial translation of the license. We should be able to collect any of these in a repository and include it automatically in a package. (Note that link is an explainer; no GPL version 2 translations are available from that page.)

    Readme. Some locales directly translate readme.html. Others add a second file and use one of two forms: the translated word “readme” (example: leame.html would be Spanish) or using a suffix (“readme-ja.html” for Japanese). We should standardize this somehow. Technically the readme changes with each version due to the version bump, but we can automate that. Bigger readme changes are fairly rare, but we’ll still need to figure out how to have these translated and tracked.

    wp-config-sample.php. This one is especially interesting. If a user has chosen a language on install, we don’t need the readme or license but we do need this file, as setup-config.php will display its contents in a textarea if we’re unable to write the file. We can store this file as a single translated string in a PO/MO file (in some automated fashion) or as part of the API response. We will also need some kind of way to translate and track this file to be included in localized packages that are downloaded.

    5) Localized packages should only be used for initial downloads from WordPress.org. Instead, language packs should be transparently used for updates.

    The WordPress.org API is set up to return a series of update “offers” — one of each type (“latest” a.k.a. reinstall, “update” and “autoupdate”), in both the site’s language and in English. This results in awkward double-upgrades even when no strings have been changed (updating first to English, then to the locale when it is available for that version) and is a lame experience. While auto-generating localized packages immediately will help, there’s no reason to actually use localized packages for updates. Any locale without local modifications can be set up as a language pack now.

    As of 3.7, WordPress core supports receiving instructions for language packs. We’d simply stop issuing localized package offers, start issuing language pack offers, and rip out some code on update-core.php that has been handling the multiple-offer dance. This is the easiest of the five 4.0 tasks but is dependent on the very complex fourth task.

    Next steps.

    Here’s an overall outline of the things we need to do. I’ll be creating relevant core and meta Trac tickets in the coming days, and I’ve also referenced a few related tickets I was able to find.

    Biggest problems to solve:

    • Figure out how to handle readmes, licenses, and wp-config-sample.php. This includes plugin (and theme) readmes as well. Remember we don’t want plugin developers to need to be involved in any way; and also that updates to these files will need to be handled elegantly (such that we have both ‘stable’ and ‘development’ tracks).
    • Eliminate all code modifications across all locales (as much as possible). Related, #20974.

    WordPress.org/API work:

    • Create an API for core to use to fetch available locales for download.
    • Create an API for core to use to recommend a locale based on browser settings/location.
    • Auto-generate localized packages and core language packs.
    • Serve core language packs for updates, not localized packages. Related: #23113, #27164, #26914, #27752.
    • Mirror the plugin and theme directories to locale sites, with full translations (including readme data) and with selective searching.

    Core work:

    • Add the ability to install a new language pack on demand.
    • Add a “switch to language” method, for languages that are installed. #26511
    • Add a screen that allows a locale to be chosen. May need to change how setup-config.php bootstraps WordPress.
    • Add a language chooser to the General Settings screen. #15677
    • Support searching for plugins/themes in a particular language, as well as leveraging translated data fields that come through from the API response. This mostly just means sending back the site’s language to WordPress.org. It also requires UI to reveal results from any languages. We could possibly filter/hide/show on the client side, if results were not paginated.
    • Take a machete to update-core.php’s localized build handling once everything else is done. Related: #25712, #28199.
     
    • MB Creation 7:47 pm on May 21, 2014 Permalink | Log in to Reply

      Evening Andrew,

      I think the what is awesome. I’ll try to think about and contribute to the how !
      Keep up the good work.

      Benoit

    • Charleston Software Associates 7:53 pm on May 21, 2014 Permalink | Log in to Reply

      Perfect timing!

      I am in the midst of testing an issue with my plugin that occurs when a user is not using English as the native language. Without boring anyone with the details, I found the need to quickly and easily switch from a native German to English version of WordPress to run through my test cycle for the upcoming patches. After the 4th edit of wp-config.php I was thinking “why the heck isn’t there a select language option on the General Settings of WordPress?”.

      Now I know why.

      I am going to talk to one of my lead contributors whom is my go-to “language issues” guy from the Netherlands and see what we can contribute to this endeavor. As I reach out to non-English-speaking customers this is an area we have been focusing on this year.

      Getting things like the up-front presentation, especially readme.txt, is probably the most prominent barrier to acceptance of the plugin in other languages.

      If we can continue the integration of things like WPML hooks, language files, and more localization hooks we may just be ready to attract more international users about the time 4.0 rolls out.

      Looking forward to bigger & better things with WordPress in the coming years!

    • Casey Driscoll 8:58 pm on May 21, 2014 Permalink | Log in to Reply

      This is really well done and thought out Nacin, nice work.

    • glueckpress 9:15 pm on May 21, 2014 Permalink | Log in to Reply

      Given this is huge already the question might be either out of scope, or of perfect timing: can we sneak a post language feature into 4.0? We’ve already been working on a plugin, the only thing is final implementation should happen in `WP_Post` which cannot be extended via plugin. Anyway, here’s what we’ve come up with so far. https://github.com/glueckpress/wordpress-post-language

      Regarding contributions to the roadmap above I’ll be happy to pitch this for the WordCamp Hamburg Contributor Day; as it looks like there’s going to be multipersonal unique language intelligence available.

      • Andrew Nacin 9:56 pm on May 21, 2014 Permalink | Log in to Reply

        I don’t see this as part of 4.0’s roadmap. It’s in the same boat as other things I mentioned like per-user languages, having the dashboard in English, and the like. For the moment, it’s a bit of a case of “cart before the horse,” but I think it makes a great plugin for now and could be considered for inclusion once we’re farther along.

    • terraling 9:21 pm on May 21, 2014 Permalink | Log in to Reply

      Hi Andrew

      Great to hear that internationalization will be getting so much attention with 4.0, but… (there is always a but).

      As is, it is nigh on impossible to make a multilingual site with WordPress. You can have a WordPress install in any language you like, as long as it’s only one language.

      Of course you can, as I have, customise wp-config.php or use plug-ins so that different users can see content on the front-end in different languages, but it’s only surface deep.

      Have someone write a post in English and then someone else who views the site in Spanish comment in pigeon-English on the post, the post author will receive the comment notification email in Spanish.

      It’s as if someone Polish sends you a friend request on facebook and the request email comes through in Polish. (And this is exactly what happens if you set up a multilingual BuddyPress site. Speaking with the developers they say it is pretty much impossible to fix without changes to WP core.)

      I’m not qualified to help make those changes, I’m afraid, but I think they are as important as the steps you’ve outlined above.

      • glueckpress 9:33 pm on May 21, 2014 Permalink | Log in to Reply

        Just think of the possibilities opened by a simple select box that sets a post as being written in a given language … now I’ll quit spamming. ;)

      • Andrew Nacin 9:50 pm on May 21, 2014 Permalink | Log in to Reply

        This post extensively covers this under task #2. See the final paragraph in that section.

        • terraling 8:05 am on May 22, 2014 Permalink | Log in to Reply

          Sorry Andrew, not sure how I missed those details.

          It requires storing a default language setting for each user. Rather than individual plug-ins producing their own solution, it would be great if the where and how could be standardised in core.

          • Andrew Nacin 3:54 pm on May 22, 2014 Permalink | Log in to Reply

            As indicated in the post, there are a lot of issues with doing this for now. If a plugin does it, it’s safe to call them “edge cases,” but once core does it, those edge cases become “bugs.” We would need to fix a number of issues of persistence and context before doing anything in core.

    • michalzuber 3:35 am on May 22, 2014 Permalink | Log in to Reply

      Wow, great. Like the first and second step. How much time did it take to write this, did you have a draft and worked on it? :)

      • Andrew Nacin 3:53 pm on May 22, 2014 Permalink | Log in to Reply

        It took about two or three hours to write, but of course we’ve been thinking about these problems for a long time.

    • Rami Yushuvaev 7:37 am on May 22, 2014 Permalink | Log in to Reply

      Nacin, the readme changes with each version due to the version bump is unnecessary. You need to remove the version number from the readme file.

      • Mike Manger 11:02 am on May 22, 2014 Permalink | Log in to Reply

        I think including the version number gives some context to the system requirements and update instructions for the specific version (“If you are updating from version 2.7 or higher”, PHP 5.2.4 is required for version 3.9).

      • Andrew Nacin 3:50 pm on May 22, 2014 Permalink | Log in to Reply

        As indicated in the post, “Technically the readme changes with each version due to the version bump, but we can automate that.” We should keep the version number but make it unnecessary for you to update it.

    • Fernandot 6:02 pm on May 22, 2014 Permalink | Log in to Reply

      Great, great, great!

      and … 

      GREAT!

      This have been one of my everlasting wishes :)

    • Mariano Perez 6:30 am on May 23, 2014 Permalink | Log in to Reply

      This will bring the software to a higher level. Great decision.

    • Paal Joachim Romdahl 11:04 am on May 23, 2014 Permalink | Log in to Reply

      Thank you for sharing Andrew! In this process are there plans on having the default WordPress phrases on the frontend also change depending on language selected?

      • Andrew Nacin 5:22 pm on May 23, 2014 Permalink | Log in to Reply

        I’m not sure what this is referring to… But yes, the language selection would be equivalent to the WPLANG constant — it would apply to everything (themes, plugins, core; dashboard, frontend).

    • niknetniko 10:14 am on May 24, 2014 Permalink | Log in to Reply

      This is all very nice!

      I have a little question: you’re going to make WordPress download the correct languages pack when the user chooses a language, so: will this apply to plugins as well?

      If you download a plugin from within the WordPress admin area, would it be possible to only download the correct language pack with it?

      For example, if my WordPress installation is in Dutch and I install a plugin, it would download the plugin and only the Dutch language files. The same would happen when you change the language from the options.

    • Nashwan Doaqan 2:10 pm on May 25, 2014 Permalink | Log in to Reply

      Great!! .. Good News!! :)
      I will be happy to help you on this..

    • Charles Frees-Melvin 1:24 am on May 26, 2014 Permalink | Log in to Reply

      When dealing with plugins or themes and localizations. It should be added to a GlotPress entry that can be set, to list the fall back language if the prefered localization is not available for the plugin or theme. Like for en_CA to use a en_UK or en_AU before settling with an en_US. Or a pt_BR to settle on using a pt_PT if it exists.

    • Misamee 6:06 am on May 27, 2014 Permalink | Log in to Reply

      Thanks Nacin: the whole post sounds really intriguing!

      I’m working on WPML development and I’d like to keep an eye on three of these changes in particular.

      1. The first step installing WordPress should be to choose a language. The rest of the install process would then be in that language.
      2. You should be able to choose/switch a language from the general settings screen, after which the language pack should be downloaded.
      3. [...] language packs should be transparently used for updates.

      As for the first and second points, we may use the WPLANG value as a default language, if define (something that we don’t currently do now).
      Each time this value get changed, WPML would need to know it: I suppose than a simple action would be enough for WPML to get the new information, and set it as a default language, rather than continuously checking if WPLANG got changed.

      As for the third point, if the core, a plugin or a theme gets a new language or an updated language, WPML could use this information (e.g. when user select to handle translations via WPML, rather than via po/mo files). Again, an action would be really helpful.
      Unlike the previous action, here I’m imagining something a bit more specific:

      // string $context: ‘core’ | ‘theme’ | ‘plugin’
      // mixed $data: null | plugin or theme data
      add_action(‘language_pack_downloaded’, $context, $language_code, $data);

      Of course, these are just suggestions: anything that could provide the information that a language pack got downloaded should be enough.

      By the way, there is any way to get all trac items related to the internationalisation changes in 4.0?

    • Amit Kvint 4:22 pm on June 1, 2014 Permalink | Log in to Reply

      Great work, looking forward to enjoying it.

    • Kaspars 8:17 am on June 3, 2014 Permalink | Log in to Reply

      I think you meant localization (l10n) instead of internationalization (i18n).

      • Andrew Nacin 1:12 pm on June 3, 2014 Permalink | Log in to Reply

        Well, it’s a mix. Generally, software does internationalization and translators do localization, as also indicated in the article you linked. Some of our work here does involve making changes to how WordPress is localized (such as integrating locale-specific tweaks) but for the most part internationalization is what’s happening here — making changes so it can later be localized.

    • Torsten Landsiedel 2:25 pm on June 4, 2014 Permalink | Log in to Reply

      @nacin: It would be great if someone have a look at this ticket for WordPress 4.0 again: https://core.trac.wordpress.org/ticket/17268
      This would be really awesome and important for non-english WordPress sites.

    • sonjanyc 10:10 pm on June 9, 2014 Permalink | Log in to Reply

      I’m happy to help with design for this (UI/UX)! After talking to @nacin yesterday, I’ve started working on wireframes and mockups. I’ve put together the flow for the installation process (both for manual WordPress install and 1-click-install).
      Installation flow: http://sonjaleix.com/wp-content/uploads/2014/06/i18n_W4.0_v0.1_flow.jpg

      Ideally we ask the user in the first step of the installation process to choose his/her language so the installation process is already translated. I’m not sure from a dev point of view if we can already install/download the language pack in that stage, but if not, we should at least have all installation screens translated.

      Since we have 135 languages (current list), the dropdown will be pretty long. I like the way apple translated the “Call-to-Action” in the example @nacin posted above, but I think it will be easier for the user to find and select his/her language, if the dropdown list only contains the names of languages. Hence see attached initial mockup.

      Mockup 1: http://sonjaleix.com/wp-content/uploads/2014/06/wp-install_language_select-1.jpg
      Mockup 2: http://sonjaleix.com/wp-content/uploads/2014/06/wp-install_language_select-2.jpg

      Looking forward to getting some feedback.

    • lonchbox 6:20 pm on June 10, 2014 Permalink | Log in to Reply

      This sounds great! :D, also think this option will give us a more accurate data of the real language usage of WordPress. Because most of the spanish language sites use english core :)

    • sonjanyc 1:50 am on June 25, 2014 Permalink | Log in to Reply

      @nacin Let me know how I can help pushing this forward on the UX/UI front. Is there a ticket in track for this or all conversation here so far?

    • Victor J. Quesada 8:53 pm on August 6, 2014 Permalink | Log in to Reply

      nice. great!

  • Helen Hou-Sandi 2:48 am on May 9, 2014 Permalink | Log in to leave a Comment
    Tags: ,   

    Summary of 5/7 dev chat (IRC log):

    Proposed 4.0 ideas

    • Multisite enhancements: SSL, get site creation/editing UIs in line with the arbitrary domain/path support. Planning on weekly office hours.
    • Mobile experience: media modal and upload flow, Press This feature plugin.
    • oEmbed discoverability, usability, and caching improvements.
    • Widgets: JS API (#28093)
    • Taxonomy roadmap, part one.
    • Background images in the customizer.
    • Plugin installer improvements: better search and more information (needs .org API support), upgrading a plugin or theme via zip upload (#19641)
    • Export API improvements/overhaul (#22435)
    • Post meta: support for revisions (#20564)
    • APIs for posts/comment types/statuses. Ping @nacin if interested in collaborating (#12706).
    • Continuous a11y enhancements, particularly in the media modal.
    • Texturize patches, continuing on performance enhancements and bugfixes in 3.9.

    If you are interested in any of the above, sound off in the comments below.

    Potential themes for the release:

    • More visual cues in the admin for user tasks, as has been done for themes.
    • Continuing to improve the editing and media experiences.
    • Lots of under the hood things and API attention to make devs happy.

    Feature Plugins

    • Front-end Editor looks like it’ll continue past 4.0, as enabled by being a feature as a plugin, but we should continuously keep an eye on it and see what improvements can be brought into core sooner.
    • Media Grid View and Press This are under way.
    • WP API continues to move forward.

    Patches needing early dev attention

    • #17689: Terms should not be sanitized inside term_exists(). This is the first step in moving along with the taxonomy roadmap, so please look here if this has been of interest to you. Potentially needs more unit tests. Thanks to @aaroncampbell for the latest patch.
    • #14759: Improve the way oEmbed deals with caching (patch from @markjaquith).

    And finally, 3.9.1 is out now, if you haven’t already updated or been updated.

     
    • Schwarttzy 5:21 am on May 9, 2014 Permalink | Log in to Reply

      How about featured background images?

    • Florian Girardey 7:51 am on May 9, 2014 Permalink | Log in to Reply

      How about better UI for Header images ?

    • helgatheviking 7:55 am on May 9, 2014 Permalink | Log in to Reply

      More admin filter/hooks everywhere! And love for the quick edit.

    • RicaNeaga 9:49 am on May 9, 2014 Permalink | Log in to Reply

      Here’s what the roadmap looks like for Cpanel, from here… http://features.cpanel.net/responses/as-a-server-administrator-i-want-mariadb-support-so-that-i-can-accomodate-both-innodb-and-noninnodb-users

      ”1. We introduce MariaDB 10 with cPanel & WHM version 11.50

      2. In version 11.50 both MariaDB and MySQL are provided, and wholly supported, by cPanel

      3. With version 11.52 we announce that MySQL is considered deprecated, and will be removed in version 11.54

      4. With version 11.54 we no longer provide the MySQL RPMs.”

      So in ~ a year from now a major web hosting control panel is going to ship without any trace of MySQL. Then why not fully supporting MariaDB (10) in the next major release, 4.0, and include MariaDB (10) as an alternative for MySQL in the requirements page? http://wordpress.org/about/requirements/

      • Andrew Nacin 3:03 pm on May 9, 2014 Permalink | Log in to Reply

        WordPress already supports MariaDB, and has for a long time, since MariaDB is a compatible replacement for MySQL. We could put it in the requirements somewhere but it’s still pretty esoteric at this time.

        • RicaNeaga 5:33 pm on May 9, 2014 Permalink | Log in to Reply

          Thanks for the answer and info. MariaDB 10 however is a combination of MySQL 5.5 and 5.6, and with features of its own, it won’t be a 100% drop-in replacement for either of them (MySQL 5.5 or 5.6).

          So maybe it’s a good idea to make sure everything it’s ok, and put it in the requiremets after that. The sooner the better I think, it would make a statement that the wordpress project is also supporting MariaDB in the long run, alongside Google, CPanel, Plesk, RHEL and other major Linux distros.

          Right now I’m annoyed since I’d like to buy a managed server from Germany, and their control panel supports by default only MySQL and PostgreSQL. ”Spreading the word” about MariaDB hopefully would make others ”embrace the future” sooner :)

    • Jon Brown 4:55 am on May 10, 2014 Permalink | Log in to Reply

      I’m assuming the Metadata API/UI is still too far out to be considered for 4.0, but I’m going to cross my fingers and hope for it anyway: https://github.com/wordpress-metadata/metadata-ui-api/

      • Helen Hou-Sandi 6:39 pm on May 10, 2014 Permalink | Log in to Reply

        I would think of this as more of a working group that also happens to have a particular end goal in mind, and improvements can (and should be) ongoing. That end goal does not seem likely for 4.0 though, no.

    • Robert Chapin 4:03 pm on May 10, 2014 Permalink | Log in to Reply

      #10041 needs early dev attention. Come on guys. If we don’t do this now, the patch will go stale.

    • rajlaksh 7:25 am on May 13, 2014 Permalink | Log in to Reply

      what about categories like tags in new post page? so u have to enter category name then auto complete search :)

      Easy then scrolling 500+ categories.

  • Helen Hou-Sandi 8:30 pm on May 6, 2014 Permalink | Log in to leave a Comment
    Tags: ,   

    Summary of last week’s dev chat on 4/30 (IRC log):

    Announcements

    Features as plugins

    • Met on 4/29 (IRC log)
    • Current potential considerations seem to be WP API and media grid.
    • Press This is getting some attention from an early stages working group, which could also be a part of the 4.0 release.
    • Admin Help is poised to shift into more of a continuous testing and advisory group, which is awesome.
    • Front-end editor is making good progress, but has UX issues that are getting worked on, needs iteration and experimentation and probably won’t be ready by 4.0, but should continuously be worked on, as is the goal of features as plugins in the first place. Developers needed.

    Potential ideas and their suggesters:

    Summary: we have good things in mind about more media improvements, more editing experience improvements, more visual media grid and better plugin installer experience (following in the footsteps of themes), and behind the scenes wins in taxonomy, multisite, and post type and comment APIs.

    If you’re interested in any of the above or have other ideas, please sound off in the comments.

    Getting involved

    • We are always looking for more people to be involved with Trac gardening, patch review, patch writing, or some combination thereof.
    • Component pages are running well, and most could still use the caretaking of a component owner or somebody who’d like to become well-versed in a particular area of core. To get started, just sign up for component notifications at http://make.wordpress.org/core/notifications/. No need to be an expert now – learning and persistence is more important.To help with a specific plugin, join their weekly chats and/or follow along wherever they post. See the Features as Plugins page for more information.
    • A reminder from @matt to always be dogfooding the product – use WordPress every day.

    Bonus punnage, to the lead’s chagrin:

    > wonderboymusic will make a t-shirt for anyone who gets all 16 of those Cache tickets closed :)
    > sams: “Cache Master”?
    > wonderboymusic: Johnny Cache
    > jorbin: If you fix the Cache, you’ll get the Credit. That Checks out.
    > MarkJaquith: I’d put in a cache pun, but I don’t want to be sent to purgetory.
    > johnbillion: You would have to be a cache machine to fix all 16

     
  • Mike Schroder 5:33 am on April 24, 2014 Permalink
    Tags:   

    Last Week in WordPress Core 

    Hello there! This is Last Week in WordPress Core for the week of April 15-April 23. Happy release week, everyone! WordPress 3.9 “Smith” was released last Wednesday! Due to that, fewer commits this week. With a 3.9.1 maintenance release expected this week, changes up to tonight are included below.

    Widgets

    • Ensure widgets stay with themes during a theme switch. See [28124]. [28161] #27897
    • Run WP_Editors::enqueue_scripts() on admin_print_footer_scripts priority 1 (later), instead of admin_footer. Fixes incompatibility with the customizer. [28187] #27853
    • Remove create_function() from the customizer class to improve HHVM compatibility. [28143] #27805

    Theme Installer

    • Restore .zip theme installation by casting wp_count_attachments() before iterating it to avoid a notice when items exist without a mime type. [28139] #27802
    • Prevent customizer header image list from listing user images twice when no theme-specified images exist. [28152] #27839
    • Improved URL routing. [28141] [28147] #27055
    • Proper redirection and action links post-install in multisite. [28163] #27869

    TinyMCE

    • Update the TinyMCE tests to 4.0.21.1. [28138] #27744
    • Fix icons in IE7. [28142] #27829
    • Restore wordpress_adv_hidden editor parameter to enable force-showing the kitchen sink. [28181] #27963
    • Shrink the font size for the selected item in “Format” dropdown so that it fits in more locales. [28180] #27903
    • Fix the active state of the Link button when an image wrapped in a link is selected. [28185] #27847
    • Don’t trigger the drag-and-drop uploader when selected test is being dragged from one window to another. [28189] #27880
    • Correct positioning when adding a caption to an image that is in a paragraph with other text. [28190] #27922
    • Update the “paste” plugin to the latest development version to fix: [28192] #27909 #27771
      • Correct pasting of Excel tables.
      • Leave TOC Anchors intact during paste.

    Playlists

    • Improve styling and fix RTL for playlists. [28172] [28174] #27923; [28173] #27924
    • Alter the layout of the checkboxes in the modal view for Audio/Video Details to allow translations more room to breathe. [28184] #27893
    • Graceful failures for TinyMCE views of video/audio playlists. [28144] #27821
    • Add a compatibility layer in wp-playlist.js to avoid VM errors from MediaElement’s plugin bridge in the TinyMCE views to whitelist file types for native playback. [28171] #27892
    • Refinements for asynchronous rendering in wp.mce.media.PlaylistView. [28182] #27899
    • Keep <tracks> from being filtered out when switching between visual and text editors. [28183] #27915
    • Hide extra tracks field in media modal when adding subtitles. [28169] #27915

    Internals

    • Avoid a PHP warning during theme background-update checks when there are multiple theme directories registered. [28137] #27815
    • Properly gray out text fields when they are disabled or when they have the disabled class. [28179] #27906
    • Avoid counting all attachments when entering the post|page edit screens. [28191] #27985

    Thanks to @avryl, @azaozz, @bobbingwide, @celloexpressions, @dimadin, @feedmeastraycat, @gcorne, @helen, @jjeaton, @johnbillion, @kworthington, @lancewillett, @mcsf, @melchoyce, @nacin, @netweb, @ocean90, @SergeyBiryukov, @smashcut, @westonruter and @wonderboymusic for their help this week!

    For the complete list of commits to trunk, check out the log on Trac. We started talking about 4.0 plans this week in the weekly dev meeting. Come chat next Wednesday to continue the discussion, and note if you encounter issues with the new release on trac.

     
  • Mike Schroder 9:32 am on April 15, 2014 Permalink
    Tags:   

    Last Week in WordPress Core 

    Hello there! This is Last Week in WordPress Core for the week of April 8-April 14. Similar to last week, commits are included up to RC2, which was released today. In addition, maintenance releases 3.8.3 and 3.7.3 are available, and automatic updates are rolling out.

    Customizer

    • Widgets: Properly handle widget settings when activating a previewed theme. [28124] #27767
    • Widgets: Account for a sidebar with no container to which classes can be added. [28100] #27780
    • Custom Headers: Fix image ordering. [28102] #27791
    • Custom Headers: Fix cropping when working with large images. [28101] #27790
    • Add color scheme support for widget choosers. [28122] #27793

    Theme Installer

    • Improve route handling and make ?theme= work. [28123] #27708
    • Revert to proxying through PHP for WordPress.org API requests to ensure we have valid installation nonces. [28126] #27798

    TinyMCE

    • Update TinyMCE to 4.0.21.1. [28066] #27744
    • Update TinyMCE paste plugin to the latest development version. Improves Pasting from Word to remove inline comments and change tracking. [28089] #27771
    • Ensure vertical resizing and menubar show/hide are set to default for each TinyMCE instance. [28059] #27724
    • Stabilize MediaElement within TinyMCE, and avoid adding undo steps when the body of a wpView changes. [28084] #27389
    • Improve fallback compatibility for wpViews with IE7 and 8. [28062] [28063] #27546

    Media

    • In the Image Details modal, remember the last state of the advanced toggle. [28125] #27366
    • Add hooks for wpeditimage TinyMCE plugin and Image Details modal. Includes wp.media.events, which is intended to be a global media event bus. [28095] #27698
    • Apply new add_image_size() cropping preferences to all sizes when image is saved in editor. [28072] #19393
    • Fix tabbing out of the title field on Media->Edit Media screen. [28069] [28070] #27750

    Internals

    Externals

    For the complete list of commits to trunk, check out the log on Trac. Release is scheduled for this Wednesday, so, the best way to help is to test! Please let us know if you run into problems in the Alpha/Beta forums or on trac.

    Thanks to @azaozz, @dd32, @DrewAPicture, @ehg, @GaryJ, @gcorne, @helen, @jesin, @johnbillion, @kerikae, @kpdesign, @mattheu, @matveb, @melchoyce, @morganestes, @nacin, @ocean90, @Otto42, @pavelevap, @redsweater, @ryelle, @scottlee, @SergeyBiryukov, @siobhan, @westonruter, @wonderboymusic, and @yoavf for their help this week!

     
    • Stagger Lee 5:03 pm on April 15, 2014 Permalink | Log in to Reply

      I am using WP Beta tester plugin, latest nightly and video playlist is still missing. Audio playlist is there. Is it normal for this beta moment ?

      • Mike Schroder 6:44 pm on April 15, 2014 Permalink | Log in to Reply

        Have you uploaded any videos? The “Create Video Playlist” option should appear on the left in the “Add Media” modal after you have videos uploaded to compile into a playlist.

    • Stagger Lee 8:23 pm on April 15, 2014 Permalink | Log in to Reply

      Yes i see now, thank you. Tried to upload it with FTP client first. (C/P, localhost) Still a bit confusing for beginners.

      Do you plan to make same styled playlists for Youtube videos ? I know there are plugins for it, but it is core code, style is fine and URL option is already there.

  • Konstantin Obenland 1:55 am on April 15, 2014 Permalink
    Tags: , , , , ,   

    HTML5 Galleries & Captions in WordPress 3.9 

    WordPress 3.6 introduced HTML5 versions of popular template tags, starting out with comments, the comment form, and the search form. With the 3.9 release we add galleries and captions to that list. Now, when adding HTML5 support for those features, WordPress will use <figure> and <figcaption> elements, instead of the generic definition list markup.

    To declare that your theme supports these new HTML5 features, add the following call to your theme’s functions.php file, preferably in a callback to the after_setup_theme action:

    add_theme_support( 'html5', array( 'gallery', 'caption' ) );
    

    For forward compatibility reasons, the second argument with the specific parts can’t be omitted when registering support. Otherwise a theme would automatically declare its support for HTML5 features that might be added in the future, possibly breaking its visually because of it.

    For both galleries and captions not only the markup changes when a theme declares its support for them, there are also peripheral changes that come with it.

    Galleries

    By default, galleries will not include inline styles anymore when in HTML5 mode. This caters to the trend of disabling default gallery styles through the use_default_gallery_style filter, a filter that even the last two default themes used. With that, theme developers can always start with a clean slate when creating their own set of gallery styles.

    We also took the opportunity to remove the line breaks between rows of images. Not only did they encourage an inferior way of positioning elements, more importantly they were non-semantic html elements that are meant for presentational use, and they made it harder to style galleries.

    Captions

    Up until now, captions received an additional 10 pixels of width, to keep text flowing around the caption, from bumping into the image. As @nacin put it, this has vexxed theme developers for years, and even resulted in the addition of a filter in WordPress 3.7 to manipulate the caption width.

    We were not able to completely remove the inline style in HTML5 mode, it’s still necessary to force captions to wrap, but we’re no longer the adding 10px of width. We also removed caption styles in the editor, bringing it on par with how non-captioned images are displayed:

    Twenty Thirteen and Twenty Fourteen have been updated to support both features, while retaining backwards compatibility with older WordPress versions. There is a remote possibility however, that child themes that use element selectors to overwrite gallery or caption styles can lose those customizations. Please test your child themes with the current development versions of the last two default themes.

    If there are any questions about the current implementation, feel free to leave a comment below.

     
    • andrei1709 5:08 am on April 15, 2014 Permalink | Log in to Reply

      Awesome! Thank you very much for this update :)

    • Manuel Schmalstieg 12:07 pm on April 15, 2014 Permalink | Log in to Reply

      Glad to see that the HTML5 mode removes the BR tags from the gallery markup. That’s great news for responsive theme development!

    • Morten Rand-Hendriksen 3:12 pm on April 15, 2014 Permalink | Log in to Reply

      This is great and long overdue. I always say WordPress is at the forefront of web standards and the two thing that have been lagging behind are the galleries and comments. This is a major milestone that will change the way we think about built in features.

    • glueckpress 9:15 am on April 16, 2014 Permalink | Log in to Reply

      (goes updating themes)

    • Justin Kopepasah 6:43 am on April 17, 2014 Permalink | Log in to Reply

      This is great news. I was happy when the filter was introduced and now I am elated to see the ability to implement HTML5 galleries completely. Definitely adding this to my latest theme.

    • car57 6:52 pm on May 14, 2014 Permalink | Log in to Reply

      I am not a developer, so would you be so kind as to explain what is meant by:

      To declare that your theme supports these new HTML5 features, add the following call to your theme’s functions.php file, preferably in a callback to the after_setup_theme action:

      add_theme_support( ‘html5′, array( ‘gallery’, ‘caption’ ) );

      I have a functions.php file for a child theme. I don’t know what code to insert to have “a callback to the after_setup_theme action”

      TIA

      • Knut Sparhell 12:39 am on May 15, 2014 Permalink | Log in to Reply

        A callback is a function (or class method) that is added to an action by add_action(). In this case add_action( 'after_setup_theme', 'my_theme_setup' );. Inside my_theme_setup() function you can add the theme support. It could also be added in other actions, like ‘init’ or ‘wp_loaded’, but not before ‘after_setup_theme’ has fired. If you just add the support in the outer scope of functions.php it may be executed too early in the load process. The internal data structures to receive this theme addition may not have been initialised before ‘after_setup_theme’.

        The outer scope of functions.php (and plugins) should only add actions and filters, nothing else. All things you want to do should be inside a “callback” (a function or a class method, to be precise).

        See http://code.tutsplus.com/articles/the-beginners-guide-to-wordpress-actions-and-filters–wp-27373

    • car57 7:56 pm on May 14, 2014 Permalink | Log in to Reply

      no matter how i add php to functions.php, this script is never run. Still getting old-style dl with inline css. Sigh.

    • paulinelephew 12:02 pm on July 23, 2014 Permalink | Log in to Reply

      Hi there,

      I am using the Argo theme and I have no caption displaying with galleries.
      I have tried about everything (including contacting the theme support a zillion times and they won’t get back to me).

      I inserted the lines below in function.php and nothing happens:

      add_action( ‘after_setup_theme’, ‘argo_setup’ );
      add_theme_support( ‘html5′, array( ‘gallery’, ‘caption’ ) );

      the website is http://www.terredalizes.fr

      If anyone can help it is greatly appreciated!

      Cheers,

      Pauline

  • Mike Schroder 7:33 pm on April 9, 2014 Permalink
    Tags:   

    Last Week in WordPress Core 

    Howdy everyone! This is Last Week in WordPress Core for the week of March 31-April 7. I’m including all of the commits up to RC1 this week, which was released yesterday. Things are looking good, with very few remaining tickets open.

    3.8.2 and 3.7.2 were also released with security fixes, and automatic updates are rolling out.

    Developers, please test with your plugins and themes and let us know if you find issues.

    TinyMCE: As a quick note, since I’ve seen this brought up in the forums — in this release, TinyMCE no longer uses wpdialogs. This means it now needs to be enqueued by any plugin that wants to use it. As of [28024], there is a clarified warning that will appear in the JavaScript console if you attempt to use it, and it’s not enqueued.

    IE8 & wpview: Due to IE7/8 compat being necessary in TinyMCE (to resolve caret issues), IE8 and wpview are not currently the best of friends. Post RC1, fixes landed for #27546 that make wpviews degrade more gracefully.

    Media:

    • Playlists: Make elements in playlists responsive and fix playlist advancement on mobile. [27894] [27895] #27625
    • Playlists: Set preload='none' for the empty <audio|video> tag. [27974] #26779
    • Playlists: Make tracks keyboard-accessible. [28023] #27644
    • A/V Shortcodes: Remove support for a caption in audio and video shortcodes. This was part of a UX iteration for the related MCE views, but these captions have since been excluded. See [27640]. [27979] #27320
    • Edit Image Modal: Make the calculation of the aspect ratio more robust. [27942] [27948] #27366
    • Do not show featured images for image attachments; remove post_supports_thumbnails() and theme_supports_thumbnails() for now. [28051] #27673

    HTML5 Galleries:

    • Remove <br> elements for HTML5 galleries; see #26697. [27914] #27637
    • Twenty Thirteen and Fourteen: Update styles to support the new HTML5 line-break-less galleries. [27926] #27637

    Admin:

    Theme Installer:

    Widgets

    • Trigger jQuery events for widget updates. widget-added when a widget is added to a sidebar and widget-updated/widget-synced for widget soft/hard updates. [27909] [27969] #19675; #27491
    • In WP_Widget, introduce is_preview() method to allow widgets to check to see if they’re currently being previewed via the customizer. [27966] #27538
    • Widget Customizer: Improve compatibility with plugin custom scripts and styles for widgets. [27907] #27619
    • Widget Customizer: Rename inject_preview_css to print_preview_css. [27968] #27534
    • Widget Customizer: Use postMessage to highlight widgets in preview or sections/controls in Customizer. [27892] [27893] #27622
    • Widget Customizer: Refactor and clean up WidgetCustomizer as wp.customize.Widgets, and make available widgets panel a Backbone view. [27985] [27986] [27988] [27995] [28034] #27690

    TinyMCE

    • Update TinyMCE to 4.0.21. [27897] #24067
    • Image Details Modal Improve look-and-feel, and add a Custom Size option to the size drop-down that reveals fields for soft-resizing the inserted image. [27918] #27366
    • Image Details Modal: Move all advanced options under a single toggle, bring back the field for CSS Class, and optimize CSS for responsive layout. [27898] #27366
    • Drag and Drop Uploading: Add new argument to wp_editor() to enable. [27901] #27465
    • Gallery Views: Avoid JS errors when image attachments lack metadata. [28008] #27691
    • Return to loading /langs/[locale].js and /langs/[locale]_dlg.js from PHP to prevent errors with missing translation files when requireLangPack() is used without its second argument. Back to using ISO 639-1 (two letter) locales. #24067; [27922] #27610
    • Clarify error when wpdialogs is not enqueued. Add wp_enqueue_editor action fired when scripts and styles for the editor are being enqueued. [28024] #16284
    • Update translatable strings. [27927] #27453, #24067
    • Tighten up toolbar and tab styles. [27978] [27983] #27279
    • Expose toolbar keyboard shortcut in Help documentation for TinyMCE, and clean up TinyMCE help dialog, removing duplicated text and leaving only Keyboard Shortcuts. [28029] #27024; [28032] #27100

    Database:

    • Fall back from ext/mysqli to ext/mysql if the connection fails. This allows us to avoid breaking a site that works under ext/mysql but is misconfigured for ext/mysqli. [27935] #21663
    • Add $allow_bail argument to wpdb::check_connection() to match the connect method. [27925] #27240
    • Don’t pass a second argument to mysqli_fetch_field(). [28002] #27693
    • Rename USE_EXT_MYSQL to WP_USE_EXT_MYSQL. [28022] #21663

    Internals:

    • Updates: Record Plugin & Theme update statistics like we do for Core updates. [27905] [27906] #27633
    • Pingbacks: Forward pingback IP during verification. [27872] #27613
    • Dashicons: [27989] [28005] [28013] #26936
      • New icons: .dashicons-external, .dashicons-editor-contract and .dashicons-universal-access-alt.
      • Updated icons: .dashicons-code, .dashicons-universal-access, .dashicons-arrow-x-alt and .dashicons-arrow-x-alt2.
      • Restores .dashicons-post-trash as an alias for .dashicons-trash, which is the new one.
      • Use new icons in Widget Customizer.
    • Don’t try to resolve symlinks for single-file plugins. plugins_url() should not be used in this context anyway. [27999] #16953
    • Remove old links_recently_updated_* DB options that never had a UI. [27916] #27649
    • Deprecate wpmu_current_site(). [28009] #27702

    Many thanks to @adamsilverstein, @andykeith, @avryl, @azaozz, @bramd, @chiragswadia, @davidmarichal, @dd32, @dpe415, @duck_, @DrewAPicture, @DrProtocols, @ehg, @eightface, @empireoflight, @gcorne, @helen, @jackreichert, @jdgrimes, @jeremyfelt, @jesin, @joedolson, @johnbillion, @jorbin, @jond3r, @kovshenin, @kpdesign, @leewillis77, @markjaquith, @matveb, @mcsf, @melchoyce, @michael-arestad, @nacin, @Nessworthy, @norcross, @obenland, @ocean90, @pento, @plocha, @rachelbaker, @rmccue, @sdasse, @SergeyBiryukov, @siobhan, @sonjanyc, @tellyworth, Tom Adams, @vancoder, @westonruter, and @wonderboymusic for their help this week!

    For the complete list of commits to trunk, check out the log on Trac. Since we’re getting very close to release, the best way to help is to test! Let us know if you run into problems in the Alpha/Beta forums or on trac.

     
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