Opened 14 years ago
Last modified 6 years ago
#16853 assigned enhancement
Error 500 when a user has too many sites
Reported by: | Owned by: | ||
---|---|---|---|
Milestone: | Future Release | Priority: | normal |
Severity: | minor | Version: | 3.0.1 |
Component: | Networks and Sites | Keywords: | needs-patch dev-feedback ux-feedback needs-design |
Focuses: | multisite, administration | Cc: |
Description
My installation
3.0.1 multi-site installation with more than 7500 blogs, with one user each. I also have one moderation user that can administer each of the blogs.
The issue
In the admin interface, when I go to Super-Admin -> Users, and when I display the page that contains my moderation user, I get "An error (500 Internal Server Error) has occured in response to this request". The page tries to display all the sites administered by him (around 7500 of them), hence the error.
Updating to 3.1 didn't resolve the problem.
Recommended enhancement
For each user in the list, display only a certain number of sites, with a possibility to see all of that user's sites, if needed.
Attachments (1)
Change History (35)
#2
@
14 years ago
Turning on debugging didn't help.
Even if I had increased the "memory_limit" setting, I don't think it would be a good idea to display all of the 7000 and something sites on one page at once.
#4
@
13 years ago
- Owner set to PeteMall
- Status changed from new to reviewing
Yeah, we should paginate this. What's the URL that breaks? Keeping in mind the network admin changes in 3.1.
#5
@
13 years ago
The admin has changed quite a bit since I have reported this issue (3.0.1). Today I have 3.2.1 running and the URL is
/wp-admin/network/users.php
/wp-admin/network/users.php?paged=x
#6
@
13 years ago
- Milestone changed from Awaiting Review to Future Release
- Status changed from reviewing to accepted
#7
@
13 years ago
- Cc edward@… added
I don't suppose y'all could include a dump of your db?
Those wanting to help probably don't want to create 5000 sites manually...
#9
in reply to:
↑ 8
@
13 years ago
Replying to luuzan@…:
Unfortunately, with over 8000 sites, we cannot afford that.
Then I'm not really sure that anyone can "afford" to help you if you're not willing to make it easier for people to find the bug and fix it.
The street goes both ways, eh?
Just do a DB dump, leave the post tables empty, just to give us lots of sites to play with and try to paginate. No harder than that and the dump won't be more than about 250kb big, I imagine.
#10
@
13 years ago
Then I'm not really sure that anyone can "afford" to help you if you're not willing to make it easier for people to find the bug and fix it.
I don't think anyone reporting a bug should be expected to provide a database dump for that simple purpose.
It's not hard to create many blogs/users/posts in a loop, unless it's a bug related to a specific configuration which shouldn't ever happen, there's no need to take that tone.
#11
@
13 years ago
Do you really need an 8000 site dump to be able to develop that simple a pagination ?
@
11 years ago
WP-CLI command to create a bunch of dummy subdirectory sites and admin users (can be adapted to subdomains if needed). Set up a multisite, Network Activate the plugin, and run the command "wp generate_fake_sites generate 8000"
#12
follow-up:
↓ 13
@
11 years ago
- Keywords dev-feedback added
This is an old, old ticket dating back to 3.0.x. Can we mark it resolved?
All Sites & User tables have pagination these days. It's possible to have a user setting for too many items per page that leads to a 500 error, which could be fixed by imposing some kind of upper bound on this setting. But I'm not sure that's a decision that should be forced on admins.
#13
in reply to:
↑ 12
@
11 years ago
Replying to csixty4:
All Sites & User tables have pagination these days. It's possible to have a user setting for too many items per page that leads to a 500 error, which could be fixed by imposing some kind of upper bound on this setting.
The ticket is not about items per page, it's about the list of sites for a particular user in a table row (Sites column):
tags/3.8/src/wp-admin/includes/class-wp-ms-users-list-table.php#L234
Looks like "My Sites" screen doesn't have an upper limit or pagination either:
tags/3.8/src/wp-admin/my-sites.php#L20
#15
@
11 years ago
- Component changed from Network Admin to Networks and Sites
- Focuses administration added
#16
@
10 years ago
- Keywords ux-feedback added
Beyond the possible server errors, the usability on this is pretty crazy. I'm sure it's an edge case, but even being a member of ~10-20 sites gets pretty ugly.
One option is to turn off the "Sites" column in screen options. This would get rid of the 500 error. Unfortunately, this is the only view where you can see all the sites a user is a member of.
I'm not imagining a great interface for pagination inside a list table column yet, but it may be possible. Is it worth adding a new interface for "user's sites"?
#17
@
10 years ago
When I first reported this 4 years ago, it was simply because of the 500 errors. And it's true that I don't have a specific need to see all the sites that the user can administer.
But then again, if we have "site's users", why wouldn't we have "user's sites", just for the sake of consistency ?
#18
follow-up:
↓ 19
@
10 years ago
There's a My Sites view, maybe that's usable for different users in the network. I don't think that screen scales either, though.
I would probably list the primary blog and then indicate X more. Maybe that links somewhere else, maybe that loads X more sites and you can keep clicking to load more, not sure. What would one need to do when looking at a list of all the sites a user is a part of, though? Bulk remove them from those sites? Just look?
#19
in reply to:
↑ 18
@
9 years ago
Replying to helen:
There's a My Sites view, maybe that's usable for different users in the network. I don't think that screen scales either, though.
Not yet.... :) That is due for some reimagining.
I would probably list the primary blog and then indicate X more. Maybe that links somewhere else, maybe that loads X more sites and you can keep clicking to load more, not sure.
I like this idea, and it follows what we've done with network/sites.php showing just the total number of users per site.
What would one need to do when looking at a list of all the sites a user is a part of, though? Bulk remove them from those sites? Just look?
This is a very good question. I've seen it as an annoyance, I'm not sure I've ever used it for something specific. I'm sure smaller networks could use this view as a way to quickly spot who's who on various sites. A study is in order.
I saw this again the other day on someone's network admin and it made me weep.
For anyone with ideas: if we linked a total user count, where would that go? In network/sites.php, the total user count is linked to network/site-users.php and provides a management interface. We don't really have the mirror interface for users (network/user-sites.php) that would allow bulk actions (though that's a ticket too... #18161). I don't have anything great right now, but I'm betting an answer exists.
This ticket was mentioned in Slack in #core-multisite by jeremyfelt. View the logs.
9 years ago
#21
@
9 years ago
- Milestone changed from Future Release to 4.4
I have been swimming in list tables all year
This ticket was mentioned in Slack in #core by sergey. View the logs.
9 years ago
#23
@
9 years ago
- Owner changed from PeteMall to jeremyfelt
- Status changed from accepted to assigned
Going to take a look at the underlying queries for how this view is generated.
This ticket was mentioned in Slack in #core by jeremyfelt. View the logs.
9 years ago
#26
@
9 years ago
- Milestone changed from 4.4 to Future Release
- Owner jeremyfelt deleted
This needs more creative thought than we probably have time for in the 4.4 cycle.
This ticket was mentioned in Slack in #design by karmatosed. View the logs.
7 years ago
#28
@
7 years ago
This also came up in Gutenberg recently. @pento anything we can apply here from those conversations?
#30
follow-up:
↓ 32
@
7 years ago
@melchoyce: Are you referring to the unbounded author list discussion? There's not much to take from that, I think this issue mostly requires the list of sites to be limited in the user list, then a view created for viewing a user's sites. network/my-sites.php
could be pretty easily reused for this, but it would need pagination, to avoid the same problem.
This ticket was mentioned in Slack in #design by michelemiz. View the logs.
7 years ago
#32
in reply to:
↑ 30
@
7 years ago
Replying to pento:
@melchoyce: Are you referring to the unbounded author list discussion? There's not much to take from that, I think this issue mostly requires the list of sites to be limited in the user list, then a view created for viewing a user's sites.
network/my-sites.php
could be pretty easily reused for this, but it would need pagination, to avoid the same problem.
Could we reuse Gutenberg's solution, when that's settled?
#33
@
7 years ago
Short term? Not really, any UI we create is going to expect to be inside a React app, but making this UI inside a React app is also the sticking point. 🙃
Replacing my-sites.php
with a list table would be the fastest way to fix it, I think.
have you turned on debugging?
and increased php memory_limit