Move readme.html & license.txt out of project root (maybe into Uploads?)

[johnjamesjacoby]

On the majority of WordPress installations, it is possible to navigate to 2 files that are outside of the control of PHP:

• ​https://nacin.com/license.txt
• ​https://nacin.com/readme.html

One could argue that it is a good thing these files are visible; that the GPL license is something worth sharing at the root, or that the Famous 5 Minute Install is still an idea worth promoting.

However, it is not uncommon to re/move these files, or otherwise obscure them via other means (server configurations, running WordPress in a subdirectory, etc...)

• ​https://ma.tt/license.txt
• ​https://wordpress.com/license.txt
• ​https://wordpress.org/license.txt

All of the immediately above URLs do not work, and result in a 404 page.

---

Some folks recommend removing these files as a security precaution, though I'm not confident this ultimately protects from very much.

Some folks delete these files from their internal WordPress forks simply to reduce their maintenance footprint, particularly when they do not need to distribute their changes.

Ultimately though, I have always considered these files to be assets that belong inside of WordPress, not outside of it. license.txt is important to the person who downloaded and installed it, not to any visitor of the site, and the same can be said about readme.html. That's why, I believe, these assets would be better served as part of the Default Site Content, specifically inside the Media Library.

I'm imagining that, upon a successful installation, these files would be moved out of the root of the installation, and into corresponding Media Attachments, as the very first 2 files in the Media Library.

• This helps promote the ideologies of the GPL to end users, and hopefully forces us to consider how valuable the content inside of readme.html really is these days (it still links to Planet, IRC, the Codex, and a number of other deprecated locations.)
• This helps users familiarize themselves with what kinds of files can exist inside the Media Library (.html is not an allowed file type, so this would likely need a total rethink, maybe a .txt file is sufficient?)

The reason I'm including the proposed solution above, is because I think these files still need to exist in the root as part of the pre-installation experience. Once installed, though, these files become invisibly burdensome on the web server, as they are untracked in PHP and rarely changing in the WordPress project.

This is another one of those far-out JJJ ideas that I'm not expecting much serious traction on, but I do think would be a welcome improvement to the overall WordPress installation process. Other OSS projects do something similar with their own bundled assets (NextCloud, GitLab, etc...) so this is not a completely new idea.

[dd32]

In my humble opinion, I personally disagree with several fundamental ideas behind your train of thought, but I like where you're going with it.

​https://wordpress.org/license.txt
All of the immediately above URLs do not work, and result in a 404 page.

That sounded like something we should fix, it now loads the WordPress.org License info page instead.

Some folks recommend removing these files as a security precaution

We're both on the same page here, removing them only removes one minor way to identify a site as running WordPress - removing them provides no benefit what-so-ever (Sorry security plugins who love to block these files).

Some folks delete these files from their internal WordPress forks simply to reduce their maintenance footprint

"Some" here would be the incredibly few people who track WordPress in their own VCS system, there's no legitimate reason to remove the files to reduce the burden here since WordPress is just going to add them back in (if using WordPress upgrades, o many 3rd party tooling) - although their lack of being on the filesystem should no longer force WordPress to abort using partial upgrade packages when it finds them missing for minor releases - but it'll add them back for the next major upgrade.

Once installed, though, these files become invisibly burdensome on the web server, as they are untracked in PHP and rarely changing in the WordPress project.

I really struggle to see where you're coming from here, they're not "untracked" unless you consider wp-login.php to also be untracked - they're treated the same as any other WordPress file and updated/refreshed with each WordPress update, they're not left to rot, and are only invisible if you never knew they existed in the first place (which is the ideal situation - most end-users shouldn't need to see these specific files) since the content (as i'll go into below) would be far better off presented in an entirely different manner.

Ultimately though, I have always considered these files to be assets that belong inside of WordPress, not outside of it.

That I can agree with; however, these files are not intended to be used within WordPress, they're specifically designed for use outside of WordPress, and given that these two use-cases are significantly different, it makes very little sense in combining it.

