From geeklog-modules-admin at lists.geeklog.net  Sat May 10 09:31:20 2003
From: geeklog-modules-admin at lists.geeklog.net (geeklog-modules-admin at lists.geeklog.net)
Date: Sat, 10 May 2003 15:31:20 +0200
Subject: [geeklog-modules] Center block API
Message-ID: <20030510133120.13768@smtp.haun-online.de>

I'd like to propose an extension of the center block API (which currently
only exists in CVS anyway, so changing it now shouldn't affect too many
plugins).

Currently, there is only one call to PLG_showCenterblock() at the
beginning of the center area, i.e. above all the stories. No additional
parameters are passed to that function.

I would like to see some flexibility here, so that the center block can
be placed further down the page (e.g. between the featured and the normal
stories or at the end of the page). Also, it may be of interest to the
block which page we're on and what the current topic is, so that you
could write blocks that only show up on the first page or display
different content for the topic pages.

This is what I have in mind:

    function PLG_showCenterblock ($where = 0, $page = 1, $topic = '')

$where can be 0 = top of page, 1 = after the featured story, 2 = bottom
of page,
$page number, obviously,
$topic = the ID of the current topic or empty = front page

As a demo, I've hacked the forum's center block to only show up after the
featured story. See it at <http://geeklog.info/>.

Comments?

bye, Dirk


-- 
http://www.haun-online.de/
http://mypod.de/



From geeklog-modules-admin at lists.geeklog.net  Sat May 10 13:09:32 2003
From: geeklog-modules-admin at lists.geeklog.net (geeklog-modules-admin at lists.geeklog.net)
Date: Sat, 10 May 2003 19:09:32 +0200
Subject: [geeklog-modules] Plugins and comments, again
Message-ID: <20030510170932.19226@smtp.haun-online.de>

Sigh, I have to come back to this issue again ...

A couple of days ago, I suggested that the plugins should handle their
comments themselves. When trying to implement that now, I noticed that
the plugins may be missing some of the information necessary to perform
the task.

The current API is

    plugin_handlecomment_<$type> ($id, $operation='')

where "$type" is the type of comment (= the name of the plugin), "$id" is
the ID of the comment's parent object and "$operation" is either 'save'
or 'delete'.

For the 'save' operation, that's fine (more or less): Geeklog saves the
comment in the gl_comments table and then calls the above function so
that the plugin can update its statistics or whatever. It would be nice,
though, if the plugin would also get the comment ID ...

For the 'delete' operation, this is obviously not sufficient since the
plugin wouldn't know which comment to delete.

So we need an additional parameter. The question is now: Should there be
a new API function for this (so as to not break any existing plugins) or
should we just add the comment id as an additional parameter, e.g.

    plugin_handlecomment_<$type> ($id, $operation='', $cid)

Comments?

bye, Dirk


-- 
http://www.haun-online.de/
http://www.macosx-faq.de/



From geeklog-modules-admin at lists.geeklog.net  Sat May 10 17:11:52 2003
From: geeklog-modules-admin at lists.geeklog.net (geeklog-modules-admin at lists.geeklog.net)
Date: Sat, 10 May 2003 17:11:52 -0400
Subject: [geeklog-modules] Center block API
References: <20030510133120.13768@smtp.haun-online.de>
Message-ID: <002b01c31738$c7a73f60$9a0a10ac@xpbl1>

Dirk,

This would give it more flexibility. I'm just trying to think of how this
will be implemented.

So... each plugin can configure these variables either tru a common admin
(all plugins - yet to be developed) or individual plugin admin, or via
modifiying the plugin function?

Blaine

----- Original Message -----
From: <geeklog-modules-admin at lists.geeklog.net>
To: <geeklog-modules at lists.geeklog.net>
Sent: Saturday, May 10, 2003 9:31 AM
Subject: [geeklog-modules] Center block API


