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


    • 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


    • 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


    • 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


    • 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


    • 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


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


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


    • 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



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


    • 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


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


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


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


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


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


    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!

  • 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 …)

  • Boone Gorges 6:30 pm on September 22, 2015 Permalink
    Tags: , ,   

    Preparing your plugins and your client sites for termmeta 

    The biggest hurdle in the introduction of metadata for taxonomy terms (#10142) is compatibility with existing plugins and customizations. In this post, I’ll outline the most significant concerns, along with recommendations for next steps.

    This post has two audiences: authors of publicly available plugins and developers of client sites.

    I’ve just completed a scan of all the plugins on wordpress.org that mention ‘termmeta’ or ‘term_meta’ (and boy, are my arms tired!). The numbers there are promising – it’s a fairly small number of plugins that will be affected, and many of them have just a few active installations. I’ll share the results of my scan at the end of this post.

    Of greater concern are customizations that developers have built for clients. I know that many larger dev agencies, and many individual developers, have custom, in-house libraries that they use for client sites, and many of these libraries implement termmeta in one way or another. The best of these libraries will be unaffected by termmeta in core: they use prefixed functions, they store data in wp_options rather than a custom table, they use function_exists() where appropriate, and so on. However, I’m certain that there are many libraries – in use on many, many WordPress sites – that do not adhere to these best practices. Sites using these libraries will react in unexpected ways – some of which involve fatal errors – if preventative steps are not taken by the developers before termmeta is rolled into core. Developers should update their libraries and client deployments as necessary to avoid lost data or site downtime.

    The primary reasons for concern, listed in order of severity, are as follows:

    1. Function name clashes. The proposed core implementation introduces a number of new functions likely to be used in third-party termmeta implementations: add_term_meta(), delete_term_meta(), get_term_meta(), update_term_meta(), and update_termmeta_cache(). (See the latest patches on the Trac ticket for details.) Plugin should either use a prefix (eg myplugin_add_term_meta()), wrap the definitions in function_exists() checks, or disable the termmeta portion of the plugin based on a WP version check.
    2. Termmeta table deletion. A number of plugins have been found that DROP $wpdb->termmeta on plugin deactivation. Aside from being bad general practice, this could be extremely bad in the case that $wpdb->termmeta becomes a core table. Plugins should not drop {$wpdb->prefix}termmeta under any circumstances.
    3. Non-matching function signatures. I haven’t found any specific examples of this, but plugins that define their own versions of unprefixed functions (using function_exists(), as described above, should be sure that the signatures match. For example, if your plugin defines get_term_meta( $term_id, $taxonomy, $key = '', $single = false ), it will break when moving to the core implementation, which has the signature get_term_meta( $term_id, $key = '', $single = false ). Plugin authors should double-check that their use of unprefixed _term_meta() functions matches the parameter order and default values described in the proposed core implementation.
    4. Non-matching table schemas. A number of plugins create tables called {$wpdb->prefix}termmeta. Most custom tables that I’ve seen are very close to the proposed core implementation, aside from a shortened index length on the meta_key column, introduced throughout core in 4.2. In fact, all implementations I’ve seen are close enough that it’s likely that core will be able to continue to use the tables, leaving data intact. However, if there are significant mismatches – for example, different field names – it will cause serious problems. Plugin author should verify that tables called {$wpdb->prefix}termmeta have a compatible schema with the core implementation.

    Here’s a list of the plugins I identified from wordpress.org that will be affected by core termmeta (sorted most popular first). All of these plugins violate at least one of the maxims above. A few of them are OK except for a mismatched meta_key index the termmeta table; the current plan is for core to take care of this index automatically on upgrade. Most of the remaining violations have to do with unprefixed function names. If your plugin is listed below, you are strongly urged to put out an update as soon as possible that addresses the concerns described above. (Some of the plugins are very old, and may be inactive and/or unmaintained. In most cases, they should still be updated, in case of legacy sites.) Don’t hesitate to contact me, in the comments or privately, if you need more details about how a specific plugin in the list below will be affected.

    It’s looking likely that termmeta will be introduced in WordPress 4.4 (or perhaps 4.5). The time to act is now. Be a good Citizen of the Internet, and fix your plugins sur-le-champ.

    • rahul286 6:37 pm on September 22, 2015 Permalink | Log in to Reply

      Thanks for list. Our rtBiz plugin is on the list but we already started preparation after reading – https://make.wordpress.org/core/2015/09/04/taxonomy-term-metadata-proposal/

      We will be ready before WordPress 4.4. 🙂

    • Boxy Studio 6:39 pm on September 22, 2015 Permalink | Log in to Reply

      Thanks for rounding up the list. I’m releasing an update today to get Resume Builder ready for 4.4. Appreciate the heads up!

    • mitcho (Michael Yoshitaka Erlewine) 6:46 pm on September 22, 2015 Permalink | Log in to Reply

      Thanks Boone! Put this on my to-do list. I might appreciate some help testing later, by you or others who have a good understanding of the current Core proposal.

      Two quick questions:
      1. What’s the right way to check for the new termmeta support? Check whether $wpdb->termmeta is set? Or check for one of the functions? Or a particular db schema version?
      2. My plugin creates a taxonomymeta table, rather than a termmeta. I worry about users upgrading to WP 4.4 and then having their term metadata suddenly disappear. On the other hand, I worry about writing a migrator that detects the introduction of termmeta and migrates the data over from taxonomymeta… just feels like a dangerous place where bugs could be introduced. Thoughts?

      Thanks! Glad this is making its way into Core.

      • Boone Gorges 7:01 pm on September 22, 2015 Permalink | Log in to Reply

        Hi Mitcho – Thanks for your quick response! I’m happy to take a look or do some testing at any time.

        Re checking for termmeta support: For functions, the easiest thing to do is wrap each individual function in if ( function_exists() ). $wpdb->termmeta is a bit flimsy as a check, and db schema versions don’t always line up with WP versions (for example, DB upgrades are delayed on Multisite).

        For existing data, I would definitely recommend migration – as you note, it’d be quite jarring for users not to have it. The most lightweight way to do it is probably something like this: on ‘admin_init’, run a routine that moves the data over in a single SQL query, if possible (I can’t remember off the top of my head whether your data will need translation due to term_taxonomy_id or anything like that). Then set a flag – something like update_option( 'mitcho_taxonomymeta_core_migration_complete', 1 ) that prevents the migration from running more than once.

        Again, I’m happy to help with testing or review at any point in the process. Thanks again!

    • Zack Tollman 7:13 pm on September 22, 2015 Permalink | Log in to Reply

      @boonebgorges I’d like to kill Custom Taxonomy Sort. Is that being a good citizen, or just a lazy citizen?

    • Steve Bruner 8:10 pm on September 22, 2015 Permalink | Log in to Reply

      @boonebgorges — Thank you for putting this list together. Just pushed Piklist v0.9.4.29 which will no longer drop {$wpdb->prefix}termmeta on uninstall: https://wordpress.org/plugins/piklist/

    • Spacedmonkey 8:54 pm on September 22, 2015 Permalink | Log in to Reply

    • tifosi 2:55 pm on November 6, 2015 Permalink | Log in to Reply

      Is there a link to a proposed schema for termmeta? I’m assuming that it’s going to be pretty close to postmeta, which many will have used – myself included as a template.

      It’s the only point from 4 that has potential issues with my own CPT framework. The new functions map my own class encapsulated versions, so all good.

      It’ll be nice to finally pull this skeleton out of the closet and give it the burial it deserves! 🙂 RIP #10142


    • Peter Elmered 10:13 am on November 16, 2015 Permalink | Log in to Reply

      Great post @boonebgorges !
      Just out of curiosity, how did you find the plugins that violates these best practices? It would be nice to be able to make that kind of searches to check for compatibility issues.

      • Boone Gorges 4:49 pm on November 16, 2015 Permalink | Log in to Reply

        Thanks @pekz0r – I have a local copy of the wordpress.org plugin repository (using a tool like https://github.com/Rarst/WordPress-Plugin-Directory-Slurper). In the current case, I simply grepped the strings `termmeta` and `term_meta`, with the idea that I’d catch both (a) function name collisions, and (b) custom tables. I probably matched 100-150 plugins. Then I did a few kinds of manual scans to check whether there were actual conflicts. It was pretty labor-intensive. Some sorts of searches could be a bit more automated, but this one required lots of manual looking-at-code.

    • Pedro Carvalho 10:14 pm on November 22, 2015 Permalink | Log in to Reply

      thanks @boonebgorges for the very complete breakdown of the implementation.

      your implementation is very close to ours, but has cache and lazy loading! i believe our only change is to not drop the database on installant. i’ve tested with 4.4-beta4-35719, and it seems to work perfectly!

    • psn 6:25 am on December 18, 2015 Permalink | Log in to Reply

      Hi Boone, we are using one of the listed plugin Page Security and Membership. As I don’t have enough knowledge around term metadata and if this plugin will totally break, can you check if this is one of the plugin that is OK to work with WP 4.4?

      I have asked author if any update will come but no response so far.


      • Boone Gorges 8:01 pm on December 18, 2015 Permalink | Log in to Reply

        @psn It looks like this particular plugin will not “totally break” – there’s just a mismatch in some column indexes related to the wp_termmeta table. It’s highly likely that you’ll be able to upgrade to 4.4 smoothly even without an update from the plugin author, though I urge you to test it first in a development environment.

        • psn 6:58 am on December 19, 2015 Permalink | Log in to Reply

          Hi, Have now tested and its working as it should and even better as the duplicates of indexes seems even created some issues before which I don’t see any longer so BIG thxs to you!!

    • psn 6:38 am on December 19, 2015 Permalink | Log in to Reply

      Thxs @Bonne Gorges, I have checked this tables indexes and you’re right it was some duplicates so I have removed these and only saved the primary for meta_id. Will now test WP version 4.4 asap.

  • 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 …)

  • Jeremy Felt 4:47 pm on June 24, 2015 Permalink

    Multisite Office Hours Recap (June 23, 2015) 

    Multisite office hours are held every Tuesday at 20:00 UTC in #core-multisite.

    Today’s chat log
    Overall 4.3 Release Objectives

    Last week’s (and this week’s) objectives:

    • More flow, more tickets, more observations to aid with Network Admin UI improvement.
    • Get a good patch up for #31240, possible commit.
    • Ongoing iterations, progress, discussion on `WP_Network` and `WP_Site` (and friends).
    • Write post, generate discussion around HTTPS in multisite for real (lower priority).

    It was a super light weight week for multisite, so not much progress. There was some traffic on existing tickets, but not much new activity. Summer lull… 🌞

    @hugobaeta gathered a few UI/UX tickets for WCEU contributor day – #32525, #32645, and #32647. We also have the general Admin UI screen sweep spreadsheet. Another ticket in that vein via @johnjamesjacoby is #32754, which is a string change but goes along with UX.

    If anyone has other UI/UX tickets, please make note. I’ll be poking around on Saturday. For anyone attending WCEU contributor day, a server with multisite is available for you to test on. I’ll hook some others up with super admin access beforehand.

  • Jeremy Felt 10:07 pm on June 9, 2015 Permalink

    Multisite Office Hours Recap (June 9, 2015) 

    Multisite office hours are held every Tuesday at 20:00 UTC in #core-multisite.

    Today’s chat log
    Overall 4.3 Release Objectives

    Last week’s objectives:

    • Have all 3 of these tickets closed and committed. #22383, #32434, #32503
    • Additional iterations on `WP_Network` and `WP_Network_Query`.
    • Generate discussion around HTTPS on #14172. @jeremyfelt will gather a list of HTTPS related tickets.
    • Nexus and iPad flows. Tickets created for bugs found in existing flows. Volunteers needed! 🙂

    Today’s meeting agenda:

    • Status on additional flows/visual records and next steps toward ticket creation.
    • New thoughts/discussion on `WP_Network`, `WP_Site` and friends?
    • Status of #22383, #32434, and #32503
    • Open floor for tickets, thoughts, etc…

    Topic Details:

    Status on additional flows/visual records. Next steps toward ticket creation.

    chat log

    We have new flows captured. @kraftbj posted the Nexus 6 results and @earnjam will be posting iPad shots within the next couple days. @topdown volunteered to capture screens for Samsung Note 8 and possibly other devices as well.

    To date, our device list includes: Nexus 6, iPhone 5s, iPhone 6, and Desktop, with additional screens specific to network upgrade.

    We posted some info late last week on how someone could help test and capture the network admin UI. Test installations of multisite are available for anyone to use if you have a device but just have no way of accessing a multisite installation. Please leave a comment on the post or in #core-multisite if you’d like to get started.

    As we create tickets and find bugs, we need to populate this spreadsheet as part of the overall screen sweep effort.

    Objective for next week: New tickets to address found issues. These issues logged in the screen sweep spreadsheet.

    New thoughts/discussion on `WP_Network`, `WP_Site`, and friends?

    Tickets: #31985, #32450, #32504, #31148
    chat log

    Not much discussion here. @johnjamesjacoby is going to have iterations of `WP_Site` and `WP_Network` this week. We should have a chat in #core-multisite soon after.

    Objective for next week: Iterations on `WP_Site` and `WP_Network`. Discussion around iterations.

    Status of #22383, #32434, and #32503

    Tickets: #22383, #32434, #32503
    chat log

    Objective for next week: Let’s cross our fingers that these are closed by tomorrow.

    Other items:

    Tickets: #14172, #32602
    chat log

    • @jeremyfelt still needs to generate discussion around HTTPS for #14172
    • @ipstenu found an issue with the plugin details modal when viewing plugin details on a sub site that has a different domain/scheme from the network admin. The switch to `network_admin_url()` that causes this came in #17902. A new ticket #32602 is open.

    Thanks everyone!

  • Jeremy Felt 6:08 am on June 3, 2015 Permalink

    Multisite Office Hours Recap (June 2, 2015) 

    Multisite office hours are held every Tuesday at 20:00 UTC in #core-multisite.

    Today’s chat log

    Overall 4.3 Release Objectives

    Last week’s objectives for dev chat:

    • Wrap-up #22383, #32434, and #32503 and then take a look at the add site flow and validation in `update_blog_details()`.
    • Continued progress on `WP_Network`, `WP_Site`, `WP_Network_Query`, and `WP_Site_Query`.
    • More thoughts on tracking scheme in `wp_blogs` for sites. #14172
    • More flows and network admin UI tickets from those flows.

    Today’s meeting agenda:

    • Status of #22383, #32434, and #32503
    • Status of `WP_Network` #31985, `WP_Site` #32450, `WP_Network_Query` #32504, and `WP_Site_Query` (likely #31148)
    • Tracking scheme for a site in `wp_blogs` is still looking for feedback, owner, etc.. #14172
    • More flows and network admin UI tickets from those flows.

    Topic Details:

    Arbitrary domain/path combinations in edit site:

    Tickets: #22383, #32434, #32503
    chat log

    • #32503, removing the home/siteurl mirror checkbox, is either ready to go in or very close. @jeremyfelt will take a closer look for commit.
    • #22383 is close, though the latest patch tracks scheme, domain, and path. We can leave scheme out for another ticket in the future. @earnjam is going to take another look, @jeremyfelt will also take a look for commit.
    • We talked through #32434 and decided to try using a URL (combined domain/path) column and converting the users column to a total count rather than a list of the first 5 users. @ocean90 is working on this.

    Objective for next week: Have all 3 of these tickets closed and committed.

    Progress on `WP_Network`, `WP_Site`, `WP_Network_Query`, and `WP_Site_Query`:

    Tickets: #31985, #32450, #32504, #31148
    chat log

    We chatted through the approach we’re using with `WP_Network` and `WP_Network_Query`. @johnjamesjacoby built the first patch by pulling most current network related code into the `WP_Network` class with the intent to break pieces out into `WP_Network_Query` once we have more of a handle on things. @jacobsantos had some good feedback on possible design approaches as he’s seen some common looking patterns/properties in `WP_Widget` and `WP_Customizer`.

    Objective for next week: Additional iterations on `WP_Network` and `WP_Network_Query`.

    Tracking scheme for a site in `wp_blogs`:

    Tickets: #14172
    chat log

    @johnjamesjacoby had some good concerns about possible approaches with tracking scheme. We’d like to generate a larger conversation around this topic. A few specific questions are:

    • Things that the current code prevents or prohibits. Or what does/doesn’t work in core now.
    • Exactly how capable do we want this to be.
    • Does the oncoming “TLS everywhere” of HTTP/2 change this discussion?
    • What concerns are there around introducing a new field on `wp_blogs`. How are large networks affected?

    Please leave any thoughts in the comments here or directly on the ticket.

    Objective for next week: Generate discussion. @jeremyfelt will gather a list of HTTPS related tickets.

    Network Admin UI flows for Make/Flow:

    chat log

    @ubernaut added many iPhone 5s flows, so we’re up to a handful now. @kraftbj is going to do Nexus flows and @earnjam is going to handle iPad.

    Objective for next week: Nexus and iPad flows. Tickets created for bugs found in existing flows. Volunteers needed! 🙂

    Thanks everyone!

  • Jeremy Felt 3:33 am on May 27, 2015 Permalink

    Multisite Office Hours Recap (May 26, 2015) 

    Multisite office hours are held every Tuesday at 20:00 UTC in #core-multisite.

    Today’s chat log

    Overall 4.3 Release Objectives

    Last week’s objectives for dev chat:

    • Continued work on mock-ups, discussion around edit site and add site flows.
    • Android and iPad flows posted to Make/Flow.
    • Conversation around and updated `WP_Network` patch and a first attempt at `WP_Site`.

    Today’s meeting agenda:

    • Arbitrary domain/path combinations. #22383 (and now #32434)
    • `WP_Network` #31985 and `WP_Site` #32450
    • Thoughts on how to track scheme for a site. #14172
    • More flows (and tickets) needed. 🙂

    Topic Details:

    Arbitrary domain/path combinations in edit site:

    • Tickets: #22383, #32434, #32503
    • chat log
    • @hugubaeta explored things some more and left some good feedback on #22383. We agreed to push ahead with the single entry for scheme, domain, and path in #22383.
    • During that discussion, we started to address the question of the checkbox for updating home and siturl. This resulted in #32503. After some further discussion there, we’re going to try removing that checkbox entirely and using some logic to determine when to update home and siturl. @earnjam is working on the patch for this.
    • @ocean90 is working on updating a patch for #32434 after discussion there and in #22383.

    Progress on `WP_Network` and `WP_Site`:

    • Tickets: #31985, #32450
    • chat log
    • second chat log
    • Initial brief conversation. @earnjam is going to take a closer look at the existing patches. We need to start brainstorming where `WP_Network_Query` starts.
    • Continued this conversation with @johnjamesjacoby later in the day. He’ll be working on the patches a bit more this weekend as well.
    • #25293 was brought up to consider so that the correct network ID is available after `switch_to_blog`. Also #14867 to ensure the correct scheme is attached to the site object.

    Thoughts on how to track scheme for a site:

    • Tickets: #14172
    • chat log
    • @johnbillion agreed that `wp_blogs` seemed like the right place to track scheme. We’ll need to worry some about the upgrade process, though larger networks should be able to handle something like this.
    • Some more discussion on the ticket would be great. We should get a patch going sooner than later. This is up for grabs, claim it in the comments! 🙂

    More flows for Make/Flow:

    • chat log
    • @ubernaut is almost done with iPhone 5s videos.
    • @johnbillion mentioned trying some recordings with Android.
    • @jeremyfelt is still claiming that he’ll do an iPad capture one night.
    • We need to get more of these up on Make/Flow to capture a good visual record. As they go up, please create tickets for things that look off. Even if you haven’t posted a flow of your own, please browse through the existing ones and look for issues.

    Thanks to everyone in office hours today! Chime in with any comments, tickets, etc… or join us in #core-multisite. 🙂

  • Jeremy Felt 9:28 pm on May 19, 2015 Permalink

    Multisite Office Hours Recap (May 19, 2015) 

    Multisite office hours are held every Tuesday at 20:00 UTC in #core-multisite.

    Overall 4.3 Release Objectives

    Last week’s objectives:

    • Mockups for the Edit Site / Add New Site improvements. [log] @hugobaeta has started working with this and we had a good conversation today to help fill in some of the blanks and give more to chew on. See the summary below of the issue.
    • Have more flows posted to Make Flow for the network admin. [log]
    • Get some decent progress on `WP_Site` and `WP_Network` #31985. [log] – I poked at @johnjamesjacoby‘s patch for `WP_Network()` and reduced it down to the bare essentials. We can start building this up and figuring out what pieces belong in `WP_Network_Query()`. Hoping to start work on `WP_Site()` shortly as well.

    Summing up the Edit Site / Add Site UI/UX issue:

    We’ve always had two configurations for a network in multisite: subdomain or subdirectory.

    Subdirectory is the easiest to handle as the domain will always be the same, inherited from the network. Only the path can change from site to site. Not only is this a UI decision in the Edit Site and Add Site screens, it is how ms-settings.php parses the requested URL when a subdirectory configuration is used.

    In the changes we make to the Edit Site #22383 and Add Site #31240 screens, we’ll still want to account for subdirectory configurations and make it as easy as possible for somebody to choose a path without worrying about scheme or domain.

    Subdomain seems similar, but ends up being very different. At first glance, only the domain can change from site to site, with the path always set to “/”. This is the case in the current Add Site screen. In the current Edit Site screen, you can change the full domain and the path to anything you’d like. Super admins have been able to use this to get around the strict UI requirements for subdomain configuration in Add Site. In ms-settings.php, the code cares less. We search the database for a matching domain and path, which effectively allows for arbitrary domains and paths—a good replacement for domain mapping.

    In the changes we make to the Edit Site and Add Site screens, we should make this as flexible as possible. The name of the configuration “Subdomain” will be weird, but it should be possible to enter any combination. Ideally we can confirm that this combination works before completing a save.

    Thanks to everyone in office hours today! Chime in with any comments, tickets, etc… or join us in #core-multisite. 🙂

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