Make WordPress Core

Tagged: multisite Toggle Comment Threads | Keyboard Shortcuts

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

  • Jeremy Felt 3:59 pm on April 27, 2016 Permalink |
    Tags: multisite,   

    Multisite Office Hours Recap (April 26, 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, @jeremyfelt, @boonebgorges, @rachelbaker, @earnjam, @iamfriendly, @johnjamesjacoby

    Tickets Covered

    • @flixos90 has been working on #15691 and is requesting feedback. @jeremyfelt will take a look this week. @boonbgorges also has it on his list. More welcome!
    • Somewhat related to that are #18088, #35698, and #35379, which require more context when sanitizing network options so that they are treated differently than site options. These are all on the 4.6 milestone now and shouldn’t be far off from commit.
    • #16001 and #31127 need testing and exploration to determine solutions. @richardtape has dug in and @earnjam will be as well.
    • #35791, WP_Site_Query is moving along nicely, thanks @spacedmonkey! @flixos90 is going to take a closer look at the latest patches. @jeremyfelt will as well. If anyone would like to dive in on unit tests, now is the time. ⚡️
    • #32504, WP_Network_Query is a possibility for 4.6. @flixos90 will start playing with a patch.
    • #34941 needs review, and @johnjamesjacoby will be taking a look at it. This wraps a large chunk of the multisite bootstrap process, so the more eyes the better. 😅
    • #27287 and #36507 both deal with unexpected or incorrect URLs when multisite is installed in a subdirectory. In general—see #19796—multisite installs should work with WordPress in a subdirectory. Any patch to resolve issues here should ensure wide coverage with unit tests so that we don’t affect current behavior.
    • #15800 is super close. @johnjamesjacoby is going to adjust the patch and we’ll see if it can go in this week.
    • #36546 and #24617 are both closed as fixed. Spammed users can no longer log in or reset their password.

    That’s that. See you next week!

  • Jeremy Felt 6:17 pm on April 25, 2016 Permalink |
    Tags: , multisite, networks-sites   

    Multisite Kickoff for 4.6 Chat Summary 

    This is a summary of the multisite kickoff chat from April 21st.

    Attendees: @ocean90, @jjj, @streetlamp, @websupporter, @johnbillion, @richardtape, @ipstenu, @mikelking, @arippberger, @tubiz

    A refresh for weekly meetings

    There is a new time for weekly office hours: Tuesday 16:00 UTC

    The agenda for those weekly office hours will look something like this:

    And a more casual bug scrub will happen in #core-multisite every week on Thursdays. Thursday 19:00 UTC. Bring bugs! 🐛

    Tickets already in progress for 4.6

    • #35791WP_Site_Query – and a multitude of tickets that will ready once this goes in.
    • #15800 – Adding tabs to “Edit Site” pages in the network admin
    • #34941 – A more testable multisite bootstrap process

    Other tickets of interest for 4.6

    • #16001 – Invited but not activated users can get lost, also related #31127
    • #34316 – User status inconsistent between single-site and multisite
    • #15691 – Network admin should have its own settings API
    • #36546 – User marked as spam can log in
    • #24617 – Spammed users should not be able to reset their password
    • #30175 – In multisite, on a site with only subscribers, wp_dropdown_users returns empty string
    • #31746 – get_blogs_of_user() can be very slow when a user is a member of thousands of sites

    Many of these tickets are looking for owners. If you have interest in patching, testing, etc…, please leave feedback on the ticket and/or stop by during office hours. See you tomorrow at 16:00 UTC! 🌮

    Chat log

  • Jeremy Felt 6:10 am on April 19, 2016 Permalink |
    Tags: , multisite   

    Multisite Kickoff for 4.6 

    Let’s have an official multisite kickoff chat this April 21 19:00 UTC in #core-multisite to discuss some of the things we’d like to cover in 4.6.

    A few ideas to ponder…

    • I’d like to reframe our weekly office hours as weekly bug scrubs for this cycle and see how that goes. We can keep tabs on the status of bigger initiatives throughout the week and use the weekly hour to walk through portions of the 217 open multisite tickets in Trac that need walking through.
    • I’d also enjoy moving to a new time for these weekly bug scrubs starting April 26 16:00 UTC. Earlier and easier to schedule for me. How about you?
    • The REST API team is looking for help from component maintainers to build up and maintain parts of the REST API related to those components. If this is something that interests you, let’s chat!

    And the bigger initiatives already in progress:

    • #35791 (previously #31148), in which we introduce WP_Site_Query and use it throughout. 👏
    • #15800, in which we DRY up a bunch of network admin code and enable the extension of the network admin interface.
    • #34941 (and #36566) to further the testability of the multisite bootstrap process, which will in turn lead to fixing things like #17376 with greater confidence.

    And now it’s your turn! Leave ideas in the comments for what we should spend time fixing or breaking in multisite for the 4.6 cycle. 😅


    • websupporter 6:20 am on April 19, 2016 Permalink | Log in to Reply

      Its not completely internal multisite, but maybe we ( I would love to participate in this ) could evaluate a bit the question of the user_status raised in https://core.trac.wordpress.org/ticket/34316 I don’t know, maybe it is a to huge task as it implies database changes which might effect some plugins. And maybe its more a User component, but it is insofar related to multisite as it tangles the `spam` column in the user database, which is only used by multisite and actually this is almost the only real used user_status around. If you think its multisite OT, just let me know 🙂

      I’ll try to make it to the meeting. 19 UTC is a good time for me (its 22:00 in my timezone and my baby sleeps 😀 )

      • Jeremy Felt 3:41 pm on April 21, 2016 Permalink | Log in to Reply

        There are fascinating possibilities with that ticket. We should talk the steps a database upgrade routine would need to take and how we can ensure back-compat for any plugins currently relying on user status.

    • csigncsign 8:43 am on April 19, 2016 Permalink | Log in to Reply

      there are several conflicts due to the fact, that the main blog of a multisite adds an additional “blog” slug to the permalinks.

      • Jeremy Felt 3:35 pm on April 21, 2016 Permalink | Log in to Reply

        This should be easier to work around after we tackled #12002 in 4.4. “blog” is still used as the default, but once you change it, WordPress won’t try to bring it back.

    • Boone Gorges 2:22 pm on April 19, 2016 Permalink | Log in to Reply

      UI for managing registrations: https://core.trac.wordpress.org/ticket/16001 Not strictly Multisite-only, but critical for any Multisite installation with open registration. A large amount of work has been done on patches, but there is some concern about how the confirmation workflow fits alongside adding users to sites. It would be great to sketch what needs to be done for this ticket to move forward – even if it means that some of the odder edge cases (a pending user being added to more than one site) are not handled smoothly in the UI for the time being.

    • zakkates 3:37 pm on April 19, 2016 Permalink | Log in to Reply

      omg, yes! WP_Site_Query

      I’ve been using: Network_Query from http://rudrastyh.com/plugins/get-posts-from-all-blogs-in-multisite-network – Maybe you can get some tips on how they used it.

    • Felix Arntz 4:03 pm on April 19, 2016 Permalink | Log in to Reply

      I’d like to continue work on the Network Settings API (https://core.trac.wordpress.org/ticket/15691) as it will address the needs of many plugin developers who currently use their own kind of hack to handle options in the network admin. Right now I’m basically waiting for some more feedback, maybe we can talk about it in the meeting as well.

  • Jeremy Felt 7:05 am on March 9, 2016 Permalink |
    Tags: , , multisite   

    Multisite Focused Changes in 4.5 

    Howdy! The 4.5 release cycle was relatively quiet for multisite, though we still managed to knock out a few good things. The following is a brief rundown of each, full details can be found in the full list of multisite focused changes for 4.5. 💫

    Introduce WP_Site

    The global $current_blog has always been used as a way to store the properties in a stdClass object of the current site during bootstrap. With the introduction of WP_Site, we add some definition and have a more proper object to pass around. Sweet.

    Take a look at ms-settings.php if you are using a custom sunrise.php to populate the $current_blog global. We now create a WP_Site object from the existing $current_blog if it has been populated elsewhere. This is a backward compatible change, though should be tested wherever your code interacts with $current_blog, especially if anything has been done to extend its structure.

    This last paragraph may sound familiar to you because I copied it from the notes on the work we did in the 4.4 release to add WP_Network as an object. In future releases, we’ll continue to build these out with query classes as well.

    See #32450 for all the details.

    New Actions and Filters

    • network_user_new_form fires at the end of the network’s Add New User form. #15389
    • network_site_new_form fires at the end of the network’s Add New Site form. #34739
    • network_allowed_themes and site_allowed_themes allow for more granular filtering of the themes allowed for a site. The legacy allowed_themes will continue to do its job. #28436
    • pre_network_site_pre_created_user fires right before a new user is created during the Add New Site process if one does not already exist. #33631

    Other interesting things

    • Use a usermeta key rather than a site option keyed to the user ID when a user changes their email address and confirmation is needed. #23358
    • In subdomain installations, if a user attempted to login to a site they did not have access to on the network, they would be shown an access denied message with a list of authorized sites. This differed from the behavior in subdirectory installs, where the user would be redirected to either their profile page or the dashboard of their primary site. In 4.5, the subdomain behavior now matches the subdirectory behavior. #30598
    • The performance of wp_upload_dir() has been improved, specifically via persistent cache. This isn’t necessarily multisite related, though you should probably be familiar with the change. #34359
    • Show the home URL rather than siteurl in site-info.php and use the text “Site Address (URL)” for consistency with the similar site in single site. #35632
    • Provide an “Edit user” link after adding a new user to a site or network. #35705 😻

    And that’s about it. There may still be some bug fixing in the next week or so, but only if you get out there and test trunk against your plugins, themes, and crazy configurations. Have at it!

  • Jeremy Felt 7:18 pm on October 28, 2015 Permalink
    Tags: , , multisite   

    Multisite Focused Changes in 4.4 

    WordPress 4.4 has been a very productive release for multisite. In addition to some exciting new enhancements, we were able to resolve some long standing bugs. Check out the full list of multisite focused changes on Trac if you want even more wonderful reading material. 💖

    Introduce WP_Network

    The $current_site global has been maintaining a stdClass object representing an assumed description of a network since the original merge of WordPress MU with WordPress. With the introduction of WP_Network, we give a network a bit more definition and open up possibilities for working with a network (or networks) in a more sane way.

    Take a look at ms-settings.php if you are using a custom sunrise.php to populate the $current_blog or $current_site globals. We now create a WP_Network object from the existing $current_site if it has been populated elsewhere. This is a backward compatible change, though should be tested wherever your code interacts with $current_site, especially if anything has been done to extend its structure.

    See #31985 for more discussion while this was built.

    Introduce *_network_option functions

    During the introduction of WP_Network, we needed a way to populate network options (stored in wp_sitemeta) for a network other than the current.

    add_network_option(), update_network_option(), get_network_option(), and delete_network_option() are all new functions in 4.4. Each takes the network ID as its first argument, matching the structure of the *_blog_option() functions.

    *_site_option() functions remain as the proper way for working with a current network’s options. These now wrap the new *_network_option() functions and pass the current network’s $wpdb->site_id.

    In a future release, likely 4.5, we can look at the introduction of network 0 as a way to store global options.

    See #28290 for more discussion.

    New actions and filters

    • before_signup_header fires before the signup header in wp-signup.php. #17630
    • ms_network_not_found fires when the $current_site global has not been filled and ms_not_installed() is about to fire. #31702
    • invite_user fires immediately after a user is invited to join a site, but before the notification is sent. #33008

    Other enhancements of note:

    • WordPress has always enforced a /blog prefix for the main site’s permalink structure to avoid collisions with other sites in a subdirectory configuration. This was always changeable in the network admin, though the permalinks UI in the site admin never reflected the change and could cause confusion. Now, thanks to #12002, WordPress forgets that /blog was ever assigned if it is changed in the network admin to anything else. When changing this value, choose something that won’t conflict.
    • manage_network_users is now used to determine edit_users caps rather than is_super_admin. In preparation for 4.4, take a look at how you’re using the manage_network_users capability in your code to be sure access is set as intended. #16860
    • Network activated plugins are now visible as “network activated” in an individual site admin if the user can manage network plugins. These are not shown to site administrators. #20104
    • Recently active plugins are now displayed as such in the network admin. #20468
    • Language selection is now available when adding a new site through the network admin. 🌍 #33528
    • Language selection is also now available when signing up for a new site through wp-signup.php. 🌏 #33844
    • Network user searching has been improved by wrapping search terms in asterisk for looser matching. #32913

    Bugs of note fixed:

    • It was previously impossible to set the upload limit for an individual site to 0 as it would then fallback to the default of 100MB. In 4.4, 0 is a respected number. #34037
    • When a site’s home, siteurl, or page_on_front option was updated in the network admin, rewrite rules were previously flushed incorrectly, causing rewrite rules for the main site on the network to take the place of the rewrite rules for the site being changed. #33816
    • Subdirectory sites created on an HTTPS network are now set to HTTPS rather than the incorrect HTTP. 🔒 #33620
    • A site’s title can now be longer than 50 characters! #33973

    Deprecated functions:

    Both get_admin_users_for_domain() #34122 and create_empty_blog() #34120 have never been used by WordPress core and are now deprecated. 🍻

    • webaware 11:17 pm on October 28, 2015 Permalink | Log in to Reply

      *_network_option functions FTW!

    • Remkus de Vries 12:12 pm on October 29, 2015 Permalink | Log in to Reply

      Thanks for the update Jeremy, and good to see so many small but wonderful updates happening in 4.4 for Multisite!

    • Ian Dunn 11:15 pm on October 30, 2015 Permalink | Log in to Reply

      Kudos to Jeremy and everyone else who contributed 🙂

    • lernerconsulting 6:25 am on November 15, 2015 Permalink | Log in to Reply

      What is happening with domain mapping in WordPress core? Or do we keep using wordpress-mu-domain-mapping plugin?

    • chrisv2 3:22 pm on December 14, 2015 Permalink | Log in to Reply

      I’m really struggling with this as well – there are so many conflicting pieces of information out there. Can anyone confirm (or dis-affirm) that WordPress 4.4 now has domain mapping functionality included in core? I think the WordPress “mu-domain-mapping” plugin is genius – but reading through the code, the idea of being dependent on it scares me.

      I’m lost right now trying to figure out the best and most robust way to enable domain mapping.

    • chrisv2 8:54 pm on December 14, 2015 Permalink | Log in to Reply

      Thanks, Mika. So then what’s the all the hoopla about “WordPress may include this function in the core someday” (which I have read about for domain mapping in more than one article)? One more line of code to handle the cookie setting?

      Your article is very helpful – but when I read the very last paragraph I got nervous again. Is this whole topic of domain mapping so fragile that it can (and will) break, so we should just expect there to be problems?

      • Ipstenu (Mika Epstein) 12:16 am on December 15, 2015 Permalink | Log in to Reply

        Well there’s no allowance for cookies, the GUI is lacking, you can’t have the backend at one domain and the front end at another (something companies like), and so on.

        So it’s not so much adding to core but making it way better in core 🙂

  • Jeremy Felt 5:07 pm on October 14, 2015 Permalink
    Tags: multisite   

    Multisite Office Hours Recap (October 13, 2015) 

    Multisite office hours are held every Tuesday at 20:00 UTC in #core-multisite. The next will be 2015-10-20 2000.

    Today’s chat log
    Overall 4.4 Release Objectives

    Rough ticket agenda posted before the meeting:

    • #28290_network_option() is in trunk with the new parameter order. Is there anything else we should do on this ticket? I’m thinking global options stored as network id 0 should be a new ticket.
    • #31985WP_Network() – Thoughts on making properties private and adding getters? I’m okay with leaving them public, though there’s no turning back. 🙂
    • #34065 – How often is the network setup screen used to create a new network with another user as the network admin? Should we just bail early with a message or think about refactoring this?
    • #20104 – Marked as commit, toss thoughts in now if you haven’t… 🙂
    • #34287 – Value of a “Settings” link under the Network Admin menu?
    • Open floor


    • #28290
      • Where does _network_option() belong? It has to stay in options.php because we wrap with _site_option() now. Moving to a new ms-options.php or similar would mean including that file anyway during single site load.
      • Are we leaving anything on the table? Requesting comments on this one. We’re happy with _network_option() as it is and happy including to have it in core. Does anyone have concerns with the current state?
      • We’ll want to close this ticket pre-beta (one week), so leave your comments! 🙂
    • #31985WP_Network(). We seem okay here. Going to stick with public properties to meet general assumptions and to avoid back-compat errors with the existing $current_site. We can bring up additional enhancements in new tickets. Ticket closed as fixed.
    • #34065 – This opened a larger can of worms around what “network admin email” means in #34293. In the meantime, we can address this ticket with a few assumptions. Added note to ticket.
    • #20104 – Everybody is happy. Ticket committed. Those who can manage network plugins now see the status of those network plugins in the site admin.
    • #34287 – We had a collective +1 on adding “Settings” to the Network Admin menu. Ticket committed.
    • #34293New ticket. @ipstenu updated with some conclusions and clarifications so we can keep the discussion going. We should update messaging around the several different types of emails used to send or receive notifications in multisite.

    Thanks everyone!

  • Jeremy Felt 5:49 pm on October 7, 2015 Permalink
    Tags: multisite   

    Multisite Office Hours Recap (October 6, 2015) 

    Multisite office hours are held every Tuesday at 20:00 UTC in #core-multisite. The next will be 2015-10-13 2000.

    Today’s chat log
    Overall 4.4 Release Objectives

    This was our first structured office hours in a bit after a lag, but here’s to being back in action. 🙂

    A rough agenda posted before the meeting:

    • #28290 – We’ve added _network_option() and need to converse some more about parameter order. After some thoughts shared in Slack yesterday, it seems that having $network_id first makes sense. This would have the side effect of a seamless transition for those already using the functions in WP Multi Network. We should also add global options with a network ID of 0. This may belong in another ticket.
    • #18292 – Opinions on whether we should temporarily fix the network upgrade process by halting on a failed site rather than using wp_die() and killing the entire thing. A long term solution via #11869 is to revamp the process entirely so that we don’t have to worry about silly things like this.
    • #34145 – Does anyone have a problem with removing Lucida Grande from wp-activate.php?
    • #31240 – Patch needed, I haven’t had time to work on it yet, though I think we still have time in this cycle.
    • #32450 – More testing, iterations on the current patch needed. This one is likely tougher than WP_Network as it touches more parts of core once implemented.
    • Open floor, other things, tickets, etc…


    • #28290 – Go with a new parameter order and accept $network_id first in _network_option(). Revert the change to use _network_option() in core. Open a new ticket to talk about storing network ID 0 as a global option. Initial revert in [34912].
    • #18292 – Let’s wait on the halt behavior and stick with what we know. We should tackle #11869 as a way to resolve all of this. Ticket closed.
    • #34145 – Get rid of it. Committed in [34882].
    • #31240 – Postpone this until we’ve had a chance to really decide what we want from the Add New site screen. Not all networks are created equal in their configuration of domain and path. We need to start doing some more unit testing around what we actually do and do not support. Ticket moved to future release.
    • #32450 – We didn’t have a chance to cover this one, more testing and iterations needed. 🙂

    Thanks all!

  • Jeremy Felt 3:37 am on September 17, 2015 Permalink
    Tags: multisite   

    Multisite objectives for the 4.4 cycle 

    We’ve made a good chunk of progress in the 4.4 cycle thus far and are starting to go in a direction that can be better defined through a handful of objectives. Let’s go through them:

    • WP_Network has been comitted to core. This is one of the major objectives for 4.4 and should be tested thoroughly. #31985
    • WP_Site will follow shortly and is another main objective. This still needs some initial work before commit, and should also be tested thoroughly. #32450
    • In the process of implementing WP_Network, it became clear that now is the time to introduce *_network_option() functions as replacements for *_site_option(). This has long been a one day objective, and now that we have an applicable use case in core, we’re going for it. Follow and help with progress in #28290.
    • In 4.3, we combined the domain/path fields when editing a site in both subdirectory and subdomain mode to allow for easier entry and for the beginnings of arbitrary domain/path support. To complete this, we need to follow up when adding a site if a subdomain install. Subdirectory configurations will remain the same. #31240
    • Adding a field for scheme to the wp_blogs table is still on the table in #14172. This goes hand in hand with the work being done by the HTTP/2 group and could help clear the way for quite a few other HTTPS tickets.
    • WP_Site_Query and WP_Network_Query are probably long shots for 4.4, and may need to wait until 4.5. That said, if progress is made on either in the near future, then we can start to speed that up.

    As we introduce things like WP_Network and WP_Site, we’re going to continue seeing smaller places that can be cleaned up or fixed in a different way. Keep your eyes open for those opportunities. And as always, if you have a ticket you’d like to see through and it’s not on this page, chime in early and let’s get it done.

    Multisite office hours are on Tuesdays at 20:00UTC in #core-multisite. We’ll be discussing these objectives weekly, and the channel is always open. 🙂


  • Jeremy Felt 6:14 am on July 24, 2015 Permalink
    Tags: , , multisite   

    Multisite Focused Changes in 4.3 

    Howdy! We’ve made quite a bit of progress in multisite as part of the 4.3 cycle and have a bunch slated to continue working on throughout the year. If you’d like to follow along, stop by our weekly office hours on Tuesdays at 20:00 UTC in #core-multisite.

    Here’s what we have coming in 4.3…

    Begin streamlining the interface for setting a site’s URL.

    Editing a site’s address for what it is—a combination of domain and path—becomes more straightforward in 4.3. A full address with or without scheme can now be entered if multisite is configured as subdomain. Network administrators have been hacking at this anyway for years when the two fields were separate to provide arbitrary domain support. See #22383 for all the details.

    In combination with this, the checkbox for “Update siteurl and home as well” has been removed when editing a site. Instead we can make an educated decision based on the current state. If the home and/or siteurl domain and path match the existing domain and path of the site, we assume that we can update all values with the new information. See #32503 for details.

    And to better enforce URLs vs domain and path, we’ve improved the default columns displayed in MS Sites List Table. The full URL is now show instead of the domain or the path. We also now show a total user count for each site rather than the first 5 users. See #32434 for details.

    Introduce get_main_network_id()

    This likely isn’t too useful to many, though will come in handy for those working with custom multi-network configurations. It will always return 1 on single site or if the current network has an ID of 1. It will return PRIMARY_NETWORK_ID if defined. And if those conditions aren’t met, it will go to the database to determine which ID is the first in line.

    It is possible to filter this value with the new get_main_network_id filter for those who have multiple networks and would like to avoid the incremental assumptions. See #30294 for the details.

    Visual and interface enhancements:

    • Better responsive styling for my-sites.php, a screen that would love to have a complete overhaul one day but now looks much better on smaller devices. #31685
    • Also in my-sites.php, the Save Changes button is conditionally displayed only if the user is a member of more than one site OR if a plugin or theme has filtered the HTML on this screen and may be expecting a Save Changes button to exist. #32645
    • Achieve parity between single and multisite by removing the Upgrades subsection in the menu and moving Updates to Dashboard. #32431
    • Provide a link to the dashboard when editing a site in the network admin. Previously, only the URL would show in the title area of the site screens with no great way to access the dashboard. Now, the full site name is shown as the title and smaller text URLs are displayed underneath for Visit and Dashboard. #32525
    • Mobile display of the network admin has been improved in general. A few inputs have been adjusted on mobile to make them act as expected. #32643, #32644, #32646. A full sweep of “content overruns” was done to ensure admin screens don’t overflow the screen on small mobile devices. #32846, #32962.

    Bugs of note fixed:

    • Don’t allow usernames over 60 characters long, a limit that was already in place via the database schema but was not enforced explicitly in code. #26784
    • Calculate the storage space used correctly for the main site. Previously, it was possible that the main site would reach it’s calculated space limit because the storage of all other sites was included in the total. #30202
    • get_blogs_of_user() now returns proper values for the archived, spam, and deleted properties. These were previously forced to 0 only when using this function. #32281
    • Deleting a super admin user via wpmu_delete_user() is no longer possible. This matches the expectation previously set by the UI. #32935

    And because some are smaller and were left out of the above, here’s a full list of multisite focused changes made in 4.3.

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