Testing: Template Editor Plugin

akb · Post by **akb** » Wed Oct 04, 2006 5:26 am

another update tonight

heres the changelog:

- even more quickies, using s9y/serendipity_editor.js
- buttons made s9y style
- started to rewrite the whole code, initEditor() done nicely so far
- preselection of chosen template in the templates dropdown list to prevent confusion
- editor now per default opens info.txt instead of index.tpl to prevent php errors if no index.tpl is available and no file is chosen
- completely rewrote filelist: output is now sorted, images are prevent from being listed and subdirs are shown (but disabled) in preparation of subdir handling
- some little PEAR compliance, still has to be done nearly completely
- rudimentary implementation of a colorpicker

so its worth to check it out, the color picker is in there too

very rudimentary for now, but it works.

-----
edit:

Hi Carl,
hi Garvin,

as you can see i have implemented the colorpicker testwise. i think it works good the way i have done this, all i have to do is some cosmetical things about it, but thats not really important

@carls template: wow, i didnt know its implemented that easy, really a nice one to make the templates configurable that way. it opens really widespread possibilites and i hope it helps s9y to spread around the worlt even more

well, regarding the template editor, color picker and its integration i have to admit that theres some difficulties with that. i do not think it should be available only within my editor or something, but would like to mention that both the configuration page for templates and my template editor belong together in some way. so my suggestion would be to put them together in the long term. maybe we could find a way to include the template editor at the bottom of the templates configuration page or, even better, put them together and make them show/hide like the different blocks in the "new article" form.

the more i think about this the more i get a clue of it, hehe. is there already an event hook that could easily do this? if we got an event hook "template_configuration_page" or something we could easily allow the plugin to integrate there and everything would be fine

Post by **garvinhicking** » Wed Oct 04, 2006 10:17 am

Hi akb!

Thanks a lot for your continued work! It will prove very helpful!

I just committed three new hooks to the 1.1-beta:

backend_templates_configuration_top
backend_templates_configuration_bottom
backend_templates_configuration_none

Those you can use to display something before/after the theme configuration tool.

Keep us posted when you have a version that I should check for security issues again

Best regards,
Garvin

carl_galloway · Post by **carl_galloway** » Wed Oct 04, 2006 7:57 pm

akb, thanks for the work you're doing, this is just incredible! I agree with you about merging the theme configurator and your plugin, in fact I think taking the theme config part out of the 'manage styles' page and putting it into the 'template editor' page is very logical. The two features are both about template usability not about template selection.

My only concern is the confusion that users might have. Which link do they follow to select a template, is it 'manage styles' or 'template editor'. I think the average new user would probably click 'template editor' because they wouldn't know what 'manage styles' means.

akb · Post by **akb** » Wed Oct 04, 2006 8:02 pm

well, but this is maybe just a naming problem. we could easily rename "manage styles" to "select style" or something like that... and i could put a notice into my template editor that the user doesnt set the used template with it. or put a button like "activate this template now" into it...

carl_galloway · Post by **carl_galloway** » Wed Oct 04, 2006 8:10 pm

Probably best if we wait to see what Garvin wants to do. Personally I'm thinking your plugin shouldn't even be a plugin. I would suggest integrating this into the core, but that's Garvin's decision.

If he decides to keep it as a plugin then he probably won't want to change the names of the 'manage styles' link because so many users would become confused, and also a lot of users are still using old versions of Serendipity, so in this case it would be better to change your link, maybe it should be 'style editor'.

akb · Post by **akb** » Wed Oct 04, 2006 8:14 pm

after reading this thread carefully i think garvin is very open to this. now its only my part to reach the quality standards, so he can integrate it without being afraid of great security holes and things like that. after all, if you take a look at the core package there are already many plugins integrated that some users might see as built in functions. so we could easily do the same and put the plugin to the included plugins and everyone would be happy

maybe with a tweak like preactivating it in the config or something

carl_galloway · Post by **carl_galloway** » Wed Oct 04, 2006 8:21 pm

