![Popular open source software is more secure than unpopular open source software, because insecure software becomes unpopular fast. [That doesn't happen for proprietary software.]](../sites/all/themes/drupal4hu/images/bg-center/bg-center_4.png)
In Drupal 8, besides settings.php I would like to see a non-PHP settings file, writeable by the webserver. settings.php would contain the secrets, the database settings, site key etc but most things that are variables now would become settings, loaded from a file. This would avoid the chicken-egg problem of how to load settings that are required to get to the database? In Drupal 8 we want to have plugins (like the cache in D7 just more generic) and this would provide an excellent place to put the plugin registry.
So this file would be treated as user input and we need to treat as something the user can read. So, nothing secretive would go in there and it needs to be validated on every load -- most importantly, filenames against a list of safe paths stored in settings.php, like includes/ sites/foo.example.com/modules etc etc. As serialize is unsafe, we can't use that, we will need a simple format to be used, we will figure this out. Edit: and the winner seems to be JSON as json_decode seems to be safe. Variables would become a key-value storage for stuff like user welcome mail etc. For people with multiple webheads, we probably need to version settings and store that as a variable and if the settings is outdated then reload it from variables.
As for performance, currently we run one DB query to fetch all the variables from cache and then unserialize that huge blob. We need one DB query to fetch the version number, so query-wise the Drupal 8 settings load is the same the Drupal 7 variable initialize. However, our unserialize will be slower than the native PHP version but compared to D7 variables, settings won't contain everything and it's exactly the bigger stuff that would not be there (like the user welcome text) so it's likely so far we are on par speed wise approximately. But then we can store things like module list in here and that saves a database query.
Indeed, most everything that went into cache_bootstrap needs to be checked for being stored in settings. Some experiments for Drupal 7 would be possible by creating a cache engine that stores cache_bootstrap in a file like this.
Commenting on this Story is closed.
An easy way to get this same functionality is to use something similar to cache routers file cache; with a copy in the DB. Storage format could be JSON (what does cache router use?). Drupal tries to load the file; if not found then try in the database; if not found then rebuild cache. As you stated above, file contains things like memcache settings. We are already reading from disk/APC so loading up one more file is not a major concern of mine.
There is no easy way, please re-read my post and consider the security implications of a webserver writeable file.
But, thanks for the great idea of using JSON, I just checked with Heine and we think it's a secure solution.
This seems to be a rather small step, and i didn't get yet towards what objective.
Thinking further of the two problems with storing, retrieving and processing configuration in Drupal, there are two big areas which can need improvement:
a) Deployment => Getting site building config into code and deployeable. Features.module is a great step towards a solution, but can be quite cumbersome for *reliably* and *efficiently* organising and deploying site building. Dries explicitely mentioned deployment and staging on his DC SF keynote.
b) Performance waste. As Rasmus Lerdorf pointed out in his DC CPH keynote, the current approach in Drupal, of having everything flexibly configured and having to check every configuration on every single request, lead to massive and application-wise unecessary resource overhead (ram, cpu, io, db, everything).
So why not thinking further and take into account what Rasmus suggested about configuration/bootstrap-process baked in code? Let's have a mechanism in D8 to "bake" any configuration and processing of configuration in code (cacheable by opcode caches!):
- to reliably and efficiently deploy any site building
- to have all basic config loaded from code
- to have the bootstrap-process pre-baked in code (anytime changeble by re-trigering the baking-mechanism, or deleting the baked files, e.g.)
- to even have complex configured processes baked into code (waaaay faster!). Think rules or display suite or any other modul that flexibly configures or executes configured processes. That would be potentially a *huge* performance boost. D8 would provide the basic mechanisms/APIs, and modules could use them to get their processes baked into php file once the config is done (and again anytime).
Of course, this would benefit the more complex processes and more enterprise-like environments.
But it would also improve performance any (even small shared hosting) systems.
And of course, there are many problems lurking (e.g. security issues).
But there are certainly solutions to these problems as other systems have took that approach before.
Let's take into account the challenges mentioned by Rasmus and Dries, and think broader about a solution!
What do you think about that approach?
IIRC, Rasmus didn't show any massive speedups with his optimizations, and they would significantly cripple our app. I was pretty disappointed by his talk, actually. He is clearly a ninja master and with enough time he would find solutions that preserve functionality and speed things up. But he didn't dedicate that time (thats understandable).
chx' proposal sounds good to me.
I was thinking of this approach but making PHP files writeable on every module enable to be able to store the modules list is a major PITA -- it was thinking on Rasmus' talk that lead me to this proposal.
I'm very new to Drupal but have seen rasmus presentation and have some common sense, and this makes sense :) It sounds excellent to have a features module like behavior in core and the rest danielnolde says.
Large multisite, git distributed dev-staging-production environments make me want this config file more than ever...
As you said Features is a great step (and really really fantastic) but IMO it's not enough to alleviate the pain of distributed dev & deployment. A settings file that held the config of every variable and site setting would be flipping glorious, support versioning and so make many lives easier, more profitable, productive, happy, give more time with families, etc...
What might be nice is a #D7EX / #D8EX - drupal 7/8 exportables experience - commitment. A push for module devs (and in D8 - Drupal) to fully support exportables of config. I don't really know if baked into code is the deal, but just somewhere, restricted but writeable, for the sake of deployment.
-jpstrikesback
For plugins I've actually been planning to just use a plugin_instance hook that works essentially like hook_views_default_views(), which then makes it possible to persist configuration in code. In fact, non-code configuration becomes just a hook that happens to build its arrays dynamically, which is good.
That said, I see no reason why you can't build that array dynamically from persisted JSON on disk. And for things like the variable table (and its larger elements), going straight to JSON makes sense.
Still pondering, but I think this has potential...
'course, there's always XML... *ducks*
I wanted a speedy parser. I can come up with slow formats myself.
Also, hooks? Um. plugins will be used waaaaaay before any modules are loaded. Like, cache. For page cache.
Actually in the current design the cache system would not use plugins directly. I wanted to, but it turned out the number of hoops I had to jump through for that was ridiculous. When I dropped that requirement and let the system rely on the cache the code got 10x cleaner. (And Earl was kind enough to only say "I told you so" once. :-) )