WordPress.org

Ready to get started?Download WordPress

Make WordPress Core

Updates from January, 2014 Toggle Comment Threads | Keyboard Shortcuts

  • Mike Schroder 10:29 am on March 13, 2014 Permalink | Log in to leave a Comment
    Tags: ,   

    Last Week in WordPress Core 

    Hi there! Welcome to Last Week in WordPress Core for the week of March 3–9. By now, you’ve heard that WordPress 3.9 Beta 1 is available! Thank you for your hard work this last week. Now we’re done adding new enhancements, and on to bugs. Your help is appreciated as we continue to test and squash bugs on the way to a stable RC.

    There are a couple important things that landed on Monday that are not covered in this post, but shipped in beta. Namely, please test the Theme Install screen refresh and the ability to crop headers from within the Customizer.

    Admin:

    • Widgets: Add widget management to the customizer. This brings in the Widget Customizer plugin. [27419] #27112
    • Admin Menu: Introduce a .dashicons-before CSS class and use it in the admin menu. Lets you use a Dashicon before an element without copying the entire .dashicons styling to your :before styling. [27418] [27425] [27444] [27482] #26630
    • Editor: Show “View Post” for any post the author can read. This expands it to private posts and matches the logic in the toolbar. [27483] #27059

    Media:

    • First pass at bringing the Image Editor into the media modal. Please test me! [27445] #21811
    • First pass adding a loading indicator to the Media Library. [27438] #24859
    • Allow $crop in add_image_size() and set_post_thumbnail_size() to receive crop anchors (top, left, right, bottom, center). [27472] #19393.
    • Add subtitle support to Video editing in the Media Modal. [27481] #27016
    • Do not output default gallery styles if the theme has opted into HTML5 galleries. [27396] #27045; see #26697
    • Add a class attribute to the caption shortcode to allow additional classes to be specified. [27404] #25295
    • Add playlist_styles and wp_playlist_scripts filters to allow users to roll their own playlist themes. [27486] #26631 & [27488] #26631

    TinyMCE:

    • Update TinyMCE to 4.0.18. [27387] #24067
    • Add TinyMCE placeholders for audio and video shortcodes and provide a UI to both edit shortcode attributes and replace the src media file in an audio or video shortcode. Also, a flurry of improvements and fixes to them, visible in the full changelog. [27411] #27016
    • Add a Ctrl+K shortcut to open the linking dialog, which is the “de-facto standard”. [27449] #27305
    • Add the <hr> plugin and button to the toolbar. [27428] #27159
    • With drag-and-drop uploading, support multiple editor instances, limit to IE10+, and other small fixes. [27378] [27372] [27464] #19845
    • When parsing a caption shortcode, recreate missing width attributes using the image tag’s width. [27426] #23103
    • Restore the “link” button state to disabled by default and enabled when text or image is selected. Remove the (recently added) default link plugin; not needed. [27447] #27309

    Templates:

    • Add has-post-thumbnail as a post class. [27429] #18804
    • Rename the new page_templates filter to theme_page_templates, and pass it a post object for proper context. [27470] [27471] #13265
    • Introduce get_the_permalink() as an alias for get_permalink(). This better aligns it with other the_* and get_the_* function pairs. [27409] #24164
    • Let get_the_date() accept a post object. [27380] #13771
    • Add the ability to short-circuit wp_nav_menu() via the pre_wp_nav_menu hook. [27386] #23627
    • Better plural handling for labels in wp_generate_tag_cloud() / wp_tag_cloud(). [27376] #27262, see #7989, #14424

    Multisite:

    • Incremental improvements and bug fixes with the multisite load process. Please test your networks! [27406] [27439] [27407] #27003
    • Fix bulk activation of network-only plugins. [27413] #26487

    Query:

    • Add has_password and post_password query variables to WP_Query. has_password true means posts with passwords, false means posts without. post_password can query for posts with a particular password. [27395] #20308
    • Allow a posts_per_rss query variable to be set to override the posts_per_rss option. [27456] [27455] #25380
    • Allow get_page_by_path() and get_page_by_title() to accept an array of post types. [27423] #24763

    Internals:

    • Allow for custom authentication handlers for all requests. Turn the logic used by wp_get_current_user() into a determine_current_user filter. [27484] #26706
    • Allow the role attribute in kses for all elements. [27388] #24098
    • Add a pre_set_theme_mod_$name filter to set_theme_mod(), modeled after pre_update_option_$option in update_option(). [27393] [27402] #14721.
    • Improve HHVM compatibility by eliminating some of our last remaining create_function() calls and making OBJECT a case sensitive constant. [27373] [27374] [27465] #14424 [27377] #27231
    • Pass $reassign parameter to delete_user and deleted_user actions. [27462] [27466] #23057
    • Bail early from shortcode functions if no delimiter is present. It’s the little things; performance results on-ticket. [27394] #23855
    • Update PHPMailer to 5.2.7 from 5.2.4. Includes two trivial modifications for WordPress (no impact to plugin developers); see the commit message. [27385] #25560
    • Use SSL when linking to WordPress.org. [27469] #27115

    For the complete list of commits to trunk, check out the log on Trac. Interested in joining in? Write or test a patch for 3.9.

    Thanks to @adamsilverstein, @akeda, @avryl, @bassgang, @bigdawggi, @bobbravo2, @bpetty, @bradt, @celloexpressions, @coffee2code, @danielbachhuber, @dd32, @DJPaul, @DrewAPicture, @empireoflight, @ericlewis, @ericmann, @frank-klein, @gcorne, @genkisan, @gradyetc, @hakre, @Hanni, @Jayjdk, @jenmylo, @johnregan3, @jorbin, @JoshuaAbenazer, @kadamwhite, @kasparsd, @Kopepasah, @kovshenin, @kpdesign, @lpointet, @markjaquith, @mcadwell, @melchoyce, @michael-arestad, @mikecorkum, @mordauk, @nacin, @obenland, @Otto42, @pavelevap, @Rarst, @rhyswynne, @ricardocorreia, @rmccue, @robmiller, @seanchayes, @SergeyBiryukov, @shaunandrews, @simonwheatley, @sirzooro, @tanner-m, @TobiasBg, @tomauger, @topher1kenobe, @topquarky, @toszcze, @westonruter, @wokamoto, @wonderboymusic, @zbtirrell, and @zodiac1978 for their efforts this week!

     
  • samuelsidler 4:40 pm on February 27, 2014 Permalink | Log in to leave a Comment
    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.

    • Janneke Van Dorpe 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 (add jannekevandorpe). 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.

  • Mike Schroder 2:46 pm on February 4, 2014 Permalink | Log in to leave a Comment
    Tags: ,   

    Last week in WordPress core 

    Welcome back to Last Week In WordPress Core, for the week of January 27-February 2. Big list this time! First, a summary of the major changes; then a roundup from the various 3.9 teams:

    Enhancements and hooks

    Database changes

    • Initial patch to reconnect when the MySQL server “goes away” has landed, with a request for feedback on how to make the solution more fool-proof on #5932.
    • Improved Compatibility with MySQL 5.6, which has stricter default SQL modes.
      Disables NO_ZERO_DATE, ONLY_FULL_GROUP_BY, STRICT_TRANS_TABLES, STRICT_ALL_TABLES, TRADITIONAL. Introduces filterable wpdb::set_sql_mode(), with incompatible_sql_modes filter for plugins. #26847
    • We now throw a notice when wpdb::prepare() is called without a placeholder. #25604
    • In wpdb::db_connect(), allow the loading of a translatable custom database error template. #25703

    Miscellaneous, including library updates

    3.9 status reports

    Here are roughly where each of the 3.9 teams/tasks stood as of last week’s meeting:

    Media/editor related:

    • Media Modal: “Initial version of the single image editor landed, which includes the ability to replace the image and update the main set of attributes (e.g. caption, alt, alignment, link).” (@gcorne) (#21811)
    • Image Editor: “have a proof-of-concept plugin ready awaiting input on how to modularize the Editor and make it extensible and flexible. Working on a patch that introduces a few well-placed hooks.” (@tomauger) (#21811)
    • Rendering in the editor: “Going to dig into rendering galleries in the visual editor using a wpview and building on some of the work that i did in https://github.com/gcorne/gallery-editor.&#8221; (@gcorne) (#26628, #26959)
    • TinyMCE: All looks good on this front, #24067. “We’ve also started looking at restyling TinyMCE modals to match the admin, #26952″(@azaozz, @melchoyce)
    • Audio/Video: There’s an update post by @wonderboymusic.

    Other UI work:

    • Widget Customizer: “We’re running more users tests; Working on keyboard accessibility features; Trying to figure out support for wide widgets; Asked for some code review/notes; And digesting feedback from our recent p2 post.” (@shaunandrews)
    • Settings screens: “We had a meeting yesterday to divvy up the redux. I’m looking at reordering of information across screens, @melchoyce is experimenting with UI approaches, and @Ipstenu is looking at cleaning up the multisite ‘edit site/settings’ view. We hope to be posting sketches/wireframes [this] week.” Also, they’re again looking at lifting post by email from core. (@jenmylo)
    • Accessibility: we are testing 3.8.1 admin screens for keyboard accessibility. (@joedolson)
    • Autocomplete: After the new site email address autocomplete landed (#25348), now looking into other areas — users (#19867) and pages (#9864). (@helen)
    • CSS: Work continues on the colors.css merge to prep for splitting up wp-admin.css. (@helen, #18380, #26669).

    Fun with internals:

    • Multisite: “Our tickets are focused. [As in, reorganized into the 'multisite' focus.] I’ve been digging through ms-load.php, ms-settings.php, etc in prep for some fun domain routing work. Would like to compare thoughts on approach soon and get moving on that.” (@jeremyfelt)
    • New Grunt-based Patching Tool: “I’ve been using it locally and haven’t run into any issues. Will be opening a ticket on Trac with a patch and instructions in the next few days.” (@jorbin)
    • Taxonomy: Hope to start with the first few tickets on the roadmap this week. (@nacin)

    Housekeeping items last week included a call for GSoC participation from @jenmylo, and trac component reorganization proposal from @nacin. The reorganization was approved during the chat on Wednesday and is well under way. Additionally, there’s now a new Trac reports overlay and Trac’s navigation got overhauled.

    For the complete changelog commits to trunk, check out the log on Trac.

    More than three dozen contributors had a hand in last week’s efforts. Want to help out this week? Write or test a patch for 3.9.

    Thanks for contributions this week from atimmer, aubreypwd, azaozz, c3mdigital, cmmarslender, coffee2code, Denis-de-Bernardy, DrewAPicture, empireoflight, gcornehelen, ippetkov, jeremyfelt, joehoyle, johnjamesjacoby, JoshuaAbenazer, kovshenin, kpdesign, kraftbj, mark8barnes, markjaquith, MattyRob, mdbitz, melchoyce, nacin, neoxx, nofearinc, ocean90, olivM, oso96_2000, ounziw, pento, romaimperator, sbruner, SergeyBiryukov, soulseekah, TobiasBg, toszcze, wonderboymusic, and yoavf!

     
  • Weston Ruter 11:52 pm on January 28, 2014 Permalink | Log in to leave a Comment
    Tags:   

    Widget Customizer Feature-as-Plugin Merge Proposal 

    Widgets in WordPress provide an easy way to add functionality to predefined areas of your theme templates. However, once you add a widget to a sidebar you have to leave the WordPress admin to go back to the frontend to actually see how the updated widget appears in the sidebar on your site’s public frontend. While you are making these changes and experimenting with a widget, it could be completely broken and everyone visiting your site will see this broken widget since there is no core way to preview changes made to widgets. But WordPress also provides an excellent way to preview changes to various settings on your site via the (Theme) Customizer. Changes made when using the Customizer are not visible to site visitors until you hit Save & Publish. So what if widgets could be edited in the Customizer? That’s what the Widget Customizer plugin makes possible. No longer do you have to edit your widgets blind!

    A widget control open the customizer

    Each registered sidebar on your site gets its own section in the Customizer panel. Within each section, widgets appear in their sidebar order. The widget controls appear there just as they appear when editing widgets in the widgets admin page. Upon making a change to the widget control, pressing the form’s Update button causes the changes to appear in the preview window; no changes to the widgets are saved permanently for others to see until you hit the Customizer’s Save & Publish button. This goes for whether you’re adding a new widget, editing existing widgets, reordering widgets, dragging widgets to other sidebars, or even removing widgets from the sidebars entirely: all of these actions are previewable.

    Adding a widget to a sidebar slides open a panel for browsing the available widgets, complete with the usual names and descriptions, but also featuring widget icons to help quickly identify widgets. The list of available widgets can also be filtered down with a search input.

    When you remove a widget from a sidebar, it is not deleted. Instead, it is moved from an active sidebar to the “Inactive Widgets” sidebar which can currently be seen on the widgets admin page. As such, removing a widget now is the same as trashing a widget.

    Adding a widget

    Customizer control sections for sidebars are shown and hidden dynamically when the preview window is initially loaded or when navigating the site within the preview window, based on whether or not the sidebar gets rendered in the previewed URL. (You may not know this, but you can navigate your site by clicking links in the preview window.) Only sidebars which can be previewed will be shown in the customizer panel. Likewise, widgets that are not rendered in the preview (for example, by means of Jetpack’s Widget Visibility module) will appear in the Customizer as semi-transparent.

    Accessibility has also been a key concern for Widget Customizer. The current keyboard navigation on the widgets admin page feels cumbersome, having to open screen options to enable a separate accessibility mode. We wanted to make re-ordering with widgets as seamless as possible. So now when any sidebar section is open, you can invoke a reorder mode to reveal up/down arrows to reorder widgets, as well as a subpanel to open for moving the widget to another sidebar entirely. (This feature is nearing completion in pull request #21.)

    Here’s an older walkthrough of the plugin:

    Live Previews

    (This did not make it into WordPress 3.9 — that also means themes do not need to indicate support for the widgets customizer.)

    While all themes and widgets should work with Widget Customizer, for the best experience the themes and widgets need to indicate they support live previews of sidebars and widgets. Without such support added, each change to a sidebar or widget will result in the preview window being refreshed, resulting in a delay before the changes can be seen (settings default to transport=refresh). To enable a much more responsive preview experience, themes and widgets should indicate that they support Widget Customizer live previews; this will update the relevant settings to use transport=postMessage, the updated widgets will be loaded via Ajax, and the widgets will be re-ordered via DOM manipulation.

    All core widgets and themes distributed with WordPress core are supported by default. For other themes, simply include add_theme_support('widget-customizer') in your theme’s functions.php to opt-in. If your theme does some dynamic layout for a sidebar (like Twenty Thirteen uses jQuery Masonry), you’ll also need to then enqueue some JavaScript to listen for changes to the sidebar and reflow them when that happens; see the bundled support for Twenty Thirteen to see an example of what is required.

    Along with themes needing to indicate support for live-previewable sidebars, widgets must also indicate that they support being live-previewed with Widget Customizer. When updating a widget, an Ajax call is made to re-render the widget with the latest changes, and then the widget element is replaced in the sidebar inside the preview. If a widget is purely static HTML with no associated script behaviors or dynamic stylesheets (like all widgets in core), then they can right-away indicate support for live previews simply by including 'customizer_support' => true in the array passed to WP_Widget::__construct(). As with sidebars, if a widget has dynamic behaviors which normally only get added when the page first loads (such as a widget which includes a carousel), then a script needs to be enqueued in the Customizer preview which will re-initialize the widget when a widget is changed.

    The sidebar-updated and widget-updated events get triggered on wp.customize when sidebars and widgets get updated, each being passed the sidebar ID and the widget ID respectively as the first argument in the callbacks. For a full example demonstrating how to add theme support for live-previewing dynamic sidebars and how to add support for JS-initialized widgets, see this annotated Gist.

    Core Tickets

    A few Core tickets have been opened with patches to generally improve widgets and the customizer, and also to improve Widget Customizer itself:

    • #26633: Customizer form submission prevention impairs accessibility of links in customizer controls
    • #26061: Customizer settings with non-scalar values incorrectly trigger as changed
    • #26569: URLs exported to JavaScript in Customizer settings get double-encoded
    • #25368: Add temp hooks for Widgets UI Refresh plugin-as-feature
    • #26661: Add before/after hooks to override output of wp_widget_control()
    • #25419: Add support to widgets for icons and screenshots

    User Tests

    A couple user tests have been done, both of which went pretty well. More user testing is being queued up. Here’s the first user test video, though note it reflects an early rendition of the plugin:

    Remaining Issues

    In addition to wrapping up the keyboard-accessible widget reordering (#21), there is the dilemma of how to handle wide widget form controls (#18); various solutions have been proposed for how to display a widget control which does not fit within the customizer panel.

    The other open issues are enhancements or open questions which may or may not need actioning.

    Contributors

    While the plugin was first conceived by me (@westonruter) and I’ve been the lead developer, a ton of valuable input and contributions have come from @shaunandrews, @michael-arestad, from my X-Team colleagues (@johnregan3, @akeda, @topher1kenobe), and from others in the community (@bobbravo2, @topquarky, @ricardocorreia).

    Development on the plugin has been done on GitHub, with the WordPress.org repo serving as a read-only mirror.

    See Also

     
    • Scott Taylor 12:04 am on January 29, 2014 Permalink | Log in to Reply

      This is really cool. Since all this widget refresh activity has been going on, I have seen the light on how great they are. It would be cool if we could find a way to rename the unfortunately base-named “sidebars.” I have no recommendation for something better, but it seems like widgets would really get their due if they were named appropriately as “one of many in a theme area” or “widget collection” or belong to a “module container.”

      Anyways, great work so far.

      • PeterRKnight 12:18 am on January 29, 2014 Permalink | Log in to Reply

        In hindsight I think just ‘widget area’ would have been the simplest name. I wonder how much trouble it would be to rename it.

      • Andrew Nacin 3:27 am on January 29, 2014 Permalink | Log in to Reply

        For what it’s worth (and it isn’t worth much), while this post uses the word “sidebar” repeatedly and while core code uses it extensively in the API, it’s nowhere in the UI. When we need to refer to one, we call it a “widget area” (such as in the help tabs).

        • Jen Mylo 4:27 am on January 29, 2014 Permalink | Log in to Reply

          Yes, we started actively saying widget area instead of sidebar when it was the controversy of the day several years back.

      • tomdryan 4:32 am on January 29, 2014 Permalink | Log in to Reply

        Scott I agree with you — the term “Sidebar” is outdated and should be retired, except when referring to containers that are actual (left/right) sidebars. The term that I’ve taken a liking to is “Container”. I’m hoping to see the entire widget functionality morphs into something more universal within WordPress, so you could have widgets, text, html, etc within a container. Page templates are made up of containers and containers can have widgets, media, text, html or other containers and other content within them.

        If you look at it that way, a menu is essentially a container (with a menu widget), as is the page header, as is the login dialog, etc, etc. Eventually, everything that is displayed by a WP site could be easily accessible and modifiable by the user without the need to edit any code or text files (unless they want to of course).

      • Weston Ruter 4:48 am on January 29, 2014 Permalink | Log in to Reply

        Yes, my bad everyone. s/sidebar/widget area/g :-)

    • Todd Lahman 12:13 am on January 29, 2014 Permalink | Log in to Reply

      Nice work Weston and contributors.

    • Jose 12:20 am on January 29, 2014 Permalink | Log in to Reply

      Awesome work! Been using the .org repo but will try and make the github transfer in the next couple of days.

      I truly love the integration of the genericons. :)

    • PeterRKnight 12:22 am on January 29, 2014 Permalink | Log in to Reply

      Are there any new approaches to the wide widget controls issue (#18) to test?

      • Weston Ruter 12:34 am on January 29, 2014 Permalink | Log in to Reply

        @PeterRKnight: no, we were talking about it over Skype today some more. Still really challenged by this. @michael-arestad did some more mocks: https://cloudup.com/iqH4tGUbQPn

        I think the idea I like the most is if wide widget controls opened over the preview as draggable areas. But it is a jarring user experience for some widgets to have controls sliding down within the panel, with others appearing in these floating windows.

        • Michael Arestad 12:57 am on January 29, 2014 Permalink | Log in to Reply

          We were also considering a flyout as an option as well that operates similar to the current wide widget controls on the widgets page.

        • PeterRKnight 2:01 am on January 30, 2014 Permalink | Log in to Reply

          Ah! Is there a reason why wide *and* normally sized controls couldn’t both enjoy the draggable-over-the-preview format? It would be consistent that way.

          Nice mockup, is it pushing the width of the preview section into a smaller frame though or does it hover over the preview? Hard to tell from the mockup, but it looks like it pushed the page layout into a narrow tablet/mode layout, I think that might be less intuitive when configuring widgets.

    • Syed Balkhi 2:27 am on January 29, 2014 Permalink | Log in to Reply

      This is pretty neat.

    • sterex 4:17 am on January 29, 2014 Permalink | Log in to Reply

      This is a really cool idea. This could probably replace the current widget settings page. Unless there is something that the customizer does not support.

    • Mike Schinkel 3:46 pm on January 29, 2014 Permalink | Log in to Reply

      Super nice Weston; two thumbs up!

    • Travis Northcutt 4:01 pm on January 29, 2014 Permalink | Log in to Reply

      Weston (or others): if using a child theme, does the child theme need to `add_theme_support(‘widget-customizer’)`, or is it sufficient for the parent theme to do so?

    • mrwweb 5:34 pm on January 29, 2014 Permalink | Log in to Reply

      Some thoughts.

      1) It looks good and it’s fun to use. Nice job!

      2) If this gets into core, it seems that a bit more consistency between the backend admin and Customizer would be useful. Particularly, if the widget icons are used in the Customizer, I’d expect them to be used in core.

      3) I think it’s important to consider how these would interact with the various “Widget Visibility” plugins (Jetpack’s Widget Visibility, Widget Logic, Widget Logic Visual, Conditional Widgets, Display Widgets, Dynamic Widgets, etc.). Right now, that can result to a widget appearing in the customizer but not in the preview.

      4) My biggest concern about including this in core is that it shifts the purpose of the Customizer from one intended for modifying the visual presentation of every page on a site, to one that handles content that may change from page to page (based on widget visibility mentioned in #3 or sidebars only appearing on certain pages). The discussion over including this in core should start by clarifying the purpose of the Customizer and whether or how much it should address editing content.

      As I addressed in an article expressing concerns about front-end editing where the focus is on the display of content, I think there’s a risk that users think they’re only changing the specific instance of the widget they’re looking at. This could be learned over time, but I think there’s a chance that it could lead to a bad first experience for many.

      5) If not all widgets can be supported when the feature is launched and not all themes can fully support the customizer, I worry that this will lead to further confusion for beginning users. What does it say if there are two places to administer widgets but some widgets can only be edited in one of the two? I think that segmentation could prove very very very confusing and frustrating to users.

      6) An alternative, much simpler change to widget administration could be similar to the front-end module edit link added to Joomla 3.2. I made a pass at this in the WP Inline Access plugin as you can see in the first screenshot on the plugin’s page. I think this comes down to what the most important feature of this plugin is. Is it to show how a widget looks (advantage: Customizer) or is it to help users quickly administer widgets from the front end (advantage: Link to Admin, in my mind).

      • Weston Ruter 5:46 pm on January 29, 2014 Permalink | Log in to Reply

        3) I think it’s important to consider how these would interact with the various “Widget Visibility” plugins (Jetpack’s Widget Visibility, Widget Logic, Widget Logic Visual, Conditional Widgets, Display Widgets, Dynamic Widgets, etc.). Right now, that can result to a widget appearing in the customizer but not in the preview.

        @mrwweb Actually, support for such Widget Visibility plugins has been added. When a widget is not rendered in the preview, it gets a semi-transparent indicator in the customizer. See https://github.com/x-team/wp-widget-customizer/issues/65

      • Weston Ruter 5:55 pm on January 29, 2014 Permalink | Log in to Reply

        5) If not all widgets can be supported when the feature is launched and not all themes can fully support the customizer, I worry that this will lead to further confusion for beginning users. What does it say if there are two places to administer widgets but some widgets can only be edited in one of the two? I think that segmentation could prove very very very confusing and frustrating to users.

        @mrwweb actually, all widgets and themes should be supported already (except for widgets with wide controls, as noted above). The piece that widgets and themes have to explicitly opt-in support for is live previews. Without that support indicated, then changes to widgets and their areas will cause the preview to refresh. This is in-line with other settings exposed in the customizer: by default they cause a refresh. Themes already have to add explicit support for live previews of settings (transport=postMessage), and so too the widgets need to indicate they support being updated without a page refresh. So themes and widgets that don’t indicate support for Widget Customizer will get a less responsive preview experience, but it all should still work.

    • Weston Ruter 5:42 pm on January 29, 2014 Permalink | Log in to Reply

      2) If this gets into core, it seems that a bit more consistency between the backend admin and Customizer would be useful. Particularly, if the widget icons are used in the Customizer, I’d expect them to be used in core.

      @mrwweb Yes, icons are being worked on for the Widgets admin page as well; see #25419. Also, @shaunandrews has been incorporating them into the Better Widgets plugin, which is also targeting core inclusion. See http://make.wordpress.org/core/2013/12/16/better-widgets/

    • Gregory Cornelius 8:40 pm on January 29, 2014 Permalink | Log in to Reply

      I think this would be a nice addition to the customizer. A few ideas:

      1) The widget block should be lower in the set of customizer components
      2) When selecting a sidebar, it would be nice if it was highlighted.
      3) I think it might be nice to keep the highlighting of the selected widget so that the user can orient themselves when making adjustments
      4) I wonder if it would be better if there weren’t update buttons and instead the preview auto-refreshed like the other settings do.

      In terms of the customizer as a whole, it would be nice if we could deep link to a specific component and incorporated some pushState() functionality in so that a plugin could experiment with removing the corresponding /wp-admin/ pages and still provide menu items that pointed directly to the component.

      • Weston Ruter 9:23 pm on January 29, 2014 Permalink | Log in to Reply

        1) The widget block should be lower in the set of customizer components

        It currently uses the default priority of 10 from WP_Customize_Section but a different priority maybe supplied via the customizer_widgets_section_args filter. Is there a better default priority?

      • Weston Ruter 9:26 pm on January 29, 2014 Permalink | Log in to Reply

        2) When selecting a sidebar, it would be nice if it was highlighted.

        That’s a great point. I had considered that, but the problem is that there is not guaranteed to be a single element container for the widgets in a sidebar widget area. I suppose the highlight could be added to the element that is the common parent element to all of the widgets. Or all widgets in the area could be highlighted together.

      • Weston Ruter 9:31 pm on January 29, 2014 Permalink | Log in to Reply

        3) I think it might be nice to keep the highlighting of the selected widget so that the user can orient themselves when making adjustments

        ?

        Agreed. The red glow is more of a placeholder. @shaunandrews has done some very interesting work on the widget highlighting front. There is an open pull request that needs to further build upon his prototype, which involves an innovative use of canvas to fade-out other parts of the page: https://github.com/x-team/wp-widget-customizer/pull/16

        Also, something which will help orientation is making sure that the widget stays scrolled into view: https://github.com/x-team/wp-widget-customizer/issues/56

      • Weston Ruter 9:36 pm on January 29, 2014 Permalink | Log in to Reply

        4) I wonder if it would be better if there weren’t update buttons and instead the preview auto-refreshed like the other settings do.

        Yes, this is something we’ve discussed, and there is an issue open for it: https://github.com/x-team/wp-widget-customizer/issues/45

        The problem with this is that widget controls may vary well have form validation in place (e.g. the RSS widget) which will cause a error message to appear in the form if it gets submitted before all of the fields are populated. Also, the widget update handlers may do some processing on the instance data (e.g. sanitizing or reformatting), so the content the user entered into the field may come back different when the form is submitted.

        If such field-by-field live previews were to be supported, it would require an additional level of support from each of the widgets.

    • Rindy Portfolio 3:57 am on January 30, 2014 Permalink | Log in to Reply

      This is a great leap forward for the customizer. Nice work!

    • Patrick Hesselberg 11:22 pm on January 30, 2014 Permalink | Log in to Reply

      Looks very cool! Gettings my plugin ready for this update!
      http://wordpress.org/plugins/pco-image-widget-field/

    • Weston Ruter 12:43 am on January 31, 2014 Permalink | Log in to Reply

      Released 0.14 of Widget Customizer, adding keyboard-accessible widget reordering and moving widgets to other sidebars (#21) (props @michael-arestad). /cc @arush @jorbin @accessiblejoe

  • Andrew Nacin 9:03 pm on January 22, 2014 Permalink | Log in to leave a Comment
    Tags:   

    Possible tasks for WP 3.9 

    During last week’s dev chat, we decided on a schedule. We also chatted about a major focus in 3.9 on improving workflow for new and current contributors alike. If there are further suggestions on changes we can make to workflow to make core easier to contribute to, let us know.

    Below is a rundown of what features/enhancements/ideas were discussed as possible for 3.9, including potential volunteers to take point on different tasks. This is all tentative. Thanks @DH-Shredder for compiling this.

    In today’s chat, let’s continue to build this out. If you have something you’d love to work on during the release, join us!

    Widgets

    There are two widget-related feature plugins to review: Better Widgets and Widget Customizer. Decisions on what we’re merging should come by next week, per the schedule. Expect a post from @shaunandrews soon explaining both and requesting help reviewing them.

    TinyMCE improvements (@azaozz, @gcorne, @lgladdy)

    • TinyMCE 4 inclusion and troubleshooting
    • Improving editing/positioning images after insertion into the editor

    Editor-related media improvements

    • Bringing the image editor into the media manager (@melchoyce, @johnbillion)
    • Allow a user to drop an item for upload on the post screen. This would then open the media modal (as an initial first step).

    A better themes experience, part 2 (@matveb)

    • Taking our new experience to the theme installer (this may be started as a plugin)
    • Supporting multiple screenshots, left out of 3.8
    • Backbone routing and subview backend improvements

    Improved audio/video support (@wonderboymusic) (see this post)

    • Playlists, subtitles, metadata generation
    • Media manager documentation

    JavaScript and CSS

    Miscellaneous

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

      RE: Grunt tool for patches

      It now is working for:

      patches you have in your local repository
      when you enter a ticket number
      when you enter a ticket url
      when you enter an attachment url
      when you enter a raw attachment url

      My next step is to add some more tests and write up documentation. Once that is in place, I would love to have some extra help testing. I most likely have some error messaging to improve and the like. I’ll post on make/core within the next week with info on how to help test/get involved.

      development is happening at https://github.com/aaronjorbin/grunt-patch-wordpress

    • Andrew Nacin 3:04 am on January 23, 2014 Permalink | Log in to Reply

      Some more things to add, from the meeting today:

      • @drewapicture is doing a mockup of a potential new tools screen he’s been talking about.
      • @gcorne is looking into syncing caret positions between the visual and text editors.
      • @obenland and @helen discussed including markup changes as part of the admin settings audit proposed by @jenmylo and @melchoyce. @Ipstenu and @ryelle are additionally interested in the UX side of things.
      • @helen proposed looking into better insert from URL handling in the media modal. This also ties into oEmbed insertion, and oEmbed previews / MCE views, which @gcorne has mentioned before.
      • @adamsilverstein brought up a post meta revisioning API. It happened in 3.6 but it was baked into post format UI stuff, and got pulled. It should be attempted again.
      • @TomAuger will be helping with image editing UIs, and posted work he’s been doing on #21811.
      • Manuel Schmalstieg 3:12 pm on January 23, 2014 Permalink | Log in to Reply

        > @gcorne is looking into syncing caret positions between the visual and text editors.
        Wow, that’s a wonderful idea! Improved preservation of whitespace when switching between visual/text modes would also be a major editing help.

      • Jen Mylo 5:46 pm on January 27, 2014 Permalink | Log in to Reply

        As I hear it, @ryelle is actually interested in the dev & API side of things.

    • RicaNeaga 10:25 am on January 23, 2014 Permalink | Log in to Reply

      So no plans in 3.9 for mysqli via #21663? Or hopefully full and official MariaDB support? Please reconsider, many are not happy (right now) to see only MySQL mentioned in the wordpress requirements page.

    • StyledThemes 12:54 am on January 24, 2014 Permalink | Log in to Reply

      Speaking of widgets, and something I am really amazed this is not part of the core…the ability to disable widget titles with each widget. There are many times where the title is needed for reference in the admin, but needs to be removed from the front-end. That’s one thing…the other would be a method to publish widgets to select pages/posts without having to install a plugin for this. Cheers!

    • Pippin Williamson 4:05 pm on January 24, 2014 Permalink | Log in to Reply

      I’d love to see the password generator enhancements get considered again, https://core.trac.wordpress.org/ticket/24633 – It’s mostly waiting on additional feedback. It was originally slated for 3.8 but then got pulled due to lack of feedback.

    • RENAUT 10:56 am on February 4, 2014 Permalink | Log in to Reply

      for TinyMCE improvements ability to deactivate fullpage icons and shortkeys for plugins using tinymce (in the simplest way) thank you

  • shaunandrews 2:59 pm on December 16, 2013 Permalink
    Tags:   

    Better Widgets 

    The Widgets team has been busy. :) Outside of the Widget Customizer plugin (posted about previously), we’re also working on some updates to the main wp-admin widgets screen through the Better Widgets plugin. This plugin does a bunch of things:

    • Available widgets have moved to the right side of the screen. The idea is that your widget areas (a.k.a. sidebars) should be the real focus of the screen — these are the things you can edit and manage. This may be a controversial change, as its the opposite of the menu screen (widgets closest cousin.)
    • Brings the widget icons from the Widget Customizer plugin to wp-admin.
    • Available widgets are now contained in a separately scrollable area. The goal is to help reduce to drag-and-scroll-and-scroll-and-scroll-and-drop problem that is so common from our initial research.
    • Widget descriptions are displayed in a single line, and truncated if they are too long. Clicking/Tapping on a widget expands the description (along with the area chooser from 3.8.)
    • Inactive Widgets are displayed below your active widget areas. This may be problematic as you have to drag-and-drop inactive widgets to active widget areas, but its an area we’d like to improve — maybe they should get an “area chooser”-like UI?
    • When editing a widget, the title is highlighted (using your current color scheme).
    • Clicking/Tapping on the “Save” button inside a widget now closes the widget and gives a quick confirmation message that the settings have been saved. This is based on some of our earlier user tests.
    • You’ve always been able to drag an active/inactive widget over the list of available widgets to deactivate it (yes, really!), but its been ugly. We’ve made it a little more tolerable. Give it a try.

    The plugin is still very young, but we’re looking to the community to get some interested from designers, developers, and testers. Please, install the plugin and play around. If you’d like to help us improve widgets, please join us every Monday at 20:00 UTC in #wordpress-ui — you can also drop your Skype nick below and we’ll add you to our ongoing chat.

    Some things to keep in mind when testing the Better Widgets plugin:

    • Responsive styles are essentially broken. Its on our short list, but we haven’t gotten to it yet.
    • The code is quick and dirrty — I’ve been the only developer committing code. Please, lets change this!
    • Some of this may look familiar to early MP6 adopters — this code comes from an earlier version of MP6, and was removed before the MP6 merge into 3.8.
    • We need accessibility help! Keyboard navigation is a must. I’d love to ditch the separate “accessibility mode” altogether and make it accessible out of the box.
     
    • PeterRKnight 3:26 pm on December 16, 2013 Permalink | Log in to Reply

      These improvements are really good!

      Better Widgets 0.2 gives me a php fatal error PHP Fatal error: Cannot redeclare wp_widget_control()
      (wp 3.8, no mp6 activated)

      • shaunandrews 3:44 pm on December 16, 2013 Permalink | Log in to Reply

        Ah shoot. This is why I shouldn’t be the sole developer on a plugin!

        I ended up modifying a core file so that I could make wp_widget_control() “pluggable” — hopefully someone knows a better way of doing this: https://gist.github.com/shaunandrews/7989121

        • Jose Castaneda 4:52 pm on December 19, 2013 Permalink | Log in to Reply

          jQuery would be one way. Remove then append. Not entirely ideal but can get it done. Unless we can make wp_widget_control filterable/pluggable in core.

      • shaunandrews 4:37 pm on December 16, 2013 Permalink | Log in to Reply

        For now, I’ve removed that “pluggable” function and bumped the plugin to v0.3. Unfortunately this means we lose the widget icon and the fancy styling of the widget descriptions.

    • DownHouse00 3:45 pm on December 16, 2013 Permalink | Log in to Reply

      Fatal error: Cannot redeclare wp_widget_control() (previously declared in domains\red.test\wp-content\plugins\better-widgets\widgets.php:24) in domains\red.test\wp-admin\includes\widgets.php on line 241

      • shaunandrews 5:40 pm on December 16, 2013 Permalink | Log in to Reply

        Grab the latest version (0.3) of the plugin — it should resolve this fatal error, but comes at the cost of some of the design/functionality. I’m hoping someone more knowledgable than me can help “fix” the issue at hand.

    • neojp 4:27 pm on December 16, 2013 Permalink | Log in to Reply

      I would love to see a built-in feature to choose what widgets show up depending on the page template / page url, like on Widget Context.

      http://wordpress.org/plugins/widget-context/

      • Weston Ruter 5:41 pm on December 16, 2013 Permalink | Log in to Reply

        @neojp In terms of sidebars, this is a feature of the Widget Customizer. The sidebar sections in the customizer will show/hide based on which sidebars are used on a given page. You can click around inside of the customizer to navigate to a page, and if that page template uses different sidebars, you’ll see the sections in the customizer change while navigating.

        It doesn’t, however, hide widgets from the sidebar sections if they aren’t currently rendered in the sidebar (e.g. via Widget Context or Jetpack’s Widget Visibility). Perhaps the widget controls could be made opaque or minimized, for example:

        I opened a Widget Customizer issue for this: https://github.com/x-team/wp-widget-customizer/issues/65

    • tomdryan 5:23 pm on December 16, 2013 Permalink | Log in to Reply

      Better Widgets is a great improvement already! The active widgets should definitely be front and center instead of off to the right as they have been historically — it makes much more sense.

      Is there a way to display which plugin created each widget? That would be very helpful info. Perhaps there could be a filter at the top of the available widgets column. It’s often difficult to figure this out from the name of the widget, especially if you are evaluating a number of plugins with similar functionality.

      • shaunandrews 5:39 pm on December 16, 2013 Permalink | Log in to Reply

        Filtering of available widgets is on my shortlist. Look at the live search-like filter UI available in the Widget Customizer plugin for a start. Sorting available widgets by their creator (think “default/core,” “Jetpack,” “theme name,” etc) could be useful as well. The icons may help with this, too.

    • Weston Ruter 5:32 pm on December 16, 2013 Permalink | Log in to Reply

      re:

      We need accessibility help! Keyboard navigation is a must. I’d love to ditch the separate “accessibility mode” altogether and make it accessible out of the box

      See @michaelarestad‘s work on adding a keyboard-accessible way to reorder widgets: https://github.com/x-team/wp-widget-customizer/issues/21#issuecomment-30152142

    • Mike Schinkel 7:15 pm on December 16, 2013 Permalink | Log in to Reply

      +1 on having the widgets on the right. I’d like to see menus reorganized in that manner, actually.

      Any thoughts given to targeting? For example, coming up with a “query language” based on resultant query vars from URL routing that would allow targeting specific pages or a group of pages. The query language could be used behind the scenes, of course, and give users nice and easy drop-downs. This was something I thought about doing a while back but then had to focus on other issues for clients.

    • Zoe Rooney 2:23 am on December 17, 2013 Permalink | Log in to Reply

      Just sent you (@shaunandrews) a pull request that improves the responsiveness via Github, so that at least it isn’t totally broken. Are you planning to use the issue tracker there for suggestions as well or do you want to keep commentary here mainly?

      • Zoe Rooney 3:16 am on December 17, 2013 Permalink | Log in to Reply

        Actually, I’ve noticed that the github repo is out of date. Would be happy to send you my suggestions for improving the responsiveness another way, as/ when it’s helpful!

    • David A. Kennedy 2:05 am on December 19, 2013 Permalink | Log in to Reply

      Hi all (and @shaunandrews)!

      I’m with the WP Accessibility team, and today during our team chat while discussing some of the needs of the plugin teams, I volunteered to help you all out. I love me some widgets, so I’m excited that they’re getting some love and look forward to helping bring accessibility into the fold. :)

      I’m leaving for vacation Friday and will be out of pocket for most of the Christmas holiday, but will spend some time catching up on the plugin goals and past posts. I’ll definitely install the plugin and play around with it from an accessibility standpoint. I’ll try to make the chat Monday (assuming there is one), and definitely those following the holiday.

      Let me know if you’ve tested anything from an accessibility standpoint or what questions you might have. I figure I’ll audit the plugin from all points accessibility, with a focus on keyboard navigation. I would love if we could remove the accessibility mode too.

      Where is primary development happening? Github? Somewhere else? I couldn’t find that in my brief scan of things. Where should I post feedback or contribute code?

      Thanks for thinking about accessibility and asking for help! Looking forward to making widgets a better experience for all!

  • shaunandrews 7:39 pm on December 7, 2013 Permalink  

    Widgets ♥ the Customizer 

    The Widgets team has been hard at work on our latest project which adds widget management to the customizer. It looks a little something like this:

    We’d love to have some more help, especially PHP and Javascript developers with experience with the customizer, to help up polish things up and get ready for a proposal for including in 3.9! If you’re interested in helping, please leave a comment with your Skype handle. I’ll add you to our ongoing chat, and all are welcome to join us in #wordpress-ui every Monday at 20:00 UTC.

     
    • Gustavo Bordoni 7:48 pm on December 7, 2013 Permalink | Log in to Reply

      Hey Guys, I would love to help. Skype: “webord”

    • Frankie Jarrett 7:48 pm on December 7, 2013 Permalink | Log in to Reply

      Very exciting! Way to go @shaunandrews @westonruter and team.

    • Brad Touesnard 7:55 pm on December 7, 2013 Permalink | Log in to Reply

      Dude, that’s awesome! One of the top questions when I was freelancing was how do I edit the sidebar/footer/some other area that uses a widget.

    • Rohit Tripathi 8:12 pm on December 7, 2013 Permalink | Log in to Reply

      Tremendous. Amazing. Lovely. Excited for it!

    • PeterRKnight 8:39 pm on December 7, 2013 Permalink | Log in to Reply

      This is really cool. I’ve been working with x-team’s plugin, but I can already see a lot of changes in this version. Is there a link to the plugin that is on display in the video? I’ll try to catch the chat on Monday. My main concern is allowing widgets that need a bit more space (width mainly) to function well.

    • Weston Ruter 9:34 pm on December 7, 2013 Permalink | Log in to Reply

      There are two big things being worked on right now:

      1) The new fly-in panel for selecting a widget to add (as opposed to the old select drop-down). Branch new-widget-addition, PR #58.

      2) Realtime previews of widget changes (as opposed to triggering a refresh of the preview). Branch issue-37-postmessage, PR #37.

      There are other issues that have been logged, some of which are low-hanging fruit and others which aren’t critical to address.

      Please fork the wp-widget-customizer repo, and open pull requests for the issues you want to tackle! For new issues, open pull requests to the develop branch; if you want to contribute to an existing branch (pull request), simply branch off of the existing branch (e.g. new-widget-addition) and then issue the pull request back to that branch so that your commits will be included when original branch (and pull request) is merged.

    • Graham Armfield 9:06 am on December 8, 2013 Permalink | Log in to Reply

      Please can I ask that anyone who gets involved with building this keeps accessibility in mind.

      Some things to think about would be: firstly, ensuring that all controls and settings can be reached and influenced by keyboard interaction – ie not requiring the user to use a mouse. The second thing to keep in mind is how the stuff you’re presenting will be voiced by screen readers. Please also ensure that there is good colour contrast.

      If there’s anything you are not sure about, please reach out to the Make WordPress Accessible team – we’re there to help devs understand more about accessibility when they’re putting new WordPress functionality together. And as soon as you’ve got something functional, let us know and we’ll try to put it through its paces.

      Thanks

    • Nashwan Doaqan 4:40 pm on December 8, 2013 Permalink | Log in to Reply

      Amazing! .. Five for X-TEAM and all the contributed developers!

    • Weston Ruter 11:23 pm on December 9, 2013 Permalink | Log in to Reply

      We could really use help testing the live previews for widget changes (PR #37), and the new UI for adding widgets (PR #58).

    • Jose Castaneda 12:01 am on December 10, 2013 Permalink | Log in to Reply

      That is amazing! I sort of wish I had known about this a little sooner! I’d love to help however I can just not as proficient with PHP/JS as I would like to be though. I can try and make the IRC chats and possible skype ( jmcasta85 ) but it’s not always easy for me since I work graveyard shifts.

      I’ll have to mess with this a little more in the coming days. :)

    • Primoz Cigler 11:18 am on December 13, 2013 Permalink | Log in to Reply

      I would be interested in this as well. I haven’t contributed to core yet, but I have build quite some themes with customizer, so I have some experiences. My skype: primozcigler

    • doubleyoumusic 10:29 am on December 16, 2013 Permalink | Log in to Reply

      I’m new to wordpress development but I really like this project and would like to help.
      Twitter: @jonathan_wilke

    • tomdryan 5:34 pm on December 16, 2013 Permalink | Log in to Reply

      It’s not working for me yet. When I run the Customizer, I see the list of widgets load, than it disappears and is replaced by the standard Customizer menus. Any ideas on this one?

      • Weston Ruter 5:49 pm on December 16, 2013 Permalink | Log in to Reply

        @tomdryan Does the template you have loaded into the customizer preview have dynamic_sidebar() calls in it? If not, then there are no sidebars on the page, and you’ll need to navigate to a page in the customizer which does.

        Also, if you are not running on trunk, you will not have problems seeing sidebars in the customizer if they are empty of widgets. See this notice shown in the plugin’s description:

        Unless you are running trunk, you won’t be able to add widgets to empty sidebars. This is because the temporary hooks necessary are removed in final releases. So you must currently add at least one widget to each sidebar (in the traditional way) for it to appear in the customizer.

    • tomdryan 6:45 pm on December 16, 2013 Permalink | Log in to Reply

      Count me in. Skype: tomdryan

  • shaunandrews 7:25 pm on November 4, 2013 Permalink
    Tags: ,   

    Widgets Area Chooser – 3.8 Proposal 

    Placing widgets with drag-and-drop can be tedious and annoying — especially if you have lots of sidebars on which to drop widgets. The Widgets team has been working on a few solutions (for this problem, and more), including redesigning the wp-admin widgets interface and adding the ability to manage widgets from within the customizer. These projects are still ongoing, and not ready for 3.8. However, along the way we’ve found a few incremental changes which improve the overall experience of working with widgets. Some of these improvements have made their way into MP6. Others involve more functional changes which don’t belong in MP6. This plugin is one of those improvements.

    The Widgets Area Chooser is available at: http://wordpress.org/plugins/widget-area-chooser/

    The Problem
    Dragging widgets from the available widgets in the top-left, to a sidebar “below the fold” is hard. Almost impossible. Dragging widgets on a touch screen device is also difficult.

    The Solution
    Clicking (or tapping) on an available widget brings up a list of available sidebars that you can place the widget in to — its pretty simple, and works great on touch devices.

    Accessibility
    There’s also the accessibility problems that drag-and-drop introduces, which necessitates the need for the separate (and often neglected) Accessibility Mode. This plugin provides a much easier way for those with screen readers to add new widgets without having to drag-and-drop. In fact, this could be the first step towards removing the need for an Accessibility Mode for widgets.

    Demonstration
    Here’s what the chooser looks like:

    Here’s a quick video of the plugin in action:

    Please let us know what you think!

     
    • william.deangelis 7:37 pm on November 4, 2013 Permalink | Log in to Reply

      Not bad. I assume that on mobile each of those two panels would be its own screen? If that’s the case then I say wicked. Go for it!

    • Jeff Behnke 8:20 pm on November 4, 2013 Permalink | Log in to Reply

      I like it. Solves the problems that need solving in the widget admin.

    • Bryan Petty 8:20 pm on November 4, 2013 Permalink | Log in to Reply

      Just wanted to say that I’m excited that you’re working on this @shaunandrews, and it’s coming along nicely.

      I’m still curious how well this UI handles with 3-5 widget areas, and maybe 50+ available widgets, and what happens with the stored/saved widget settings, but this really is a great start.

      • shaunandrews 1:43 am on November 5, 2013 Permalink | Log in to Reply

        Hey Bryan, thanks for the kind words — I’m super excited to be working on this!

        I think you may be getting the Widgets Area Chooser (WAC) plugin confused with the general layout updates as part of MP6 and the separate widgets project. This post is focused solely on the WAC plugin, which lets you click-to-add a new widget.

    • and0r1995 8:25 pm on November 4, 2013 Permalink | Log in to Reply

      I don’t know, I like the idea and stuff, but I personally prefer the drag and drop, Although when there are a lot of widget areas it’s a bit annoying.

    • Marcus 8:36 pm on November 4, 2013 Permalink | Log in to Reply

      I like this, already an improvement, nicely done!

      Aside from @bpetty ‘s point, another (minor) idea/tweak also is for UX just clicking on the area to place a widget instead of click area > add widget will save a click for non-default widget areas. The cancel button should probably still remain.

      • shaunandrews 1:47 am on November 5, 2013 Permalink | Log in to Reply

        …just clicking on the area to place a widget…

        I thought about that initially, primarily because it was one less new UI element to show on the screen — the widget areas are already there, just let the user click on them to add the selected widget. This caused two problems:
        1) It wasn’t immediately obvious what to click.
        2) It didn’t really solve the problem of the widget area being off the screen.

        If you have an idea on how to make this all better, please don’t hesitate to sketch it out and/or attend our chat on Monday at 20:00 UTC. Your thoughts and feedback is greatly appreciated. Thanks!

        • Luke McDonald 6:25 pm on November 8, 2013 Permalink | Log in to Reply

          My initial thought when trying this out for the first time was I would click on the widget area I wanted and the widget would be added to that area. I was testing on a theme that had 7 or 8 widget locations, which is why I didn’t see the “Add Widget” button below the chooser list.

          That said, for me it was *obvious* what to click, and I think it would be for many others too. It seems this functionality should replicate that of a select menu or your typical drop-down menu. In both cases, once you select an item, an action takes place.

          If it’s not immediately obvious for users the first time, it will be the next time they do it. I think after someone knows how it works, it would be preferred not to have to make an extra click or even scroll down to the “Add widget” button in cases where there are many widget areas.

    • mbootsman 9:17 pm on November 4, 2013 Permalink | Log in to Reply

      Major UI improvement. Thanks for developing this!

      • shaunandrews 1:49 am on November 5, 2013 Permalink | Log in to Reply

        Thanks for trying it — hope you like it. Please let me know if you find any problems, or have any suggestions for improvements.

    • Dan Milward 2:59 am on November 5, 2013 Permalink | Log in to Reply

      Awesome work man. I don’t know why but on one of my test sites the list of available widgets is on the right hand side of the screen instead of the left hand side of the screen. Its pretty weird.

      Also I hope the menus screen gets a similar overhaul.

      • shaunandrews 3:16 am on November 5, 2013 Permalink | Log in to Reply

        Perhaps you’re using an older version of MP6? Can you provide version details for WordPress, MP6, and the Widgets Area Chooser plugin? Also, what browser and OS? A screenshot would go a long ways as well.

    • Grant Palin 5:17 am on November 5, 2013 Permalink | Log in to Reply

      I like it. I’ve found the drag and drop setup a bit finicky before, and the click, click, click seems a usability improvement, especially when multiple widget areas are involved. Plus the UI fits nicely with the MP6 theme.

    • HerrLlama 11:19 am on November 6, 2013 Permalink | Log in to Reply

      I don’t like it. The UI is nice tough, but the usability is … well how could I say it neat? … a piece of crap. Now I drag and drop the widget on the wanted position in the wanted widget area. With this “improvment” I have to click on the widget, then I have to choose the area and than click I have to click the add button. But after all that I have to drag and drop the widget on the right position. Seriously, that makes it more complicate than it could be.

      • shaunandrews 2:51 pm on November 6, 2013 Permalink | Log in to Reply

        You can still drag-and-drop widgets in to place. You don’t have to click.

        • HerrLlama 3:57 pm on November 6, 2013 Permalink | Log in to Reply

          Yes, I already read this, but your proposal is a way more to confuse the users. WordPress itself said that they wanted to implement decisions, not options. It would help if we don’t work on the frontend for the widgets and create an API (e.g. add_widget_to_sidebar( $widget_type, $sidebar ) or stuff like that) which actually works.

          I agree, that the UI needs some improvements, but there are plenty of different screens of editing things (tags, posts, menus, widgets, options, etc) which also confuses the users. I think we should focus on a consistent backend before we implement new things. If not, I think that is a major problem of WordPress. Have you ever been to a Typo3 backend? Everything looks like it is in one pour.

          And also: Sorry for beeing rude, but I’m german ;)

      • Helen Hou-Sandi 3:20 pm on November 6, 2013 Permalink | Log in to Reply

        As @shaunandrews noted, this does not replace drag and drop; it provides an alternate method for those who can’t or don’t want to drag and drop for whatever reason. Also, you are being rude, and that is unnecessary.

      • Matt Thomas 6:19 pm on November 7, 2013 Permalink | Log in to Reply

        I would recommend re-reading the original proposal. Managing widgets is currently not possible on a mobile device because drag-and-drop is the only supported method of adding or removing widgets.

      • PeterRKnight 4:17 am on November 8, 2013 Permalink | Log in to Reply

        drag and dropping a position vertically is easy (on desktop), the issue with the current widgets screen that this improvement solves is about making it much easier to add widgets to widget areas without having to do acrobatics. Try dragging and dropping a widget on a screen that requires scrolling because there’s so many widgets and so many widget areas. This however is a major usability improvement for desktop as well as mobile.

    • bfintal 2:08 pm on November 11, 2013 Permalink | Log in to Reply

      I like it. This would solve the drag and drop problem in mobile versions also.

      This is just me, but a method of duplicating a widget would be helpful.

      • shaunandrews 2:46 pm on November 11, 2013 Permalink | Log in to Reply

        Yup, part of the goal with this was to improve the experience of adding widgets on mobile.

        This is just me, but a method of duplicating a widget would be helpful.

        This isn’t the first time I’ve heard this request, so you are not alone. :)

      • Weston Ruter 6:20 pm on November 11, 2013 Permalink | Log in to Reply

        Regarding duplicating a widget, there is this Duplicate Widget plugin and there is the Clone Widgets plugin. The former does a shallow-copy/symlink/reference for the widget, and the latter seems to do a clone or deep copy of the widget. Which use case are you interested in? Do these plugins do what you want?

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

  • Scott Taylor 4:48 pm on August 19, 2013 Permalink
    Tags: ,   

    Featured Content: Getting Started 

    Ahead of our first official office hours, here is an overview of what I would like to discuss:

    What is Featured Content?

    Obenland discussed the high-level concept here: https://gist.github.com/obenland/3010432c8edcfcbf95a9

    To me, Featured Content is a flexible way to show one or many posts in one or many places in your theme. A blog might have 1 featured post area that will support 1-4 posts, as an example. A more complex site using WP as a CMS might program its homepage using many “featured areas” that contain varying numbers of post-like entities.

    Featured Content, in the end, is just a way to return posts chosen by a content producer. The way in which featured content is selected should be intuitive, easy to manage, and use existing WP technology/terminology whenever possible. A featured post-like thing should an entity that points at a canonical post, while having the ability to override any of the parent post’s attributes on display. Example: I should be able to use a different title and image for a post that is featured when it is rendered in a featured area.

    I should also be able to schedule featured items, much like I can schedule a post.

    How are we going to implement it?

    Here are my ideas:

    I think we can get a lot of immediate mileage using a custom taxonomy, working name: “Featured Area” and a custom post type, working name: “Featured Item”. By default, a function like `wp_get_featured_content()` can return all featured posts. Passing a parameter can return posts matching that featured area slug that are published – `wp_get_featured_content( ‘mini-header’ )`. A custom taxonomy can be registered to post and featured_item. Themes can register the taxonomy for more post_types as necessary.

    The plugin, in its current form, implements all of the above: http://wordpress.org/plugins/wp-featured-content/

    Things to consider:

    • How do we always keep the post and its featured_item brethren in sync?
    • Do featured_items and posts always share the same post_status? Should they be independent?
    • How do themes opt in to multiple featured areas if the terms have not be created for the featured_area taxonomy?
    • What are alternate ways to implement the above?
     
    • George Stephanis 4:56 pm on August 19, 2013 Permalink | Log in to Reply

      This may be a bit out of scope, but I would like to also consider a wp_get_featured_content( array( 'post_id' => 123 ) ) contrasted with that may wp_get_featured_content( array( 'location' => 'mini-header' ) ) — that could be used to fetch related posts or the like?

      Just have it accept an $args array, rather than a string, so it’s more extensible for plugins to offer new ways to use.

    • shaunandrews 4:59 pm on August 19, 2013 Permalink | Log in to Reply

      I haven’t been following to closely, so please excuse my ignorance, but what if featured content was just a widget (or content block) that you could place into any sidebar area, post, or page?

      A blog might have 1 featured post area that will support 1-4 posts, as an example. A more complex site using WP as a CMS might program its homepage using many “featured areas” that contain varying numbers of post-like entities.

      This sounds very similar to widgets and sidebars…

      With the rethinking of widgets and post-formats-as-blocks, there’s been chatter about combining the two concepts. Widgets would become content blocks, which could then be dropped into a post, page, or widget area. There could be a “featured content” block (né widget) that allows you to pick posts to feature. You could place this block into a “content area” (né “widget area”), post, or page.

      • paaljoachim 9:08 pm on August 24, 2013 Permalink | Log in to Reply

        + 1. Creating consistency is very important. I would suggest merging Featured Content into CEUX. As featured content would be a natural content block one of many that can be added into CEUX. As Content Blocks gets going more and more blocks will naturally also be added.

        Featured Content to me would be like using the short code that I am using through the themify.me shortcode panel. A panel for which categories to show, how many posts to display, order, list/thumb/4-grid/etc. Below is a screenshot from the Themify Page Builder:
        http://easywebdesigntutorials.com/wp-content/uploads/List-Post-Themify-Builder.jpg

        What other good options exist today can we learn from?
        Any good plugins to show features categories/content?

    • Manuel Schmalstieg 5:01 pm on August 19, 2013 Permalink | Log in to Reply

      Here are my 2 cents, from my experience implementing custom themes for various clients. A “featured post” functionality is something i’m using all the time. What I use for that is generally a custom Taxonomy, which holds all the “display settings” that are needed for a site.

      Using a regular Category is generally bad, because it blurs the role of the “visible categories” (visible on the frontend, and in URLs), which for clarity shouldn’t be mixed with “settings” categories, of which the “featured item” is a perfect example. So a custom “Settings” taxonomy is what I consider the cleanest and most logical way.

      Using a Custom Post Type is a bad idea, in my experience, as you cannot easily switch a regular post into another CPT. Imagine that you wrote a post with title, content, image attachments, categories and tags – then you decide this should be a featured item. You would have to copy everything over to the “Custom Post Type”. Bad user experience…

      @ Shaun Andrews: indeed, if we had a “Archive of any Taxonomy widget”, we could use a widget area, and define “last X posts of with Taxonomy:Display Settings and Term:Featured Item…

      • Chip Bennett 5:15 pm on August 19, 2013 Permalink | Log in to Reply

        I think combining custom post meta data with a new “Featured Content” taxonomy is all that’s needed here, and would be quite powerful. The post meta data designates the post as “featured”, and the taxonomy associates the post with other related posts, allowing for multiple groupings of “featured” content. WP_Query calls (with appropriate post meta and taxonomy parameters) in the template handle the rest.

    • Chip Bennett 5:02 pm on August 19, 2013 Permalink | Log in to Reply

      I think creating a CPT is probably too heavy for “featured” content. The status of being “featured” is independent of content type, and as such would be better suited either as a custom taxonomy – or, perhaps better yet: as custom post meta data.

      Using custom post meta data allows any content type – posts, pages, or any custom post types – to be designated as “featured”, and to be queried/displayed accordingly.

      • Manuel Schmalstieg 5:04 pm on August 19, 2013 Permalink | Log in to Reply

        Using custom post meta data allows any content type – posts, pages, or any custom post types – to be designated as “featured”, and to be queried/displayed accordingly.

        Full agreement, as per my comment above.

      • Rohit Tripathi 5:46 pm on August 19, 2013 Permalink | Log in to Reply

        I totally Agree. Using CPT is not feasible at all. Custom post meta data does make a lot of sense. That would be the right way to proceed.

    • Chip Bennett 5:08 pm on August 19, 2013 Permalink | Log in to Reply

      Pet peeve alert:

      …A more complex site using WP as a CMS…

      WordPress is a CMS, and is always used “as a CMS”.

      Pet peeve/rant aside: The front-page.php template file has been around for a long time now, meaning that it is simple for any Theme to designate a custom site front page template. The normal use-case for such a template is “featured” content, so I’m all in favor of standardizing on how content is designated as “featured”.

    • Jonathan Desrosiers 5:19 pm on August 19, 2013 Permalink | Log in to Reply

      I created a quick solution for this (http://wordpress.org/plugins/post-type-spotlight/) because it comes up frequently on our projects. Our plugin adds a check box for content editors to designate something as featured.

      I like the placement, and I think that could work well with the scheduling aspect of featuring, because it could function similar to the Publish & Visibility fields.

      Would there be any disadvantages to assigning it to a specific featured area? Instead of using an area, it could be simply featured, or not featured, and wp_get_featured_content() could accept other parameters, such as which categories/custom taxonomy terms it should also have, or what publish dates, etc..

    • Weston Ruter 5:41 pm on August 19, 2013 Permalink | Log in to Reply

      It seems a key feature to include with these featured content areas is the ordering of posts within them. Consider a news site that has homepage sections for different news categories (Local, National, Sports, Entertainment, etc). Editors need to have control over the ordering of the posts that appear in these featured content areas. Hacking the publish date to ensure proper ordering is not an option, as the same post may appear in a different order in other featured content areas.

      • Chip Bennett 5:43 pm on August 19, 2013 Permalink | Log in to Reply

        That can be custom post meta data, also: “Featured Content Sort Order”

        • Fab1en 7:19 am on August 20, 2013 Permalink | Log in to Reply

          No: the custom post meta data can only be present once : it is not linked to the area. What if my post must appear first in Local category and second in Sports one ?

      • Manuel Schmalstieg 12:44 pm on August 20, 2013 Permalink | Log in to Reply

        Oh, if we could come up with a good solution for “custom-ordering” things, that would be amazing (and would be useful beyond the scope of featured content)! If we would apply the taxonomy logic to featured content, could we imagine that we give to some taxonomies “support for custom-ordering”? And provide a new interface, where the content of each taxonomy term could be ordered by drag-and-drop?

        My typical use case would be: a “Series of posts” or “Related content” custom taxonomy, which gets used by the theme to display “other articles in this series”. Each term then becomes a group of related content (or “featured content”). If that term/group could be ordered, it would be CMS heaven…

    • Chris Olbekson 5:47 pm on August 19, 2013 Permalink | Log in to Reply

      Sorting by postmeta requires a meta_query and I think we can all agree that this is not ideal. I think the term_order column would be great here. See my comments on http://core.trac.wordpress.org/ticket/9547#comment:26

      • Chip Bennett 5:59 pm on August 19, 2013 Permalink | Log in to Reply

        I don’t think there’s anything inherently “not ideal” about using a meta_query, but I certainly agree that term_order would be a better solution all around.

        • Scott Taylor 6:13 pm on August 19, 2013 Permalink | Log in to Reply

          meta_query falls apart at scale

          • Chip Bennett 6:17 pm on August 19, 2013 Permalink | Log in to Reply

            How much scale is needed for “featured” content? Having even 10 “featured” posts would probably be near the edge case.

            As for scale: if I’m understanding the concept properly, the idea is to mimic custom nav menus, and have a CPT that identifies an existing post/page/whatever, so there will be a one-to-one relationship between “featured” CPT and existing content. The CPT is queried, and then each associated post must then be queried from within that query, in order to display post data?

            That seems like a far bigger scale/performance issue than using post meta.

            Alternately: users will have literally have to duplicate content in order to designate a post/page/whatever as “featured” – and I would hope that idea is a non-starter?

            • Zack Tollman 6:19 pm on August 19, 2013 Permalink

              Alternately: users will have literally have to duplicate content in order to designate a post/page/whatever as “featured” – and I would hope that idea is a non-starter?

              I think a better term than “duplicate” is “fork”. It copies the content to the post featured content type. It can then be changed without ever re-syncing the content.

            • Scott Taylor 6:22 pm on August 19, 2013 Permalink

              There is no duped content – the featured_item has the post as post_parent/foreign id. That’s normalized. The only content that is even populated is overrides. “Featured” is really content that is “designated” to an area. The use-case is more for programming a homepage, or ad areas. That won’t be the default use case. But if all we care about is a flag, why not stay with stickies or a category?

            • Chip Bennett 6:29 pm on August 19, 2013 Permalink

              I’m guessing that the most common use-cases will be front-page sliders, and single-post/page feature boxes.

              In any case, the biggest win here is standardizing the method of designating content as “featured”, so that such designation is portable among Themes. Using “stickies” is common, and works, but is limited. Having an actual “featured content” taxonomy would allow for far more flexibility, while retaining standard conventions.

          • Chip Bennett 6:26 pm on August 19, 2013 Permalink | Log in to Reply

            Looking at the referenced Plugin, running two queries is exactly what’s being done:

            $args = array(
            	'fields' => 'id=>parent',
            	'post_type' => WP_Featured_Content::POST_TYPE,
            	'orderby' => 'menu_order'
            );
            
            if ( ! empty( $term->term_taxonomy_id ) ) {
            	$args['tax_query'] = array(
            		array(
            			'taxonomy' => $term->taxonomy,
            			'field' => 'term_taxonomy_id',
            			'terms' => $term->term_taxonomy_id
            		)
            	);
            }
            			
            $query = new WP_Query( $args );
            
            if ( empty( $query->posts ) )
            	return array();
            
            return get_posts( array( 
            	'post__in' => wp_list_pluck( $query->posts, 'post_parent' ), 
            	'post_type' => 'any',
            	'orderby' => 'post__in'
            ) );
            

            The contention is that this is faster/more scalable than a single meta_query?

    • swissspidy 5:51 pm on August 19, 2013 Permalink | Log in to Reply

      Just as Helen noted on Trac, querying for post metadata would be too slow: http://core.trac.wordpress.org/ticket/24857#comment:17

      I think CPT + taxonomy is fine and allows for better flexibility e.g. (multiple) custom featured items for a post.

      • Scott Taylor 5:54 pm on August 19, 2013 Permalink | Log in to Reply

        that’s the main point – a post should be able to be featured in multiple featured areas, with different display data in each, like a different title/image per area

      • Chip Bennett 5:58 pm on August 19, 2013 Permalink | Log in to Reply

        Using a CPT means that one bit of content must be both its original content type (e.g. “post”), and also a second content type (e.g. “featured”). That means that content is inherently duplicated. I don’t get how that is in any way ideal.

        • Helen Hou-Sandi 6:01 pm on August 19, 2013 Permalink | Log in to Reply

          Given that this is exactly how nav menus work (CPT + taxonomy), this seems like a non-argument.

          • Chip Bennett 6:04 pm on August 19, 2013 Permalink | Log in to Reply

            Except that nav menus aren’t a separate type of content; they are a link to content. Featured content is actual content, that already exists as an appropriate content type. “Featured” is merely a designation that describes that content, and correlates that content to other content. Thus, post meta and/or taxonomy is the correctly analogous data type.

        • Zack Tollman 6:17 pm on August 19, 2013 Permalink | Log in to Reply

          I think that the “duplication” is a good thing. Once the content is “featured”, it becomes a different type of content. It then takes on different properties. It is reasonable to think that when content is featured, it takes on a different title, featured image, post content, etc. “Forking” this from the original post makes sense in that we can use the CPT API to manage all of that content. Moving this content into post meta fundamentally changes how we would work with the pieces of content associated with a post. For instance, if we change a title of a post when it is featured and save it as post meta, do we run the “get_the_title” filter on it when retrieving it? I think it makes sense to use the API that is developed for the purpose of interacting with post content and using a new CPT for this purpose makes sense.

          • @ubernaut 3:41 pm on August 20, 2013 Permalink | Log in to Reply

            i think the main issue here is that you end up with a bunch of old no longer featured CPTs and expiration feature for these would resolve that issue imo.

      • Chip Bennett 6:01 pm on August 19, 2013 Permalink | Log in to Reply

        Also, regarding query speed: improve the query if/where need be – and that speed discussion compares taxonomies to post meta, and does not address CPTs particularly.

    • Taylor Dewey 6:35 pm on August 19, 2013 Permalink | Log in to Reply

      Here is an initial round of mockups based almost entirely on a featured item solution that we built for Global News (http://vip.wordpress.com/2013/04/25/global-news-qa/). I took out some of the UI that was more specific to them.

      The architecture we build uses a CPT + CTT. Featured areas are a hierarchical taxonomy. Featured Items are a custom post type generally derived from, and linked to original content. Curating a featured item is done from a separate admin screen (I’d love to see a way to do this from the content itself, too). Each item is sortable within it’s featured area. Adding a new curated item is a three step process that takes place in a modal.

      http://cl.ly/3W3r190k2z1i

    • karmatosed 8:01 pm on August 19, 2013 Permalink | Log in to Reply

      I’ve gone with the easiest option for my first batch of sketch mockups. These show just a single checkbox option. I then explored some potential placing for an editor/allocator/collection (*needs funky name) interface.

      I will be back with a second round of wireframes but wanted to get these out as the easy end of things.

    • karmatosed 9:57 pm on August 19, 2013 Permalink | Log in to Reply

      I have explored some potential allocation screens. I don’t feel either are there yet but worth sharing the experiments.

      The first is the simplest. This can have a theme defined image to allow for users to at a glance understand what areas are featured. To the side are the featured areas and you click into each to see the posts assigned. I’m not sold we should move from the edit post screen assigning I explored earlier but allowing myself to explore.

      The second I like a bit better but still would like to see how more of this could be done in the post edit screen / single post (that’s going to be my next experiment). This has the ability to add or take away so we could even just strip back to the short code. This nods to your work @taylorde so thank you.

      Neither covers fully everything discussed but I’m still playing.

      • karmatosed 5:10 pm on August 20, 2013 Permalink | Log in to Reply

        Building on from the last wireframe, I have explored what collections could be like. This focuses on collections you then assign to content areas for featuring.

    • paaljoachim 9:09 am on August 20, 2013 Permalink | Log in to Reply

      What about adjusting the Create/edit Category to look similar to make a new page/post? To keep the consistency of the overall design method? This way the user can easily create a new category and create a design for it at the same time. I am using templates for the pages/posts/categories. Use an existing template and see the visual changes in the layout area. Modify and save as a new template to be used in other places.
      http://easywebdesigntutorials.com/wordpress/wordpress-mockups/

      I do agree that creating a listing through a category page or regular page of specific posts within a specific category can also be done with a widget/element/content block.

    • karmatosed 10:57 am on August 20, 2013 Permalink | Log in to Reply

      I continued today and moved onto what would things look like if all done in the post edit screen. I’ve added in the ability to pick a featured image (or have it auto select one) and not just using the featured post image. This probably requires some thought about how but it’s something I know was mentioned in the chat so seeing where it could fit.

    • @ubernaut 3:36 pm on August 20, 2013 Permalink | Log in to Reply

      i put this on the trac ticket yesterday it very rough (some missing bits as well) but illustrates my idea of borrowing the menu ui:

    • karmatosed 4:56 pm on August 20, 2013 Permalink | Log in to Reply

      I had a look for another wireframe at what a box would look like on the single post edit screen. This is a simplified format.

    • Robert Dall 10:59 pm on August 20, 2013 Permalink | Log in to Reply

      One of the reason I wanted to part of this group was the ability to show a bunch of content together. What was once template and query based could now be done in the UI would be a great addition to WordPress.

      After reading most of the posts I have seen any reference to see if the user only wants to use a post excerpt as the featured content.

      Or if they wanted more of a Featured Image, Title, Excerpt. Read more link.

      What if they only want featured content that is only the titles of other posts?

      I have done this via wp_query and template for a number of websites and as it helped people who liked to click on both the header and for people who like to click on the drop down.

      See Annotated Screenshot:

      uprising-breads-featured-content

      See actual page here: http://www.uprisingbreads.com/bread

      Or here is another page

      Couple Questions?

      • Is this the actually direction of this plugin or is it an iteration that is heading off in another direction?

      • Also the order of this content could it be controlled by the actual menu order? Or would have to create the “featured content” and then create the drop down menu of the same order?

      And if I have jumped the gun on these topics my apologies…

    • Scott Taylor 2:14 pm on August 21, 2013 Permalink | Log in to Reply

      We are in an exploratory phase. If something interesting pops up, we may move in a different direction.

    • Matt McLaughlin 4:06 pm on August 21, 2013 Permalink | Log in to Reply

      I have to say that I’m with @shaunandrews in thinking that this should not be a new high level UI concept but rather a canonical implementation of how to use Content Blocks/Widgets to achieve the same goals. The absolute last thing I want for my users is yet more UI concepts to confuse them. A grand unification of all the types of static and dynamic content blocks whether they appear on the front page, a post, page, or in a sidebar is just exactly what the doctor ordered.

      That said, I think there’s a lot that can be done in terms of simplifying the act of choosing and formatting content for highlighting using a really well thought out core Content Block for featured content.

      More musings here: http://mattnamclaughlin.wordpress.com/2013/08/21/featured-content-as-a-widget-or-content-block/

      • Taylor Dewey 6:52 pm on August 23, 2013 Permalink | Log in to Reply

        I agree. In fact, I’ve used my version of a featured item curator as a replacement for the menu system on one of these projects.

        However, it was significantly less flexible than the current implementation. And same with widgets. Making a UI that can manage all of those will require some serious work. However, I’d love to see a UI that can accomodate everything that we need to go this route in the future.

    • magicroundabout 8:21 am on August 29, 2013 Permalink | Log in to Reply

      Hi Everyone,

      I’ve been following some stuff on core but have not contributed before. This conversation caught my eye.

      There’s a couple of requirements that I have for this that hasn’t been mentioned yet:

      • you might want links to things other than single content items. Custom links to external resources, media items, archives of posts
      • different images have been suggested, but you might want to display a different title too. Some of my featured areas have limited space and you might need an alternative title to fit the space.
      • Sometimes these areas need to contain multimedia. So would it be possible to have an option to insert an oembed code?

      I definitely think a menus-like interface with defined areas and drag-and-drop organisation would work better than a meta-box on existing post types, or as a custom post type or taxonomy. For me that’s just not flexible enough. But the ability to be able to choose posts to go in a featured area remains a must.

      Hope that’s useful. I’ll keep an eye on the conversation and try to contribute if I can.

      Thanks

      Ross W

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