Use default value when DB_NAME constant is not defined
#203
Conversation
JanJakes
changed the title
DB_NAME constant is not defined
| * the default value of the constant in "wp-config-sample.php" and in Studio. | ||
| */ | ||
| if ( ! defined( 'DB_NAME' ) ) { | ||
| define( 'DB_NAME', 'database_name_here' ); |
There was a problem hiding this comment.
log a warning maybe? or would that not make sense?
There was a problem hiding this comment.
@adamziel At the moment, this seems to be a valid use case in Studio that probably shouldn't even generate warnings, I guess.
That said, I think I figured out a way to make the information schema DB_NAME independent, so I think this will be only temporary. The idea is to use temporary views on top of the stored information schema tables. They are naturally per-session and enable injecting any DB_NAME to the affected columns, they are low cost to create (they don't materialize + it can be lazy), and they could also unlock features like row count and auto-increment values.
There was a problem hiding this comment.
This code is not studio-specific, though, but distributed to all sites where the SQLite plugin is installed. Would that make a warning reasonable?
There was a problem hiding this comment.
@adamziel the issue is not Studio-specific. It could happen on WoA sites, too, if user uses WordPress with SQLite plugin. WoA sites don't have database constants defined in wp-config.php file.
There was a problem hiding this comment.
Makes sense. I guess it makes sense for any sqlite-only site to skip the database constants.
This is needed for integration of the new SQLite driver in Studio.
We discovered that Studio doesn't use the default implemented in Playground, as it's using
wp-nowand booting Playground differently.As a hotfix, when there is no
DB_NAMEdefined at all, we'll fall back to the same value that Studio is using through an MU plugin with polyfills.A proper fix will be to make the SQLite driver independent of the
DB_NAMEconstant.