Variable pagination for term administration

I would actually support backporting this to Drupal 6 as well. The drag and drop on the taxonomy pages is really nice, but with only 10 items per page it becomes effectively useless on eve marginally interesting taxonomies. I believe the menu admin pages had their paging removed for the same reason.

On visual inspection the code looks good, although I am confused by the comment "// This line does nothing -- but we need to go back to page one..". Do you mean it doesn't work, or that we just want to force it back to page 1? If the latter, I'd just say "This sends us to the current page, but without any pager information so that we go to page 1".

It seems to me that pagination is broken with DnD even if we decided to replace 10 by 100. It sounds to me as if removing the pagination might be best?

I don't think we can remove pagination for freetagging vocabularies with potentially 20-30,000 terms (or even 2-3,000 terms on most hardware). However free tagging is less likely (thought not impossible) to use drag and drop and/or hierarchy - so maybe disable paging on everything else?

Even then I think there'd be a risk for large structured vocabularies, so it might need a setting somewhere. Maybe an on/off setting, per vocabulary in core, but use a variable for the number of terms per page so one of the taxonomy utility modules could change it from contrib?

Maybe we can simply hardcode this settings to 200 then, instead of 10?

Using a variable with a default value of 100 and no UI for it means we get a usable taxonomy page, no string changes, and allow contrib to handle it from there. I'm OK with that, especially as we can then get this into D6 (no string changes).

fwiw I agree 100% with Crell in #10.

The attached patch changes the terms per page to a variable named "taxonomy_page_increment", which defaults to 100. Is there anything more missing that you guys can think of? Is 100 the best value we can put here?

This works well, but I'd really love to be able to control how many taxonomy terms are displayed on the page. I understand that enabling 200 or 500 terms might slow things down a bit, but if I had to reorganize a large taxonomy it would be great to be able to change the setting for at least the time I had to work on it.

+1 for backporting at least the 90 term increase on the taxonomy pages.

I know it's what's already in the taxonomy code, but 'increment' doesn't sound right for the variable name.

The variable we're feeding into pager_query() is $limit.

Currently we have these variables in core for setting pager limits:

* 'default_nodes_main' in node.admin.inc.
* 'forum_per_page' in forum.admin.inc.
* 'comment_default_per_page_' . $node->type in comment.module.

So possibly

* 'taxonomy_per_page_admin'?

Or we could rename the set, e.g.

* 'node_pager_limit'
* 'forum_pager_limit'
* 'comment_pager_limit_' . $node->type
* 'taxonomy_pager_limit_admin'

Renaming the full set is not an option for D6, and this will need to be backported, so let's go with taxonomy_per_page_admin. Once that's in, someone interested in DX can go in and rename stuff in D7 with appropriate update hooks.

Yes please, re-rolled with taxonomy_per_page_admin.

http://testing.drupal.org/node/14654

Looks good.

+1 Works great.

I made it taxonomy_terms_per_page_admin. The other one rubbed me the wrong way.

I am 200% for a DX patch in 7.x that makes these consistent though. Yuck.

Moving back to 6.x for consideration.

webchick: Um, so did you commit it to D7 or not? :-) It's not clear from #22.

Oops. Yes. :P

Since Dries was so supportive of the change saying that pagination is broken in the current ways, I've committed this change to Drupal 6 as well, with the same change webchick did on Drupal 7.

Hooray!

This needs a UI in Drupal 7. Dries, should we reopen this issue or start a new one?

I'm not convinced we really need to expose a UI for this, personally. I think adjusting the number of elements on the taxonomy term admin page qualifies as "power user" enough for settings.php.

Perhaps if we did a follow-up patch to make these consistent, and add them to pages that don't have them (menu.module?) we could talk there about standardizing a UI as well.

menu module doesn't handle paging on drag and drop /at all/ - the implementation needs to be refactored to match what taxonomy does (saving the order of the elements in $_POST and such).

Thank you from all of us who were hacking core (boo!) in order to accomplish this before. +1