> I'd like to propose an extension of the center block API (which currently
> only exists in CVS anyway, so changing it now shouldn't affect too many
> plugins).
>
> Currently, there is only one call to PLG_showCenterblock() at the
> beginning of the center area, i.e. above all the stories. No additional
> parameters are passed to that function.
>
> I would like to see some flexibility here, so that the center block can
> be placed further down the page (e.g. between the featured and the normal
> stories or at the end of the page). Also, it may be of interest to the
> block which page we're on and what the current topic is, so that you
> could write blocks that only show up on the first page or display
> different content for the topic pages.
>
> This is what I have in mind:
>
>     function PLG_showCenterblock ($where = 0, $page = 1, $topic = '')
>
> $where can be 0 = top of page, 1 = after the featured story, 2 = bottom
> of page,
> $page number, obviously,
> $topic = the ID of the current topic or empty = front page
>
> As a demo, I've hacked the forum's center block to only show up after the
> featured story. See it at <http://geeklog.info/>.
>
> Comments?
>
> bye, Dirk
>
>
> --
> http://www.haun-online.de/
> http://mypod.de/
>
> _______________________________________________
> geeklog-modules mailing list
> geeklog-modules at lists.geeklog.net
> http://lists.geeklog.net/listinfo/geeklog-modules
>



From geeklog-modules-admin at lists.geeklog.net  Sat May 10 17:27:37 2003
From: geeklog-modules-admin at lists.geeklog.net (geeklog-modules-admin at lists.geeklog.net)
Date: Sat, 10 May 2003 23:27:37 +0200
Subject: [geeklog-modules] Center block API
In-Reply-To: <002b01c31738$c7a73f60$9a0a10ac@xpbl1>
References: <002b01c31738$c7a73f60$9a0a10ac@xpbl1>
Message-ID: <20030510212737.14235@smtp.haun-online.de>

Blaine wrote:

>So... each plugin can configure these variables either tru a common admin
>(all plugins - yet to be developed) or individual plugin admin, or via
>modifiying the plugin function?

It would be up to the plugin to provide any form of user interface for
these options. At least that was my idea ...

For example, the position of the block could simply be a an option in the
plugin's config.php file. Or the author of a plugin could decide to not
make this configurable at all.

Admittedly, there's a bit of a problem here with the topics. Since topic
IDs are configured in Geeklog directly, having those in (e.g.) the
plugin's config.php file bears the risk of them getting out of sync. In
this case, the author of the plugin may need to do some more work and
actually provide a setup form for them ...

bye, Dirk


-- 
http://www.haun-online.de/
http://www.tinyweb.de/



From geeklog-modules-admin at lists.geeklog.net  Sat May 10 18:35:46 2003
From: geeklog-modules-admin at lists.geeklog.net (geeklog-modules-admin at lists.geeklog.net)
Date: Sat, 10 May 2003 18:35:46 -0400
Subject: [geeklog-modules] Center block API
References: <002b01c31738$c7a73f60$9a0a10ac@xpbl1> <20030510212737.14235@smtp.haun-online.de>
Message-ID: <005f01c31744$7f8a9770$9a0a10ac@xpbl1>

So in index.php, we will need to call the PLG_showCenterblock ($where = 0,
$page = 1, $topic = '') several times and the plugin functions will need the
logic to figure out when they should return the formated block HTML.

Will there be anyway to prevent a plugin centerblock from firing more then
once or will there be a default position?

Is that your thinking at this time?

----- Original Message -----
From: <geeklog-modules-admin at lists.geeklog.net>
To: <geeklog-modules at lists.geeklog.net>
Sent: Saturday, May 10, 2003 5:27 PM
Subject: Re: [geeklog-modules] Center block API


> Blaine wrote:
>
> >So... each plugin can configure these variables either tru a common admin
> >(all plugins - yet to be developed) or individual plugin admin, or via
> >modifiying the plugin function?
>
> It would be up to the plugin to provide any form of user interface for
> these options. At least that was my idea ...
>
> For example, the position of the block could simply be a an option in the
> plugin's config.php file. Or the author of a plugin could decide to not
> make this configurable at all.
>
> Admittedly, there's a bit of a problem here with the topics. Since topic
> IDs are configured in Geeklog directly, having those in (e.g.) the
> plugin's config.php file bears the risk of them getting out of sync. In
> this case, the author of the plugin may need to do some more work and
> actually provide a setup form for them ...
>
> bye, Dirk
>
>
> --
> http://www.haun-online.de/
> http://www.tinyweb.de/
>
> _______________________________________________
> geeklog-modules mailing list
> geeklog-modules at lists.geeklog.net
> http://lists.geeklog.net/listinfo/geeklog-modules
>



