[geeklog-devel] lib-layout.php

[Euan McKay]

I haven't followed this entire discussion, but this is what I do mostly:

1) I have a theme based off professional incorporating the blueprint
css library (http://code.google.com/p/blueprintcss/) so windows layout
is not too much hassle.
2) I add a new css file for my new theme and put everything I do in there.
3) I then make any changes to the actual theme files if required.

If I then upgrade, I only need to update my base theme, and everything
else is roughly the same - less a few patches from (3).

I think it makes sense to have a "template" folder, with the basic
(x)html files, and then a "theme" folder that holds the unique images
and css for each theme.

2 yen.

Cheers,

Euan.


On 1/5/08, geiss at midnightforce.com <geiss at midnightforce.com> wrote:
> 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
>
> _______________________________________________
> geeklog-devel mailing list
> geeklog-devel at lists.geeklog.net
> http://eight.pairlist.net/mailman/listinfo/geeklog-devel
>


-- 
-----------------------------------------------------------------------------
Euan McKay
PhD Candidate in International Relations
Department of Advanced Social and International Studies
Graduate School of Arts and Sciences
The University of Tokyo