[wp-trac] [WordPress Trac] #53298: Checking if wp-config-sample.php file exists before checking if wp-config.php exists
WordPress Trac
noreply at wordpress.org
Wed Jul 12 06:04:29 UTC 2023
#53298: Checking if wp-config-sample.php file exists before checking if wp-
config.php exists
-------------------------------------+-------------------------------------
Reporter: machineitsvcs | Owner: (none)
Type: defect (bug) | Status: new
Priority: normal | Milestone: Awaiting Review
Component: Upgrade/Install | Version: 5.7.2
Severity: trivial | Resolution:
Keywords: needs-patch dev- | Focuses: administration,
feedback | privacy, coding-standards
-------------------------------------+-------------------------------------
Comment (by machineitsvcs):
I believe the main consideration to note here, whether or not the @ is
used, the order of checking wp-config-sample.php and wp-config.php should
be swapped, as most requests for a WordPress site would be for completed
installations where wp-config.php exists, and therefore checking if wp-
config-sample.php exists when wp-config.php already exists would produce
the message that the wp-config-sample.php doesn't exists instead of the
message that wp-config.php already exists.
Unless your concern is that the message stating wp-config.php exists
instructs that the wp-config.php be deleted first, and that this would
result in a broken installation if wp-config-sample.php also did not
exist, requiring the wp-config-sample.php file be re-uploaded, which is
already presented in a message if the file is missing anyway, so the
messaging wouldn't even have to change.
Regardless, in my opinion, it just seems that logically it should consider
if wp-config.php exists first, and only check if wp-config-sample.php
exists if not. Although the improved performance from removing the two
additional file_exists calls in the current version would negligable, it
should still be seen as best practice in most use-cases.
As for the security situation I mentioned, I was referring specifically
just to restricting open_basedir to not include the directory above the
web directory (which shouldn't need to be explained), and that such a
restriction, in combination with the deletion of wp-config-sample.php
file, would result in the PHP warning message in the log. That is all.
Deleting the wp-config-sample.php file in and of itself is not necessarily
a "security measure" - although deleting the file on a completed
installation does reduce the unnecessary overhead from requests to this
file, which subsequently loads the wp-settings.php file, which loads
numerous other functions for no reason, to inevitably return a "Database
Error - Error establishing a database connection" page, whereas on a
completed installation the wp-config.php returns nothing (except a 200
response) if it is even publicly accessible (I personally block public
access to wp-config.php using .htaccess). However, most do not take any
similar steps to restrict public access to the wp-config-sample.php file
if it still exists, as they assume like you did that it's a non-issue.
Which isn't wrong exactly, but I believe it could definitely be improved
upon, but that's for another discussion I guess. Hopefully this at least
helps to explain why someone, like me, would delete the wp-config-
sample.php file.
--
Ticket URL: <https://core.trac.wordpress.org/ticket/53298#comment:6>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform
More information about the wp-trac
mailing list