Hello,
While the Grouping field works perfectly on the view, it does not group by correctly on the PDF page.
The same field is selected in the View Table settings and in the PDF Page Table settings (Grouping field).
Am I missing something?
See attached screenshots
Thanks!
Anne Marie

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

_cam_’s picture

subscribe for version 7.x-1.0-rc1 as well

lame’s picture

I've rolled a quick & dirty patch to get the grouping field working in one use case (simple category headings for a table view on a two-page document), but this is against the latest 7.x version from Git, not 6.x-1.0.
There didn't seem to be a simple bug to fix; there is already a function views_plugin_style::render_grouping in the base class, but this wasn't being used at all, and PdfTemplate::drawTable needed refactoring so that it could produce multiple sub-tables (one for each grouping) while still tracking the overall position within the document. At the moment I've not added anything to the UI to style the group headings, and the updating of numberOfRecords in views_pdf_plugin_style_table::render is almost certainly wrong. It might be better to do some more drastic refactoring, affecting PdfTemplate::renderRow as well, before trying much more with this.

cybermache’s picture

If "drastic refactoring" is needed would it be better to have individual pdfs per grouping? As in we would have a HTML page of multiple tables according to their grouping field. Under each table would be their pdf icon for a printout of that group. I understand that if the current function was working for 6.x it would print one page that contained all the groupings. I can see how my suggested change could be done by a views exposed filtering form as well. But, setting it up to separate by grouped field might have other benefits in the long run.

Also is someone working on the 6.x patch or should the Version be changed to 7.x to reflect this discussion better?

lame’s picture

I can't speak for the maintainers, but it seems as if a hybrid HTML-PDF approach isn't just a refactoring, but a different module from Views-PDF (but of course that might be a desirable thing in itself, if someone wanted to work on it). If I update the patch I'll change the version here to 7.x, but an update depends on having some way of checking that it doesn't break the existing behavior of the module in unexpected ways.

kevin.mcnamee@mailbox.org’s picture

Subscribing

zikaelismik’s picture

I'm tryin to replicate the behaviour of normal views where i list content (products) grouped by taxonomy terms (category) hiding the taxonomy term in the field section and just setting it as a group field but as a result the category is not printed on pdf.
Using 7.x dev version.
Is there anything new on this issue?
Is the above patch working somehow?

Zik

Simon Georges’s picture

Version: 6.x-1.0 » 7.x-1.x-dev
lame’s picture

The previously posted patch no longer applies cleanly, so here's a revision against a recent clone of the 7.x-1.x branch.
Most of the commits since the original version didn't conflict with it directly.

commit aec75710db3dce6a112e9f23ece5a503f5275d99
Author: Christian Steiger <e-mail@christiansteiger.eu>
Date:   Wed Feb 1 15:12:27 2012 +0100
	Issue #1280394 by Zuzuesque: fixed by applying the patch http://drupal.org/node/1280394#comment-5434618

was the one real conflict, and the commit to fix #1252660: Weird stuff with table view was duplicated.

Simon Georges’s picture

Status: Active » Needs review

Patch needs review.

giuvax’s picture

I found this issue because I got many errors in my log, similar to this:

Notice: Undefined index: eval_after in PdfTemplate->renderRow() (linea 506 di /home/sapories/domains/saporiesapere.it/public_html/shop/sites/all/modules/views_pdf/views_pdf_template.php).

Has this error something to do with this issue? Something about rows rendering that module isn't able to do?

kevin.mcnamee@mailbox.org’s picture

Since the issue has been moved to the 7.x branch, then 6.x users might be interested in a workaround.

Generally speaking, it seems like a duplicate effort to produce a PDF document of the same content in a HTML page. I mean wouldn't it be nice to just to be able to use a regular Drupal theme to style the PDF? Shouldn't all browsers just have a "Save as PDF" function that works the same way as an embedded HTML "Print" button does now?

Anyway, the workaround I have used is to install the "Print pages to PDF" plugin for Firefox. We don't have many users, so this is an acceptable solution for us for 6.x. I used the Sections module to specify a PDF friendly theme (e.g. Marvin) and customised the style.css with the CSS attribute "page-break-before: always;" on h2 headings. Crude but effective.

