[geeklog-devel] lib-layout.php

[geiss at midnightforce.com]

While I don't pretend to understand all the behind the scenes code
stuff, I can report that one of the major reasons why theme creation for
GL has languished is because of the sheer amount of files to go through.
Even though one would only end up modifying a handful, many users look
at the professional directory and say, "Whoa!" and get gun shy.

Anything to cut down on the size, or number of files would be fantastic
for a theme dev POV. I especially like the idea of pulling the majority
of .thtml files from the main theme folder, and then building any
modified files in a another directory. All around it seems like a
leaner, meaner, more user friendly solution. Then, you could include
multiple themes in a release without the size overhead of 90% duplicated
files. (since it's been reported that people are complaining about the
size of the archive then need to FTP up to their servers.) ...one other
thought on this is that it seems like the bulk of the file sizes are
coming from all the language files. I would see it as more valuable to
the user to have more theme selection out of the box than language
selection. My thought is to keep a handful of the dominant language
files, and roll the rest into a separate language file download.

Registering themes also is valuable in that you could check for a
particular version of GL to install against. If a theme is only
compatible with v1.5 for instance, when they try to install it on a
1.3.9 site, they would get the appropriate incompatibility message. This
could greatly reduce support issues. How many forum posts contain,
"...copy over the templates from the professional directory..."!

Also, I haven't come across any clear documentation as to what each and
every .thtml file corresponds to on a site. Over time, I've become
relatively familiar with the .thtml files. Once 1.5 is released, I
wouldn't mind creating a document that corresponds .thtml files to the
part of the site they control. We'll see as time progresses.

...back to work! :-)

Eric

> -------- Original Message --------
> Subject: Re: [geeklog-devel] lib-layout.php
> From: "Mark R. Evans" <mevans at ecsnet.com>
> Date: Fri, January 04, 2008 8:01 am
> To: Geeklog Development <geeklog-devel at lists.geeklog.net>
> Blaine,
> 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 
> it..
> [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 
> done.
> 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.
> Thanks!
> Mark
> _______________________________________________
> geeklog-devel mailing list
> geeklog-devel at lists.geeklog.net
> http://eight.pairlist.net/mailman/listinfo/geeklog-devel