From geeklog-modules-admin at lists.geeklog.net  Sat May 10 18:37:20 2003
From: geeklog-modules-admin at lists.geeklog.net (geeklog-modules-admin at lists.geeklog.net)
Date: Sat, 10 May 2003 18:37:20 -0400
Subject: [geeklog-modules] Plugins and comments, again
References: <20030510170932.19226@smtp.haun-online.de>
Message-ID: <006d01c31744$b7b12240$9a0a10ac@xpbl1>

Dirk,

Can ID not be the comment id - either the parent to individual comment id ?

Blaine
----- Original Message ----- 
From: <geeklog-modules-admin at lists.geeklog.net>
To: <geeklog-modules at lists.geeklog.net>
Sent: Saturday, May 10, 2003 1:09 PM
Subject: [geeklog-modules] Plugins and comments, again


> Sigh, I have to come back to this issue again ...
> 
> A couple of days ago, I suggested that the plugins should handle their
> comments themselves. When trying to implement that now, I noticed that
> the plugins may be missing some of the information necessary to perform
> the task.
> 
> The current API is
> 
>     plugin_handlecomment_<$type> ($id, $operation='')
> 
> where "$type" is the type of comment (= the name of the plugin), "$id" is
> the ID of the comment's parent object and "$operation" is either 'save'
> or 'delete'.
> 
> For the 'save' operation, that's fine (more or less): Geeklog saves the
> comment in the gl_comments table and then calls the above function so
> that the plugin can update its statistics or whatever. It would be nice,
> though, if the plugin would also get the comment ID ...
> 
> For the 'delete' operation, this is obviously not sufficient since the
> plugin wouldn't know which comment to delete.
> 
> So we need an additional parameter. The question is now: Should there be
> a new API function for this (so as to not break any existing plugins) or
> should we just add the comment id as an additional parameter, e.g.
> 
>     plugin_handlecomment_<$type> ($id, $operation='', $cid)
> 
> Comments?
> 
> bye, Dirk
> 
> 
> -- 
> http://www.haun-online.de/
> http://www.macosx-faq.de/
> 
> _______________________________________________
> geeklog-modules mailing list
> geeklog-modules at lists.geeklog.net
> http://lists.geeklog.net/listinfo/geeklog-modules
> 



From geeklog-modules-admin at lists.geeklog.net  Sun May 11 10:09:02 2003
From: geeklog-modules-admin at lists.geeklog.net (geeklog-modules-admin at lists.geeklog.net)
Date: Sun, 11 May 2003 10:09:02 -0400
Subject: [geeklog-modules] Center block API
References: <002b01c31738$c7a73f60$9a0a10ac@xpbl1> <20030510212737.14235@smtp.haun-online.de> <003f01c26c5e$2339a060$275bf7a5@lm76>
Message-ID: <001601c317c6$dff11cb0$9a0a10ac@xpbl1>

JD,

This is being implemented as a Plugin API and thus will only look for
registered plugins to see if they have such a function.
All the plugin API's are like this.

So example. If I am making a plugin called mystuff and its installed and
tested. When  PLG_showCenterblock() is called, it will look for a  function
called plugin_centerblock_mystuff(). If it exists - it will be executed.

You could modify index.php and add a call to your own centerblock routine -
right after the call to PLG_showCenterblock. I have done that on my site.

GL needs to know what possible functions to call and using registered
(installed) plugins is one such way. I'd imagine we could also use the name
of installed blocks and see if there is such a defined function as well. So
if I have a stockblock that I want to show in the center. Look for
phpblock_centerblock_stockblock();

Blaine
----- Original Message -----
From: <geeklog-modules-admin at lists.geeklog.net>
To: <geeklog-modules at lists.geeklog.net>
Sent: Saturday, October 05, 2002 6:58 AM
Subject: Re: [geeklog-modules] Center block API