Garvin is totally committed to making Serendipity the best platform, and I agree he would want your plugin as part of the core, I really hope your code passes his security tests.

I've often thought of putting a readme into my template with instructions for changing them, but most users download my templates from spartacus so they would never even know the file exists. But with your plugin, I can put a 'readme first' file into the folder and users can open it from inside serendipity, and never need to worry about ftp. This is a big deal to me, and opens template editing up to a whole new class of user.

akb · Post by **akb** » Wed Oct 04, 2006 8:29 pm

ha, sounds like another feature: at the moment my editor opens info.txt by default. what about enhancing the guidelines to include a readme (fixed filename) that gets opened per default if it is available?

or, on the other hand, the info.txt could be expanded to include readme parts too. so the file would not be simply visible but also displayed per default when opening the template in the editor.

[edit] note to myself: what about displaying info.txt informations within the editor somewhere at the top?

[edit2] the readme file could even be a readme.html that gets linked (or displayed with show/hide) in the editor view

carl_galloway · Post by **carl_galloway** » Wed Oct 04, 2006 8:40 pm

ooh, the possibilities are endless and if you're willing to code that up...

I would actually prefer to use the info.txt instead of a readme, but I don't know if that file has any conventions that would confuse Serendipity. One of the things I've always wanted to do with info.txt is place a template version number into it, and a link my site (should open in a new window).

If I could also add a short description and and a link to my site where the user could see the very latest readme would be awesome. I could keep everything in one place, and any updates will always be visible to the user.

akb · Post by **akb** » Wed Oct 04, 2006 8:50 pm

yes, this sounds interesting. lets see what garvin thinks about it and how he could imagine it to be implemented, since it would maybe force him to change something with the info.txt handling.

woohoo, that thingy gets quite big

carl_galloway · Post by **carl_galloway** » Wed Oct 04, 2006 9:00 pm

Garvin won't reply until we have sorted out what we want to do, he sits around watching conversations, seeing where they go to, then puts in his two cents. He's probably laughing at me as I type this, but I agree with you, we do need guidance on how he sees this fitting together.

Then we need to work out a format for the info.txt file and I guess I would need to contact all the theme designers and let them know to update the info.txt file, and we should probably update all the older themes as well. I'd be happy to do that if you and Garvin can make this work at the code level.

akb · Post by **akb** » Wed Oct 04, 2006 9:08 pm

well, but when it goes to updating all the old templates and so on, it might be a better way to leave the info.txt like it is, or at least leave it backwards compatible. i'll check out tomorrow how the info.txt is implemented, because if its only parsing the given lines so far and does not get in conflict with following lines, this all shouldnt be too hard to enhance i think

carl_galloway · Post by **carl_galloway** » Wed Oct 04, 2006 9:19 pm

I've just downloaded your latest plugin, and I can see all the hard work you've put in, on my test server (localhost) the colorpicker isn't working, do I need to edit the files to change the paths?

akb · Post by **akb** » Wed Oct 04, 2006 9:27 pm

hm, dont think so. at least not the path to the color picker javascript itself, the path is constructed in the same way as the ones to the other javascripts. so if the other (resizable textarea, inserting the xhtml heads...) work, the color picker should work too. the only thing i could imagine is that the call to show/hide the div that contains the color picker does not work with your browser/your browsers settings. if so, i will try to fix this tomorrow by either rewriting the show/hide function (its really very, very simple implemented by now) or using the corresponding function that already exists in s9y (what would be the most correct way i think).

d_cee · Post by **d_cee** » Thu Oct 05, 2006 12:10 am

Hi akb

I've just been checking out your latest test version and I'm really impressed. I think it's excellent - and the colour picker's great.

Is it possible that if you highlight the colour code in the style.css file, then launch the colour-picker. When you're happy with your choice, you could then click on OK (or something) and it will replace the highlighted code in the style.css file.

And syntax highlighting would be a great help to less experienced users.

I think Carl's idea - whether a read_me or an extension to the info.txt is a really good one. And that the info.txt link should be clickable.

Any chance of a preview after editing but before saving changes?

Great job!

Dave