Make WordPress Core

Opened 8 years ago

Closed 5 days ago

#38204 closed enhancement (wontfix)

enhancement: custom pathname to wp-config.php

Reported by: gdamjan's profile gdamjan Owned by:
Milestone: Priority: normal
Severity: normal Version: 4.7
Component: Bootstrap/Load Keywords: has-patch needs-refresh 2nd-opinion close
Focuses: Cc:

Description

This patch allows for setting the pathname to the wp-config.php file with a WP_CONFIG_FILE environment variable.

The end goal is to have wordpress code separate (and possibly read-only) from the config file, and from the state (user content).

Attachments (2)

0001-allow-custom-pathname-to-configuration.patch (993 bytes) - added by gdamjan 8 years ago.
allow-custom-pathname-to-configuration.patch
0001-allow-custom-pathname-to-configuration.2.patch (1.1 KB) - added by gdamjan 6 years ago.
updated patch to latest HEAD

Download all attachments as: .zip

Change History (11)

@gdamjan
8 years ago

allow-custom-pathname-to-configuration.patch

#1 @gdamjan
8 years ago

A bit of discussion:
if I posit that an application has:

  • code (typically in /usr)
  • configuration (typically in /etc)
  • persistent state (typically in /var)
  • ephemeral state (typically /tmp)

all of those parts has different lifecycles and permissions:
for example, we never need to backup /usr since that can be retrieved from upstream (either github release, or distro packages). /usr also can be read-only (a ro filesystem, or just in relation to the user that's running the application). and can be shared between users.

configuration needs to be backed up, be writeable to the admin, but not readable to other users, and typically not writeable to the application

persistent state is images, uploads and the database, needs to be backed up regularly, is read-write for the application, but not readable to other users.

ephemeral state are caches, sessions, temporary uploads and similar, can be cleared by the sysadmin at any time, doesn't need backups. Typically this will be /tmp in tmpfs (and with systemd can be a PrivateTmp, so I don't care to configure it in wordpress), needs to be read-write to the app but not readable to other users.

with WP_CONTENT_DIR we already can setup the persistent state directory outside of the code directory. this patch allows for the configuration to be outside of the code directory too.

this makes the code directory easier to share between wordpress instances, each running as a separate user, also makes updates easier - just replace the code directory.

#2 @knutsp
8 years ago

Hello gdamjan and welcome to Trac!

wp-config.php may already be located above the code directory.

Since it's a PHP script file you may also change the file to just include or read another readable file or resource.

Why is an environment variable a better way?

#3 @SergeyBiryukov
8 years ago

  • Component changed from General to Bootstrap/Load

#4 @gdamjan
8 years ago

@knutsp of course, there are different ways I could accomplish this (I typically over bind-mount the file - though that does require root).

the reason I propose this is so that we can have a more common and standard way to have the config file outside the code directory (and outside of the /usr file-system hierarchy too).

This ticket was mentioned in Slack in #core by swissspidy. View the logs.


8 years ago

#6 @desrosj
6 years ago

  • Keywords has-patch needs-refresh 2nd-opinion added

The patch needs a refresh to apply cleanly to trunk. Also, marking for a 2nd opinion.

@gdamjan
6 years ago

updated patch to latest HEAD

#7 @iandunn
2 years ago

One drawback here might be that PHP's open_basedir would need to be configured to allow access outside the webroot, which should be done carefully (especially if the config is placed in /etc).

IIRC, some plugins and WP-CLI would need to be updated as well.

This doesn't address your desire for a standard mechanism, but another alternate approach would be keeping the non-sensitive values hardcoded (WP_LANG, WP_DEBUG, etc) in wp-config, and then using env vars for the sensitive values. e.g.,

define( 'DB_PASSWORD', getenv( 'WP_DB_PASSWORD' ) );

#8 @jorbin
4 weeks ago

  • Keywords close added

If you are trying to make wp-config only readable by specific individuals, then setting the permissions on the filesystem seems like a better approach and an ENV variable setting a file. I think this should be closed as wontfix

#9 @JeffPaul
5 days ago

  • Milestone Awaiting Review deleted
  • Resolution set to wontfix
  • Status changed from new to closed

I concur, close.

Note: See TracTickets for help on using tickets.