Hard coded pager limits
| Project: | Drupal |
| Version: | 7.x-dev |
| Component: | base system |
| Category: | feature request |
| Priority: | normal |
| Assigned: | Unassigned |
| Status: | patch (code needs work) |
I have a need to expose some of the core druapl pages (logs, users, comments etc)
in a view with limited space available. I noticed that the page size
is hard coded in most core modules that use drupals paging mechanism. A
quick glance reveals the following hard-coded pages sizes:
watchdog = 50 lines
user = 50 lines
statistics = 30 lines
comment = 50 lines
poll = 50 lines
I think it would be really usefull to provide a mechanism to override
these hard-coded values. I would suggest something simple like
appending a value to the url in the query string for page size. This
value could be interogated by each module that calls
theme_pager_link() to see if it should use it's hard-coded default or
use an override.
The comment module already makes use of this method to display it's
normal comment view (though not for it's admin view). I also found a
couple of instances where a variable was being used to determine the page
size as well. For these cases the variable could still be used but the query
string value could be used to override it.

#1
#2
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.
#3
#4
#5
patch can be accessed here http://mycivicsite.com/page_size.patch
#6
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.
#7
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.
#8
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
#9
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?
#10
love the idea, but it's do for a re-roll
#11
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..
#12
reroll
#13
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?
#14
patch stores all pager limits inside variable pager_settings
#15
and bonus: the module which provides easy way to change all your pager limits
inspired by String Overrides http://drupal.org/project/stringoverrides
#16
#17
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.
#18
This still applies cleanly to Drupal 6 HEAD.
#19
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.
#20
If others would support the idea, I would like to change the second parameter in functions
pager_query()andtheme_pager().Instead of
$limitthe$pager_typeor$pager_idwould be appropriate.like:
pager_query($query, $pager_type = 'short', $element = 0, $count_query = NULL)theme_pager($tags = array(), $pager_type = 'short', $element = 0, $parameters = array(), $quantity = 9)
Or change it to an array to support alpha pager like
{'#limit' => 'short', '#type' => 'alpha', '#options' => array() }Any suggestions?
#21
+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.
#22
drupal.org really needs a true watchlist function
#23
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
#24
#25