/Kevin

timmay’s picture

So, the verdict is that grouping doesn't work at all for PDF Unformatted or for PDF Table, and the patch doesn't help?
This is a great module in many ways, but this is a show-stopper for most of what I'm trying to accomplish.

guillaumev’s picture

FileSize
3.84 KB

Here is a new patch. I haven't done extensive testing, but it groups rows in my case...

guillaumev’s picture

FileSize
5.85 KB

Another version of this patch, with improved grouping support.

killua99’s picture

Component: Miscellaneous » Code
Priority: Normal » Major
Status: Needs review » Needs work

I'm just moving to needs works, Cause I have to reorder the issues. That doesn't mean the patch doesn't work. Is just to start making progress to fix the module.

killua99’s picture

Priority: Major » Normal
Status: Needs work » Fixed

Lets try the guillaumev solution other solution for this user work so seen good to me. Commited.

Please reopen this issue if this doesn't work.

Status: Fixed » Closed (fixed)

Automatically closed -- issue fixed for 2 weeks with no activity.

guillaumev’s picture

Status: Closed (fixed) » Needs review
FileSize
480 bytes

Reopening this as I've found out that the grouping fields don't show up when combined with this patch:

https://drupal.org/node/2032863

Here is a patch that fixes this issue.

killua99’s picture

Need to be an is_string? could be !empty ?

killua99’s picture