> I like your idea of making a flexible centerblock so we can place
> it in different positions on the frontpage and topics.  Having
> them between stories would be nice too, but I personally would
> not miss this if it's not included.
>
> I'm confused though on how someone would use this feature.  Say I
> wanted to make three different center blocks...two on the
> front-page (one top, one bottom) and the third at the top on a
> specific topic.  Would this require making a totally separate
> plugin for each or could one plugin do as many different
> centerblocks as a person wants?  What I'm thinking of is a
> similar functionality as we already have in the block manager but
> for the center.
>
> JD
>
> ----- Original Message -----
> From: <geeklog-modules-admin at lists.geeklog.net>
> To: <geeklog-modules at lists.geeklog.net>
> Sent: Saturday, May 10, 2003 5:27 PM
> Subject: Re: [geeklog-modules] Center block API
>
>
> Blaine wrote:
>
> >So... each plugin can configure these variables either tru a
> common admin
> >(all plugins - yet to be developed) or individual plugin admin,
> or via
> >modifiying the plugin function?
>
> It would be up to the plugin to provide any form of user
> interface for
> these options. At least that was my idea ...
>
> For example, the position of the block could simply be a an
> option in the
> plugin's config.php file. Or the author of a plugin could decide
> to not
> make this configurable at all.
>
> Admittedly, there's a bit of a problem here with the topics.
> Since topic
> IDs are configured in Geeklog directly, having those in (e.g.)
> the
> plugin's config.php file bears the risk of them getting out of
> sync. In
> this case, the author of the plugin may need to do some more work
> and
> actually provide a setup form for them ...
>
> bye, Dirk
>
>
> --
> http://www.haun-online.de/
> http://www.tinyweb.de/
>
> _______________________________________________
> geeklog-modules mailing list
> geeklog-modules at lists.geeklog.net
> http://lists.geeklog.net/listinfo/geeklog-modules
>
> _______________________________________________
> geeklog-modules mailing list
> geeklog-modules at lists.geeklog.net
> http://lists.geeklog.net/listinfo/geeklog-modules



From geeklog-modules-admin at lists.geeklog.net  Sun May 11 11:31:44 2003
From: geeklog-modules-admin at lists.geeklog.net (geeklog-modules-admin at lists.geeklog.net)
Date: Sun, 11 May 2003 11:31:44 -0400
Subject: [geeklog-modules] Center block API
References: <002b01c31738$c7a73f60$9a0a10ac@xpbl1> <20030510212737.14235@smtp.haun-online.de> <003f01c26c5e$2339a060$275bf7a5@lm76> <001601c317c6$dff11cb0$9a0a10ac@xpbl1>
Message-ID: <005a01c317d2$aaa336e0$275bf7a5@lm76>

Okay, I see.  Well, it's definitely much better than we have now.

JD

----- Original Message -----
From: <geeklog-modules-admin at lists.geeklog.net>
To: <geeklog-modules at lists.geeklog.net>
Sent: Sunday, May 11, 2003 10:09 AM
Subject: Re: [geeklog-modules] Center block API


JD,

This is being implemented as a Plugin API and thus will only look
for
registered plugins to see if they have such a function.
All the plugin API's are like this.

So example. If I am making a plugin called mystuff and its
installed and
tested. When  PLG_showCenterblock() is called, it will look for a
function
called plugin_centerblock_mystuff(). If it exists - it will be
executed.

You could modify index.php and add a call to your own centerblock
routine -
right after the call to PLG_showCenterblock. I have done that on
my site.

GL needs to know what possible functions to call and using
registered
(installed) plugins is one such way. I'd imagine we could also
use the name
of installed blocks and see if there is such a defined function
as well. So
if I have a stockblock that I want to show in the center. Look
for
phpblock_centerblock_stockblock();

Blaine
----- Original Message -----
From: <geeklog-modules-admin at lists.geeklog.net>
To: <geeklog-modules at lists.geeklog.net>
Sent: Sunday, May 11, 2003 6:58 AM
Subject: Re: [geeklog-modules] Center block API


