@Chardonneaur
Hello,
when using Microsoft Windows, either on Google Chrome or Firefox, when exporting a pdf it is in fact exporting a php file. This issue is not happening on GNU/Linux OS.
@sgiehl
Hi @Chardonneaur
Could you please describe that a bit more in detail and maybe provide a list of steps to reproduce?
Sure, Microsoft Windows users only, browser (Firefox or Google Chrome):
--> Click on admin.
--> Click on Email report.
--> Create a report with file format PDF.
--> Once created click on Download. It will open up a tab with the pdf, then click on download the pdf within this new window... the result is ... a php file.
Hm... that's interesting. We are actually sending a header like
`Content-Disposition: inline; filename="matomo.org_-_Sonntag_6._Mrz2022-_test.pdf"``
I'm not sure why the browser doesn't use that. Might be an issue with the windows file dialog maybe. Not sure if there is more we could do about it.
@Findus23
Can you check if renaming the file to .pdf gives the expected PDF file?
If not, then maybe your webserver is not properly set up to execute .php files in all cases.
Gonna try that out, thank you guys.
@Findus23 the problem is not solved when renaming the .php file into .pdf.
I guess we could only change to Content-Disposition: attachment and force the browser to do a download instead trying to display it inline.
@Chardonneaur In that case can you try opening the .php file in a text editor to see if you actually see PHP code in it. If so, then this is probably not a bug in Matomo, but in the webserver setup.
@Findus23 I'm able to reproduce that on my windows machine. Clicking the download link correctly opens the PDF in the browser. But trying to download it suggests index.php as filename and at least for me always fails du to a "network" error. Maybe its a problem that the PDF is generated with a POST request. Might be that the download then tries to fetch the same request with GET and fails due to missing token auth.