Active Development

How many people are actively developing greymatter?

What area of development are they focusing on?

That is a good question. Right now, as far as I know, its myself and Pete Finnigan.

I am focusing on refactoring the code to be more modular and easier to add enhancements. I have documented this in the gm_dev_guide.html that comes with GreyMatter. I also look for defects mentioned on the forums and attempt to fix them, depending on time and how extensive the fix will be.

I have setup two copies of Greymatter 1.7.1 on one of my web servers. The first one is my base line and the only changes I made to it is edit the templates so that they produce valid xhtml.

The second copy I am going thru the gm-library from line 1 on. My goal is have all web pages produced by Greymatter to be valid xhtml/css. I am using it to keep a log of all changes made.

Thats cool. Gm should be able to do valid xhtml/css. The Admin screens are very table heavy and I think it would be cool to move to styled divs. I am not anti-table, but they are using a trick I used to use, in which you create a nesting table with a 1% pad to create a border, so two tables instead of one div with border attribute.

Yes i would agree, I have not heard of anyone else (so far) apart from myself and Coldstone. I am working in feeds, comment moedreation queue and will also work on draft posts after that.

Looks interesting. I noticed you separated some of the stuff out. I only half finished moving the Admin css and js to the lib/Gm_Web.pm.

My only concern is: moving the css into seperate files is usually a good thing, but I was a fan of Gm keeping it all together. I thought it was nice to keep it togther since there is less files and its easier for a new person to edit, they don’t have to do server side file access to change the css, they can just use Gm’s template editor. A more advanced user can then use the templates to link to external css/js files and avoid name collisions on the users file system.

I was thinking that this is the first step toward themes or skins.

• Remove css and link
• Remove js and link
• Remove all deprecated tags
• Bring remaining HTML up to XHTML
• Reduce tables use for layout
• Add interface to save or select themes

What do to think?

Its interesting, but do you mean themes for the admin side, or themes for the web log side?

Its actually not too bad to switch themes, you just upload a new gm-templates file, but I think it should be handled by the ui so you cold have more than one. I have put some thought into this as well and the issue I always stumbled on was that if you seperate out the css/js from the template file, then thats another folder to maintain and update when installing new themes. Now if the theme uses emoticons or images, then this is unavoidable.

But basically I was thinking you would have a gm/cgi-bin/themes/new_theme.cgi, which would be a template file with the name of the theme. But for emoticons and images (and external js/css files) you would also need a directory under the web readable dir, such as gm/themes/new_theme.

However, since the {{logwebpath}} is defined, template authors could use that to specify the location of external files. Basically multi-theme stuff would need a admin screen to switch/install themes, and a new template variable for the theme name.
I think alot of people customize the template file, so we can clean it up, but I think most people do that during the course of customizing it.

The themes would be for the web log side.
I was thinking we would have something like gm/cgi-bin/themes/new_theme/gm-template.cgi

Have the ui check to see if there are any folders in the theme folder

• if none are there then use the default gm-template.cgi
• if one or more was there then offer a choice

When starting a new theme the ui would have you name it then the ui would create a folder with this name in the the theme folder. A copy of the gm-template.cgi would be copied to that folder which you could change without effecting the default theme.

Any external files related to a theme would be kept in the related theme folder.

I was thinking of something similar, except that the other files can’t be in the cgi-bin folder (not on all hosts I should say), for instance on my web host, I can’t access html files in my cgi-bin directory. Thats one of the issues with putting all the files in one place.