WordPress.org

Ready to get started?Download WordPress

Make WordPress Core

Updates from January, 2014 Toggle Comment Threads | Keyboard Shortcuts

  • Mike Schroder 6:03 am on June 19, 2014 Permalink | Log in to leave a Comment
    Tags: ,   

    Last Week(s) in WordPress Core 

    Hi Everyone! It’s time for another update. This edition covers through Sunday, June 15th, and has taken a while due to travel, but @swissspidy & @designsimply have joined the team, helping to gather the information to bring us up to date. Hopefully this will help these updates be a bit more sustainable over time. If you’re interested in pitching in with these updates as well, please let me know in the comments below!

    Especially of note are the first pass of the grid view for the media library, several SSL and oEmbed updates, and a new ‘Beta Testing’ tab on the Plugins screen.

    Admin

    • Plugins Screen: Add a new ‘Beta Testing’ tab on the plugin installation screen, for features as plugins such as Press This. [28749] #28513
    • Media Library: Grid view for the media library, first pass. This is alpha; expect imperfection to start. [28682] #24716

    SSL

    • Forcing SSL logins now forces SSL for the entire admin. [28609] #10267
    • Force SSL on the frontend when the home URL uses HTTPS. [28610] #27954
    • Force SSL admin when siteurl is explicitly configured with HTTPS. [28674] #27954
    • Use a secure logged_in_cookie when the home URL is forced HTTPS. [28627] #15330
    • Deprecate url_is_accessable_via_ssl(). [28709] #19555

    Embeds

    Themes and Templates

    • Add a filter to human_time_diff() to allow more detailed depictions of time differences. [28670] #27271
    • Allow simple modification of sections of the title by adding a wp_title_parts filter to wp_title(). [28669] #17877
    • Add CSS rules to ensure that videos will be responsive, regardless of theme. [28650] #28414
    • Replace TEMPLATEPATH and STYLESHEETPATH with get_template_directory() and get_stylesheet_directory(). These constants are now deprecated [28563] #18298
    • Update Twenty Thirteen and Twenty Fourteen to Genericons 3.0.3. [28692] [28693]

    Accessibility

    • Improve keyboard accessibility for the media modal. [28607] #23560
    • Add screen reader labels to the date inputs on the post editing screen. [28730] #25461

    WP_Query

    • When parsing the main query, if s is set to empty: ?s= and $this->is_main_query() && array_key_exists( 's', $this->query ) – kill the query instead of loading the homepage. This will load the search page with no results. [28612] #11330
    • Kill queries that explicitly pass empty arrays to category__in, tag__in, tag_slug__in, and author__in to WP_Query. [28664] #28099
    • Fix SQL generation when meta_query has an 'relation' => 'OR' for its queries and wants to 'orderby' => 'meta_value'. [28659] #25538
    • Allow users to sort posts by type in WP_Query. [28605] #28214
    • Add access modifiers to WP_User_Query Add magic methods for BC: get(), set(), isset(), unset(), and call(). [28528] #27881, #22234

    Internals

    • Wide-reaching changes to do away with many instances of variable-variables. See #27881 for full list of changes.
    • Eliminate use of extract() within WordPress. #22400
    • Fix curly quotes around numbers when applicable. [28721] #8775
    • Only include relevant post authors in WXR exports. [28731] #20206
    • Append the date to $wp_version in the build output, for nightly packages. [28611] #26751.
    • Update wp_insert_comment() and wp_new_comment() with a check for successful database insert. [28672] #28254
    • Use get_pages() instead of a raw SQL query in get_body_class(). [28696] #28159
    • Pre-populate the selected URL or mailto:<email-address> when “Insert/edit link” is clicked. [28705] #19992
    • Live update the menu item title when the user is editing the “Navigation Label” field. [28707] #23076
    • Deprecate get_all_category_ids(). Suggest get_terms() as a replacement. [28679] #21200
    • Deprecate like_escape() and replace with $wpdb->esc_like(). [28711] #10041
    • Redirect edit.php?post_type=attachment to upload.php to avoid an empty list table. [28729] #27951

    Formatting

    TinyMCE:

    • Update TinyMCE to 4.0.28. [28606] #28391, #27941
    • In iOS, fix placing the caret at the bottom of longer posts when the keyboard is open and disable resizing on switching editors and on show/hide of the kitchen sink row. [28626] #28242
    • Fix problems with undo/redo after resizing an image several times. [28614] #28389
    • Fix saving the editor content on switching from Visual to Text. [28576] #28353

    Thanks to @aaroncampbell, @adamsilverstein, @alexander.rohmann, @aliso, @atimmer, @avryl, @azaozz, @boonebgorges, @bramd, @celloexpressions, @clifgriffin, @coffee2code, @danielhuesken, @DavidTheMachine, @DeBAAT, @donncha, @DrewAPicture, @eddiemoya, @edwin-at-studiojoyo.com, @ericlewis, @filosofo, @frank-klein, @Funkatronic, @garhdez, @gauravmittal1995, @gcorne, @georgestephanis, @ghost1227, @grahamarmfield, @harrym, @helen, @iamtakashi, @iljoja, @issuu, @ixkaito, @jackreichert, @JanHenkG, @Jayjdk, @jdgrimes, @jeffstieler, @jeremyfelt, @jesin, @jgadbois, @jjeaton, @jkudish, @joedolson, @johnbillion, @johnjamesjacoby, @johnzanussi, @jtsternberg, @kitchin, @knutsp, @kovshenin, @kpdesign, @kraftbj, @kurtpayne, @kwight, @lancewillett, @lessbloat, @markoheijnen, @mdbitz, @MikeHansenMe, @mikemanger, @miqrogroove, @mrmist, @MuViMoTV, @nabil_kadimi, @nacin, @nd987, @Nessworthy, @netweb, @niallkennedy, @ocean90, @obenland, @pdclark, @pento, @purzlbaum, @rclations, @redsweater, @ruudjoyo, @schoenwaldnils, @scribu, @senlin, @SergeyBiryukov, @sharonaustin, @shaunandrews, @simonwheatley, @sixhours, @slimndap, @solarissmoke, @tar.gz, @tillkruess, @topher1kenobe, @torresga, @UmeshSingla, @winterDev, @wonderboymusic, @wpsmith, @zamfeer, and @duck_ for their core contributions!

    Thanks to @swissspidy & @designsimply for their help with compiling this post.
    Revisions covered: [28528] to [28757]. For the complete list of commits to trunk, check out the log on Trac.

    Interested in joining in? Write or test a patch for 4.0.

     
  • Helen Hou-Sandi 8:30 pm on May 6, 2014 Permalink | Log in to leave a Comment
    Tags: ,   

    Summary of last week’s dev chat on 4/30 (IRC log):

    Announcements

    Features as plugins

    • Met on 4/29 (IRC log)
    • Current potential considerations seem to be WP API and media grid.
    • Press This is getting some attention from an early stages working group, which could also be a part of the 4.0 release.
    • Admin Help is poised to shift into more of a continuous testing and advisory group, which is awesome.
    • Front-end editor is making good progress, but has UX issues that are getting worked on, needs iteration and experimentation and probably won’t be ready by 4.0, but should continuously be worked on, as is the goal of features as plugins in the first place. Developers needed.

    Potential ideas and their suggesters:

    Summary: we have good things in mind about more media improvements, more editing experience improvements, more visual media grid and better plugin installer experience (following in the footsteps of themes), and behind the scenes wins in taxonomy, multisite, and post type and comment APIs.

    If you’re interested in any of the above or have other ideas, please sound off in the comments.

    Getting involved

    • We are always looking for more people to be involved with Trac gardening, patch review, patch writing, or some combination thereof.
    • Component pages are running well, and most could still use the caretaking of a component owner or somebody who’d like to become well-versed in a particular area of core. To get started, just sign up for component notifications at http://make.wordpress.org/core/notifications/. No need to be an expert now – learning and persistence is more important.To help with a specific plugin, join their weekly chats and/or follow along wherever they post. See the Features as Plugins page for more information.
    • A reminder from @matt to always be dogfooding the product – use WordPress every day.

    Bonus punnage, to the lead’s chagrin:

    > wonderboymusic will make a t-shirt for anyone who gets all 16 of those Cache tickets closed :)
    > sams: “Cache Master”?
    > wonderboymusic: Johnny Cache
    > jorbin: If you fix the Cache, you’ll get the Credit. That Checks out.
    > MarkJaquith: I’d put in a cache pun, but I don’t want to be sent to purgetory.
    > johnbillion: You would have to be a cache machine to fix all 16

     
  • Samuel Sidler 4:37 pm on April 28, 2014 Permalink | Log in to leave a Comment
    Tags:   

    Feature Plugin Chat tomorrow 

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

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

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

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

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

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

    See you tomorrow!

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

      I think WordPress lacks a feed reader.

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

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

      It’s just me working on it so far.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

      Hi,

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

      Slavi,
      http://Orbisius.com

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

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

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

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

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

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

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

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

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

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

      Current status: Idea and research stage.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

      Congrats Helen :)

  • Mike Schroder 10:29 am on March 13, 2014 Permalink
    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!

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

    Feature Plugin Chat on March 4 

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

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

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

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

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

    See you all at the chat!

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

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

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

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

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

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

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

      Not sure at the moment how I might assist.

    • 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
    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
    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. Read more about Live Widget Previews: Widget Management in the Customizer in WordPress 3.9.)

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

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