The OED temp file will only be added to doctemplates after I have fetched the PatientName document via the patients account.
Patientname doc: Patientname.txt (29 Bytes)
The OED doc fetched from Patientname doc: OEDLxAhKV (48 Bytes)
No PHP errors are shown
They appeared a couple of minutes later!
Can you view the file OEDLxAhKV from FTP. I need to make sure the file is written incorrectly and not from download!
Also do you know what php version you are using? This may be an encoding issue.
PHP version 5.6 …
I had to make a new one (already deleted the previous one):
New one: OEDvqO4Ct (30 Bytes)
This one is from the FTP
Okay, looks like the app is parsing and writing to drive correctly. Nice to know!
Remember you can’t use word docx but saved as odt.
I’d check several templates downloaded with FTP to ensure we’re okay to that point. PHP 5.6 sets encoding auto so should be utf8.
Can you download the uploaded main template file okay from Document Template Management. Should look same as what was uploaded. If not then i’m befuddled and may need to get somebody that deals with this IT stuff. From what I can see, the software works. Must be environment…
In the Document Template management is the uploaded document readable via the FTP, the download option, in the Document Template management, for the Patientname as well the OED document are unreadable.
All the uploaded docs via Document Template management are in the FTP readable.
So it’s the download. About the only thing left for me to do is try sending with some additional headers. I’ll send another file here shortly.
You might try Googling issues with corrupt downloads from PHP, encoding and/or locales. Try http or https. I just don’t know w/o duplicating issue myself so I can do debug magic…
Corrupt downloads from php happens more often, A common solution mentioned on the internet: https://stackoverflow.com/questions/29906595/laravel-5-file-downloads-invalid, OR https://stackoverflow.com/questions/8853568/downloading-file-is-corrupted-header
Note: the server is not properly cleaning the output buffer, especially the code"ob_end_clean();" works well!
However, I don’t know in which file I have to add the lines. Download_template.php?
Because the code was already in the download_template.php document, I deleted the ob_clean and flush code. Result: fetching the documents via patient=>documents works partly. Opening the document in Word and letting Word reparing the document gives the result … strange!!
That did the trick, fetching the document and open in openoffice works!!
What was the issue?
You added
error_reporting(error_reporting() & ~E_NOTICE);
ini_set(‘display_errors’, 1);
mb_internal_encoding(“UTF-8”);
AND deleted: Flush
correct?
This was debug stuff and multibyte may be issue but doubt it. I did add character set to header content type: header(“Content-Type: $mimetype; charset=utf-8”); and set cache control to private:
header(“Cache-control: private”); Also, ended the output buffer instead of
ob_clean();
flush();
So here is a source for release. Took out debugging and multibyte. If this file works then your good to go.
download_template.php (14.0 KB)
I implemented download_template.php and it works!!!
Thank you very much for all your work and patience.
What do I owe you?
hi @sjpadgett and @Ralf_Lukner , The session/cookie fix will be in the first 5.0.2 patch (guessing it will go out in a couple weeks). Here is the fix if you need it earlier: cookie/session fix and a path fix (#2615) · openemr/openemr@22f3c7c · GitHub
(just the code in the login.php script)
You owe me nothing. I know how hard these types of issues can be for folks. In this case we had a perfect storm of symptoms.
Now, if you wanted to make a small donation to OpenEMR to help defray the cost of this forum then, who am I to tell you how to spend your money. 
Until next time.
I will do, thanks …
Thanks. I’ve already have on my server. Seems to be working back to way it use to work. Still testing though.