Domain Content: too many menu items

Anyone?...

Is I'm the chosen one who have more than 20 (truly say, more than 10k) domains at one site? ))

I've found some pages where module gets stuck:

- /admin (probably because of "affiliated content" menu items)
- /admin/modules (i don't know why..),
- /node/add/*/ (probably because of "assign to domain" block),
- /admin/content/node-type/*/ after "save" button click (i don't know why..).

With domain access modules disabled all this pages are working properly.

There are some others out there, but it may take some time to find this issue.

I'm developing a site for a client where he'll add a domain for each company he consults to. He's hoping to get 100 clients within a year, so I've been researching scalability for the different multisite options. So far Domain Access looks to be a brilliant fit - and I'll cross the scaling question of 20+ domains if/when we get there.

Isn't a simple way to test this to add 20+ domains on a local dev server and then test the site and see if some things break?

As to drupal hanging at
/node/add/*/
wouldn't a way to solve that be to have an ajax-populated search box - so that 10k domains don't need to be loaded each time a node is added?

Possibly. We also have a maintainer who runs 110+ sites.

Right now, I am more interested in the menu issue, which is what this issue is about.

There's two issues here - admin menu items and list of domains on node add/edit pages.

I've got 100+domains so for users with sufficient permissions the list of domains gets very long (when used in combination with Admin Menu module one cannot get to domains after the first screen).
Perhaps the solution is to list first 20 domains the user has access to and as the last item link to /admin/domain/content where depending on permissions users would see all or only their domains?

Or just create one menu callback, which is a page that contains a sortable table of the domains.

To clarify we'd have the following menu items on any site no matter how many domains are enabled:
- affiliated content (admin/domain/content)
-- content for all affiliate sites (admin/domain/content/all)
-- content by affiliate sites (page that contains sortable table of domains)

Or did you have something else in mind?

Nope. That's all we can do to solve this problem. We have to make $items['admin/domain/content/'. $domain['domain_id']] a MENU_CALLBACK, and then use the table to handle it.

Alternatively, we could get fancy and allow the menu items as is as long as there are < 20 domains. But that seems a PITA.

Wow. No help on this one? This actually needs to get fixed.

Release blocker.

Here is a start. It sets a new variable 'domain_list_size' which defaults to 25 (and is configurable). This variable should be used whenever generating lists or tables of domain information. See the code in domain_content.admin.inc for example.

This logic now needs to be applied to the checkboxes taht appear on forms, so we need to standardize the rendering of a 'domain_list_form' element.

Hmm, haven't seen this issue until now. We have a client that runs over 200 domains with DA, so this seems like it should apply to us. With that said, I haven't seen or heard of any issues regarding this, yet. Sure, we have a loooong list of domains on node/add if you have proper permissions, and Admin menu gets a ridicously long list, but haven't seen any problems with it. Maybe we haven't hit the threshold yet.

I will give the patch a try tomorrow.

When I tested with 500 domains, it got pretty bad. Admin Menu was the main problem, but the UI became unusable.

I tried the patch, and it works as expected for the menu part of the problem. Re-rolled for a missing </em>. I'm not sure we need to treat sites with <25 domains differently, just adds code, but that's up to you.

There are many more parts of the system that needs tweaking for handling >25 domains, so getting this in there could help.

The idea was to make that <25 configurable. The real menu problem is on the path /admin/domain/content, which can get really ugly if more than 30 or so domains.

I misread the patch, sorry. I can see that creating quick links for domain content on less than 25 domains can be helpful.
I really like the new list page! Quite useful.

Nitpick: 'Article count' should probably be Node count or Item count.

I think this patch can be committed and we move on to other parts that need attention in follow-ups.

Here's a slightly revised patch. I changed the column label to 'Content count', which is more in line with core.

I'd like another review or two, especially nonsie, who deals with this problem frequently.

A side note: I've been experiencing on our clients site that jQuery.js gets halted, and haven't found an answer to it, but ran into this issue today: #336924: Massive page rendering slowdown with many links. Now I know why, with admin menu showing 200+ domain links.

I've been neck deep in various projects in the past few weeks but I promise I'll get to this patch either today or tomorrow.
re #17 - it can also occur if you use content taxonomy and its tree widget when you have thousands of terms/links. There really ought to be a list of things to look out for when building a large site;)

Omg, this patch is a lifesaver. Not only because of getting rid of the list of domains that won't fit on the screen (most frequent complaint) it also gives nodes counts per domain (somewhere in top ten in complaints list as well). I still need to run some tests on dev server in addition my own sandbox but so far so good.

One thing that in my option would improve usability is changing the order of columns to site name, domain, content count, edit. In LTR lists the edit link is normally on the right.

@nonsie-

I give you free rein to re-roll the changes you need to the layout, then I will just test them. Then we can commit this, and the next steps I see are:

1) A setting that controls the max count of the list (currently hardcoded at 25)
2) A form builder function that abstracts the creation of the checkbox elements on domain forms (node, user, overviews) so that we can toggle from checkboxes to selects (or nicely themed checkboxes) through a single function.

I stripped down the items on the table, removing the less obvious. I resisted putting the edit link on the right simply because it isn;t really an 'edit' link, its a link to another table view.

The variable 'domain_list_size' is now in DA, and is used for all table views. Proper use is variable_get('domain_list_size', DOMAIN_LIST_SIZE).

Committed to HEAD. We can address other issues in followups.

Automatically closed -- issue fixed for 2 weeks with no activity.