Make WordPress Core

Opened 5 years ago

Last modified 20 months ago

#45138 new defect (bug)

mixed line endings: wp-config-sample.php uses CRLF (windows) line endings

Reported by: mattpr's profile mattpr Owned by:
Milestone: Awaiting Review Priority: normal
Severity: trivial Version:
Component: Upgrade/Install Keywords: close
Focuses: Cc:

Description

Not sure if this is on purpose? Looks like it has always been that way.

# curl -s -N "https://core.trac.wordpress.org/browser/trunk/src/wp-login.php?format=txt" | head -n1 | hexdump -c
0000000   <   ?   p   h   p  \n
0000006
# curl -s -N "https://core.trac.wordpress.org/browser/trunk/wp-config-sample.php?format=txt" | head -n1 | hexdump -c
0000000   <   ?   p   h   p  \r  \n
0000007

Change History (5)

#1 @knutsp
5 years ago

  • Keywords close added
  • Version trunk deleted

Many are those who has used Windows Notepad to edit and save it as wp-config.php. LF only line endings look very bad and will confuse those more than necessary. For many of those, wp-config.php will be the only php file they ever edit.

As long as consistent within the file, and that file only, I don't think it is, or should be regarded as, a bug.

Last edited 5 years ago by knutsp (previous) (diff)

#2 @mattpr
5 years ago

Okay. I was just quite surprised to find a mix between files. Not common to see that in large projects.

It came up for me because my own deployment is scripted as well as my backup and restore.
Some of that involves scripted file editing (sed, etc)...which of course leads to a mix of line endings within the file with windows line endings.

Editors like vim (or notepad++, etc) are smart enough to detect the file line endings and be consistent with their edits...although I grant you Windows Notepad probably isn't.

Don't have an issue with windows line endings...if wordpress is setup for windows line endings, then I just factor that into my provisioning stuff. When it is a mix where some files are CRLF and some files are LF...then it is more messy because I can't set one default but need to check every file every time and potentially do a conversion.

I am sure Windows Notepad users are more helpless than I am, so if that is a big part of your user base, then I guess it makes sense to stick with a system that is more friendly to them (ie make the one file they are likely to edit appear properly in the only built-in plain text editor on their system).

I can just add line ending checks/conversions to all my provisioning code now that I know you use a mix of line endings.

#3 @SergeyBiryukov
5 years ago

  • Component changed from General to Upgrade/Install

Hi @mattpr, welcome WordPress Trac! Thanks for the report.

Not sure if this is on purpose?

It is, see #12775 (also #20890 and #28187).

That said, I think being able to edit the file in Windows Notepad is actually a disservice to most Windows users, as it inserts the UTF-8 byte order mark, causing the Headers already sent PHP warning (as seen in #27373, #27974, #28490, #32575, #33626, #36213, #37036, and some other tickets).

The issue mostly happens in non-Latin locales, where wp-config-sample.php is translated and includes non-ASCII characters. The solution is then to re-save the file in UTF-8 without BOM using Notepad++ or other editor.

Warning: Cannot modify header information - headers already sent by (output started at .../public_html/wp-config.php:1) has been the top FAQ entry on https://ru.wordpress.org/support/ for almost 10 years now. The page specifically advises against using Notepad for editing wp-config.php.

So, while the original intention was to make it easier to edit the file in Notepad, maybe we could reconsider that?

On the other hand, more and more people these days get WordPress from their hosting provider without manually editing files, so perhaps making the change now is not worth it.

#4 @hellofromTonya
20 months ago

Revisiting this issue today's state.

It looks like the problem was solved in Windows 10 1809 (released 13 Nov 2018) when Notepad got an extended line endings support update:

Starting with the current Windows 10 Insider build, Notepad will support Unix/Linux line endings (LF), Macintosh line endings (CR), and Windows Line endings (CRLF) as usual. New files created within Notepad will use Windows line ending (CRLF) by default, but it will now be possible to view, edit, and print existing files, correctly maintaining the file’s current line ending format.

As @SergeyBiryukov wonders:

So, while the original intention was to make it easier to edit the file in Notepad, maybe we could reconsider that?

For those people who are using Windows 10 1809 or greater, Notepad should understand and work correctly with other line endings. However, those on previous versions would still be impacted, if they are editing wp-config.php using Notepad.

On the other hand, more and more people these days get WordPress from their hosting provider without manually editing files, so perhaps making the change now is not worth it.

True. What about developers and implementers who are on Windows' machines running less than Windows 10 1809 who use Notepad? Support for Windows 10 doesn't end until 14 Oct 2025.

I'm thinking it's likely not worth it until Windows 10 EOL, i.e. after 2025.

@SergeyBiryukov what do you think?

#5 @mattpr
20 months ago

Great to hear notepad finally plays nice with files created on other systems (other than the BOM).

While it is great to make wordpress accessible to non-technical users (ie the types that use notepad), many of those non-technical users may not even be aware of notepad's existence or the difference between plain text, rich text and word documents. If we are going to point non-techies at notepad anyway (which it sounds like we don't want to do due to the BOM)...we might as well point them at notepad++ or VScode.

I advise non-tech people to avoid self-hosting wordpress. There is a high chance they get hacked via a poorly written plugin or poorly configured VPS. A lot of the spam I get originates from hacked wordpress installs. I know a couple e-shops that threw in the towel after their poorly self-hosted wordpress was hacked and it was too much effort to recover.

I'm not sure having "zero bar" for non-techies to install/configure/self-manage wordpress should be the top priority. But that's just my opinion.

Note: See TracTickets for help on using tickets.