I was wondering is there a reason why pager is not included in views PDF? If for example someone wishes to export a large number of results to PDF then being able to export results paginated would be really useful.
For example, I have a simple paginated view with a corresponding export to PDF link in every page, and I am trying to export only the current page's results(eg my_page?page=1) by adding the page url parameter to the corresponding 'PDF export' link (eg ..my_page/export_to_pdf?page=1).
By setting: 'use pager' => TRUE, inside the views_pdf.views.inc I manage to accomplish that easily so I was wondering if there is a particular reason for this setting ('use pager') to be by default set to FALSE
| Comment | File | Size | Author |
|---|---|---|---|
| #9 | allow_pager-2491949-9.patch | 1.33 KB | vegansupreme |
| #6 | allow_pager-2491949-6.patch | 1.32 KB | abu-zakham |
| #3 | allow_pager-2491949-3.patch | 473 bytes | abu-zakham |
Comments
Comment #1
cdeces commentedSubscribe.
An option to inherit pager (like in views attachment) would be really helpful to print only a portion of the records.
Comment #2
vegansupreme commented@fgiannar, I can only guess that 'use pager' is false because having a pager render at the bottom of a PDF probably wouldn't work. But you bring up a different and interesting use case. Could you post a patch?
Comment #3
abu-zakham commentedComment #4
abu-zakham commentedComment #5
vegansupreme commentedI've tested this patch and it looks like it may have an undesirable effect on existing PDF displays.
There are cases, and I suspect they may be fairly common, where existing PDF displays change from: "Items to display:Display all items | All items" to "Use pager:Full | Paged, 10 items"
If the master display is set to "Use pager:Full | Paged, 10 items" which is the default, then when this patch is applied, the PDF display changes to "Use pager:Full | Paged, 10 items" even though the PDF display was previously set to "Items to display:Display all items | All items"
I'd like to see if this can be resolved before committing. Otherwise there could be many users whose PDFs will only display the first 10 items after updating. This will seem like a bug, requiring them to update all their PDF displays.
This patch does work as intended, in allowing "?page=0" etc… to be added to the URL in order to break up large PDFs. If you need this functionality, this patch should work great.
Comment #6
abu-zakham commentedHi vegansupreme,
I've implement hook_updat_n in module.install to update all PDF displays that use default pager to Views PDF default one, "Display a specified number of items | 10 item | 0 Offset ".
Hopefully this patch will fix the issue without affecting old views.
Best regards.
Comment #7
vegansupreme commentedShouldn't it be something like this?
instead of
$display->display_options['pager'] = array('type' => 'some', 'options' => array('items_per_page' => '10', 'offset' => '0'));I'm not sure if my example is exactly right, but the patch seems to be changing the PDF display to show a specified number of items: 10.
It does seem like the right approach though. Thanks for the quick patch update!
I wonder should we mention anything in the documentation block about updating features if there are any Views PDF in code?
Comment #8
abu-zakham commentedHi,
After creating many PDF display with different "Master display" pager settings, always the default pager is "show a specified number of items: 10", you say this patch seems to be changing the PFD to show ..., yes you are right but this patch will change only PDF displays that still on default settings, If you already change the default pager and apply patch number 3 your display will not affected, patch number 6 will handle the displays that on default pager settings, and we can announce people to check all PDF displays just to make sure everything is okay.
Thanks you in advance.
Comment #9
vegansupreme commentedHere's a slight tweak to abu-zakham's patch. It keeps existing views using whatever settings they had before. Whether set to 'display all items' or 'Display a specified number of items'.
Comment #11
vegansupreme commentedI've committed this patch. Please reopen this issue if there are any problems. Note a DB update is required for this patch. Also, I'm considering a new point release soon. I'm not sure if this patch should stay in DEV for a little longer, or if it would be best to include it in the release. Please let me know if you have an opinion!
Comment #12
argiepiano commentedThis patch in #9 breaks Views. The issue is line 74.
In SOME cases, line 74 results in
display_options['pager'] = NULL;. This basically BREAKS Views.This NULL value happens if the pdf display's
display_options['pager']was not previously set (that is, if the PDF view pager was untouched and was the same as the Master)The quickest solution is to get rid of line 74. This will cause the pdf display to revert to a full pager, with 10 items, which is what is provided by Views when you create a new View. This is regardless of whatever pager setting you used in your Master. But I see in the comments above that this was not ideal.
I'll provide a patch shortly.
Comment #13
argiepiano commentedComment #14
argiepiano commentedI've created a new issue to offer a patch to the specific aspect I discussed in #12. See #2844799: Update to version 7.x-1.6 breaks some Views
Since the faulty patch offered in this issue was already committed, I will change back status to Fixed for clarity, even though the patch created a new problem.
Comment #15
argiepiano commented