Bug #20843
Exporting t3x file delivers wrong data
| Status: | Rejected | Start date: | 2009-08-06 | |
|---|---|---|---|---|
| Priority: | Could have | Due date: | ||
| Assignee: | Oliver Hader | % Done: | 0% |
|
| Category: | Extension Manager | |||
| Target version: | - | |||
| TYPO3 Version: | 4.2 | Complexity: | ||
| PHP Version: | 5.2 | |||
| Votes: | 0 |
Description
Same issue as bug #M4068 which was closed without success. Please reactivate and merge with older bug #.
After saving the extension as .t3x file, I was not able to import it through extension manager on any other server. This actually is not related to the server, but due to the fact, that the extension manager for somewhat reason adds some blank characters at the beginning of the .t3x file. After removing the extra blanks, extension could be loaded without problems.
Attached .zip is the extension, and also within the .zip is a incorrectly saved .t3x file.
(issue imported from #M11661)
Related issues
| related to Core - Bug #21236: Add API functions for cleaning and flushing output buffers | Closed | 2009-10-11 |
History
Updated by Marcus Krause almost 4 years ago
Is there any reason why this issue has been set to private?
Updated by Michael Riedel almost 4 years ago
no, just because of the attachments. But I think you can unset the private statement.
Additional note on the bug - it seems that to somewhat reason every extension gets saved incorrectly, not only the attached one.
Updated by Marcus Krause almost 4 years ago
I cannot reproduce this - and I have to deal with manual export/import of extensions nearly on a daily basis.
Any special steps to do for reproducing?
OS? Up-to date libraries (aka. up-to-date system)?
Updated by Michael Riedel almost 4 years ago
I will try to debug myself. I have the feeling it is realted to some other extension or misconfiguration. Since this happens on my machine with every extension right now.
Updated by Michael Riedel almost 4 years ago
I could figure out the follwing:
in file class.em_index.php, line 2534 backup data ich echoed:
.-.-.-.-.-.-.
if (intval($this->CMD['doBackup'])==1) {
header('Content-Type: application/octet-stream');
header('Content-Disposition: attachment; filename='.$filename);
echo $backUpData;
exit;
.-.-.-.-.-.-.
$backupData contains the correct Data without blanks at the beginning. When I save the file in Firefox or IE, 8 blanks get added. Could it be it has something to do with the header? Strange.....
Updated by Michael Riedel almost 4 years ago
I was able to fix it !
by adding ob_clean() before the header() functions, it removes the blanks. So when I modify the code to:
.-.-.-.-.-.-.
if (intval($this->CMD['doBackup'])==1) {
ob_clean();
header('Content-Type: application/octet-stream');
header('Content-Disposition: attachment; filename='.$filename);
echo $backUpData;
exit;
.-.-.-.-.-.-.
Everything works great. Do you think that might make sense?
best regards
Michael
Updated by Oliver Hader almost 4 years ago
That makes sense. Using ob_end_clean() for all existing buffers would also be fine.
I guess that some PHP scripts that have been included before have some empty spaces/linebreaks after the closing "?>" tag...
Updated by Marcus Krause almost 4 years ago
As the sample extension has been removed, I hereby set the view status to public.
Updated by Helmut Hummel over 1 year ago
- Target version deleted (
0)
Updated by Steffen Gebert over 1 year ago
- Priority changed from Should have to Could have
Well.. that's just the usual "you have whitespaces somewhere" problem.. wouldn't be wrong to clean before sending the file, as it's a weird side effect, but such problems will also occur on other places.
Updated by Anja Leichsenring 2 months ago
- Status changed from Accepted to Rejected
Extension Manager is no longer responsible for delivering t3x files, so this issue is no longer valid.