WordPress.org

Ready to get started?Download WordPress

Make WordPress Core

Recent Updates Page 4 Toggle Comment Threads | Keyboard Shortcuts

  • Scott Kingsley Clark 4:00 pm on June 5, 2014 Permalink | Log in to leave a Comment
    Tags:   

    WP Metadata API / UI team meeting hours vote 

    It was brought up that our current meeting time at 18:00 UTC on Fridays in #wordpress-core-plugins on Freenode IRC is not necessarily the best for everyone.

    What day would be better? Around what time would be better?

    This week’s meeting will continue as planned at the existing time on Friday, but next Friday’s meeting will be postponed due to a scheduling conflict with @mikeschinkel and I.

     
    • Slobodan Manic 6:25 pm on June 6, 2014 Permalink | Log in to Reply

      Hi. No one around for the meeting this week?

      • Scott Kingsley Clark 6:35 pm on June 6, 2014 Permalink | Log in to Reply

        We’re usually just hanging in #wordpress-core-plugins during that time frame, lately we’ve just been working through issues and code together. Not a whole lot of discussion during this period beyond “I’m working on this” :)

  • Helen Hou-Sandi 7:20 pm on June 4, 2014 Permalink | Log in to leave a Comment
    Tags: ,   

    Proposed agenda items for today’s meeting:

    • State of .org APIs for plugins and i18n (@tellyworth and @nacin), where people can help with tickets, storyboarding, or otherwise.
    • Taxonomy roadmap: #17689 needs active discussion, please.
    • Media grid: #24716
    • oEmbed sandboxing: #28249

    Add anything in comments below.

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

  • Janneke Van Dorpe 2:13 pm on May 30, 2014 Permalink | Log in to leave a Comment
    Tags:   

    GSoC: Editor Experiments 

    I’ve not posted on /core before, so, hello everyone! :) I’m Janneke and I’m currently working on my GSoC project. I’m from Belgium, but I currently live in Scotland and study philosophy at the University of Glasgow. This is something different entirely, but I started playing with WordPress a bit last year and enjoyed it a lot. :)

    The original proposal was focussed on the front-end editor and content blocks, but that has changed a bit. I’ll focus on the back-end editor first instead, though the work will likely be reusable for a front-end editor. I’ll also focus on a bit more than just “content blocks”, so that’s why I’ve titled this “Editor Experiments”.

    My general goals are to try to simplify and visualise the editor more, and to improve the workflow by providing as many tools as possible inline, at the right place and time. A lot of these ideas are not new, of course, and can be found in other editors and Joen‘s and Mel‘s mockups from last year. In order to visualise the editor more, I’ll try to make it easy for plugins to register shortcodes with previews for them, like there are now previews for a couple of media shortcodes such as galleries.

    I’ll post an update on this blog every Friday with the progress I’ve made. I meant to publish a post last Friday, but didn’t have access to this blog yet, so here’s one for both weeks. I’ve set up a GitHub repo, and for now that’s the only place where you can download the plugin.

    Sooo.

    I’ve empty the TinyMCE toolbar, leaving only the most general tools, undo/redo, paste as plain text, remove format and help. On the other side we can control the the screen: switch between visual and text mode and activate fullscreen mode.

    Screen Shot 2014-05-30 at 13.35.31

    Instead of putting the title in a tiny box, I moved it to the editor as a first heading so it looks the same as on the front-end. Themes can style it appropriately.

    Screen Shot 2014-05-30 at 13.41.37

    Whenever you move the focus to an empty paragraph, a suggestion pops up to insert a “content block”.

    Screen Shot 2014-05-30 at 13.46.29

    To insert aligned images, you can put your cursor at the start of a paragraph.

    Screen Shot 2014-05-30 at 13.58.42

    Clicking on it gives you some kind of modal, where you can choose a block to add to your post. Of course, in the future plugins will be able to add their own blocks by registering shortcodes. So blocks can be block level HTML elements and block level shortcodes.

    Screen Shot 2014-05-30 at 13.49.21

    What happens after clicking on one of the blocks will depend on the block. Clicking on any of the media blocks will forward you to the media modal. Plugins can have a custom modal to configure the shortcode, which will likely also be used to edit it. Of course, blocks that require no configuration are added immediately (like a horizontal rule).

    To format text, you should select it, and a toolbar will pop up.

    Screen Shot 2014-05-30 at 14.03.56

    And let’s add a link.

    Screen Shot 2014-05-30 at 14.06.06

    That’s it for now. :)

    In the next two weeks I’ll work on the registration of views for shortcodes.

    Now I’d love to hear what you think! I really value your opinion and brilliant ideas. Please do try it, and file issues on GitHub.

     
    • andrei1709 2:21 pm on May 30, 2014 Permalink | Log in to Reply

      Hello and pleased to meet you!
      Your suggestion looks good, but wouldn’t this send too many GET requests to the server, thus making the text editor more laggy?

      • Janneke Van Dorpe 3:59 pm on May 30, 2014 Permalink | Log in to Reply

        For the previews? Currently galleries, playlists etc. are already previewed in the editor. They’re put together from templates, so the output of the shortcode is not requested. But yes, depending on the shortcode, it will always take some time to generate it, but not more than on the front-end.

    • Remkus de Vries 2:23 pm on May 30, 2014 Permalink | Log in to Reply

      I like where this is going. One thing we’d have to be careful with is not putting to much stuff in the modal pop-up. All the various media types would only need one button and take if from there to what we know now.

    • tomdryan 2:26 pm on May 30, 2014 Permalink | Log in to Reply

      Good stuff!

      I’ve wanted to see the registration of shortcodes, along with content blocks and I’m glad you are working on it. In your registration procedure/data structure, please include a description of the shortcode function, supported parameters and the source of the shortcode (which plugin created it).

      Also, it would be nice if you enabled standard widgets to be inserted anywhere and if you enabled any widgets to have a corresponding shortcode (there are plugins that do this now, but it should be included as part of your overall re-envisioning of content creation).

      Keep up the good work!

    • tomdryan 2:32 pm on May 30, 2014 Permalink | Log in to Reply

      Also, it would be nice if you put this in the form of a plug in at some point, so those of us non-coders can test it out and provide feedback.

    • Brad Touesnard 2:37 pm on May 30, 2014 Permalink | Log in to Reply

      Very cool, great work, looking forward to seeing more of this.

    • Eric Binnion 2:47 pm on May 30, 2014 Permalink | Log in to Reply

      Looks interesting! I went ahead and starred the Github repo and I look forward to playing with this :)

    • Christiaan Conover 2:56 pm on May 30, 2014 Permalink | Log in to Reply

      Great idea! I love seeing a new take on the way the editor functions to make it more flexible and extensible. I’ll definitely be trying out your solution!

    • Seth Rubenstein 3:25 pm on May 30, 2014 Permalink | Log in to Reply

      Great idea. Can’t wait to see what’s possible with the shortcode registration.

    • @ubernaut 3:32 pm on May 30, 2014 Permalink | Log in to Reply

      looking good.

    • camu 4:02 pm on May 30, 2014 Permalink | Log in to Reply

      It reminds me of Visual Composer (check CodeCanyon).

      • Janneke Van Dorpe 4:13 pm on May 30, 2014 Permalink | Log in to Reply

        The biggest difference is that Visual Composer is more like a page builder. If you just want to write something, it’s very confusing.

        • binarymoon 4:22 pm on May 30, 2014 Permalink | Log in to Reply

          that said – I’d love to see some visual composer style functionality built into this. Even if it’s just the ability to add additional shortcodes to the popup through a plugin.

          Regardless – I think this looks sweet. If you create a plugin for it so I can install through wp.org then I’d love to test it out.

    • Chris Reynolds 4:19 pm on May 30, 2014 Permalink | Log in to Reply

      I’d be really interested in seeing how this fares vs. the regular editor in user testing. It looks good, but I wonder about the lack of the WYSIWYG (or, more specifically, the stripped-down toolbar). For me, I use keyboard controls to do things like bold or italics, so selecting text and waiting for the pop up wouldn’t bug me much, but some of the other things (content blocks and links) might not be immediately intuitive. But I have no idea — would be great to see some testing :) and +1 for the pluginified version. You get a plugin for this and maybe the admin-help-come-user-testing team can maybe run some tests for it (or at least add it to the list).

    • Diego de Oliveira 4:49 pm on May 30, 2014 Permalink | Log in to Reply

      Just tested this plugin and… wow, it’s already awesome! Congratulations!

      I think that this approach could really solve the main issues of CEUX project and would integrate really good with the FEE. The editing experience reminds a lot of Medium editor, which is good. And I really liked the modal for content blocks, looks like a good solution for scalability of content blocks.

      One thing that the CEUX project had was the possibility to sort / reorder content blocks. Any plans for something like this? I know that drag / drop is naturally possible for media objects (and other possible views), but it would be cool if we could do the same with the usual elements, like paragraphs, lists, tables, etc.

      And please, keep the awesome work!

      • Janneke Van Dorpe 4:58 pm on May 30, 2014 Permalink | Log in to Reply

        Great! Thanks for giving it a try!

        Yes, maybe. I’ve experimented a bit with with drag and drop of direct children of the body, which is challenging, but could work. That be really cool. I know that arrow are really useful sometimes, especially on touch devices, but I really hate adding so much buttons/icons. :)

        • Diego de Oliveira 5:14 pm on May 30, 2014 Permalink | Log in to Reply

          Yeah, “less is more”, almost always! More buttons/icons = more cluttering, and a strong point for your approach is how clean is the process of editing content. But for touch devices… that’s would be challenging, for sure!

          There are some sortable js libraries that works on touch devices too, but I don’t know if it would work for a really long content that would be edited in a smartphone. Still, I would prefer drag ‘n drop instead of arrows. At least for me, it feels more intuitive.

      • Janneke Van Dorpe 4:59 pm on May 30, 2014 Permalink | Log in to Reply

        I’ve experimented a bit with with drag and drop of direct children of the body

        This sounds so weird out of context.

    • Paal Joachim Romdahl 5:12 pm on May 30, 2014 Permalink | Log in to Reply

      I am thinking beside the eye (visual) mode there can also be a grid icon. Turn on the grid to place elements in grid cells (kinda like table data cells). Click inside a cell and see the cell walls go darker blue. Write and add content into the specific cell. Turn off the grid to see how the content is aligned into nice columns and rows.

      Adding break points. Resize the browser and click somewhere to make a break point. At each break point redo any of the content. Easy way to create media queries directly inside the content creation area. Perhaps a way to turn break point view on or off.

      • Janneke Van Dorpe 5:18 pm on May 30, 2014 Permalink | Log in to Reply

        Yes, columns is a much requested feature… I’m not sure if something like this should added in the content itself. The theme should handle that. What if you divide your content into 2 columns and switch to a smaller width theme? :/

        I’m not sure what you mean in the second paragraph.

        • Paal Joachim Romdahl 5:33 pm on May 30, 2014 Permalink | Log in to Reply

          Ok instead of a grid it is important to add items to columns one can see. To directly see how it looks. A grid is basically about seeing how elements are together on a page.

          Another way to to drop/click an element next to another automatically creating a row of two elements.

          Break points to where the page changes to another layout. Here is an example on how it is done in Macaw: https://www.youtube.com/watch?v=lz7MlRSAR-I

          Creating visual media queries directly in the content screen instead of creating them through CSS (or having the option to do so).

          • Janneke Van Dorpe 5:51 pm on May 30, 2014 Permalink | Log in to Reply

            Break points to where the page changes to another layout. Here is an example on how it is done in Macaw: https://www.youtube.com/watch?v=lz7MlRSAR-I

            Creating visual media queries directly in the content screen instead of creating them through CSS (or having the option to do so).

            Why would you want to do that? Isn’t that something for the theme to handle? I don’t really want to make it more difficult for writers to write something in WordPress. I want to make it easier. :)

    • Juanfra Aldasoro 5:28 pm on May 30, 2014 Permalink | Log in to Reply

      Looking and working great :) I think that something like this (if it is coded with an extensibility approach) could normalize the diverse world the page builders are suffering these days. This way WordPress would have a final answer for the call on builders and shortcodes – as it did before with the customizer and options/settings for example.

    • Robert Chapin 2:09 pm on June 1, 2014 Permalink | Log in to Reply

      This is conceptually awesome. The editor is the soul of WordPress and yet is often neglected during discussions of new features.

    • bduclos 9:00 am on June 2, 2014 Permalink | Log in to Reply

      Looks really good!
      Is it planned for WordPress 4.0 or later?

    • PeterRKnight 11:27 am on June 2, 2014 Permalink | Log in to Reply

      Looks amazing already. I love where this is going.

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

      Really liking this, especially the inline text formatting.

      Have accessibility considerations been made for keyboard-only input?

      • Janneke Van Dorpe 3:20 pm on June 19, 2014 Permalink | Log in to Reply

        It wouldn’t be less accessible than the current toolbar. You can still use keyboard shortcuts to execute editor commands. The toolbar currently shows up when selecting content with your keyboard, but I’ll need to add a shortcut to move the focus to the toolbar. If you have any suggestions, feel free to share. :)

    • Manny Fleurmond 9:08 pm on June 10, 2014 Permalink | Log in to Reply

      Little iffy on the title being part of the editor but everything else is awesome. Having shortcodes being registered in your modal would be awesome for plugin developers. I’d probably find a way to merge your modal with the existing media modal, since all of the media buttons are repeated. Heck, it could be a chance to abstract the media modal to an “insert content block’ modal.

      I’m definitely keeping an eye on this. Great job.

    • morethinking 9:07 am on June 19, 2014 Permalink | Log in to Reply

      First of all, thanks for doing this. This is something that many people in the WordPress community have been wanting for a long time (as the popularity of page builders indicates).

      With that said, I would like to offer my two-sense worth on the issue of columns.

      You wrote:

      “Yes, columns is a much requested feature… I’m not sure if something like this should added in the content itself. The theme should handle that. What if you divide your content into 2 columns and switch to a smaller width theme?”

      In my opinion, columns are more often than not an issue of content and should be part of the editor. What’s more, I believe there are solutions to the issue that you raised. Take a look at the Live Grid Example here: http://getbootstrap.com/2.3.2/scaffolding.html.

      Beyond that, obviously a user needs to pick a theme that works with his or her particular content. If someone wants columns and a particular theme doesn’t work with their columns then they should either choose a different theme, modify the theme so that it fits in with their content or give up on using columns.

      What I don’t think should be done is to leave the option of users organizing their content into columns to theme developers (except in those cases where columns are being used more for design purposes). I also don’t see why the option shouldn’t be included because of those rare cases where a problem may develop.

      One last thought/point. It may be worth taking some time to look at the Squarespace layout editor to see what they have done in general as well as how they handle columns.

      With that said, once again thanks for the great work.

      • Janneke Van Dorpe 3:30 pm on June 19, 2014 Permalink | Log in to Reply

        When people talk about columns, the first thing I think of is splitting the whole content in two columns, but that’s not what they mean in most cases. That’s why I suggested that the theme should handle it, because in that case it makes sense.

        Sure, I can see why it’d be useful. I’m not sure if it can be done within TinyMCE, but I have some ideas. I’ll definitely give it a try at some point.

        I’ve looked at most editors on the internet, including Squarespace. :)

    • morethinking 9:07 am on June 22, 2014 Permalink | Log in to Reply

      I see that you have done your homework :).

      Glad to hear that you are willing to give it a try.

      Just one question, I’m not sure what you mean by ‘splitting the whole content in two columns’. What I have in what one might find on a home page — with different sections of the page divided into different columns to display the content differently. It would be nice if the end user could have control for laying out content like that.

  • Eric Andrew Lewis 3:50 pm on May 29, 2014 Permalink | Log in to leave a Comment
    Tags:   

    Media component office hours 

    Weekly office hours (bug scrubbing and feature development chat) for the Media component will start tomorrow, combining with Media Grid’s weekly meeting.

    I’ve heard the Media component is “where tickets on trac go to die,” let’s see what we can do to thwart that status quo.

    Our Media Grid meetings have been held every Friday at 1700 UTC in #wordpress-ui. We’ll keep the same time, but move the meeting into #wordpress-dev.

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

  • Ryan McCue 4:45 am on May 25, 2014 Permalink | Log in to leave a Comment
    Tags:   

    JSON REST API: Version 1.0 

    I’m incredibly excited to announce the availability of version 1.0 of the JSON REST API.

    This version is a huge release and introduces a bunch of new features, such as user, revision and post meta endpoints. It also introduces our long-term backwards compatibility policy, aligning with WordPress core backwards compatibility.

    Here’s a selection of the new stuff:

    • Add user endpoints.

      Creating, reading, updating and deleting users and their data is now possible
      by using the /users endpoints. /users/me can be used to determine the
      current user, and returns a 401 status for non-logged in users.

      Note that the format of post authors has changed, as it is now an embedded
      User entity. This should not break backwards compatibility.

      Custom post types gain this ability automatically.

      (props @tobych, @rmccue, #20, #146)

    • Add post meta endpoints.

      Creating, reading, updating and deleting post meta is now possible by using
      the /posts/<id>/meta endpoints. Post meta is now correctly embedded into
      Post entities.

      Meta can be updated via the Post entity (e.g. PUT to /posts/<id>) or via
      the entity itself at /posts/<id>/meta/<mid>. Meta deletion must be done via
      a DELETE request to the latter.

      Only non-protected and non-serialized meta can be accessed or manipulated via
      the API. This is not predicted to change in the future; clients wishing to
      access this data should consider alternative approaches.

      Custom post types do not currently gain this ability automatically.

      (props @attitude, @alisspers, @rachelbaker, @rmccue, @tlovett1, @tobych,
      @zedejose, #68, #168, #189, #207)

    • Add endpoint for deleting a single comment.

      Clients can now send a DELETE request to comment routes to delete
      the comment.

      Custom post types supporting comments will gain this ability automatically.

      (props @tlovett1, @rmccue, #178, #191)

    • Add endpoint for post revisions.

      Post revisions are now available at /posts/<id>/revisions, and are linked in
      the meta.links.version-history key of post entities.

      Custom post types supporting revisions will gain this ability automatically.

      (props @tlovett1, #193)

    • Respond to requests without depending on pretty permalink settings.

      For sites without pretty permalinks enabled, the API is now available from
      ?json_route=/. Clients should check for this via the autodiscovery methods
      (Link header or RSD).

      (props @rmccue, #69, #138)

    • Add register post type argument.

      Post types can now indicate their availability via the API using the
      show_in_json argument passed to register_post_type. This value defaults to
      the publicly_queryable argument (which itself defaults to the
      public argument).

      (props @iandunn, @rmccue, #145)

    • Remove basic authentication handler.

      This breaks backwards compatibility for clients using Basic
      authentication. Clients are encouraged to switch to using OAuth
      authentication
      . The Basic Authentication plugin can be
      installed for backwards compatibility and local development, however should
      not be used in production.

      (props @rmccue, #37, #152)

    • Require nonces for cookie-based authentication.

      This breaks backwards compatibility and requires any clients using cookie
      authentication to also send a nonce with the request. The built-in Javascript
      API automatically handles this.

      (props @rmccue, #177, #180)

    • Clean up deprecated methods/functions.

      Functions and methods previously deprecated in 0.8/0.9 have now been removed.
      Future deprecations will take place in the same manner as WordPress core.

      This breaks backwards compatibility, however these were marked as
      deprecated in previous releases.

      (props @rmccue, #187)

    • Only expose meta on ‘edit’ context as a temporary workaround.

      Privacy concerns around exposing meta to all users necessitate this change.

      This breaks backwards compatibility as post meta data is no longer
      available to all users. Clients wishing to access this data should
      authenticate and use the edit context.

      (props @iandunn, @rmccue, #135)

    • Add json_ensure_response function to ensure either a
      WP_JSON_ResponseInterface or a WP_Error object is returned.

      When extending the API, the json_ensure_response function can be used to
      ensure that any raw data returned is wrapped with a WP_JSON_Response object.
      This allows using get_status/get_data easily, however WP_Error must
      still be checked via is_wp_error.

      (props @rmccue, #151, #154)

    • Use version option to check on init if rewrite rules should be flushed.

      Rewrite rules on multisite are now flushed via an init hook, rather than
      switching to each site on activation.

      (props @rachelbaker, #149)

    As always, you can view all commits or the longer changelog.

    For those interested, here’s the list of contributors to this release:

    $ git shortlog --summary 0.9...
         1  Chris Marslender
         1  Eric Lanehart
         2  K.Adam White
         1  Kat Hagan
         2  Matth_eu
        41  Rachel Baker
       139  Ryan McCue
         5  Taylor Lovett
        10  Toby Champion
    

    There’s a few really important things to note with this release.

    Authentication Changes

    Authentication has changed significantly in 1.0. If you’ve been using Basic authentication previously, you’ll now need to install the Basic authentication plugin. This plugin is designed for local development, as Basic authentication requires sending your plaintext credentials over the wire, which is unsafe for production.

    Production users have two choices: built-in cookie authentication, or OAuth authentication. OAuth 1.0a is an authorization protocol that allows you to authorize clients to act on your behalf, and does not require giving your username and password to the client. It does, however, require a significantly more complicated authentication/authorization process, and clients are required to register on the site beforehand. We’re working on long-term solutions to this.

    Plugins and themes can also use built-in cookie authentication. This is the normal WordPress login process, however requires a nonce for authentication to the site. This is automatically handled for you when using the built-in Javascript client.

    Backwards Compatibility

    From this release forwards, backwards compatibility will not be broken. This includes both the internal PHP API, as well as the REST API we expose. New endpoints may be added, as well as new data, but responses will continue to be supersets of the current response.

    The exception to this is for security concerns. As we continue development, we may need to change some endpoints for security issues, as we did with post meta for this cycle. These will be announced well before release where possible.

    Please note also that this release has removed some previously deprecated methods and changed some internal implementation details. This only affects plugins or themes that extend the API.

    Core Integration

    We’re pushing hard for integration into 4.0 this cycle, and we need your help. Our core integration plan outlines the motivation behind the project and the specific plan for integrating it into core. We’re currently working on a comparison document for the API compared to the WP.com/Jetpack API and others, and will be publishing that soon.

    We need your help to make it into 4.0. Developers, we’d love to know what you’ve built with the API, whether public or internal (even vague details help!), and we’d especially love to see things built with the API. We’re currently in danger of not making it in this cycle, so anything you can do to help us here would be fantastic.

    As always, we’re also looking for help. The main API always needs help, and the other related projects do too. Both the WP-CLI client and Javascript client need help here.

    You’re always welcome over at the team o2, and our next meeting will be at Tuesday, 00:00 UTC; we’d love to see you there. If not, see you soon for version 1.1!

     
    • Nikola Nikolov 7:45 am on May 25, 2014 Permalink | Log in to Reply

      I’ve used the JSON API to make front-end submissions to a budgeting app I did for my family.
      I basically only use it for publishing entries in custom post types. I started using the plugin while it was at .6, or .7, so I had to extend it in order to get the endpoints and post meta handling that I needed, but it wall worked out just great.
      I haven’t had the time to update from 0.8 to the latest version, since I’m not sure how much code I’d have to change and I don’t really have lots of free time these days :)

      But in any case, it saves time(once you have it figured out), it’s reliable, well-written and I personally would love to see it in core. Because if it’s in core, more people would actually use it(which means having a more unified experience for developers). I’m sure almost everyone right now is using one of three methods in order to push/pull data via AJAX:

      • request to /wp-admin/admin-ajax.php
      • request to /wp-content/plugins/…./plugin-ajax.php
      • request to the current url, with a hook on init or something else

      — Nikola

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

      Good work @ryan and all the team.. it’s really a big project :)

    • cemdev 3:17 pm on May 25, 2014 Permalink | Log in to Reply

      Please, please, please let this make it into 4.0. The xml-rpc API is soooooo crap. And insecure. Really looking forward to leveraging a modern, more secure API for our customers.

    • Mikel King 3:21 pm on May 25, 2014 Permalink | Log in to Reply

      Very cool! Thank you @ryan and the whole team I can’t wait to mess around with this! I would love to see a talk on this at WordCamp NYC in Aug…

    • Towfiq I. 3:48 pm on May 25, 2014 Permalink | Log in to Reply

      +1 this SHOULD be in core!!

    • memuller 11:47 pm on May 25, 2014 Permalink | Log in to Reply

      This is really, really impressive. curl’ing those API endpoints is a lot of fun.
      Will surely use in future projects, regardless of its inclusion on core. It’s superior to the Jetpack API, and clearly superior to the default one.

      As Nikola pointed out, the ways currently in use to perform data operations via AJAX are a little awkward. As someone that is frequently sough for WP-related advice, I would *really* appreciate if this was included on core, since them I could teach novices to use it for AJAX calls – if it remains as a plugin, it would be a little irresponsible to do so. I think that’s an important point – experienced developers will always be able to use this API as a plugin, regardless of its inclusion on core; but we can’t expect first-time wordpressers to depend on a plugin; they will just google for the “standard” way of doing things and will stick to it.

      I used to work in a local media conglomerate, heavily dependant on WordPress. At the time, I did a *lot* of integration between WP and other applications – a work that would have been a lot easier if this API already existed; specially since most of those apps were quite RESTfull (rails applications, sinatra and node middlewares and the like). It would have allowed us to keep a higher quality standard on our infrastructure – without it, we did some integrations with the Jetpack API, some with RPC, and some even by mucking with the database directly. This API would have provided us with a way that was so much better and easier than the alternatives, that no developer – regardless of skill level – would have been able to ignore it.

    • Eric Andrew Lewis 2:31 am on May 26, 2014 Permalink | Log in to Reply

      Will there be some kind of versioned usage of the API, so that breaking changes can be made in a new version, but the old version can still be supported?

      • Ryan McCue 4:07 am on May 26, 2014 Permalink | Log in to Reply

        Beau Lebens asked the same over on the o2, here’s my response:

        The plan for versioning, if it’s ever needed, is to use Content-Type headers to indicate the version, much the same way that GitHub versions their APIs. This doesn’t affect the current approach, so it’s not something needed at this point.

        • Eric Andrew Lewis 9:11 am on May 26, 2014 Permalink | Log in to Reply

          B)

        • Aaron Jorbin 6:05 pm on May 28, 2014 Permalink | Log in to Reply

          I don’t like this approach for a couple of reasons. 1) It makes it harder to use tools like Curl for testing. 2) It would make debuging by looking at server logs harder. 3) It also adds a higher barrier to entry for developers as not all developers know how to add headers. Yes this can be solved with education, but I don’t think every problem should be solved with education.

          I think we should add the version string into the url.

          • Mikel King 7:27 pm on May 28, 2014 Permalink | Log in to Reply

            I have to imagine that WP_Http (where adding headers is really rather trivial) is preferred over curl.

            • Aaron Jorbin 7:31 pm on May 28, 2014 Permalink

              I’m was talking about from the command line, not from php. Sorry that wasn’t clear.

    • Eric Lanehart 6:07 pm on May 27, 2014 Permalink | Log in to Reply

      We’ve been using WordPress as an API at sparkart for many of our projects, starting with the Americas Cup (http://sparkart.com/work/americas-cup) in 2012/13. That project used Dan Phiffer’s JSON API plugin in a manner similar to what he built that plugin to do for the MoMA: supply content to a Ruby-based server. Nowadays we use node.js (http://github.com/solidusjs) in the same fashion. This allows us to easily integrate data from other sources and simplify our production and development environments by removing a database dependency. Our production sites are essentially static, fronted by a CDN for fast performance around the world. Unlike static site generators content is refreshed as it expires.

      YoungMoney.com, official site of Lil Wayne, is using the JSON REST API plugin today. All sites in development also rely upon it. We’re actually planning to migrate all content from a legacy, proprietary CMS to WordPress. We began using the plugin as of 0.6, seeing a much clearer future than the existing JSON API plugin and appreciating the thoughtful design behind it. We also considered the Thermal API plugin but found it’s implementation, particularly around media, to be uneven. The response schema also seemed too much of an abstraction.

      This maybe isn’t the most compelling use case since we flout much of the WordPress ecosystem (themes, widgets, plugins, etc). But a new class of CMS’s have emerged in this time (Osmek, Contentful, Prismic.io) that are essentially the same proposition: content management without the presentation layer. The problems they solve around support for mobile apps and other non-browser based environments connected to the web is also tremendously valuable. The Quartz use case along with some examples of similar node.js-fronted sites like the WSJ, other Dow Jones properties, and Artsy have helped validate our approach in my mind. Except unlike Quartz we don’t need expensive WordPress VIP installations to scale to millions of visitors.

      As developers we’re all about the Unix philosophy of small, focused tools. We strongly prefer these tools to be open whenever possible, and this is one reason we continue to use WordPress despite the existence of these services.

    • paulkevan 9:55 am on May 28, 2014 Permalink | Log in to Reply

      Although we (metro.co.uk) haven’t used any the JSON api plugin, due to using WP.com VIP, we have built replica json endpoints so we can consume some of our post meta fields in other applications.

      The other area we use is the XML-RPC endpoints to push in images from our picture management system and as previously mentioned this isn’t the nicest method to use.

      I’d be happy to get involved in the testing of any post meta based endpoints and also the development of the media endpoints, in particular the extending of what data can be send through these endpoints for each media item.

    • K.Adam White 8:44 pm on May 28, 2014 Permalink | Log in to Reply

      We’re using the API as the content backend for an in-development Node.js website and several single-page applications; nothing I can share publicly yet, but the API project was the tipping point that let me convince my colleagues that WordPress was a suitable backend for a non-PHP application. We’re really excited about the work we’re doing and I look forward to sharing it later in the year.

  • Scott Kingsley Clark 12:46 am on May 24, 2014 Permalink | Log in to leave a Comment
    Tags:   

    We’re ready for more contributors to join us on the WP Metadata UI / API project 

    Where we need help most

    • Field Types – We need help building new field types, we currently have a few basic fields to start off with including the Text, Textarea, URL, Date, and Hidden field types.
    • Actions / Filters – We are now seeking to add in the hooks necessary to extend things further, feel free to request hooks anywhere you see a need for them.
    • Repeatable Fields – We are architecting a solution for repeatable fields, in which you can take a single field and make it have repeatable inputs that let someone add multiple values. These values would be stored in multiple meta values for the same meta key for the specific object ID.
    • Unit Testing – If your UT fu is strong, then strong would the use of your fu be on our team!

    Have any other ideas you’d like to help out with? Hop in, the world is your oyster and we’re eager to help you get those pearls!

    Join us in #wordpress-core-plugins on Freenode IRC and seek out @sc0ttkclark or @mikeschinkel if you need anything to help you get started, or open up an issue on our GitHub with your questions/feedback.

    We’re also still meeting 18:00 UTC on Fridays in #wordpress-core-plugins on Freenode IRC, feel free to search IRC logs for <#metadata> for a history of our previous conversations.

    So… ready to start? Head over to the WordPress Metadata UI / API GitHub now, see you there! Happy coding!

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

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