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