@aristath The change looks good to me, but I think we need to evaluate whether this is generally considered useful enough to take a spot in the admin bar. I think it's a bit too late for 1.8.0 since it's an enhancement that was just opened today and needs a bit of thought, so will move this to 1.9.0.

@aristath We still haven't had any conversation about this. For example here's some questions I have which would be good to discuss:

• Is this something that users of the module would want to see?
• Is it justified to reserve some of the very limited space in the admin bar for a very basic piece of information like this?
• Since it sets a precedent on adding PL information to the admin bar, should we rather think about a dedicated PL admin bar menu which could potentially incorporate other important heuristics than just this?

Last but not least, should we do this or should we not do this?

@bethanylang This is probably not a massive conversation to reserve an entire chat for, but still it could be a good topic to cover in one of the next ones.

For now I'll move this to the next release (2.0.0) since we need to create the 1.9.0 release branch today.

@aristath Wondering what your take is on the above? What led you to opening this PR? :)

Initially, when someone was activating the module, they were getting the install screen where they would set their site-name etc. With that workflow, I was just setting the site-name to SQLite test and I could immediately see (by the site-title) which db I'm working with.
In order to make the testing experience smoother, that process was automated and the installation of WP runs automatically, copying over the pre-existing sitename, admin-user etc. As a result, I no longer know which db I'm working with unless I go to site-health to check - or check the filesystem, to see if wp-content/db.php is there.
If we keep the current flow that runs during the module's activation, a visual indication of which DB is currently used would be useful.

Thanks @aristath, makes sense. I was just a bit concerned to use the limited WP Admin bar space, but that use-case is reasonable to me.

However, I would advise we also show that menu item when not using SQLite, just as long as the module is active. We also need to consider the value of the DATABASE_TYPE constant. Maybe like this:

• If PERFLAB_SQLITE_DB_DROPIN_VERSION is defined and DATABASE_TYPE is set to "sqlite", the menu displays in green something like "Database: SQLite".
• Otherwise, the menu displays in red something like "Database: MySQL".

Or alternatively, we could just rely on $wpdb->db_server_info() to determine which DB is being used, this way we wouldn't need to deal with the constants at all, and it would look at the real source of truth (arguably the $wpdb class is the source of truth for what is actually being used). If we do that, we can even differentiate between "SQLite", "MySQL", and "MariaDB" if we want (the latter isn't really necessary but nice to have).

Let me know what you think. My main feedback would be to show the menu even when SQLite is not enabled but the module is enabled, as that would be a good indicator that something is wrong.

@aristath Friendly ping ^

Or alternatively, we could just rely on $wpdb->db_server_info() to determine which DB is being used, this way we wouldn't need to deal with the constants at all, and it would look at the real source of truth (arguably the $wpdb class is the source of truth for what is actually being used). If we do that, we can even differentiate between "SQLite", "MySQL", and "MariaDB" if we want (the latter isn't really necessary but nice to have).

Sounds good to me 👍

• If PERFLAB_SQLITE_DB_DROPIN_VERSION is defined and DATABASE_TYPE is set to "sqlite", the menu displays in green something like "Database: SQLite".
• Otherwise, the menu displays in red something like "Database: MySQL".

Done.
I also rebased the PR to bring it up to speed with trunk 👍

@aristath In the interest of time, I've quickly addressed the outstanding feedback myself in 6bf9328, since we preferably need to merge this today to get it into the 2.0.0 release.

@SergeyBiryukov Can you give this a quick review, since you previously commented (and I rather don't just approve my own additions 😄)?

@aristath Can you add this change to the standalone plugin as well please?

Will do 👍

I'm gonna go ahead and merge this in order to create the new release branch. If there's anything that should be changed, we can always open a quick follow up PR against that branch release/2.0.0.