CRLF added in content.htm

[ludovicam]

Hello everyone,

I just passed my site from version 1.6 to 1.7.6
On this occasion, I passed the PHP version from 5.5 to 7.1 on the OVH server

I successfully used Exchange, to save the content.htm of version 1.6,
Then to import them into version 1.7. Everything went well.

I specify that I do not use any Wysiwyg editor, only the direct edition of the source code to edit my articles.

I prepared my site on the local EasyphP server then I uploaded the elements via Filezilla on the remote server (OVH) having previously deleted the old version (1.6).

This is what happens:
Local, no worries.
On the remote site, just save an article once, without even changing it and the latter's code is added lines, an empty line between each line of code.

I believe that the easiest way to explain it to you is to show you two screen copies of the Content.htm file published with Notepad ++ configured to display line feed:
The first is the content.htm before modifying an article on the remote site.
The second is the content.htm after simply saving this article (or modified, the result is the same).
[ external image ]
[ external image ]

We can clearly see a CRLF that was added between each HTML code line.

If I open the article on the site and I display the source code, there is no problem.
If I open the article again to edit it, the code is also correct in the textarea.

Other than that, everything works very well. Ultimately, this defect is not annoying and does not prevent the site from working but it is curious and I would like to understand

(this post is translate from french on a online translator).

[olape]

Test another editor!
This does not happen locally?

You have a mix of LF and CRLF.
Is it a Linux or a Windows server?
Filezilla should actually adjust the line endings when transferring. (if it is transferred in ascii mode)

[ludovicam]

Thanks Olape for taking time to respond to me.

Test another editor!

The use of direct writing of the source code is a choice.

This does not happen locally?

Indeed, no local problem.

You have a mix of LF and CRLF.

If you mention the LF on the PHP code and the CRLF on the HTML code in the content of Content.htm, it was already the case in version 1.6 and it is the case on local server.

Is it a Linux or a Windows server?

I suppose it is a Linux server, in any case it is not Windows. It is a shared server.

Filezilla should actually adjust the line endings when transferring. (if it is transferred in ascii mode)

Filezilla has always been configured automatically so far. I hesitate to change the configuration when it worked very well before ...
And if it was a transfer problem, why would that not affect the entire file ?

I rather thought of a problem server side, at the time of the registration of the article. But I don't know the subject enough and I haven't found the reason yet.

[lck]

Do you work with macOS?
The mixing of the line ends with LF and CRLF seems to me to be the cause here. Convert the line endings to LF before transferring them to the server and test. Are the empty lines then also available online here?
 

CRLF2LF.jpg

[ludovicam]

Do you work with macOS?
The mixing of the line ends with LF and CRLF seems to me to be the cause here. Convert the line endings to LF before transferring them to the server and test. Are the empty lines then also available online here?

CRLF2LF.jpg

I guess I explain myself badly.

This problem does not occur after a transfer between the PC (Windows 10) and the server, it occurs during a modification/registration of an article on the site, therefore online.

The screen copies I provided are those of the content.htm file before and after such a modification -on line-.

And the content.htm file was not transferred directly from Windows, it is an XML version created with Exchange which was uploaded and then imported by the same plugin installed on version 1.7.

And the content.htm file does not have an additional line jump as evidenced by my first screenshot.

Well, I hope I have been clear and that the translation will be faithful (because I do not speak English and even less German).

[olape]

I guess I explain myself badly.

Non, on a compris.

Nous ne pouvons pas faire de déclaration claire. À ma connaissance, le problème ne s'est pas encore posé. En tout cas, le mélange de LF et de CRLF n'est pas correct. Et il existe déjà avant les modifications en ligne.

Essaie donc de corriger le fichier de contenu en conséquence et de le télécharger à nouveau.

Convert the line endings to LF before transferring them to the server and test. Are the empty lines then also available online here?

Rien n'est perdu. C'est peut-être la solution.
Sinon, je recommanderais, si possible, de télécharger l'ensemble du site sur un autre serveur et de l'y tester.
Il se peut qu'il y ait un problème au niveau du serveur.
Mais ce n'est qu'une supposition.

[ludovicam]

Thank you for responding to me in French but I will continue in English for those who will read these lines and who could know the same kind of mishap.

I have a start to the track. It was the transfer of the XML produced by Exchange which posed a problem.
The one present on the PC has all these lines ended by LF.
Whoever is present online and was uploaded by Filezilla has only CRLFs.
Exchange then made the import starting from this file. Only the code generated in PHP side server ended up with LF at the end of the line.
The whole HTML code from import has kept CRLF, which explains the LF/CRLF mix.

It remains to understand how to configure Filezilla because I suppose that it is ultimately the fault!

[olape]

but I will continue in English for those who will read these lines and who could know the same kind of mishap.

ok

It remains to understand how to configure Filezilla because I suppose that it is ultimately the fault!

All Text files (htm, html, css, txt, php, xml, ...) in ascii mode.
Images, videos, program files (.exe, .msi) or zip, rar, cab, 7zip, ... in binary mode.

https://ekiwi.de/index.php/906/ftp-uebe ... terschied/
Unfortunately it is in German.

[ludovicam]

This is what I did:
I configured Filezilla in default binary mode.

Then dowloaded the content.htm of the server and used Notepad++ to convert the file CRLF to LF.

Finally, I have uploaded this file to crush that of the server and after verification, it remains in LF only, even after online modifications of article.

I guess this is the solution. There is not really a choice with Filezilla.

All Text files (htm, html, css, txt, php, xml, ...) in ascii mode.
Images, videos, program files (.exe, .msi) or zip, rar, cab, 7zip, ... in binary mode.

If I understand the configuration, these files are listed as being treated as ASCII files. So that should work. To be checked during the next transfers.
In any case, thank you for the help

[ludovicam]

I noticed one thing:
There is the way to transfer a PC file to the server so that it remains in LF.

But there is also what the local server produces itself.

For example :
template.htm can be modified via the site admin.
Local, I previously converted Template.htm which was in CRLF to pass it in Unix (LF).
All lines are therefore now LF.

I open the local server (easyphp devserver), I open the local site, go to the admin and modify the template then record the action.

The Local Template.htm file is immediately transformed into CRLF.

Another example :
I modify a local article and then validate the operation.
The content.htm file previously converted to LF is with an LF/CRLF mix because the part concerned by the article modified to all its lines ended by CRLF.

I wonder if we can configure something for a local server -In a Windows environment- to work like a UNIX server