I have a view displayed with a node, and would like to use a field on the node to parametrize the number of results returned by the view. It's easy enough to get the value of that field into a contextual filter, but the pager doesn't parse tokens, so I can't do anything with it once I have it.
Patch in first comment updates the (non-date) pagers to check for tokens in items_to_show and offset fields. The alternative approach would be a separate pager plugin, which would be redundant in every way except parsing config options, but this seemed less desirable for long-term maintenance.
I tried to encourage some safety by ignoring tokens if those config options are exposed. I did not add tests (yet), figuring I'd ask for a sense of whether this functionality is even desirable first.
Comment | File | Size | Author |
---|---|---|---|
#5 | views-use_tokens_in_pager_config-2530734-5.patch | 14.38 KB | jproctor |
|
Comments
Comment #1
jproctorComment #2
Chris Matthews CreditAttribution: Chris Matthews as a volunteer commentedThe 4 year old patch in #1 does not apply to the latest views 7.x-3.x-dev and if still relevant needs to be rerolled.
Comment #3
Andrew Answer CreditAttribution: Andrew Answer as a volunteer commentedPatch rerolled.
Comment #4
Andrew Answer CreditAttribution: Andrew Answer as a volunteer commentedFix.
Comment #5
jproctor@Andrew Answer, thank you!
I tried applying your reroll to 3.22 (latest stable) and it failed in 3 places. All are because of #2885660: Warning: A non-numeric value encountered in views_plugin_pager_full->query(): 3.x-dev explicitly casts some things as
(int)
that 3.22 did not. I don’t want to lose that important change, so I added that back in.This made me wonder if we had lost anything else since the original patch; I compared by re-rolling it against 3.22 and didn’t see anything.
Also I added a couple tests to make sure the tokens are being interpolated.
Comment #6
Andrew Answer CreditAttribution: Andrew Answer as a volunteer commented@jproctor,
thank you for adding tests. I always re-roll patches to the last dev module version at the moment of my work; it allow me to use Drupal patch testing system immediately to control quality.
Look here: https://www.drupal.org/node/1054616 "Do not attempt to create or apply patches to git tags. This causes trouble for not only you, but everyone else trying to use your patch. Except in very specific and unusual cases, patch development should generally be done on branches."