> I like your idea of making a flexible centerblock so we can
place
> it in different positions on the frontpage and topics.  Having
> them between stories would be nice too, but I personally would
> not miss this if it's not included.
>
> I'm confused though on how someone would use this feature.  Say
I
> wanted to make three different center blocks...two on the
> front-page (one top, one bottom) and the third at the top on a
> specific topic.  Would this require making a totally separate
> plugin for each or could one plugin do as many different
> centerblocks as a person wants?  What I'm thinking of is a
> similar functionality as we already have in the block manager
but
> for the center.
>
> JD
>
> ----- Original Message -----
> From: <geeklog-modules-admin at lists.geeklog.net>
> To: <geeklog-modules at lists.geeklog.net>
> Sent: Saturday, May 10, 2003 5:27 PM
> Subject: Re: [geeklog-modules] Center block API
>
>
> Blaine wrote:
>
> >So... each plugin can configure these variables either tru a
> common admin
> >(all plugins - yet to be developed) or individual plugin
admin,
> or via
> >modifiying the plugin function?
>
> It would be up to the plugin to provide any form of user
> interface for
> these options. At least that was my idea ...
>
> For example, the position of the block could simply be a an
> option in the
> plugin's config.php file. Or the author of a plugin could
decide
> to not
> make this configurable at all.
>
> Admittedly, there's a bit of a problem here with the topics.
> Since topic
> IDs are configured in Geeklog directly, having those in (e.g.)
> the
> plugin's config.php file bears the risk of them getting out of
> sync. In
> this case, the author of the plugin may need to do some more
work
> and
> actually provide a setup form for them ...
>
> bye, Dirk
>
>
> --
> http://www.haun-online.de/
> http://www.tinyweb.de/
>
> _______________________________________________
> geeklog-modules mailing list
> geeklog-modules at lists.geeklog.net
> http://lists.geeklog.net/listinfo/geeklog-modules
>
> _______________________________________________
> geeklog-modules mailing list
> geeklog-modules at lists.geeklog.net
> http://lists.geeklog.net/listinfo/geeklog-modules

_______________________________________________
geeklog-modules mailing list
geeklog-modules at lists.geeklog.net
http://lists.geeklog.net/listinfo/geeklog-modules






From geeklog-modules-admin at lists.geeklog.net  Sun May 11 12:45:07 2003
From: geeklog-modules-admin at lists.geeklog.net (geeklog-modules-admin at lists.geeklog.net)
Date: Sun, 11 May 2003 18:45:07 +0200
Subject: [geeklog-modules] Plugins and comments, again
In-Reply-To: <006d01c31744$b7b12240$9a0a10ac@xpbl1>
References: <006d01c31744$b7b12240$9a0a10ac@xpbl1>
Message-ID: <20030511164507.24999@smtp.haun-online.de>

Blaine wrote:

>Can ID not be the comment id - either the parent to individual comment id ?

You're right - that was too simple for me :-)

Since the parent id is stored in the comments table, it would enough if
Geeklog would simply pass the comment id for both the save and the delete
operation. If the plugin needs the parent, it can easily get it from the
comment table.

I'll try implementing that ...

bye, Dirk


-- 
http://www.haun-online.de/
http://geeklog.info/



From geeklog-modules-admin at lists.geeklog.net  Mon May 12 06:44:26 2003
From: geeklog-modules-admin at lists.geeklog.net (geeklog-modules-admin at lists.geeklog.net)
Date: Mon, 12 May 2003 12:44:26 +0200
Subject: [geeklog-modules] Center block API
In-Reply-To: <005f01c31744$7f8a9770$9a0a10ac@xpbl1>
References: <005f01c31744$7f8a9770$9a0a10ac@xpbl1>
Message-ID: <20030512104426.31493@smtp.haun-online.de>

Blaine wrote:

>So in index.php, we will need to call the PLG_showCenterblock ($where = 0,
>$page = 1, $topic = '') several times and the plugin functions will need the
>logic to figure out when they should return the formated block HTML.

Yep. Geeklog could cache the information which plugin actually supports
the center block API so that we only need one MySQL request.


>Will there be anyway to prevent a plugin centerblock from firing more then
>once or will there be a default position?

That would be in the plugin's responsibility. With all those parameters
that it is given, it should be easy to figure out.

Actually, I was thinking some more about this and I'd like to take it one
step further: What we have with the "static pages on frontpage" hack is,
effectively, a center block (specifically hacked into Geeklog for that
one plugin). So it would make sense to replace that hack with a proper
center block call for the static pages plugin.

However, static pages has one additional feature: "nonews", i.e. the
ability to replace the frontpage entirely. I would image that this could
be used e.g. for the forum center block as well - you could have a
Geeklog site that only displays the forum topics on the frontpage.

So my revised suggestion for the API and its parameters would be:

    function PLG_showCenterblock ($where = 1, $page = 1, $topic = '')

