Thinking about the css editor

[drmike]

Been thinking about this again because some of my clients are bugging me about this.  Here's my current thoughts about the editor and css in general.

- I don't like how wp.com does theirs.  I don't mind the editor but I do mind how they left the original image CSS within header.php.  An occasional issue over on wp.com is folks having the original image load followed by the custom header image afterwards.  (ie visitors see both images, especially on a slow connection.)

- Two sets of CSS.  You have the style.css from the theme followed by the blog admin's css for most users.  Granted they now have the option to use just the admin's css but this comes off as confusing.

Here's what I would do:

- Move the CSS declairs currently found within header.php into style.css where it should be.

- Modify the header.php file and instead of loading the CSS from there, do a function call for something like load_css(); which would be found as a mu-plugin. (Note I say mu- and not a standard plugin.)

- Create a mu-plugin file where the load_css function is to load the css.  Do a check against the premium services feature to see if the blog has the 'edit_theme' upgrade.  If yes, then load the css out of the options table if found.  If the option is not found or they don't have that upgrade, then load the theme's standard css.

- Ditto on the editor with the check.  Gotta admit that for me, that's been the sticking point besides actually sitting down and writing it.  Send the content through kses or something else? (Since it's contained as a site option, I gather that that would be done automatically.)

of course this means editing each and every theme to change header.php.  They wouldn't be hard.  Just a pain in the butt.

Just some thoughts.
-drmike

[Luke]

I think that "most" of the css options would be for colors, right?

After all, are you going to let a user go in and trash a layout and end up with a myspace nightmare?

That being the case...

- Initially read in the original css file (first time).
- Replace any colors with text boxes, just for the color name.

- User adds new color combination.

- On post, each posted field is ran against a regex ([0-9A-F]).
  If this fails, it's kicked back. (strtoupper on the post data)

- Write the new css file, set a blog option to true.

- Now this editor page will load the modified css file, with an option to
  turn it off, or "restore to default".

It's basic in theory, but are they changing anything other than colors? I wouldn't think they would. And "most" users would need a color box to pick from.

Now, what you "could" do, is set up a "special" file (that mirrors) the current css file, but it puts a % around any color options.

This way, the editor page knows where to add the text boxes.

In turn, it would save 2 copies of the file to the users directory.
A new style.css file (or blogname.css), and a style.css.info file.

The difference would be the .info file would have the % around the color options, and the style.css file written would (obviously) not have those.

It would be a slight pain in the ass to initially implement, but once it was in place it would work out pretty well.

Then when a blog loads, the header uses a function to make the css declaration, where the original css tag is now.

Original Example:

Code:

<style type="text/css" media="screen">
     @import "http://example.com/wp-content/themes/mytheme/style.css"
</style>

New example:

Code:

<style type="text/css" media="screen">
     @import "<?php get_my_css(); ?>"
</style>

Function:

Code:

<?php
function get_my_css() {
  if ( get_option('premium_custom_css') ) {
    $css_link = get_bloginfo('home') . '/files/mytheme/style.css';
  } else {
    $css_link = get_stylesheet_directory() . '/style.css';
  }
  echo $css_link;
}
?>

To be honest, this really wouldn't be too difficult at all.

The "worst" parts would be:
  - Adding in the little color box (which isn't bad) for each
    textbox, so that it updates the color in that field.

  - Initially making duplicate css files to be read from initially.

The actual coding of it is pretty simplistic, really.

No need for kses, or anything like that.

Combine this with a custom header image option, that fully works of course, and it's all good.

[Andrea_R]

I think that "most" of the css options would be for colors, right?
After all, are you going to let a user go in and trash a layout and end up with a myspace nightmare?

In our case, yes.  One, for ease in implementation and two, we can educate 'em.

Combine this with a custom header image option, that fully works of course, and it's all good.

OMG, this is currently my pet peeve. Way to make it so I can see what I've previously uploaded. So I can pick a previous one or even, gosh, I dunno.. delete unwanted ones...

[ron_r]

And, if the CSS is written with Luke's idea in mind, it would result in relatively few text boxes.

[Luke]

OMG, this is currently my pet peeve. Way to make it so I can see what I've previously uploaded. So I can pick a previous one or even, gosh, I dunno.. delete unwanted ones...

For sake of space, it should upload the image, and use the theme name as the title. This way, when you switch themes back and forth, you don't lose the image, but at the same time, you can only upload one per theme.

Ideally, to be honest, it should be one file and that's it. Call it header.jpg (or png, or gif), and call it a day. 1 image, and no dups that don't get deleted.

And, if the CSS is written with Luke's idea in mind, it would result in relatively few text boxes.

Yepper. For me, that would seem to be the only necessity in managing css custom css. Letting a user jack with layout properties isn't too bright. *cough* mycrapspace *cough*

That being the case, my general idea above would work rather well.

It might eat up a little bit of resources, not too much though, but it won't be something that is constantly being run either.

[drmike]

But I want to do an editor.....

[Luke]

A full editor?

Wow. You're brave. I wouldn't touch that with a 50ft pole.

For the very rare occasion where I "might" have a user smart enough to do that, I'd tell them to copy the original, modify it, then send it to me and I'll enable the theme just for them. lol

Other than that, users should be limited to color selection, and that's it. Of course, that can make it bad enough.

[drmike]

For the very rare occasion where I "might" have a user smart enough to do that

Well that's what you get for playing up to those NASCAR folks.

[Luke]

*reaches back like a pimp and slaps the Doc*

[Andrea_R]

I have some users smart enough for the full editor.

Gotta start them somewhere. 

[drmike]

Of course they're smarter.  They're not making all those left hand turns over and over again.