Add a SAPI function to define PHP constants

[adamziel]

Let's provide a method such as define to enable defining PHP constants for every subsequent request:

php.define('DB_NAME', 'dev');

This would enable setting up wp-config.php constants without patching WordPress or creating preloaded files like in the DefineWpConfigConstsStep.

[adamziel]

Relevant note from http://php.adamharvey.name/manual/en/internals2.ze1.zendapi.php:

Creating Constants

Zend supports the creation of true constants (as opposed to regular variables). Constants are accessed without the typical dollar sign ($) prefix and are available in all scopes. Examples include TRUE and FALSE, to name just two.

To create your own constants, you can use the macros in Macros for Creating Constants. All the macros create a constant with the specified name and value.

You can also specify flags for each constant:

• CONST_CS - This constant's name is to be treated as case sensitive.
• CONST_PERSISTENT - This constant is persistent and won't be "forgotten" when the current process carrying this constant shuts down.

To use the flags, combine them using a inary OR:

     // register a new constant of type "long"
     REGISTER_LONG_CONSTANT("NEW_MEANINGFUL_CONSTANT", 324, CONST_CS |
     CONST_PERSISTENT); 

There are two types of macros - REGISTER_CONSTANT and REGISTER_MAIN_CONSTANT. The first type creates constants bound to the current module. These constants are dumped from the symbol table as soon as the module that registered the constant is unloaded from memory. The second type creates constants that remain in the symbol table independently of the module.

Macros for Creating Constants

REGISTER_LONG_CONSTANT(name, value, flags) 
REGISTER_DOUBLE_CONSTANT(name, value, flags)
REGISTER_STRING_CONSTANT(name, value, flags) 

[adamziel]

I'm starting to think this is a bad idea. Right now the PHP runtime is not entirely stateless, but it's stateless enough we could reuse the same PHP instance to serve a few different sites. If we bake constants into the runtime, that won't be possible anymore. Playground currently loads the constants from an internal PHP file with a bunch of define() statements. The only downside is they cannot override constants defined in wp-config.php. When I think about that now, it's not actually a downside. It's a great, sensible, non-magical behavior. Imagine defining WP_CONFIG as false only for it to be true. It would be confusing. Let's close this issue and stick with the current way of defining constants.