[geeklog-devel] lib-layout.php

Mark R. Evans mevans at ecsnet.com
Fri Jan 4 10:01:48 EST 2008


If there are areas that can be modularized easily, then I'm all for it!

> I don't think it's a good long term strategy to copy the complete 
> COM_siteHeader and COM_siteFooter functions into the themes. There are 
> already a number of changes in CVS and with each release. Sites have to 
> merge manually the changes into their themes and I suspect most site 
> admin's won't know where to start and will have to wait for the theme 
> owner to release an update.

We already have this situation where folks are not upgrading their sites 
because they are using a different theme or have hacked their theme and 
don.t want to mess with  finding the changes.  If someone were to hack the 
COM_siteHeader/COM_siteFooter calls in their theme directory, I.m assuming 
(dangerous thing to do) they should have enough knowledge to merge their 
changes into an updated version.

Personally, I believe most site admins will either wait for the theme 
author to publish an update or for someone else to update the theme like 
Ironmax has been doing.

I believe this is a serious enough issue that it should be addressed 
sooner rather than later.  Scanning the forums, it does seem to be a major 
reason folks don't upgrade.  As usual, I have an opinion on how to address 

[beating dead horse mode on]

The Caching Template Library will take an array of locations in the 
initial new Template() call.  This allows you to create a new theme and 
only copy over the templates you wish to change to the new theme 
directory.  Making the second array element the professional theme, you 
now have the ability for users to only copy a handful of templates they 
wish to modify to their new theme directory.  Upgrades will not overwrite 
their work.  It will keep it separated which will facilitate upgrades.  A 
quick review of the release notes to see what template files have changed, 
cross referenced with the custom theme files, you know quickly what you 
need to change (if anything).  Site admins don.t have to remember what 
they changed, the changes are sitting in their own directory.

This is how I am doing themes in Media Gallery now.  I'll never worry 
about an upgrade overwriting a users template modifications.  It also 
makes theming much easier, if you only want to change the overall album 
view, simply copy the necessary templates over, change them and you're 

Yes, I know, an admin can simply make an exact copy of Professional to 
another theme directory and then hack away and basically accomplish the 
same goal.  The big difference here is that only the changed files need to 
go into the new theme directory.  Also, if new template files are added in 
the next version of Geeklog, no problem, the system will pick them up 
automatically from the Professional layout.  This would accomplish what 
lib-custom.php has tried to do with the code except for themes.

I believe this will facilitate future upgrades significantly.  Think big 
picture, long term stuff here..

[beating dead horse mode off]

While we are talking about themes, I would love to see themes 'registered' 
at some point.  Instead of just doing a quick directory search for all 
directories in layout/, make the site admin actually 'install' the theme 
into Geeklog.  I would also add permissions to the theme record too. 
This would allow an admin to create a test or development theme that is 
only available to a certain group.  When it is ready to go production, 
change the perms so everyone can select.  With all the security checks and 
really great permission model that Geeklog has, scanning a directory for 
the themes just doesn't seem to fit the overall model.


More information about the geeklog-devel mailing list