No, it's not in the code generated by scaffolding. The problem is in the core index.php (front controller) that handles every request. (See Oleg's link to the commit that added str_replace to the project templates.)
All HTML output, from every request, is processed by this str_replace line in index.php. It removes all unnecessary whitespace from the output: newlines, carriage returns and tabs. And that's where the 'bug' is: whitespace must not be removed within <textarea> and <pre> tags, because it is printed literally.
You can easily reproduce the bug by putting this in a view:
<textarea cols=80>
this is line 1
this is line 2
</textarea>
When viewing the output in a browser, you would expect to see two separate lines in the textarea, but instead they will be on one line, which is wrong.
There is no workaround. For instance, <br> is printed literally in a textarea. The only solution is to fix or remove str_replace.
I was working on a regular expression to fix it (works only for <textarea>, not for <pre>):
echo preg_replace(
"/(\n|\r|\t)(?!(?>[^<]*<(?!textarea\b))*(?>[^<]*)<\/textarea>)/",
'',
$application->handle()->getContent()
);
It works, but it is really slow, even though it uses non-backtracking subexpressions for speed. My testpage (~250 kB) takes about 10 seconds to process. :-|
For every \n, \r or \t it will look ahead to check if it is followed by a </textarea> tag and if there's not a <textarea> (opening) tag in between. If HTML tags within a textarea would be formatted like lt/gt instead of </>, I could just look for the next < and check if it's followed by /textarea, that would be fast. But alas, < and > are allowed in textareas, so I have to scan the entire rest of the document for every newline/tab.
But any regex is pointless if Phalcon is slowed down by it. We want it to be superfast! :-)
So the easiest way to fix this is to remove str_replace again. Phalcon's processing will be slightly faster. The increased output size is hardly noticable. For instance, a large 250 kB HTML page may grow 5%, but on relatively slow 10 Mbit line the download time would only increase by 0.01 second. A nice side effect will be that the output will have 'normal' formatting again, which makes debugging a lot easier.
