[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