WordPress.org

Make WordPress Core

Updates from January, 2016 Toggle Comment Threads | Keyboard Shortcuts

  • Eric Binnion 6:50 pm on January 27, 2016 Permalink |
    Tags: ,   

    Week in Core, Jan. 19-26 2016 

    Welcome back to the latest issue of Week in Core, covering changes from January 19th – January 26th, 2016, changesets [36351-36406]. Here are the highlights:

    • 55 commits
    • 44 contributors with props
    • 99 tickets created
    • 10 tickets reopened
    • 86 tickets closed

    Ticket numbers based on trac timeline for the period above.

    Note: If you want to help write the next WordPress Core Weekly summary, check out the schedule over at make/docs and get in touch in the #core-weekly-update Slack channel.

    Code Updates

    Accessibility

    • Improve the focus style on the Credits screen. Leads and contributing developers will now look nicer when focused. Also, combines adjacent image and text links for the same resource thus simplifying markup and reducing noise for screen reader users. [36406] #34953
    • Accessibility: Improve the color contrast ratio replacing the residual occurrences of the #777 gray. Uses the existing #72777c on white backgrounds and the new #555d66 “dark medium gray” on darker backgrounds. [36396] #35605
    • Fix the color contrast ratio in the login screen. [36395] #31548
    • Remove title attributes from the Menus screen. [36379] #35374

    Cache API

    • Pass $clean_taxonomy param to ‘clean_term_cache’ action. [36399] #35611

    Comments

    • Fire an action after a comment is removed from object cache. When a comment is removed from the object cache, the clean_comment_cache action is now fired. This provides plugin and theme developers a chance to perform secondary cache invalidation as needed. [36405] #35610
    • In comments list table, $post_id should default to false rather than 0. [36387] #35090
    • Allow comment query results to be limited to comments with comment_post_ID = 0. [36381] #35090
    • Ignore hierarchy in pagination calculation when comment threading is disabled. Merges [36275] to the 4.4 branch. [36362] #8071, #35419
    • Respect all post-related filters in WP_Comment_Query. Merges [36326] to the 4.4 branch. Fixes #35478. [36361] #35478
    • Use the post-filter WHERE clause when querying for comment descendants. Merges [36277] to the 4.4 branch. Fixes #35192. [36357] #35192
    • Always respect $comments array passed to wp_list_comments(). Merges [36276] to the 4.4 branch. [36356] #35175, #35356
    • In comments_template(), don’t run hierarchical queries if comment threading is disabled. Merges [36226] to the 4.4 branch. [36353] #35378

    Customizer

    • Use “(Untitled)” as site title if blogname is empty. Fixes #35579. [36388] #35579
    • Add shift-click on nav menu items in preview to focus on corresponding nav menu item controls in pane. [36383] #32681
    • Hide help toggle button in panel when no description is supplied. This aligns with the .customize-panel-description element which is also excluded if there is no description. [36374] #35540
    • Fix click.preview event handler for jump links and shift+clicks in preview. Fixes #26005. [36371] #32681, #26005
    • Prevent erroneously directing user to login screen when closing. Fixes #35355. [36363] #32637, #35355
    • Respect custom pagination params when using wp_list_comments() in a query loop. Merges [36324] to the 4.4 branch. [36360] #35402

    Documentation

    • Correct return value for is_allowed_http_origin(). [36398] #35607
    • Clarify that mu-plugins can’t be “active” in docs. [36397]
    • Fix parameter documentation ordering in the hook docs for the register_taxonomy_args filter. [36391] #32246

    Editor

    • TinyMCE: add inline link dialog. First run. Links the advanced button to the “old” dialog for now. [36384] #33301
    • TinyMCE: remove the srcset and sizes attributes (if any) after replacing or editing an image. [36376] #35434

    Emoji

    • Work around a mod_security rule which prevents pages with 4 or more instances of String.fromCharCode( from being served. [36359] #35412

    I18n

    • Add the text domain to translate_nooped_plural() calls as well. [36390] #34126
    • Add a test for the add-textdomain.php script. [36389]

    Media

    • In _wp_handle_upload(), move ending brace to a new line. [36373] #35565
    • When reusing the initial values from the global MediaElement config object, the config object should first be cloned. Objects in JS are references that will retain any changes. Fixes #34152. [36364] #34152

    Multisite

    Plugins

    • Pass data consistently on plugin, network plugin, and network theme screens. [36394] #35335

    Query

    • Respect ‘suppress_filters’ when filtering search-related SQL. [36404] #35594
    • Introduce $comment_status and $ping_status params for WP_Query. [36403] #35601
    • Avoid invalid SQL when building ORDER BY clause using long search strings. Merges [36251] to the 4.4 branch. Fixes #35361. [36354] #35361

    Quick/Bulk Edit

    • Remove a no more used jQuery loop for unsupported post formats. See #24096. [36375] #23426, #24096, #35564
    • On the Taxonomies screens, prevent a page reload when pressing Enter on a focused field. Merges [36260 to the 4.4 branch. [36355] #35401

    Posts, Post Types

    • Allow is_post_type_viewable() to accept a post type name. Previously, it accepted only a post type object. [36402] #35609
    • Add tests for is_post_type_viewable(). [36401] #35609

    Taxonomy

    • Populate term cache with proper clone of term objects. Merges [36323] to the 4.4 branch. [36358] #35462

    Themes

    • Themes: Enhance filtering options for allowed themes on a network. [36366] #28436

    TinyMCE

    • Update to 4.3.3. Update the QUnit tests and revert back to testing the non-minified files in /src. [36352] #35539

    Upgrade/Install

    • Switch the locking mechanism to using static methods so that it can be accessed from other upgrade-classes. [36370] #34878

    Widgets

    • Show the “Clear Inactive Widgets” button only after the sidebar with inactive widgets. Merges [36326] to the 4.4 branch. [36369] #35447

    Props

    Thanks to @5um17, @afercia, @azaozz, @berengerzyla, @birgire, @boonebgorges, @chandrapatel, @chriscct7, @danielbachhuber, @dd32, @dmsnell, @dotancohen, @drebbitsweb, @DrewAPicture, @ericlewis, @Fab1en, @firebird75, @Frozzare, @georgestephanis, @iseulde, @ivankristianto, @jeremyfelt, @jmdodd, @johnjamesjacoby, @johnnypea, @kraftbj, @lamosty, @luciole135, @MattGeri, @michalzuber, @mrahmadawais, @obenland, @ocean90, @pauldewouters, @rob, @salvoaranzulla, @scarinessreported, @SergeyBiryukov, @spacedmonkey, @tahteche, @walbo, @westi, @westonruter, and @wonderboymusic for their contributions!

     
  • Adam Silverstein 8:14 am on January 27, 2016 Permalink |
    Tags:   

    Feature Plugin chat notes for Jan 26 

    Agenda

    • Review the feature plugins for status updates from leads
    • Open floor for feature plugin proposal

    Feature Plugin Updates

    • Background Image Cropper: @celloexpressions asked for feedback for the Background Image Cropper. Current thinking is this is better explored as a standard enhancement for core. See #32403.
    • Customizer: @westonruter left status on the blog post for the Customize Pane Resizer, Customize Device preview (along with @celloexpressions), Selective Refresh, and Transactions. Please comment there if you’re interested in helping out where needed (especially requested for the Pane Resizer).
    • Fields API: @sc0ttkclark updated: term add/edit is in: props @technosailor. Team has been working on simplifying the code required for each screen implementing the Fields API. Scott posted an update on make/core and reports getting lots of feedback (especially from @helen, @drew, @technosailor & @celloexpressions)
    • Shiny Updates:  @obenland updated – Lots of progress in the last week. @ipstenu helped tremendously in getting it multisite compliant. Team decided to not pursue shiny activations/deactivations for a whole set of reasons, mostly around redirects on subsequent page loads, and fatal error protection.
      Currently working on enabling theme updates without having to open the modal, and revamping update-core.php.  An update will be posted to the make/core blog soon. The team needs more feedback and testing! Testers can get the current plugin from the wordpress.org repository.
    • WP-API: @danielbachhuber updated – released beta 11 yesterday. The team is meeting in person (minus @rachelbaker) this week at A Day of REST. Summary: in the home stretch, but there’s a ton more work to do. Friday’s contributor day (at the Day of REST) will hopefully get other people diving in and contributing to the final push.

    Open Floor

    The full logs are available on Slack.

     
    • jrf 10:52 am on January 27, 2016 Permalink | Log in to Reply

      I’d love to continue the discussion on Plugin Dependency management within WP.
      We’d very much would like to invite everyone to give their opinion on the direction we’re thinking of taking though this survey: http://goo.gl/forms/Fq1gbY9vCW

      We’d really appreciate getting as many opinions as possible about this. Thanks!

      • Felix Arntz 11:50 am on January 27, 2016 Permalink | Log in to Reply

        I just took the survey, I have a few comments on the approach.

        I certainly like that multisite will be supported, this is definitely a requirement anyway. 🙂

        About the dependency management: although I personally would prefer a JSON file, I think the theme/plugin header way is more the WordPress way, and a lot easier. People new to WordPress and even to development should be encouraged to start creating plugins/themes – external libraries/library plugins make this a lot easier, but I’m afraid a JSON file is too complex. Maybe both methods should be supported: while only the JSON approach would support the full functionality of dependency management, the file header would still allow to at least require plugins listed on wordpress.org with a minimal version number (there’s not really room in there to do more complex things). If someone needs external plugins or something like that, that should only be possible using JSON.

        The other thing is, in my opinion the recommendations feature should not be part of the feature plugin. Standard dependency management does not handle recommendations either, and I think this goes into kind of an advertising direction which I wouldn’t like to have in WordPress Core.

        I’m looking forward to this project and I’m happy you make these efforts to create a feature plugin. I think the full power of this feature however could only be leveraged if the wordpress.org plugins API would be adjusted as well to contain dependency information as this would allow notifications prior to installing which I think is even more elegant than notifications before activating (also due to the problems that this would bring on multisite). Anyway, first things first! 🙂

    • Ryan Boren 3:33 pm on January 27, 2016 Permalink | Log in to Reply

      Beta testing is much easier when feature plugins are kept up-to-date in the plugin repo. This allows using the built-in WP update mechanism to follow development. Our beta testing onboarding, such as it is, relies on feature plugins being updated regularly.

      A survey of https://wordpress.org/plugins/browse/beta/ and https://make.wordpress.org/core/features-as-plugins/:

      • Background Image Cropper: Last updated one month ago in the plugin repo. The features as plugins entry is bare.
      • Customize pane resizer: This is listed in neither browse/beta nor features-as-plugins.
      • Customize Preview Responsiveness (aka Customize Device Preview): The Customizer UI Experiments plugin was last updated two months ago. This is called three different things.
      • Customize Partial/Selective refresh: The plugin hasn’t been updated for 6 months.
      • Customizer transactions: I don’t see this in browse/beta or features-as-plugins.
      • Fields API: This is not listed in browse/beta. Does it even exist in the plugin directory?
      • Shiny Updates: This is in browse/beta and kept up-to-date. As such, I’ve been testing it.
      • WP API: This is in browse/beta and kept up-to-date. It is pretty much the only feature plugin to post on make/core regularly and do calls for testing.

      Court beta audiences. Update plugins in the plugin dir, preferably nightly. Keep features-as-plugins up-to-date. Publish calls for testing to make/core. Here’s a call for testing template and checklist. http://simp.ly/publish/XrHJDL

    • Ryan Boren 8:04 pm on January 27, 2016 Permalink | Log in to Reply

      If you have the beta tester plugin, feature plugins can be installed from Plugins > Add New > Beta Testing. Details here: https://make.wordpress.org/core/handbook/testing/beta/

  • Eric Binnion 3:20 pm on January 20, 2016 Permalink |
    Tags: ,   

    Week in Core, Jan. 12-19 2016 

    Welcome back to the latest issue of Week in Core, covering changes from January 12th – January 19th, 2016, changesets [36269][36350]. Here are the highlights:

    • 81 commits
    • 38 contributors with props
    • 127 tickets created
    • 19 tickets reopened
    • 100 tickets closed

    Ticket numbers based on trac timeline for the period above.

    Note: If you want to help write the next WordPress Core Weekly summary, check out the schedule over at make/docs and get in touch in the #core-weekly-update Slack channel.

    Code Updates

    Accessibility

    • After [36333] correctly use esc_attr() instead of esc_attr__(). [36334] #35313
    • Remove title attributes from the Posts list table. [36333] #35313, Media Library list table. [36331] #35136 & the Comments screen. [36298] #35304
    • Improve focus handling on the Taxonomies Quick Edit. Moves focus back to a proper place when saving or closing the form. [36304] #35460
    • Improve focus handling and audible feedback on the Posts Quick-Bulk Edit. Avoids a focus loss when saving or closing the form moving focus back to a proper place. Uses wp.a11y.speak() to dispatch successful edits and error messages to screen readers. [36303] #34756

    Administration

    • CSS: Reference the original location of the CSS rule being overridden. [36342] #35229
    • CSS: Stop using wp-admin.min.css and instead queue the individual stylesheets up through load-styles.php. We still generate the wp-admin.* files for compabitility purposes, however they only include the @import() lines. [36341] #35229
    • List Tables: Use the $GLOBALS array when unsetting the global post and comment in WP_Comments_List_Table::single_row(). [36339] #35506
    • Allow searching for 0 throughout the admin. [36302] #31025
    • Add a “Drag boxes here” message to empty dashboard meta boxes so it’s clear to users that it’s possible to drag meta boxes into empty spaces. [36295] #26399
    • Support searching for '0' in WP_Query. [36278] #31025

    Build/Test Tools

    • Build/Test Tools: Move PHP factory classes into their own files. [36347] #35492\
    • Build Tools: Append the timestamp to $wp_version instead of only the current date. [36315] #28722

    Canonical

    • After [36280] remove the unit tests which are no longer supported for 4.4. This also removes the is_feed() code to avoid confusion – only pages & embeds will be redirected. [36281] #35344
    • Restore the is_404() check in wp_old_slug_redirect() which was removed in [34659]. This reverts part of [34659] due to excessive canonical problems it’s caused in 4.4.x. [36280] #35344, #21602

    Comments

    • Ignore false values of ‘search’ in WP_Comment_Query. [36345] #35513
    • Remove unused $default_comments_page variable in get_comment_link(). [36343] #34073, #35511
    • Correct description of comment_author property in WP_Comment class. The comment_author property is the comment author’s name, not an ID. [36332] #35464
    • Respect all post-related filters in WP_Comment_Query. [36326] #35478
    • Use TEXT column type in fallback for wp_get_comment_column_max_length(). [36325] #10377
    • Respect custom pagination params when using wp_list_comments() in a query loop. [36324] #35402
    • Remove unneeded $req variable in comments_template(). [36322] #35473
    • Add a new pre_wp_update_comment_count_now filter. [36318] #35060
    • Use assertEqualSets() in comment_author test. The previous assertion was too specific, resulting in race conditions. [36279] #35377
    • Use the post-filter WHERE clause when querying for comment descendants. [36277] #35192
    • Always respect $comments array passed to wp_list_comments(). [36276] #35175, #35356
    • Ignore hierarchy in pagination calculation when comment threading is disabled. [36275] #8071, #35419
    • Restrict the maximum characters for input fields within the comments template. [36272] #10377

    Customizer

    Embeds

    • Allow embedding static front pages and pages having a child page with an embed slug. This makes embed a special slug that can’t be used for new pages/posts. When https://example.com/foo/embed/ is an existing page, embeds fall back to https://example.com/foo/?embed=true. Adds unit tests. [36307] #34971

    Filesystem API

    Formatting

    • Emoji: adjust $wpsmiliestrans. Swap simple-smile.png with SLIGHTLY SMILING FACE and frownie.png with SLIGHTLY FROWNING FACE [36336] #31710

    HTTP API

    • Add response status code aliases on WP_Http for convenience. These provide a more descriptive way to set response codes elsewhere, so it’s readable and less chance for the wrong response code to be used such as 401 vs 403. [36294] #35426
    • Add missing HTTP status code descriptions (specifically 308 and 421.) [36274]
    • Add support for 451 http status code (Unavailable For Legal Reasons.) Though this is technically still in the proposal stage, there is support from the core team and precedent in #16914 [36273] #16914, #35333

    I18n

    • Introduce tests for WP_Locale. [36292] #34688
    • Correct an argument description and return value for wp_dropdown_languages(). [36290] #35294

    JavaScript

    • In wp.Backbone.Subviews, extract subviews with proper Underscore.js functions. [36305] #34350
    • jQuery: Replace use of deprecated methods and events. [36288], [36287], and [36286] for #35380,
    • External Libraries: Update jQuery to 1.12.0 and jQuery Migrate to 1.3.0. [36285] #35380

    Media

    • Update some attach/detach strings in the columns view. [36328] #33237

    Multisite

    • Add initial tests for the allowed_themes filter. [36350] #28436

    Network and Sites

    • Clarify the docblock for get_current_site() so it’s clear that it returns the current network object, not anything to do with the current site. As a further exercise, the reader is invited to fix the nomenclature surrounding blogs, sites, and networks in WordPress. [36293] #35414

    Performance

    • Share post fixture in WP_Comment_Query tests. [36346] #30017
    • Script Loader: Add Etag: $wp_version header in load-scripts.php and load-styles.php. This improves performance since browsers won’t re-download the scripts and styles when there was no change in $wp_version. [36312] #28722

    Plugins

    • Prevent a warning when searching in the plugins list table. [36301] #35461
    • Make sure the ‘Beta testing’ tab is first in the plugin installer. This makes feature plugins more discoverable for people running development builds. [36297] #29631
    • In _get_plugin_data_markup_translate() remove the fallback to the “default” textdomain for Akismet. Akismet has its own language files since WordPress 3.9. [36283] #35436

    Posts, Post Types

    Taxonomy

    • Don’t double-escape the ‘name’ param in get_terms(). [36348] #35493
    • Populate term cache with proper clone of term objects. [36323] #35462
    • Fix unit tests after [36308]. [36309] #34988
    • Introduce wp-admin/term.php for editing single terms. [36308] #34988
    • Correct the accetped types for the taxonomy element in the arguments passed to wp_dropdown_categories(). [36289] #35446

    Themes

    • Show template loading error to users with switch_themes cap. [36344] #21931
    • Only users with proper capability should see theme errors. [36338] #21931
    • Show an error message to logged-in users if a template file isn’t loaded. [36335] #21931
    • Clear floated theme cards on Themes page. Also maintains visual separation for Broken Themes table on searches that return no results. [36270] #26646

    Upgrade/Install

    • Add a locking mechanism to avoid two concurrent updates of WordPress occuring. [36349] #34878

    Users

    • Always return $current_user in wp_get_current_user(), never a boolean. [36313] #19615
    • Deprecate the get_currentuserinfo() pluggable function. [36311] #19615
    • Decode special characters in password and email change notification emails. [36306] #35283

    Props

    Thanks to @5um17, @adamsilverstein, @afercia, @andizer, @berengerzyla, @boonebgorges, @chriscct7, @danielbachhuber, @dd32, @DrewAPicture, @ericlewis, @firebird75, @grapplerulrich, @iseulde, @ivankristianto, @jeremyfelt, @jmdodd, @joehoyle, @johnbillion, @jrf, @kraftbj, @Latz, @meitar, @MikeHansenMe, @obenland, @ocean90, @peterwilsoncc, @rachelbaker, @realloc, @rmccue, @scribu, @sebastianpisula, @sergejmueller, @SergeyBiryukov, @swissspidy, @valendesigns, @westonruter, and @xavortm for their contributions this week!

     
  • Helen Hou-Sandi 7:56 pm on December 9, 2015 Permalink |
    Tags:   

    Welcome the 4.5 class of committers! 

    As announced in the State of the Word this year at WordCamp US by @matt, there are seven new committers to introduce.

    Many of you have seen Michael Arestad‘s (@michaelarestad) design and front-end development contributions over the last couple of years, notably with the redesign of Press This in WordPress 4.2. His numerous, high quality contributions are a welcome addition to core. I personally am looking forward to his work on markup and styling, having relied heavily on his judgment for quite some time now.

    WordPress 4.4 adds a new embed feature to WordPress, making it an oEmbed provider for the first time. Work on this new feature was done in a large part by Pascal Birchler (@swissspidy), who has been doing great work for the past few releases. Pascal’s clear communication and thorough support of the flow mindset are things we can all be inspired by.

    Rachel Baker (@rachelbaker) is the co-lead of the REST API, a Comments component maintainer, and a major contributor to WordPress 4.4. Her work has made it possible for sites around the world to utilize the REST API, making WordPress a great application platform. Look for more of these contributions as the REST API iterates within core.

    Likewise, Joe Hoyle (@joehoyle) is a major contributor to the REST API. As we prepare to commit the REST API endpoints in an upcoming WordPress release, there will be more and more to come from both him and Rachel.

    As a Media component maintainer and a long-time contributor across many components and features, Mike Schroder (@mikeschroder) helped shepherd the responsive images feature plugin into core for WordPress 4.4. He was also a backup release lead for WordPress 3.9.

    Throughout the WordPress admin interface, everywhere you look you’ll see the work of Mel Choyce (@melchoyce). Her design and experience contributions are long-standing and have benefited the entire ecosystem. As one of the maintainers of the Dashicons project, the icons you interact with daily are a big part of her contributions, as well as themes available in the WordPress.org Theme Directory.

    Eric Andrew Lewis (@ericlewis) has been contributing in various forms for many years, exploring lesser-known areas, documenting them, and challenging assumptions. Most recently, you may have seen his work as a Media component maintainer or with the shiny updates feature in WordPress 4.2.

    Additionally, Ella Van Dorpe (@iseulde), Konstantin Obenland (@obenland), Weston Ruter (@westonruter), Tammie Lister (@karmatosed), Andrea Fercia, (@afercia) and Ryan McCue (@rmccue [that’s one M, two C’s]) have all had their guest commit renewed.

    Please join me in welcoming this great set of new committers!

     
  • Konstantin Obenland 5:49 pm on October 20, 2015 Permalink |
    Tags: , ,   

    Document title in 4.4 

    WordPress 4.1 introduced a way for themes to support a new way of rendering the document title, letting Core handle its generation and output. The next step followed just recently (#31078), deprecating wp_title() and replacing it with a more comprehensive way to generate titles.

    UPDATE 12 November – wp_title has been reinstated until alternative usages have been identified and a path forward for them defined.

    Plugin authors can now check for theme support and have a few new filters available that will allow them to change or replace the title in a reliable way:

    • 'pre_get_document_title' short-circuits wp_get_document_title() if it returns anything other than an empty value.
    • 'document_title_separator' filters the separator between title parts.
    • 'document_title_parts' filters the parts that make up the document title, passed in an associative array.

    This latest change makes the new API (almost) feature complete and theme authors are discouraged from using wp_title() in the future. If it was decided to add a UI to let users choose the make up of their document title, or another improvement to how title generation works, we now have a forward compatible way to handle these things.

    To upgrade themes from using wp_title() to declaring theme support for core’s title-tag without breaking backwards compatibility with WordPress 4.0 and older, theme authors can check if the callback function exists and add a shiv in case it does not:

    if ( ! function_exists( '_wp_render_title_tag' ) ) :
    	function theme_slug_render_title() {
    ?>
    <title><?php wp_title( '-', true, 'right' ); ?></title>
    <?php
    	}
    	add_action( 'wp_head', 'theme_slug_render_title' );
    endif;
    
     
    • Pippin Williamson 6:10 pm on October 20, 2015 Permalink | Log in to Reply

      As much as I love this improvement, I really don’t think a deprecated notice should be thrown here. The sheer number of themes using wp_title() is overwhelming and it will be a support / maintenance nightmare.

      • WebMan Design | Oliver Juhas 6:24 pm on October 20, 2015 Permalink | Log in to Reply

        I completely agree! This will be huge impact.

      • Konstantin Obenland 6:43 pm on October 20, 2015 Permalink | Log in to Reply

        At the point of release, theme support will have been introduced a year earlier, with the WPTRT adding it as recommended from the start. Two default themes will have been shipped with it, and it’s used in over 300,000 themes derived from _s since November ’14. And as Justin pointed out, it will have been required for the theme repo for more than a quarter of that time.

        While legacy themes will obviously still use it, there has been quiet a bit of theme developer education around this. The current landscape of document titles is really not as bleak as some make it sound.

      • Chuck Reynolds 2:15 am on October 21, 2015 Permalink | Log in to Reply

        I agree there will be a lot of questions but I also agree it’s time.

      • Coen Jacobs 10:08 am on October 22, 2015 Permalink | Log in to Reply

        If we’d go by that reasoning, there would be never any change possible. Production environments need to have debug mode switched off, so no notices there. Second, this change has been coming for so long, themes that have been actively maintained have had the chance to introduce their own way to deal with the deprecation already.

        • Samuel Wood (Otto) 9:32 pm on October 23, 2015 Permalink | Log in to Reply

          Like it or not, many live webhosts default to having the PHP display_errors flag enabled. Every time a new deprecated notice is added, sites all across the web break. Since this is going to affect themes, right on the front-page of the site and everywhere else, then that’s a lot of breakage. We cannot hope to upgrade all sites in time for this breaking change.

          Suggestion: Make the deprecated notice system not quite so stupid. Yes, users need to know things. However, if display_errors is on, and it’s the front end of the site (or the login page), and WP_DEBUG is not turned on, then we should probably shut it off if a deprecated notice is thrown. Throwing a notice out on login breaks logins (by breaking cookies), and throwing one on the main site makes for “broken” sites in the eyes of users. And all for a notice that a function, which still likely works okay, may not work in the future.

          I’m fine with the title change. But “deprecated” messages should not be so strong as to actually cause people to want to rollback WordPress versions.

          Yes, BTW, I do realize that _deprecated_notice only triggers when WP_DEBUG is explicitly on. Still, sometimes it is through auto-installers or something else. We should have some better way of warning people than displaying these notices right on the front end of the site.

          • FolioVision 3:13 am on November 3, 2015 Permalink | Log in to Reply

            We strongly agree here Samuel. While improving core structure is wonderful, transition should be gradual and over time. There’s no overwhelming benefit to breaking the web in this particular case. Gently gentlemen.

    • Justin Sainton 6:15 pm on October 20, 2015 Permalink | Log in to Reply

      +1 to not throwing a notice. this will be basically _every_ theme.

      • Pippin Williamson 6:15 pm on October 20, 2015 Permalink | Log in to Reply

        Including themes that are superbly built.

      • Simon Prosser 8:45 pm on October 20, 2015 Permalink | Log in to Reply

        Notices are only displayed with WP_DEBUG on, whats the issue?

        • Sybre Waaijer 6:29 am on October 22, 2015 Permalink | Log in to Reply

          The problem is that when a user wishes to turn it on to discover a nasty bug on a live site it will absolutely destroy the SEO value of the site if a search engine spider sees it.

          It would be better to enqueue the deprecation notice within the footer or any other part other than the tag.</p> <p>However, it’s suffice to say that I’ve been working for a good 40 hours to compromise the wrongly used wp_title tag within the header without using buffer rewriting.</p> <p>This update will force users to switch to a better theme, and it will also force theme developers to use the standards.<br /> From there it will also save a lot of developers heaps of time 🙂 So I’m pretty much all for the deprecation notice, wherever it actually may be.</p> <p>You know what, keep the deprecation notice within the title 😀 Hurray for standards!

    • Justin Tadlock 6:22 pm on October 20, 2015 Permalink | Log in to Reply

      I just wanted to note that WordPress.org themes are no longer encouraged to have the back-compat code. Title tag support is now required.

    • Aaron D. Campbell 6:49 pm on October 20, 2015 Permalink | Log in to Reply

      There is a fine line to be walked between backward compatibility and pushing ahead into better things. I think this is one of those cases where we’re walking that line very well. Themes are encourage (or in the case of .org, required) to push ahead into the newer/better way, and any theme that uses the older way **still works as it did before**. The notice deprecated function notice is not only just a notice (not an error or warning), but it’s only triggered by default if WP_DEBUG is on.

    • Drew Jaynes 7:12 pm on October 20, 2015 Permalink | Log in to Reply

      I see an inevitable question popping up: “What do I use instead?”

      The simple answer is nothing.

      If you add add_theme_support( ‘title-tag’ ); to your after_setup_theme callback, the title will just be handled. An internal core function adds it via the wp_head hook. No need to add anything to your theme’s header.php file, just remove the legacy wp_title() call.

      The ‘title-tag’ theme support was (as mentioned) added to core a year ago.

      Also, as @obenland alluded, there are several filters available for customizing the output:

      • pre_get_document_title – short-circuits wp_get_document_title() if it returns anything other than an empty value.
      • document_title_separator – Makes the separator between title parts filterable.
      • document_title_parts – Makes the parts that make up the document title filterable, passed in an associative array.
    • Jose Castaneda 8:47 pm on October 20, 2015 Permalink | Log in to Reply

      Sweet! One less thing for theme authors to maintain!

      • Ross Wintle 2:48 pm on October 22, 2015 Permalink | Log in to Reply

        So the simple answer is actually: “add `add_theme_support(‘title-tag’);` to your `after_setup_theme` callback! 😉

      • Ross Wintle 2:49 pm on October 22, 2015 Permalink | Log in to Reply

        Oh bother – that was a reply to @drewapicture above. Why is the reply button at the top of comments here?! You can tell I don’t comment on make blog very often.

    • catchmyfame 9:14 pm on October 20, 2015 Permalink | Log in to Reply

      Should https://codex.wordpress.org/Theme_Development#Template_File_Checklist be updated to *not* encourage the use of wp_title()? I didn’t see the equivalent checklist at https://developer.wordpress.org/themes/

    • simonrcodrington 9:51 pm on October 20, 2015 Permalink | Log in to Reply

      I’m all for moving forward with better things. As long as this is a developers notice when debugging is turned on and not an admin level notice that bothers users, I’m all for it.

    • Ahmad Awais 8:44 am on October 22, 2015 Permalink | Log in to Reply

      Fantastic! I just hope that theme authors will adopt this thing as quickly as possible.

    • Ross Wintle 2:47 pm on October 22, 2015 Permalink | Log in to Reply

      Confession: I’ve not been keeping up with developments in wp_title() in the last few releases. And I’m a developer who reads the make blog!! It’s only just now become clear that there is a new best practice from the one I started using several years ago. I suspect that there are many other developer like me, and many who don’t read the make blog!!!

      As a developer that creates custom themes for clients, I’m happy for a notice to be issued (to remind me to do it in future work!). I accept the need for (well documented and communicated) deprecation, but I’d really appreciate some guarantee on removal from core. I have a LOT of custom themes out there that I’ve built over the last four or five years. They all use wp_title somewhere. I’m hoping that I won’t be needing to update all that legacy code.

      Should the codex for wp_title be updated at this point to reflect the new best practice?

      • Drew Jaynes 3:04 pm on October 22, 2015 Permalink | Log in to Reply

        Should the codex for wp_title be updated at this point to reflect the new best practice?

        The code reference page for wp_title() will be updated with the deprecation notice when 4.4 is released. By that point, the wp_title() Codex article will already be redirecting to the code reference, as well.

    • BackuPsNL 4:05 pm on October 22, 2015 Permalink | Log in to Reply

      Hi

      How to call the new title function with the separator of choice?
      How to get just the title without the wpsite name?

      I liked the way wp_title() worked.

      I am not happy with this code change… 🙁

      • Konstantin Obenland 3:32 pm on October 23, 2015 Permalink | Log in to Reply

        How to call the new title function with the separator of choice?

        You can use the document_title_separator filter to change the separator to whatever you like. You can now even customize it to change based on what kind of page is being viewed!

        How to get just the title without the wpsite name?

        When you filter document_title_parts you can just change or unset the part that you don’t want to show up.

        • BackuPsNL 8:54 am on October 24, 2015 Permalink | Log in to Reply

          How does this work with the Yoast Seo plugin. As in the previous version i could just call wp_title and i got the correct yoast seo title when the plugin was activated.

          Now i have to enable force rewrite titles in that plugin settings to get the correct title in my page.

          With the Yoast plugin enabled and with force rewrite titles off i do not get the correct title as entered in the yoast seo title field in the page.

          I want to use my own title function as i dont like how wp presents it now.

          From wordpress you get Title – Page – Blog But i want Title – Blog – Paged

          There is no way to change the order or how wordpress presents the title. is there? If so please provide a example how todo so.

          • Konstantin Obenland 7:59 pm on October 24, 2015 Permalink | Log in to Reply

            The API was not usable for plugins until now. I’m sure SEO plugins will provide a way to interact with it by the time 4.4 ships.

            • BackuPs 4:29 pm on December 9, 2015 Permalink

              I updated the post to reflect that wp_title() has been reinstated until alternative usages have been identified and a path forward for them defined.

              Luckily the depricated notice has been removed at the final release of wp 4.4.

              I should have waited updating the theme core files on the final release and not have worked with the beta 4.4.xxx

    • johnstonphilip 4:57 pm on October 22, 2015 Permalink | Log in to Reply

      I had used wp_title to generate facebook open graph meta tags. What would one want to use for that instead moving forward?

      <meta property="og:title" content="” />

      • johnstonphilip 4:58 pm on October 22, 2015 Permalink | Log in to Reply

        ok so the php was stripped out of that comment. Here it is again without the php tags

      • Konstantin Obenland 3:34 pm on October 23, 2015 Permalink | Log in to Reply

        Using wp_title() to display anything other than the document title is not really ideal. In your case you’d want to use the wp_head action to attach a callback that would output that html.

        • Nathan Shubert-Harbison 10:37 pm on November 5, 2015 Permalink | Log in to Reply

          What would you use to print the page title inside the `wp_head` action though?

          • Samuel Wood (Otto) 4:27 pm on November 11, 2015 Permalink | Log in to Reply

            Ideally, you would not be rolling your own code to do this in the first place. Many plugins can do this for you, such as SEO plugins, Facebook specific plugins, Sharing plugins, Jetpack, etc. Themes would not have this sort of code in them.

            That said, the OpenGraph title for, say, a Page, would ideally be the title of the Page, not the wp_title(). OpenGraph is for sharing content, after all. So get_the_title() would be what you want to use, although you would probably need to preload the_post() and do a rewind_posts() to get that in the normal manner. It’s not an ideal situation to pre-load posts, but it is doable by plugins. It is poorly doable by themes, they’re doing it in the wrong order, basically.

    • Shah Alom 2:43 pm on November 12, 2015 Permalink | Log in to Reply

      Have basic confusion!

      What is the difference between

      add add_theme_support( ‘title-tag’ ) to function file directly

      and

      in the after_setup_theme callback hook

    • Konstantin Obenland 6:37 pm on November 12, 2015 Permalink | Log in to Reply

      I updated the post to reflect that wp_title() has been reinstated until alternative usages have been identified and a path forward for them defined.

    • Darko A7 4:41 am on November 17, 2015 Permalink | Log in to Reply

      This feels like a downgrade to me, what I had in few lines of code just the way I like it in one visible place, now have to do with filters and what not. Why?

      Anyway, I was doing a quick beta testing (4.4-beta4-35649) and there are absolutely no options to customize titles (separators, handling empty search strings…). This is a big omission, since they are supposedly now generated and handled by core.

      • Konstantin Obenland 4:33 pm on November 17, 2015 Permalink | Log in to Reply

        Separators can be changed with the document_title_separator filter, adjustments for special cases can be done by filtering document_title_parts .

    • BobNwp 6:36 am on December 11, 2015 Permalink | Log in to Reply

      This is going to be VERY, VERY long, but it would behoove you to read it all and discuss it amongst yourselves.
      ———————————

      WP “deprecates ” far too often! There is the principle of backward compatibility and it is a serious issue.

      Given the number of sites using WP (hundreds of thousands, or maybe millions??), there is no excuse for the number of things you drop and replace in the package.

      I believe that you would find that a large percentage of questions posted in the forums are about things that have been dropped or changed?

      Have any of you people ever worked in a real data processing shop and learned the foundation and principles of software design, coding, modification, and problem determination and problem resolution?

      I’ve been at this since 1973 (everything from basic programming to designing, coding, implementing telecommunications software and systems support for large IBM mainftrame shops) and I have never run into a product, either PC or mainframe, which drops or changes as many things as WP. – never.

      I’ve never encountered a package that requires such attention to release changes simply to keep a site up and running.

      The hallmark of a good software package is backward compatibility. An installation of WP created years ago should continue to work if an upgrade is done. Sure, it won’t be taking advantage of the latest and greatest features, but it should work as it had before the upgrade.

      You need to step back and take a realistic look at the way you drop functions and change other things.

      Seriously – you are not using generally accepted design and modification principles.

      WP is far to complicated for what it does. It is a bloated attempt to be everything for everyone.

      You documentation is poor and you have invented terms and methods which do not correspond with the terms and meaning used elsewhere.

      When I step back and look at this, it seems that you are more interested in doing things in the fanciest way you can; you can’t leave well enough alone; you are confusing “bleeding edge” software ideas with creating and maintaining an easy to use product which is fully backward compatible.

      Yes, there can come a time when something must be changed, but you go about it all wrong.

      I history language,, and then I’ll end this:

      In the 1960s, IBM took a billion dollar gamble on what became the IBM System/360. The top designers and engineers were taken to a motel and told that they would stay there until they had a system design which met what at the time were revolutionary ideas.

      One was staggering in its implications. The system they designed MUST be backward compatible – period

      A customer must be able to purchase the smallest system and be able to upgrade to a faster, larger system with absolutely no changes in software!

      They achieved that and many other revolutionary accomplishments.

      When the IBM System/360 was announced in 1964 (I was in elementary school at the time and knew nothing about computers) what it presented was a rlarge, serious, startling evolution in computing.

      The System/360 could be used for any purpose. It was the first general purpose system and it laid the foundation for everything that has occurred since then.

      When I say that no software changes were needed, I mean NONE.

      You could disconnect the main system from the peripherals, slide in a new one, cable everything up and IPL (Initial Program Load -“boot” to you) from the same disks with the same operating system configuration used for the previous system. Certainly there would be new features available, but they did not replace or change other features available on the other model.

      Unless the programmers were told that they were running stuff on a new system, the only way they would know it would be to go into the machine room and see the new unit or they noticed that things were running faster.

      I’ve been involved with five System/360 upgrades and I cannot remember any problems. Programs written, compiled, and link-edited on the previous system ran exactly as they had been running on the new system with not changes. The operations staff had newer, “modern” consoles but they controlled the system with the same commands and procedures.

      One upgrade was from a System 360/125 to a System 370/148 – a very large jump. The 370 was the next line of IBM systems – totally compatible with the 360. New features were available on the 370, such as the very first virtual storage – I think that was available in the early 1970s. I know it was available when I started in 1973.

      If IBM were to have announced that the new release of COBOL or some other language, was not compatible with the previous release and changes were necessary – customers would have stormed the offices and lynched everyone.

      If IBM changed the instruction set of a new model, which would require all software, including operating system and other support packages, to either be replaced or recompiled/assembled and link-editted, customers would have set upon the complete destruction of IBM.

      Short of violence, IBM would find that no one was buying the new systems. Businesses have more than enough to do without having to change all the software, applications and system.

      MS did this with VB – VB 6 programs were not compatible with VB Net. You had to made code changes.

      They got away with it because they have spent enough money to convince everyone that whatever they do is correct and “you simply don’t understand things as well as we do.”

      To close this out – stop the continuous dropping and changes of functions and features. Create a product which is backward compatible.

      Try to it picture the problem that would occur when a WP site that was running for years suddenly broke because you people dropped some function. The company/person might not find out it was broken for several days, during which customers would be running into the problems.

      Not everyone using WP has the time to monitor your site to try and stay up-to-date on what you are going to drop next.

      Please, bring a little sanity to WP.

      Bob Novell

  • morganestes 1:45 am on October 13, 2015 Permalink
    Tags: ,   

    Week in Core: Sept. 28 – Oct. 11, 2015 

    Welcome back to the latest issue of Week in Core, covering changes from Sept. 28 – Oct. 11, 2015, changesets [34659][35029]. Here are the highlights:

    See that ↑ right there? That’s an oEmbed. And it’s loaded from inside this site.

    Feature Plugins Merged

    The Responsive Images, oEmbed Provider, and the “baby” REST API feature plugins have been merged into core. Grab the latest version of trunk and test them out.

    WordPress logo with wordmark below

    Responsive images in your posts. Just upload and insert!

    Potent Notables

    These changes were big enough to merit their own blog posts:

    Deeper Reading

    Some commits pack in a lot of info, from detailed background to best practices in using hooks. Here are a few worth reading the entire commit message:

    • WP_Term class introduced [34997] #14162
    • Fix scalability performance problem for previewing multidimensional settings in the Customizer. [35007] #32103
    • Ensure that wp.customize.Widgets.savedWidgetIds is defined up front. [34883] #33901
    • The history and implementation of oEmbeds. [34903] #32522
    • Improve role-related arguments in WP_User_Query. [34875] #22212
    • Use wp_installing() instead of WP_INSTALLING constant. [34828] #31130
    • Introduce *_network_option functions for Multisite installs. [34777] #28290
    • Ensure that comment permalinks reflect pagination. [34735] #34068, #34073

    (More …)

     
  • morganestes 7:37 pm on September 29, 2015 Permalink
    Tags: ,   

    Week in Core: Sept. 21-27, 2015 

    Oh Snap!, it’s time to usher in a new edition of Week in Core! If you have the time, throw a house party with some friends and read the full force of changes on Trac; if not, don’t sweat it — take simple pleasure in these highlights.

    This post covers changesets [34362][34658], committed during Sept. 21–27, 2015. Let’s give a hi-five and some TLC to the 102 contributors for a combined 296 updates! Together, we’re making WordPress nice & smooth.

    (More …)

     
  • morganestes 9:08 pm on September 21, 2015 Permalink
    Tags: ,   

    Week in Core: Sept. 13-21, 2015 

    Welcome to the Week in Core — Week Four, with super-exciting news from around WordPress-land, and Core changes and updates for Sept. 13–21, 2015 (commits [34093][34361]). This week’s core contributors number 106! I’m especially jazzed about the number of new names on the list, and want to thank everyone for your effort this week.

    News you can use

    The WP REST API team submitted a proposal to merge the plugin into core, with a two-phase integration plan. The merge proposal blog post also does a nice job of presenting the history of the plugin and some use cases.

    Do you use my-hacks.php in your site? Don’t. (A quick search through the plugin and theme repos shows only 10 plugins and 3 themes that mention the file.)

    Multisite is making some pretty big changes, including the addition of the  WP_Network class. Check out this blog post, which outlines some of the changes and a roadmap for future updates for 4.4.

    Interested in the user-focused part of WordPress? Of course you are! Join in the conversation about “Potential UI/UX projects in core.”

    Code changes

    Here are some highlights from the 268 change sets published to Trac; the complete report is available online in plain-text format for a bit more in-depth coverage.

    (More …)

     
  • morganestes 9:04 pm on September 16, 2015 Permalink
    Tags: ,   

    Week in Core: Aug. 31 – Sept. 12, 2015 

    Welcome to the Week in Core, with updates from weeks 2 & 3: Aug. 31 – Sept. 12, 2015, changesets [33821][34092].

    It’s been a busy couple of weeks in Core, with almost too many changes to count (for the record, this one covers 271 commits!). I’m going to keep this update shorter than usual and highlight some of the bigger changes.

    If you’re interested in helping write this weekly post, ping @morganestes in #core-weekly-update on Slack.

    Special Note: WordPress 4.3.1 was released this week, with three security-related fixes. Be sure to update your sites!

    Here’s some highlights of recent changes in core, along with some future plans and ongoing initiatives. Remember, Core moves pretty fast. If you don’t stop and look around once in a while, you could miss it.

    • WordPress will support PHP7 when it’s released. Huzzah!
    • HTTP/2 is coming! Here’s a list of tickets that need attention to get WordPress ready.
    • Get involved in Twenty Sixteen, which is in active development on GitHub.
    • Write better commit messages. The world will thank you for it. 🙂
    • As described in this post by @johnbillion, the show_ui flag for post types now gets fully honored. See #33763 for the ticket discussion.
    • A new helper function, wp_validate_action( $action = '' ), was introduced in [34059] and is used throughout admin instead of directly accessing $_REQUEST['action'].
    • A new file, wp-admin/includes/noop.php, was created to load all of the noop functions for load-script|styles.php and is only loaded by those files. DRYs in the process. [34037] #33813
    • Schema change introduced in [34030] to increase the length of wp_options.option_name to 191 chars. #13310
    • Implement a priority system for Help Tabs to add them at specific positions. [33985] #19828
    • Multisite: Don’t allow sites to be created with the following reserved slugs: wp-admin, wp-content, wp-includes [33952] #33615
    • Updated recommendations for minimum versions of PHP (5.6) and MySQL (5.5), with a special note that Oracle only actively supports MySQL for 5 years after a General Availability release. [33937] [33946]

    For the full report, visit https://core.trac.wordpress.org/log/?verbose=on&format=changelog&rev=34092&stop_rev=33821&limit=400&mode=stop_on_copy.

    Thanks to @adamsilverstein, @afercia, @amereservant, @ankit-k-gupta, @antpb, @austinginder, @azaozz, @BdN3504, @benjmay, @boonebgorges, @bradt, @brettz95, @celloexpressions, @cgrymala, @Cheffheid, @chriscct7, @codeelite, @CoenJacobs, @danielbachhuber, @daniellandau, @dannydehaan, @dd32, @dimadin, @dipeshkakadiya, @dlh, @DrewAPicture, @dustinbolton, @egower, @enshrined, @ericdaams, @ericlewis, @extendwings, @figureone, @filosofo, @gaelan, @GaryJ, @gitlost, @gnaka08, @gradyetc, @gregrickaby, @hauvong, @helen, @imath, @ippetkov, @iseulde, @ixkaito, @jazbek, @jeffstieler, @jeremyfelt, @jesin, @jobst, @johnbillion, @joostdevalk, @jorbin, @juliobox, @JustinSainton, @kevinlangleyjr, @khromov, @kitchin, @kraftbj, @lancewillett, @liljimmi, @lukecarbis, @macmanx, @MatheusFD, @mehulkaklotar, @mercime, @metodiew, @michielhab, @MikeHansenMe, @miqrogroove, @mitchoyoshitaka, @mordauk, @morganestes, @mrahmadawais, @mrmist, @Mte9, @nacin, @netweb, @nikeo, @nikolovtmw, @nofearinc, @obenland, @ocean90, @OriginalEXE, @Otto42, @paulwilde, @pavelevap, @pento, @peterwilsoncc, @racaseh, @rachelbaker, @rajnikmit, @rmccue, @rommelxcastro, @sc0ttkclark, @scribu, @SergeyBiryukov, @sillybean, @solarissmoke, @stevehenty, @swissspidy, @tmatsuur, @trepmal, @tyxla, @umeshnevase, @utkarshpatel, @wen-solutions, @wenthemes, @westonruter, @wojtekszkutnik, @wonderboymusic, @yoavf, and @zeo for their contributions!

     
  • Ryan Boren 4:43 pm on September 2, 2015 Permalink
    Tags: , maintainership   

    Component Page Updates for 4.4 

    Now that 4.4 is underway, let’s update the component pages to reflect 4.4 activity. The Customize, Editor, and Press This pages serve as good templates, though they all need 4.4 updates. The component pages are targeted at beta testers. They should describe the component, list milestones (roadmap), and explain what needs testing and how to test it. Good component pages assist triage. For details, see the previous round of component page updates.

    Also, if your component has a corresponding Slack chat, link to the component page from the chat’s channel topic. This assists using Slack in beta testing flows.

    Component maintainers, here are your component pages…

    (More …)

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