+    if (($key !== NULL && $view->field[$key]->theme($row)) || is_string($row)) {

It's not better to be if (($key !== NULL && $view->field[$key]->theme($row)) || !empty($row)) {

mkostir’s picture

Hi everyone,

first of all, THANKS for such a useful module.

Not that I would have a solution to the above discussed bug, however I do have a workaround that works quite fine for me (not ideal, but it does do the job).

Scenario:

Every day a list of delivery dockets must be printed for each order. Every delivery docket must be listing all the ordered products. So Ideally, I would group all the products from the same order and place a PDF page break after this group. (but that doesn't work).

Workaround:
1/ install http://drupal.org/project/views_field_view
2/ create a view (single_docket) listing all the products for an order (this view has a contextual filter which is the order ID) - chose any format for this view (table works for me)
3/ create a view (list_of_dockets) which is simply a list of all orders that need to printed as single dockets.
4/ add a field: Global View - using the module mentioned in point #1, and add pass the order ID from each row to this embedded view as an argument.
5/ create PDF page, set it all up as usual
6/ place a pdf page break after this Global View field

Now, what happens is that "list_of_dockets" simply prints out all the orders, each order/row on a single page (thanks to the pdf page break), but at the same time, it runs another "nested" query for each row, which returns the list of products (single_docket)

If it is not clear either ask or just read documentation for views_field_view module.

However, this is merely a workaround. Not a solution to the bug.

killua99’s picture

I just commit the patch. In a few hours will be able to download in the dev branch. Test it and see what happen.

I didn't reply the scenario. I'll tomorrow

thauk’s picture

Version: 7.x-1.x-dev » 7.x-1.1

I have figured it out.

killua99’s picture

Version: 7.x-1.1 » 7.x-1.x-dev

Thauk.

Keep this in dev stage. You still have some problem?

mikran’s picture

My view doesn't even use grouping but I get this notice:

Notice: Undefined offset: 0 in render_grouping_sets() (line 48 of /.../views_pdf/views_pdf_plugin_style_unformatted.inc).

killua99’s picture

Mikran can you please submit some patch for this.

Thanks :)

killua99’s picture

Issue summary: View changes
Status: Needs review » Active

If this issue generate an extra notice. Please open a new issue. The functionality of this issue is working.

killua99’s picture

Status: Active » Fixed
mikran’s picture

#2042927: notices in style unformatted fixed the notice I was getting (comment #25).

Status: Fixed » Closed (fixed)

Automatically closed - issue fixed for 2 weeks with no activity.

rupyjl’s picture

#21 works well for me. Basically create the first view with the header/grouping info you need, then insert the rest of the information (from a separate view) as a view field.

mathes’s picture

Version: 7.x-1.x-dev » 7.x-1.3
Status: Closed (fixed) » Needs work

If the format is PDF Table grouping field still doesn't work. I looked at patch in #14 and only views_pdf_plugin_style_unformatted.inc was updated.

killua99’s picture

Version: 7.x-1.3 » 7.x-1.x-dev

mathes, can bring a patch for it?

idflood’s picture

I have tested today the latest dev version and I still can't make grouping work. The group title didn't show up and there doesn't seem to be any effect on the order/grouping of the rows. In fact I have the same result with and without grouping enabled.

edit: I found why the grouping title doesn't get displayed in my case. In views_pdf_template.php in renderRow function there is this condition:

if (empty($key) || !empty($view->field[$key]->options['exclude']) || (empty($content) && $view->field[$key]->options['hide_empty'])) {
  return '';
}

There is 2 problems: The first one is that the field is excluded since I don't want the grouping field to appear on each items.

The second one is that the $key is empty. For unformatted view this is called from views_pdf_plugin_style_unformatted.inc > render_grouping_sets, with this call:

$this->view->pdf->drawContent($set['group'], $options, $this->view);
idflood’s picture

FileSize
1.32 KB

Here is a basic patch which add a 'group_title' element to the $options array. This allow to prevent excluding the grouping title even if the field is set as "exclude from display".

I'm leaving the issue as "Needs work" since it's not possible to style an excluded field right now. I think this might need another condition somewhere to display style option for grouping field.

idflood’s picture

Status: Needs work » Needs review
FileSize
2.25 KB

I've adapted the same logic for the field option "page" so that grouping field can be customized.

There is still one problem with the above patch. The field in the items is hidden like wanted since it is excluded but it still take some space. The issue is more clear when the exluded/grouping field has a large font size. In fact it add the "position" setting of the grouping field. So if i use 10 in y position for the grouping field it will also add this 10 spacing where there is the excluded field.

edit: I've found a quick hack to fix to not add the position of an excluded field but it's not very clean since it consist of duplicating the "hide" logic from renderRow to drawContent (from views_pdf_template.php):

public function drawContent($row, $options, &$view = NULL, $key = NULL, $printLabels = TRUE) {
  ...
  $x = $y = 0;

  // Here after setting $x and $y to 0 we duplicate the hide logic from renderRow method. This mean that we may double render
  // the $content.
  // Render the content if it is not already:
    if (is_object($view) && $key != NULL && isset($view->field[$key]) && is_object($view->field[$key]) && !is_string($row)) {
      $content = $view->field[$key]->theme($row);
    }
    elseif (is_string($row)) {
      $content = $row;
    }
    else {
      // We got bad data. So return.
      return;
    }
    if (empty($options['group_title']) && (!empty($key) && !empty($view->field[$key]->options['exclude']) || (empty($content) && $view->field[$key]->options['hide_empty'])) {
      return;
    }

idflood’s picture

Status: Needs review » Needs work
killua99’s picture

So this need a reroll patch?

idflood’s picture

No reroll needed, but the patch is not complete. In fact the patch is missing the code in comment of #36.

But more importantly, I'm not sure if this is the correct way to fix this. Also, the code in comment of #36 would duplicate the mostly same code which is already just a function below.

abel_osorio’s picture

Hey!

I'm trying to make a pdf display with a grouping field. I wish to know when the module will be stable with patch applied.

Thanks a lot.
Regards.

killua99’s picture

Hi @abel_osorio what about, give us a patch to get this feature stable?

abel_osorio’s picture

No, sorry. Just i'm querying.

drasgardian’s picture

I can get primary grouping to display with the patch from #36. However, if I apply secondary grouping then the primary grouping disappears.

  • guillaumev authored 96d0d63 on 8.x-1.x
    Issue #1313404 by lame, guillaumev | ampiche: Fixed Grouping field doesn...
misterpo’s picture

Same as drasgardian here... I need 3 levels of grouping and thus can't achieve the expected result.

tiger_h’s picture

It working when using Aggregation to group fields.

killua99’s picture

Status: Needs work » Closed (outdated)