Testing: Template Editor Plugin

Creating and modifying plugins.
akb
Regular
Posts: 35
Joined: Tue Aug 22, 2006 6:43 pm
Contact:

Post by akb »

well, now we come to the difficulties :D

i think there will be no problem with adding a "insert color at cursor" button, noted for the next release :-)

but the code highlighting... woohoo. we would need an other way to get the code displayed, because a textarea - as it is implemented atm - is not able to mix formats. we only have one style definition for the whole textareas content. so the best way would be to develop a javascript class with a brand new textarea like htmlarea and fckeditor do, but for source code with highlighting. i dont know why there isnt already one available, or maybe i just didnt notice, but for this project this would be too heavy to code. i think the better way is to code such a project externally and then just _use_ it for our purposes, as it is with the mentioned html editor areas. so its a project that is made for more widespread use than just one plugin. but at the moment i am not able (as of my available time) to do this. does anyone have infos if this is on the todo for htmlarea or fckeditor or something?

a preview will be difficult to implement too. you have to take in mind that these files have to be parsed before it is displayed, so you can not just preview the file you're editing, but have to call the whole site. therefore the - imho - only possibility to do this is to use a save-and-fallback function, so it is saved and backuped when you click "preview" and then rewinded to call back the original version before you save it. but maybe we can work around this by implementing some sort of backup handling, or - even better, file handling, so we can give the possibility to rename files in the editor and so on. this would help you to save and recover the last version on your own. if you have further ideas how it could be implemented, just let me know :-)
garvinhicking
Core Developer
Posts: 30022
Joined: Tue Sep 16, 2003 9:45 pm
Location: Cologne, Germany
Contact:

Post by garvinhicking »

Hi Guys!

I'm absolutely blasted by your efforts on improving this. I like where your thoughts are going, so I'll just let you deal with each other, like Carl indicated.

So I just want to drop some fundamental things:

1. Enhancing info.txt is not a problem at all. It can parse any "X: Y" formats, where "X" is a thing like "version", "instructions" or whatever. You can even put multiple lines after a "version: blabla" thing; but you might not use ":" in any of the lines, because the ":" is the character that indicates the next element. So you can basicaly put anything you like into info.txt. But one will have to also display the information given in info.txt in the interface, so I would need to get a list of new items and key names you want to use to put them into the interface.

Places for this are include/functions.inc.php, function serendipity_fetchTemplateInfo(). And for displaying, see include/admin/templates.inc.php

2. The button "Manage Styles" was a bit mislabeled from the beginning on. Serendipity does not have a clear route differing between "Style", "Theme" and "Template". This is also mainly because I myself confuse those often. I am much in favor of unifying this nomenclature, but it's a lot of work to do for all languages and checking all documentation to change them.
Until somebody can do that, I like Carls suggestion of calling your tool "Style Editor", and keeping the current naming as status quo.

3. The Style Editor should better be kept as a plugin. Many providers that use serendipity for offering on their servers do not want that people can store code on the server. Thus, the editing functionality must be easily to shut down completely, and this can only be guaranteed as a plugin.

A second reason for using a plugin is that paranoid people can also disable it, and most of all: I am quite sure that a security concern could be raised by this. We cannot cover for all possible intrusions of this. If there would happen to be a flaw, we can just issue a new plugin and tell people to disable it; if it were in core, many people would need to upgrade their whole installations.

Keep up the great work!

Regards,
Garvin
# Garvin Hicking (s9y Developer)
# Did I help you? Consider making me happy: http://wishes.garv.in/
# or use my PayPal account "paypal {at} supergarv (dot) de"
# My "other" hobby: http://flickr.garv.in/
carl_galloway
Regular
Posts: 1331
Joined: Sun Dec 04, 2005 5:43 pm
Location: Andalucia, Spain
Contact:

Post by carl_galloway »

Garvin, you mention we should not use a : in the info.txt unless it is part of the x: y scenario. If we want to put : into the description field, is their any way of escaping from the parsing. For example the config.inc.php file if we need to put in a reserved php symbol we use the \ character to escape. If info.txt doesn't have an escape character then I suppose we'll have to be disciplined, but a lot of new designers won't have our experience of these things so whatever we do needs to be as easy to use as we can make it. Any thoughts?
akb
Regular
Posts: 35
Joined: Tue Aug 22, 2006 6:43 pm
Contact:

Post by akb »

@garvin:

1) okay, good to know. i bet there are functions for this in the prefab (include files)? another one to check out :-)

2) ok :-)

3) you're definitely right. besides i didnt even think of providers that use s9y. good you mentioned it, theres always something i forget to consider :-) and at the end... well, i dont even want to be the one that crapped s9y because the plugin was "hardcoded" and it makes problems of any kind. doesnt say i dont want to be responsible or something, i just try to bring in some realism with this. everything _can_ go wrong in some way and if it does, its better to have it done in a way it doesnt result in some type of horror scenario.

@carl: your postings leads me to a sentence that means hard work. the sentence is "on the long term s9y needs an xml class including a new info.txt(.xml) handling" :-) but i dont want to scare garvin. for now :D
garvinhicking
Core Developer
Posts: 30022
Joined: Tue Sep 16, 2003 9:45 pm
Location: Cologne, Germany
Contact:

Post by garvinhicking »

Hi!

No, sadly Carl there is no escape mechanism. The code to fetch the info.txt currently does not have any exception for parsing, so no ":" will be usable. But I'm sure that we can push template writers into the direction to only use ":" as a seperator ;)

Akb: Hehe. :) Thanks for your insight! I'm quite sure though that we will bundle your plugin in our distribution - just not installed by default. :-) So just like you said: Better safe than sorry. ;)
@carl: your postings leads me to a sentence that means hard work. the sentence is "on the long term s9y needs an xml class including a new info.txt(.xml) handling" :-) but i dont want to scare garvin. for now :D
I'm definitely for that, once that PHP4 has vaporized from the face of earth. XML and PHP4 simply suck.

Best regards,
Garvin
# Garvin Hicking (s9y Developer)
# Did I help you? Consider making me happy: http://wishes.garv.in/
# or use my PayPal account "paypal {at} supergarv (dot) de"
# My "other" hobby: http://flickr.garv.in/
judebert
Regular
Posts: 2478
Joined: Sat Oct 15, 2005 6:57 am
Location: Orlando, FL
Contact:

Post by judebert »

If the info is displayed as HTML, couldn't we use : instead of colons?
Judebert
---
Website | Wishlist | PayPal
Post Reply