Allow customizing themes from the UI

Great ideas, oft-expressed, and I don't want to come off as negative, but my first reaction is that Drupal's development culture isn't like to embed into core such "newbie/surface" functionality.

So this idea is probably best implemented as an add-on theme framework, which IMO means as enhancements to, or sub-themes of, Zen.

If it proved to be very useful for noobs AND flexible for wizards, then the next step is to propose it as a theme to be included with shipping core, or even as "the" core theme, but deadlines for selecting this for D7 are already here.

Bottom line I suspect a very small set of people in the Drupal community would have the 1 skills 2 time and 3 interest to work together to make this happen. Of course if you have all three yourself, the classic answer is "scratch your own itch" or "patches welcome". . .

While I could not agree more that this functionality is needed, the problem is that CSS is so powerful. I have thought quite a bit about this in the past and am still pretty determined that creating a usable interface to be able to edit the majority of CSS properties is virtually impossible. My reasoning behind this is that if you are giving users the option to select color, background color, border, font-family, ... then they have to have a general understanding of CSS to begin with.

The next problem is that CSS is.. cascading. While styles might be applied to .block in one stylesheet, there might also be #sidebar-right .block.. creating a usable interface which accounts for all of these possibilities is virtually impossible in my eyes. After all, dreamweaver does not even do all of this...

Now, with that said, I think that Panels could be extended a great deal to not only control the structure of the entire page (not just the $content var), but also use a completely drag and drop interface, being able to resize regions, add and remove regions and the like. With this, themes could simply be CSS files which rely on Panels to handle the structuring. Personally, I think this is the direction that we should go for now. At some point in time, I definitely think that your ideas will be implemented, but at this stage, I think we should focus one what is achievable at this point in time.

my first reaction is that Drupal's development culture isn't like to embed into core such "newbie/surface" functionality

That is an incorrect reaction. :) Both core maintainers -- Dries and myself -- plus the entire Drupal community (including its developers), have cited usability as one of the foremost things they'd like to see improved in Drupal 7.

However, as you say, I'm not aware of anyone with this particular "itch" right now, and that person (or team of people) would need to surface and start working on this ASAP for it to make it into Drupal 7. http://groups.drupal.org/theme-development is probably the best place to start brainstorming on a solution if you're serious about putting effort into getting this into core.

Amending issue title so it's more obvious what's being asked for here.

More customizable themes sounds like a good idea to me. You have to find the right balance between power and simplicity though. Would it be for font sizes and colors, column width, header background and the likes? Or would you go further with maybe borders, margins between cols, ability to customize individual elements (blocks...)? It could become really bloated :)

Couldn't it start a "base" theme à la Zen (or even a Zen sub-theme)? Perhaps with a companion module to avoid a theme settings page overload?

Browsing through all themes is another issue imo. It would be great to be able to filter the theme, something like "show me all themes that can display a 3 columns layout, that could be set to content-left-right order, for D6".

I see this as something that could be done and be helpful to lots of people. The key to starting off would be not to try and edit ALL CSS styles from a UI interface...only ones that a theme configures to be changeable (themes could build in this 'feature' much the way they build in color module interaction now). The reality is, this feature would be most useful for people who only want to change theme basics (such as font family, colors, font sizes, etc) and not more advanced things like actual layout properties. This idea was what I approached the changeme theme with...make it easy to change the basics...leave the more advanced stuff off limits.

I'm not a developer...but it seems to me creating a 'theme admin' page where designated items could be changed (and previewed) shouldn't be crazy-difficult. I would imagine this working much like a contemplate-style module for CSS, in that it would store these 'CSS overrides' in the database...not in the file system. The question I have is: "can CSS be overridden via theme functions?". If so, then this seems like it would be easy to implement. If not, and CSS can only be overridden in files...then it's a whole other problem and probably not worth pursuing.

So, as an example, I'd imagine a situation where I build a theme and designate (for example) the following styles for being overridden:

