[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