Hard coded pager limits

I've got a patch for this but for some reason drupal.org is not letting me upload it. I get an error that says the directory is not writable.

patch can be accessed here http://mycivicsite.com/page_size.patch

Per the discussion on the developer list, I've redone this patch to use a variable to specify the page size for admin pages. Two new variables are used.

variable_get('admin_pager_long', 50)
variable_get('admin_pager_normal', 30)

The following modules are affected.

comment
node
path
profile
statistics
taxonomy
user
watchdog
locale (locale.inc actually)

New patch attached.

Great patch, except that it doesn't use the new variables admin_pager_long and admin_pager_normal. All the pager lengths are still hard coded.

This attached patch replaces all hard-coded calls to:

drupal_get_page_size(50) with drupal_get_page_size(variable_get('admin_pager_long', 50))
drupal_get_page_size(30) or drupal_get_page_size(25) or drupal_get_page_size(20) with drupal_get_page_size(variable_get('admin_pager_long', 30))

Also made one more change:
drupal_get_page_size(15) with drupal_get_page_size(variable_get('admin_pager_search', 15))

I have added a new variable, 'admin_pager_search', as I feel that search results are different to all other pager results (since they alone are not displayed as a table in the admin section), and should have their own special setting.

Jaza.

Yikes! I seemed to have uploaded the wrong patch in my last post. Here's a new one.

Thanks for the patch Jaza but when this was discussed on the developer list I think the concensus was to not have this overridable via a URL parameter. So my new patch only provides for the new variables.

discussion at http://lists.drupal.org/archives/drupal-devel/2005-10/msg00301.html

Updated patch to work with HEAD. I did not change search result lengths in user.module and search.module. Should they get an extra variable, or just use admin_pager_normal?

love the idea, but it's do for a re-roll

reroll
used a new function for better readability/usage

test:
1. fresh install
2. enable "devel generate" module and generate some stuff (http://drupal.org/project/devel)
3. change variables pager_limit_long and pager_limit_short in {variables} table
4. go to admin/settings/performance and click "clear cached data"
5. visit pages where pager is used
6. check new pager_limit_* variables for taxonomy and poll modules at install/uninstall

problem:
I think upgrade from older drupal version does not create pager_limit_long and pager_limit_short variables, which result in that all pagers using these variables will be defaulted to limit 50

there is still a variable default_nodes_main which is used for similar purposes. i don't know if i can remove it..

reroll

I think there will be too many variables, I will try to store it into 1 variable like the theme_settings variable is stored.
Or is it an overkill?

patch stores all pager limits inside variable pager_settings

and bonus: the module which provides easy way to change all your pager limits

inspired by String Overrides http://drupal.org/project/stringoverrides

Having hard-coded limits is a real limitation, especially for the search page, so I'm marking this as must-have i.e. critical for 7.x.

Thanks to Pasqualle for getting it this far.

This still applies cleanly to Drupal 6 HEAD.

I'd love to see this fixed in 6 if possible. Here's the cheap hack I'm using at the moment.. in search.module, this:

$result = pager_query("SELECT * FROM temp_search_results", 10, 0, $count_query);

becomes this:

$result = pager_query("SELECT * FROM temp_search_results", isset($GLOBALS['pager_override']) ? $GLOBALS['pager_override'] : 10, 0, $count_query);

Then you just need to set $GLOBALS['pager_override'] before calling a search. Not a good or comprehensive fix, but might get you by if you're looking for an easy way to change that number for some reason.

If others would support the idea, I would like to change the second parameter in functions pager_query() and theme_pager().
Instead of $limit the $pager_type or $pager_id would be appropriate.
like:

Or change it to an array to support alpha pager like {'#limit' => 'short', '#type' => 'alpha', '#options' => array() }
Any suggestions?

+1 for supporting default constants 'short', 'medium' and 'long' in pagers, whose value can be reconfigured. This would emulate the behavior of the date API.

Of course, sending in explicit numeric values should still be possible.

Note: '#hash prefixed keys' are only used in array trees of arbitrary depth, like forms. They're used to distinguish a property from a sub-item. We have no sub-items here.

drupal.org really needs a true watchlist function

Here is a solution better than using globals:
http://drupal.org/node/166172

use: variable_get('search_num_results',10)

I still don't know why it's not possible to get this "fix" into Drupal 5.
I wouldn't consider it a "feature request" but more of basic functionality that was left out.

Drupal seems quite serious, and even though you could just update line 871 to the nmber you prefer it feels dirty and "hackish" to update core files.

Is there a place were we can vote to include these type of "fixes" into 5.x?
thanks