h1 {color: #000;}
h2 {color: #333;  font-family: arial, helvetica, sans-serif;}

by inserting something in the theme's template.php which interacts with a "css ui" module....

Then, in the config screen, the user could see these styles, put in their own color for h1 or color and font for h2, and save it to the database. When the pages are called, the module grabs these overrides and inserts them after the stylehsheets.

I'm not sure if any of this is possible..but I think starting simple like this could really work and would make lots of folks happy. So, developers...is this doable? If so, what's the difficulty rating of doing it right?

Rob, they way themes like Tapestry enable stuff like selectable fonts is to use an embedded stylesheet, printing the theme settings directly into page.tpl.php.

If this were actually considered its probably worth looking at Wordpress - in WP you can edit theme files via the UI, which is great if you dont have access to FTP etc. One reason this is doable in WP is the 100% separation between the admin section and the front end theme, whereas in Drupal you could do some damage and lock yourself out with a bad edit. As far as I can recall WP writes the changes back to the file system and not to the database which makes most sense (thinking performance here).

Plenty of contrib themes are taking a stab at this general idea, to be highly configurable and even style-able via theme settings. I think it will be interesting to see what comes in D7.

I've had an idea for a very elegant solution to themes in Drupal.

Why not simply allow .css files to be stored as nodes? Turning the module on would sweep your themes css files and convert them into nodes. Which you could edit from within Drupal.

A simple check box to enable/disable would allow newbies to quickly revert back if they screwed anything up.

It would be wise to make them exportable in some way, perhaps simply the option to write back over the original files, or export them as a feature.

This could even be extended to include .tpl.php files. Imagine how simple it would be to create a new theme node type, call it say views-view.tpl.php or node-events.tpl.php and edit your theming there.
However the .tpl files include PHP, which I know isn't the best thing to store in the database. That's not the Drupal way.

So basically we just need a contrib module that allows file write/edit access to your theme files, allows you to easily cone a theme and change it, and then to export the theme and submit it into the community if you so wish.

And then once its polished enough, get it included in core... Then just watch the creativity begin!

CSS is going to be a huge thing in the next few years in web development, CSS3 almost does away with the need for any graphics on your site. Drupal really needs to give users the tools to quickly and easily make any changes they want to their sites.

Referencing #1530074: Create Theme UI API.

Not quite the same issue, but pretty darn close.

@medden: OMG! Love the idea of storing theming aspects in the DB, just from the standpoint of making themes "Feature-able". Granted, I know it's not initially the "Drupal" way, but is there really a sound reason behind why we shouldn't try? Ultimately, yes, pulling from the DB on a production site would be bad, but on a development site wouldn't this be a God-send? When I'm developing, I'm never worried about performance at that point because I'll recreate the feature and fine tune afterwards. We edit our content in the browser, why can't we start editing the theme in the browser (at least some aspects of it) and then package it up to push?

Because we have Twig in Drupal 8, we can make something similar to https://www.drupal.org/project/contemplate in contrib for Drupal 8 (and I think it should start in contrib and we can consider adding it to core at a later time).

We can verify the syntax of the Twig template before saving it to the database, for example.

Because I strongly feel this should start in contrib, closing. We can consider adding it to core if it's viable in contrib.

I'd rather not close the issue. Let's postpone it for 9.x for now. If contrib becomes viable enough during 8.x cycle, we can introduce it as a 8.Y.0 feature sooner than 9.x.

Marked #738008: Elastic Theme Editor (WYSIWYG) for Drupal as duplicate.

Building layouts through the UI is in the works, likely for 8.5. Have a look at proposed wireframes and workflow here: https://youtu.be/PAvTyNPkw7k?t=31m23s

Related: #2808151: [policy] Move the Color module to a contributed project when Bartik is deprecated

9.x is very much released so not postponed anymore

I feel like this is somewhat obsolete given that this will be included in XB and site templates. Does anyone who has already commented want to weigh in?

+1, see also #3533198: [Meta] Make Drupal the first "design-system native" CMS + Unify & simplify render & theme systems

Based on the last two comments I am closing this as a duplicate. The work is being done in #3533198: [Meta] Make Drupal the first "design-system native" CMS + Unify & simplify render & theme systems