One thing I've been thinking about is how Firefox balances these two items. There are hundreds (thousands?) of settings in firefox (type about:config into your location bar to see many of them). You only see ~10% of them in the menu structure and dialog boxes while the rest are hidden in about:config or via files (e.g. changing your chrome/*css). most Firefox users will never use about:config or the chrome files. But for the 5% who use them, they are very important!
Can and should we adopt this separation in Drupal? We already have some examples of variables which have no UI in core but can be enabled via a contributed module or via settings.php (e.g. dev_query). Should we take this further as a general system?
I'm leaning towards yes, but want to know how other people feel.
I've often fantasized about rolling common features from a custom "admin screens" I end up building for clients into a general "Drupal Admin Lite" module. Obviously it would be fantastic to get something like this into core, but with the vast array of use-cases it seems like a ripe opportunity for contrib space to take on. A product-specific admin interface also makes a lot of sense for an install profile. My experience is if you're doing anything interesting, you end up with a custom module doing various API tweaks and workflow glue for your use-case. Even if you're just rolling a "blog" or "wiki" install profile, a key part of making it wildly successful will be giving blog/wiki admins quick and intuitive access to the tools they need... -j ------------------------------------------ Josh Koenig, Partner http://www.chapterthreellc.com AOL IM: chap3josh 1-888-822-4273