Hello Ahmed!
Are you talking about losing custom constants (those not defined in the form) like those defined for other Plugins?
Yes, that is what I was referring to.
Your plugin seems like a great idea for newly set up instances of WordPress without any manual changes having been made to the config file as yet.
I noticed a few things specifically:
1. my DB collation setting
define('DB_COLLATE', 'utf8_unicode_ci');
is not being picked up by WP Config File Editor, resulting in an empty string written to the config file.
2. although DOMAIN_CURRENT_SITE is commented out (because of WP Multi Network), WP Config File Editor insists on putting it back in.
3. although I have commented out define('DISABLE_WP_CRON',true);, WP Config File Editor wants to uncomment it.
Also, in my config.php I have things like, for example
define( 'WP_DEBUG', false ); // true or false
if ( WP_DEBUG ) {
define( 'WP_DEBUG_LOG', true );
define( 'WP_DEBUG_DISPLAY', false );
@ini_set( 'display_errors', 0 );
}
which, as it stands, is changed to define( 'WP_DEBUG', true );.
Would it perhaps be feasible to have WP Config File Editor enclose the code it generates within markers, just like WordPress does in the .htaccess file?
You might have a setting for new/untouched vs. customized/tweaked installations, so that new/untouched installations are regarded safe for WP Config File Editor to handle generated code as it does right now.
When an installation has already been played with, you could have WP Config File Editor put the generated code just before the closing /* That's all, stop editing! Happy blogging. */ line, leaving the original content untouched.
That way any configuration done from within WP Config File Editor would simply redefine the one(s) already present in config.php, which I assume would greatly reduce the risk of messing things up too badly.
The admin could then manually delete any redundant settings, leaving in the ones WP Config File Editor is not set to handle yet, or which it shouldn’t override.
Just my 2 cents, anyway.