What I think you really want to say here, is that you feel the content of these files provides useful content to the end user, specifically, so that they a) understand the license of what WordPress is (license.txt) and b) understand the requirements of WordPress and where to get support (readme.html).

On the license front - Linking to, or displaying the raw license, is a common way for software to present it to the end-user, but is one that is ignored and never read by the vast majority of even technically minded people - I doubt many of the WordPress users who would appreciate what the GPL provides to them would ever actually read the GPL and not get bored. So I don't think that's the right approach for WordPress. I actually appreciate the effort that has been taken in the About section, viewable at a URL similar to ​https://dd32.id.au/wp-admin/freedoms.php (Toolbar -> W -> About WordPress -> Freedoms). That page does a great job IMHO of explaining what freedoms the license gives, although it lacks in actually defining the license and the actual license text is at least two clicks away from the page, it's a lot more useful to the average WordPress user than the raw license ever would be. I obviously think that could be improved, in both linking to the license text and explicitly defining what it is (Rather than just "GPL")

On the Requirements and Support front, I wouldn't mind seeing the requirements spelt out somewhere, but for the majority of users, Site Health provides a better insight into that than what listing the requirements ever would. Support is available through the Admin Toolbar with the W menu listing Documentation (Codex - That should be updated), Support (Forums), and Feedback (Feedback Forum). I think we could obviously do better there as well. I would even argue that a "Where to get help" in the about section would be a useful addition, pull the support section from the readme and expose it there in a nice readable manner - although that will also show that readme.html probably needs it's support section updating.

tl;dr: I'm not against exposing this data more, I just don't believe it's the right format to be doing it in. Just my 5c.

[apedog]

These two files might belong in a WordPress installation (well, pre-installation anyway) but I don't feel they belong in my database. I don't want them in my SQL tables nor in my uploads folder. Why spread the clutter?

These files are as useful as wp-config-sample.php - very useful up until the point my site is up and running. Not so much afterwards.

Maybe they can find their home as links next to about.php credits.php etc. It would certainly give them the visibility you feel they need.

[johnjamesjacoby]

I really struggle to see where you're coming from here, they're not "untracked"

Bad word choice on my part, but I couldn’t think of anything better at the time.

By untracked, I meant to convey that these files are uniquely served raw and without any PHP intervention, unlike favicon.ico and robots.txt which both have handlers when the files are not otherwise present (or filtered in some other way.)

I don’t think license.txt or readme.html are the kinds of files that make sense to handle dynamically like a favicon or robots file, but I also don’t think it makes sense to bundle them in the root of every single installation, especially when no commonly popular Apache or Nginx ruleset for WordPress have ever attempted to 404 them, redirect them, or anything else.

So step one in my mind is to find a way to simply remove these files. Step two is to make that way feel intentional, possibly as an improvement.

macOS ​famously ships with a not-so-hidden copy of the “Here’s to the crazy ones” speech. I do still think it would be fun if WordPress shipped with the GPL license as an Attachment that a User might read, as opposed to a raw file they never will. That’s just a single idea off the top of my head, to soften the blow of WordPress not shipping with a copy of the GPL license at all, which isn’t what I’m suggesting. Hopefully that clarifies somewhat?

[tobifjellner]

I don't like the idea of moving these files into /wp-content/uploads

1. Some WordPress installations may place the /uploads directory even on a separate server. The WordPress installation shouldn't really put anything in the uploads directory.
2. The file readme.html is updated now and then. It includes important information about WordPress' environment demands. But a system update shouldn't never change anything in the /updates directory.

Also keep in mind that several translated versions of WordPress will either replace these files and/or add a localized version with a different name.
If we move license.txt and readme.html, then we would also need to shuffle around the corresponding localized versions.

[bradparbs]

What about having these live inside of WordPress as content in the admin? Similar to how about.php has information about the GPL / freedoms / etc. I think promoting the "About" page to be an always-present submenu on Dashboard that has links to the readme / license would work there.

When I was looking at about.php just now, I noticed that the license link doesn't even use license.txt, it links to ​https://wordpress.org/about/license/, just shows how unused the license.txt file is.

100% agree that these probably have a better home than the root of the project.