WordPress.org

Make WordPress Core

Updates from Samuel Sidler Toggle Comment Threads | Keyboard Shortcuts

  • Samuel Sidler 8:50 pm on July 30, 2015 Permalink |
    Tags: , 4.2.4   

    WordPress 4.2.4 Release Candidate 1 

    tl;dr WordPress 4.2.4 RC1 is available (download) for testing and fixes an issue with inline scripts.

    A change in WordPress 4.2.3 had the unintentional side effect of breaking some inline scripts when the CDATA block is used (see #33106). For example, consider the intended content here:

    <script>// <![CDATA[
    _my_function('data');
    // ]]>
    </script>

    In 4.2.2, this content is left as is and _my_function() fires as expected. In 4.2.3, the content is manipulated as such:

    <script>// <![CDATA[ _my_function('data'); // ]]></script>

    This results in the script being commented out by the // and it will not fire. A workaround for this is to use /* for commenting.

    <script> /* <![CDATA[ */ _my_function('data'); /* ]]> */ </script>

    However, this workaround should not be necessary. As a result, we intend on releasing WordPress 4.2.4 to fix this issue.

    Additionally, WordPress 4.2.3 caused issues when using shortcodes within angle brackets (see #33116). For example, this shortcode usage worked in 4.2.2 but did not work in 4.2.3:

    <[shortcode]>

    While we do not recommend this use of shortcodes and strongly encourage plugin developers to move away from this use of shortcodes, the breakage was unintentional and we have restored the behavior in WordPress 4.2.4 RC1.

    Please download and test WordPress 4.2.4 RC1 and report any issues to core trac or to this post.

     
    • Mickey Kay 6:54 am on July 31, 2015 Permalink | Log in to Reply

      Yay! Thanks for hearing the community feedback and responding as best you could! It’s much appreciated – thanks for all the hard (volunteer) work.

    • twinsmagic 7:19 pm on July 31, 2015 Permalink | Log in to Reply

      Still is broken for me. I’m merging contact details onto my page and before was able to set the value in form fields automatically but now it shows as half of my shortcode. See this example:

      http://www.blueandgoldentertainment.com/4-2-4-rc1-test/?Email1=test@test.com&mc-firstname=David

      You’ll see merging that sample name and email onto the standard content of the page works fine just not when I have it in the value attribute of the form field, ie: value=”[SHORTCODE]”

    • Dave Navarro, Jr. 5:39 pm on August 3, 2015 Permalink | Log in to Reply

      “While we do not recommend this use of shortcodes and strongly encourage plugin developers to move away from this use of shortcodes”

      From a “user” point of view, using a short code as an attribute in an HTML tag is **VERY** natural. Especially when I am pulling URLs from post-meta:

      <a href="[url_shortcode]">Click Me</a>

      So saying that it’s not recommended seems counter-intuitive to the goal of WordPress being “easy to use”. Especially since it’s BEEN WORKING for years.

    • programmin 6:47 pm on August 3, 2015 Permalink | Log in to Reply

      Will there also be a 4.1.7 update?

    • Mav3000 7:32 pm on August 4, 2015 Permalink | Log in to Reply

      If we’re not to use Click Me and need to insert the site url into a longer url, how are we supposed to do this if not via a shortcode like the above?

  • Samuel Sidler 2:47 pm on July 10, 2015 Permalink |
    Tags: ,   

    Feature Plugin Chat on July 14 

    Hey everyone!

    As I mentioned at this week’s dev chat, we’re going to have a feature plugin chat this coming Tuesday July 14 19:00 UTC.

    If you have an idea that you’d like to propose as a feature plugin or if you have a feature plugin already in development, come to the chat and comment below with the following details:

    • A brief (one paragraph) overview of your feature plugin proposal.
    • Current status (e.g. idea, planning, early/late development, existing plugin, testing, stable, etc). If you’re just in the idea stages, list any existing plugins that are similar to your idea.
    • A list of those involved or already interested in your feature plugin (including you!).
    • A link to the plugin in the WordPress.org plugin directory and/or GitHub repository, if applicable
    • What you’d like help with (scoping, planning, wireframing, development, design, etc).

    Please leave just one comment per feature plugin/idea so others can comment on the ones they’re interested in.

    Current feature plugin leads: We want your feature plugins here too! Please post an update with the information above.

     
    • Pascal Birchler 3:10 pm on July 10, 2015 Permalink | Log in to Reply

      I think there was a discussion about a toolbar feature plugin as mentioned in #32678. Basically, it should explore adding (most of) the admin menu to the toolbar.

      Status: Idea
      Similar plugins: https://wordpress.org/plugins/admin-bar-plus/

      I’d love to help with development and testing.

    • Pascal Birchler 3:13 pm on July 10, 2015 Permalink | Log in to Reply

      At the moment you can’t edit multiple users at once, which is pretty annoying for some use cases. Maybe this is something that should be explored as a feature plugin.

      Status: Idea
      Similar plugins: https://github.com/Automattic/bulk-user-management (old, multisite-only)

      I could help with scoping, planning and development if there’s enough interest. But I’ll probably end up developing something anyway 😉

      Relevant core tickets: #28050 and #32356

    • BrashRebel 3:49 pm on July 10, 2015 Permalink | Log in to Reply

      The TV team is collaborating on a plugin which places tutorial videos in the contextual help menu. The videos come from WordPress.tv and provide a visual walkthrough of the current screen in the wp-admin. The plugin is being developed for the purpose of assisting beginner WordPress users through video. The idea of proposing it as a future feature plugin has been briefly discussed.

      Current status: existing plugin
      Interested parties: @brashrebel @jerrysarcastic @roseapplemedia @ubernaut @johnparkinson
      Github: https://github.com/brashrebel/wptv
      We’d like help with:

    • jrf 4:37 pm on July 10, 2015 Permalink | Log in to Reply

      > Overview of your feature plugin proposal.

      Dependency management for themes and plugins the WordPress way.
      Allow themes and plugins to indicate dependencies on (other) plugins and providing an easy way for admin users to install, update and activate those. Will include activation prevention if dependencies are not met and providing cascading deactivate of dependents when a providing plugin would be deactivated.

      > Current status

      Existing external library which is widely used. +/- 6% of all themes in the repo use it, also used by a large number of premium themes and numerous plugins.
      A large refactor is planned and knowing what parts would be acceptable for core would be useful before starting the refactor.
      Roadmap for refactor from before this proposal (open to change per scoping): https://github.com/TGMPA/TGM-Plugin-Activation/issues/394

      > People involved

      Thomas Griffin – Project Owner & creator of the original TGMPA library
      Gary Jones – Project Lead
      Juliette Reinders Folmer – Lead Developer

      Suggesting this as a feature plugin is inspired by numerous users who keep suggesting it should be part of core.

      > Link

      https://github.com/TGMPA/TGM-Plugin-Activation/

      > What you’d like help with

      Scoping: the libary currently features some functionality which may or may not be acceptable for core. Advise on this would be helpful before starting the refactor.
      Ref: https://docs.google.com/document/d/1abkiqT15SSboJVF8a16QDOL8o8Ocy4EHxsoZKwuwMFY/edit?usp=sharing

      Placement in the admin/user interface: currently plugins and themes can influence where the admin screen for TGMPA will show up. In the roadmap for 3.0 we’ve already included removal of this functionality and creating a set place for the admin page. Thoughts on where this should be and/or whether this should be integrated in an existing admin page would be helpful.

    • Daniel Bachhuber 9:41 pm on July 10, 2015 Permalink | Log in to Reply

      Overview

      Shortcake adds a user interface to shortcodes.

      Status

      Late development. The next slated version is 0.5.0. You can easily skim through many discussions to date.

      Involved

      @danielbachhuber, @mattheu, @goldenapples, @davisshaver and others

      Links

      https://wordpress.org/plugins/shortcode-ui/
      https://github.com/fusioneng/Shortcake

      Get Involved!

      At this time, we’d very much appreciate involvement in the form of documentation and user testing.

    • Nick Halsey 6:48 pm on July 12, 2015 Permalink | Log in to Reply

      Customizer Theme Installer
      Customizer theme installer would build on the Customizer Theme Switcher plugin merged in WordPress 4.2, bringing .org-repo-browsing and theme installation into the Customizer experience. The current idea is that entering theme-installation mode would bring the Customizer controls area full-width, hiding the preview, and the different tabs on the existing admin screen would be available, along with an “installed” tab. This would incorporate “shiny” theme installs – for each theme there are two options: “install” and “install & preview”. We would remove the existing theme-install previewer and instead offer the ability to download a theme and preview it in the Customizer with your actual site in one click. The basic install action would allow multiple themes to be installed at once, then the user could go through them to preview within the Customizer using the existing workflow.

      Current status: idea/design/wireframing

      Involved: @folletto and I (@celloexpressions) have tossed several ideas around and done some initial branstorming and wireframing, building on the work done in 4.2. I was originally planning on working on this for 4.3, but did Menu Customizer instead. I’d like to set up a meeting in the next couple weeks to get going on this effort and try to develop a merge-ready plugin by the time 4.3 is released, to be ready for merge in 4.4. Based on Customizer Theme Switcher (which was developed in only a few days), this effort will likely be more design/UX-heavy than development-heavy.

      • Paal Joachim Romdahl 7:02 pm on July 13, 2015 Permalink | Log in to Reply

        Features added to the customizer will these also be added outside of the customizer as well? For instance to the settings section. (Just thinking in general here).

    • Nick Halsey 7:51 pm on July 12, 2015 Permalink | Log in to Reply

      Background Image Cropper
      This plugin adds cropping to background images, to bring the feature into closer parity with header images. The plugin is currently awaiting review for the plugin repo, but is trivial code-wise and more about deciding whether this is a feature that users need/want. See also #32403.

      Current Status: Late development. The plugin is not currently functional due to a critical core bug in trunk that will be resolved in #29211 (specifically, it prevents the Customizer from loading, but there are additional issues that need to be cleaned up with the new API here). Once that core ticket is resolved in 4.3, the plugin will be fully functional and only potentially require minor tweaks.

      Involved: @johnbillion first proposed the idea in #32403, and I’ve built the plugin. Now, this feature is all about getting the word out about the plugin (once 4.3 is out, since that’s the required version), and gauging user interest. I suspect that we may run into issues here with some of the broader problems with the background images feature, and it remains to be seen whether cropping should be introduced without exploring broader changes here. Feedback and ideas welcome.

      https://wordpress.org/plugins/background-image-cropper/

    • Nick Halsey 8:06 pm on July 12, 2015 Permalink | Log in to Reply

      Customizer UI Experiments
      Customizer UI Experiments is a new feature-plugin designed to be used on an ongoing basis for testing smaller UI/UX changes in the Customizer before rolling them into core. It contains several components that can be merged into core and subsequently removed from the plugin on an individual basis, with new components added as ideas are proposed. This single plugin to cover several distinct proposals allows testers to evaluate UI changes without wading through patches on different tickets scattered throughout trac. It also gives us a place to evaluate patches with feedback from a larger audience, hopefully improving our processes around UI-related Customizer tickets, which have had issues in the past. As a general rule, components added to this plugin should have a trac ticket first. This is a great plugin for multiple people to have commit access to, so if you’re interested in working on it (primarily porting patches to plugin form, and maintaining the plugin as components are added, updated and removed), please let me know and I can add you.

      The plugin is awaiting review on the .org repo, and initially contains an implementation of the patch on #32296. Components implementing #31195 (device-preview buttons) and #29158 (testing approaches to increasing visual contrast and improving focus styles for accessibility) are in the works as well.

      Current Status: This is a slightly different type of feature-plugin, so it will always be in a stable mode where testers can try it out (and leave it on) on their sites, with features coming in and out as they’re developed and merged into core. This is a sort of preview and testing ground for minor changes and features to come. Scope is strictly limited to changes with the Customizer UI itself – this plugin should avoid implementing larger features that add new panels/sections/settings/controls. Once the plugin is available on .org, I’ll link it on the tickets that it implements currently.

      Involved: I’ve done the initial development and scoping, with @voldemortensen already volunteering to help out and have commit access. Anyone interested in welcomed to jump in on Customizer-ui-related trac tickets and ping us in #core-customize or #design on Slack to discuss ideas.

      https://wordpress.org/plugins/customizer-ui-experiments/

    • George Stephanis 4:57 pm on July 13, 2015 Permalink | Log in to Reply

      Two-Factor Authentication

      Simple username/password authentication is fast becoming insufficient for the modern web. Several plugins so far have begun implementing methods for running two-factor authentication through varied systems, but none of them play well with one another. Our goal is to get a framework for two-step, two-factor authentication into core with several default providers (emailing a code, TOTP, and FIDO U2F) that core can support without any dependency on external providers, and keep it extensible, so that third-party plugins can add in new methods, such as Clef or TXT codes.

      Current Status: Active development, probably ~60% complete. Some providers need fleshed out, and the system needs backup provider support and some UI help. Also probably needs a couple audits from varied perspectives to make sure it solves everyone’s use cases and is accessibility friendly.

      Interested folks (who have expressed interest on Twitter or directly):

      @JeffMatson
      @brennenbyrne (and the Clef gang)
      @nikv
      @ericmann
      @daveross
      @jjj
      @moonomo
      @rezzz-dev
      @morganestes
      @voldemortensen
      @mor10
      @kraftbj
      @johnbillion
      @michael-arestad

      Probably some others I’ve missed.

      Current repository: https://github.com/georgestephanis/two-factor

      I’ve got the plugin approved for the .org repo, I just wanted to get backup methods fleshed out before starting porting it across.

      What we need help with: Code audits, design help, security audits, accessibility audits, development time fleshing out providers.

    • Weston Ruter 10:54 pm on July 13, 2015 Permalink | Log in to Reply

      Customize Partial Refresh

      Refresh parts of a Customizer preview instead of reloading the entire page when a setting changed without transport=postMessage. The goal with this plugin is to eliminate full-page refreshes as much as possible, as they are extremely bad for performance. This has been implemented in Core now for menus in the Customizer as of 4.3 beta. This plugin currently implements partial-refresh for widgets, but it also will abstract the functionality into a general API for developers to register their own partial-refreshable regions. This plugin has been floating around as a feature plugin for awhile. Blue sky: if we can eliminate full-page refreshes, we can start to introduce controls inline with the preview (e.g. widget controls appearing with their widgets), and even eliminate the Customizer iframe altogether since the Customizer pane could then slide-in on any existing frontend page the user is on without having enter into a completely different Customizer state; when done, they can just collapse the Customizer away and continue on their way browsing the site.

      Current status: existing plugin, development, testing

      Contributors: @westonruter

      Project links:
      https://wordpress.org/plugins/customize-partial-refresh/
      https://github.com/xwp/wp-customize-partial-refresh

      Areas to contribute: identifying use cases and designing API for registering partial-refreshable region.

    • Pascal Birchler 12:59 pm on July 14, 2015 Permalink | Log in to Reply

      oEmbed for WordPress Posts

      Basically, we want to make WordPress an oEmbed provider. Users should be able to paste an URL from a WordPress blog and the post gets embedded right away. Difficulties here are discovering other WordPress sites as oEmbed providers and whitelisting them. The oEmbed endpoint requires the WP-API to be in use, so this can’t land in core until the API does.

      Current status: Idea / early development. There’s an existing plugin on GitHub we can build upon and we already have mockups of the desired end result.

      People already involved:

      @swissspidy
      @melchoyce
      @pento
      @folletto
      @markhowellsmead

      And all the others who have joined the discussion on Trac.

      Project links

      Ticket: #32522
      Plugin on GitHub: https://github.com/swissspidy/oEmbed-API

      What we need help with: Mostly design and development, especially the oEmbed auto-discovery part.

      I’ll be around tonight for the chat, the others can’t make it unfortunately.

    • Ryan McCue 4:43 pm on July 14, 2015 Permalink | Log in to Reply

      Overview

      The WP REST API adds a JSON-based REST API to WordPress, allowing accessing and modifying your site from a modern API.

      Status

      Ready for merge (version 2). Always more work to continue in the meantime.

      Involved

      @rmccue, @rachelbaker, @danielbachhuber, @joehoyle

      Links

      https://wordpress.org/plugins/json-rest-api/ (v1 only)
      https://github.com/WP-API/WP-API

      Get Involved

      We’re mostly deep focussing on getting it ready for merge, but we always need help on documentation and associated projects (OAuth, Basic Auth, client SDKs).

    • Joe McGill 1:25 am on July 15, 2015 Permalink | Log in to Reply

      For posterity…

      **RICG responsive images**

      **Big idea:** to bring responsive image markup natively into WP core.

      **Current status:** In development, stable (8,000+ active installs) could be considered for a 4.4 merge but will need some shepherding.

      **Plugin devs:** @tevko, @joemcgill, @dnewton, @jaspermdegroot, with consultation from @wilto (and a host of others).

      **Links:**
      WP.org: https://wordpress.org/plugins/ricg-responsive-images/
      GH: https://github.com/ResponsiveImagesCG/wp-tevko-responsive-images

      **Get involved:** We could use dev feedback, more testing (particularly against non-standard setups).

    • dshanske 2:01 am on July 15, 2015 Permalink | Log in to Reply

      Overview #32844 – There is interest in trying to put together a group to work on revamping Post Formats. This would not necessarily be the Post Formats UI that has laid dormant since 3.6, but a serious look at the feature as it exists today and how it can be refined in the same way the long-abandoned Press This feature was refined.

      I’m not looking to propose something with the scope of the WordPress 3.6 work, as I think the starting work is refining how Post Formats work. This includes better defining their use, producing examples of the types(documentation), looking for opportunities to better integrate them into existing parts of WordPress and enhance their functionality.

      https://core.trac.wordpress.org/ticket/32844#comment:21

      I think @helen laid out a reasonable list of goals.

      “…existing content must be considered, as well as migration paths for those who currently use plugins/themes that store into meta. This may include things like auto-detection in Press This, modular content building, creation-only UI affordances, and so forth.”

      @dshanske
      I’m willing to put in some time on this, and contribute out of my limited ability. Looking for interest.

    • Ryan Boren 2:36 am on July 15, 2015 Permalink | Log in to Reply

      Carousel

      Working on the latest Today in the Nightly post reminded me that I’ve been wanting a carousel feature plugin. The galleries on this post are handled by Jetpack’s carousel. Clicking/tapping an image pops up the image in a modal. The single images are not handled by JP’s carousel. They get the core behavior of following the bare image link. This is a bad experience, especially on mobile. Even on desktop, clicking the single images is a far worse experience than the carouseled images. Bare image links present no nav. You’re only way back is browser back history. This should work out of the box.

      https://make.wordpress.org/flow/2015/02/26/core-support-for-wordpress-images-to-open-in-a-modal-window/

      https://core.trac.wordpress.org/ticket/31467

  • Samuel Sidler 2:32 pm on April 25, 2015 Permalink |
    Tags:   

    WordPress 4.1.3 Released 

    Shortly after we shipped WordPress 4.2, we shipped WordPress 4.1.3 to fix an issue caused in WordPress 4.1.2.

    Specifically, WordPress 4.1.3 fixed database writes for esoteric character sets, which were broken in the WordPress 4.1.2 security release. However, neither UTF-8 nor latin1 were affected. More information on this issue can be found in #32051.

    Additionally, we shipped WordPress 4.0.3, 3.9.5, 3.8.7, and 3.7.7 to fix the same issue on other branches.

     
  • Samuel Sidler 8:13 pm on September 16, 2014 Permalink
    Tags: ,   

    Feature Plugin Chat on September 23 

    Last week we mentioned holding a feature plugin chat today, but that didn’t happen. Let’s have it next week on September 23 2014 20:00 UTC.

    We’ve done this before, but just to recap…

    If you have an idea for a new feature, this will be a great opportunity to bring it up and find others interested in helping out.

    Please leave one comment per feature idea with the following information:

    • A brief (one paragraph) overview of your feature plugin proposal.
    • Current plugin status (idea stage, planning stage, under development, existing feature plugin, prior work, etc).
    • A list of those involved or already interested in your feature plugin (including you!)
    • What you’d like help with (scoping, planning, wireframing, development, design, etc).

    This post and the accompanying chat are for posting ideas that you’d be interested in working on. It is not for posting every feature idea you have for WordPress.

    Current feature plugin leads: Please post an update for your plugin here, along with the information above.

    See you all at the chat!

     
    • Nikola Nikolov 10:08 pm on September 16, 2014 Permalink | Log in to Reply

      The meeting is going to be held in #wordpress-dev channel right? I’m adding the time & date to my calendar :)

    • Caspar 5:35 am on September 17, 2014 Permalink | Log in to Reply

      Added to calendar, thx!

    • Peter Luit 7:35 am on September 17, 2014 Permalink | Log in to Reply

      In general the installation of plugins will have to be done on a site-by-site base. It would be very nice to have the possibility to have pre-defined sets of plugins for certain applications. Now we can just ‘favorite’ a plugin at wordpress.org, in others words ‘you make one set’. Would it be a nice idea to be able to make more sets?

      It could be done in wordpress.org, but it would also be great to have one plugin-installer (as a plugin) in which you can choose one of your own pre-defined sets and then download them all…..

      I am sure the WordPress community would love such a feature.

      Kind Regards,

      Peter Luit
      The Netherlands

    • Siobhan 1:13 pm on September 17, 2014 Permalink | Log in to Reply

      Image Flow is a project focused on improving the the image editing experience in WordPress.

      Current status: UX and wireframes
      Already involved: siobhan, @mor10, @sonjanyc, @markoheijnen, @dh-shredder, @pablo-perea, @edwerd, @klosi, @teamadesign (also less active ppl in the chat room and lots of feedback from people on the UI blog – apologies if I’ve missed anyone).
      What we’d like help with: development (particularly JS), ui design, research, labelling, testing

      • Ryan Boren 12:59 pm on September 18, 2014 Permalink | Log in to Reply

        You know how desperately I want to improve media flow. I’ll be around for research and testing, particularly on mobile.

        Usability as a feature. A featured flow for each release. Each screen of that flow and every tap and click gets attention, on all devices and across all interfaces. 4.1: Starting on your blog’s home page, create and publish a captioned gallery of edited images.

      • Andy Mercer 1:24 pm on September 22, 2014 Permalink | Log in to Reply

        Given that we have Featured Images, would anyone else be interested in the concept of Featured Galleries? Being a metabox, like the Featured Img metabox, which would allowed a user to select multiple images, and be called in a theme template the same way?

    • Nick Halsey 5:08 am on September 18, 2014 Permalink | Log in to Reply

      I have a class during the meeting, so I won’t be there. But I’d like to officially introduce the Menu Customizer as a feature-plugin seeking contributors.

      Menu Customizer is my GSoC Project that I’d now like to build out as a feature-plugin with the help of anyone else who’s interested. The goal is to merge navigation menus into the Customizer. Ideally, this should be done in a feature-complete and backwards-compatible way that allows the mess that is nav-menus.php to go away entirely for users who have access to the Customizer. In addition to leveraging the live-previewing framework that the Customizer provides, this project seeks to improve the user experience of menus as well as fixing several significant technical issues with the current implementation (particularly, scaling). The project is similar to the Widget Customizer project that landed in 3.9 in many ways.

      Current plugin status: development. The plugin is mostly functional, implementing the entire menu-management experience in a Customizer panel and allowing menus to be live-previewed. However, significant work remains to make things scale even better, improve the add-menu-item experience, improve the handling of sub-menus, and make menu-addition and deletion work more smoothly. Many improvements to WordPress core have already come out of this project, including the panels API, and those will need to continue before the plugin is ready to be merged (in particular, for 4.1, #29572 and #28709).

      To date, I’m the only developer working on the project, per GSoC regulations. But the project is now officially open to contributions. I’m in the process of getting set up on plugins trac with @samuelsidler and will be scheduling weekly meetings soon. @ethitter and @obenland are also familiar with the project, as they were my GSoC mentors.

      We need help with the following: development, particularly some JS-heavy components, but also on the PHP side. UI/UX, workflow research, and user testing. Changing the relationships between pages/posts and menus is not in scope, but for the first iteration we’d like to offer a much-improved UI/UX that fixes many issues with the current workflow. This particular project requires significant dev work regardless, which is why formal UI/UX work is happening mid-development. If you’re interested in helping out in any way, please leave a comment here or say something at the meeting (I’ll read the logs), and we can try to schedule the weekly meetings at a time that works for everyone.

    • Aaron Jorbin 9:17 pm on September 22, 2014 Permalink | Log in to Reply

      WP Session manager is a UI around user sessions. We aim to provide users with controls on the user profile screen and user editing screen for managing logged-in sessions.

      Current Status: Under development at https://github.com/johnbillion/wp-session-manager

      Current Team: @johnbillion, @DrewAPicture, @nacin, @jorbin

      What we want help with: Development, design (our UI/UX is currently functional and inline with core, but can always be improved)

    • M. Gage Morgan 11:38 pm on September 23, 2014 Permalink | Log in to Reply

      I think we should bring the post formats UI back again, this time with the new steps added to the process (3.6 “Oscar”).

      Current Status: Needs extracted from the old core files, we’d need somebody to do that. Still in the technical “idea stage.”

      Current Team: Myself, as a student, plus anyone who would be willing to volunteer.

      What I Need Help With: Porting the old files to WP 4.0.(Plus plugin development, I’m new here.)

      • Samuel Sidler 11:40 pm on September 23, 2014 Permalink | Log in to Reply

        There was some interest in this previously, but I’m not sure there’s enough to get it off the ground. If you’re willing to work on it, feel free. Things will have to be quite a bit different for it to be incorporated into core, so keep that in mind. I’d recommend starting from scratch design-wise, going through the steps that the Image Flow team is doing.

    • M. Gage Morgan 12:34 am on September 24, 2014 Permalink | Log in to Reply

      I would think it’s more than possible to do, but it would likely not be ready by 4.1, rather 4.2 or 4.3. I’ll try to work when I can, but scheduling is complicated.

      • Samuel Sidler 12:36 am on September 24, 2014 Permalink | Log in to Reply

        Keep in mind that feature plugins aren’t targeted at specific releases. Inherently they’re flexible and can ship when they’re ready. It’s also possible that a feature plugin never gets into core. That’s fine too. Experimentation is good.

    • Daniel Bachhuber 10:20 pm on September 29, 2014 Permalink | Log in to Reply

      A pretty consistent problem I run into is shortcode UX. Specifically:

      1. Remembering what shortcodes are available to a given site.
      2. Remembering what attributes each shortcode supports.
      3. Preview disconnect (shortcode ain’t WSYWIG)

      It would be neat to have UX in WordPress for selecting from available shortcodes, filling out required vs. optional attributes, and TinyMCE preview framework for registering a display callback for a shortcode.

      I’d be interested in working on this. I’d be best supported with UX help. And I’m pretty curious as to why this problem hasn’t been solved yet (e.g. what big gotchas we’re going to run into).

  • Samuel Sidler 4:37 pm on April 28, 2014 Permalink
    Tags:   

    Feature Plugin Chat tomorrow 

    As mentioned at the dev chat last week, we’re having a feature plugin chat tomorrow, April 29, 2014 20:00 UTC in #wordpress-dev. That’s the same time, same place as the dev chat on a different day. (The dev chat will take place on Wednesday, like normal.)

    Just like we did before, post your feature ideas here in one comment with the following information:

    • A brief (one paragraph) overview of your feature plugin proposal.
    • Current plugin status (idea stage, planning stage, under development, existing feature plugin, prior work, etc).
    • A list of those involved or already interested in your feature plugin (including you!)
    • What you’d like help with (scoping, planning, wireframing, development, design, etc).

    Again, this post and the accompanying chat is for posting ideas that you’d be interested in working on. It is not for posting every feature idea you have for WordPress.

    Current feature plugin leads: Please post an update for your plugin here, along with the information above.

    We’ll go through current feature plugins at a brisk pace, then talk about the new ones that are forming.

    See you tomorrow!

     
    • mttktz 6:38 pm on April 28, 2014 Permalink | Log in to Reply

      I think WordPress lacks a feed reader.

      If you look at the most popular new blogging platforms: Facebook, Twitter, Tumblr, etc, they all have a way for you to see what others are writing and then re-blog or re-share that info. It’s a key feature that lets people communicate with each other. I’d like to see WordPress do this well, to have a feed reader integrated into the admin site with the ability to blog and comment on what you are reading in the world. It’s a feed reader with integrated “PressThis!”

      I’ve made a rough edged version of this plugin that works and people have started using it without me promoting it at all.
      See: http://mattkatz.github.io/Orbital-Feed-Reader/

      It’s just me working on it so far.

      I’d love help with design and development. Any advice appreciated – I think this is a big feature for WordPress-as-blog rather than WordPress-as-CMS.

      • Tomas Mackevicius 3:03 pm on May 1, 2014 Permalink | Log in to Reply

        Good idea! Are you using internal SimplePie library to produce the feed? I noticed that if it takes a bit more time to get the complex feed (I was trying to parse Yahoo Pipes feed), SimplePie would render an empty page with an error message :(

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

      The JSON REST API is marching towards 1.0, with all the pieces beginning to fall into place. We want in on 4.0, and we’re determined to merge this cycle. :)

      For anyone who hasn’t seen the project, we’re working on providing a JSON-based API to access all your data in WordPress. Work on the project is happening over on GitHub, and we chat about the project over on our o2.

      We’re always seeking people to help, and we’d especially love some designers to help out with some UI pieces. If anybody’s using the API, we’d also love to hear about that and your experiences with using it!

      (I’ll endeavour to be present at the meeting tomorrow, however if I don’t make it, Rachel Baker will be present on the team’s behalf.)

    • Manny Fleurmond 3:58 am on April 29, 2014 Permalink | Log in to Reply

      I know the that the last time the post formats feature was proposed to get an overhaul there were kinks and setbacks to be had. My proposal, which might be a bit controversial, is this: instead of post formats being lumped together with the main post type, I believe they should be split up into their own post types.

      I wrote a blog post a few months ago about this a few months ago but to sum it up: I think post formats are an arbitrary distinction that causes confusion to WordPress users. They are technically types of posts, so why can’t they be post types? My proposed set of features is as follows:

      1. The ability to allow individual formats to be enabled/disabled
      2. The ability to allow individual formats to be included or excluded from the main loop.
      3. Rework the quickdraft meta box on the dashboard to allow the choosing and quick posting of different post formats, using some of the old code/interface from the last attempted redesign
      4. They should be extensible, via the new meta field initiative
      5. Stricter definitions of said post formats.

      I’ve only done some brainstorming, specifically with the more media based formats, which I plan to enhance via some of the new media modals now available since WP 3.9 (audio, video and playlists). That being said, I would love feed back in planning and developing such a plugin. I think that this would help make post formats a lot more accessible and less confusing.

    • trishasalas 12:24 pm on April 29, 2014 Permalink | Log in to Reply

      Admin Help is in the initial stages of project scope and planning. Our goal is to make the WordPress Admin area easier, and more intuitive to use and to hopefully reduce the attrition rate in the process. The focus is on the existing Admin Help documentation with the knowledge that it could be completely re-written or morphed into a more intuitive UI. The idea of a tour has been mentioned many times in the past, but we are beginning with user testing to make sure that we solve the correct ‘problem’.

      We are currently in the planning stage doing user-testing, personas, storyboards and discussion. Project scope is also a focus because we want to keep the initial idea at a manageable level (i.e. we do *not* want to re-do the entire admin area!)

      Those currently involved include myself (@trishasalas) and @clorith as co-leads, @jazzs3quence, @ubernaut, @brainfork and @jerrysarcastic. @designsimply is helping with user testing.

      Our biggest need is to have more people familiar with user help/user support and those who are familiar with UI/UX design. The more input we have during the initial planning stages, the more successful we’ll be.

    • Svetoslav Marinov 12:58 pm on April 29, 2014 Permalink | Log in to Reply

      Hi,

      Plugin: Orbisius Quick Nav
      Info: This plugin allows you to quickly switch between pages, posts, or any other custom post types from a dropdown.
      Status: up and running at https://wordpress.org/plugins/orbisius-quick-nav/
      Who is involved: just me (but I am both using my personal and company WP accounts)
      Need help with: ideas people, testers and programmers.

      Slavi,
      http://Orbisius.com

    • Michael Arestad 6:50 pm on April 29, 2014 Permalink | Log in to Reply

      Press This is a redesign with a focus on automation and speed. It will have a simplified interface, efficient media upload, and site switching.

      The plugin is currently in the idea stage You can see discussion and progress at corepressthis.wordpress.com

      I am the project lead (@michael-arestad) and those who are involved or have shown interest are:
      @melchoyce, @bilalcoder, @danielbachhuber, @folletto, @georgestephanis, @helen, @ryelle, @morganestes, @ryan, @stephdau

      If you’re interested in contributing, ping one of us on IRC and we’ll add you to the Skype Group and blog.

    • Dave Navarro, Jr. 7:51 pm on April 29, 2014 Permalink | Log in to Reply

      Native support for mobile platform detection is critical, in my opinion. Check out the Mobble plugin (https://wordpress.org/plugins/mobble/) which adds functions for detecting the OS and device characteristics.

      Mobile web sites and Responsive web sites are NOT the same thing and right now we can create responsive sites with CSS, but we can’t create Mobile sites without help. A mobile site doesn’t just HIDE elements on mobile devices, it never even sends the data (like unregistering widget areas on mobile to prevent data from widgets being sent).

    • John Blackbourn 8:46 pm on April 29, 2014 Permalink | Log in to Reply

      I know I’m late but I’d like to look into improvements to user profile editing in core. I’ve recently looked at quite a few plugins which add the ability to upload an avatar in addition to Gravatar, and I’ve been looking at how WordPress.com does this, as well as how it separates the screens for managing your profile and managing your user settings.

      Current status: Idea and research stage.

    • shaunandrews 8:47 pm on April 29, 2014 Permalink | Log in to Reply

      Sorry for the late reply, I wasn’t sure if I could make the meeting today (which is in progress), but I wanted to mention that there’s a group of people working on the media-grid plugin: https://make.wordpress.org/core/2014/04/22/remember-the-media-grid-project-it-was-original/

      We had a single meeting (which I also missed, due to being a fool and confusing timezones), and are just gearing up. I’m @shaunandrews) planning to lead the project, and we have @helen, tillkruess, caseypatrickdriscoll, jcastaneda, kopepasah, klihelp, and ericlewis all showing interest in helping.

      We’ve got a GitHub repo: https://github.com/helenhousandi/wp-media-grid-view/

      I’m considering setting up a WordPress.com blog and/or a group Skype chat to help keep us all connected. Hit me up on Skype (shaun.andrews) or email (shaun@automattic.com) if you’re interested in helping.

      • Dave Navarro, Jr. 9:31 pm on April 29, 2014 Permalink | Log in to Reply

        Would love to see the ability to use a Taxonomy (separate from categories) to better organize media. I have sites with 10’s of thousands of media items and it’s a PITA to browse all that.

        • shaunandrews 12:22 am on April 30, 2014 Permalink | Log in to Reply

          Some sort of grouping (or, collecting) is in our plans, but its too early to know how that’ll shape up. If you have any specific thoughts on the matter, please feel free to share :)

    • pressupinc 9:13 pm on April 29, 2014 Permalink | Log in to Reply

      I’d like to build a version with more consistent written tone that is less colloquial–especially around error messages (e.g. “Are you sure you want to do this?” and the default 404).

      I have a few people interested in work on the project, and have done a survey to see what tone most community members would like to see.

      • John Blackbourn 10:17 pm on April 29, 2014 Permalink | Log in to Reply

        This has been brought up before. If you have a search through Trac you’ll probably find a couple of tickets relating to changing of phrases in core. Do you have a link to your survey?

        That said, this isn’t related to feature plugins. A better place to discuss it would be in a ticket on Trac.

    • vivekgounder@gmail.com 1:53 pm on May 1, 2014 Permalink | Log in to Reply

      Congrats Helen :)

  • Samuel Sidler 10:22 pm on March 19, 2014 Permalink
    Tags: ,   

    GSoC Chat Tomorrow 

    For those interested in Google Summer of Code, we’ll be holding a chat tomorrow on IRC in #wordpress-gsoc, March 20, at 18:00 UTC (2pm EDT, 11am PDT). Bring your proposal along and you’ll have five minutes to talk through your proposal with mentors. We’ll try to fit everyone.

    If you haven’t already, be sure to submit your proposal as soon as possible. There’s not much time left to get feedback prior to the submission deadline! Keep in mind that you can modify your proposal up until the deadline.

    See you all tomorrow!

     
    • Andrew Nacin 10:25 pm on March 19, 2014 Permalink | Log in to Reply

      The deadline is Friday, March 21 at 19:00 UTC..

      Worth pointing out that you can edit your proposal after it is submitted, up until the deadline. After that, you can still comment on your proposal, such as if any mentors ask you questions.

  • Samuel Sidler 4:40 pm on February 27, 2014 Permalink
    Tags:   

    Feature Plugin Chat on March 4 

    As mentioned at this week’s and last week’s meeting, we’re going to be holding a feature plugin chat on March 4 2014 21:00 UTC. If you have an idea for a new feature, this will be a great opportunity to bring it up and find others interested in helping out. In fact, just like we’ve done before, post your feature ideas here.

    Please leave one comment per feature idea with the following information:

    • A brief (one paragraph) overview of your feature plugin proposal.
    • Current plugin status (idea stage, planning stage, under development, existing feature plugin, prior work, etc).
    • A list of those involved or already interested in your feature plugin (including you!)
    • What you’d like help with (scoping, planning, wireframing, development, design, etc).

    This post and the accompanying chat is for posting ideas that you’d be interested in working on. It is not for posting every feature idea you have for WordPress.

    Current feature plugin leads: Please post an update for your plugin here, along with the information above.

    See you all at the chat!

     
    • scotthack 4:52 pm on February 27, 2014 Permalink | Log in to Reply

      I’d like to see a plugin built that will accept an XML file to import custom post types and taxonomies. That way theme authors can just provide an XML file with their themes. Then the end user can use the import file to create custom post types and taxonomies and it would be imported independent of the theme.

      This is in the idea stage. My coding skills are very basic, so I’d be of little to no help in the coding department. It would need to be picked up by a competent programmer to actually see it through. I’m only able to help with testing, feedback, and idea conception.

    • UaMV 5:33 pm on February 27, 2014 Permalink | Log in to Reply

      Extend proper author/contributor support when defining custom post types. Currently, when a CPT is registered with support for ‘author’, the metabox returns a list of users with the author role (even if those users don’t have ‘edit_posts’ capability for the CPT. Even in the standard post editor, the author metabox includes only users with an author role, not necessarily those who can contribute (or have edit_posts capability). I believe this metabox should return any user that has the ‘edit_posts’ capability for the specific post type in which the author metabox is being supported.

      There is currently a plugin, Authors Autocomplete Meta Box, in the repository that extends this functionality.

      Rachel Carden (aka bamadesigner) is the author of this plugin (commissioned by ereleases.com). I have, as of yet, had no contact with her regarding the plugin, but find it of great use on my site with multiple CPTs and multiple custom roles.

      Not sure at the moment how I might assist.

    • Avryl 6:36 pm on February 27, 2014 Permalink | Log in to Reply

      The Front-end Editor is a plugin that allows posts to be edited on the front-end (so it’s really WYSIWYG) and aims to have all the features available that the back-end editor has.

      It’s currently in development on GitHub and updates a posted weekly on the UI blog.

      I’m the project lead (@avryl) and those who are involved or have shown interest are @azaozz, @brainstormforce, @bravokeyl, @gcorne, @helen, @henrywright, @hugobaeta, @joen‎, @kraftbj, @markjaquith, @melchoyce, @mrahmadawais, @obenland, @protechig‎, @rafaelxt, @rhurling‎, @roundhill, @samuelsidler, @shaunandrews, @tillkruess, @ubernaut, @wholegraindigital and others.

      If you’re interested, take a look on GitHub and join our Skype chat. The next meeting will be Tuesday, 4 March 2014, 17:00 UTC in #wordpress-ui.

    • Chris Reynolds 12:46 am on February 28, 2014 Permalink | Log in to Reply

      AH-O2 (aka Admin Help) is venturing to reimagine the help system in the WordPress admin.

      It’s currently in development is on GitHub with updates being pushed weekly to the WordPress plugin repository. Updates are posted to the Docs and UI P2s.

      I’m the project lead (@jazzs3quence) and other contributors and folks who’ve been involved one way or another are:
      @brainfork, @trishasalas, @jdgrimes, @ubernaut, @zoerooney, @ninnypants, @mdbitz, @clorith, @nikv, and @veraxus

      We need help with:

      1. Documentation — new tooltips are being added to every admin page. Coders (the folks adding them) != writers, so many of these need to be (or will need to be) reviewed, fixed, updated or written. Also, it’s been pointed out that the help overviews we’re building — which replace the help tabs — may not be best suited for the existing documentation in the help tab (which we’re currently pulling from). So help documentation for those areas may need to be edited/changed/added/removed/etc.
      2. Coders — tooltips are added with javascript (and a little php, just to add the translatable string) but fear not! It’s really easy and repetitive. With about 10 minutes of guidance I think I can walk just about anyone through the process of adding a tooltip.
      3. Testers — please break our stuff (and create tickets)! https://github.com/jazzsequence/WordPress-Admin-Help/issues
      Also, extra brownie points to anyone who can test existing, open tickets to confirm/deny a behvior that has an open ticket.

      We meet weekly in #wordpress-sfd on Monday 18:30UTC.

    • Greg Ross 7:50 pm on March 4, 2014 Permalink | Log in to Reply

      The Admin Theme Experience is an update to the existing admin theme system to try and match the site theme user interface. It has two primary goals; simplify the creation of admin color themes and bring the Site Theme Experience to admin themes.

      Current plugin status: under development

      A list of those involved or already interested in your feature plugin: Me!

      What you’d like help with: Anyone with knowledge of the current site theme code would be helpful.

  • Samuel Sidler 11:27 pm on October 22, 2013 Permalink
    Tags: ,   

    Preparing your feature for the 3.8 merge 

    Now that 3.7 RC has shipped – and the final release is coming soon – it’s time to talk a bit more about how merging to core will work for feature plugins. First, let’s talk about decisions.

    Decisions

    I’ve been asked a few times “who decides” what goes in core and variants of that question. There’s actually three decisions that need to get made. In order:

    1. Does the feature belong in core?
    2. Is the feature ready for core?
    3. Should the feature be in this release?

    Core contributors and members of the community are strongly encouraged to help inform and guide each of these decisions. You may even want to offer some of your feedback in the form of answers to these questions. Each question is ultimately answered by a different group.

    1. Project leaders determine if a feature belongs in core.
    2. Contributing developers determine if a feature is ready for core.
    3. The release lead – for 3.8, @matt – determines if a feature belongs in a particular release.

    We’re now at the point where these questions need to get answered. To do that, it’s time to present your feature plugins.

    Present Your Feature

    If you remember back when we first started the feature plugin process, each team had to present its feature idea and answer a few questions. We’re going to do that again, but with a bit more information. If your project thinks it’s ready for core – and specifically for 3.8 – your team lead should make a post to make/core with the following information:

    • A visual and written overview of your feature plugin, along with a link to your plugin.
    • What problem is your feature plugin trying to solve?
    • What brought you to this solution and what other potential solutions did you explore?
    • Have you done user testing of your feature plugin? If so, what were the results? What worked and what didn’t?

    In your post, be sure to include links to previous posts and even specific comments that have helped form your decisions.

    Be ready for feedback from across the WordPress community – especially UX and code quality  – and be ready to defend your decisions or change your mind if a better idea emerges. Everyone will be reviewing the make/core posts and feedback in their discussion threads to determine if the answers to the questions above are all “yes”. If so, the feature can land when the merge window opens.

     
  • Samuel Sidler 7:15 pm on September 30, 2013 Permalink
    Tags: ,   

    Making preparations for 3.8 

    As mentioned previously, 3.8 development officially opens shortly after 3.7 ships. With the first beta of 3.7 behind us and the final release scheduled for mid-October, it’s time to talk about what’s expected of feature plugins.

    @nacin mentioned at last week’s dev chat that 3.7 will likely branch at the WordCamp Europe contributor day, on October 7. At this point, most core developer focus will be on shipping 3.7. However, feature plugins that want to be considered for 3.8 should be ready by October 14 to give everyone time to review them.

    What does being ready mean? Here’s what will be examined:

    • a strong and well-tested user experience
    • fully-baked design
    • positive feedback from the community
    • core-quality code
    • no major bugs or issues
    • a belief that the feature belongs in WordPress core

    Some of the above is subjective and will vary from feature to feature. If you have questions, look to a lead developer for guidance.

    Of the feature plugins listed, the furthest along are MP6 and global admin search, with Dash not far behind. Plugins in the “feedback” stage should be prepared to answer the question “Why should we include this in core?” As of today, they should prepare their code for core, removing anything unnecessary and making the feature into a patch that can be easily merged with core.

    tl;dr

    • Feature plugins wanting consideration for 3.8 should be ready for presentation and inclusion by October 14.
    • Feature plugins will undergo review shortly after 3.7 ships.
    • Plugins must be ready to merge when the merge window opens.
     
    • Weston Ruter 7:24 pm on September 30, 2013 Permalink | Log in to Reply

      We’ve also been making great strides with the Widgets UI Refresh, specifically with the customizer integration (from my perspective). The plugin project for this is Widget Customizer, and development is happening on GitHub. I’m hoping that we’ll have the remaining issues addressed by October 14th.

      /cc @shaunandrews

      • Bryan Petty 8:06 pm on September 30, 2013 Permalink | Log in to Reply

        Hi Weston, it appears like the widgets team working on this decided to switch the plugin being used for development on this effort entirely just 6 days ago… this shouldn’t happen honestly. If your team has decided on a direction to go in, it should be integrated back into the officially tracked plugin as listed on the core plugin tracking page.

        That aside though, it’s usually a good sign that the plugin is not really “ready for core” when major decisions like that are being made even in the last week here. Nothing new there has had time to be discussed, tested, and generally baked – and it’s really hard to get that feedback when development isn’t even being done on the official plugin where it’s supposed to be.

        • shaunandrews 11:57 pm on September 30, 2013 Permalink | Log in to Reply

          We haven’t switched. We’re developing multiple concepts and testing them simultaneously.

          That being said, I don’t think we have (or will have) “a strong and well tested user experience” by October 14.

        • Weston Ruter 5:28 am on October 1, 2013 Permalink | Log in to Reply

          OK, thanks. I’m obviously over eager. Sorry to jump the gun.

    • Jonatan Santos 8:32 pm on September 30, 2013 Permalink | Log in to Reply

      One point that could be seen would be a button to turn the text to uppercase and minuscule vise versa in menu text editor

      • Mark-k 3:43 am on October 1, 2013 Permalink | Log in to Reply

        As far as I know non latin langs, which are used by more people then latin ones, don’t have uppercase/lowercase distinction, therefor IMO this kind of feature should not be in core

    • Mufasa 4:22 am on October 2, 2013 Permalink | Log in to Reply

      It’d be really great if there was a way to collapse menus in 3.8 (or 3.7). If you look at the following image you can see that in order for me to drag the menu at the bottom to the top I have to do quite a lot of dragging.

      If I could collapse the encyclopedia menu so that I can’t see all those children it would be useable… well if the page didn’t grind to a halt with that many menu items it would 😉

      So I was thinking you could either have a button to collapse them OR when the user starts dragging they close. Which is something we executed in another app and its quite nice to use. I’ve thought the same UI would be nice on the widgets admin page too.

      Thoughts?

      Menu Pain: http://files.kiwijs.org/dan/arghhh.jpg

      • Sam Sidler 5:01 am on October 2, 2013 Permalink | Log in to Reply

        I’d recommend filing a ticket (perhaps there’s already one on file). Fixing that in the way you suggest isn’t something that would be covered by a feature plugin, though there was a (now on-hold) proposal for merging pages and menus.

  • Samuel Sidler 9:35 pm on August 27, 2013 Permalink
    Tags: ,   

    WordPress 3.8 agenda for tomorrow 

    Our next WordPress 3.8 chat is tomorrow, August 28 at 21:00 UTC, following the 3.7 dev chat. Here’s our agenda:

    • Answer questions/comments about the features as plugins process (see yesterday’s post).
    • Review projects with no lead or weekly chat.
    • New feature presentations. Is there a new feature you want to work on that’s not being tracked? Now’s the time to present it. Bring as much information as possible and comment on this post beforehand.
    • Office hours.

    Hope to see all of you tomorrow!

     
    • Charleston Software Associates 3:24 pm on August 29, 2013 Permalink | Log in to Reply

      I am new to the make/core process but would like to start contributing to improving WordPress. I have some “contributor newb” questions:

      • Is creating a Trac ticket the best way to log new concepts for the admin UI?

      Assuming the answer is yes…

      • Is there a way to get Trac to show me more than 10 results at a time?

      I want to log my “wish list items” while working with WordPress over the next couple of weeks. For example:

      • Admin tables Infinite Scroll
      • Adding “delete permanently” w/ “are you sure?” confirmation to bulk actions (skipping trash = one less step in some cases)
      • Adding a page length option to admin tables v. the fixed 20 items limit.

      I’m not clear on the process, but thought it should start with a formal enhancement ticket in Trac. That at least organizes the wish list so myself, or another code geek, can come back and create a MP6-like plugin for a future release of WordPress.

      My other thought was a GitHub / Bitbucket project with an independent issues list, but that just feels wrong as it fragments the community and efforts to improve core. However I can see the benefit of not filling up trac with concepts, many of which do not belong in core.

      Maybe a new “wishlist” Trac?

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