Make WordPress Core

Opened 8 years ago

Closed 7 years ago

#38210 closed enhancement (duplicate)

WPMS sites list table doesn't display the blog name by default

Reported by: mista-flo's profile Mista-Flo Owned by:
Milestone: Priority: normal
Severity: normal Version:
Component: Networks and Sites Keywords: ux-feedback has-patch close
Focuses: multisite Cc:

Description

I really don't understand why in WPMS sites list table (wp-admin/network/sites.php) page, the blog name is not displayed by default (only in 'excerpt' mode), instead, the URL of the blog is displayed.

It's really difficult to identify the current blog only with only the URL.

Why don't we display the blog name by default in a new column, next to the URL one ?

Attachments (4)

site_name1.jpg (85.3 KB) - added by xkon 7 years ago.
List mode
site_name2.jpg (111.1 KB) - added by xkon 7 years ago.
Excerpt Mode
38210.diff (1.3 KB) - added by xkon 7 years ago.
Show site names on Sites List
38210.2.diff (1.8 KB) - added by xkon 7 years ago.
Made a single switch and removed unnecessary printf

Download all attachments as: .zip

Change History (15)

#1 @Mista-Flo
8 years ago

  • Keywords needs-patch ux-feedback added

#2 @ocean90
8 years ago

I'm managing a network with sites in 150 languages, since I don't speak all of them the name is really unimportant to me.

The main reason is probably that displaying the name and description requires a switch_to_blog() call which isn't quite performant.

#3 @Mista-Flo
8 years ago

Thank you for your answer, I guess it's a crucial information for a lot of users, maybe not all yes, but it should be a default behavior. Unfortunately, if it's a performance matter, I understand and maybe we have to forget this enhancement.

Version 0, edited 8 years ago by Mista-Flo (next)

@xkon
7 years ago

List mode

@xkon
7 years ago

Excerpt Mode

@xkon
7 years ago

Show site names on Sites List

#4 @xkon
7 years ago

  • Keywords has-patch added; needs-patch removed

Hello,

I'm also managing multiple, Multisites across different servers for different purposes and in my opinion it would be really useful to see the names actually. For example in my field usually the sites url is just an automated code but the Name is actually the clients name so it would make perfect sense to have it all the time there.

Also the switch_to_blog is either way used in here for the Excerpt view so I don't feel like it is going to make that much of a performance issue.

I've uploaded a small patch ( 38210.diff )as it was an easy fix to implement a name in there and I also removed it from the Excerpt view to not have duplicates.

Check it out and you might like it better... I do at least and probably going to implement it right away on my deployments to check it out as well.

I don't know if there's another list have I have to check out, I'm managing the sites but never actually wandered around the multisite UI but I'll be happy to make all the tables with names if you can point them out for me.

Best regards,
Konstantinos

Last edited 7 years ago by xkon (previous) (diff)

This ticket was mentioned in Slack in #core by xkon. View the logs.


7 years ago

#6 @SergeyBiryukov
7 years ago

  • Component changed from Administration to Networks and Sites
  • Milestone changed from Awaiting Review to 4.9

38210.diff seems like a good first step.

  1. Could we get both blogname and blogdescription in a single switch_to_blog() call?
  2. Once blogname is moved above the URL, the printf() and __() calls for blogdescription can be removed, it doesn't make much sense to translate __( '%1$s' ) on its own.
Last edited 7 years ago by SergeyBiryukov (previous) (diff)

@xkon
7 years ago

Made a single switch and removed unnecessary printf

#7 @xkon
7 years ago

Following @SergeyBiryukov suggestion which makes total sense I remade the code to 38210.2.diff .

If it can get even better please advice so I can proceed with updates.

Best regards,
Konstantinos

#8 follow-up: @flixos90
7 years ago

While it's nice that the code did not use switch_to_blog() before, I think the benefits here outweigh the cost. However, we must consider that this will decrease performance a bit (which is probably okay, considering we're doing that in so many places already).

#9 in reply to: ↑ 8 @xkon
7 years ago

Hello @flixos90 what do you mean? It was using it in the excerpt view. It just got transferred outside the views to gain access either way .

To complete the thinking behind this of why this is basically 'faster' not code-wise but usability wise is this.

Like I mentioned it was used on the Excerpt view either way that it was loading the name + description as well.

Imagine having a bloated list of sites but by random paths ( like the ones I'm used to in the company I work for... don't ask me why they just do it ). This means i have to wait 1 time for the page to load then click the Excerpt to view the clients name and eh, wait again even a bit longer. That's double time for me. So by just moving it out you might wait longer first hand but you might never use the Excerpt view again as well as the main interest would be the blog's name usually not the description as much.

Just a thought.

Best regards,
Konstantinos

Replying to flixos90:

While it's nice that the code did not use switch_to_blog() before,).

Last edited 7 years ago by xkon (previous) (diff)

#10 @flixos90
7 years ago

  • Keywords close added

On a second closer look, I don't think that change is necessary.

I like the idea of keeping the list mode free of switch_to_blog() calls. This allows everyone to choose between the variant they like: more performance vs. more information.

As stated by @ocean90 before, not everyone cares about the names of each site. Those who do can already see that information via the excerpt view.

@SergeyBiryukov I'm curious what you think about this, but I'd suggest closing this as I don't see a benefit by having the two modes showing the same amount of information, particularly since that means decreasing the performance of one variant.

#11 @flixos90
7 years ago

  • Milestone 4.9 deleted
  • Resolution set to duplicate
  • Status changed from new to closed

Actually I just noticed #40268 which talks about the same change, but goes a little further by considering removal of the mode switcher.

Let's close this ticket and continue discussion in the other one. Thanks for working on this, and I hope to see you weigh in on #40268!

Note: See TracTickets for help on using tickets.