WordPress.org

Make WordPress Core

Tagged: multisite Toggle Comment Threads | Keyboard Shortcuts

  • Felix Arntz 12:23 pm on September 21, 2016 Permalink |
    Tags: , , multisite   

    Upcoming Multisite Bug Scrubs 

    After the initial multisite bug scrub in the 4.7 release cycle last week, we will continue going through the list of bug tickets this week on Thursday 20:00 UTC, in #core-multisite as usual. The respective report was about bug tickets with the multisite focus that were opened within the last year. We have 8 tickets to go for that report, so we should be able to finish it this week.

    After that, we will continue having regular multisite bug scrubs that are held every Thursday at 20:00 UTC, then focussing on multisite tickets milestoned for the 4.7 release.

    If you aren’t available during the weekly multisite bug scrubs, feel free to leave a comment here or in #core-multisite if you have other tickets you’d like to see covered.

    See you then!

     
  • Jeremy Felt 10:15 pm on July 8, 2016 Permalink |
    Tags: , , multisite,   

    Multisite Focused Changes in 4.6 

    The 4.6 release cycle has been a productive one! Several major and a few minor updates are described in detail below. If you’d like even more detail, here is a full list of multisite focused changes for 4.6.

    Introduce WP_Site_Query and WP_Network_Query

    WordPress 4.6 introduces WP_Site_Query and WP_Network_Query as well as their companion functions, get_sites() and get_networks().

    WP_Site_Query

    With WP_Site_Query (or get_sites()), sites can now be queried from the $wpdb->blogs table in a flexible way by id, domain, path, and more. For a full list of supported arguments, see the documentation attached to the __construct() method.

    New filters and actions associated with this change include parse_site_query, pre_get_sites, the_sites, site_search_columns, sites_clauses, and found_sites_query.

    Query results are cached as part of the global sites group. This will provide a performance boost for sites using a persistent object cache.

    The introduction of this class helped resolve several long standing issues with WP_MS_Sites_List_Table. Expect to see a faster and more relevant search when browsing through a network’s sites. See #36675.

    For the background discussion around these changes, see #35791.

    WP_Network_Query

    With WP_Network_Query (or get_networks()), networks can now be queried from the $wpdb->site table by id, domain, and path. Query results are cached as part of the global networks group. For a full list of supported arguments, see the documentation attached to the __construct() method.

    WordPress core does not provide a UI for managing multiple networks, but any sites using a plugin to do this will start to see a benefit from having this available.

    New filters and actions associated with this change include parse_network_query, pre_get_networks, the_networks, networks_clauses, and found_networks_query.

    For the background discussion around these changes, see #32504.

    Enhancements to WP_Site and WP_Network

    New utility methods

    New functions get_site() and get_network() have been introduced to retrieve a specific site or network respectively. They both accept either an ID, database object or class instance as the first parameter. If that parameter is omitted, the current site / network is returned.

    Property changes on WP_Site and WP_Network

    The WP_Site and WP_Network objects now support access to their respective ID properties through property names which match current naming conventions. Furthermore, by accessing the properties with the new names, it is ensured that these are returned as integers rather than strings. The old properties are still accessible and valid, but these changes should encourage developers to use the new property names.

    The following is the list of property improvements:

    • $site->id is the site’s ID. (previously $site->blog_id)
    • $site->network_id is the site’s parent network ID. (previously $site->site_id)
    • $network->id is now an integer instead of a string.
    • $network->site_id is the network’s main site ID. (previously $network->blog_id)

    For background discussion around these changes, see #36717 and #37050.

    Lazy-loading extended properties

    Additional properties of a site object normally accessed with get_blog_details() are now automatically lazy-loaded when requested. This allows developers to use get_site() as a replacement for get_blog_details() which is likely to be deprecated in a future release. See #36935.

    New Actions and Filters

    Several new actions and filters were added as part of the WP_Site_Query and WP_Network_Query changes. Here are some others of note:

    • ms_loaded fires at the end of the multisite bootstrap process in ms-settings.php. At this point the current site and network are available in the global scope. See #37235.
    • pre_get_blogs_of_user allows developers to alter or short-circuit the results of get_blogs_of_user(), which can be an expensive function to run on configurations with many users. See #36707.
    • clean_site_cache fires after cache has been cleared with clear_blog_cache(). This can be useful for clearing any custom cache keys associated with a site record. See #36203.
    • network_edit_site_nav_links filters the list of links displayed at the top of Edit Site views as a “tabbed” interface. See #15800.
    • ms_sites_list_table_query_args filters the arguments passed to WP_Site_Query when building the MS Sites List Table. See #26580.

    Other enhancements of note

    Introduce get_current_network_id() as a helper function to find the current network’s ID. See #33900.

    The MULTISITE and SUBDOMAIN_INSTALL constants can now be overridden in a project’s wp-config.php when running unit tests. See #36567.

    Deprecated Functions

    wp_get_sites() has been deprecated and get_sites() should be used instead. Please note when making code changes that get_sites() returns an array of WP_Site objects where wp_get_sites() returned an array of arrays.

    WP Multi Network compatibility

    The introduction of get_networks() in 4.6 conflicts with the function of the same name in WP Multi Network, a plugin commonly used to provide multiple networks on a multisite installation. A fix for this is already in the master branch of the plugin, and will be included in the next release. In the same change, many other functions were wrapped in function_exists() calls to prevent similar conflicts in the future. If you are using WP Multi Network, please be sure to update accordingly.

     
    • David Naber 8:14 am on July 9, 2016 Permalink | Log in to Reply

      wp_get_sites() has been deprecated and get_sites() should be used instead.

      The introduction of get_networks() in 4.6 conflicts with the function of the same name …

      Am I the only one who spots the problem here? Why gets prefixed functions deprecated in favor to use unprefixed ones and even unprefixed functions gets introduced today?

      • Jeremy Felt 8:39 pm on July 9, 2016 Permalink | Log in to Reply

        Thanks David, you aren’t the only one. 🙂 We deliberated on this before going forward. In addition to conversations during the weekly multisite chats, we brought this up for discussion in the weekly core dev chat – https://wordpress.slack.com/archives/core/p1462395264003378.

        In general, it was agreed that for the benefit of developer experience, having `get_site(s)` and `get_network(s)` match the existing experience for posts, users, comments, etc… made sense here.

        We did some due diligence and searched the plugins directory for any usages, knowing in advance that WP Multi Network would conflict. There are no other obvious conflicts and WPMN has been a good example multiple times where a function there makes sense in WordPress core.

        The deprecation of `wp_get_sites()` is a benefit of making this decision as it also broke with developer experience and returned an array of arrays rather than `WP_Site` objects as one would expect. A similar change has happened with `wp_get_network()`, though it has not yet been deprecated.

        • David Naber 4:47 pm on July 10, 2016 Permalink | Log in to Reply

          With «developer experience» you mean the weekend hours to workaround naming collisions when using WordPress together with other code bases, for example?

          Prefixing is something fundamental when not using namespaces. Why not just the other way around and deprecate everything non-prefixed and introduce a prefixed version of it?

          • Ipstenu (Mika Epstein) 9:27 pm on July 10, 2016 Permalink | Log in to Reply

            Currently we enforce plugins hosted on .org to use namespaces or prefixes, to prevent these kinds of issues. When we introduce new functions, we are highly aware of the potential for conflicts. As the ‘parent’ project, WordPress’ use of function prefixes is less of a requirement than for the children of themes and plugins.

            We’ve had as many issues with wp_ or wordpress_ as prefixes, compared to nothing as a prefix. It’s simply the bane of project management when you have an ecosystem this large.

            In general we search for all plugins in the repository and attempt to find any potential conflicts.

    • Martin Stehle 12:11 pm on July 22, 2016 Permalink | Log in to Reply

      Can you please confirm that code will be correct:
      // get registered site IDs
      $site_ids = array();
      if ( version_compare( get_bloginfo( ‘version’ ), ‘4.6.0’, ‘>=’ ) ) {
      $sites = get_sites();
      foreach ( $sites as $site ) {
      $site_ids[] = $site->id;
      }
      } else {
      $sites = wp_get_sites();
      foreach ( $sites as $site ) {
      $site_ids[] = $site[ ‘blog_id’ ];
      }
      }

      Thank you.

      • Felix Arntz 7:01 pm on July 27, 2016 Permalink | Log in to Reply

        Hi Martin, yes that code is correct and works in a backward compatible way. A minor improvement: In the first clause you could use the following code:

        $site_ids = get_sites( array( ‘fields’ => ‘ids’ ) );

        By using that code, you don’t need to query the entire site objects and thus can get rid of the foreach loop. Note that this only works for the first clause (4.6 version).

    • tazo todua 5:13 pm on September 1, 2016 Permalink | Log in to Reply

      get_site() doesnt contains these values, what we should do ?

      `public ‘blogname’ => string ”`
      `public ‘siteurl’ => string ‘http://127.0.0.1/mysub’`
      `public ‘post_count’ => boolean false`
      `public ‘home’ => string ‘http://127.0.0.1/mysub’`

      • Jeremy Felt 5:35 pm on September 1, 2016 Permalink | Log in to Reply

        @tazo todua The `WP_Site` object returned by `get_site()` should lazy load those properties once they are requested.

        • tazo todua 8:39 am on September 2, 2016 Permalink | Log in to Reply

          can you explain what’s lazy-load means? I called `get_site(3)` and it returned the values correclty (like `get_blog_details()`), but the above properties were missing.

          • Jeremy Felt 4:18 pm on September 2, 2016 Permalink | Log in to Reply

            Of course! Sorry for the bad description. 🙂

            If you do something like `$site = get_site( 3 ); var_dump( $site );`, you’ll get a WP_Site object that has default properties, but none of those listed in your first comment. As soon as you request one of those properties, say via `$site->post_count;`, then they will populate.

            This saves some processing until the properties are actually needed.

            • tazo todua 5:16 pm on September 2, 2016 Permalink

              thanks! now i understand.

            • tazo todua 5:18 pm on September 2, 2016 Permalink

              what is the way, to know, what lazy-load properties does any OBJECT has? how to predict what properties may be available?

              (thanks for your answers to my questions, that will be helpful to many others like me).

  • Felix Arntz 9:28 pm on July 6, 2016 Permalink |
    Tags: , multisite,   

    Multisite Office Hours Recap (July 5, 2016) 

    Multisite office hours are held every Tuesday at 16:00 UTC in #core-multisite. The next will be Tuesday 16:00 UTC. A more casual bug scrub is on Thursday 20:00 UTC.

    The weekly agenda for the 4.6 cycle is to (a) address blockers and share status on bigger initiatives, then (b) walk through a few multisite focused tickets on Trac.

    Today’s chat log

    Attendees: @spacedmonkey, @ocean90, @paaljoachim, @richardtape, @flixos90

    Tickets Covered

    • #20537 seems possible, but needs an updated patch. @jrf left a note after office hours that she is going to work on it Friday.
    • #26855 is likely to be punted due to a lack of recent activity. However, @spacedmonkey would like to work on a patch there, so there is still a chance this could land.
    • #18088 has an updated patch by @flixos90 which needs some testing. @spacedmonkey will try to review it.
    • #35379 still lacks a decision which approach to take. Considering there might possibly be major changes in handling network options coming up (see #37181), more time is required to think about the best way to tackle this bug. The ticket got punted to a future release.
    • #37223 is a rather straightforward fix, but will need an updated patch. @flixos90 is going to leave a comment there to ask the author of the patch for an update.
    • #36954 is being reviewed by @jeremyfelt and is likely to be merged.
    • #37102 will, although being a straightforward change, not make it into 4.6 as the first beta has already been released. Furthermore the function get_blog_details() has not been deprecated yet, so the ticket is not necessary to complete at this point.

    Other Notes

    • The 4.6 dev note for the Networks & Sites component should get ready on Wednesday. A Google doc will be used for collaboration.

    If you aren’t available during the weekly multisite office hours, feel free to leave a comment here or in #core-multisite with a ticket number you’d like to see discussed.

    See you next week!

     
  • Jeremy Felt 6:51 pm on June 15, 2016 Permalink |
    Tags: , multisite,   

    Multisite Office Hours Recap (June 14, 2016) 

    Multisite office hours are held every Tuesday at 16:00 UTC in #core-multisite. The next will be Tuesday 16:00 UTC. A more casual bug scrub is on Thursday 20:00 UTC.

    The weekly agenda for the 4.6 cycle is to (a) address blockers and share status on bigger initiatives, then (b) walk through a few multisite focused tickets on Trac.

    Today’s chat log

    Attendees: @flixos90, @spacedmonkey, @jeremyfelt

    Tickets Covered

    • #36675, WP_MS_Sites_List_Table should use WP_Site_Query. This is almost ready and should also close #33185, #24833, and #21837. Soon after an effective patch can be written for #26580. Available search columns in WP_Site_Query will remain as domain and path. Once everything is in, an assessment can be made on the usefulness of searching custom columns on the wp_blogs table.
    • #35791, WP_Site_Query has a patch that will go in before the above so that search columns are available. Most of the functions mentioned in the ticket description have been updated to use get_sites(). New tickets should be created for the replacement elsewhere in core.
    • #36935 implements lazy-loading of site details in WP_Site and will go a long way towards the—possibly silent—deprecation of get_blog_details() in core. It implements a new global cache key (site_details) that will help clear up some of the issues that come with the blog-details cache key. Once this is in, get_blog_details() can be replaced almost everywhere. See #37102 for that progress.
    • #36717 is still in temporary limbo. The private blog_id and site_id properties will likely need to be made public again, but there remains a sliver of hope that this can be worked around inside get_blog_details() for the time being. If it’s still in for beta, it will mostly be for testing.
    • #32504WP_Network_Query still has 2 weeks before beta. A patch and tests are already there, so there’s a high chance it can go in this week.

    If you aren’t available during the weekly multisite office hours, feel free to leave a comment here or in #core-multisite with a ticket number you’d like to see discussed.

    See you next week!

     
  • Jeremy Felt 4:50 pm on June 8, 2016 Permalink |
    Tags: , multisite,   

    Multisite Office Hours Recap (June 7, 2016) 

    Multisite office hours are held every Tuesday at 16:00 UTC in #core-multisite. The next will be Tuesday 16:00 UTC. A more casual bug scrub is on Thursday 20:00 UTC.

    The weekly agenda for the 4.6 cycle is to (a) address blockers and share status on bigger initiatives, then (b) walk through a few multisite focused tickets on Trac.

    Today’s chat log

    Attendees: @iamfriendly, @ipstenu, @spacedmonkey, @flixos90, @paaljoachim, @jeremyfelt

    Tickets Covered

    • #35791, WP_Site_Query, is almost complete. It’s open as a task to help track any issues, but can probably be closed as fixed soon. Specific implementation can be handled in other tickets.
    • #36675, implementing WP_Site_Query in WP_MS_List_Table, is the biggest remaining piece at the moment. Patches are getting closer and will likely solve a handful of tickets when done—#33185, #24833, and #21837.
    • #36994 was committed after office hours and wp_get_sites() is now deprecated. It wraps the new get_sites() instead.
    • #32504, WP_Network_Query is still possible for 4.6. There’s a patch and tests. @jeremyfelt will review this week.
    • #36717 adds magic methods so that WP_Site and WP_Network have nicely named properties. It was committed after office hours and broke the routing of sites on w.org. 🔥 It has been reopened for further exploration. See comment 20 on the ticket for more information. @flixos90 has already been looking at the issue and how #36935 can help.
    • #37050 was opened because it would be nice if id was an int on WP_Network. The concern with this is that anything doing a strict comparison on a numeric string would break. Feedback please. 👋
    • #33900 introduces get_current_network_id() and is close to commit. @jeremyfelt will likely get that in today.
    • #18088 and #35379 are still on deck. @jeremyfelt owes reviews.

    If you aren’t available during the weekly multisite office hours, feel free to leave a comment here or in #core-multisite with a ticket number you’d like to see discussed.

    See you next week!

     
  • Jeremy Felt 4:33 pm on May 25, 2016 Permalink
    Tags: , multisite,   

    Multisite Office Hours Recap (May 23, 2016) 

    Multisite office hours are held every Tuesday at 16:00 UTC in #core-multisite. The next will be Tuesday 16:00 UTC. A more casual bug scrub is on Thursday 20:00 UTC.

    The weekly agenda for the 4.6 cycle is to (a) address blockers and share status on bigger initiatives, then (b) walk through a few multisite focused tickets on Trac.

    Today’s chat log

    Attendees: @flixos90, @DrewAPicture, @richardtape, @ipstenu, @jeremyfelt

    Tickets Covered

    • The commit for #34941 landed. This ticket will stay open for a bit to track any issues that come up and any new tests that are written. A dev note will be needed to describe the changes and hopeful lack of impact.
    • WP_Site_Query is now in core as part of #35791. There is still some work to do to implement get_sites() as a wrapper for queries and apply it throughout core, but we’re moving along. @jeremyfelt is going to work on getting that in shortly.
    • Once get_sites() is in, a ticket should be created to deprecate wp_get_sites() as it will no longer be useful.
    • #36935 was opened to lazy load details on WP_Site objects. This could allow for the deprecation of get_blog_details() in the future. For inspiration see #15458, which did something similar for user meta. @flixos90 has a patch up already.
    • #36717 introduces getters and issetters to WP_Site and WP_Network so that we can use better named properties for ID, network_id, etc… The topic of naming should be discussed in the core meeting first so that we can settle on id vs ID or something else.
    • #35379 and #18088 cover the differences in option sanitization between site and network options. There are good patches on both. @jeremyfelt will take a closer look this week.

    If you aren’t available during the weekly multisite office hours, feel free to leave a comment here or in #core-multisite with a ticket number you’d like to see discussed.

    See you next week!

     
  • Jeremy Felt 7:47 pm on May 18, 2016 Permalink
    Tags: , multisite,   

    Multisite Office Hours Recap (May 17, 2016) 

    Multisite office hours are held every Tuesday at 16:00 UTC in #core-multisite. The next will be Tuesday 16:00 UTC. A more casual bug scrub is on Thursday 20:00 UTC.

    The weekly agenda for the 4.6 cycle is to (a) address blockers and share status on bigger initiatives, then (b) walk through a few multisite focused tickets on Trac.

    Today’s chat log

    Attendees: @iamfriendly, @flixos90, @nerrad, @ericlewis, @ocean90, @jeremyfelt

    Tickets Covered

    • #35791, WP_Site_Query() is still in progress. Most (all?) of what’s left is assigned to @jeremyfelt. @iamfriendly is going to try things out in their staging environment. @ocean90 may put portions on wp.org. More testing is always welcome. Hoping to have the first patches for this in within a day or two.
    • #34941, which wraps the multisite bootstrap process into ms_load_current_site_and_network is also getting closer. @ocean90 tested it on wp.org and nothing exploded, so the ticket is okay to move forward.
    • #17904, managing user login character restrictions in single and multisite, has an updated patch and tests and needs feedback. @ericlewis has been working on moving that along. @jeremyfelt left feedback. Other eyes always welcome.

    It was quiet. See you next week!

     
  • Jeremy Felt 3:55 pm on May 11, 2016 Permalink
    Tags: , multisite,   

    Multisite Office Hours Recap (May 10, 2016) 

    Multisite office hours are held every Tuesday at 16:00 UTC in #core-multisite. The next will be Tuesday 16:00 UTC. A more casual bug scrub is on Thursday 20:00 UTC.

    The weekly agenda for the 4.6 cycle is to (a) address blockers and share status on bigger initiatives, then (b) walk through a few multisite focused tickets on Trac.

    Today’s chat log

    Attendees: @ericlewis, @paaljoachim, @nerrad, @iamfriendly, @spacedmonkey, @flixos90, @jeremyfelt

    Tickets Covered

    • #35791, the weekly favorite for WP_Site_Query() is still in progress. More tests need to be written and more review is needed before commit. @flixos90 will take a stab at starting some tests. @jeremyfelt will review/continue on Wednesday morning. @spacedmonkey also brought up #36675 to have WP_MS_Sites_List_Table use the new WP_Site_Query(). Quite a few of these should appear once #35791 lands.
    • #34941, which wraps the multisite bootstrap process into ms_load_current_site_and_network is still a possibility. Would like some more review/testing.
    • #15691, network admin should have its own settings API. @flixos90 has a patch up that needs review. @jeremyfelt will take a look soon, other eyes welcome as well. 🙂
    • #32504, WP_Network_Query has an initial patch. @spacedmonkey is going to look at writing tests for that. We agreed per last week’s core discussion that it’s okay to use get_network() and get_networks() as needed.
    • #17904, Multisite has more restrictions on user login character set. @ericlewis has pushed this forward quite a bit and a patch is now in place with unit tests to review. wp_validate_user_login() would be used in both single site and multisite to enforce a more aligned set of rules.
    • #35698 is closed in favor of #35379, as both deal with the sanitization of network options vs site options and overlap with their solutions.
    • #32678 is a ticket to audit the toolbar links and content. @paaljoachim is looking for multisite specific feedback. It looks like a few ideas have been generated with single site, but dealing with the My Sites menu will be more painful.
     
  • Jeremy Felt 6:45 am on May 4, 2016 Permalink
    Tags: , multisite,   

    Multisite Office Hours Recap (May 3, 2016) 

    Multisite office hours are held every Tuesday at 16:00 UTC in #core-multisite. The next will be Tuesday 16:00 UTC. A more casual bug scrub is on Thursday 20:00 UTC.

    The weekly agenda for the 4.6 cycle is to (a) address blockers and share status on bigger initiatives, then (b) walk through a few multisite focused tickets on Trac.

    Today’s chat log

    Attendees: @ocean90, @flixos90, @spacedmonkey, @rachelbaker, @jeremyfelt, @johnjamesjacoby, @mikelking

    Tickets Covered

    There was some great conversation around a handful of tickets that took the hour.

    • #35791, WP_Site_Query has been continuing to make good progress. Existing core unit tests pass with the latest patch. These primarily test wp_get_sites(). Tasks for the next couple weeks include writing more new unit tests for WP_Site_Query() itself, testing the patches, and gathering additional feedback. The target commit date is May 12th. Please leave feedback on the ticket! 🗒
    • #32504, WP_Network_Query is also looking like a possibility for the 4.6 cycle. Additional feedback on supported arguments and use cases for WP_Network_Query is more than welcome at this point.
    • Which brings us to naming. 🤓 We need to determine if get_sites() is appropriate or if we should stick with wp_get_sites(). The only trouble with the current form (wp_get_sites()) is that an array of arrays is returned rather than an array of objects. Introducing get_sites() would allow us to deprecate wp_get_sites() and follow previous work like get_posts(), get_users(), get_comments(). The same question exists for networks and get_networks(). A related ticket there is #29415.
    • And more naming. #36717 introduces magic getters so that id will be available on WP_Network and WP_Site objects, site_id will be available for the main site on a WP_Network object, and network_id will be available on a WP_Site object. The changes seem sane, there are probably a few additional details to sort out.

    And a couple tickets left over from last week that should be mentioned to continue progress:

    • #15800 remains super close. @johnjamesjacoby is going to adjust the patch and we’ll see if it can go in this week.
    • #34941 would enjoy some review. This wraps a large chunk of the multisite bootstrap process, so the more eyes the better. 😅
     
  • Jeremy Felt 10:45 pm on April 28, 2016 Permalink
    Tags: multisite,   

    Multisite Bug Scrub Recap (April 28, 2016) 

    Multisite office hours are held every Tuesday at 16:00 UTC in #core-multisite. The next will be Tuesday 16:00 UTC. A more casual bug scrub is held on Thursday 20:00 UTC.

    The weekly agenda for the bug scrub is to discuss 1 or more multisite focused bugs to help move it along. 🐛

    Today’s chat log

    Attendees: @websupporter, @flixos90, @jeremyfelt, @nerrad, @mensmaximus

    Tickets Covered

    #31746get_blogs_of_user() can be very slow when a user is a member of thousands of sites. This is a hefty ticket and several possibilities have been covered as solutions for the problem.

    • Create an additional table to specifically map user capabilities to sites so that the data is more queryable from both the perspective of the user and the perspective of the site.
    • Create an additional site’s meta table (wp_blogmeta) that would do a better job of maintaining a many (users) to one (site) relationship for certain things.
    • Maintain static $blogs data during the request so that only one set is requested during a page view if necessary.
    • Add a filter!

    We decided to open #36707 as a short term solution. The pre_get_blogs_of_user filter will allow large networks to short circuit the function completely and provide their own results. This will also enable the exploration of other solutions through a plugin. #31746 will remain open as a place to discuss solutions for get_blogs_of_user() as a whole.

    Next, we discussed #33887, which was closed as a duplicate in favor of #31405upgrade.php fails with mixed HTTPS (SSL) and simple HTTP sites. The problem here is that set_url_scheme() applies the scheme of the current page view, even when in an ms_is_switched() state.

    We tossed around a few solutions and landed on adding an original scheme to set_url_scheme() that could be used when calling something like admin_url() in a switched state. This would leave the original scheme of the URL untouched and still allow various filters to fire. A patch is up for feedback on #31405.

    And that’s it. Discussion for each of these tickets was great. #36406 is on the list to discuss during Tuesday’s office hours. If you have other tickets you’d like to see covered, drop a note in the comments. 😃

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