Possibility to shortcircuit WP startup about wpstarter HOT 7 CLOSED

The DB data is available in the .env file. If you just want to access WP data without loading WP, you shouldn't use wp-config.php, but the original settings in .env it gets initialized with.

from wpstarter.

Thanks for the thorough response! I was reluctant to add my particular use case when creating the issue because I wasn't really convinced this is relevant for the general issue I meant to bring up here. This being an easy way to load all the configuration plus all the extra logic happening in wp-config.php.

Anyway I've seen that you'd probably consider this an edge case that is still solvable with some extra work so it is out of scope. As far as I am concerned you can close this issue.

from wpstarter.

But for example the keys/salts are by default not in the .env file but in wp-config.php and moving them to .envdoesn't auto-regenerate them which I actually think is good.

Also some other constants that by default all get created in wp-config.php would all need to be in .env then.

from wpstarter.

What would be a use case where you need the salts outside of WP?
The way I see it, wp-config.phpis misleadingly named, as it is not a mere "config" file, but rather is the "bootstrapping" file for your WP application. Similarly, if you run unit tests, you use a different "bootstrap" file (wp-tests-config.php), which indicates that this is indeed the environment-dependent bootstrap file. So, in essence, this is the file you would replace when running your stuff in a different environment (web app, tests, cli, ...).

from wpstarter.

e.g. Cookie-Validation (Checking if user is logged in) without loading WP.

Maybe what this boils down to also is that some of the things in wp-config.php shouldn't happen/be in that file. Because as you correctly said currently it is a mix of config and bootstrapping logic.

from wpstarter.

Yes, but that is a general problem with WordPress. There's just no real structure AT ALL in there, all grown organically for more than a dozen years.

This also leads me to ask for a specific use case, because chances are that you'll need more than just wp-config.php if the .env is not enough...

I'm no expert on WP authentication, but I think that you don't need the salts for that. The salts are used at generation to create unique hashes, but the salts are then included within these hashes. As far as I know, to check if a hash is valid, the salts from wp-config.php are not needed. Otherwise, you wouldn't be able to change the salts without breaking logins.

from wpstarter.

Otherwise, you wouldn't be able to change the salts without breaking logins.

Changing salts do breaks logins, actually.

But the things are more complicated than this. Since WordPress 4.0 user sessions are stored in database (in user meta table) so by knowing the salts, you could just verify that the cookie is not corrupted, but you can't really validate it.

To validate cookie you need to access database. This is done by WordPress with WP_User_Meta_Session_Tokens which logic can be changed in future versions, so you need to keep you custom code with WP at every new version...

So if you don't want to use WordPress to authenticate users, you'll need to duplicate a lot of WordPress code and still not be 100% WP-compatible (you know, actions & filters...)

So I would suggest that implementing REST API + some auth client (see http://v2.wp-api.org/guide/authentication/) is a better way to login users in a 100% WordPress-compatible without actually loading WordPress code. But, yes, that needs an HTTP request.

If you really want to validate the cookie with custom code (and so replicate what WP_Session_Tokens and WP_User_Meta_Session_Tokens do), you have to know that WP Starter does not re-define salts if they are stored in environment variables.

If you look at code, salts constants are not defined if already defined and all the environents variables which have a name that matches a known WordPress constants are automatically used to define the related constants.

So you workflow would be:

1. create salts in .env file
2. read DB config and salts from .env file and use them to validate cookies without WordPress (you'll need to replicate WP functionality)

That's it.

Since salts are stored in .env file, WP Starter will define WordPress constants from the values in environment variables so everything will work.

More generically, every configuration constant you need should be placed in .env file. Beside other benefits, this also makes all the configurations available outside WordPress.

For example, I recently used this approach to create a custom Composer script that generates some compiled assets taking into consideration WP_DEBUG and SCRIPTS_DEBUG configuration, but using getenv() instead of accessing constants...

from wpstarter.