TYPO3 Core

This kind of thing happend to me as well, but I don't understand it either.

BTW it's the same for t3d page tree exports...
Last time I just removed the line breaks (AFAIR there were two!) in the beginning of the t3d file and it worked.

Would be nice if someone finds out if there is any logic behind it or if it's happening randomly! ;-)

I tried to track the generation of the output but I failed. I think it may have something to do with output buffering (gzcompress?) but really don't now. Perhaps it's some LF in one of the lib files being loaded.

Anyway, I am for implementing the workaround to ignore all leading LF (or simply all whitespace).

If the decision is not to make the woraround, then please update the comment in the ext.mng. Currently it says the MD5 doesn't match. This is NOT true. It's the LF.

TATAAA!

It were the trailing LFs and spaces at the end of the files (after ?>) I don't know how they got there. It may have been me accidentally when adding some debug code. But this may happen anytime, with any 3rd-party code. So we need a solution. And I have found one:

As the very first comman in mod/tools/em/index.php we add an ob_start(). Before we do any includes or requires!

And in extBackup() we add another line right before "echo $backUpData;":

while (@ob_end_clean());

And that's the end of our worries.

Attached one patch to ignore leading whitespace (to be compatible with old broken archives) and one to suppress any "rogue output" (to prevent new broken archives). Diffs of typo3/mod/tools/emindex.php are against 3.7.0-RC1.

Thanks, I have applied the patch_ignws.diff to the EM in CVS for 3.7.

The problem still exists in t3d page tree exports though.
I'll write this on my todo list, but if someone else does it, fine with me.

Why didn't you use the other patch as well?

Please file a bug for the page tree stuff. Please include details tso the relevant files can be found.

hi masi,

doesn't the patch_ignws.diff fix the whole problem?
The leading whitespaces aren't a problem anymore if they are ignored by the import script, are they?

Apart from that, I was not 100% sure about the patch_sprws.diff because I could not reproduce the whole thing about whitespace when I tried it.
I entered many linebreaks at the end of class.t3lib_div.php but they were not included in the output t3x file even without your patch applied.

BTW, if I just applied your patch, the EM would completely break, because in a comment ( preceded with // ) you had a "?>" which ended the whole PHP section.

Anyway, if you are sure it works well and cannot possibly cause any problem, than I'll include it into 3.7.1.

cheers,
Ingmar

Masi, can I close this bug?

Well, all patch_sprws.diff does is to add

while (@ob_end_clean());

before

echo $backUpData;

As explained it saves us from any unwanted output that has slipped in accidentally (eg whitspaces in included 3rd-party lib or added by someone in a "debug-session").

IMHO, it's better to try to produce correct output rather than to be generous in input. But yes close the bug, either with apllied patch or without.

Hi Masi,

see Ingmars questions:

doesn't the patch_ignws.diff fix the whole problem?
The leading whitespaces aren't a problem anymore if they are
ignored by the import script, are they?

Since both Ingmar and I cannot reproduce the problem, I'd like to know if the bug is still occuring or not.

I agree now agree that the other patch_sprws.diff should be used as well, sorry for not using it right away!

Because that would also catch PHP error messages/warnings such as "mysql_fetch_array(): supplied argument is not a valid MySQL result resource..." in the beginning of the output, wouldn't it?

If only whitespece were the problem, I'd not use patch_sprws.diff.

I did not try it with PHP warnings, but as they are written on the standard "stream" I think my patch will supress them as well.

But you have to make sure that the ob_start() is the very first statement in the script!

This has been resolve quite a while ago...