WordPress.org

Make WordPress Core

Updates from John Blackbourn Toggle Comment Threads | Keyboard Shortcuts

  • John Blackbourn 3:53 am on April 2, 2015 Permalink |
    Tags: ,   

    Reminder: Term splitting in 4.2 

    Here’s a quick reminder to plugin authors. Beginning in WordPress 4.2, shared taxonomy terms will get split into separate terms when one of the terms gets updated.

    What does this mean for you? If your plugin is independently storing term IDs in post meta, user meta, or options, then it’s likely you’ll need to update your plugin to prevent problems when a shared term gets split.

    Boone Gorges has posted a complete guide to preparing for term taxonomy splitting. Take a read if you’re a plugin author and you think a plugin of yours may be affected.

     
  • John Blackbourn 8:07 pm on January 26, 2015 Permalink |  

    Here’s a reminder for those who haven’t seen it. Please take a few minutes to fill in the Community Hub Poll as the poll closes in the next few days. Get at it!

     
    • Michael Arestad 11:22 pm on January 26, 2015 Permalink | Log in to Reply

      I’m not particularly clear on the purpose of the community site. Judging from the survey, it sounds like it could pretty much end up being a clone of meetup.com. I’m not too fond of that idea, but I’ll wait until more info is available before judging.

  • John Blackbourn 11:47 pm on January 14, 2015 Permalink |
    Tags:   

    There will be a meeting in #core Slack next Tuesday at 2100 GMT (January 20 2015 21:00 UTC) to discuss feature plugins for WordPress 4.2. Several have been proposed. (If you want to propose one, please do it on that thread.)

    In order for a feature plugin to be considered for merge into 4.2, the plugin should already be fairly stable in order to avoid the sort of late development work that we’ve seen with merged feature plugins in recent releases.

    A separate meeting to discuss the feature plugin workflow and development process in general will be scheduled at a later date.

     
    • NateWr 10:05 am on January 15, 2015 Permalink | Log in to Reply

      I may have missed it already, but was there a meeting where people could suggest tickets they wanted to see addressed in 4.2?

    • Paal Joachim Romdahl 11:32 am on January 21, 2015 Permalink | Log in to Reply

      Will all feature plugin suggestions receive feedback as to why or why not each seem suitable as a feature plugin? What is the criteria to become a feature plugin and who decides on this? As it seems like this would be a good community discussion as to what to include in WordPress core and not.

  • John Blackbourn 9:30 am on January 13, 2015 Permalink |
    Tags:   

    Feature plugins in 4.2 and beyond 

    Feature plugins for WordPress 4.2 and beyond need to be planned. Let’s get some suggestions together along with their status and who’s working on them.

    For each feature plugin that you would like to see considered, either for 4.2 or for a future version, please leave a comment with the following details:

    • Current status (eg. idea, planning, early/late development, testing, stable)
    • Who’s responsible
    • Link to GitHub repo or w.org page, if appropriate
    • Whether you’d like the plugin to be considered for 4.2

    It’s become apparent that feature plugins need to be at a much more mature stage before they are considered for merge into core. After all, the point of a feature plugin is to build a feature as a plugin and if the plugin never gets merged into core then we’re still left with a fully workable standalone plugin. Any feature plugins which are to be considered for 4.2 need to be at a very mature stage already.

     
    • Hugh Lashbrooke 9:41 am on January 13, 2015 Permalink | Log in to Reply

      Not sure what kind of things you’re looking for here exactly, but I built this plugin to improve the export tool: https://wordpress.org/plugins/export-plus/ because the patch I submitted doesn’t look like it’s going to be merged anytime soon: https://core.trac.wordpress.org/ticket/27048.

      The plugin is fully functional and there aren’t any bugs that I’m aware of. The only thing it really needs before merge is unit testing, which is a problem because the core unit test library for the export tool was rewritten for a separate patch that also hasn’t been merged (https://core.trac.wordpress.org/ticket/22435), so we would need to revert the core unit test repo for this side of things. Anyway – just thought I’d throw this out there because I think it’s a very useful filler until the export API is properly rewritten like that other patch is doing.

    • Rami Yushuvaev 11:56 am on January 13, 2015 Permalink | Log in to Reply

      Currently, the wp.mce.views API is still experimental (https://core.trac.wordpress.org/browser/tags/4.1/src/wp-includes/js/mce-view.js). It would be nice if WordPress 4.2. will Introduce the full API.

    • Eric Mann 2:59 pm on January 13, 2015 Permalink | Log in to Reply

      I’d been working on Secure XML-RPC for consideration as a feature plugin, and would like to see it revisited.
      Current Status: Late development (on hold as the JSON API was supposed to be in core already, but since it’s not, let’s take some time to revisit this for security sake)
      Who’s Responsible: Me, at the moment. More than happy to have other collaborators.
      Github: https://github.com/ericmann/secure-xmlrpc
      Consider for 4.2: Yes please

      The plugin currently sub-classes the XML-RPC server to provide the secure authentication method as an alternative to sending username/password in plain text. If/When rolled into core, this subclass would be replaced by actually updating the core server implementation. Everything is still backwards compatible (original auth still works, it just sends an X-Deprecated header), so concerns about this breaking existing libraries are minimal.

      • Dave Navarro, Jr. 6:41 pm on January 14, 2015 Permalink | Log in to Reply

        Does anyone know the status of the JSON API? Are they ever gonna finish it?

        • Adam Silverstein 9:43 pm on January 14, 2015 Permalink | Log in to Reply

          Development is ongoing, version 1.1 was recently released and is avaialable for your use: https://wordpress.org/plugins/json-rest-api/

        • Eric Mann 12:09 am on January 15, 2015 Permalink | Log in to Reply

          v1.1 is live. When it’s eventually rolled into core, we’ll increment the version to v2.x. Unfortunately, the “when” for rolling into core is a moving target. Every time we get close, something else comes up to delay it. I was expecting it in 4.0. Then 4.1. Now we’re hoping it might make it into 4.2, but still no promises.

          I’m still really looking forward to the JSON API making it into core. It’s going to be a huge step forward to what WordPress can do. That said, XML-RPC isn’t going to disappear, even when the new API ships. So we should do what we can to make sure that the existing remote interaction API works and is secure.

          • Dave Navarro, Jr. 10:22 pm on January 15, 2015 Permalink | Log in to Reply

            Okay, great! So 1.1 is ready for production sites?

          • dshanske 12:05 am on January 17, 2015 Permalink | Log in to Reply

            I was hoping for a gradual sunsetting of XML-RPC after JSON came into core, although I know that is less likely to happen.

            Of course, it may merely be my annoyance of it being probed by so many outside sources.

    • Mike Hansen 4:02 pm on January 13, 2015 Permalink | Log in to Reply

      I have been exploring starting a project for the registration flow for new users. This would include the signup, login, email, etc.
      Current Status : Idea/Planning
      I would like to lead this project. I would like to have it ready for consideration in 4.3.

      Looking for others interested as well.

      • Travis Northcutt 4:53 pm on January 13, 2015 Permalink | Log in to Reply

        Mike, would this potentially include an option for something like “send this user a link to set their password” when creating a new user in wp-admin? Basically, a way to avoid setting passwords for users, and to avoid transmitting passwords via email.

        Feel free to ping me on twitter (tnorthcutt), I may be interested in helping out.

        • Mike Hansen 5:03 pm on January 13, 2015 Permalink | Log in to Reply

          Yea, plain text passwords in email is one thing on the list.

          • Ihor Vorotnov 10:03 pm on January 21, 2015 Permalink | Log in to Reply

            If this includes possible improvements to the whole registration process, I may be interested as well. Working on a several large projects based on WP, created 2 different versions of custom registration / activation / login process. Have some interesting experience, fails and mistakes, wins and tweaks.

    • Scott Kingsley Clark 4:17 pm on January 13, 2015 Permalink | Log in to Reply

      We’re still working on getting a proposal together for a new Metadata API for registering contextual custom field data (type of data, label text for forms) along with UI (show custom fields in a post edit screen with their corresponding field type inputs).

      It’s not ready, and we’re currently in the process of rebooting our efforts geared towards everything as a result of a discussion with core dev @helen

      We’ll be starting up discussion and status posts in the coming month.

      Though, not exactly a normal feature plugin, we’re hoping to develop it in such a way that it could be used and tested via a plugin for proof of concept.

      • Nick Halsey 4:33 pm on January 13, 2015 Permalink | Log in to Reply

        I’d love to see this, especially if it takes inspiration from (or actually uses, which could be a possibility) the Customizer API. The ease with which devs can spin up, for example, a media control with previewing with that API, as well as being able to easily create custom controls (and custom sections and panels) by subclassing in PHP and JS would be great for post meta.

      • Ihor Vorotnov 10:05 pm on January 21, 2015 Permalink | Log in to Reply

        That might be yet another bottleneck for multilingual sites until WP core becomes multilingual. Just saying :)

    • Siobhan 5:02 pm on January 13, 2015 Permalink | Log in to Reply

      Feature Plugin – Image Flow
      Better image uploading, management, and editing, on every device.

    • Nick Halsey 5:17 pm on January 13, 2015 Permalink | Log in to Reply

      Menu Customizer

      Current status: late development/iterations
      Who’s responsible: me (Nick Halsey, @celloexpressions), with help from @westonruter, @voldemortensen, and others so far
      Links: https://wordpress.org/plugins/menu-customizer/, https://github.com/voldemortensen/menu-customizer, continuous discussion in #core-customize on Slack
      Whether you’d like the plugin to be considered for 4.2: depends on 4.2 timeline and how the next couple weeks go. It’s fairly stable and usable, but there are a few things that need refactoring, and we’re also working on improving core APIs to make things less hacky. The UI is essentially the same as the Widget Customizer UI, so while there’s potential room for improvement there, I don’t foresee needing significant design work before the initial version goes into core (and no one has done much work there yet).

      • Paal Joachim Romdahl 4:05 pm on January 14, 2015 Permalink | Log in to Reply

        What about adding features from kirki?:
        https://github.com/presscodes/kirki

        • Nick Halsey 9:03 pm on January 14, 2015 Permalink | Log in to Reply

          That could probably be done in the form of core tickets/patches if anyone’s interested. The only potential thing that could add would be more custom controls.

      • Samuel Sidler 7:34 pm on January 14, 2015 Permalink | Log in to Reply

        I’d like to see some user testing before it goes into core. Has the accessibilty team reviewed it?

        • Nick Halsey 8:59 pm on January 14, 2015 Permalink | Log in to Reply

          I’ve done some informal in-person user testing and not run into issues. But if someone has the ability to do better user testing that we can iterate from, that would obviously be better (maybe @designsimply?).

          It would be good if the accessibility team started reviewing it. I’ve done basic keyboard-only tests and retained things from the menus admin and the widget Customizer API, but I have only limited knowledge there.

    • Daniel Bachhuber 5:33 pm on January 13, 2015 Permalink | Log in to Reply

      Shortcake (Shortcode UI)

      • Current status: Early to mid development
      • Who’s responsible: Matt H-Y from Human Made and a few of us from Fusion.
      • Link: https://github.com/fusioneng/Shortcake
      • Whether you’d like the plugin to be considered for 4.2: Could, if there’s interest. We have it in production, and it’s available on WordPress.com VIP. Currently it’s more of a developer API than user-facing feature because it requires code-level configuration. At the least, it would be good to get some core opinions on it.
      • Hugh Lashbrooke 7:09 pm on January 13, 2015 Permalink | Log in to Reply

        This sounds interesting – I’d be keen to get involved here. Will check out the repo.

      • Scott Kingsley Clark 9:47 pm on January 13, 2015 Permalink | Log in to Reply

        Would be a good idea to be sure we’re aligned in approach and what we’re doing between the Metadata project and Shortcake, could share some lessons learned and come up with a solution that has even greater reach.

    • petermolnar 9:00 am on January 14, 2015 Permalink | Log in to Reply

      Filter Post Formats
      If the site supports post formats, we should be able to filter by them on the posts admin.

      ImageMagick Sharpen Resized Images
      Simple Image Sizes
      WP Resized Image Quality
      For those who use WordPress as a portfolio, the default image quality is disappointing. Please let us have the option to change those.

      Thin Out Revisions
      Revisions are nice – unless you have hundreds of them.

      Unattach and Re-attach Media Attachments
      Instead of re-uploading everything, this would be useful.

      WP-Paginate
      The default pagination is way too simple.

      Webmention
      Semantic-Linkbacks
      Pingbacks are dead, long live webmentions.

      • John Blackbourn 10:01 pm on January 14, 2015 Permalink | Log in to Reply

        Can you provide some more info like I asked for? Would you like these plugins considered for 4.2 or later releases? What’s the current status of each?

        • dshanske 1:47 am on January 15, 2015 Permalink | Log in to Reply

          Webmention
          Who’s Responsible: The plugin was developed by Matthias Pfefferle, but I’m not sure if he’s prepared to lead a project on it.
          Current Status: Webmention is fairly mature
          Links – https://wordpress.org/plugins/webmention/ and the Github version https://github.com/pfefferle/wordpress-webmention

          It is basic plumbing for a better alternative to Pingbacks and Trackbacks. Both of those have become so much of a problem that people often disable them. It is time to start building better solutions than disabling them. That comes with a better foundation on which to base enhancements.

          Semantic Linkbacks
          Who’s Responsible: The plugin was developed by Matthias Pfefferle, but I’m not sure if he’s prepared to lead a project on it.
          Current Status: Also mature
          Links – https://wordpress.org/plugins/semantic-linkbacks/ and the Github is https://github.com/pfefferle/wordpress-semantic-linkbacks

          Semantic Linkbacks endeavors to generate richer trackbacks, pingbacks, and ‘webmentions'(see above) by parsing the source URL for microformats, but could also add other types of markup.

          Back to the issue of linkbacks of all types becoming useless…this, combined with webmention, is the start of making linking to other sites a more meaningful thing once more.

        • petermolnar 3:45 pm on January 15, 2015 Permalink | Log in to Reply

          I’m sorry for not being more detailed; I should have been in the first place.
          Thanks for dshanske for stepping in for the webmentions/semantic linkbacks plugin.

          For the rest:

          Thin Out Revisions
          ————————–
          Current status
          Mature and actively maintained.

          Who’s responsible
          blogger323 user.

          Plugin to be considered for 4.2?
          The provided functionality helps cleaning up and maintaining revisions in a nice and user-friendly way; yes, it should be considered might even for 4.2

          WP-Paginate
          ——————
          Current status
          Mature and old project, under active development.

          Who’s responsible
          Eric Martin and StudioFuel users.

          Plugin to be considered for 4.2?
          Not neccessarily for 4.2, but since it provides sophisticated and detailed settings for pagination, including labels, range, etc., therefore it could be considered.

          ImageMagick Sharpen Resized Images
          —————————————————–
          Current status
          Relatively new plugin but actively maintained.

          Who’s responsible

          HansVanEijsden
          and niwreg users.

          Plugin to be considered for 4.2?
          For one of the following versions where the Media Library receives significant updates.

          WP Resized Image Quality
          ————————————
          Current status
          It have not received an update in a long time and seems to be unmaintained.
          The functionality it provides is very useful though, especially for image-heavy portfolio sites.

          Plugin to be considered for 4.2?
          For one of the following versions where the Media Library receives significant updates.

          Unattach and Re-attach Media Attachments
          ———————————————————–
          Current status
          Seem to be abandoned, but the idea it represents should be considered as a feature.

          Plugin to be considered for 4.2?
          For one of the following versions where the Media Library receives significant updates.

    • Dan Nisbet 2:37 pm on January 14, 2015 Permalink | Log in to Reply

      It’s not anything gigantic or groundbreaking, but I created a plugin called Home & Blog Label: https://wordpress.org/plugins/home-blog-label/

      It simply adds a label next to the pages that are set to display blog posts or on the front page when a user sets them under Settings > Reading.

      I’ve been using it on some client websites and people love being able to quickly scan through the list of pages to find the blog or home page when it needs editing. I’d love to see it as part of core.

    • FolioVision 4:05 pm on January 14, 2015 Permalink | Log in to Reply

      Hi John,

      This is a great idea. We’ve always found the comment moderation/management a bit weak (no wonder so many people are using the Disqus crutch). Our plugin Thoughtful Comments supercharges comment moderation by moving it into the front end (i.e. in context). It also allows banning by IP, email address or domain.

      Unlike many comment plugins, Thoughtful Comments works hand in hand with Akismet, feeding all the information into Akismet as well as the existing WordPress whitelist and blacklist features.

      What’s cool about Thoughtful Comments is that you can add it to a WordPress site with no changes to existing comment moderation tables and you can remove it from a WordPress site with no loss of core functionality. I.e. I think Thoughtful Comments could be integrated into core with a minimum amount of pain. Thoughtful Comments works with all current Subscribe to Comment plugins as well. As we use all core functions and tables, Thoughtful Comments works with all current Subscribe to Comment plugins as well.

      Thoughtful Comments is the most powerful and useful code we’ve ever written (we have four very popular plugins). It’s integration into core would save many, many site owners the pain of Disqus.

      1. Thoughtful Comments is entirely stable and active on some of the most heavily commented political and lifestyle sites in the world.
      2. Foliovision is responsible.
      3. https://wordpress.org/plugins/thoughtful-comments/developers/
      4. We’d love to be considered for 4.2.

      I know Automattic has a horse in the ring (Intense Debate) but improving the core comment moderation would be such a great fix. Upcoming: we have additional invisible caching coming for heavily commented posts (so that if there are hundreds of older comments, they get saved as flat html, lightening PHP load and speeding up busy sites significantly.

      Cordial regards,

      Alec Kinnear
      Creative Director, Foliovision

    • aneeskA 5:21 pm on January 14, 2015 Permalink | Log in to Reply

      Current status : stable
      Who’s responsible : aneeskA
      Link to GitHub repo or w.org page, if appropriate : https://wordpress.org/plugins/downml/
      Whether you’d like the plugin to be considered for 4.2 : YES

    • Adam Silverstein 6:12 pm on January 14, 2015 Permalink | Log in to Reply

      Post Meta Revisioning

      Status: In development.
      Who’s responsible: Me, inviting contributors.
      Status: I’ve been working on Post Meta Revisioning (its a feature!) and a handful of related tickets in the Revisions component. I would love to see this considered for 4.2.

      I took the last patch from #20564 and, with the inclusion of two hooks added in 4.1, turned ‘Revisioning of Post Meta’ into a plugin:

      On wordpress.org: https://wordpress.org/plugins/wp-post-meta-revisions/

      Development taking place on github: https://github.com/adamsilverstein/wp-post-meta-revisions/

      I would appreciate any help with testing, patches, review, etc.

      Tickets related to and relying on this plugin:

      #29276 – Ability to edit and preview any revision, not just autosaves
      https://core.trac.wordpress.org/ticket/29276

      #23314 – Allow published posts to be revised without being updated immediately
      https://core.trac.wordpress.org/ticket/23314

      #20299 – Preview changes on a published post makes all post meta “live”
      https://core.trac.wordpress.org/ticket/20299

      #27244 – ‘Restore This Autosave’ immediately updates a published post
      https://core.trac.wordpress.org/ticket/27244

    • jtarrier 3:46 am on January 15, 2015 Permalink | Log in to Reply

      Improved Media Library with user-defined subfolders, taxonomies, categories, “where used” etc.

      The current media library only allows us the choice of uploading into year/month folders or into the “uploads” dumping ground. This is severely limiting and has been in dire need of an overhaul for years.

      The following is a list of plugins which provide much of the desired functionality. The main item of functionality not in the plugins (as far as I have found) is the ability to move media between subfolders and having the database links updated automatically.

      WordPress › Media Library Assistant « WordPress Plugins
      https://wordpress.org/plugins/media-library-assistant/

      WordPress › Support » FANTASTIC app for arranging media library in folders
      https://wordpress.org/support/topic/fantastic-app-for-arranging-media-library-in-folders?replies=1

      WordPress › Media File Manager « WordPress Plugins
      https://wordpress.org/plugins/media-file-manager/

      WordPress › Media Category Library « WordPress Plugins
      https://wordpress.org/plugins/media-category-library/

      WordPress › Enhanced Media Library « WordPress Plugins
      https://wordpress.org/plugins/enhanced-media-library/

    • Weston Ruter 5:09 am on January 15, 2015 Permalink | Log in to Reply

      Customize Partial Refresh

      GitHub: https://github.com/xwp/wp-customize-partial-refresh
      w.org: https://wordpress.org/plugins/customize-partial-refresh/
      Contributors: westonruter
      Status: in development, currently adding partial refresh support for widgets
      Milestone: not concerned to get it into 4.2

      This feature plugin is for implementing what is needed for #27355. As of now it resurrects the partial-refresh functionality from the Widget Customizer plugin and makes it available for Customizer management of Widgets as they exist in Core now. The problem being solved is eliminating the painfully slow Customizer preview update times when a setting transport=refresh. Ideally 100% of changes requiring PHP would be implemented using partial refresh as opposed to a full-page refresh, and this would allow us to do cool things like have Customizer controls appear inline on the frontend without even having to “go into” the Customizer to make changes. Partial refresh is closely related to the work being done on transactions: #30937.

    • Pascal Birchler 9:23 am on January 15, 2015 Permalink | Log in to Reply

      this would allow us to do cool things like have Customizer controls appear inline on the frontend without even having to “go into” the Customizer to make changes

      Ohh this sounds great! Just think of all the use cases for this…

    • Dave Navarro, Jr. 10:25 pm on January 15, 2015 Permalink | Log in to Reply

      I’d really like to see “title” supported with the audio player. It’s supported in jPlayer, but I don’t know how much jPlayer was modified for WordPress as I haven’t been able to find the support code in the WP version.

    • Cătălin Dogaru 10:14 am on January 16, 2015 Permalink | Log in to Reply

      Avatar Manager
      Plugin for storing avatars locally. Started as a core ticket (#16020) some time ago.

      • Current status: Pretty stable, feedback/peer review wanted.
      • Who’s responsible: Me and anyone interested.
      • Links: GitHub, WordPress.
      • Whether you’d like the plugin to be considered for 4.2: Not necessary, depending on your interest. At least, it would be great to set a resolution on it.
      • Dave Navarro, Jr. 8:48 pm on January 16, 2015 Permalink | Log in to Reply

        +1 on this, I really would like to see Gravatar removed from core and left in Jetpack and native avatars used instead.

        • dshanske 11:48 pm on January 16, 2015 Permalink | Log in to Reply

          The agument is that gravatar is an industry standard. Nothing ever seems to leave core though.

          Local storage of information should always be the primary option over polling a third-party site, at least for local accounts.

          Although I’d like to find a good solution for also polling the URL provided by a commenter to get their local avatars also.

      • Cătălin Dogaru 8:49 pm on January 20, 2015 Permalink | Log in to Reply

        Thanks @dnavarrojr and @dshanske for getting involved! Just to be clear, this doesn’t remove Gravatar support. Gravatar is nice; if you’re using it you’re all set! I just want to make it easier for anyone to update (like GitHub did).

        • dshanske 4:40 am on January 21, 2015 Permalink | Log in to Reply

          The counterargument is that gravatar support should be secondary. WordPress is self-hosted, yet has a dependency on a third-party service. I’m not advocating removing gravatar support…It’s been there too long, and too many things depend on it. But I think that infrastructure should be local first, remote second.

          I should be able to tell my install to only rely on local. If you can’t find a local image, use a local default. It should be a choice.

      • Cătălin Dogaru 1:43 am on February 1, 2015 Permalink | Log in to Reply

        For anyone interested, I’ve posted an update on the original ticket. It would be great to see more opinions on this, whether you think it’s suitable for core or not.

    • Merv Barrett 6:33 pm on January 17, 2015 Permalink | Log in to Reply

      Not sure if this is the right place to submit a request for an enhancement to get_template_part() I’ve searched but have not found a request for a core change.

      What would make plugin development much easier for plugins adding custom post types is a filter that would enable filtering of get_template_part() function.

      For example for a post type “property” we would be able to override the get_template_part if the post is being viewed.

      Is this possible to add to the core or are we requiring users to create their own single-property.php and archive-property.php.

      Having a filter would allow plugin developers to replace that with their own function and allow for greater control and compatibility with the thousands of themes. In my case adding to the_content is not sufficient as I would like complete control over the contents of the single and archive pages. Doing this also allows the plugin to inject customised content into the theme design withouth breaking the theme layout. (Every theme is so different in CSS and container elements)

      An example would be

      My plugin creates its own template eg:

      Function epl_single_content() {
      // address
      // bedrooms bathrooms price
      // featured image
      // content
      // features
      // map
      // more stuff
      }
      add_filter( ‘get_template_part’ , ‘$post_type’ , ‘epl_single_content’ );

      This would allow WordPress to be able to deal with custom post types and user skills much easier?

      Thanks

    • Nick Halsey 7:49 am on January 19, 2015 Permalink | Log in to Reply

      Customizer Theme Switcher

      Current status: stable, seeking feedback
      Who’s responsible: me (@celloexpressions)
      Link: https://wordpress.org/plugins/customizer-theme-switcher/
      Whether you’d like the plugin to be considered for 4.2: definitely 4.2 material. Although I only started working on it a few days ago, it’s pretty complete thanks to re-using a lot of code and UI from themes.php. Almost could have been done as a core patch, but this makes testing & iteration easier. Additionally, while a couple minor core patches would help, it’s entirely built on the 4.1 Customizer API. Accessibility should be covered, but it wouldn’t hurt for the team to do an audit. See also #26890.

      I have class during the meeting unfortunately, but if this and Menu Customizer could be discussed in my absence that would be great (I’ll read the archives).

      • Nick Halsey 1:10 am on January 20, 2015 Permalink | Log in to Reply

        Also, a clarification: the plugin simply provides the UI and is functional with the current way that theme previewing in the Customizer works. @westonruter also has some ideas for improving the internals, along with the proposed Customizer transactions API. That’s not a requirement but would be nice to have and will likely end up in 4.2 anyway.

    • Måns Jonasson 10:29 am on January 19, 2015 Permalink | Log in to Reply

      Enable Media Replace

      The plug allows users to replace uploaded media, which is perfect for switching out images or files without having to update URL:s on pages.

      Current status: stable
      Who’s responsible: me (@mungobbq)
      Link to w.org: https://wordpress.org/support/plugin/enable-media-replace
      Link to Github: https://github.com/mansj/enable-media-replace

      I think this functionality should be in core.

      • dshanske 4:36 am on January 21, 2015 Permalink | Log in to Reply

        If it is being looked at to replace uploaded media, is there anything we can do to deduplicate media concurrently? I’ve seen people try to upload the same picture multiple times.

      • enailor 7:56 pm on April 7, 2015 Permalink | Log in to Reply

        Just added this plugin as an idea as well.. did not realize it was already mentioned. I use this awesome plugin for every project I do. Thanks to Måns for this great feature!

    • Helen Hou-Sandi 8:24 pm on January 19, 2015 Permalink | Log in to Reply

      RICG Responsive Images

      Current status: Initial release
      Who’s responsible: Primarily @tevko and @wilto
      Link to .org: https://wordpress.org/plugins/ricg-responsive-images/
      Link to GitHub: https://github.com/ResponsiveImagesCG/wp-tevko-responsive-images

    • Ihor Vorotnov 10:30 pm on January 21, 2015 Permalink | Log in to Reply

      Multilingual core, please. Years are passing and WP is still a single-language platform. I understand, that making core truly multilingual will kick WPML out of business. But hey, it’s a core feature in all platforms. It has to be in core.

      Polylang plugin is the best out there, better than WPML (and compatible with WPML API btw)

      Current status: stable, used by many people on many sites, pretty well maintained
      Who’s responsible: https://profiles.wordpress.org/chouby/
      Link to repo: https://wordpress.org/plugins/polylang/
      Whether you’d like the plugin to be considered for 4.2 – I understand that doing it right will require a lot of work and I suppose it has to be done in small steps. Last year I was talking to plugin author about making some significant and useful changes but we faced lots of limitations of the core. Once these limitations are solved, we will do the rest. So, basically, we just need some core architecture changes that will make it possible to turn Polylang into truly multilingual plugin, flexible and solid. I can describe those changes if there’s interest in at least planning to make it happen.

      • Paal Joachim Romdahl 3:37 pm on February 18, 2015 Permalink | Log in to Reply

        Regarding limitations. What about creating (finding existing) trac tickets to solve the limitations?

        The plugin seems really interesting. I hope you will bring this up again sometime in the future.
        I have added it to my to do list of language plugins to take a closer look at.

    • enailor 7:55 pm on April 7, 2015 Permalink | Log in to Reply

      Sorry I am late to this party, but a plugin that I think is very useful and appropriate is Enable Media Replace. I use this on every project I do and recommend it to anyone.

      WP.org link: https://wordpress.org/plugins/enable-media-replace/

      Måns Jonasson is the author https://profiles.wordpress.org/mungobbq/

      I know its too late for 4.2, but it should be added soon. So many added features around the media uploader and management of media, I am surprised this has not yet been added as a default feature.

      Enable Media Replace allows a user to simply replace an image with a new version, preventing the unnecessary uploading of newer versions of an image in addition to older versions that are no longer needed. Most users, in my experience, do not remove old images from the media library, so the library and hosting account can become bloated with images that are no longer used. being able to simply replace an image with a new one, but keep the original file names, also allows a user to update images without having to find every location of that image on their site. Big advantage if the image has been used on several blog posts.

  • John Blackbourn 5:04 pm on January 7, 2015 Permalink |
    Tags: , ,   

    January 7th meeting agenda 

    The first meeting of the new year and our first post-4.1 meeting. January 07 2015 21:00 UTC. We’ll split this between items for 4.1 and 4.2.

    • 4.1 debrief
    • 4.1.1
    • Review 4.2 schedule
    • Feature plugins for 4.2 and beyond
    • AOB
     
  • John Blackbourn 11:54 am on December 16, 2014 Permalink
    Tags:   

    RC2 and release dry run 

    Various issues which came up over the weekend have meant that we’ve decided to delay the release of 4.1 by another 24 hours. The new target release date is Wednesday 17th December. It doesn’t serve anybody well to delay things this late in the day, but it’s essential to ensure the late fixes which have landed in the last few days are well tested.

    RC2 will be packaged within the next few hours, once the recent batch of fixes in trunk are merged into the 4.1 branch. Here’s the current list of open tickets in the 4.1 milestone.

    We’ll try to fit in a release dry-run meeting today at 17:00 GMT (December 16 2014 17:00 UTC) in #core, depending on the availability of the lead devs.

     
  • John Blackbourn 2:13 pm on December 14, 2014 Permalink
    Tags:   

    Release candidate status meeting 

    Just a quick reminder that there will be a meeting in #core today December 14 2014 20:00 UTC to discuss new tickets that have been reported against RC1 and any other issues from the forums, etc.

    Drop a comment here if there’s anything specific to RC1 that you think needs discussing.

     
  • John Blackbourn 4:15 pm on December 10, 2014 Permalink
    Tags: ,   

    Release candidate and today’s dev meeting agenda 

    4.1 was originally due for release today, but a few tickets in the 4.1 milestone have held things up a little. The release candidate will be tagged in time for today’s dev meeting at December 10 2014 21:00 UTC, and the target release date is now Monday, December 15th Tuesday December 16th.

    Here’s the agenda for today’s dev meeting:

    • Documentation from various make/core posts need to go into the plugin handbook and theme handbook.
    • The 4.1 page on the Codex is in progress.
    • Eyes on the support forums – the alpha/beta forum has seen almost no activity so we need eyes on the forums as a whole.
    • ‘About’ page design – @melchoyce, kelly, @helen #30435
    • Plugin developers – update your plugin’s readme files to indicate support for 4.1 once RC1 is released. You’ve tested all your plugins with the beta, yeah?
    • Looking for something to do? Tickets reported against trunk needs some continued triaging.
    • Status of plugin directory l10n and recommended plugins tab. @stephdau @tellyworth
    • Discuss status of l10ns for polyglots.
    • Discuss a status update meeting type thing on Sunday.
    • Discuss release plan. @nacin
    • Any other business.
     
    • Jeff Chandler 7:26 pm on December 10, 2014 Permalink | Log in to Reply

      One possible reason for the Alpha/Beta forums having low activity is that there hasn’t been much in the way of beta release communication on the WordPress.org development blog. There’s a small mention of a beta at the bottom of the 4.0.1 security update post but that’s from Late November. Hopefully, news of the RC1 release will be published on the official blog and that might get things going again on those forums.

      In that post, I’d also like to see specific items you want people to test.

    • Stephane Daury (stephdau) 8:39 pm on December 10, 2014 Permalink | Log in to Reply

      Plugin Directory l10n

      I’ve just uploaded a major milestone to #760-meta which bring the complete solution to life, as what I’d qualify as a sophisticated proof-of-concept (as in still needs a lot of work/testing but shows everything off):

      • code & readme translation processing
      • localized directories content translation display (wporg code already use gettext for its strings, that’s covered)
      • translation caching policy, as well cache expunging on interaction with translate.wordpress.org (imports, edits, etc)
      • api content translation display when passed a language param (arbitrary, not set-in-stone)

      See screenshots showing it in action here: https://cloudup.com/cmAHT9qu2Wx

    • Lance Willett 8:56 pm on December 10, 2014 Permalink | Log in to Reply

      For release plan, I’ll be on duty to prepare new versions of default themes for submission to Themes directory.

    • Michel - xiligroup dev 12:48 pm on December 11, 2014 Permalink | Log in to Reply

      @john
      Just a question of release : why when, testing feature on a temporary website, updating from admin from 4.1beta2 …734, we arrive directly to 4.2 alpha… and with no RC release…
      Please tell how to fin RC nighty build

    • conservativeread 1:06 pm on December 11, 2014 Permalink | Log in to Reply

      same issue here updating from admin from 4.1beta2 we arrive directly to 4.2 alpha

    • Xavier Borderie 2:03 pm on December 11, 2014 Permalink | Log in to Reply

      @michelwppi @conservativeread As discussed on Slack, “[the developers] branched 4.1 a bit earlier this time, that’s why you’re getting 4.2-alpha. The plugin gives you the nightly build from trunk, not the branch.”

    • Michel - xiligroup dev 4:18 pm on December 11, 2014 Permalink | Log in to Reply

      @[the developers]
      Branching is practical for developers… but not for ‘devoted’ testers… the update page in WP dashboard is unusable with / for RC versions… So need to use again FTP client even on localhost… and avoid again to go to 4.2 alpha… I am sure that developers can solve the UX issue 😉

      • Knut Sparhell 5:09 pm on December 11, 2014 Permalink | Log in to Reply

        I second this. I was really annoyed by experiencing the beta tester plugin took me to 4.2.alpha insted of 4.1-RC1. If you (leads) are going to branch out before last RC in the future please give us a beta tester with three options (point releases, beta/RC or trunk). Those who always want latest alphas select trunk, betaRC-testers select beta/RC. During the cycle we can change option from trun to btea/RC to avoid this, and still have alphas at the start of a cycle.

  • John Blackbourn 7:14 pm on November 26, 2014 Permalink
    Tags: ,   

    Agenda for today’s dev chat in #core Slack (November 26 2014 21:00 UTC).

     
    • Stephane Daury (stephdau) 7:25 pm on November 26, 2014 Permalink | Log in to Reply

      Under “Any other business”: progress on plugin directories (code/readme) internationalization:

      • Good progress, got both plugin code and readme processing (in practice), and GlotPress import (in theory for now).
      • Examples of POT file extracted from IRL readmes: https://cloudup.com/c4-PkWGb7mG
      • Currently: dealing with makepot.php expecting the plugin directory name to match the plugin slug (not so with tmp file), last hurdle before GP import.
    • Alex Shiels 9:04 pm on November 26, 2014 Permalink | Log in to Reply

      Unfortunately I can’t hang around, but I’d like to give #30337 a quick plug – it could use feedback.

  • John Blackbourn 10:35 pm on November 25, 2014 Permalink
    Tags: , , ,   

    An update on shared term splitting 

    Background reading: #30335 and the notes on shared term splitting in https://make.wordpress.org/core/2014/11/20/dev-chat-summary-november-19th/.

    As part of the work on the taxonomy roadmap in 4.1, shared terms (terms which are shared across more than one taxonomy due to a slug collision) now get split when the term gets updated. The end result being that editing a term in one taxonomy will no longer affect the term in another taxonomy.

    Many plugins store term IDs in post meta, options, terms (!), etc, and the side effect of shared term splitting is that these caches can break when the ID of a term they reference changes. Not only that, but the breakage (and the cause) can be invisible to the user and hard to track down if they do notice it.

    Following a discussion in #core Slack I’m proposing that shared term splitting is removed from 4.1 and we’ll add it back in for 4.2 and allow a full release cycle to get the word out to developers about the change. I’ll make the final decision during tomorrow’s dev chat.

    Thanks in particular to @mboynes for his time spent on this.

    (Note that this only affects existing terms; new terms do not get shared since r30240.)

     
    • George Stephanis 3:21 pm on November 26, 2014 Permalink | Log in to Reply

      Sad, but understandable.

    • Eric Mann 3:23 pm on November 26, 2014 Permalink | Log in to Reply

      Considering this change was announced by Nacin in the roadmap for cleaning up terms back in July of 2013, I’m not sure waiting just one more release cycle will give us much more breathing room. We’ve all known this was coming for quite a while, you’re just making the call “when.”

      Whether we release the update in 4.1 or 4.2, there will always be developers who “missed the announcement.” That’s the point of announcing now, reinforcing plugin testing (and updating) during the release beta, and maintaining the “tested up to” in plugin headers.

      Am I concerned we’ll break things by releasing this? Not really. It’s a major release with a generous testing phase that developers should use to their advantage. Anyone releasing a plugin as “tested up to 4.1″ that doesn’t actually test the new term changes is releasing at their own risk.

      • Boone Gorges 4:12 pm on November 26, 2014 Permalink | Log in to Reply

        Eric – I’m sympathetic to this point of view in general – I think that, for a large class of developers, another release cycle isn’t going to make any difference. But I think there’s a not-insignificant group who will be happy to update their sites and plugins, but they’ll need sufficient notice and documentation. And while you’re right that these changes have been in the works for a long time, the specific ramifications and the specifics of the fixes (like the new ‘split_shared_term’ hook) are pretty much brand new.

        Term splitting will be dropped back into trunk immediately after 4.1 is released, and will be accompanied with transition guides for developers. Then we’ll have done our due diligence.

        Believe me when I say that I’m more disappointed than anyone else for this to be delayed yet again. However, we’ve been living with the current situation for years now. Another couple months isn’t going to make a huge difference in the long run.

    • programmin 4:15 pm on November 29, 2014 Permalink | Log in to Reply

      How will this affect those of us using 4.1 Beta1 currently, when upgrading?

c
compose new post
j
next post/next comment
k
previous post/previous comment
r
reply
e
edit
o
show/hide comments
t
go to top
l
go to login
h
show/hide help
shift + esc
cancel
Skip to toolbar