We should considering deprecating/reducing use of/removing DBTNG in Backdrop to accomplish the following goals: - Improve performance by removing abstraction around constructing queries. - Improve learnability by avoiding a Drupal-specific abstraction layer and syntax.
This introduces a need for substitutes in a number of places however: - Alterability: Remove the ability to alter queries. No more alterableQueries or db_rewrite_sql(). Instead, any query that needs to be altered instead utilizes a View, that can be altered to affect the query. Or, avoid altering entirely through... - Access control: Make access control queries explicitly defined when creating Views. Instead of automatically restricting listings, require listings to have access control explicitly defined (similar to explicitly defining the "published" state). - Database connections: We can still use PDO to connect to the database. It's just as fast as a mysqli connection in benchmarks, and makes it so we can use a consistent syntax for doing queries, regardless of the back end.
Things we would NOT remove or build out later include: - Schema API: As long as we support PostgreSQL (which we should for the initial release at least), Schema API is still needed to define and update tables. - Entity abstraction: We should focus on ensuring entities are loaded and modified through the entity API alone, making it so it's still possible to cache and store entities in a swappable mechanism. Although things like MongoDB are probably not the target audience, efficient per-entity caching definitely is, so this benefits us for the time being.
The initial effort should be to provide a database system that can update usage of db_query() throughout core with a lightweight replacement directly against PDO. We can work on removing db_select/update/insert/delete queries over time and then remove them (and DBTNG) when finished.
Recent comments
There is a Drupal 7 contrib module that "lets the administrator see all administration pages in her preferred language" and which could be ported to Backdrop: https://www.drupal.org/project/...
Allow admin to select admin language seperate from front end language (multilingual)
@stpaultim – You're right: my approach affects also the main menu. I guess, because menus are also considered as user interface (not as content). @findlabnet – If I didn't miss anything,...
Allow admin to select admin language seperate from front end language (multilingual)
Go to the account edit of the desired user. On the horizontal tab below "Region and Language," select "English" or another language. WFM.
Allow admin to select admin language seperate from front end language (multilingual)