WordPress MU

Hi and merry Christmas,

I'm coding a css editor for the sandbox theme. The code will be gpl, so you can adjust it to other themes, but I will only support the sandbox theme.

Here's a demo of the prototype: http://www.soderlind.no/demo/editcss.php

v1.0 might/will:
- support both WordPress 2.x and MU
- only support the Sandbox theme skins
- have a preview
- allow you to save a style to a temporary file prior to publishing it (for testing)
- in MU, save the style to wp-content/blogs.dir/$wpdb->blogid/css
- filter the saved css to prevent xss

Anything else / comments?

btw, if you don't know the Sandbox theme, have a look here: http://www.plaintxt.org/themes/sandbox/. At the first glance it might look boring, but it is one of the easiest/best themes to use a building block for creating your own themes using css.

that looks AMAZING Pers!

Personally I can't wait to get my hands on the code, to see how difficult/easy it would be to tweak it to work on other themes.

I used Sandbox on one of the blogs for my site, but I think I edited stuff in a regular WordPress before uploading to my MU install. This solution would be very nice indeed. Although there are only about 8 active blogs out of 80 on the site and I haven't really had anyone ask to edit a theme.

That is awesome! I am really looking forward to this release and can't wait to play with it.

That would be awesome considering the users at wp.com have the css edit box already (well, paid ones I think) and when the theme was "released" it obviously didn't have it.

It would be really awsome as andrea stated!

I have one suggestion for you so far. Since the script will save to a temp directory for viewing before publishing, would it also be possible to have the option to save the file locally, or better yet to another directory on the server? (provided the right permissions are set on the server)

The reason for this is so that I can get to work on creating multiple theme css files for broader use in MU.

Speaking of which, would there be a way to plug this into the system as a whole in order to do theme development on the site, maybe only from the main admin account?

Or supply us with some code to add to our themes that are already installed. For me it would save on development time. I realise it will be released as GPL, but I'm code moron :-p

Another teaser: http://www.soderlind.no/demo/skineditor.php

I've also changed the name to Sandbox Skin Editor, since it will only support the Sandbox theme.

how do you handle security ?

"No" security at the moment. The plan is to give access only to the owner of each blog (level 10), but I'm very open for suggestions / comments :)

well it's currently being discussed here:
http://mu.wordpress.org/forums/topic.php?id=3017&replies=12
without security such a tool can't be used in a publicly accessible MU.

My misunderstanding, I thought you meant 'who' not 'what'. As I mentioned in my initial post, I will filter the css on save, to prevent xss etc.

I've looked at at couple of filters:
http://pixel-apes.com/safehtml/
http://www.owasp.org/index.php/OWASP_PHP_Filters

both strips out the xss examples at http://ha.ckers.org/xss.html

that looks like a very elegant solution to the xss issue PerS. Perhaps when you release your code we could look to integrating the CSS editor back into WPMU with your XSS filters integrated.

After testing several filters, the one I'm most likely going to use is HTML Purifier

Here's a comparison: http://hp.jpsband.org/comparison.html

btw: Maybe we should create a generic HTML Purifer plugin for MU / WordPress?

My thoughts exactly Pers :)

well, isn't that the purpose of kses.php in WP distribution ?

quenting, you'll find a kses ( = wp_kses) vs HTML Purifier comparison here: http://hp.jpsband.org/comparison.html

Note: this comparison is on HTML Purifier's site, are you convinced the benchmark is objective ?
Also, do you think the advantages of HP are worth introducing a 2nd system in your code base ?
Finally, if you answered twice yes, maybe it would be worth suggesting a replacement to the devs ? WP could use an HTML tidying engine.

no, I'm not sure if it's objective so I've asked the wp-hackers list if anyone have a comment. I do agree with you that we shouldn't add unnecessary code.

Pers, have you had any success with either filter? I've been actively following this project, since I think it may be the precursor to allowing CSS editing on all themes.

Agreed. I'm rather surprised that there hasn't been any real development on kses in quite some time.

Gotta admit that I'm a bit concerned actually since that's what we use here.

edit: Been thinking about the CSS editor recently as I think that's the main thing holding us back here. I can see using the preexisting theme or file editor and running the input through a filter (either kses or the other one). It really shouldn't be an issue.

My main concern is how we're going to store the css file. As a file within the wpmu structure or as a option in the db. I'm leaning towards files actually. Probably would mean doing a new subdirectory to coexist within the current upload subdirectories and restricting access to just the editor. Also if you were to name the css files into something like {$theme}style.css, you could retain the css file is you switched themes.

I also gotta admit that I don't like how wp.com combines the two css files. (Although they allow you to do a blank one now) I'd rather do it as an either or and load the file that's requested. This means probably changing the css load line within header.php of all the files. Doable but a pain.

Just some thoughts.

Can't believe I didn't get any feedback on this. :(

Sorry. :(

Just not ready to let folks do it yet. I keep having nightmares of myspace.

Agreed. I was just asking for general ideas. I gotta admit that I'm stuck on where to keep the CSS. In a file or in the database. I'm torn and couldn't get a reply out of wp.com staff and which one they do. I didn't want them to tell me how they did the entire procedure but just which method they used.

Sorry here too. We're veering in a slightly different direction (options pages mostly). I'm not sure which one Ron woudl prefer. I kinda like the file myself. Then all you'd need to store in the db is the filename or info.

I like the file as well. It would keep the database from growing and you could make multiple versions fo the different themes.

The downside to that is you would have to count the space usage against your clients. That and if you saved the file to a directory somewhere, you would have to restrict the file access to the specific user. Maybe create an additonal subdirectory alongside the uploads.

Not trying to be negative here. I just can't deside. It seems simplke enough to do with coping over the file editor, restricting it to the user's css file(s) and running it through the filters.

Why not save it to files/css/themename?

The file option would be better. I can't imagine serving an entire css file out of the db.

I'm thinking files/css/{$themename}style.css actually. That why if you get someone who switches between themes regularly, it woun't be an issue as the edited css won't go away.

I've been having database issues for the last two days so this is on hold for a day or two.

So only 1 file then? That's how I'm reading it.

I was suggesting something like files/css/"theme-name"/style.css.

Although, it could be beneficial to allow style.css to be named differently, so that there could be multiple css files per theme or something? I dunno. Ideas maybe.

However, maybe only 1 per theme is a better idea.

That would work as well but creating a new directory takes up space on the hard drive. Even though it's only 4k on the linux platform, do that enough times over and over again and it's a chunk of bits used up.

I was thinking more of a $blog_id/files/css/ subdirectory where each theme would have a seperate CSS file using the subdirectory name of the theme (That is what is kept within the db anyway) plus 'style.css'. For example the custom CSS file for the default theme would then be /$blog_id/files/css/defaultstyle.css and would be loaded at the end of the head portion using a plugin or at the front of the page in place of the themes normal CSS. (Although that would probably require hardcoding of all of the themes in ones install.)

The thing with the multiple css files for each theme would get confusing for the end user. I had thought about doing it like wp.com did it with saving each version but we've noted that the version number is always set to zero now so we think they gave up on that and just now keep the latest. (At least that's what I've seen)

Donncha, if you read this, I'd love to know where wp.com is storing the file. Either as a file or within the db. I'm leaning towards the file method myself for this.

Makes sense to me.

To me, the easiest way would be to add a plugin and hook into wp_head.

In the plugin file, do a check for an option in their settings table, and if the file exists then go with it and echo it.

I'd say possibly mu-plugins, which would work, but since not everyone will use it, then having it as an alternate plugin would probably be better. That, and also if they don't want to use it anymore they can turn off the plugin.