title and header not output?

I'm not sure but I'm having the same issue. I think its a theming template issue but I am still a noob.

The default views template of the header area looks like this

see views-view.tpl.php line 36

<?php if ($header): ?>
    <div class="view-header">
      <?php print $header; ?>
    </div>
  <?php endif; ?>

But this module's theming calls the $header and $footer variables to add the wrapping elements around the body.

see views-data-export.tpl.php

<?php print $header ?>
<?php print $body ?>
<?php print $footer ?>

This template is used on every data export type. I think the solution might be to break the wrapping elements off of into separate .tpl.php files for each data type. Then ensure the $header variable is being passed the normal data and place it within a conditional statement with a validator to ensure the data being rendered won't break the format.

But again I'm still a noob.

Also I am using 7.x-3.0-beta6

You should be able to use the header specific template: views-data-export-doc-header.tpl.php to change the header output of a DOC export.

I have the same problem. the Views header and footer are not output

To address this issue, I used the $static variable to output a header with the first row - adding a php customfield with this code:

if (!isset($static)) print "your header";
$static = true;

I have written #5 code. The code works fine. But the header text(value) is not displaying in the doc or(Any other format). Please help me. How to do ?.

I'm not sure why this issue status is set to 'fixed'. Since the header is still not showing, the problem still exists.
@Steven Jones: you suggest we do something with the views-data-export-xls-header.tpl.php? Could you explain what?

Thanks,

Mike.

Also experiencing this issue under 7.x-3.0-beta7.

May this be a lack of memory issue? Are you using memcache or something similar? How many memory limit do you have set for PHP?

Mine is set to 512M and I'm not using memcache. Edit: should have also mentioned that PHP out of memory errors are not showing up in the server log.

silurius, are you able to test it with more amount of memory assigned (like 1gb)?

Yes, I upped it to 1GB and still the exported XLS shows only view row output, not header or footer content. But I really doubt it's related to the php memory_limit setting, because (1) when php memory is exceeded there are symptoms on the frontend (slow performance, sometimes blank pages or error pages) and (2) whenever php memory is exceeded, the event gets reported in the php error log, which is not the case here.

So if you want to change the header then you just need to find the file called:

views-data-export-doc-header.tpl.php

And copy it to somewhere in your theme (beware if you're using the admin theme to do your data export) and then flush caches. This template will then get picked up an used.

Just tested this, and it's working fine for me.

Thanks, Mr. Jones. Unfortunately, I did exactly this (taking care to ensure that tpl files were in the correct theme/templates folder), retested and nothing appears to have changed.

1. Copied views-data-export-xls-body.tpl.php, views-data-export-xls-footer.tpl.php and views-data-export-xls-header.tpl.php files into theme's "templates" sub-directory.
2. Double-checked that display filters (including exposed) matched attached data export filters exactly.
3. Added a Global:text field to header area of data export display, put some text in there.
4. Cleared all caches.
5. Pulled up results in view display.
6. Downloaded to Excel, and no header content is visible.

So, because of the nature of creating export files, the view 'areas' like headers, footers etc configured in the UI will not work, sorry.

You actually need to edit the actual file: views-data-export-doc-header.tpl.php

And add the things you want in there.

The only working solution for me was editing the views-data-export-doc-header.tpl.php file. We have the access to the $view object there so we can use dynamic values. Thanks.

@heshan.lk Feel like pasting some code in here for others to use?

@omar, I have a very specific solution I did. What you all need to do is create a template file for your header, body or footer in your theme folder and update the markup. Thanks.

Just wanted to post this in case anyone else gets stuck. You can add similar code to a separate template file and it will print the region as you would expect. In my case, I was trying to add a footer to my CSV.

<?php

/**
 * CSV files don't really have a footer.
 */

print $view->display_handler->render_area('footer');

Sorry, with all due respects to the great work that already has been done here, I also clearly consider this not fixed. I cannot go along with the point that (so I understood it, correct me if I got it wrong) "this is a data export and thus no header or footer", because it does not respect all possible use cases.

I figure this is due to the module's history, which, IIRC, started with CSV and XML - in that regard, the said argument is right (but then you should at least not include "DOC", but move such displays into another dedicated child module IMO). But while you do want to provide Word docs and other data types which include some kind of end user presentation, custom header and footer (without having to dig into code, or templating) is simply what anyone configuring the view would expect. And if no one intuitively expected this behaviour, we would never had this here issue opened. Would you really disagree on this? Would it hurt anyone to improve the module design in this regard and thus make it even better?

I know, there's different opinions on template-hacking being "the Drupal way" or not, however, making things more intuitive is for sure never a bad idea, right. Also keep in mind that simply not everyone has the means to "quickly" hack templates or any prod sources. And then think of multisite installations, with probably 20 different instances sharing your module. No, you do not want this. So please, no forced template hacking. Thanks.

No offense, au contraire, your module is a great tool I would not want to miss -- but also not to "hack". There is really enough "quickly hacked" stuff all around already. Isn't it. :)

Thx for reading!

is this getting fixed in 7.x-4.x? hack the template != fixed ;) anyhow, it's a great (crucial) module, and this is no disrespect. it'd be great to have a working solution though