Make WordPress Core

Recent Updates Page 4 Toggle Comment Threads | Keyboard Shortcuts

  • Simon Wheatley 8:22 pm on July 9, 2015 Permalink |
    Tags: , ,   

    We’re going to be holding weekly multilingual discussions in the the core channel in WordPress.org Slack every Monday at 16:00 UTC, commencing the Monday 20th July.

    We’ll be continuing the discussions we began at the contributor day for WordCamp Europe (notes here), thinking through the feedback received since (thanks everyone!) and looking for considered and pragmatic ways forward.

    Anyone is welcome to join.

  • Andrew Ozz 1:31 am on July 9, 2015 Permalink |
    Tags: , , ,   

    Editor changes in WordPress 4.3 

    The editor initialization was updated. The main change is that the content for both Visual and Text editors is prepared/escaped the same. We used to run the content through the PHP wpautop() when the default editor was TinyMCE. This is no longer needed as we run the textarea content through the JavaScript wpautop() before initializing TinyMCE.

    In that terms wp_richedit_pre() and wp_htmledit_pre() were deprecated together with the richedit_pre and htmledit_pre filters. They were replaced by format_for_editor() and the format_for_editor filter. For more information see #32425.

    Another change is the complete removal of the code for the old Distraction Free Writing mode. This code was disabled and has been unused since WordPress 4.1. We left it in core so the authors of plugins that were using it would have plenty of time to update.

    If this is essential for some plugins, the files from WordPress 4.2 can be reused. For more information see #30949.

    If you are the author of a plugin that uses any of the deprecated functions or filters, please update it now. If your plugin uses wp_editor(), please test it in the latest beta.

    As always, feedback is very welcome.

    • Samuel Wood (Otto) 1:39 am on July 9, 2015 Permalink | Log in to Reply

      FYI to support team members. Any major editor JS change causes massive issues, because of caching. Bottom line, adding a version to the JS files, like we do, doesn’t solve the problem for people like CloudFlare users and people with overly crazy caching situations. Expect that these changes will cause big upticks of reports of breakage and silly demands to revert. CLEARING CACHES WILL FIX IT. The trick is finding out what kind of cache they use, and then clearing that.

      Just saying. This always happens for every major JS change.

      • Andrew Ozz 3:32 am on July 9, 2015 Permalink | Log in to Reply

        Yeah, this used to be a really big problem some time ago. Lately the situation has been improving. We have been updating TinyMCE and the custom plugins in each new WordPress release. There are still some reports of editor JS errors, but far less than few years ago.

    • Leo Caseiro 2:08 am on July 9, 2015 Permalink | Log in to Reply

      Hi @azaozz believe the PHP function is wpautop()

  • Ryan Boren 11:25 pm on July 8, 2015 Permalink |
    Tags: beta-testing-flow, , , list-tables, , , , toolbar   

    Today in the Nightly: Customize in the Toolbar, Passwords UI, List Tables on Phones, Dashicons 

    Development leading up to the first beta brought several visual changes. These are available right now in the nightly build. Switch a site to nightly builds and try them out.

    Customize in the toolbar

    To disambiguate between links to the Customizer and links to the Appearance screens from the front-end, Customize now has a top-level toolbar button rather than having links to it mixed with dashboard links in the site menu. This context mixing leads to disrupted user expectations as they navigate, as well as experiences that feel slower or actually are slower in some cases. See #32924.

    This means an additional top-level menu item, but the existing links to Widgets and Themes in the dropdown will now point to the admin, as the Dashboard and Menus links do. The advantage and goal for this change is to make it clear that you are about to enter the customizer. Deep links have not been added back in this go-round; this means that direct links to Header and Background are currently absent (with a very narrow exception related to old browsers). Those two deep links are still available in the admin menu under Appearance, which similarly mixes context but has not yet been addressed.

    More changes are coming to the toolbar. Peek at a possibility for more general improvements to the toolbar, being discussed in #32678.

    Phone friendly list tables

    List tables now scale down to phones. The column truncation strategy they used before didn’t scale down to small screens. A single column layout with disclosures is the new strategy. Some of our most important screens use list tables, notably Media and Posts. Truncated columns was number 5 on our top  5 impediments to flow on touch devices list.



    See #32395.

    For more screenshots, see these visual surveys of the list table screens.

    Toolbar interaction fixes for touch devices

    I’ve been wanting this one for a long time.  Toolbar interaction was number 3 on the top  5 impediments to flow on touch devices.




    See #29906. That ticket is a good read.  It has: Visual feedback and visual surveys. Punting a working fix to the next release so that a new, more future proof approach could be tried. Development of touch capability detection. Working around iOS. Development of testing checklists. Lots of iteration.

    Passwords UI

    The password set/change UI was updated with these improvements.

    • Generate the password for the user
    • More tightly integrate password strength meter
    • Warn on weak passwords

    See #32589 for more screenshots.

    Dashicons update

    Dashicons received a big update.

    New icons:

    • .dashicons-admin-customizer (f540)
    • .dashicons-admin-multisite (f541)
    • .dashicons-editor-table (f535)
    • .dashicons-filter (f536)
    • .dashicons-hidden (f530)
    • .dashicons-image-filter (f533)
    • .dashicons-image-rotate (f531)
    • .dashicons-layout (f538)
    • .dashicons-sticky (f537)
    • .dashicons-thumbs-down (f542)
    • .dashicons-thumbs-up (f529)
    • .dashicons-unlock (f528)
    • .dashicons-warning (f534)

    Updated icons:

    • .dashicons-plus (f132)
    • .dashicons-yes (f147)


    See #30902.

    Better styling for .form-invalid inputs

    See #32490.

    Responsive styling for my-sites.php

    My Sites now moves to a single column layout on narrow viewports. Here it is on an iPhone 6, an iPad, and a Macbook, as well as at full-width.

    Here’s what it looked liked before.


    See #31685 – Better responsive styling for my-sites.php

    Crosslinking Customizer Panels

    The graf in the Menus panel details about using the Customize Menu widget now links directly to the widgets panel.

    customize menus details

    See #32742.

    You might notice the misaligned question mark icon on that screenshot. #32733 is tracking that.

     Easy switching between production and nightly builds

    The beta tester plugin makes it easy to switch a site to nightly builds. Now switching back to the latest stable build is just as easy. It’s not the prettiest, but it is shown only to beta testers and will suffice until we finally refresh the Grand Unified Updater screen. For info on using the beta tester plugin to test with nightly builds, see the Beta Testing page of the core handbook.

    See #32613.


    Previously: Today in the Nightly: Site Icons, Text Editor in Press This

    • Thong Tran 12:06 am on July 9, 2015 Permalink | Log in to Reply

      Awesome updates. Btw, the ability to move a widget from one widget area to another has gone (in Customizer) in WP 4.3 beta 1, please bring it back.

      • Nick Halsey 3:50 am on July 9, 2015 Permalink | Log in to Reply

        To support a broader UX change made in #31336, it is no longer possible to drag & drop items between widget areas. However, the move-to-area functionality is still present along the reorder buttons when you enter the “reorder” mode, similar to the click-to-add functionality in the admin page.

    • Jon Brown 12:51 am on July 9, 2015 Permalink | Log in to Reply

      “Customize in the toolbar” getting it’s own top level menu is going to make me SOOOoooo happy you have no idea. Every time since 4.2.2 I hit that widgets link and get thrown into the customizer I scream curses at it my installs. Also just inspired me to write a plugin… to scratch another itch I’ve long had around that menu.

    • nikeo 8:48 am on July 9, 2015 Permalink | Log in to Reply

      Hi, thanks for this post.

      Funny : the customize button is something I’ve had to remove from my theme last year because there was “no real justification for elevating the Theme settings page to admin toolbar status.”
      See here : https://themes.trac.wordpress.org/ticket/18164#comment:5

      Well, I guess this is now 100% justified and of course I think this button is an excellent choice ! :)

    • Remkus de Vries 10:21 am on July 9, 2015 Permalink | Log in to Reply

      Love the move of giving the Customizer its own top level link. Love it.

  • Aaron Jorbin 9:09 pm on July 8, 2015 Permalink |  

    Dev Dependency updates for 4.3 have been completed today as off about 2 hours ago. If you encounter an error when running grunt due to a missing module, `npm install` or ‘npm update` should fix things right up for you.

  • Konstantin Obenland 5:20 pm on July 7, 2015 Permalink |
    Tags: ,   

    Dev Chat Agenda for July 8 

    Here’s the agenda for tomorrow’s Dev Chat in the #core channel on Slack.

    Time/Date: July 8 2015 20:00 UTC:

    1. Beta Notes
    2. Feature Updates
      1. Admin UI – @helen
      2. Menu Customizer – @westonruter
      3. Passwords – @markjaquith
      4. Site Icon – @obenland
    3. Feature Plugin Chat Next Week@samuelsidler
    4. Component Updates
    5. Open Floor

    Feature Leads: Let’s review last weeks goals and set new ones for next week.

  • Mel Choyce 8:35 pm on July 6, 2015 Permalink |
    Tags: , , ,   

    Comments are now turned off on pages by default 

    In [33041] and [33054] for #31168, we’ve turned comments off on new pages by default.

    I know many of you have done the “make a bunch of pages, fill them out, realize comments are turned on, go back into the admin, turn off comments” dance. Now when you make a page, you won’t have to manually turn off comments — it’ll match the expected behavior of being off by default.

    In addition to pages, this functionality has been extended to all custom post types. Post registrations that don’t explicitly add support for comments will now default to comments being off on new posts of that type (before, they defaulted to on). Up until now, post type support for comments has only affected admin UI; a developer could omit comment support on registration but still allow comments to be posted. This is a change in behavior, and we will be closely monitoring its effects during beta. Moving to explicit support will allow core behavior to be more predictable and robust in the future, but we will always consider real-world usage.

    In trunk, you’ll notice two new things: the get_default_comment_status() function, which accepts the post type and comment type as arguments (both optional), and within it a get_default_comment_status filter, which receives the status, post type, and comment type as arguments. If you’ve been directly checking options such as with get_option( 'default_comment_status' ), you will likely want to replace those calls with get_default_comment_status(). We recommend explicit registration of post type support for comments, but as an example of using the filter, you can restore current behavior using the following:

     * Filter whether comments are open for a given post type.
     * @param string $status       Default status for the given post type,
     *                             either 'open' or 'closed'.
     * @param string $post_type    Post type. Default is `post`.
     * @param string $comment_type Type of comment. Default is `comment`.
     * @return string (Maybe) filtered default status for the given post type.
    function wpdocs_open_comments_for_myposttype( $status, $post_type, $comment_type ) {
        if ( 'myposttype' !== $post_type ) {
            return $status;
        // You could be more specific here for different comment types if desired
        return 'open';
    add_filter( 'get_default_comment_status', 'wpdocs_open_comments_for_myposttype', 10, 3 );
    • Ihor Vorotnov 8:39 pm on July 6, 2015 Permalink | Log in to Reply

      Gods of Codes, thank you! Less junk in my mu-plugins now. And special thanks for CPTs – really good news these are :)

    • Frankie Jarrett 8:40 pm on July 6, 2015 Permalink | Log in to Reply

      Fantastic! Thanks to everyone involved in making this happen.

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

      Awesome! Now how about making SUNDAY the default first day of the week on install?

      • Frankie Jarrett 8:46 pm on July 6, 2015 Permalink | Log in to Reply

        Hey Dave, Monday will likely always be the default because that is the ISO standard. See https://en.wikipedia.org/wiki/Week#Week_numbering

        • Dave Navarro, Jr. 9:01 pm on July 6, 2015 Permalink | Log in to Reply

          So besides crusading for the Metric system, I need to be crusading to make American calendars start on Monday… When am I gonna find the time to finish my plugin documentation? 😉

          • Ihor Vorotnov 9:08 pm on July 6, 2015 Permalink | Log in to Reply

            If WP will ever switch to imperial system and make Sunday first, then the rest of the World (you know, that billions of folks outside of US) would have to crusade 😉 There’s no way to make everybody happy, so following ISO standards is the only way to go.

        • Tom Ryan 12:22 am on July 7, 2015 Permalink | Log in to Reply

          Isn’t this something that could be detected at install time, instead of forcing a one size fits all setting?

      • Ihor Vorotnov 9:04 pm on July 6, 2015 Permalink | Log in to Reply

        According to ISO 8601 Sunday is the 7th day of the week, that’s why we have weekENDs. WP is just obeying standards.

      • Andrew Nacin 2:43 am on July 8, 2015 Permalink | Log in to Reply

        Actually, I think we should indeed change this. But this will probably require us to bring the concept of a locale into core, beyond what we already do (date/time formats).

        I would very much like Sunday to be the default for a place (say, the United States) that uses Sunday as the default. This hasn’t been a major priority because it only affects the calendar widget. That said, there’s some traction to get locale work happening.

        Specific ticket: https://core.trac.wordpress.org/ticket/28344
        More generally, tickets like #18146 and #29783.

    • Shapeshifter 3 8:43 pm on July 6, 2015 Permalink | Log in to Reply

      Good Decision for users of WordPress as a CMS!!! Thank You!

    • Shawn Hooper 8:44 pm on July 6, 2015 Permalink | Log in to Reply

      So happy to see this getting implemented!

    • Tony Scott 8:46 pm on July 6, 2015 Permalink | Log in to Reply

      Great news!

    • Navneil Naicker 8:52 pm on July 6, 2015 Permalink | Log in to Reply

      Awesome, thank you guys.

    • Morten Rand-Hendriksen 8:55 pm on July 6, 2015 Permalink | Log in to Reply

      Small changes like these significant positive impact on the WordPress user experience. Great move.

    • webdevmattcrom 9:03 pm on July 6, 2015 Permalink | Log in to Reply

      And the world rejoiced! Thank you!

    • leemon 9:03 pm on July 6, 2015 Permalink | Log in to Reply

      At last!!!

    • nbrowe46 9:05 pm on July 6, 2015 Permalink | Log in to Reply

      Great stuff! This reduces the things I have to do on a fresh install :)

    • Marco Milesi 9:06 pm on July 6, 2015 Permalink | Log in to Reply

      In my experience i’ve used comments in ~1/10 website. I usually use WordPress as a CMS instead of a blogging platform. So i would prefer to have comments disabled for posts too…

      NVM, one step at a time. Thank You!

    • Grant Palin 9:13 pm on July 6, 2015 Permalink | Log in to Reply

      Excellent. This has been a nuisance before when creating custom post types. Explicit opt-in is the way to go for this sort of thing.

    • Sakin Shrestha 9:15 pm on July 6, 2015 Permalink | Log in to Reply

      Finally, it’s nice. Thanks :)

    • Ansel Taft 9:16 pm on July 6, 2015 Permalink | Log in to Reply

      I’m thrilled with this change! May I inquire about media attachments (aka images)? Are they comment-enabled by default? We’ve seen a rash of comment spam on a couple sites to media attachments and would be forced to name my third-born Mattilda if such a thing could come to be. Cheers!

      • Helen Hou-Sandi 9:29 pm on July 6, 2015 Permalink | Log in to Reply

        Attachments are explicitly registered with comment support, yes. I’m not personally opposed to turning them off, though there are definitely sites that use comments for attachments – worth discussing. It is at least relatively trivial to turn comments off for attachments now, via remove_post_type_support() or the aforementioned filter.

        • Morten Rand-Hendriksen 9:31 pm on July 6, 2015 Permalink | Log in to Reply

          I would definitely leave attachment comments on by default because unlike all other post types there is no clear way for the user to do this on their own. If a user decides to direct a visitor to the Attachment page, there is a good chance that same user is looking to enable the comments section on that page.

          • Ansel Taft 10:14 pm on July 6, 2015 Permalink | Log in to Reply

            Morten, we land on the other side of the fence. We have yet to build a site where we would want/need comments enabled on attachments by default. We use media attachments on posts and comments are enabled on those which is perfect for our needs.

            • Helen Hou-Sandi 12:01 am on July 7, 2015 Permalink

              We don’t expose this in any of the Backbone-driven parts, no. I’ve used attachment comments on some sites (photo commenting vs. post commenting, much like Facebook has), and hate the spam problem on others. The spam can come even if you don’t have a comment form, which is also frustrating. I’m not sure we can really turn it off by default, but again, at least it’s easier to turn them off now. Which I should go do for some sites right now. :)

            • AskKim 6:50 am on July 7, 2015 Permalink

              I have the same experience that Ansel has. Nothing we’ve developed for ourself or clients has used those pages except a singular site that could have done with a custom enabling code snippet.

              I definitely think media comments should be off by default.

    • Tom Ryan 12:21 am on July 7, 2015 Permalink | Log in to Reply

      Excellent! This is one of about 20-50 relatively small tweaks which are necessary to make WordPress more delightful for those users who are not developers. Thank you!

    • Jon Brown 12:24 am on July 7, 2015 Permalink | Log in to Reply

      Sooo many comments about comments… lmao… a most welcome change. Thank you.

    • Piet Bos 2:10 am on July 7, 2015 Permalink | Log in to Reply

      At long last something good to come to 4.3! Thank you!

    • Knut Sparhell 2:57 am on July 7, 2015 Permalink | Log in to Reply


    • intriguingnw 12:29 pm on July 7, 2015 Permalink | Log in to Reply

      Delighted, I am sure there will be more to delight us in 4.3, I hope so ! Positive thinking. I agree with Tom Ryan above! THANKS

    • Nashwan Doaqan 12:58 pm on July 7, 2015 Permalink | Log in to Reply

      Fantastic! It will save our time!

      The changeset [33041] had introduced a dynamic filter name `get_{$post_type}_default_comment_status` ! and the code snippet is using a .literate version ! Which one should we use?!

    • Seth Alling 3:00 pm on July 7, 2015 Permalink | Log in to Reply

      This is great news. It makes my plugin (No Page Comment) pretty much irrelevant (I’ll still keep it as it has an interface for the everyday user to use on custom post types), but it’s been something I’ve felt should be in core for a long time, so thanks!

    • TechDaddyK 6:34 pm on July 7, 2015 Permalink | Log in to Reply

      Thank you for making this change! I build a lot of sites that don’t have traditional blogs, etc. so I spend a lot of time building Pages. It has become a habit to turn off commenting on Pages, but I’ve forgotten many times and had to correct dozens (or even hundreds) of Pages once I remembered to do so.

    • Michael Beil 7:26 pm on July 7, 2015 Permalink | Log in to Reply

      This is wonderful.

    • Ahmad Awais 7:47 pm on July 7, 2015 Permalink | Log in to Reply

      Most needed change ever. I really had a very few pages where I actually needed to use comments.

  • Aaron Jorbin 7:34 pm on July 6, 2015 Permalink |
    Tags: , , ,   

    Singular.php: New Theme Template in WordPress 4.3 

    A new theme template has been added to the theme hierarchy as of r32846: singular.php.  This template follows the rules of is_singular and is used for a single post, irregardless of post type.  It comes in the hierarchy after single.php, page.php, and the variations of each. Themes that used the same code for both of those files (or included one in the other) can now simplify down to the one template.

  • Konstantin Obenland 3:52 pm on July 6, 2015 Permalink |
    Tags: ,   

    This week in 4.3: July 6 – 12 

    This is the jump-start post for the ninth week of the WordPress 4.3 release cycle.

    Beta2 will land on Wednesday. Our target until then is to get the ticket count in the 4.3 milestone down to 90.

    Priority Tickets this week:

    Core Meetings this week:

    4.3 Feature Chats this week:

  • Aaron Jorbin 2:22 am on July 2, 2015 Permalink |
    Tags: , , php7   

    Deprecating PHP4 style constructors in WordPress 4.3 

    PHP7 is slated for release later this year. One of the changes is that PHP4 style constructors are deprecated. In order to prepare WordPress to support PHP7, these constructors have been deprecated in WordPress core. This is a quick guide to all you need to know about this change.

    What are PHP4 style constructors?

    Prior to the introduction of __construct in PHP5, classes were constructed by using a method with the same name as the class.  For example:

    class Yo {
        function yo(){
            // code that constructs our class

    PHP5 added __construct, but it also continued to allow the PHP4 style constructors, but with some evolving (and occasionally confusing) rules related to the presence of __construct, the ordering of the methods, and if a class is within a namespace.

    What is WordPress Doing

    r32990 introduced a change so that all classes use the PHP5 style constructors, while still retaining the PHP4 style constructors for backwards compatibility. For WordPress classes (not external libraries), a deprecated_constructor warning that follows the same rules as deprecated_function will also be displayed. This is designed to help ease the transition to PHP7.

    What should you do?

    If you are sub classing a WordPress class and calling the PHP4 constructor, you should update your code to use parent::__construct instead. You should also audit your own code to make sure it is using PHP5 style constructors.

    PHP7 is promising some very impressive performance improvements, and I’m excited to see it get closer and closer to release.   If you have any questions on this change, please comment below.

    Update: A list of affected plugins that call WP_Widget::WP_Widget() or parent::WP_Widget() is here.

    • nicholas_io 2:41 am on July 2, 2015 Permalink | Log in to Reply

      That’s great! I’m really excited about PHP 7, and I think we need to move forward with the WordPress minimum requirements (For PHP, at least PHP 5.4).

      • Aaron Jorbin 12:19 pm on July 2, 2015 Permalink | Log in to Reply

        If we move the requirements now, then 15% of our users will be left behind. That’s 3.6% of the internet, more than the market share of Drupal, Magento, and Squarespace combined. As much as I would love to be able to use some of the great features added in more recent versions of PHP, it doesn’t make sense to discard that many users.

        • Zach Tirrell 1:56 pm on July 2, 2015 Permalink | Log in to Reply

          This seems like a false argument. WordPress’ dominant position would encourage a large chunk of that group to move forward. The ones that don’t could continue running an older version of WordPress. On that point, are all of the 15% you cited running the latest WordPress?

          Not looking for a big argument, but WordPress has great power and therefore great responsibility to lead this segment of the internet forward.

        • nicholas_io 3:07 am on July 3, 2015 Permalink | Log in to Reply

          I think that we can’t wait for 3.6% of the internet update their PHP version. Maybe we could maintain the security releases for the latest WordPress version that supports legacy PHP and move forwards with new features on the next releases.

        • MarkRH 11:47 pm on July 9, 2015 Permalink | Log in to Reply

          My webhost just now upgraded server from PHP 5.3.28 to PHP 5.4.41. Heh..

    • Jon Brown 4:16 am on July 2, 2015 Permalink | Log in to Reply

      Thanks Aaron! Seeing this sort of far future planning and notices delights me.

      Is there really any reason keep the PHP4 fallbacks around? in core, or otherwise?

      • Aaron Jorbin 12:10 pm on July 2, 2015 Permalink | Log in to Reply

        In core, they are there for backwards comparability. I haven’t had time to grep the plugin repo yet, but I wouldn’t be surprised if many plugins are calling `parent::WP_Widget` or something similar.

        Unless you think your class is being subclassed and want to keep the backwards compatibility, I don’t think you need to keep the PHP4 fallbacks around in your own code.

    • prionkor 5:40 am on July 2, 2015 Permalink | Log in to Reply

      +1 for the progressiveness

    • francescolaffi 7:45 am on July 2, 2015 Permalink | Log in to Reply

      just a hint if someone has to update a codebase: php code sniffer has a sniff for that

    • Slava UA 8:11 am on July 2, 2015 Permalink | Log in to Reply

      WordPress won’t care about PHP7 for 5-7 years, so it doesn’t matter.

      • Slava UA 8:19 am on July 2, 2015 Permalink | Log in to Reply

        To be clear: WordPress minimum requirement is 5.2.4, which was released on August 30, 2007. That’s almost 8 year ago. Recommended requirements are 5.4 (security releases are only for 2 month from now), which was released 3+ years ago. Just the facts.
        So WordPress won’t use all cool 7.0 things for quite a lot of time, for years we will be stuck in PHP5.

      • chriscct7 10:34 pm on July 4, 2015 Permalink | Log in to Reply

        It does because starting in 4.3, using a PHP 4 style constructor for widgets will throw a deprecation notice, regardless of PHP version installed

    • Mustafa Uysal 8:41 am on July 2, 2015 Permalink | Log in to Reply

      Finally! 👍

    • Subharanjan 9:21 am on July 2, 2015 Permalink | Log in to Reply

      Glad to know about this future planning !! (y)

    • Stephane Daury (stephdau) 1:19 pm on July 2, 2015 Permalink | Log in to Reply


    • Nashwan Doaqan 7:17 pm on July 3, 2015 Permalink | Log in to Reply

      Nice! . I am really surprised of how many plugins are affected but it looks like many of them haven’t updated in over 2 years!

    • chriscct7 10:35 pm on July 4, 2015 Permalink | Log in to Reply

      Updated the list to include plugins using ${object}->WP_Widget().

  • Ryan Boren 10:56 pm on June 30, 2015 Permalink |
    Tags: , , , image-editor, , , site-icons, today-in-the-nightly   

    Today in the Nightly: Site Icons, Text editor in Press This 

    Here are a few cool things that recently landed in trunk. They are available right now in the nightly build. Install the nightly, and try them out.

    Site Icons

    We’ve wanted site icons in core for a long time. #16434 was opened four years ago and will be resolved as fixed for 4.3.


    Our crop controls are not easy to use on my iPhone 6+. The images overflow the right side of the screen. Horizontally and vertically scrolling an image bigger than the screen while working a rubber band select that resets when the image is tapped is not pleasant.

    Provide feedback on #16434 or on this post.

    See these visual records for more screenshots and flow storyboards.

    Text editor in Press This

    Press This now has a Text editor for editing HTML, just like the standard editor in post-new.php.


    Provide feedback on #32706, in #core-pressthis, or on this post.

     Padding for image settings

    The Image Crop and Thumbnail Settings boxes received a little bottom padding.

    And so that we are always aware of what our mobile experience looks like, here are those settings boxes on an iPhone 6+.

    When you see a sidebar obscuring content on a phone, you can be pretty sure you’re witnessing lingering desktop bias. These screens were designed for desktops where you have room to use  sidebars. You can’t make a screen responsive and call it ready for a phone. The image flow effort is working on this.

    Provide feedback on #31845 or on this post.

    Manage in the Customizer

    Appearance > Menus received a “Manage in the Customizer” button to match Appearance > Widgets.

    Screen Shot 2015-06-30 at 3.16.57 PM

    Next, fix up mobile.


    Provide feedback on #32808 or on this post.


    Previously: Today in the Nightly: Inline link toolbar and Press This split button

    • Emil Uzelac 11:05 pm on June 30, 2015 Permalink | Log in to Reply

      Just awesome!

    • Ryan Boren 11:45 pm on June 30, 2015 Permalink | Log in to Reply

      To create these posts, I work my way through the latest commits looking for changes to visuals. From the changesets, I visit the tickets. If the tickets don’t have before and after screenshots for both a desktop and a phone, I test the changes on a desktop and a phone and take screenshots. I upload those screenshots to the ticket. I comment on the ticket with any bugs I find in the process. I often find something, especially on phones. If I don’t have time to test and screenshot, I tag the ticket with needs-screenshots so I can get back to it later.

      Now that I have tickets with screenshots. I collect those screenshots and publish them as “Today in the Nightly” using the tool we’re all making together, WordPress. I often find bugs that way, too. Triage, recursive dogfooding, visual archiving, visual awareness, and a useful post to show for it. Recruiting drive: This is a great way to contribute. Help us with flow patrol, as we call it. :-)

    • Andre 4:27 am on July 2, 2015 Permalink | Log in to Reply

      I am just now playing with the beta 4.3, but regarding the site icon…I’m sure many will be extremely happy about that feature being part of the core. The only thing that should be given consideration is the labeling of it. I think it might confuse many end-users who may wonder what is a site icon when most are familiar with the term “favicon”, which as I understand, is the correct name for it. Just something to think about.

compose new post
next post/next comment
previous post/previous comment
show/hide comments
go to top
go to login
show/hide help
shift + esc
Skip to toolbar