[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