Make WordPress Core

Updates from September, 2015 Toggle Comment Threads | Keyboard Shortcuts

  • Morgan Estes 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!

  • Morgan Estes 5:03 am on September 2, 2015 Permalink |
    Tags: ,   

    WordPress Core Weekly – Aug. 24-30, 2015 

    Welcome back to the weekly core development recap post, with highlights from Trac changesets and other development updates for 4.4. This week’s update covers changesets [33721][33820], Aug. 24-30, 2015. That’s a lot of changes, but there are a few that developers need to be especially aware of:

    • File restructuring: new class and functions files have been introduced, and existing files used as loaders for the new files for backwards compatibility.
    • File and class documentation enhancements: ensuring every file gets a standard file header, even if that file only contains a class that is itself documented.
    • Switching themes now takes menu locations into account so the new theme (maybe) gets the locations of the current theme.
    • New hooks introduced: 'invite_user' (Multisite users) and 'wp_verify_nonce_failed'.
    • The Twenty Sixteen theme is being developed on GitHub.

    Now on to the firehose…


    • Bump h3 headings to h2 on various admin screens for better accessibility:
    • Network Admin: Hide the bulk actions checkbox for super admins. [33777] #28529
    • Avoid PHP notices in redirect_canonical() and _wp_menu_item_classes_by_context() if $_SERVER['HTTP_HOST'] is not set. [33775] #32229


    • Remove error from the query variables when cleaning up a URL in wp_admin_canonical_url(). [33770] #32847
    • Prevent unintended password change after clicking “Generate Password” and then “Cancel” when editing a user profile. [33766] #33419
    • When wp_json_encode() calls json_encode(), the latter will generate warnings if the string contains non-UTF-8 characters. No one likes warnings, so we need to do something about that. [33747] #33524
    • Add oEmbed support for ReverbNation. [33745] #33207
    • Remove rounded corners from “Choose from the most used tags” result in Tags meta box. [33742] #31560
    • Add some more data for shortcode unit tests. [33740] #33455
    • Allow these CSS properties in KSES: min-height', 'max-height', 'min-width', 'max-width' [33739] #31949
    • Pass option name to option and transient filters with dynamic names. [33738] #28402
    • In get_home_url(), import the $pagenow global to avoid having to check if it exists before comparing against it. [33736] #33545
    • In WP_Users_List_Table::single_row(), $actions is not always set before being used. [33735] #33491
    • foreach is a statement, not a function. [33734] #33491
    • Instead of [33713], allow WP_Posts_List_Table::get_bulk_actions() to check edit_posts AND delete_posts. [33733] #29789
    • TinyMCE: ensure the wordpress plugin is loaded before calling _createToolbar(). [33728] #33393
    • With a few modifications in wp-admin/menu.php, we can eliminate the extra logic for Post and Page menu registration. Instead, they can just declare menu_position on post type registration. [33723] #16865
    • WP_Query: add changelog for the title param after [33706] [33722] #33074

    Restructured some files for separation of purpose, so class files only contain classes, functions files only contain functions, and the existing file loads the new files for backwards compatibility.


    Move WP_Tax_Query into class-wp-tax-query.php and functions into taxonomy-functions.php; taxonomy.php contains only top-level code and loads the new files. [33760] #33413


    Move WP_Post into class-wp-post.php and functions into post-functions.php. post.php contains only top-level code and loads the new files. [33759] #33413


    Move classes into their own files, and functions into its own:

    • class-wp-roles.php
    • class-wp-role.php
    • class-wp-user.php
    • capbilities-functions.php

    capbilities.php contains only top-level code and loads the new files. [33752] #33413


    Move classes into their own files and functions into its own:

    • class-wp-http-cookie.php
    • class-wp-http-curl.php
    • class-wp-http-encoding.php
    • class-wp-http-proxy.php
    • class-wp-http-streams.php
    • http-functions.php

    http.php contains only top-level code and loads the new files, so this is 100% BC if someone is loading http.php directly.

    class-http.php requires functions from http.php, so loading it by itself wouldn’t have worked.

    WP_Http remains in class-http.php. [33748] #33413


    Move WP_Meta_Query into class-wp-meta-query.php and functions into meta-functions.php. meta.php contains only top-level code and loads the new files. [33761] #33413


    Move WP_Rewrite into class-wp-rewrite.php, functions into rewrite-functions.php, and constants into rewrite-constants.php. rewrite.php contains only top-level code and loads the new files.

    The rewrite functions have all kinds of cross-dependencies (like WP_Query), so loading the file by itself would have been bizarre (and still is). [33751] #33413


    Move WP_Comment_Query into class-wp-comment-query.php, and functions into comment-functions.php. comment.php contains only top-level code and loads the new files. [33750] #33413


    Move WP_User_Query into class-wp-user-query.php and functions into user-functions.php. user.php contains only top-level code and loads the new files. [33749] #33413


    Move classes and functions into their own files:

    • class-wp-widget.php
    • class-wp-widget-factory.php
    • widget-functions.php

    widgets.php contains only top-level code and loads the new files. [33746] #33413


    It’s important for every file in WordPress, regardless of makeup or architecture, to have its own file header, even if the file contains nothing but a class. When parsed, files and classes are mutually exclusive and should be documented with this in mind. [33755] [33756] #33413

    • Bring the file header and class DocBlock summaries for class-wp-widget.php in-line with the intention of the docs standard:
      • File headers: What the file is
      • Class DocBlocks: What purpose the class serves. Mentioning the class name in the class DocBlock is redundant [33816] #33413
    • Add inline-docblocks for the require_once() calls that now bring in the WP_Widget and WP_Widget_Factory classes, as well as general core widgets functionality, as of [33746]. [33758] #33413
    • Add a file header description and @since version to wp-includes/widget-functions.php, introduced in [33746].
      Also adds sub-section headers per the inline documentation standards for syntax. [33757] #33413
    • Add a file header to wp-includes/class-wp-widget-factory.php, created when the WP_Widget_Factory class was moved to its own file in [33746]. [33756] #33413
    • Correct the hook docs for the user_profile_update_errors action. [33769] #33537
    • After [33764], fix docblock formatting for wp_list_categories(). [33765] #33460
    • Use proper array documentation formatting for wp_list_categories().
      This changeset also corrects a few parameter descriptions, and adds a few that
      were previously missing. [33763] #33556
    • Fix copy pasta in wp_cache_decr() doc block. [33809] #33548
    • The type for the $t_time parameter in the post_date_column_time filter docs should be string, not array. [33731] #33540
    • Document the default comment data arguments for wp_new_comment(). [33730] #32369
    • After [33698], wrap the time constants in a DocBlock template. [33737] #33397
    • Clarify the return description for wp_create_user() to illustrate that a WP_Error object will be returned on failure. [33725] #33321

    Add changelog entries for a variety of hook doc parameters added in [33738]:

    hook parameter changeset/ticket
    set_site_transient_$transient $transient [33794] #28402
    site_transient_$transient $transient [33792] #28402
    pre_delete_site_option_$option $option [33789] #28402
    pre_add_site_option_$option $option [33788] #28402
    pre_site_option_$option $option [33785] #28402
    transient_$transient $transient [33783] #28402
    option_$option $option [33779] #28402
    pre_option_$option $option [33768] #28402
    pre_set_site_transient_$transient $transient [33793] #28402
    pre_site_transient_$transient $transient [33791] #28402
    pre_update_site_option_$option $option [33790] #28402
    site_option_$option $option [33787] #28402
    default_site_option_$option $option [33786] #28402
    pre_set_transient_$transient $transient [33784] #28402
    pre_transient_$transient $transient [33782] #28402
    update_option_{$option} $option [33781] #28402
    pre_update_option_$option $option [33780] #28402
    default_option_$option $option [33778] #28402


    • Get the correct theme when template and stylesheet were both passed as arguments. Fixes a bug introduced in [21131] where $new_theme got set before the second argument was
      appropriately handled, causing the current_theme option to later always be updated to the parent theme’s name. [33815] #32635


    • Improve/update escaping in default widgets:
      • wrap some variables in esc_attr() before echoing
      • replace some strip_tags() calls with sanitize_text_field()
      • call esc_url() when wrapping some URLs [33814] #23012
    • Improve/update escaping in WP_Widget_Pages. [33813] #23012
    • Switch back to using array_key_exists() instead of isset() for widget instance existence check.
      Reverts unnecessary change in [32602] since array_key_exists() does actually work with ArrayIterator objects.
      Merges [33696] to the 4.3 branch. [33721] #32474, #33442



    • Fix the doc block syntax for the 'wp_get_current_commenter' filter. [33811] #33304
    • get_comment_count() currently increments awaiting_moderation when comments are in the trash. This occurs because case 0: will match any value passed to switch that is a string that isn’t specified in the list of cases. This is terrifying.
      Cases for 0 and 1 should be '1' and '0'
      Add unit tests for get_comment_count(). Currently, there are none. [33806] #33414


    • Favor using the consistent and agnostic string ‘Attach’ over ‘Attach to a post’ in the media list table. [33810] #33515
    • Make a period translatable. [33802] #33594
    • Switching themes: if the new theme doesn’t have nav_menu_locations defined, but the old theme does, copy the old theme’s nav_menu_locations into the new theme’s theme mods. [33808] #18588


    • Improve the reliability of the crop returned by image_get_intermediate_size() and add a bunch of unit tests to tests/image/intermediate_size.php. [33807] #17626
    • When inserting an image into a post, the values in wp.media.controller.Library should not default to linking the image when no user settings are present.
      The default display setting value for link is now none. User settings persist and will override or confirm this value based on user actions. [33729] #31467

    Posts, Post Types

    • In get_post_type_labels(), ensure that filtered labels contain all required default values. [33776] #33543
    • Don’t change the View Post button permalink in the sample permalink HTML when updating the slug on a published or future post. [33773] #32954
    • Pass taxonomy name to filters in get_adjacent_post(). [33805] #33568
    • Make post meta box toggles accessible. [33762] #33544


    • Improve the efficiency of is_user_member_of_blog() by removing its use of get_blogs_of_user(). Adds additional tests. [33771] #32472
    • Add 'invite_user' action that fires immediately after a user is invited to join a site, but before the notification is sent. [33732] #33008


    • In wp_list_categories(), ‘current_category’ should accept an array of values. [33804] #33565
    • Introduce $hide_title_if_no_cats parameter to wp_list_categories(). [33764] #33460
    • Rename param added to wp_list_categories() in [33764] to $hide_title_if_empty. [33767] #33565
    • Term Splitting: Switch to a faster cron unschedule process to benefit sites with thousands of affected jobs. Fix the cron hook name in the failsafe rescheduler. [33727] #33423
    • In WP_Query::parse_tax_query(), allow ‘cat’ and ‘tag’ querystrings to be formatted as arrays. [33724] #32454, #33532


    • Simplify the weeks-per-year calculation WP_Date_Query::validate_date_values(). [33803] #30845


    • Bring network admin user searching to parity with single site user searching by wrapping search terms in asterisks. This means that searches don’t require an exact match and therefore significantly reduces friction when searching for users on the network admin screens. [33801] #32913

    Bundled Theme

    Correct license information in readme.txt.

    Text Changes

    • Drop the hyphen from e-mail and standardize on email.
      The AP Stylebook changed this in 2011, and we’re woefully inconsistent, so let’s go with the standard. [33774] #26156



    • Add 'wp_verify_nonce_failed' action that fires when nonce verification fails. [33744] #24030
    • Fire the check_ajax_referer action on failure as well as success. [33743] #33342

    Build Tools

    Thanks to @azaozz, @BinaryKitten, @boonebgorges, @bordoni, @Cheffheid, @chipbennett, @danielbachhuber, @dd32, @DeBAAT, @dimadin, @DrewAPicture, @ebinnion, @egill, @eherman24, @ericlewis, @garza, @hauvong, @helen, @janhenckens, @jjeato, @jmayha, @joedolson, @joehills, @joemcgill, @johnbillion, @KalenJohnson, @kitchin, @liljimmi, @luciole135, @mako09, @MikeHansenMe, @miqrogroove, @morganestes, @niallkennedy, @nikeo, @obenland, @Otto42, @pavelevap, @pento, @peterwilsoncc, @rachelbaker, @rhubbardreverb, @sammybeats, @sboisvert, @scribu, @SergeyBiryukov, @Shelob9, @tyxla, @Veraxus, @vilkatis, @Viper007Bond, @voldemortensen, @welcher, @westonruter, @wonderboymusic, and @yamchhetr for their contributions!

  • Morgan Estes 1:37 pm on March 6, 2015 Permalink
    Tags: ,   

    WordPress Core Weekly 

    Howdy, and welcome to this week’s installment of WordPress Core Weekly – covering February 26, 2015 [31545] through March 4, 2015 [31620].

    If you want to 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.

    Let’s start with a warm welcome to our new Component Maintainers, who play an important role in the development process.

    Build/Test Tools: @voldemortensen
    Comments: @rachelbaker
    Editor – Press This: @Michael-Arestad, @stephdau
    General: @SergeyBiryukov
    I18N: @SergeyBiryukov
    Options, Meta APIs: @MikeHansenMe
    Themes – Customize: @voldemortensen
    Users: @justinsainton

    These maintainers are vital to keeping WordPress development running as smoothly as possible. They triage new tickets, look after existing ones, spearhead or mentor tasks, pitch new ideas, curate roadmaps, and provide feedback to other contributors.

    Dev Chat Notes

    This week’s Dev Chat was a lively one, with updates on the Customizer and Press This (with an emphasis on accessibility, hooray!), Shiny Updates (needs helping hands, see the todo list), Emoji (not just for smiles), and Accessibility (revisiting the age-old a vs button question).

    If you missed the meeting, or need a reminder of what was discussed, take a few minutes to read the transcripts.

    A couple of reminders: we’re a week away from Beta 1, and Daylight Saving Time is coming so make sure to check the time of next week’s Dev Chat so you won’t miss it!

    Tickets needing a look:

    • #5305: permalinks broken when article name is numeric
    • #31349: Screen options posts/pages/etc. per page label
    • #17817: do_action/apply_filters/etc. recursion on same filter kills underlying call
    • #29820: Smooth installation and updating of plugins and themes

    Code Updates

    It’s been a busy week with lots of commits, so let’s get into the ticket overview:


    • Allow inline editing of width and height parameters while previewing an embed in the media modal. [31620] #31139
    • Media modules: set $ to Backbone.$, instead of jQuery, so fewer globals are imported. [31618] #28510
    • When viewing media in List mode, auto-submit the form for attachment filters when the value of a <select> changes. This makes it behave similar to Grid mode and “feels” more performant, even though it is a full page load. [31582] #30333
    • Allow attachments to be detached from their parent in media grid and list modes. [31619] #6820
    • In the Insert From URL state of the Post frame, add the necessary CSS for focus styles for images. [31585] #28820
    • Build: Let RTLCSS handle swapping the codes for right/left arrows from Dashicons. [31579] #31478
    • Support GIMP files in the Media Library. We already support Photoshop files. [31578] #31146
    • In the ->multi_resize() method of the WP_Image_Editor subclasses, when looping through potential crops, we need to make sure the crop isn’t the exact same dimensions as the original image before copying it as a new crop. [31576] #31296
    • Make a new function, wp_delete_file(). Use it. [31575] #17864
    • Improve get_media_embedded_in_content() so that it returns the media it finds in the same order that it appears in the content. [31574] #26675
    • Customize Widgets: Don’t return undefined items in getWidgetFormControls method. [31570] #31465
    • CSS: Move relevant #sidemenu rules into deprecated-media.css and remove the cruft. [31564] #27956
    • Persist search terms across grid/list modes. [31562] #30583


    • Respect comment_date and comment_date_gmt params in wp_new_comment(). [31615] #14279
    • In get_next_comments_link(), ensure proper pagination when no ‘cpage’ query var is found. [31617] #20319
    • wp_insert_comment() should be checking and setting $compacted, not the non-existent $post_data. [31553] #21212



    • decode HTML entities before trying to insert view markers. [31612] #31412
    • introduce getText() and remove() methods, improved getInstance(), better docs. [31559] #31412
    • Better structure; simpler “view” registration; better extensibility; better inline documentation; don’t show a placeholder for pasted link until we know the link is “embeddable’. [31546] #31412
    • Remove the (obsolete) get/setViewText methods. Update stopping/pausing of multiple ME media players. [31548] #31412



    • Autocomplete: Update CSS based on both jQuery UI and general visual changes. [31611] #31427
    • Add wp.a11y.speak() for audible alerts/updates in screen readers. [31594] #31368
    • Remove the once-placeholder-esque “tag hint”, which has not worked in quite some time. [31607] #31485
    • When sanitizing a URL to redirect to, UTF-8 characters can be URL encoded, instead of being removed. [31587] #31486
    • Introduce get_object_terms filter in wp_get_object_terms(). [31581] #18828
    • In get_avatar_data() and get_avatar(), allow height and width to be specified separately (both default to size). Also allow arbitrary attributes on the <img> via the extra_attr arg. [31561] #31469
    • Permalinks: In wp_get_attachment_url(), convert to HTTPS when possible. [31614] #15928

    Posts, Post Types

    • List tables: Display front and posts page indicators. [31610] #30190
    • Hide irrelevant UI and display a message when editing the page for posts. [31550] #17470

    Press This

    • Add missing access modifiers to WP_Press_This. [31552] #31456
    • Add press-this.css to the list of stylesheets that are minified and to list of RTL styles. [31547][31572] #31373
    • Make sure buttons.css is loaded before press-this.css. [31597] #31373
    • Use correct URL for update bookmarklet link. [31556] #31461
    • Go back to loading the minified bookmarklet content with file_get_contents(). Add Grunt task to minify bookmarklet.js on precommit and update it in /src. [31545] #31373
    • Improve handling of the data, both from the bookmarklet and from server-side parsing. [31609] #31373
    • Remove unneeded passing of post formats strings to JS. Set the currently selected post format name with jQuery. [31589] #31373

    [31601] #31493

    • Remove classes from suggested HTML for the editor.
    • Improve the filter, pass an associative array as param.
    • Use <em> instead of <cite>.

    [31595] #31373

    • Simplify getSuggestedContent() and helpers. No need to override the global data.
    • Replace the press_this_source_string and press_this_source_link filters with press_this_suggested_html that allows filtering of the link and the wrapper HTML tags.

    [31588] #31373

    • Backwards compatibility enhancements.
    • Add missing actions for printing styles/scripts.
    • Since $hook_suffix is null, hardcode press-this.php.
    • Restore body classes, add filter.
    • Use wp_json_encode().
    • Update docs for filters in script-loader.php.


    • TinyMCE: set ‘directionality’ and add the LTR button when in RTL. [31580] #31474
    • RTL improvements: [31577] #31478, #31474
    • Fix and update buttons styles. [31598] #31498
    • When there is a protocol mismatch (http vs. https), use server-side media detection instead of submitting a form as it triggers “Unsafe data” warning in some browsers. [31584] #31468
    • Fix selecting a post format (radio buttons) with the keyboard. [31583] #31440
    • Accessibility enhancements [31566] #31449
    • Enable scrollbars in Firefox, remove overflow-x: hidden from the html element. [31565] #31455
    • Fix notices/errors classes. [31549] #31456


    • Fix a typo in the $args parameter hash notation description for add_settings_field(). [31593] #28975
    • Nav menus: Better JS performance on initial load of edit screen. [31604] #25698
    • Themes: Avoid jumping when selecting a feature in the feature filter on Add Themes screen. [31603] #31497

    External Libraries


    • Settings API: Allow passing a class to add_settings_field() via the $args array. [31560] #30168, #28975

    Build/Test Tools

    • RTL CSS generation: Switch from CSSJanus to RTLCSS. [31573] #31332
    • Run unit tests on Travis CI with PHP nightlies. With PHP7 in active development, this will help us identify issues there. [31558] #31454
    • Update grunt-patch-wordpress to 0.3.0. [31557] #31466

    Thanks to @abhishekfdd, @afercia, @alexkingorg, @atimmer, @azaozz, @boonebgorges, @couturefreak, @doublesharp, @DrewAPicture, @floriansimeth, @GrahamArmfield, @HarishChaudhari, @helen, @ipm-frommen, @iseulde, @joemcgill, @jorbin, @kopepasah, @kraftbj, @Michael-Arestad, @MikeHansenMe, @miqrogroove, @MomDad, @morganestes, @nacin, @ocean90, @kadamwhite, @oso96_2000, @pento, @postpostmodern, @rodrigosprimo, @scribu, @SergeyBiryukov, @sevenspark, @solarissmoke, @stephdau, @swissspidy, @valendesigns, @welcher, @westonruter, and @wonderboymusic for their contributions!

  • Mike Schroder 6:03 am on June 19, 2014 Permalink
    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.


    • 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


    • 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


    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]


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


    • 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


    • 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



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

  • Simon Wheatley 2:04 pm on June 12, 2014 Permalink
    Tags: ,   

    In yesterday’s Weekly Developer Chat, various minor schema change tickets were discussed. We would want to address any changes in as efficient a fashion as possible, and have discussed using the pre_schema_upgrade() function rather than dbDelta(), so we can control the queries more precisely.

    Below is a list of the tickets discussed yesterday, along with which tables they affect. Please add any questions, concerns, additional tickets, or +1’s for this work in the comments.


    • comment_author_email #21435 – “wp-includes/comment.php line85 causes slow query due to the non-indexed column” raised by @matsubobo (proposes adding an index to comment_author_email)
    • multiple-column indexes #15499 – “Add an index for get_lastpostmodified query” raised by @simonwheatley (proposes adding an index on post_type, post_status, post_date_gmt and another on post_type, post_status, post_modified_gmt)


    • option_name #13310 – “Extend option_name to varchar(255)” raised by @scribu


    • post_name #10483 – Increase field length from 200 to 400. #21212 – Reduce index length to 191 for InnoDB.
    • guid #18315 – “Add an index to the GUID column in the posts table” raised by @alexkingorg
    • post_password – #881 – “Lengthen password field for protected posts” raised by @ScytheBlade1


    • slug #22023 – “Remove UNIQUE for slug in wp_terms” raised by @nacin (related). #16230 – Increase field length from 200 to 400. #21212 – Reduce index length to 191 for InnoDB


    • modify existing index #5034 – “Impossible to have duplicate category slugs with different parents” raised by @snakefoot (proposes adding an index on term_id, taxonomy, parent)
  • Mike Schroder 8:23 am on March 5, 2014 Permalink
    Tags: ,   

    Last Week in WordPress Core 

    Howdy! This is Last Week in WordPress Core for the week of February 24—March 2! Lots of activity for the past week, which is great as we head into our last few days of alpha. Please join us for daily triage at 1900 UTC to help work through the remaining enhancements scheduled for 3.9.

    As a quick note, if you work with our tools in ‘develop’, and are receiving a SELF_SIGNED_CERT_IN_CHAIN error, you can resolve it by running npm config set ca="". For details, check out this npm blog post.

    If you want to skim, each section is roughly ordered by an important and/or interesting factor.


    • Add the ability to drag and drop files directly onto the editor. Upon drop, the media manager will open, and file will begin to upload. [27343] #19845
    • Throttle scrolling of the main window when the editor is active and is being scrolled with the mouse wheel or a trackpad. [27368]. Expect some major tweaks here, though; see #27013.


    • Introduce HTML5 gallery support. When a theme supports HTML5 galleries via add_theme_support( 'html5', 'gallery' ), figure, and figcaption will be used instead of definition list markup. [27302] #26697
    • Add a filter to remove or rename page templates for a theme. This does not yet handle adding page templates. [27297] #13265
    • Move comment-reply.js to the footer. While it can function before the page is loaded, it works by moving the comment form, which is usually toward the bottom of the page. Please report any contraindications on the ticket. [27303] #12641
    • Return 404 when querying author’s posts who is not a member and has no posts on the site. [27290] #20601
    • Make get_adjacent_post() wrap a new WP_Adjacent_Post object that uses WP_Query. [27285] [27286] #26937
    • Add exclude and include arguments to wp_list_authors(). [27274] #9902


    • Multisite: Introduce get_site_by_path() and further rewrite the site detection process for multisite. This makes it so that a sunrise plugin could do much of its work by adding filters, if those are even needed. [27359] #27003
    • Database: Use MySQLi for WordPress development versions, regardless of PHP version, to increase testing footprint. There’s also a constant for testing purposes. [27257] [27278] #21663
    • Plugin API: Introduce doing_filter() and doing_action() to identify hooks in progress. You can also use this with to identify a hook that has completed. For more, see [27294] #14994.
    • Formatting: Strip backslashes, not just forward slashes, from untrailingslashit(). trailingslashit() will now remove any forward or backslashes from the end of a string before appending a forward slash. [27344] #22267
    • Date/Time: Allow current_time() to accept a date format string, adding to timestamp and mysql. [27259] #21653
    • Updates: During core upgrade, copy wp-includes/version.php over last, to avoid an installation failing with the new version.php in place. [27336] #25860
    • Rewrite API: Allow rewrite endpoints to specify a query variable name. [27327] #20905
    • Cache API: Revert [27115] and let cache backends handle the stripping of spaces in cache keys as necessary. microtime() returns greater precision than microtime(true). [27300] #27000, #23448, #26903, #14485
    • Query: Add a $default argument to get_query_var() and WP_Query::get(). Helpful when working with endpoints. [27304] #16471
    • Comment Query: Allow user_id to be an array of IDs in WP_Comment_Query. [27258] #27064
    • Users: Make the user arguments for get_edit_profile_url() and get_dashboard_url() optional, defaulting to the current user. [27260] [27265] #16686

    External Libraries

    • Update the Masonry JavaScript library to version 3. [27271] #25351
      • The new script handle is masonry. The old jquery-masonry handle is the official shiv that sits on top of the v3 library to be backwards compatible with v2 usage. While v3 no longer depends on jQuery, a theme or plugin may have been implicitly loading jQuery though Masonry, rather than additionally declaring it as a dependency for themselves.
      • Themes should switch to masonry and declare jQuery as a dependency on their own if they need it.
      • Upgrade guide on Masonry’s site, with the exception that, for core, we continue to include imagesLoaded.
    • Upgrade Plupload to 2.x (2.1.1) [27316] #25663
    • Update the Root Certificate bundle used for SSL communication by WP_HTTP from the latest Mozilla release NSS. [27307] #27017

    Developer Tools

    • Add grunt-patch-wordpress for applying patches directly from Trac. Mapped to grunt patch, which declares usage. Requires npm install to install. [27299] #27023
    • Add JSHint to Travis CI config. [27267] #26446

    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, @andy, @avryl, @bassgang, @bootsz, @chrisscott, @danielbachhuber, @DrewAPicture, @enej, @ericlewis, @ericmann, @ethitter, @evarlese, @garyc40, @GaryJ, @gcorne, @georgestephanis, @GregLone, @helen, @iamfriendly, @Ipstenu, @jackreichert, @jeremyfelt, @johnjamesjacoby, @jorbin, @knutsp, @kovshenin, @kpdesign, @leewillis77, @markjaquith, @mattheu, @mboynes, @mitchoyoshitaka, @mjbanks, @mordauk, @morganestes, @nacin, @nicolealleyinteractivecom, @obenland, @ocean90, @patricknami, @pento, @pross, @rickalee, @salcode, @scribu, @SergeyBiryukov, @shelob9, @siobhyb, @solarissmoke, @xsonic, @stephcook22, @theorboman, @tivnet, @TobiasBg, @willmot, @wonderboymusic, @xknown, and @yoavf for their help this week!

  • Andrew Nacin 9:01 pm on January 27, 2014 Permalink
    Tags: ,   

    Proposed Trac component reorganization 

    Warning, this long. tl;dr: I propose a reorganization of our Trac components. 34 top-level components with two dozen subcomponents. New tree at the bottom. First, an overview of some of our problems.
    (More …)

    • Robert Dall 12:30 am on January 28, 2014 Permalink | Log in to Reply

      I am not sure if we want to confuse the themes & bundled theme anymore then they already are. When I gave a talk on trac and I explained why it is called bundled themes a couple light bulbs went off in the crowd. But yet they knew what default themes meant. It’s all semantics, but now that understand why themes and bundled themes are different.

      What I *REALLY* like is having a subcomponent for each theme in development. We could still use use the title to differentiate between Twenty-Thirteen and Twenty-Fourteen as is the current standard but having this and the easy of use sounds whole lot better and easier for query’s of trac etc…

      • Andrew Nacin 1:12 am on January 28, 2014 Permalink | Log in to Reply

        I’ve got no issue renaming Bundled Theme to Default Themes, and we can definitely nest individual components underneath it for each theme. The issue I see would be that if we added subcomponents for each default theme directly under the Themes component, where would a ticket go that affects more than one theme? (This isn’t entirely uncommon.)

        • Sam Sidler 4:19 pm on January 28, 2014 Permalink | Log in to Reply

          In the main Bundled/Default Theme component? I assume the components are still usable even when subcomponents exist.

          • Andrew Nacin 6:47 pm on January 28, 2014 Permalink | Log in to Reply

            Sorry, I should have been more specific. Option 1, which is totally fine;

            Default Themes

            • Twenty Ten
            • Twenty Eleven

            Option 2, which I’d prefer (and which I thought RDall was hinting at):


            • Appearance
            • Widgets
            • Nav Menus
            • Twenty Ten
            • Twenty Eleven

            My point was I’d like to merge “Bundled Theme” (or “Default Themes” or whatever) with “Themes” to make it even less confusing. But then I’m not sure where general default theme tickets (affecting multiple themes) would go — getting dumped in “Themes” means they may get lost.

        • Robert Dall 6:20 pm on January 28, 2014 Permalink | Log in to Reply

          Does it need a subcomponent if it effects all themes? Or are subcomponents required when they exist?

    • Jon Brown 12:15 am on January 28, 2014 Permalink | Log in to Reply

      This looks great. You’ve done a great job of making the parents obvious (fwiw, I’d keep bootstrap as bootstrap).

      Two things seemed non-obvious to me, and maybe that’s just unfamiliarity on my part, but worth mentioning.
      First – Formatting-Shortcodes/Charset. This seems non-obvious to me but I’m guessing this is processing raw content, essentially wpautop, it’s brethren and associated filters. Formatting sounds more like CSS to me than filtering/processing content.
      Second – There are separate top level categories for HTTP API & XML-RPC. It seems to me this could be a single top level “Remote/External APIs” component with sub-components for HTTP, XML-RPC, JSON, etc… Maybe that’s makes no sense though though since code wise they’re entirely separate.

      Again, great work sifting all this into these components, these are just comments as I read through and understand what’s group where, why and what each component covers.

      • Andrew Nacin 7:01 pm on January 28, 2014 Permalink | Log in to Reply

        Formatting has been called Formatting, well, for as long as I’ve been around. It also centers around formatting.php. It might not be the best name, but yeah, it’s for processing raw content. We’ll make sure the description and search keywords for it are solid.

        For right now, HTTP and XML-RPC have pretty much zero overlap in form or function. We’ll need to revisit everything here anyway when the REST API comes into core. (Gut reaction would be a component for the server, and a focus to handle APIs specific to another component.)

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

      One additional focus that may make sense is Unit-Tests. The use case I’m thinking of is a patch that just adds unit tests. It would go in the component that it most directly deals with as I think the test tools component is more focused on the tools of testing rather than the actual tests and receive the focus of Unit-Tests (and optionally the JavaScript focus if it is a javascript unit test)

      • Andrew Nacin 10:07 pm on January 27, 2014 Permalink | Log in to Reply

        Ah, yeah, I forgot to mention this. This is also on my list. I’m still trying to figure out how it overlaps with keywords (needs-unit-tests and has-unit-tests), so I saved it for later. Does needs-unit-tests and has-unit-tests simply trigger the unit-tests focus automatically? If a ticket is opened specifically to provide unit tests for something, is that more of a has-patch situation? etc.

        • Aaron Jorbin 11:27 pm on January 27, 2014 Permalink | Log in to Reply

          I think needs-unit-tests and has-unit-tests should trigger the unit tests focus.

          Has-patch makes sense in the just adding unit tests case since it is fixing the reported issue (not having unit tests) while I think needs-unit-tests and has-unit-tests is more workflow oriented.

    • StyledThemes 9:24 pm on January 27, 2014 Permalink | Log in to Reply

      Give me a BIG Pot of coffee and I will ready this shortly…however, I saw the part of Bootstrap which caught my eye as I build my themes with it (well, parts of it). But from what I see in the list, looks interesting overall.

      • Andrew Nacin 9:25 pm on January 27, 2014 Permalink | Log in to Reply

        Bootstrap is not Twitter Bootstrap, it’s the “loading” process of WordPress. I may rename this to Bootstrapping if it’s a problem.

        • StyledThemes 9:34 pm on January 27, 2014 Permalink | Log in to Reply

          ah… how about WordStrap :)

        • nofearinc 9:37 pm on January 27, 2014 Permalink | Log in to Reply

          That’s the initial association of many folks btw, even knowing what Bootstrapping is, the recent popularity of the Twitter’s thing is overlapping actively, just my 2¢

        • jack96161 10:26 pm on January 27, 2014 Permalink | Log in to Reply

          Agreed, Twitter commandeered “Bootstrap” for too many in the community these days — greybeards like me know what a real bootstrap is, but renaming it will eliminate more questions like this in the future. I always liked the “Progenitor Process”, we used in an early operating system at HP, but it will probably end up as something like “startup”, “init”, or other bland 2-syllable invention …

          • jack96161 10:34 pm on January 27, 2014 Permalink | Log in to Reply

            Just noticed on the 3.9 Trac pages that “Bootstrap/Load” is used as a component name — I’ll vote for that one and the Twitterites can just deal with it!

    • nofearinc 9:23 pm on January 27, 2014 Permalink | Log in to Reply

      I’m curious about the Query branches of Comments and Users – too many tickets for these types of Queries or plans to extend a lot furthermore?

      Great list though, and the “hall of fame” with notes is awesome.

      • Andrew Nacin 9:28 pm on January 27, 2014 Permalink | Log in to Reply

        I don’t think either is necessarily the case. The idea was to create a specific subcomponent under Users that those focused on Query (in general) could also specifically follow. Same for Comments. So in this case, it’s about granularity, not necessarily roadmap or ticket counts. Query is goofy, as I mentioned in the post — it’s a cross-section that would normally be good as a focus, but it actually covers functional areas of core (there just happen to be a lot of areas).

    • Helen Hou-Sandi 9:22 pm on January 27, 2014 Permalink | Log in to Reply

      I am particularly excited about how groups and maintainers will (hopefully) form around components and focuses. Anybody can comment on a Trac ticket or pitch an idea or create a potential roadmap, but there’s a real sense of empowerment when you really feel like you’ve got your head and hands wrapped around a specific area, and are perhaps even recognized for doing so.

      I know for me personally it’s been really gratifying to be entrusted to run with a particular area (what we can now define as the UI focus) and has made me feel more comfortable with interacting and pushing core forward. And not just when it comes to UI development and conception, but in other areas as well. I also might just dare hope that we can stop the worst of the ticket rot, with having both more bodies as well as a clearer idea for hopeful contributors as to where to go for more feedback or help.

  • Andrew Nacin 2:26 am on July 28, 2013 Permalink
    Tags: post types, ,   

    Potential roadmap for taxonomy meta and post relationships 

    In the days before the WordPress Community Summit in October, a number of contributing developers huddled together to discuss a number of long-term architecture ideas. Among them were taxonomy meta and post relationships. (Ah, I see I now have your attention!) This post is more or less a proposed roadmap. It’s an ambitious plan that is designed to take place over perhaps five or more releases.

    (During WordCamp San Francisco’s keynote, @matt talked a little about a new aim to build teams of contributors and reviewers around individual core components. There will be a lot more on that in the coming days and weeks. For now, here’s a post that covers two components, post types and taxonomy.)

    The discussion included all core committers at the time — @ryan, @markjaquith, @westi, @azaozz, @nacin, @dd32, @koopersmith, and @duck_ — and a number of contributing developers, including @aaroncampbell, @dh-shredder, @helen, and @scribu.

    At the moment, terms are represented in WordPress using two different IDs: a term ID, and a term taxonomy ID. A term ID (and name and slug) can actually appear in multiple taxonomies, so to identify a particular term, you must have either the term ID and the corresponding taxonomy, or just the term taxonomy ID. This dates back to the original taxonomy schema in WordPress 2.3. At the time, the concept of “shared terms” seemed like it could be an important abstraction. Hindsight is 20/20, and shared terms are the bane of taxonomies in WordPress.

    So when we talk about term meta, we’re actually talking about term taxonomy meta — meta associated with a term taxonomy ID, not a term ID. The problem is, the public ID used in the API and elsewhere is the term ID (and, by necessity, a taxonomy is also passed). This confusion — and the need for there to be only one object identifier in our metadata API (term taxonomy ID, not two, as in term ID and taxonomy) — has long forced us to table the discussion of term metadata.

    (There are separate conceptual issues here — at what point does a term with metadata simply become a post-like object that can relate to other posts? And given post relationships, could terms and posts actually converge in their underlying schema? I’m not actually going to answer those questions in this post. Purely talking schema and architecture at this point.)

    At WordCamp San Francisco last year, four of us — me, Gary Pendergast (@pento), @scribu, and @koopersmith — came up with a rather crazy way to make major changes to our table schema while still being backwards compatible. In fact, we came up with two ways to do it. This was the plan everyone heard and discussed at the summit.

    It was clear that shared terms had to go. The first step is removing a UNIQUE index on the slug field in the wp_terms table. (This is dependent on #17689.) Then, we stop creating new shared terms. Step three, on an upgrade routine, we actively look for any existing shared terms and split them.

    These three initial steps must happen over two to three major releases, as we’re talking about a bug fix, a schema change, an API change, and an upgrade routine — in that order.

    Then comes the fun part, in yet another major release. With shared terms split, term ID and term taxonomy ID will be identical  on every install.  If we moved the slug and name fields from wp_terms to wp_term_taxonomy, we could actually drop wp_terms.

    How can we remove an entire table but still be backwards compatible? We came up with two solutions:

    1. Because all fields in wp_terms will exist in wp_term_taxonomy, wp_terms can be recreated as a MySQL view to be a read-only mirror of term data, thus being compatible with all existing queries.
    2. Because all fields in wp_terms will exist in wp_term_taxonomy, and because table aliases like `t`and `tt` are always used when joining these two tables, $wpdb->terms can simply be set to $wpdb->term_taxonomy. A query that previously joined wp_terms with wp_term_taxonomy would just join itself.

    In all: Using the second approach (yes, it works), it took about 20 lines of code to make WordPress run without a wp_terms table. Wow, right?

    So by this point, we would finally have a sane taxonomy schema. Less joins, a cleaner API (probably helped by a new WP_Term object to model WP_Post and WP_User), no more shared terms headaches, and a single, sane ID for a single taxonomy’s term.

    Once that is all finished, we can finally have term meta. Maybe. (Kidding. (Kind of.))

    Where do post relationships come in? The existing Posts 2 Posts plugin by @scribu is fantastic and serves the niche well. But we’re not really comfortable making any architecture or API changes along these lines while our taxonomy schema is still in a far from ideal state.

    The post relationships plugin supports posts to posts, and posts to users. Core taxonomy relationships supports posts to terms, but it can also be rigged to relate users to terms. (It also supported links to terms, yet another object type.) We didn’t fully iron out this idea yet, but one idea is to convert the current wp_term_relationships table to a more generic object relationships table, which can support posts to posts, posts to users, terms to users, and of course posts to terms (and, really, any arbitrary relationship).

    A disclaimer: This post doesn’t promise anything. Do not rely on the contents of this post for future projects.  It will take us some time to lay out the proper groundwork and make sure we get this right. Do not expect this to happen in WordPress 3.7, or even 3.8. (Actually, do not expect this to happen at all.)

    That said, I’m really glad to get this information out there and I’m excited to hear any feedback you may have. We are always thinking toward the future, and a lot of contributing developers have mile-long roadmaps in their heads — it’s long past time to get those on paper.

    • Chuck Reynolds 10:43 am on August 3, 2013 Permalink | Log in to Reply

      needs to happen.. might as well start the move and roll it out slow.

    • grindcode 12:10 pm on August 2, 2013 Permalink | Log in to Reply

      This is the last milestone WP needs to approach any needs. Good stuff!

    • AzzX 12:10 am on August 2, 2013 Permalink | Log in to Reply

      I have used CPTonomies and Posts to Posts to achieve more functionality though they are hacks and susceptible to being discontinued and breaking. This is where Drupal excels. If I want to have ratings and comments on a specific Taxonomy I can – without hacking the core.

    • Chris Lema 2:53 pm on July 31, 2013 Permalink | Log in to Reply

      +1 for doing it over several releases (even if it’s slow). Quick DB changes have tons of unintended consequences. Great write up.

    • shawfactor 7:18 am on July 31, 2013 Permalink | Log in to Reply

      @nacin the speed and modelling improvements would be nice but the can you elaborate further on how you would extend the current taxonomies which are doubles into triples without having a redundant field on the doubles?

      Also I think Posts 2 Posts plugin by @scribu is nice but as I’ve argued: http://shawfactor.com/b/gaA

      post relationships need to be in the core and they nheed to be semantic.

    • Allstar 9:14 pm on July 30, 2013 Permalink | Log in to Reply

      I’m all for progress…

      What about internationalisation?

      I’ve wanted for ages for the term_taxonomy tables description field to be moved into the terms table. Therefore all the language would be in one place and the data in another.
      So, you would only use the term_taxonomy_id as a primary for getting stuff BUT you could have multiple terms (in different languages) associated with it. You would not go to the terms table first to find something unless it was by text lookup.

      A WP_Term object is a big *like* from me but I’d l’d also like WP to be easier on the international side of things and my above comment on how to do international user entered terms would be a good step.

      Of course I’m no Core Developer big wig so I might’ve overlooked something but it’s at least worth mentioning in case the idea had been overlooked or I overlooked a way of doing it.

    • Marcus 12:46 pm on July 30, 2013 Permalink | Log in to Reply

      this will be awesome!

    • Ben Huson 7:11 pm on July 29, 2013 Permalink | Log in to Reply

      Nice to see this on the roadmap – even if we should “not expect this to happen at all” :)

    • Michael Dance 5:00 pm on July 29, 2013 Permalink | Log in to Reply

      This sounds like a really, really sharp approach. Great job so far.

      As a heavy Posts 2 Posts user, I just want to mention that post relationships have pretty much eliminated my need for term meta.

      As a simple example: say you have a Journal Article post type and a Journal Issue taxonomy. Each term is a different journal issue, but for each one you’d want an image, a masthead — more than a term can provide. So that’s where term meta could help.

      But: with post relationships, you can just make Journals a post type and relate each journal to a bunch of articles that way. Suddenly journals have access to post meta, featured images, the works.

      I’m not saying I don’t want term meta at all, but there is a danger that it could open the door to terms and taxonomies being used way beyond the scope of what they’re meant to do and muddy the lines between term and post. And while post relationships can cover most of the use cases of term meta (if I’m wrong on this, I’d love to see some examples), the opposite is definitely not true, so to me, post relationships are the bigger priority.

      (All that said, I know that this is a long way off, and in the meantime I’m just as excited about getting rid of the shared term abstraction and creating WP_Term.)

    • Frank Bültge 10:04 am on July 29, 2013 Permalink | Log in to Reply

      @Nacin Thanks for the status. This are very nice news.

    • sboisvert 4:14 am on July 29, 2013 Permalink | Log in to Reply

      I’ve thought about this. And I’m happy smarter people have also thought about it and now have a good plan to fix it :)

    • Matt Van Andel 11:33 pm on July 28, 2013 Permalink | Log in to Reply

      Finally! These are all things that have driven me crazy for as long as I’ve been developing for WordPress.

      But over at *least* 5 major versions? Ugh. Post 2 Post is a decent bandaid, but that’s functionality that we need in core as of yesterday. What is the reasoning for spacing out the rollout that much? Is it just to minimize potentially breaking changes? Are there ways we can accelerate the process?

      • Japh 11:36 pm on July 28, 2013 Permalink | Log in to Reply

        If you have a listen to Matt’s State of the Word talk, you’ll note that the plan is to speed up update and release cycles generally. So this could happen over a shorter period of time than you might think, despite being over a number of cycles.

        In fact, I imagine it’s this type of thing that’s part of the reasoning behind speeding up the cycles: bigger changes can happen faster.

      • Andrew Nacin 10:43 am on July 29, 2013 Permalink | Log in to Reply

        As the post tried to carefully outline, this requires a significant number of schema, API, and architecture changes. Database upgrades can be very painful, especially with the very real potential of significant amounts of data to modify and migrate here — we need to make sure that we don’t try to bite off too much each release.

        There’s nothing wrong with Posts 2 Posts being in a plugin. You’ll note this post doesn’t actually promise post relationships — it’s entirely possible we leave it out of core for the long term. I’m not saying it’s likely, but my point is that not only is there not a way to accelerate this process, but that there isn’t a need for it either.

        • Taras Mankovski 5:28 pm on July 29, 2013 Permalink | Log in to Reply

          > There’s nothing wrong with Posts 2 Posts being in a plugin.

          This reads like a Jedi mind trick: “You don’t need this… Go back to work.”

          “I don’t need this… I’ll go back to work”

    • portfola 8:43 pm on July 28, 2013 Permalink | Log in to Reply

      This is a welcome development, thank you!

    • Stephanie Leary 8:09 pm on July 28, 2013 Permalink | Log in to Reply

      I will now find @nacin and give him a hug.


    • Robert Chapin 4:29 pm on July 28, 2013 Permalink | Log in to Reply

      Excellent direction.

    • Mike 2:47 pm on July 28, 2013 Permalink | Log in to Reply

      Does this mean I won’t be able to use one taxonomy term with two different taxonomies?
      Because I thought that was the perfect bug –>>feature scenario.

      • Matt Van Andel 11:57 pm on July 28, 2013 Permalink | Log in to Reply

        This wouldn’t affect that at all. Currently, taxonomy terms are an overly-normalized nightmare. If you create a Category called “Foo” and a Tag called “Foo”, only one term is added to wp_terms and then it is associated with the taxonomy in wp_term_taxonomy. The weird thing about this is that there is only entry in wp_term_taxonomy for each term, even though the normalized terms are listed in wp_terms. It is, frankly, really stupid… but as @Nacin said, hindsight is 20/20.

        What is being proposed is that those two tables are merged. You could still have identical terms in multiple taxonomies – but how they are identified in the database and by the API would change to something a little more sane.

        • Mike Schinkel 5:39 pm on July 29, 2013 Permalink | Log in to Reply

          taxonomy terms are an overly-normalized nightmare.

          Actually, if it had been normalized it would likely be much less of a nightmare. As-is the current schema causes E. F. Codd to turn over in his grave.

    • Charles Frees-Melvin 2:25 pm on July 28, 2013 Permalink | Log in to Reply

      What if there was a single meta table and a meta_type filed that has “posts”, “comments”, “users” in it. It would make meta more versatile to extend to taxonomies once taxonomies are ready for it. Kind of like we did to categories and link categories when we came up with the terms/taxonomies system.

    • aristath 12:30 pm on July 28, 2013 Permalink | Log in to Reply

      This conversation brings in mind what happened on Drupal 6 when it became Drupal 7. I know Drupal and WordPress are 2 completely different things, but bare with me.

      On Drupal 6, there were taxonomies and nodes. Something similar to out terms and posts… And the database structure was also similar to what we have now.
      On Drupal 7 however, they decided to make some radical changes. There were no longer nodes and taxonomies, everything was an “entity”. The database structure was significantly simplified and allowed it to move forward as a CMS.
      Ideally this is the direction I would love to see on WordPress… and this sounds like a first step to that direction.

      The proposed solutions are both viable, though I find the 2nd one more compelling.

      • Andrew Nacin 8:15 am on July 29, 2013 Permalink | Log in to Reply

        Yeah, we’re aware of this. It’s certainly something to at least think about. But I don’t think a generic “entity” makes sense for us.

        I’ll share that, according to folklore, the current taxonomy schema was actually inspired by Drupal’s own schema. And we know how that went. :-)

    • Mike Little 11:24 am on July 28, 2013 Permalink | Log in to Reply

      For those who need to work now with the idea of Term/Taxonomy metadata, there are some plugins already out there. I have successfully used “Taxonomy Metadata” (https://wordpress.org/plugins/taxonomy-metadata/) in a project; also “Meta for taxonomies” (https://wordpress.org/plugins/meta-for-taxonomies/) looks interesting.

      A question: the current system (sort of) supports synonyms/aliases for terms, which can be very useful: are there plans to retain this functionality?

      • Andrew Nacin 8:13 am on July 29, 2013 Permalink | Log in to Reply

        I’ve almost never seen it used, but no plans to remove that functionality. This should continue to work just fine. Worth pointing out that any shared terms will be split which could possibly break aliases. Something to keep in mind.

      • Rahe 8:03 am on July 29, 2013 Permalink | Log in to Reply

        Meta for taxonomies is perfect, it uses the WordPress meta API and is only an API ( like the WordPress post_meta ).
        I use it very often, the only problem is there is no easy way like the posts meta box to display/edit the meta in the admin.

    • Julien 10:13 am on July 28, 2013 Permalink | Log in to Reply

      Great news! The future is bright with WordPress. This will open up everything and Worpress will be seriously taken as à tool for web application! Can’t wait to see this released for Wp 3.9 (kidding;))

    • Hassan 9:42 am on July 28, 2013 Permalink | Log in to Reply

      For the past two weeks or so I was always thinking about taxonomy meta, whether WordPress will ever support it or should I just go with workarounds (e.g. wp_options). Then all of a sudden @nacin wrote this post! Yay!

      Even though it’s not here yet (hey come soon already!), I’m already planning for some projects! (Yeah, I read the disclaimer :))

    • Avryl 8:29 am on July 28, 2013 Permalink | Log in to Reply

      Awesome! 😀

    • rfair404 7:01 am on July 28, 2013 Permalink | Log in to Reply

      Both are great ideas. I want to play.

    • Shane Pearlman 5:51 am on July 28, 2013 Permalink | Log in to Reply

      + yay

    • Mike Schinkel 5:22 am on July 28, 2013 Permalink | Log in to Reply


    • Grant Palin 5:14 am on July 28, 2013 Permalink | Log in to Reply

      The two terms tables have puzzled me for a while. Now I see it is due to the way core is set up. So it’s interesting that you are looking at correcting the core setup and simplifying things a bit. WP_Terms sounds good, and will help improve the image that WordPress has among some coders as being poorly coded. And not least, the possibility of having content type or term relationships in core would be excellent, and further the ability of WP to be a CMS out of the box.

    • Manny Fleurmond 4:52 am on July 28, 2013 Permalink | Log in to Reply

      Keeping an eye out for developments. The things that could be possible with connecting posts, terms, users, etc in all types of relationships (one to one, one to many, many to many) is mind boggling. This would definitely help plugins like bbPress and cause an awesome boom of innovation in the WP plugin development community. I wait and watch with baited breath.

    • Scott Kingsley Clark 4:06 am on July 28, 2013 Permalink | Log in to Reply

      Excited about all the above, will watch like a hawk at how things go and be available to test and implement changes in my own projects!

    • Jon Brown 2:44 am on July 28, 2013 Permalink | Log in to Reply

      Will this happen for 3.7? j/king… I read every beautiful word of this post including the disclaimer. This all sounds brilliant. TaxID/TermID confused the heck out of me for a LONG time as a new to WP developer.

    • Scott Taylor 2:39 am on July 28, 2013 Permalink | Log in to Reply

      `WP_Term` should happen as soon as possible. Proper modeling, fix caching, etc

      • Andrew Nacin 6:26 am on July 29, 2013 Permalink | Log in to Reply

        Yes, but ideally we wait until we have a single ID to pass around. It really needs to be term_taxonomy_id, but we don’t pass it around anywhere else in the UI.

  • Jen 4:50 pm on December 24, 2012 Permalink

    Team Reps 

    Heya. Now that we know Mark will be the release lead for 3.6, on with team rep voting results. :)
    Part of why I wanted to wait was because the people with the most votes were Nacin and Jaquith, and I suspected Jaquith would be leading 3.6 (so he shouldn’t be team rep also, per earlier discussions).

    Core team reps: @nacin and @scribu. Woohoo!

    Term begins with the new year and goes through June.

  • Andrew Nacin 11:08 pm on August 29, 2012 Permalink
    Tags: ,   

    Minified versus development scripts and .min.js 

    For some time (since r10291), WordPress has shipped minified scripts and styles as .js and .css, with the non-minified, “development” versions at .dev.js and .dev.css.

    These weren’t great for discoverability and it has become clear that these are non-standard. So, we’ve moved to using .min.js and .min.css for minified files. You can now find the “development” versions at .js and .css. This also works nicely with tools like ack, which are coded to ignore .min.js.

    This was implemented in #21633. Now if only we can get TinyMCE to move away from _src.js. :-)

    A note, for some external libraries, we don’t include the un-minified versions. In this case, you can find them on their respective websites and also in the sources repository. (This is linked from wordpress.org, which in turn is referenced at the bottom of our license file.) @scribu and I were talking about writing a developer plugin to use un-minified versions of these libraries, which would be cool.

    More on external libraries in 3.5 here.

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