Where $where would now mean 0 = nonews, i.e. center block takes over the
entire page, 1 = top of page, 2 = after the featured story, 3 = bottom of
page.

So for $where = 0, the plugin would either return an empty string (if it
doesn't intend to take over the page) or it would have to return the
_complete_ HTML to be displayed, i.e. including site header and footer
(the static pages plugin has an option to create a page without the
header and footer). Of course, only one plugin could take over the page,
so Geeklog would stop calling the other plugins as soon as one returns a
non-empty string for PLG_showCenterblock(0).

For $where = 1, 2, 3 the plugin would simply return the HTML for the
block and Geeklog would place it above, between, or below the stories,
respectively.

How does that sound? One MySQL request (if cached), and up to four
PLG_showCenterblock() calls (only to those plugins that actually
implement the API) shouldn't have too much of an impact on the
performance, but would offer a lot of flexibility.

bye, Dirk


-- 
http://www.haun-online.de/
http://www.tinyweb.de/



From geeklog-modules-admin at lists.geeklog.net  Mon May 12 08:50:52 2003
From: geeklog-modules-admin at lists.geeklog.net (geeklog-modules-admin at lists.geeklog.net)
Date: Mon, 12 May 2003 08:50:52 -0400
Subject: [geeklog-modules] Center block API
In-Reply-To: <20030512104426.31493@smtp.haun-online.de>
References: <005f01c31744$7f8a9770$9a0a10ac@xpbl1> <20030512104426.31493@smtp.haun-online.de>
Message-ID: <3EBF98AC.9090907@abtech.org>

Dirk,

I think it might be better to add a $CONF variable 'fp_nonews' or 
similar which, when set to true, would disable news on the index page. 
I don't think putting the option in the function call to the plugin API 
makes much sense in this case.

Using a config variable would make things more straight forward than 
people figuring which flags need to be set in function calls and/or what 
format to return the results of a function in.

Other than that I like the ability to control front page content.

-Vinny

geeklog-modules-admin at lists.geeklog.net wrote:
> Blaine wrote:
> 
> 
>>So in index.php, we will need to call the PLG_showCenterblock ($where = 0,
>>$page = 1, $topic = '') several times and the plugin functions will need the
>>logic to figure out when they should return the formated block HTML.
> 
> 
> Yep. Geeklog could cache the information which plugin actually supports
> the center block API so that we only need one MySQL request.
> 
> 
> 
>>Will there be anyway to prevent a plugin centerblock from firing more then
>>once or will there be a default position?
> 
> 
> That would be in the plugin's responsibility. With all those parameters
> that it is given, it should be easy to figure out.
> 
> Actually, I was thinking some more about this and I'd like to take it one
> step further: What we have with the "static pages on frontpage" hack is,
> effectively, a center block (specifically hacked into Geeklog for that
> one plugin). So it would make sense to replace that hack with a proper
> center block call for the static pages plugin.
> 
> However, static pages has one additional feature: "nonews", i.e. the
> ability to replace the frontpage entirely. I would image that this could
> be used e.g. for the forum center block as well - you could have a
> Geeklog site that only displays the forum topics on the frontpage.
> 
> So my revised suggestion for the API and its parameters would be:
> 
>     function PLG_showCenterblock ($where = 1, $page = 1, $topic = '')
> 
> Where $where would now mean 0 = nonews, i.e. center block takes over the
> entire page, 1 = top of page, 2 = after the featured story, 3 = bottom of
> page.
> 
> So for $where = 0, the plugin would either return an empty string (if it
> doesn't intend to take over the page) or it would have to return the
> _complete_ HTML to be displayed, i.e. including site header and footer
> (the static pages plugin has an option to create a page without the
> header and footer). Of course, only one plugin could take over the page,
> so Geeklog would stop calling the other plugins as soon as one returns a
> non-empty string for PLG_showCenterblock(0).
> 
> For $where = 1, 2, 3 the plugin would simply return the HTML for the
> block and Geeklog would place it above, between, or below the stories,
> respectively.
> 
> How does that sound? One MySQL request (if cached), and up to four
> PLG_showCenterblock() calls (only to those plugins that actually
> implement the API) shouldn't have too much of an impact on the
> performance, but would offer a lot of flexibility.
> 
> bye, Dirk
> 
> 



From geeklog-modules-admin at lists.geeklog.net  Mon May 12 09:05:55 2003
From: geeklog-modules-admin at lists.geeklog.net (geeklog-modules-admin at lists.geeklog.net)
Date: Mon, 12 May 2003 15:05:55 +0200
Subject: [geeklog-modules] Center block API
In-Reply-To: <3EBF98AC.9090907@abtech.org>
References: <3EBF98AC.9090907@abtech.org>
Message-ID: <20030512130555.14822@smtp.haun-online.de>

Vinny wrote:

>I think it might be better to add a $CONF variable 'fp_nonews' or 
>similar which, when set to true, would disable news on the index page.

Err, how would that work? If, say, both the forum and the static pages
plugin would have the ability to replace the frontpage, how would a flag
decide which one should?


>Using a config variable would make things more straight forward than 
>people figuring which flags need to be set in function calls and/or what 
>format to return the results of a function in.

Of course, the plugins which support this feature would have to provide
some way for the user to configure it. Currently, the static pages plugin
does that by assuming a static page named "frontpage" should replace the
frontpage. A simple checkbox would probably do it for most plugins (and
would be more intuitive).

bye, Dirk


-- 
http://www.haun-online.de/
http://www.tinyweb.de/



From geeklog-modules-admin at lists.geeklog.net  Mon May 12 09:17:05 2003
From: geeklog-modules-admin at lists.geeklog.net (geeklog-modules-admin at lists.geeklog.net)
Date: Mon, 12 May 2003 09:17:05 -0400
Subject: [geeklog-modules] Center block API
In-Reply-To: <20030512130555.14822@smtp.haun-online.de>
References: <3EBF98AC.9090907@abtech.org> <20030512130555.14822@smtp.haun-online.de>
Message-ID: <3EBF9ED1.2020300@abtech.org>

What about the case when you want multiple center blocks, but no news? 
That is why I though a no news flag would be appropriate.  Also, I don't 
think we should place the burden on plugin developers to create an 
complex administrative GUI to control the content of the front page.  If 
we go that route an Admin may have to go to each individual plugin page 
to adjust the content of the center block.

Using a flag in the config.php will allow multiple center blocks to 
appear on the front page (and would even give limited control of the 
order they appear for up to three blocks by the where parameter [1. 
before news, 2. after featured story, 3. after news]).  Also, control 
over the articles that appears on the front page won't rest within 
plugins that have nothing to do with the articles (less confusion?).

Instead of a $CONF variable, a database variable may be equally relevant 
for this.  But I think the core geeklog should control if news is displayed.

-Vinny

geeklog-modules-admin at lists.geeklog.net wrote:
> Vinny wrote:
> 
> 
>>I think it might be better to add a $CONF variable 'fp_nonews' or 
>>similar which, when set to true, would disable news on the index page.
> 
> 
> Err, how would that work? If, say, both the forum and the static pages
> plugin would have the ability to replace the frontpage, how would a flag
> decide which one should?
> 
> 
> 
>>Using a config variable would make things more straight forward than 
>>people figuring which flags need to be set in function calls and/or what 
>>format to return the results of a function in.
> 
> 
> Of course, the plugins which support this feature would have to provide
> some way for the user to configure it. Currently, the static pages plugin
> does that by assuming a static page named "frontpage" should replace the
> frontpage. A simple checkbox would probably do it for most plugins (and
> would be more intuitive).
> 
> bye, Dirk
> 
> 



From geeklog-modules-admin at lists.geeklog.net  Mon May 12 09:59:35 2003
From: geeklog-modules-admin at lists.geeklog.net (geeklog-modules-admin at lists.geeklog.net)
Date: Mon, 12 May 2003 15:59:35 +0200
Subject: [geeklog-modules] Center block API
In-Reply-To: <3EBF9ED1.2020300@abtech.org>
References: <3EBF9ED1.2020300@abtech.org>
Message-ID: <20030512135935.11332@smtp.haun-online.de>

Vinny wrote:

>What about the case when you want multiple center blocks, but no news? 

Ah, now I see your point. That would indeed not be possible with what I
have suggested so far.

I was (again) thinking in terms of the static pages plugin. There you
have the option to have the static page on a blank page, a page with only
header & footer, a page with header, footer & left blocks or on a page
with header, footer, left & right blocks. Hence the idea to leave all
that under the control of the plugin.


>Also, I don't 
>think we should place the burden on plugin developers to create an 
>complex administrative GUI to control the content of the front page.

Would it really become that complex?


>If we go that route an Admin may have to go to each individual plugin 
>page to adjust the content of the center block.

I tried to think of a way to control the center block from Geeklog's
Block Admin menu (so that you had a central place to control them all),
but it didn't work out for a number of details ...

bye, Dirk


-- 
http://www.haun-online.de/
http://www.macosx-faq.de/



From geeklog-modules-admin at lists.geeklog.net  Mon May 19 09:01:27 2003
From: geeklog-modules-admin at lists.geeklog.net (geeklog-modules-admin at lists.geeklog.net)
Date: Mon, 19 May 2003 15:01:27 +0200
Subject: [geeklog-modules] Center block API
In-Reply-To: <3EBF98AC.9090907@abtech.org>
References: <3EBF98AC.9090907@abtech.org>
Message-ID: <20030519130127.20250@smtp.haun-online.de>

Vinny wrote:

>I think it might be better to add a $CONF variable 'fp_nonews' or 
>similar which, when set to true, would disable news on the index page.

After thinking about it some more, I'm beginning to like this. I would
probably implement this such that calling up the front page with
index.php?page=1 brings the news back, so that you can put a link
somewhere that links to the stories.

However, I would still like to be able to replace the frontpage entirely,
like you can do with the current "static page on frontpage" hack, but
with a more generalized interface so that any plugin could take over the
frontpage if the user wants that to happen.

Couldn't think of a good way to configure this, though. Any ideas anyone?

bye, Dirk


-- 
http://www.haun-online.de/
http://mypod.de/



From geeklog-modules-admin at lists.geeklog.net  Thu May 22 17:08:12 2003
From: geeklog-modules-admin at lists.geeklog.net (geeklog-modules-admin at lists.geeklog.net)
Date: Thu, 22 May 2003 23:08:12 +0200
Subject: [geeklog-modules] Center block API
In-Reply-To: <20030519130127.20250@smtp.haun-online.de>
References: <20030519130127.20250@smtp.haun-online.de>
Message-ID: <20030522210812.25832@smtp.haun-online.de>

Center block API, again ...

I decided the best way to come to a decision would be to try and
implement the new API so that I could play around with it a bit.

The first thing I noticed is that the idea of having a $_CONF option for
"nonews" (i.e. whether news should be displayed on the frontpage or not)
has a problem: Suppose I wanted to display a "splash screen" to anonymous
users and the normal index page to logged-in users. You can't do that
with a global setting ...

So I went back to my previous idea and implemented an extra mode for the
center block call where the plugin has the chance to replace the
frontpage entirely.

Actually, there's a slight difference between these two things: One is
that you want to be able not to display news on the front page and the
other is to have an option such that a plugin can "take over" the
frontpage. But I couldn't think of a good way to make that configurable.

So what I've implemented now are the 4 modes for PLG_showCenterblock, as
mentioned before (top of page, after the featured story, bottom of page,
take over frontpage). I've also implemented a buffered version of
PLG_showCenterblock (i.e. it only does one MySQL request and re-uses the
result on the subsequent calls), removed the "static pages on frontpage
hack" from index.php and implemented the center block API in the static
pages plugin instead.

The new functionality of the static pages is currently as follows:

- label equals "frontpage": will be displayed above the stories when no
topic is selected
- label equals "topic:topic-id": will be displayed above the stories when
the topic with that topic-id is selected
- label equals "nonews" and no topic selected and it's page #1: take over
the frontpage entirely

Note that I moved the keywords to the label (from the title of the static
page). I'm thinking about adding extra field to the plugin and let you
select the topic from a drop-down menu (similar to what we have for
blocks). Also missing is the ability to display static pages after the
featured story and at the bottom of the page. That, too, would require a
new field in the database.

Consider the current implementation (in CVS now and soon in the nightly
tarball) a request for discussion, not a final implementation ...

bye, Dirk


-- 
http://www.haun-online.de/
http://www.macosx-faq.de/