[geeklog-devel] Geeklog 1.9.0 or Geeklog 2.0.0?

[Tom]

>> I don't know if it's a big redesign, but the real question is how much
effort is it to change Geeklog core to pass this information to 
>> COM_siteHeader. Plugins will already be broken so don't worry about that.
It is only the non-plugin pages that need to be considered.

We sort of talked about his before (see
http://project.geeklog.net/tracking/view.php?id=1358) and a few interesting
ideas where floated around. The other problem we have is in some cases (like
the use of autotags or the mobile phone theme that uses jquery) we need to
add lines to the header (css files, javascript) and we can't because
COM_siteHeader has already run before we knew that a block or autotag was
going to display.

COM_siteHeader and COM_siteFooter really should be the last things called
before the webpage is displayed.

Tom

-----Original Message-----
From: geeklog-devel-bounces at lists.geeklog.net
[mailto:geeklog-devel-bounces at lists.geeklog.net] On Behalf Of Joe Mucchiello
Sent: March-15-12 12:03 AM
To: Vincent Furia; Geeklog Development
Subject: Re: [geeklog-devel] Geeklog 1.9.0 or Geeklog 2.0.0?

>From: Vincent Furia <vfuria at gmail.com>
>To: Joe Mucchiello <jmucchiello at yahoo.com>; Geeklog Development 
><geeklog-devel at lists.geeklog.net>
>Sent: Wednesday, March 14, 2012 10:26 PM
>Subject: Re: [geeklog-devel] Geeklog 1.9.0 or Geeklog 2.0.0?
> 
>As of now, it would take a pretty serious redesign of how pages are built.
That isn't out of the question, and may end up being part of a GSoC project
(if we're selected, and depending on the details of student projects).
>
>Pages call these functions to generate the page template: COM_siteHeader,
COM_siteFooter. COM_siteHeader can be passed with an option to disable left
blocks. COM_siteFooter can be passed with an option to disable right blocks.
>
>There is currently no consistency as to when (or where) these function are
called for all the pages.


I don't know if it's a big redesign, but the real question is how much
effort is it to change Geeklog core to pass this information to
COM_siteHeader. Plugins will already be broken so don't worry about that. It
is only the non-plugin pages that need to be considered. 


Regexes are fun: 173 out of 178 calls to COM_siteFooter in he core use the
function defaults and "true" is used in the other 5 calls. In other words,
inside Geeklog core and the shipped plugins, there are only 5 places where
it is not known ahead of time if the blocks will display, based on the
$_CONF stuff. This really isn't that big a project. In most cases, it is
assumed they will not display unless forced by the $_CONF settings. This
means if a parameter were added to COM_siteHeader to store this data f or
use in a new COM_siteFooter, only the 5 places where true is sent to
COM_siteFooter would need updating to pass this info to COM_siteHeader:

public_html\admin\plugins\spamx\index.php
public_html\directory.php
public_html\index.php
public_html\lib-common.php (called twice in here)

How the information is carried to COM_siteFooter from COM_siteHeader?
Probably overriding the $_CONF setting that already exists. :-)

_______________________________________________
geeklog-devel mailing list
geeklog-devel at lists.geeklog.net
http://eight.pairlist.net/mailman/listinfo/geeklog-devel