WordPress.org

Make WordPress Core

Updates from February, 2015 Toggle Comment Threads | Keyboard Shortcuts

  • Daniel Bachhuber 11:23 pm on February 2, 2015 Permalink |
    Tags: ,   

    Shortcode UI Chat Summary, February 2nd 

    Attendees: @jdgrimes @danielbachhuber @samuelsidler @matth_eu @bobbingwide @michaelarestad

    Full conversation: https://wordpress.slack.com/archives/core/p1422914584001521

    tl;dr:

    • Background: Fusion (a media company using WordPress) is using shortcodes increasingly to embed content within other content. Given the historically bad UX for shortcodes, we thought we’d invest a bit of development effort. The primary pain points for shortcodes we’re solving are discoverability (what shortcodes are there), and usability (what arguments do I need for this shortcode). @matth_eu (from Human Made) has done a substantial amount of development, along with other contributors.
    • We discussed whether, for pragmatic purposes, shortcodes are content blocks. Answer: Kind of, to a limited degree. We’d need to determine which types of shortcodes are safe to deal with.
    • Everyone agreed inline editing would be nice for the shortcodes that support it well, and take Shortcode UI from good to great. @michaelarestad offered to do some wireframes.
    • @bobbingwide opened a number of Github issues this morning that largely represent useful enhancements.
    • Because Shortcake makes use of JavaScript templates, @kaiser mentioned it would be nice to declare the templates as dependencies of specific scripts. @danielbachhuber agreed, and suggested opening a core ticket.

    Next chat: February 16, 2015 22:00 UTC (two weeks from now)

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

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

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

  • Eric Lewis 6:50 pm on December 18, 2013 Permalink
    Tags:   

    The group formerly known as Metamorphosis Update 

    Yesterday we held our last round of presentations of post meta library authors. Here’s Daniel Quinn on WP Extend, Tom Auger on Zeitguys’ Meta Tool, and Joey Kudish on Custom Metadata Manager.

    RIP Metamorphosis

    Our current project is not a feature-as-a-plugin. Features are big, user-facing elements that would probably get slapped onto a WP version’s About page. We are a bit more under-the-hood. We’re officially now working as the Metadata component group, working on our current task of creating an API for a metadata UI . Although this doesn’t really change our focus, I do think it’s a less pointed perspective to bring to the table, which is good.

    Organizational Changes

    We’ve been operating out of a big ol’ Google doc since day one. That’s been fun, but we’re going to get a bit more organized. I’ve created a project overview page for the Post Meta UI API project Github repo (Updated 1/11/14), which should serve as a portal to all related content.

     
  • George Stephanis 10:35 pm on November 4, 2013 Permalink
    Tags:   

    Upcoming Global Admin Search (née Omnisearch) Meeting 

    After the feedback in the merge chat today, it looks like we’ve got a bit more work to do on the global search spine.

    Based on a quick survey, it looks like Monday, November 11, 20:00 UTC (3pm EST) is likely to be the best time for the most people.

    As we’ve done before, we’ll meet in #wordpress-core-plugins on Freenode, and I’ll give a shout in advance on #wordpress-dev for anyone that may be lurking in there.

    Putting up the bat-signal:

    Other folks who spoke up during the merge chat that I’d love to have join us:

     
  • George Stephanis 5:11 pm on October 23, 2013 Permalink
    Tags: , , ,   

    Omnisearch / Global Admin Search, Final Pitch 

    Plugin: https://wordpress.org/plugins/omnisearch/
    Diff: https://cloudup.com/cC6IbXxoHXN

    Previous posts:
    https://make.wordpress.org/core/2013/08/14/present-your-3-8-feature-idea-at-tomorrows-meeting/#comment-9948
    https://make.wordpress.org/core/2013/08/30/omnisearch/
    https://make.wordpress.org/core/2013/10/08/omnisearch-user-testing/

    IRC chats in #wordpress-core-plugins:
    https://irclogs.wordpress.org/chanlog.php?channel=wordpress-core-plugins&day=2013-08-30&sort=asc#m21304
    https://irclogs.wordpress.org/chanlog.php?channel=wordpress-core-plugins&day=2013-09-12&sort=asc#m23506
    https://irclogs.wordpress.org/chanlog.php?channel=wordpress-core-plugins&day=2013-09-19&sort=asc#m24911
    https://irclogs.wordpress.org/chanlog.php?channel=wordpress-core-plugins&day=2013-09-26&sort=asc#m25942
    https://irclogs.wordpress.org/chanlog.php?channel=wordpress-core-plugins&day=2013-10-10&sort=asc#m27386

    We were a small, but scrappy group. It was mostly myself, @japh, and @lessbloat.

    Omnisearch currently adds three ways to search.

    • A Dashboard Widget:
      Omnisearch Dashboard Widget
    • An admin page under the Dashboard:
      Omnisearch Admin Page
    • And as a search box on  the adminbar — when you’re on the admin side of the site:
      Omnisearch Admin Bar

    All three turn up the same results page:

    Omnisearch Results Page

    And all is happy with the world.

    We were trying to solve the proliferation of different search forms for different data structures in the admin.  When trying to find content, it’s inconvenient and difficult to always navigate to the right data structure and then search it — especially if you’re unsure if something was in a comment or a post (all too frequent in p2s)– and you just want to pull in all relevant results.

    Other things we’d considered were potentially adding an Alfred-like pop-up modal where you could enter omnisearches, and see results from the menus on the page that happen to match — very much like WP Butler’s current functionality.  We opted not to add it in this pass, though, figuring better to keep a slimmer implementation.

    Our user testing confirmed that this was a definite win.  In fact, the user even remarked that there should be a centralized search when we had them running through the initial steps where they were to search each data structure independently, before activating Omnisearch and seeing how that compared.

    We’re eager to hear any feedback on code, methods, or even name.  I’ve had some people mention that they’d prefer it have a less ‘marketing’ name, and more of a generalized “Global Admin Search”.  I prefer Omnisearch for brevity, but would love to hear some discussion on the pros and cons of whether it would be better to use a more general name.

     
    • Andrew Nacin 6:43 pm on October 23, 2013 Permalink | Log in to Reply

      My suggestions on UI: The search tool in the toolbar is very likely sufficient placement for this. Drop the dashboard widget and the menu item. Add a “Search everywhere” link to each individual search results page in the admin, next to “Search results for “%s”. There’s no reason to force this onto people — just let it be naturally discovered in times of need.

      If no results are found for a section, it may be okay to omit that section entirely, rather than showing an empty table and taking up 100+ vertical pixels. If no results are found at all, it could just be a simple single line of feedback, rather than scrolling through a bunch of empty tables.

      Is the “Search Pages” button/link helpful? They see all of the results here (presumably with pagination). Maybe clicking the name of the section should take them to that particular page (with the search conducted) to allow for filtering and such. Otherwise, it seems like clutter.

      I see that plugins is searchable, along with posts, pages, and media. What about themes? Custom post types? Taxonomies? Settings? Importers? Admin screens & keywords? Etc. (A lot of this came up with @markjaquith was kicking around this exact idea a year or two ago.)

      My suggestions on naming: simply call it “search”. When discussing it in code, call it an admin search or the dashboard search or whatever. “omnisearch” sounds like (and, in Jetpack, is) a gimmicky product name. There’s no need for a tagline. “Search” is a pretty natural and common feature; let it speak for itself.

      Will note that comments are also searched on P2s. Would be more interested in hearing additional use cases for this. I think a lot of it comes down to increasing uses of custom post types. As of right now, since it only supports posts/pages/comments/media/plugins, it’s not really “everywhere” yet.

      I think the feature implementation is pretty close for core — certainly could be smoothed out over the course of a merge.

      • George Stephanis 7:25 pm on October 23, 2013 Permalink | Log in to Reply

        My suggestions on UI: The search tool in the toolbar is very likely sufficient placement for this. Drop the dashboard widget and the menu item. Add a “Search everywhere” link to each individual search results page in the admin, next to “Search results for “%s”. There’s no reason to force this onto people — just let it be naturally discovered in times of need.

        Good call. Depending on how DASH goes, if it ever migrates to a fixed column of static stuff like in this older mockup, it may be worth including this there as a search field. The primary reason for all the avenues was to have them available, then pare them down in the merge.

        Agreed on sacking the widget and probably the menu item. I’m not sure if it would make more sense to have the menu item there if you’re on that page at the time, but hide it if you’re not? Or if that would be confusing from a UX perspective.

        If no results are found for a section, it may be okay to omit that section entirely, rather than showing an empty table and taking up 100+ vertical pixels. If no results are found at all, it could just be a simple single line of feedback, rather than scrolling through a bunch of empty tables.

        I’d prefer the line of feedback, it might play nicer with results sections that load in results after dom.ready via js for latency reasons.

        Is the “Search Pages” button/link helpful? They see all of the results here (presumably with pagination). Maybe clicking the name of the section should take them to that particular page (with the search conducted) to allow for filtering and such. Otherwise, it seems like clutter.

        Actually, just to keep it short, it only displays the first five results (adjustable via a filter) (and possibly would be wise to have customizable in Screen Options). To dig deeper into a given section they need to click the link for that specific section. This also avoids a large degree of confusion as to results page refreshes when paginating — which list table is it paginating? They all use the same query argument!

        A potential down-the-road enhancement would be to enable pagination via js on specific tables, but for the moment, it’s just capped at five.

        I see that plugins is searchable, along with posts, pages, and media. What about themes? Custom post types? Taxonomies? Settings? Importers? Admin screens & keywords? Etc. (A lot of this came up with @markjaquith was kicking around this exact idea a year or two ago.)

        Themes could be, I excluded it initially, as it seemed to me to be a much more infrequent task.

        Custom post types aren’t included by default, as they can have such disparate data structures, that forcing them into a single custom list table may not end well. They’re easy to include, though, like so: https://gist.github.com/georgestephanis/6926206

        Taxonomies, settings, and importers are all feasible, this is just the baseline that was felt to be most useful to the most people, while still keeping the UI reasonably simple. We could always offer them, but have them hidden by default in Screen Options. If that’s the consensus, I’ll add them in.

        My suggestions on naming: simply call it “search”. When discussing it in code, call it an admin search or the dashboard search or whatever. “omnisearch” sounds like (and, in Jetpack, is) a gimmicky product name. There’s no need for a tagline. “Search” is a pretty natural and common feature; let it speak for itself.

        Maybe Global Search then. There’s so many searches in the admin already, that a ‘Search’ label without context could be more confusing than helpful.

        • Raam Dev 7:32 pm on October 23, 2013 Permalink | Log in to Reply

          Maybe Global Search then. There’s so many searches in the admin already, that a ‘Search’ label without context could be more confusing than helpful.

          I also vote for ‘Search’. Putting ‘Search’ on the Dashboard tab provides the necessary context and helps indicate that we’re not searching any one particular section but rather the whole site.

    • Sam Sidler 6:48 pm on October 23, 2013 Permalink | Log in to Reply

      A few questions:

      • What was the rational for putting Omnisearch under “Dashboard” in the admin? Not saying it’s the wrong place, just curious if other places might make more sense, especially since it’s permanently located on the top right of the admin interface.
      • Why only show the search box when you’re on the admin side? Other than “Edit Post”, it would be the only thing that changes between admin side and not.
      • Related: Why show the entire box instead of just a search icon? Whoops, I realized I misunderstood this. :)
      • Does this search custom post types? I’d take off the “search everything” tagline if it doesn’t search literally everything.

      Otherwise than those questions, looks like good work. I’m on the side of Omnisearch being a bit too gimmicky, but would love to hear what others think.

      • George Stephanis 7:32 pm on October 23, 2013 Permalink | Log in to Reply

        RE: under Dashboard in the admin, it’s legacy that I worked up initially. In Jetpack, it’s under the Jetpack menu item, but when merging it into WPCOM, I didn’t have that available, and put it under Dashboard. I’m not particularly attached to it, and would be happy to drop it from the menu as mentioned above.

        RE: why only the admin side, that was because the search in the admin bar is already there on the front-end, and I didn’t want to change that form’s behavior. If other folks would rather have adminbar search be Omnisearch at all times, I’m fine with that as well — we’d just need a fallback or capability check if logged out users had it displayed to them.

        RE: CPTs: It can, I had just intentionally left them off initially due to the disparate data structures they can represent, with the bulk of it potentially in postmeta — I wasn’t sure how well it would search them, and if displaying them in the list table would look in any way reasonable or representative of what they’re storing.

        • Sam Sidler 7:53 pm on October 23, 2013 Permalink | Log in to Reply

          RE: why only the admin side, that was because the search in the admin bar is already there on the front-end, and I didn’t want to change that form’s behavior. If other folks would rather have adminbar search be Omnisearch at all times, I’m fine with that as well — we’d just need a fallback or capability check if logged out users had it displayed to them.

          It feels like strange behavior for the search icon in the admin bar to have two different behaviors, depending on the view. I’d be interested to see what user testing would say on that. Easy enough to change anyway.

          RE: CPTs: It can, I had just intentionally left them off initially due to the disparate data structures they can represent, with the bulk of it potentially in postmeta — I wasn’t sure how well it would search them, and if displaying them in the list table would look in any way reasonable or representative of what they’re storing.

          I think they should get included, but you said above (and showed!) that it’s not hard to add. Perhaps we can wait for feedback post-merge.

    • Bryan Petty 7:20 pm on October 23, 2013 Permalink | Log in to Reply

      As far as the admin bar search goes, what are your thoughts about the fact that there is already currently a search bar on the admin when browsing the frontend on a site, which pulls up the regular search results page on the frontend. I know you’ve stuck with keeping the search on the frontend the same as it is now, but do you think that behavior should change for an admin/editor/author? How might that be affected by roles and capabilities?

      @sams Does your theme you tested with this not have search?

      Also, not just “gimmicky”, but I think calling it “Omnisearch” instead of just “search” is actually detrimental once it’s considered the official built-in search functionality (as opposed to begin able to identify it as an add-on provided by Jetpack).

      Also, I get this fatal with the plugin (with *multisite* WP trunk):
      “Fatal error: Call to undefined function wp_is_mobile() in /home/bryan/Projects/wordpress/src/wp-content/plugins/omnisearch/omnisearch-core.php on line 14″

    • memuller 5:11 pm on October 24, 2013 Permalink | Log in to Reply

      About the name, I think just “search”, as nacin suggested, might work.
      @georgestephanis, while I agree that it may be confusing given the presence of many “search” functionalities, I believe that’s an issue with the other search functionalities, not with this one. Since this search will be the de-facto admin search – that is, it will be enough in most cases – it makes sense for its name to be just “search”. The “global” here is unnecessary – the name “search” should be reserved to the most general and useful case possible, and this plugin is that case. Aditionaly, “global” implies the existence of more types of search – which is the case, but the user does not need to be exposed to that confusion so early.

      The issue, them, is to make sure that all other search functionalities are named differently; that all instances of “[custom post name] search” or “theme search” are always named in such way as to make clear that they are more limited in scope or functionality.

      Omnisearch is inadequate for the same reasons – the name won’t be a selling point for this feature, so a descriptive, simple name wins. That name would – for example – be a pain to I18N teams.

      Otherwise, this is awesome – it will greatly help finding stuff in huge sites; and the API for including custom posts is looking good. I really hope to see this on 3.8.

    • George Stephanis 9:01 pm on October 24, 2013 Permalink | Log in to Reply

      Okay, got two changesets in just now.

      https://plugins.trac.wordpress.org/changeset/793194/omnisearch
      https://plugins.trac.wordpress.org/changeset/793196/omnisearch

      To-accomplish yet, based on feedback from above:

      • Drop the table output from empty result sets.
      • Add in the links to “search globally for %s” to the end of the normal archive tables when a search has been performed.
      • ???

      Current version is 0.9, installable from https://wordpress.org/plugins/omnisearch/

    • Gregory Cornelius 7:35 pm on October 27, 2013 Permalink | Log in to Reply

      Nice work.

      I wasn’t exactly sold on the idea initially, but seeing the search a bit more tightly integrated with the admin UI instead of just hanging out under Dashboard, its potential is starting to emerge. UX-wise I sorta wish that the results were more unified and less of a direct reflection of the data schemas. Perhaps, all post-like content could be combined into a single group in a manner not unlike how search results are handled in the Link modal in the visual editor. It would also be nice if the results could be re-ordered by clicking the table headings or maybe even experiment with removing the headings.

      Thinking about the search field, I wonder if some sort of autosuggestion of results built from matches on post titles across post types with a “Show All Results” link at the top of the list. This would make the dashboard feel a lot more responsive for power users that are used to using search tools like Spotlight, Alfred, Quicksilver, or even the new Window 8 thingy. Eventually, I could even imagine the results including the results from the content of the various admin screens, especially the settings. It would be kind of neat if searching “Disable comments” included a link to the Discussion Settings.

      Maybe the search bar could also be integrated into the new DASH dashboard if/when that component is integrated. And, as the tool becomes more refined and useful, I think it would be nice if the field somehow became a bit more prominent in the admin bar. At the very least, it would be nice if the animation to open the field was a lot faster.

    • George Stephanis 8:37 pm on October 27, 2013 Permalink | Log in to Reply

      Just upped the plugin again. Posts/Pages are now decended from the WP_Posts_List_Table class, which lets a lot of stuff like custom columns and displaying taxonomies work out of the box. I’m about to auto-include custom post types as well, if their UI is exposed in the admin.

      Also switched it so it displays a blurb, instead of an empty table, if there’s no results. Also skips the link to search that data type in more depth if there was no results.

    • sandeepbagchi 7:48 am on October 31, 2013 Permalink | Log in to Reply

      Is it possible to add filters for searching?
      Date Search: “Search To And Search From”
      Search In Category: dropdown with multiple selection
      Search In Posts or Search In Pages or Search In Available Custom Post Types (drop down with multiple selection)

      After taking all the inputs a query can be formed to refine the search?

    • Sarah Gooding 8:02 pm on November 11, 2013 Permalink | Log in to Reply

      Is it possible to include an auto-suggest while typing and load results via AJAX instead of whisking the user away onto another page – similar to how it’s done in the http://wpjarvis.com plugin (see demo on that page)? This seems like a more elegant implementation. I understand that there’s a lot of data to show in the results but if there was any way to make it more compact I think the experience would be improved. Of course, I may be missing a lot of the complexity involved here…

  • Andrew Nacin 6:50 pm on August 21, 2013 Permalink
    Tags: ,   

    Agenda for today’s dev meeting:

    • Review why/how we’re doing features-as-plugins for post-3.7 releases (@samuelsidler)
    • Start cranking on tickets, discuss any major tickets we need to discuss, check if anyone is stuck or wants something to work on (@duck_)
    • A number of people are working on make/core posts to kick off some 3.7 initiatives (updates, language packs, inline docs, develop.svn ideas list) or jumpstart conversations for future dev meetings (CSS preprocessor pros/cons) — let’s aim to get these done this week.
    • This meeting will be followed by 3.8 office hours at 21:00 UTC. There is no 3.8 meeting tomorrow — postponed for this week.

    Also, the JavaScript meeting (IRC logs) went great:

    • @kadamwhite and @carldanley will be enumerating JS style preferences and working on a jshintrc
    • @jorbin and @kadamwhite are working on JS unit tests (#24870, #25096, #25088)
    • We’ll be formally adopting JSDoc for inline documentation (same basic style as PHPDoc)
    • Also discussed include JS actions/filters (#21170)
     
    • Andrew Nacin 6:52 pm on August 21, 2013 Permalink | Log in to Reply

      Suggest any items for the dev chat in the comments.

    • Carl Danley 6:55 pm on August 21, 2013 Permalink | Log in to Reply

      Also – i’m putting together a formal approach on design patterns to further enhance our consistency in JS. I’m hoping this will help to introduce a standard that developers can conform to; something that promotes both ease of use and a clear definition for how we should be approaching implementations. Will have this content ready a little later in the week.

    • Unsal Korkmaz 7:11 pm on August 21, 2013 Permalink | Log in to Reply

      Sorry if i miss, what happened to post formats?

    • WraithKenny 7:34 pm on August 21, 2013 Permalink | Log in to Reply

      I’m totally down for the pro’s side of css preprocessors. Grunt supports lesscss.org

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