[wp-trac] [WordPress Trac] #49072: Move readme.html & license.txt out of project root (maybe into Uploads?)

WordPress Trac noreply at wordpress.org
Tue Dec 24 00:50:36 UTC 2019


#49072: Move readme.html & license.txt out of project root (maybe into Uploads?)
-----------------------------+------------------------------
 Reporter:  johnjamesjacoby  |       Owner:  (none)
     Type:  enhancement      |      Status:  new
 Priority:  normal           |   Milestone:  Awaiting Review
Component:  General          |     Version:
 Severity:  normal           |  Resolution:
 Keywords:                   |     Focuses:
-----------------------------+------------------------------

Comment (by 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.

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/49072#comment:1>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform


More information about the wp-trac mailing list