From greg.gillis at sillig.com  Thu Oct  1 11:05:23 2009
From: greg.gillis at sillig.com (Greg Gillis)
Date: Thu, 1 Oct 2009 10:05:23 -0500
Subject: [geeklog-devel] PLG_itemDisplay() hook in lib-story
In-Reply-To: <20090929195713.2102634359@smtp.haun-online.de>
References: <ed01086a0909291131l639426dev561b9471874d66e1@mail.gmail.com>
	<20090929195713.2102634359@smtp.haun-online.de>
Message-ID: <ed01086a0910010805m5b738498m57aafc8cc81dc404@mail.gmail.com>

Thanks Dirk,
PLG_templateSetVars worked fine.

If PLG_itemDisplay() in lib-story.php is included in a future version of
Geeklog I will switch back to it since it would not require three template
file changes.


Regards,

Greg




On Tue, Sep 29, 2009 at 2:57 PM, Dirk Haun <dirk at haun-online.de> wrote:

> Greg Gillis wrote:
>
> >Back around version 1.4 there was a proposed PLG_itemDisplay() hook in
> >lib-story.php.
> >http://project.geeklog.net/cgi-bin/hgwebdir.cgi/geeklog/rev/3d49aa6f192d
>
> Thanks for digging this up.
>
>
> >I wrote a plugin to add your choice of social network icons to the bottom
> of
> >each story and it requires this hook.
>
> Is there anything that PLG_itemDisplay does that could not be done using
> PLG_templateSetVars?
>
> I guess the main difference is that you wouldn't need to modify the
> story templates. But at the same time it would be more flexible, since
> that implementation of PLG_itemDisplay only added things to one specific
> template variable.
>
> bye, Dirk
>
>
> --
> http://www.geeklog.net/
> http://geeklog.info/
>
> _______________________________________________
> geeklog-devel mailing list
> geeklog-devel at lists.geeklog.net
> http://eight.pairlist.net/mailman/listinfo/geeklog-devel
>



-- 
Greg Gillis
Webmaster www.sillig.com

Microsoft Certified Professional
Network+ Certified Professional
A+ Certified Professional

This email message is for the sole use of the intended recipient(s) and may
contain confidential, proprietary and privileged information.  Any
unauthorized review, use, disclosure or distribution is prohibited.  If you
are not the intended recipient, please contact the sender by reply email and
destroy all copies of the original message.  Thank you
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://pairlist8.pair.net/pipermail/geeklog-devel/attachments/20091001/4dbc7f20/attachment.html>

From Randy.Kolenko at nextide.ca  Fri Oct  2 16:54:17 2009
From: Randy.Kolenko at nextide.ca (Randy Kolenko)
Date: Fri, 2 Oct 2009 16:54:17 -0400
Subject: [geeklog-devel] Autoinstall plugins and dependencies
Message-ID: <063B8B70CB9DA141B2FC1DB483561B9F112242@nex-pluto.nextide.ca>

The autoinstall for plugins is a great way to eliminate the manual
install process and to facilitate the upload of plugins.
However there are some functional aspects of the autoinstall process
which need to be addressed.  In particular the idea of plugins which
have dependencies on other plugins.

For example, if Plugin A depends on Plugin B being installed, there is
no way with the autoinstaller to notify the end user that their plugin A
needs to have Plugin B installed first.  

We need to have a change to the plugin install routine to have a
preliminary installation check done first so that the plugin being
installed has the chance to check for dependencies, and return friendly
error messages.

This augmentation needs to behave with the fresh/clean installation of
geeklog as well in the event plugins are bundled with a distribution.
That means that a prerequisite test should not disrupt the clean
installation of plugins during a fresh install and should gracefully not
install themselves.

I suggest having a plugin_autoinstall_prerequisite_pluginname function
in the autoinstall.php file that would carry out the dependency checks
and return status/message codes.  On a geeklog fresh install, those
status/error codes can be dumped to the error log, and on manual
installs, they can be displayed as error messages in the plugin admin
page.

Thoughts?

-randy


From vfuria at gmail.com  Fri Oct  2 21:28:06 2009
From: vfuria at gmail.com (Vincent Furia)
Date: Fri, 2 Oct 2009 19:28:06 -0600
Subject: [geeklog-devel] Autoinstall plugins and dependencies
In-Reply-To: <063B8B70CB9DA141B2FC1DB483561B9F112242@nex-pluto.nextide.ca>
References: <063B8B70CB9DA141B2FC1DB483561B9F112242@nex-pluto.nextide.ca>
Message-ID: <8319e2d60910021828n589133e9s27126fe7eb33bd2@mail.gmail.com>

Are there any plugins out there (yet) that require another plugin to be
installed? While its certainly something that should take into account going
forward, are we borrowing trouble addressing an issue that doesn't exist
yet?

-Vinny

On Fri, Oct 2, 2009 at 2:54 PM, Randy Kolenko <Randy.Kolenko at nextide.ca>wrote:

> The autoinstall for plugins is a great way to eliminate the manual
> install process and to facilitate the upload of plugins.
> However there are some functional aspects of the autoinstall process
> which need to be addressed.  In particular the idea of plugins which
> have dependencies on other plugins.
>
> For example, if Plugin A depends on Plugin B being installed, there is
> no way with the autoinstaller to notify the end user that their plugin A
> needs to have Plugin B installed first.
>
> We need to have a change to the plugin install routine to have a
> preliminary installation check done first so that the plugin being
> installed has the chance to check for dependencies, and return friendly
> error messages.
>
> This augmentation needs to behave with the fresh/clean installation of
> geeklog as well in the event plugins are bundled with a distribution.
> That means that a prerequisite test should not disrupt the clean
> installation of plugins during a fresh install and should gracefully not
> install themselves.
>
> I suggest having a plugin_autoinstall_prerequisite_pluginname function
> in the autoinstall.php file that would carry out the dependency checks
> and return status/message codes.  On a geeklog fresh install, those
> status/error codes can be dumped to the error log, and on manual
> installs, they can be displayed as error messages in the plugin admin
> page.
>
> Thoughts?
>
> -randy
> _______________________________________________
> geeklog-devel mailing list
> geeklog-devel at lists.geeklog.net
> http://eight.pairlist.net/mailman/listinfo/geeklog-devel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://pairlist8.pair.net/pipermail/geeklog-devel/attachments/20091002/01dce3bb/attachment.html>

From devel at portalparts.com  Fri Oct  2 23:38:58 2009
From: devel at portalparts.com (Blaine Lang)
Date: Fri, 02 Oct 2009 23:38:58 -0400
Subject: [geeklog-devel] Autoinstall plugins and dependencies
In-Reply-To: <8319e2d60910021828n589133e9s27126fe7eb33bd2@mail.gmail.com>
References: <063B8B70CB9DA141B2FC1DB483561B9F112242@nex-pluto.nextide.ca>
	<8319e2d60910021828n589133e9s27126fe7eb33bd2@mail.gmail.com>
Message-ID: <BLU0-SMTP2064843818965349B23379BCD10@phx.gbl>

Vincent Furia wrote:
> Are there any plugins out there (yet) that require another plugin to 
> be installed? While its certainly something that should take into 
> account going forward, are we borrowing trouble addressing an issue 
> that doesn't exist yet?
>
Yes, several of the nexpro suite plugins have dependencies on other 
plugins. Most of the plugins are dependand on the nexpro core plugin and 
others need the nexlist plugin. The nexflow plugin uses the nexform 
plugin for creating forms and routing them for review and approval. The 
nexproject plugin needs nexfile and nexforum.,

Our new release will be using the core nexpro plugin to manage even more 
common code and config options online for the other plugins. Our plugins 
today, have a pre-install hook that is called on install and checks if 
the dependencies like other plugins, directories, perms etc are tested 
before allowing the install to proceed and we show the site admin the 
status of the pre-requisites.

The autoinstall feature works well but is missing this ability. The 
autoinstall should check if a plugin has 'preinstallcheck' function, and 
allow that plugin to return more then a status or message. It should 
optionally be able to return a formated page - that can display status 
of any requirements. The autoinstall needs to have an fully automatic 
mode that is invoked if a plugin archive is uploaded or when geeklog is 
being installed - as it is now. The autoinstall is also invoked if you 
do a normal individual plugin install and  there should be an option of 
calling a preinstall function to display a splash page or into page 
before proceeding with the manual install. This function can also 
display the results of any preinstall checks.

It also would be nice if there was a way to control the order plugins 
are installed.

So in summary:
 - autopreinstall($mode)
 - if mode ==  'automatic' then just return a status and message.
 - if mode == 'manual' then return a status and formatted page

Blaine


From vfuria at gmail.com  Sat Oct  3 11:38:25 2009
From: vfuria at gmail.com (Vincent Furia)
Date: Sat, 3 Oct 2009 09:38:25 -0600
Subject: [geeklog-devel] Autoinstall plugins and dependencies
In-Reply-To: <BLU0-SMTP2064843818965349B23379BCD10@phx.gbl>
References: <063B8B70CB9DA141B2FC1DB483561B9F112242@nex-pluto.nextide.ca> 
	<8319e2d60910021828n589133e9s27126fe7eb33bd2@mail.gmail.com> 
	<BLU0-SMTP2064843818965349B23379BCD10@phx.gbl>
Message-ID: <8319e2d60910030838x7fe3c126vb06ae9077c62b835@mail.gmail.com>

Is there a reason why:

Our plugins today, have a pre-install hook that is called on install and
checks if the dependencies like other plugins, directories, perms etc are
tested before allowing the install to proceed and we show the site admin the
status of the pre-requisites.

Isn't sufficient?

Would a dependency array work better.

PluginA_Required = array('PluginB', 'PluginC');.

With that information the autoinstaller could be made to be smart enough to
generate a dependency tree and install multiple plugins in order. Other
"preinstall" checks (file permisisons, etc) could be accomplished in the
install function.

-Vinny

On Fri, Oct 2, 2009 at 9:38 PM, Blaine Lang <devel at portalparts.com> wrote:

> Vincent Furia wrote:
>
>> Are there any plugins out there (yet) that require another plugin to be
>> installed? While its certainly something that should take into account going
>> forward, are we borrowing trouble addressing an issue that doesn't exist
>> yet?
>>
>>  Yes, several of the nexpro suite plugins have dependencies on other
> plugins. Most of the plugins are dependand on the nexpro core plugin and
> others need the nexlist plugin. The nexflow plugin uses the nexform plugin
> for creating forms and routing them for review and approval. The nexproject
> plugin needs nexfile and nexforum.,
>
> Our new release will be using the core nexpro plugin to manage even more
> common code and config options online for the other plugins. Our plugins
> today, have a pre-install hook that is called on install and checks if the
> dependencies like other plugins, directories, perms etc are tested before
> allowing the install to proceed and we show the site admin the status of the
> pre-requisites.
>
> The autoinstall feature works well but is missing this ability. The
> autoinstall should check if a plugin has 'preinstallcheck' function, and
> allow that plugin to return more then a status or message. It should
> optionally be able to return a formated page - that can display status of
> any requirements. The autoinstall needs to have an fully automatic mode that
> is invoked if a plugin archive is uploaded or when geeklog is being
> installed - as it is now. The autoinstall is also invoked if you do a normal
> individual plugin install and  there should be an option of calling a
> preinstall function to display a splash page or into page before proceeding
> with the manual install. This function can also display the results of any
> preinstall checks.
>
> It also would be nice if there was a way to control the order plugins are
> installed.
>
> So in summary:
> - autopreinstall($mode)
> - if mode ==  'automatic' then just return a status and message.
> - if mode == 'manual' then return a status and formatted page
>
> Blaine
>
> _______________________________________________
> geeklog-devel mailing list
> geeklog-devel at lists.geeklog.net
> http://eight.pairlist.net/mailman/listinfo/geeklog-devel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://pairlist8.pair.net/pipermail/geeklog-devel/attachments/20091003/8ea20d4b/attachment.html>

From devel at portalparts.com  Sat Oct  3 12:03:49 2009
From: devel at portalparts.com (Blaine Lang)
Date: Sat, 03 Oct 2009 12:03:49 -0400
Subject: [geeklog-devel] Autoinstall plugins and dependencies
In-Reply-To: <8319e2d60910030838x7fe3c126vb06ae9077c62b835@mail.gmail.com>
References: <063B8B70CB9DA141B2FC1DB483561B9F112242@nex-pluto.nextide.ca>
	<8319e2d60910021828n589133e9s27126fe7eb33bd2@mail.gmail.com>
	<BLU0-SMTP2064843818965349B23379BCD10@phx.gbl>
	<8319e2d60910030838x7fe3c126vb06ae9077c62b835@mail.gmail.com>
Message-ID: <BLU0-SMTP7555C33320C90E35BF4E9EBCD10@phx.gbl>

Vincent Furia wrote:
> Is there a reason why:
>
> Our plugins today, have a pre-install hook that is called on install 
> and checks if the dependencies like other plugins, directories, perms 
> etc are tested before allowing the install to proceed and we show the 
> site admin the status of the pre-requisites.
>
> Isn't sufficient?
This is how we are able to do it now (using a standard 
admin/plugin/install.php script) but with out using the autointall 
feature in 1.6.
The autoinstall feature if available will not execute the 
admin/install.php and is missing the preinstall hook

There is a postinstall hook but the main autoinstall hook is meant to 
just return an array of config parms. Yes, we can add our prechecks in 
this function but our only option if the prechecks fail is to not return 
the install config array. Not very clean and not very informative.

Vincent Furia wrote:
> Would a dependency array work better.
>
> PluginA_Required = array('PluginB', 'PluginC');.
>
> With that information the autoinstaller could be made to be smart 
> enough to generate a dependency tree and install multiple plugins in 
> order. Other "preinstall" checks (file permisisons, etc) could be 
> accomplished in the install function.
This is closer as it would use a new preinstall hook. I still think we 
need 2 modes so that we either display an interactive page or return 
just a status that would allow the automated install to proceed on to 
the next plugin and report success/fail results at the end.

Plugin installation order is something that has come up in the past as a 
want/need. The autoinstall feature would need to read in all the to-be 
installed plugins install_parms array and then resort based on any 
dependencies.

Blaine




From Randy.Kolenko at nextide.ca  Sat Oct  3 14:46:44 2009
From: Randy.Kolenko at nextide.ca (Randy Kolenko)
Date: Sat, 3 Oct 2009 14:46:44 -0400
Subject: [geeklog-devel] Autoinstall plugins and dependencies
Message-ID: <063B8B70CB9DA141B2FC1DB483561B9F356E5F@nex-pluto.nextide.ca>

I thought about having the dependency idea as well as you noted.
That, in fact, could be part of the return array in the
plugin_autoinstall_pluginname function.
This way the autoinstaller can detect if those specific plugins are
installed or not and then bail out of the install with messages
signifying those plugins are not installed.

Perhaps that is a "simpler" way to do this?

-randy





-----Original Message-----
From: Vincent Furia [mailto:vfuria at gmail.com] 
Sent: Saturday, October 03, 2009 11:38 AM
To: Geeklog Development
Subject: Re: [geeklog-devel] Autoinstall plugins and dependencies


Is there a reason why:


Our plugins today, have a pre-install hook that is called on install and
checks if the dependencies like other plugins, directories, perms etc
are tested before allowing the install to proceed and we show the site
admin the status of the pre-requisites.


Isn't sufficient?

Would a dependency array work better.

PluginA_Required = array('PluginB', 'PluginC');.

With that information the autoinstaller could be made to be smart enough
to generate a dependency tree and install multiple plugins in order.
Other "preinstall" checks (file permisisons, etc) could be accomplished
in the install function.

-Vinny


On Fri, Oct 2, 2009 at 9:38 PM, Blaine Lang <devel at portalparts.com>
wrote:

Vincent Furia wrote:

Are there any plugins out there (yet) that require another plugin to be
installed? While its certainly something that should take into account
going forward, are we borrowing trouble addressing an issue that doesn't
exist yet?


Yes, several of the nexpro suite plugins have dependencies on other
plugins. Most of the plugins are dependand on the nexpro core plugin and
others need the nexlist plugin. The nexflow plugin uses the nexform
plugin for creating forms and routing them for review and approval. The
nexproject plugin needs nexfile and nexforum.,

Our new release will be using the core nexpro plugin to manage even more
common code and config options online for the other plugins. Our plugins
today, have a pre-install hook that is called on install and checks if
the dependencies like other plugins, directories, perms etc are tested
before allowing the install to proceed and we show the site admin the
status of the pre-requisites.

The autoinstall feature works well but is missing this ability. The
autoinstall should check if a plugin has 'preinstallcheck' function, and
allow that plugin to return more then a status or message. It should
optionally be able to return a formated page - that can display status
of any requirements. The autoinstall needs to have an fully automatic
mode that is invoked if a plugin archive is uploaded or when geeklog is
being installed - as it is now. The autoinstall is also invoked if you
do a normal individual plugin install and  there should be an option of
calling a preinstall function to display a splash page or into page
before proceeding with the manual install. This function can also
display the results of any preinstall checks.

It also would be nice if there was a way to control the order plugins
are installed.

So in summary:
- autopreinstall($mode)
- if mode ==  'automatic' then just return a status and message.
- if mode == 'manual' then return a status and formatted page

Blaine

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


From joe at ThrowingDice.com  Sat Oct  3 15:18:58 2009
From: joe at ThrowingDice.com (Joe Mucchiello)
Date: Sat, 03 Oct 2009 15:18:58 -0400
Subject: [geeklog-devel] Autoinstall plugins and dependencies
In-Reply-To: <063B8B70CB9DA141B2FC1DB483561B9F356E5F@nex-pluto.nextide.c a>
References: <063B8B70CB9DA141B2FC1DB483561B9F356E5F@nex-pluto.nextide.ca>
Message-ID: <0KQY00KWCDNSKTJ0@mta4.srv.hcvlny.cv.net>

At 02:46 PM 10/3/2009, Randy Kolenko wrote:
>I thought about having the dependency idea as well as you noted.
>That, in fact, could be part of the return array in the
>plugin_autoinstall_pluginname function.
>This way the autoinstaller can detect if those specific plugins are
>installed or not and then bail out of the install with messages
>signifying those plugins are not installed.
>
>Perhaps that is a "simpler" way to do this?

What if a plugin requires a specific version or higher of a plugin in 
order to work? As nice as the autoinstaller is for most installs, 
sometimes a plugin needs control before it can allow itself to be 
installed. Moving the preinstall check function out of 
admin/install.php and into autoinstall.php seems much simpler. The 
admin/install.php file can just include autoinstall.php if necessary 
for a manual install. Plugins can have other kinds of dependencies, 
such as directory structure requirements, that cannot be handled 
neatly and simply in the autoinstall array.


----
Joe Mucchiello
Throwing Dice Games
http://www.throwingdice.com 



From dirk at haun-online.de  Sat Oct  3 16:29:23 2009
From: dirk at haun-online.de (Dirk Haun)
Date: Sat, 3 Oct 2009 22:29:23 +0200
Subject: [geeklog-devel] Autoinstall plugins and dependencies
In-Reply-To: <8319e2d60910030838x7fe3c126vb06ae9077c62b835@mail.gmail.com>
References: <063B8B70CB9DA141B2FC1DB483561B9F112242@nex-pluto.nextide.ca> 
	<8319e2d60910021828n589133e9s27126fe7eb33bd2@mail.gmail.com> 
	<BLU0-SMTP2064843818965349B23379BCD10@phx.gbl>
	<8319e2d60910030838x7fe3c126vb06ae9077c62b835@mail.gmail.com>
Message-ID: <20091003202923.569235653@smtp.haun-online.de>

Vincent Furia wrote:

>With that information the autoinstaller could be made to be smart enough to
>generate a dependency tree and install multiple plugins in order. Other
>"preinstall" checks (file permisisons, etc) could be accomplished in the
>install function.

The "info" array that the autoinstall function returns can easily be
extended, keeping backward compatibility. So it could contain additional
information regarding a plugin's dependency on other plugins.

It's already documented[1] that plugin_autoinstall_xxx may be called
more than once, so the installer could collect information from all
plugins first before it even attempts to install the first one.

So it all comes down to writing a more "intelligent" plugin installer.
And what it should be doing if the requirements are not met. Especially
when all this happens in the install script ...

Does that summarize the discussion so far?

bye, Dirk

[1] <http://wiki.geeklog.net/index.php/Plugin_Autoinstall#plugin_autoinstall_>


-- 
http://www.geeklog.net/
http://geeklog.info/



From vfuria at gmail.com  Sat Oct  3 17:46:12 2009
From: vfuria at gmail.com (Vincent Furia)
Date: Sat, 3 Oct 2009 15:46:12 -0600
Subject: [geeklog-devel] Autoinstall plugins and dependencies
In-Reply-To: <20091003202923.569235653@smtp.haun-online.de>
References: <063B8B70CB9DA141B2FC1DB483561B9F112242@nex-pluto.nextide.ca> 
	<8319e2d60910021828n589133e9s27126fe7eb33bd2@mail.gmail.com> 
	<BLU0-SMTP2064843818965349B23379BCD10@phx.gbl>
	<8319e2d60910030838x7fe3c126vb06ae9077c62b835@mail.gmail.com> 
	<20091003202923.569235653@smtp.haun-online.de>
Message-ID: <8319e2d60910031446l3a8ea933y627f32fbd3762d95@mail.gmail.com>

On Sat, Oct 3, 2009 at 2:29 PM, Dirk Haun <dirk at haun-online.de> wrote:

> The "info" array that the autoinstall function returns can easily be
> extended, keeping backward compatibility. So it could contain additional
> information regarding a plugin's dependency on other plugins.
>
> It's already documented[1] that plugin_autoinstall_xxx may be called
> more than once, so the installer could collect information from all
> plugins first before it even attempts to install the first one.
>
> So it all comes down to writing a more "intelligent" plugin installer.
> And what it should be doing if the requirements are not met. Especially
> when all this happens in the install script ...
>
> Does that summarize the discussion so far?
>
> Yes that sums it up. If we want to do version checking for plugin
dependencies we'll have to figure out a way to compare version numbers
(difficult, since we don't specify a versioning system).

-Vinny
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://pairlist8.pair.net/pipermail/geeklog-devel/attachments/20091003/56633164/attachment.html>

From dirk at haun-online.de  Sat Oct  3 17:42:43 2009
From: dirk at haun-online.de (Dirk Haun)
Date: Sat, 3 Oct 2009 23:42:43 +0200
Subject: [geeklog-devel] Static Pages mishap on geeklog.net
Message-ID: <20091003214243.711837376@smtp.haun-online.de>

Earlier today, I accidentally uninstalled the Static Pages plugin on
geeklog.net. Yeah, "localhost" and "www.geeklog.net" are really hard to
tell apart. *cough*

Hooray for backups. And a boo for mysqldump for creating dumps with
"INSERT INTO staticpage VALUES (..." which causes, erm, interesting
results if the fields happen to be in a different order.

Anyway, content-wise everything is back to normal AFAICS. If anyone
thinks he should have access to the static pages plugin but doesn't,
drop me a note.

bye, Dirk


-- 
http://www.geeklog.net/
http://geeklog.info/



From dirk at haun-online.de  Sun Oct  4 14:09:51 2009
From: dirk at haun-online.de (Dirk Haun)
Date: Sun, 4 Oct 2009 20:09:51 +0200
Subject: [geeklog-devel] Suggested new SEC_ functions
Message-ID: <20091004180951.220321497@smtp.haun-online.de>

Can I get some feedback on
<http://project.geeklog.net/cgi-bin/hgwebdir.cgi/geeklog/rev/aaa5a1f1850e>
please?

During development, I'm running Geeklog with error_reporting(E_ALL)
usually. That can be a bit of a pain in some situations, though. For
example, when saving an object and the perm_anon checkbox is not set,
you get an error when trying to access $_POST['perm_anon'].

So I came up with a helper function that filters the 6 standard
permission entries (owner_id, group_id, perm_owner, and so on), ensures
that they are all set and also does the translation from the array of
checkboxes to numerical values.

So now you could do something like

    $PERM = SEC_filterPermissions($_POST);
    if ($PERM['perm_anon'] == 0) { ...

without PHP throwing a fit when E_ALL is on but the perm_anon checkbox
wasn't checked.

And since one of the next steps usually involves passing all those
permission values to SEC_hasAccess, I came up with SEC_hasAccess2 (for
lack of a better idea for a name - suggestions welcome) which will do
the same but accept that $PERM array instead of 6 separate values.

Does anyone else think those functions could be useful? I've checked
them in but haven't started using them yet.

bye, Dirk


-- 
http://www.geeklog.net/
http://geeklog.info/



From joe at ThrowingDice.com  Sun Oct  4 15:06:04 2009
From: joe at ThrowingDice.com (Joe Mucchiello)
Date: Sun, 04 Oct 2009 15:06:04 -0400
Subject: [geeklog-devel] Suggested new SEC_ functions
In-Reply-To: <20091004180951.220321497@smtp.haun-online.de>
References: <20091004180951.220321497@smtp.haun-online.de>
Message-ID: <0KR0006Z17PLOU60@mta2.srv.hcvlny.cv.net>

At 02:09 PM 10/4/2009, Dirk Haun wrote:
>And since one of the next steps usually involves passing all those
>permission values to SEC_hasAccess, I came up with SEC_hasAccess2 (for
>lack of a better idea for a name - suggestions welcome) which will do
>the same but accept that $PERM array instead of 6 separate values.

Just use SEC_hasAccess. If param1 is an array, assume it is the $PERM array:

function 
SEC_hasAccess($owner_id,$group_id=0,$perm_owner=0,$perm_group=0,$perm_members=0,$perm_anon=0)
{
     global $_USER;

     if (is_array($owner_id)) {
         $group_id = $owner_id['group_id'];
         $perm_owner = $owner_id['perm_owner'];
         $perm_group = $owner_id['perm_group'];
         $perm_members = $owner_id['perm_members'];
         $perm_anon = $owner_id['perm_anon'];
         $owner_id = $owner_id['owner_id'];
     }
// etc.
}


----
Joe Mucchiello
Throwing Dice Games
http://www.throwingdice.com 



From Randy.Kolenko at nextide.ca  Mon Oct  5 09:06:05 2009
From: Randy.Kolenko at nextide.ca (Randy Kolenko)
Date: Mon, 5 Oct 2009 09:06:05 -0400
Subject: [geeklog-devel] Autoinstall plugins and dependencies
Message-ID: <063B8B70CB9DA141B2FC1DB483561B9F112243@nex-pluto.nextide.ca>



> Yes that sums it up. If we want to do version checking for plugin
dependencies 
> we'll have to figure out a way to compare version numbers (difficult,
since we 
> don't specify a versioning system). 


So, extending your initial idea of:

PluginA_Required = array('PluginB', 'PluginC');

This could simply be an array of arrays:

PluginA_Required = array(
	array('PluginB','1.1.0'),
	array('PluginC','2.1.1')
);

And the installer would check for the version number tacked in the
plugin table.
The plugin_required array could be part of the $info return array in the
autoinstall function.
If a plugin is not installed and is in the required array AND it exists
in the install path, the installer could go ahead and install the
dependant plugins.  

Likewise, it would be a good idea for the autoinstaller to be able to
test out file writing permissions for those plugins that require dumping
data to the file system.  That could easily be another return in the
$info array.

However we still need the autoinstall to be able to return error codes
and/or write them to the error.log file depending on how/where the
installation is happening.

-randy


From vfuria at gmail.com  Mon Oct  5 12:08:05 2009
From: vfuria at gmail.com (Vincent Furia)
Date: Mon, 5 Oct 2009 10:08:05 -0600
Subject: [geeklog-devel] Autoinstall plugins and dependencies
In-Reply-To: <063B8B70CB9DA141B2FC1DB483561B9F112243@nex-pluto.nextide.ca>
References: <063B8B70CB9DA141B2FC1DB483561B9F112243@nex-pluto.nextide.ca>
Message-ID: <8319e2d60910050908j62edf500gbe6a2beb015c32a2@mail.gmail.com>

An associative array would probably work better:

PluginA_Required = array(
       'PluginB' => '1.1.0',
       'PluginC' => '2.1.1'
);

On Mon, Oct 5, 2009 at 7:06 AM, Randy Kolenko <Randy.Kolenko at nextide.ca>wrote:

>
>
> > Yes that sums it up. If we want to do version checking for plugin
> dependencies
> > we'll have to figure out a way to compare version numbers (difficult,
> since we
> > don't specify a versioning system).
>
>
> So, extending your initial idea of:
>
> PluginA_Required = array('PluginB', 'PluginC');
>
> This could simply be an array of arrays:
>
> PluginA_Required = array(
>        array('PluginB','1.1.0'),
>        array('PluginC','2.1.1')
> );
>
> And the installer would check for the version number tacked in the
> plugin table.
> The plugin_required array could be part of the $info return array in the
> autoinstall function.
> If a plugin is not installed and is in the required array AND it exists
> in the install path, the installer could go ahead and install the
> dependant plugins.
>
> Likewise, it would be a good idea for the autoinstaller to be able to
> test out file writing permissions for those plugins that require dumping
> data to the file system.  That could easily be another return in the
> $info array.
>
> However we still need the autoinstall to be able to return error codes
> and/or write them to the error.log file depending on how/where the
> installation is happening.
>
> -randy
> _______________________________________________
> geeklog-devel mailing list
> geeklog-devel at lists.geeklog.net
> http://eight.pairlist.net/mailman/listinfo/geeklog-devel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://pairlist8.pair.net/pipermail/geeklog-devel/attachments/20091005/24efe4fc/attachment.html>

From devel at portalparts.com  Mon Oct  5 12:30:02 2009
From: devel at portalparts.com (Blaine Lang)
Date: Mon, 05 Oct 2009 12:30:02 -0400
Subject: [geeklog-devel] plugin_autoinstall - two more issues
Message-ID: <BLU0-SMTP8779E9D844AED6AF1D7DC1BCCF0@phx.gbl>

Two new issues have surfaced while working with the autoinstall - 
admin/plugins.php  function plugin_do_autoinstall().

1) If the autoinstall fails, then the PLG_uninstall will always fail.
The plugin has not yet been installed and the plugins autouninstall 
function is then not found. The code as far as I can see does not do an 
include the plugins functions.inc

To duplicate: uninstall the Polls plugin and then manually create a 
groups record for 'Polls Admin'
The autoinstall will fail and not be able to recover.

2) If a plugin needs to create multiple groups, they will be created 
fine but the plugin_doautoinstall only will create the group_assignments 
records for the first created group. Is there a reason the code to 
create group_assignment records does not loop through the $groups array?

Is the plan for the autoinstall feature to remove the need for the 
admin/plugins/{pi_name}/install.php file entirely ?
I was close to removing until these issues appeared.

Blaine





From cordiste at free.fr  Mon Oct  5 13:35:52 2009
From: cordiste at free.fr (cordiste)
Date: Mon, 5 Oct 2009 19:35:52 +0200
Subject: [geeklog-devel] plugin_autoinstall - two more issues
In-Reply-To: <BLU0-SMTP8779E9D844AED6AF1D7DC1BCCF0@phx.gbl>
References: <BLU0-SMTP8779E9D844AED6AF1D7DC1BCCF0@phx.gbl>
Message-ID: <364575ed0910051035j51cc70d2t4b801a068e1abaf@mail.gmail.com>

Hello,

Could it be related?
http://www.geeklog.net/forum/viewtopic.php?showtopic=88552

::Ben

2009/10/5 Blaine Lang <devel at portalparts.com>

> Two new issues have surfaced while working with the autoinstall -
> admin/plugins.php  function plugin_do_autoinstall().
>
> 1) If the autoinstall fails, then the PLG_uninstall will always fail.
> The plugin has not yet been installed and the plugins autouninstall
> function is then not found. The code as far as I can see does not do an
> include the plugins functions.inc
>
> To duplicate: uninstall the Polls plugin and then manually create a groups
> record for 'Polls Admin'
> The autoinstall will fail and not be able to recover.
>
> 2) If a plugin needs to create multiple groups, they will be created fine
> but the plugin_doautoinstall only will create the group_assignments records
> for the first created group. Is there a reason the code to create
> group_assignment records does not loop through the $groups array?
>
> Is the plan for the autoinstall feature to remove the need for the
> admin/plugins/{pi_name}/install.php file entirely ?
> I was close to removing until these issues appeared.
>
> Blaine
>
>
>
> _______________________________________________
> geeklog-devel mailing list
> geeklog-devel at lists.geeklog.net
> http://eight.pairlist.net/mailman/listinfo/geeklog-devel
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://pairlist8.pair.net/pipermail/geeklog-devel/attachments/20091005/d9c128c0/attachment.html>

From cordiste at free.fr  Mon Oct  5 13:40:15 2009
From: cordiste at free.fr (cordiste)
Date: Mon, 5 Oct 2009 19:40:15 +0200
Subject: [geeklog-devel] Example of PLG_itemDisplay()
In-Reply-To: <BLU0-SMTP284D3E15A68EAE0EE603D8BCD40@phx.gbl>
References: <BLU0-SMTP9784838BAC5736DE0B463CBCD50@phx.gbl>
	<364575ed0909291158x1a313462ib270e7f45a8451c4@mail.gmail.com>
	<BLU0-SMTP284D3E15A68EAE0EE603D8BCD40@phx.gbl>
Message-ID: <364575ed0910051040hd4eabe1rdcf2c279b90afdc9@mail.gmail.com>

Thanks Blaine for the proposition but as I see my futur plugin more like a
chat room than a box, I will need to give a new name to this plugin to avoid
confusion.

::Ben

2009/9/30 Blaine Lang <devel at portalparts.com>

> Hi Ben,
>
> I am presently working on the Nexpro plugins that we offer from Nextide. We
> have been working on a new release that brings them up to date.
> Your more then welcome to take over Chatterblock as it's not a plugin that
> I have used personally for a few years.
>
> Regards,
> Blaine
>
> cordiste wrote:
>
>> 2009/9/29 Blaine Lang <devel at portalparts.com <mailto:
>> devel at portalparts.com>>
>>
>>
>>    I was working on a plugin update
>>
>>  Blaine,
>>
>> Could you tell me witch one of you good plugins you gonna release :))
>> because I would like to try implement a new chatter box.
>>
>> ::Ben
>> ------------------------------------------------------------------------
>>
>> _______________________________________________
>> 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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://pairlist8.pair.net/pipermail/geeklog-devel/attachments/20091005/95773b0e/attachment.html>

From Randy.Kolenko at nextide.ca  Mon Oct  5 14:00:07 2009
From: Randy.Kolenko at nextide.ca (Randy Kolenko)
Date: Mon, 5 Oct 2009 14:00:07 -0400
Subject: [geeklog-devel] plugin_autoinstall - two more issues
Message-ID: <063B8B70CB9DA141B2FC1DB483561B9F112244@nex-pluto.nextide.ca>

Ben, 

That is the same issue.
The solution is to alter admin/plugins.php at line 1035-1048 to look
like this:

if (count($groups) > 1) {
  if ($verbose) {
    COM_errorLog("Attempting to give all users in the Root group access
to the '$plugin' Admin group", 1);
  }

  foreach($groups as $key=>$value){
    DB_query("INSERT INTO {$_TABLES['group_assignments']} VALUES "
                 . "($value, NULL, 1)");
    if (DB_error()) {
      COM_errorLog('Error adding plugin admin group to Root group', 1);
      PLG_uninstall($plugin);
      return false;
    }
  }
}

This should be a fix made to the core.  If not, then we have to document
in the wiki that the post plugin install routine needs to add in the
group_assignments for root.  Otherwise those groups are totally
unusable.

-randy


-----Original Message-----
From: cordiste [mailto:cordiste at free.fr] 
Sent: Monday, October 05, 2009 1:36 PM
To: Geeklog Development
Subject: Re: [geeklog-devel] plugin_autoinstall - two more issues


Hello,

Could it be related?
http://www.geeklog.net/forum/viewtopic.php?showtopic=88552

::Ben


2009/10/5 Blaine Lang <devel at portalparts.com>

Two new issues have surfaced while working with the autoinstall -
admin/plugins.php  function plugin_do_autoinstall().

1) If the autoinstall fails, then the PLG_uninstall will always fail.
The plugin has not yet been installed and the plugins autouninstall
function is then not found. The code as far as I can see does not do an
include the plugins functions.inc

To duplicate: uninstall the Polls plugin and then manually create a
groups record for 'Polls Admin'
The autoinstall will fail and not be able to recover.

2) If a plugin needs to create multiple groups, they will be created
fine but the plugin_doautoinstall only will create the group_assignments
records for the first created group. Is there a reason the code to
create group_assignment records does not loop through the $groups array?

Is the plan for the autoinstall feature to remove the need for the
admin/plugins/{pi_name}/install.php file entirely ?
I was close to removing until these issues appeared.

Blaine



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


From dirk at haun-online.de  Mon Oct  5 14:28:18 2009
From: dirk at haun-online.de (Dirk Haun)
Date: Mon, 5 Oct 2009 20:28:18 +0200
Subject: [geeklog-devel] plugin_autoinstall - two more issues
In-Reply-To: <BLU0-SMTP8779E9D844AED6AF1D7DC1BCCF0@phx.gbl>
References: <BLU0-SMTP8779E9D844AED6AF1D7DC1BCCF0@phx.gbl>
Message-ID: <20091005182818.626422530@smtp.haun-online.de>

Blaine Lang wrote:

>2) If a plugin needs to create multiple groups, they will be created 
>fine but the plugin_doautoinstall only will create the group_assignments 
>records for the first created group. Is there a reason the code to 
>create group_assignment records does not loop through the $groups array?

That sounds like a bug.


>Is the plan for the autoinstall feature to remove the need for the 
>admin/plugins/{pi_name}/install.php file entirely ?

Yes.

bye, Dirk


-- 
http://www.geeklog.net/
http://geeklog.info/



From joe at ThrowingDice.com  Mon Oct  5 20:46:52 2009
From: joe at ThrowingDice.com (Joe Mucchiello)
Date: Mon, 05 Oct 2009 20:46:52 -0400
Subject: [geeklog-devel] plugin_autoinstall - two more issues
In-Reply-To: <BLU0-SMTP8779E9D844AED6AF1D7DC1BCCF0@phx.gbl>
References: <BLU0-SMTP8779E9D844AED6AF1D7DC1BCCF0@phx.gbl>
Message-ID: <0KR200HDOI31GU60@mta2.srv.hcvlny.cv.net>

At 12:30 PM 10/5/2009, Blaine Lang wrote:
>2) If a plugin needs to create multiple groups, they will be created 
>fine but the plugin_doautoinstall only will create the 
>group_assignments records for the first created group. Is there a 
>reason the code to create group_assignment records does not loop 
>through the $groups array?

In case it helps, I rewrote this code into an entirely separate 
library for glFusion. Whether or not you want to look at the code I 
wrote, the approach I took could help. I made each part of the array 
returned by plugin_autoinstall_foo it's own function. If the function 
was successful, it returned a string containing a SQL statement that 
would undo whatever that function just did. This value is assigned 
into a list of strings. If at any time there was an error installing 
the plugin, you simply run the list backwards to repair the database. 
Another part of the approach was to flatten the array and include a 
type field so the install library is extensible: if 
(function_exists('installer_'.$item['type']) { //call that func} Data 
loading statements are included in the array in case they do things 
that need to be reversed. Yes, that's more work for the plugin writer 
but the added safety during install outweighs that to me.

http://glfusion.svn.sourceforge.net/viewvc/glfusion/glfusion/releases/release-1.1.6/private/system/lib-install.php?view=markup

And an example of the array. Note that whether a group is added to 
the admin group is done with 'addroot'=>true on the group line. Also 
notice that groups can be added to other groups in this setup.
http://glfusion.svn.sourceforge.net/viewvc/glfusion/pm/releases/release-1.1.0/autoinstall.php?view=markup 
Lines 45-60, lines 69-85 become the boilerplate code for running the install.




----
Joe Mucchiello
Throwing Dice Games
http://www.throwingdice.com 



From Randy.Kolenko at nextide.ca  Tue Oct  6 09:26:23 2009
From: Randy.Kolenko at nextide.ca (Randy Kolenko)
Date: Tue, 6 Oct 2009 09:26:23 -0400
Subject: [geeklog-devel] plugin_autoinstall - two more issues
Message-ID: <063B8B70CB9DA141B2FC1DB483561B9F356E68@nex-pluto.nextide.ca>



> returned by plugin_autoinstall_foo it's own function. If the function 
> was successful, it returned a string containing a SQL statement that 
> would undo whatever that function just did. This value is assigned 


So, how does returning 1 line of sql help remove data structures created
in a dependent plugin's table structure -- especially when the table
structure is relational?  

I would have thought a simpler approach would have been to include the
failed installed plugin's functions.inc file and simply call the
autouninstall function to cleanly uninstall it.
You have to write the uninstall function anyways, so might as well use
it properly.. The original bug noted by Blaine is that the PLG_uninstall
will never work during a failure in the autoinstall method due to the
functions.inc file not being included for the failed plugin.

-randy


From joe at ThrowingDice.com  Tue Oct  6 09:54:38 2009
From: joe at ThrowingDice.com (Joe Mucchiello)
Date: Tue, 06 Oct 2009 09:54:38 -0400
Subject: [geeklog-devel] plugin_autoinstall - two more issues
In-Reply-To: <063B8B70CB9DA141B2FC1DB483561B9F356E68@nex-pluto.nextide.c a>
References: <063B8B70CB9DA141B2FC1DB483561B9F356E68@nex-pluto.nextide.ca>
Message-ID: <0KR300HNQIK1BE11@mta1.srv.hcvlny.cv.net>

At 09:26 AM 10/6/2009, Randy Kolenko wrote:


> > returned by plugin_autoinstall_foo it's own function. If the function
> > was successful, it returned a string containing a SQL statement that
> > would undo whatever that function just did. This value is assigned
>
>So, how does returning 1 line of sql help remove data structures created
>in a dependent plugin's table structure -- especially when the table
>structure is relational?
>
>I would have thought a simpler approach would have been to include the
>failed installed plugin's functions.inc file and simply call the
>autouninstall function to cleanly uninstall it.
>You have to write the uninstall function anyways, so might as well use
>it properly.. The original bug noted by Blaine is that the PLG_uninstall
>will never work during a failure in the autoinstall method due to the
>functions.inc file not being included for the failed plugin.

You missed the point that each line of the autoinstall structure is a 
function call and that those functions return the sql. So for every 
group created, every feature created, every group to feature mapping, 
every table created, every group added to another group, etc. a 
separate SQL statement is returned. The INSTALLER_install_table 
function returns a DROP TABLE $tablename string. The 
INSTALLER_install_group function returns a DELETE FROM groups.... 
string. The mapping lines return the string to clean the 
group_assignments table.

The reason not to call the uninstall function is to simplify the 
uninstalll code. Usually a failed install fails in the middle. With 
the reversal strings you only undo what actually was done. Uninstall 
functions might attempt to do things to files on the filesystem or 
make updates to other tables. When you only undo the minimum there is 
less risk of collateral damage. And the uninstall function only has 
to be written to uninstall a proper installation. It doesn't need to 
worry about partial installs.

Oh, and if you really wanted to just use the uninstall, you should 
move the uninstall function to the autoinstall.php file and include 
that during uninstall not the other way around. Again, some 
functions.inc files make database calls outside of all functions. If 
the plugin failed to install, this will most like cause errors. 
Including the functions.inc is therefore potentially dangerous. The 
autoinstall.php is designed to be called while the plugin does not 
exist. In addition, normal operation of the site would no longer have 
to parse the uninstall function with every web hit. During 99.99% of 
the time that is dead code.

----
Joe Mucchiello
Throwing Dice Games
http://www.throwingdice.com 



From Randy.Kolenko at nextide.ca  Tue Oct  6 10:11:20 2009
From: Randy.Kolenko at nextide.ca (Randy Kolenko)
Date: Tue, 6 Oct 2009 10:11:20 -0400
Subject: [geeklog-devel] plugin_autoinstall - two more issues
Message-ID: <063B8B70CB9DA141B2FC1DB483561B9F112245@nex-pluto.nextide.ca>



> You missed the point that each line of the autoinstall structure is a 
> function call and that those functions return the sql. So for every 
> group created, every feature created, every group to feature mapping, 
> every table created, every group added to another group, etc. a 
> separate SQL statement is returned. The INSTALLER_install_table 
> function returns a DROP TABLE $tablename string. The 
> INSTALLER_install_group function returns a DELETE FROM groups.... 
> string. The mapping lines return the string to clean the 
> group_assignments table.


Oh, I didn't miss that point... I'm just curious as to how returning 1
line of sql for each step will alleviate deleting data a plugin dumps
into another plugin's tables?  Forget groups, features etc.. I'm talking
about relational data that can take numerous (read tens or hundreds) of
lines of sql code to create related data.


> 
> The reason not to call the uninstall function is to simplify the 
> uninstalll code. Usually a failed install fails in the middle. 

Define "middle".  It could fail at the last step, or the first step --
after numerous database queries, file system manouvers etc. have been
done.


> the reversal strings you only undo what actually was done. Uninstall 
> functions might attempt to do things to files on the filesystem or 
> make updates to other tables. When you only undo the minimum there is 
> less risk of collateral damage. And the uninstall function only has 
> to be written to uninstall a proper installation. It doesn't need to 
> worry about partial installs.


So, why have a plugin uninstall then? It too would undo any table
changes etc.  Full or partial install seems to be a moot point as you're
trying to remove whatever junk you've insertted into the database.  If
you created folders, removing those should not pose any risk as you just
created them.  If you try to remove a folder that doesn't exist, well,
it can't be removed anyways.


> 
> Oh, and if you really wanted to just use the uninstall, you should 
> move the uninstall function to the autoinstall.php file and include 
> that during uninstall not the other way around. Again, some 
> functions.inc files make database calls outside of all functions. If 
> the plugin failed to install, this will most like cause errors. 
> Including the functions.inc is therefore potentially dangerous. The 
> autoinstall.php is designed to be called while the plugin does not 
> exist. In addition, normal operation of the site would no longer have 
> to parse the uninstall function with every web hit. During 99.99% of 
> the time that is dead code.
> 


Well, perhaps its just me, but I think that functions.inc should not
contain any DB calls outside of a function.  That just plainly does not
scale.  Config class stuff aside (as that can be removed to become a
config.php file in highly scalable environments), making db calls,
setting up arrays etc on each page view is a waste of resources
especially if you're not even in the plugin in question.  Just my
$0.0000002 worth.  I've lived it and had to fix that kind of "coding".
Fine for 10 people.  Not so fine for 500 concurrent people.

Perhaps the most straightforward approach would be to pull the
autouninstall out to its own uninstall_defaults.php file and include
that from functions.inc and the auto-install routine.  Now THAT is much
safer all around.


-randy




From devel at portalparts.com  Tue Oct  6 15:31:34 2009
From: devel at portalparts.com (Blaine Lang)
Date: Tue, 06 Oct 2009 15:31:34 -0400
Subject: [geeklog-devel] plugin_autoinstall - two more issues
In-Reply-To: <063B8B70CB9DA141B2FC1DB483561B9F112245@nex-pluto.nextide.ca>
References: <063B8B70CB9DA141B2FC1DB483561B9F112245@nex-pluto.nextide.ca>
Message-ID: <BLU0-SMTP1391424CD8F6AD38D7F6E9BCCE0@phx.gbl>

Randy Kolenko wrote:
> Perhaps the most straightforward approach would be to pull the
> autouninstall out to its own uninstall_defaults.php file and include
> that from functions.inc and the auto-install routine.  Now THAT is much
> safer all around.
I have to agree and this solves the first issue reported.
1) Create an autouninstall.php and move the function from functions.inc 
into this new file
2) Add a require_once of autouninstall.php in functions.inc - now it's 
aware of the function
3) Add a require_once of autouninstall.php in autoinstall.php - now it's 
aware of the function and PLG_uninstall() will work.

No core code changes needed.





From Randy.Kolenko at nextide.ca  Tue Oct  6 16:27:53 2009
From: Randy.Kolenko at nextide.ca (Randy Kolenko)
Date: Tue, 6 Oct 2009 16:27:53 -0400
Subject: [geeklog-devel] Autoinstall plugins and dependencies
Message-ID: <063B8B70CB9DA141B2FC1DB483561B9F356E6F@nex-pluto.nextide.ca>

So, is there some agreement here as to the implementation of a
plugin_check_prerequisites_pluginname()  function?

OR are we going to offload those checks to the auto-installer routine
via the associative array noted by Vinny?


-randy



> -----Original Message-----
> From: Randy Kolenko 
> Sent: Monday, October 05, 2009 9:06 AM
> To: Geeklog Development
> Subject: Re: [geeklog-devel] Autoinstall plugins and dependencies
> 
> 
> 
> 
> > Yes that sums it up. If we want to do version checking for plugin
> dependencies 
> > we'll have to figure out a way to compare version numbers 
> (difficult,
> since we 
> > don't specify a versioning system).
> 
> 
> So, extending your initial idea of:
> 
> PluginA_Required = array('PluginB', 'PluginC');
> 
> This could simply be an array of arrays:
> 
> PluginA_Required = array(
> 	array('PluginB','1.1.0'),
> 	array('PluginC','2.1.1')
> );
> 
> And the installer would check for the version number tacked in the
> plugin table.
> The plugin_required array could be part of the $info return 
> array in the
> autoinstall function.
> If a plugin is not installed and is in the required array AND 
> it exists
> in the install path, the installer could go ahead and install the
> dependant plugins.  
> 
> Likewise, it would be a good idea for the autoinstaller to be able to
> test out file writing permissions for those plugins that 
> require dumping
> data to the file system.  That could easily be another return in the
> $info array.
> 
> However we still need the autoinstall to be able to return error codes
> and/or write them to the error.log file depending on how/where the
> installation is happening.
> 
> -randy
> _______________________________________________
> geeklog-devel mailing list
> geeklog-devel at lists.geeklog.net
> http://eight.pairlist.net/mailman/listinfo/geeklog-devel
> 


From joe at ThrowingDice.com  Wed Oct  7 02:00:03 2009
From: joe at ThrowingDice.com (Joe Mucchiello)
Date: Wed, 07 Oct 2009 02:00:03 -0400
Subject: [geeklog-devel] plugin_autoinstall - two more issues
In-Reply-To: <063B8B70CB9DA141B2FC1DB483561B9F112245@nex-pluto.nextide.c a>
References: <063B8B70CB9DA141B2FC1DB483561B9F112245@nex-pluto.nextide.ca>
Message-ID: <0KR400CF8R94WW90@mta3.srv.hcvlny.cv.net>

At 10:11 AM 10/6/2009, Randy Kolenko wrote:
>Oh, I didn't miss that point... I'm just curious as to how returning 1
>line of sql for each step will alleviate deleting data a plugin dumps
>into another plugin's tables?

Plugins should not modify tables they don't own. I don't know of any 
plugins that do. You want to add info to a story or a forum post you 
create a table with a sid or (whatever the forum primary key is) as a 
foreign key and you maintain that table outside the main table.

>Forget groups, features etc.. I'm talking
>about relational data that can take numerous (read tens or hundreds) of
>lines of sql code to create related data.

All that related data should be in your plugin's tables that get 
wiped out in a single SQL call: DROP TABLE foo.

>Define "middle".  It could fail at the last step, or the first step --
>after numerous database queries, file system manouvers etc. have been
>done.

All of those places are the "middle". Middle is anywhere that is not 
before or after. What are you getting at?

>Well, perhaps its just me, but I think that functions.inc should not
>contain any DB calls outside of a function.

How about Bad Behavior? GUS? There are plenty of reasons for a DB 
call outside of a function on every single page load.

>That just plainly does not
>scale.

Who said it did? Fact is it happens. And if you really care about 
slimming down the page load profile then you should also be appalled 
that there are plugin_search functions and plugin_stats functions 
defined and wasting memory on every page hit whether or not the page 
is the search page or the stats page. Shouldn't functions.inc be 
minimal and only include stuff needed for the current page? It 
wouldn't be hard to do. But that's a tangent. I was saying the 
uninstall function should only exist when you are on the plugins page 
and could possibly press "uninstall".

>Perhaps the most straightforward approach would be to pull the
>autouninstall out to its own uninstall_defaults.php file and include
>that from functions.inc and the auto-install routine.  Now THAT is much
>safer all around.

Now you want to add another file that is always included from the 
functions.inc page rather than putting it in existing autoinstall 
file. Does this scale?

Wait, why am I talking about scale? What are we talking about? Oh, 
yeah, I wrote a different autoinstaller for plugins that's been in 
use in glFusion for a while. Use it. Don't use it. Look at it for 
ideas. Ignore it. Whatever. I have nothing else to really say about 
it. The code speaks for itself and it's GPL2.


----
Joe Mucchiello
Throwing Dice Games
http://www.throwingdice.com 



From dirk at haun-online.de  Wed Oct  7 02:02:24 2009
From: dirk at haun-online.de (Dirk Haun)
Date: Wed, 7 Oct 2009 08:02:24 +0200
Subject: [geeklog-devel] plugin_autoinstall - two more issues
In-Reply-To: <063B8B70CB9DA141B2FC1DB483561B9F112244@nex-pluto.nextide.ca>
References: <063B8B70CB9DA141B2FC1DB483561B9F112244@nex-pluto.nextide.ca>
Message-ID: <20091007060224.1983093660@smtp.haun-online.de>

Randy Kolenko wrote:

>The solution is to alter admin/plugins.php at line 1035-1048 to look
>like this:

Can someone fix this then or submit a patch, please? Probably exists in
both admin/plugins.php and the install script.

Which, btw, is something else we may want to address: The code
duplication in those two scripts. Plugin install requires a working
Geeklog install, so that should be doable.

bye, Dirk


-- 
http://www.geeklog.net/
http://geeklog.info/



From Randy.Kolenko at nextide.ca  Wed Oct  7 07:44:13 2009
From: Randy.Kolenko at nextide.ca (Randy Kolenko)
Date: Wed, 7 Oct 2009 07:44:13 -0400
Subject: [geeklog-devel] plugin_autoinstall - two more issues
Message-ID: <063B8B70CB9DA141B2FC1DB483561B9F112247@nex-pluto.nextide.ca>



> 
> Plugins should not modify tables they don't own. I don't know of any 
> plugins that do. You want to add info to a story or a forum post you 
> create a table with a sid or (whatever the forum primary key is) as a 
> foreign key and you maintain that table outside the main table.

Really?  How could the forum/stories/pluginx possibly use that data then
if the newly insertted data is in a separate table?  I'm not trying to
sound snarky here -- just really trying to understand the approach.

 

> All of those places are the "middle". Middle is anywhere that is not 
> before or after. What are you getting at?
> 

Trying to clarify where our understanding of what we're talking about
meets or separates.  Trying to understand where you're coming from and
trying to convey where I'm coming from.



> Now you want to add another file that is always included from the 
> functions.inc page rather than putting it in existing autoinstall 
> file. Does this scale?


May not scale for Geeklog 1.6 -- but if its in its own file, 1.6.x could
include the uninstall ONLY when on the plugins page when the uninstall
is clicked.  That scales.



> 
> Wait, why am I talking about scale? What are we talking about? Oh, 
> yeah, I wrote a different autoinstaller for plugins that's been in 
> use in glFusion for a while. Use it. Don't use it. Look at it for 
> ideas. Ignore it. Whatever. I have nothing else to really say about 
> it. The code speaks for itself and it's GPL2.
> 

That's great Joe.  I looked at it and I simply asked a question as to if
we used that approach, how can we manage external data.  That is all.
It was a valid question that I don't have an answer to yet.  Perhaps its
my lack of understanding on your approach so I asked for clarification.



-randy


From Randy.Kolenko at nextide.ca  Wed Oct  7 10:19:20 2009
From: Randy.Kolenko at nextide.ca (Randy Kolenko)
Date: Wed, 7 Oct 2009 10:19:20 -0400
Subject: [geeklog-devel] plugin_autoinstall - two more issues
Message-ID: <063B8B70CB9DA141B2FC1DB483561B9F356E72@nex-pluto.nextide.ca>

The code should actuall start with:
if (count($groups) > 0) {




> -----Original Message-----
> From: Dirk Haun [mailto:dirk at haun-online.de] 
> Sent: Wednesday, October 07, 2009 2:02 AM
> To: geeklog-devel
> Subject: Re: [geeklog-devel] plugin_autoinstall - two more issues
> 
> 
> Randy Kolenko wrote:
> 
> >The solution is to alter admin/plugins.php at line 1035-1048 to look 
> >like this:
> 
> Can someone fix this then or submit a patch, please? Probably 
> exists in both admin/plugins.php and the install script.
> 
> Which, btw, is something else we may want to address: The 
> code duplication in those two scripts. Plugin install 
> requires a working Geeklog install, so that should be doable.
> 
> bye, Dirk
> 
> 
> -- 
> http://www.geeklog.net/
> http://geeklog.info/
> 
> _______________________________________________
> geeklog-devel mailing list
> geeklog-devel at lists.geeklog.net 
> http://eight.pairlist.net/mailman/listinfo/geeklog-devel
> 


From joe at ThrowingDice.com  Wed Oct  7 10:42:22 2009
From: joe at ThrowingDice.com (Joe Mucchiello)
Date: Wed, 07 Oct 2009 10:42:22 -0400
Subject: [geeklog-devel] plugin_autoinstall - two more issues
In-Reply-To: <063B8B70CB9DA141B2FC1DB483561B9F112247@nex-pluto.nextide.c a>
References: <063B8B70CB9DA141B2FC1DB483561B9F112247@nex-pluto.nextide.ca>
Message-ID: <0KR500BENFFO5NH0@mta4.srv.hcvlny.cv.net>

At 07:44 AM 10/7/2009, Randy Kolenko wrote:


> >
> > Plugins should not modify tables they don't own. I don't know of any
> > plugins that do. You want to add info to a story or a forum post you
> > create a table with a sid or (whatever the forum primary key is) as a
> > foreign key and you maintain that table outside the main table.
>
>Really?  How could the forum/stories/pluginx possibly use that data then
>if the newly insertted data is in a separate table?  I'm not trying to
>sound snarky here -- just really trying to understand the approach.

I'm not getting this. If the data (from plugin X) was not put there 
by the native plugin (forum, say) then how would the native plugin 
know how to use that data.

Perhaps the disconnect is "modify". I mean adding fields to some 
other plugin's tables. How would the plugin owning the modified table 
be aware of how to use that data?

> > Now you want to add another file that is always included from the
> > functions.inc page rather than putting it in existing autoinstall
> > file. Does this scale?
>
>May not scale for Geeklog 1.6 -- but if its in its own file, 1.6.x could
>include the uninstall ONLY when on the plugins page when the uninstall
>is clicked.  That scales.

If you really wanted scale, you'd do something about 3000 line 
functions.inc files containing 70-80% unneeded code which take up 
memory on every page load. Search functions would only be loaded when 
search was active. Stats, profile editing, user create/destroy, 
comment code, config change, etc. I wouldn't mandate file name 
conventions for this. Instead have a PLG_LoadFeature($feature, 
$plugin = '') function that calls the plugin before attempting to 
access that feature. If the plugin supports the feature (and dynamic 
loading of the feature) it would load the functions needed at that 
time. I admit I don't know if this really would improve anything. I 
plan to test it out when I get the chance. It sounds good on paper though.

>That's great Joe.  I looked at it and I simply asked a question as to if
>we used that approach, how can we manage external data.  That is all.
>It was a valid question that I don't have an answer to yet.  Perhaps its
>my lack of understanding on your approach so I asked for clarification.

You don't. The plugin author does by making another "type". When 
autoinstall.php is loaded, it could contain a function such as 
"INSTALLER_install_special_action". In the install array, the plugin 
could have an entry of type "special_action". When the installer 
reached that line of the array, it would look for a function called 
INSTALLER_install_special_action and call it. The uninstaller (did I 
mention that the library's uninstall uses the same array as the 
install function uses to do the uninstall?) would attempt to call 
INSTALLER_uninstall_special_action. Thus a plugin with special 
requirements could supply the installer (and uninstaller) with 
special functions to handle those requirements. The cool thing about 
this setup is the INSTALLER function is passed the current array 
being acted on as well as an array of "variables". These variables 
are generated by the "group", "feature", etc


----
Joe Mucchiello
Throwing Dice Games
http://www.throwingdice.com 



From Randy.Kolenko at nextide.ca  Wed Oct  7 10:53:22 2009
From: Randy.Kolenko at nextide.ca (Randy Kolenko)
Date: Wed, 7 Oct 2009 10:53:22 -0400
Subject: [geeklog-devel] plugin_autoinstall - two more issues
Message-ID: <063B8B70CB9DA141B2FC1DB483561B9F356E73@nex-pluto.nextide.ca>



> Instead have a PLG_LoadFeature($feature, 
> $plugin = '') function that calls the plugin before attempting to 
> access that feature. If the plugin supports the feature (and dynamic 
> loading of the feature) it would load the functions needed at that 
> time. I admit I don't know if this really would improve anything. I 
> plan to test it out when I get the chance. It sounds good on 
> paper though.
> 


That is a good idea -- which is all predecated on refactoring the way
plugins are written.
Separation of logical functional units of code into their own
dynamically linkable libraries would cut the parsed codebase down
considerably.

-randy


From joe at ThrowingDice.com  Wed Oct  7 20:45:16 2009
From: joe at ThrowingDice.com (Joe Mucchiello)
Date: Wed, 07 Oct 2009 20:45:16 -0400
Subject: [geeklog-devel] plugin_autoinstall - two more issues
In-Reply-To: <063B8B70CB9DA141B2FC1DB483561B9F356E73@nex-pluto.nextide.c a>
References: <063B8B70CB9DA141B2FC1DB483561B9F356E73@nex-pluto.nextide.ca>
Message-ID: <0KR600FGK7DJJRW0@mta3.srv.hcvlny.cv.net>

At 10:53 AM 10/7/2009, Randy Kolenko wrote:


> > Instead have a PLG_LoadFeature($feature,
> > $plugin = '') function that calls the plugin before attempting to
> > access that feature. If the plugin supports the feature (and dynamic
> > loading of the feature) it would load the functions needed at that
> > time. I admit I don't know if this really would improve anything. I
> > plan to test it out when I get the chance. It sounds good on
> > paper though.
>
>That is a good idea -- which is all predecated on refactoring the way
>plugins are written.
>Separation of logical functional units of code into their own
>dynamically linkable libraries would cut the parsed codebase down
>considerably.

The original idea was to do it at the load level. If you were on 
search.php it would define something to signal that search was 
needed. That idea is over a year old. But the PLG_loadFeature idea 
came out of this discussion and is more elegant I think. I figure you 
could remove just about everything from the functions.inc. Even 
"typically used" stuff like the usermenu block would be unneeded 
cruft in webservice call. Similarly, plugin authors would be 
encouraged to add features to their own plugins. The forums, for 
example, don't need to load the topic specific code (badges, smileys, 
the display code for a specific forum post, etc) unless those 
features are needed by the forums themselves. When viewing the 
calendar, those functions aren't needed.

So you end up with a bunch of subsections if you want to do it fully:

plugin: PLG_install, PLG_uninstall, PLG_upgrade, PLG_migrate, 
PLG_pluginStateChange
moderate: PLG_isModerator, PLG_getSubmissionCount, 
PLG_approveSubmissions, PLG_deleteSubmissions, etc.
submit: PLG_showSubmitForm
admin: PLG_getCCOptions, PLG_getAdminOptions, PLG_getIcon
comment: PLG_getCommentUrlId, PLG_commentDeleted, PLG_commentSave, etc.
stats: PLG_getPluginStats
search: PLG_getSearchTypes, PLG_supportsExtendedSearch, PLG_doSearch
user: PLG_createUser, PLG_deleteUser, PLG_loginUser, PLG_logoutUser
profile: PLG_userInfoChanged, PLG_profileVariableEdit, 
PLG_profileBlocksEdit, (and display) etc
content_filters: PLG_templateSetVars, PLG_collectTags, PLG_replaceTags
spam: PLG_checkForSpam, PLG_spamAction
item_filters: PLG_groupChanged, PLG_userInfoChanged, PLG_itemPreSave, 
PLG_itemSaved, PLG_itemDeleted, PLG_afterSaveSwitch
feeds: PLG_supportingFeeds, etc
blocks: PLG_getHeaderCode, PLG_getMenuItems, PLG_getWhatsNew, 
PLG_showCenterblock, PLG_getBlocks, PLG_getUserOptions
webservices: PLG_invokeServices, PLG_wsEnabled
config: PLG_configChange, PLG_getDocumentationUrl
tasks: PLG_runScheduledTasks
ping: PLG_handlePingComment

About the only thing I would leave in the functions.inc is 
plugin_checkversion_$plugin and plugin_loadfeature_$plugin. Now, I 
realize that is a lot of "features" but I think it is better to err 
on the side of too many features than too few. Yes, moderate and 
admin could easily be combined. But leave that for the plugin author 
to do if he wants. If the plugin author doesn't want create a whole 
file just for PLG_isModerator, that's his business. This is the kind 
of thing that should be profiled but will be hard to profile. If you 
can determine PLG_getHeaderCode is invoked on 99% of all page hits, 
then perhaps it should be left in functions.inc. I'm just laying out 
the idea. The devil is always in the details.

In general the features with just one or two functions should be the 
ones that only get called from one place: submit, search, stats. 
Putting them all into a single file won't be too detrimental but 
getting them out of functions.inc should be most beneficial.


----
Joe Mucchiello
Throwing Dice Games
http://www.throwingdice.com 



From dirk at haun-online.de  Mon Oct 12 01:58:54 2009
From: dirk at haun-online.de (Dirk Haun)
Date: Mon, 12 Oct 2009 07:58:54 +0200
Subject: [geeklog-devel] To-do list for Geeklog 1.6.1, part 1
In-Reply-To: <20090905073818.1354014370@smtp.haun-online.de>
References: <20090905073818.1354014370@smtp.haun-online.de>
Message-ID: <20091012055854.1214508206@smtp.haun-online.de>

Dirk Haun wrote:

>Okay, I think we should aim for a 1.6.1 release soon, maybe October-ish.

With the issues regarding the comment handling finally sorted out (I
hope), we should wrap up 1.6.1 development real soon now to make these
fixes available to our users. Anyone working on something they want to
see in 1.6.1?

I have a busy week ahead, followed by vacation, so don't expect much
from me over the next 2.5 weeks. After that, I'd like to push a beta out
before the end of the month.

I've updated the language files (i.e. synced them with their English
counterparts), so the nightly tarball can be used for test installs (for
those that don't pull from the Mercurial repository anyway).

bye, Dirk


-- 
http://www.geeklog.net/
http://geeklog.info/



From websitemaster at cogeco.net  Tue Oct 13 10:52:39 2009
From: websitemaster at cogeco.net (Tom)
Date: Tue, 13 Oct 2009 10:52:39 -0400
Subject: [geeklog-devel] To-do list for Geeklog 1.6.1, part 1
In-Reply-To: <20091012055854.1214508206@smtp.haun-online.de>
References: <20090905073818.1354014370@smtp.haun-online.de>
	<20091012055854.1214508206@smtp.haun-online.de>
Message-ID: <00e301ca4c14$cf56a760$6e03f620$@net>

I will have the staticpage stuff finished up by the time you get back.

Tom

-----Original Message-----
From: geeklog-devel-bounces at lists.geeklog.net
[mailto:geeklog-devel-bounces at lists.geeklog.net] On Behalf Of Dirk Haun
Sent: October-12-09 1:59 AM
To: geeklog-devel
Subject: Re: [geeklog-devel] To-do list for Geeklog 1.6.1, part 1

Dirk Haun wrote:

>Okay, I think we should aim for a 1.6.1 release soon, maybe October-ish.

With the issues regarding the comment handling finally sorted out (I
hope), we should wrap up 1.6.1 development real soon now to make these
fixes available to our users. Anyone working on something they want to
see in 1.6.1?

I have a busy week ahead, followed by vacation, so don't expect much
from me over the next 2.5 weeks. After that, I'd like to push a beta out
before the end of the month.

I've updated the language files (i.e. synced them with their English
counterparts), so the nightly tarball can be used for test installs (for
those that don't pull from the Mercurial repository anyway).

bye, Dirk


-- 
http://www.geeklog.net/
http://geeklog.info/

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

__________ Information from ESET NOD32 Antivirus, version of virus signature
database 4498 (20091011) __________

The message was checked by ESET NOD32 Antivirus.

http://www.eset.com





From Randy.Kolenko at nextide.ca  Wed Oct 14 10:05:12 2009
From: Randy.Kolenko at nextide.ca (Randy Kolenko)
Date: Wed, 14 Oct 2009 10:05:12 -0400
Subject: [geeklog-devel] To-do list for Geeklog 1.6.1, part 1
Message-ID: <063B8B70CB9DA141B2FC1DB483561B9F356E88@nex-pluto.nextide.ca>

Any objection to me adding a PLG function in lib-plugins.php that is
named:
PLG_testRequiredPluginVersion($current_version, $target_version)
That will take 2 parameters to test required versions for plugins (or
anything else really)?  Return is boolean true to denote whether the
current verison is >= the target version and boolean false if < target
version.

Thoughts?  Should this be in lib-common or keep it in lib-plugins?

-randy

> -----Original Message-----
> From: Dirk Haun [mailto:dirk at haun-online.de] 
> Sent: Monday, October 12, 2009 1:59 AM
> To: geeklog-devel
> Subject: Re: [geeklog-devel] To-do list for Geeklog 1.6.1, part 1
> 
> 
> Dirk Haun wrote:
> 
> >Okay, I think we should aim for a 1.6.1 release soon, maybe 
> >October-ish.
> 
> With the issues regarding the comment handling finally sorted 
> out (I hope), we should wrap up 1.6.1 development real soon 
> now to make these fixes available to our users. Anyone 
> working on something they want to see in 1.6.1?
> 
> I have a busy week ahead, followed by vacation, so don't 
> expect much from me over the next 2.5 weeks. After that, I'd 
> like to push a beta out before the end of the month.
> 
> I've updated the language files (i.e. synced them with their 
> English counterparts), so the nightly tarball can be used for 
> test installs (for those that don't pull from the Mercurial 
> repository anyway).
> 
> bye, Dirk
> 
> 
> -- 
> http://www.geeklog.net/
> http://geeklog.info/
> 
> _______________________________________________
> geeklog-devel mailing list
> geeklog-devel at lists.geeklog.net 
> http://eight.pairlist.net/mailman/listinfo/geeklog-devel
> 


From dirk at haun-online.de  Wed Oct 14 10:20:39 2009
From: dirk at haun-online.de (Dirk Haun)
Date: Wed, 14 Oct 2009 16:20:39 +0200
Subject: [geeklog-devel] To-do list for Geeklog 1.6.1, part 1
Message-ID: <20091014162039.59674i24bv2374mc@webmail.df.eu>


Randy Kolenko wrote:

> Any objection to me adding a PLG function in lib-plugins.php that is
> named:
> PLG_testRequiredPluginVersion($current_version, $target_version)

Is this only meant to compare version numbers? If so, PHP already has  
a version_compare function. Or, if you want to take Geeklog version  
naming conventions into account, have a look at

http://project.geeklog.net/tracking/view.php?id=866

bye, Dirk




From Randy.Kolenko at nextide.ca  Wed Oct 14 10:18:55 2009
From: Randy.Kolenko at nextide.ca (Randy Kolenko)
Date: Wed, 14 Oct 2009 10:18:55 -0400
Subject: [geeklog-devel] To-do list for Geeklog 1.6.1, part 1
Message-ID: <063B8B70CB9DA141B2FC1DB483561B9F356E89@nex-pluto.nextide.ca>

Ok.. Version_compare should be more than enough then.  Thanks!



> -----Original Message-----
> From: Dirk Haun [mailto:dirk at haun-online.de] 
> Sent: Wednesday, October 14, 2009 10:21 AM
> To: geeklog-devel at lists.geeklog.net
> Subject: Re: [geeklog-devel] To-do list for Geeklog 1.6.1, part 1
> 
> 
> 
> Randy Kolenko wrote:
> 
> > Any objection to me adding a PLG function in lib-plugins.php that is
> > named:
> > PLG_testRequiredPluginVersion($current_version, $target_version)
> 
> Is this only meant to compare version numbers? If so, PHP 
> already has  
> a version_compare function. Or, if you want to take Geeklog version  
> naming conventions into account, have a look at
> 
> http://project.geeklog.net/tracking/view.php?id=866
> 
> bye, Dirk
> 
> 
> _______________________________________________
> geeklog-devel mailing list
> geeklog-devel at lists.geeklog.net 
> http://eight.pairlist.net/mailman/listinfo/geeklog-devel
> 


From Randy.Kolenko at nextide.ca  Wed Oct 14 11:25:39 2009
From: Randy.Kolenko at nextide.ca (Randy Kolenko)
Date: Wed, 14 Oct 2009 11:25:39 -0400
Subject: [geeklog-devel] To-do list for Geeklog 1.6.1, part 1
Message-ID: <063B8B70CB9DA141B2FC1DB483561B9F356E8C@nex-pluto.nextide.ca>



> Is this only meant to compare version numbers? If so, PHP 
> already has  
> a version_compare function. Or, if you want to take Geeklog version  
> naming conventions into account, have a look at
> 
> http://project.geeklog.net/tracking/view.php?id=866
> 
> bye, Dirk


From Randy.Kolenko at nextide.ca  Wed Oct 14 11:27:53 2009
From: Randy.Kolenko at nextide.ca (Randy Kolenko)
Date: Wed, 14 Oct 2009 11:27:53 -0400
Subject: [geeklog-devel] To-do list for Geeklog 1.6.1, part 1
Message-ID: <063B8B70CB9DA141B2FC1DB483561B9F356E8D@nex-pluto.nextide.ca>

Whooops!  Hit send to fast.

Version_compare is fine, but it considers 1.0.0 > 1.0 > 1

This requires some translation to make 1.0 look like 1.0.0 etc.  This
should be a function.
I've written it already and I've tucked it into the autoinstall.php for
the plugin -- however it's a function that all of our plugins would use.
Which means I'll have to copy it across all autoinstall.php files.  The
alternative is to pop it into the core.  But again, I don't want to do
that without agreement.

-randy


> Is this only meant to compare version numbers? If so, PHP 
> already has  
> a version_compare function. Or, if you want to take Geeklog version  
> naming conventions into account, have a look at
> 


From dirk at haun-online.de  Wed Oct 14 15:36:30 2009
From: dirk at haun-online.de (Dirk Haun)
Date: Wed, 14 Oct 2009 21:36:30 +0200
Subject: [geeklog-devel] To-do list for Geeklog 1.6.1, part 1
In-Reply-To: <063B8B70CB9DA141B2FC1DB483561B9F356E8D@nex-pluto.nextide.ca>
References: <063B8B70CB9DA141B2FC1DB483561B9F356E8D@nex-pluto.nextide.ca>
Message-ID: <20091014193630.1382654061@smtp.haun-online.de>

Randy Kolenko wrote:

>I've written it already and I've tucked it into the autoinstall.php for
>the plugin -- however it's a function that all of our plugins would use.
>Which means I'll have to copy it across all autoinstall.php files.  The
>alternative is to pop it into the core.  But again, I don't want to do
>that without agreement.

I'm fine with adding such a function, but then I think we should go all
the way and provide one that can also interpret Geeklog version numbers,
i.e. cover
http://project.geeklog.net/tracking/view.php?id=866

bye, Dirk


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



From robg at griffsweb.com  Sat Oct 17 00:54:53 2009
From: robg at griffsweb.com (Rob Griffiths)
Date: Fri, 16 Oct 2009 21:54:53 -0700
Subject: [geeklog-devel] Handling of 'special' characters in 1.60sr2
Message-ID: <955159C0-6143-4B90-B50C-63CC555CFE07@griffsweb.com>

After a long and sometimes frustrating afternoon, macosxhints.com is  
finally upgraded to Geeklog 1.6.0sr2. One of the reasons I was really  
looking forward to this upgrade was the better handling of special  
characters in story submissions, which I seem to recall reading about  
in this list over the last year or two.

Unfortunately, my experience with the new system is that handling of  
special characters is still broken, though not quite as badly as  
before - at least on my domain. As an example, I tried this very basic  
test story (on both macosxhints.com and geeklog.net), submitted in  
HTML mode:

<pre>a \ b <> c | d $ e</pre>

<code>a \ b <> c | d $ e</code>
<br><br>
<tt>a \ b <> c | d $ e</tt>
<br><br>
a \ b <> c | d $ e

My expectation for the output of this story would be:

[mono]a \ b <> c | d $ e

a \ b <> c | d $ e

a \ b <> c | d $ e[end mono[

a \ b <> c | d $ e

On geeklog.net, this worked as expected. On macosxhints.com, though,  
all the backslashes were stripped out, from both the coded bits, and  
the plain HTML final line. Does anyone have any idea *why* it works on  
one site, but not another, when both are running 1.6.0.sr2? I've  
looked at the various config options, but don't see anything there  
that would explain this oddity. Something in the PHP configuration?

Even worse than the missing backslashes, though, is what has happens  
to the input area -- the special characters are now displayed as their  
HTML entities, making the submission very hard to read. For instance:

<pre>a &#92; b &lt;&gt; c | d &#36; e</pre>

To a user, the conversion of the normal characters to their HTML  
entities may be very confusing, especially in the bit of "regular"  
text after the code examples. For my users, this is far from ideal --  
the text in the input form shouldn't, in my opinion, ever change from  
what the user put there. I understand it needs to be encoded for  
display, but it should be unencoded in the input box. In Geeklog 1.4,  
this didn't happen at all -- sure, it ate the backslashes, but all the  
rest of the characters were displayed in their normal form.

Help? Any chance of fixes for the encoding of the submission form? Any  
idea how I can get my backslashes to work as they do on geeklog.net?

thanks;
-rob.


From sc1245 at messiah.edu  Sat Oct 17 15:18:06 2009
From: sc1245 at messiah.edu (Sean Clark)
Date: Sat, 17 Oct 2009 15:18:06 -0400
Subject: [geeklog-devel] Handling of 'special' characters in	 1.60sr2
Message-ID: <4AD9E02E020000CB0002527B@gwia.messiah.edu>

The first thing that comes to mind is that either you, or geeklog, has magic quotes enabled and the other doesn't. You can check it with this: 

if(get_magic_quotes_gpc()) {
	echo "Magic quotes are enabled";
} else {
	echo "Magic quotes are disabled";

Nowadays it's recommended for them to be off, since they can muddle things a bit, but I'm not sure how Geeklog handles them since it's older software. If they're on, try turning them off and see if that helps things.

- Sean

>>> Rob Griffiths <robg at griffsweb.com> 10/17/09 1:00 AM >>>
After a long and sometimes frustrating afternoon, macosxhints.com is  
finally upgraded to Geeklog 1.6.0sr2. One of the reasons I was really  
looking forward to this upgrade was the better handling of special  
characters in story submissions, which I seem to recall reading about  
in this list over the last year or two.

Unfortunately, my experience with the new system is that handling of  
special characters is still broken, though not quite as badly as  
before - at least on my domain. As an example, I tried this very basic  
test story (on both macosxhints.com and geeklog.net), submitted in  
HTML mode:

<pre>a \ b <> c | d $ e</pre>

<code>a \ b <> c | d $ e</code>
<br><br>
<tt>a \ b <> c | d $ e</tt>
<br><br>
a \ b <> c | d $ e

My expectation for the output of this story would be:

[mono]a \ b <> c | d $ e

a \ b <> c | d $ e

a \ b <> c | d $ e[end mono[

a \ b <> c | d $ e

On geeklog.net, this worked as expected. On macosxhints.com, though,  
all the backslashes were stripped out, from both the coded bits, and  
the plain HTML final line. Does anyone have any idea *why* it works on  
one site, but not another, when both are running 1.6.0.sr2? I've  
looked at the various config options, but don't see anything there  
that would explain this oddity. Something in the PHP configuration?

Even worse than the missing backslashes, though, is what has happens  
to the input area -- the special characters are now displayed as their  
HTML entities, making the submission very hard to read. For instance:

<pre>a \ b <> c | d $ e</pre>

To a user, the conversion of the normal characters to their HTML  
entities may be very confusing, especially in the bit of "regular"  
text after the code examples. For my users, this is far from ideal --  
the text in the input form shouldn't, in my opinion, ever change from  
what the user put there. I understand it needs to be encoded for  
display, but it should be unencoded in the input box. In Geeklog 1.4,  
this didn't happen at all -- sure, it ate the backslashes, but all the  
rest of the characters were displayed in their normal form.

Help? Any chance of fixes for the encoding of the submission form? Any  
idea how I can get my backslashes to work as they do on geeklog.net?

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



From robg at griffsweb.com  Sat Oct 17 18:05:13 2009
From: robg at griffsweb.com (Rob Griffiths)
Date: Sat, 17 Oct 2009 15:05:13 -0700
Subject: [geeklog-devel] Handling of 'special' characters in	 1.60sr2
In-Reply-To: <4AD9E02E020000CB0002527B@gwia.messiah.edu>
References: <4AD9E02E020000CB0002527B@gwia.messiah.edu>
Message-ID: <AC371ACB-0663-4DD4-84BA-B2035BB19EB6@griffsweb.com>

On Oct 17, 2009, at 12:18 PM, Sean Clark wrote:

> The first thing that comes to mind is that either you, or geeklog,  
> has magic quotes enabled and the other doesn't. You can check it  
> with this:

We disabled magic quotes, and indeed, it no longer eats backslashes.  
Unfortunately, the output is now really bad. The backslashes are  
converted to HTML entities in the actual story *and* in the input box  
(along with, in the input box, all the other special characters).

I need to find a fix for this ASAP; my site is now unusable for any  
code submissions, and those are probably 30% of what we get :(.

-rob.


From robg at griffsweb.com  Sat Oct 17 18:07:38 2009
From: robg at griffsweb.com (Rob Griffiths)
Date: Sat, 17 Oct 2009 15:07:38 -0700
Subject: [geeklog-devel] Handling of 'special' characters in	 1.60sr2
In-Reply-To: <AC371ACB-0663-4DD4-84BA-B2035BB19EB6@griffsweb.com>
References: <4AD9E02E020000CB0002527B@gwia.messiah.edu>
	<AC371ACB-0663-4DD4-84BA-B2035BB19EB6@griffsweb.com>
Message-ID: <2DF1E6BB-5FED-4867-8ABE-B26ABC1BC371@griffsweb.com>

On Oct 17, 2009, at 3:05 PM, Rob Griffiths wrote:

> We disabled magic quotes, and indeed, it no longer eats backslashes.  
> Unfortunately, the output is now really bad. The backslashes are  
> converted to HTML entities in the actual story *and* in the input  
> box (along with, in the input box, all the other special characters).

Quick follow-up: when published, the backslashes appear correctly. All  
the text between the < and > has vanished, however.

-rob.


From websitemaster at cogeco.net  Sat Oct 17 19:37:29 2009
From: websitemaster at cogeco.net (Tom)
Date: Sat, 17 Oct 2009 19:37:29 -0400
Subject: [geeklog-devel] Handling of 'special' characters in 1.60sr2
In-Reply-To: <955159C0-6143-4B90-B50C-63CC555CFE07@griffsweb.com>
References: <955159C0-6143-4B90-B50C-63CC555CFE07@griffsweb.com>
Message-ID: <01b001ca4f82$ca508da0$5ef1a8e0$@net>

Hi Rob,

As far as I can tell Geeklog.net is having the same problem. When I preview
a contributed story with the text sample from this email and with a post
mode of HTML Formatted I get the following text back in the Story Intro text
area

<pre>a &#92; b &lt;&gt; c | d &#36; e</pre>

<code>a &#92; b &lt;&gt; c | d &#36; e</code>
<br><br>
<tt>a &#92; b &lt;&gt; c | d &#36; e</tt>
<br><br>
a &#92; b &lt;&gt; c | d &#36; e

Tom


-----Original Message-----
From: geeklog-devel-bounces at lists.geeklog.net
[mailto:geeklog-devel-bounces at lists.geeklog.net] On Behalf Of Rob Griffiths
Sent: October-17-09 12:55 AM
To: geeklog-devel at lists.geeklog.net
Subject: [geeklog-devel] Handling of 'special' characters in 1.60sr2

After a long and sometimes frustrating afternoon, macosxhints.com is  
finally upgraded to Geeklog 1.6.0sr2. One of the reasons I was really  
looking forward to this upgrade was the better handling of special  
characters in story submissions, which I seem to recall reading about  
in this list over the last year or two.

Unfortunately, my experience with the new system is that handling of  
special characters is still broken, though not quite as badly as  
before - at least on my domain. As an example, I tried this very basic  
test story (on both macosxhints.com and geeklog.net), submitted in  
HTML mode:

<pre>a \ b <> c | d $ e</pre>

<code>a \ b <> c | d $ e</code>
<br><br>
<tt>a \ b <> c | d $ e</tt>
<br><br>
a \ b <> c | d $ e

My expectation for the output of this story would be:

[mono]a \ b <> c | d $ e

a \ b <> c | d $ e

a \ b <> c | d $ e[end mono[

a \ b <> c | d $ e

On geeklog.net, this worked as expected. On macosxhints.com, though,  
all the backslashes were stripped out, from both the coded bits, and  
the plain HTML final line. Does anyone have any idea *why* it works on  
one site, but not another, when both are running 1.6.0.sr2? I've  
looked at the various config options, but don't see anything there  
that would explain this oddity. Something in the PHP configuration?

Even worse than the missing backslashes, though, is what has happens  
to the input area -- the special characters are now displayed as their  
HTML entities, making the submission very hard to read. For instance:

<pre>a &#92; b &lt;&gt; c | d &#36; e</pre>

To a user, the conversion of the normal characters to their HTML  
entities may be very confusing, especially in the bit of "regular"  
text after the code examples. For my users, this is far from ideal --  
the text in the input form shouldn't, in my opinion, ever change from  
what the user put there. I understand it needs to be encoded for  
display, but it should be unencoded in the input box. In Geeklog 1.4,  
this didn't happen at all -- sure, it ate the backslashes, but all the  
rest of the characters were displayed in their normal form.

Help? Any chance of fixes for the encoding of the submission form? Any  
idea how I can get my backslashes to work as they do on geeklog.net?

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

__________ Information from ESET NOD32 Antivirus, version of virus signature
database 4517 (20091017) __________

The message was checked by ESET NOD32 Antivirus.

http://www.eset.com





From websitemaster at cogeco.net  Tue Oct 27 14:14:18 2009
From: websitemaster at cogeco.net (Tom)
Date: Tue, 27 Oct 2009 14:14:18 -0400
Subject: [geeklog-devel] Why the 403 code after spam detected? IIS7 doesn't
	like it
In-Reply-To: <01b001ca4f82$ca508da0$5ef1a8e0$@net>
References: <955159C0-6143-4B90-B50C-63CC555CFE07@griffsweb.com>
	<01b001ca4f82$ca508da0$5ef1a8e0$@net>
Message-ID: <024701ca5731$4ca97b30$e5fc7190$@net>

Hi All,

I have been getting reports of 403 errors on my new server with IIS7 when a
user attempted to submit something.  I finally narrowed it down to this line
after a submission of a comment, story, etc.. if the spamx plugin detects
spam:

        COM_displayMessageAndAbort ($result, 'spamx', 403, 'Forbidden');


Is there any reason we should be generating this 403 error here? This
doesn't play nice with IIS7 which by default returns a custom summary error
page. As a temp solution I have turned off Custom Error Pages which now
gives me the appropriate geeklog page with 
"Spam detected. Post was deleted." information.  This is not an ideal
solution because if other server errors happen, a detailed error report is
displayed to users.

Does anyone have any problems with changing the above line to this in the
geeklog code?

	COM_displayMessageAndAbort ($result, 'spamx');

Thanks

Tom



From dirk at haun-online.de  Tue Oct 27 18:30:27 2009
From: dirk at haun-online.de (Dirk Haun)
Date: Tue, 27 Oct 2009 23:30:27 +0100
Subject: [geeklog-devel] Why the 403 code after spam detected? IIS7
 doesn't like it
In-Reply-To: <024701ca5731$4ca97b30$e5fc7190$@net>
References: <955159C0-6143-4B90-B50C-63CC555CFE07@griffsweb.com>
	<01b001ca4f82$ca508da0$5ef1a8e0$@net>
	<024701ca5731$4ca97b30$e5fc7190$@net>
Message-ID: <20091027223027.1158843187@smtp.haun-online.de>

Tom wrote:

>Is there any reason we should be generating this 403 error here?

Yes: It's proper HTTP.

The client sent a POST request and the server denies to fullfill it. In
which case we should tell the client why, by sending the 403 (machine-
readable) and the actual error message as the content (human-readable).
A 200 status code would be wrong here, since the POST request was not handled.


>This
>doesn't play nice with IIS7 which by default returns a custom summary error
>page.

I guess as long as it still indicates that a 403 happened, that would be
okay (need to check with the RFC). Still, I have to wonder why they
chose to do that.


>	COM_displayMessageAndAbort ($result, 'spamx');

That would send a 200 status code which, as mentioned above, would be wrong.

Does IIS do the same for other error codes (from the 400 or 500 range)?
There may be one or two other status codes that we could use here if
it's only a problem with the 403.

bye, Dirk


-- 
http://www.geeklog.net/
http://geeklog.info/



From mike at fuckingbrit.com  Wed Oct 28 05:55:19 2009
From: mike at fuckingbrit.com (Michael Jervis)
Date: Wed, 28 Oct 2009 09:55:19 +0000
Subject: [geeklog-devel] Why the 403 code after spam detected? IIS7
	doesn't like it
In-Reply-To: <20091027223027.1158843187@smtp.haun-online.de>
References: <955159C0-6143-4B90-B50C-63CC555CFE07@griffsweb.com>
	<01b001ca4f82$ca508da0$5ef1a8e0$@net>
	<024701ca5731$4ca97b30$e5fc7190$@net>
	<20091027223027.1158843187@smtp.haun-online.de>
Message-ID: <7b42e7470910280255n2b0b93b8hbffa6a313bb5e0d1@mail.gmail.com>

>>This
>>doesn't play nice with IIS7 which by default returns a custom summary error
>>page.

IIS does this. Because it thinks it's being helpful. It does posher
error handling automatically to 'help' out.

You can re-configure it on a per-virtual directory or site basis to do
what you want exactly.

Then on top of THAT you GET IE showing 'friendly' HTTP errors to users
when the server HAD told them exactly what did go wrong.

It's such fun supporting an IIS hosted app to IE users...


From joe at ThrowingDice.com  Wed Oct 28 05:50:56 2009
From: joe at ThrowingDice.com (Joe Mucchiello)
Date: Wed, 28 Oct 2009 05:50:56 -0400
Subject: [geeklog-devel] Why the 403 code after spam detected? IIS7
 doesn't like it
In-Reply-To: <024701ca5731$4ca97b30$e5fc7190$@net>
References: <955159C0-6143-4B90-B50C-63CC555CFE07@griffsweb.com>
	<01b001ca4f82$ca508da0$5ef1a8e0$@net>
	<024701ca5731$4ca97b30$e5fc7190$@net>
Message-ID: <0KS700ISTY14S4Q0@mta5.srv.hcvlny.cv.net>

At 02:14 PM 10/27/2009, Tom wrote:
>Is there any reason we should be generating this 403 error here? This
>doesn't play nice with IIS7 which by default returns a custom summary error
>page.

That default can (and with Geeklog, should) be changed:

http://serverfault.com/questions/69839/show-php-error-message-on-iis-7


----
Joe Mucchiello
Throwing Dice Games
http://www.throwingdice.com 



From websitemaster at cogeco.net  Thu Oct 29 09:05:14 2009
From: websitemaster at cogeco.net (Tom)
Date: Thu, 29 Oct 2009 09:05:14 -0400
Subject: [geeklog-devel] Why the 403 code after spam detected? IIS7
	doesn't like it
In-Reply-To: <0KS700ISTY14S4Q0@mta5.srv.hcvlny.cv.net>
References: <955159C0-6143-4B90-B50C-63CC555CFE07@griffsweb.com>	<01b001ca4f82$ca508da0$5ef1a8e0$@net>	<024701ca5731$4ca97b30$e5fc7190$@net>
	<0KS700ISTY14S4Q0@mta5.srv.hcvlny.cv.net>
Message-ID: <002701ca5898$7539dc80$5fad9580$@net>

Yeah I did change it already to detailed errors to bypass the problem. I'm
not sure why Microsoft decided to change how things behaved from IIS6 to
IIS7.

-----Original Message-----
From: geeklog-devel-bounces at lists.geeklog.net
[mailto:geeklog-devel-bounces at lists.geeklog.net] On Behalf Of Joe Mucchiello
Sent: October-28-09 5:51 AM
To: Geeklog Development
Subject: Re: [geeklog-devel] Why the 403 code after spam detected? IIS7
doesn't like it

At 02:14 PM 10/27/2009, Tom wrote:
>Is there any reason we should be generating this 403 error here? This
>doesn't play nice with IIS7 which by default returns a custom summary error
>page.

That default can (and with Geeklog, should) be changed:

http://serverfault.com/questions/69839/show-php-error-message-on-iis-7


----
Joe Mucchiello
Throwing Dice Games
http://www.throwingdice.com 

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

__________ Information from ESET NOD32 Antivirus, version of virus signature
database 4550 (20091028) __________

The message was checked by ESET NOD32 Antivirus.

http://www.eset.com





From dirk at haun-online.de  Thu Oct 29 13:35:41 2009
From: dirk at haun-online.de (Dirk Haun)
Date: Thu, 29 Oct 2009 18:35:41 +0100
Subject: [geeklog-devel] [geeklog-cvs] geeklog: Experimental: Give the
 user an idea how long they have ...
In-Reply-To: <hg.37fcd14cdee2.1256836340.1485632861@qs1489.pair.com>
References: <hg.37fcd14cdee2.1256836340.1485632861@qs1489.pair.com>
Message-ID: <20091029173541.1055943830@smtp.haun-online.de>

>url:  http://project.geeklog.net/cgi-bin/hgwebdir.cgi/geeklog/rev/
37fcd14cdee2

>description:
>Experimental: Give the user an idea how long they have until the
>security token expires

So Tony and myself were discussing CSRF and the dreaded usage problems
they cause when trying to make things secure. This was one idea we had.

I'd consider this an intermediate step until we get around to
overhauling the editors. But it will at least prevent some nasty
surprises (I would hope).

What does everybody think? Also, how's that message?

>+    91 => 'You have until %s to make changes. After that time, the
>security token embedded into this page will expire and you will lose
>your changes. You can always hit "Preview" to extend the expiry time.'

This would need some adjustment for forms without a preview option, of
course. I was thinking of adding such a message to all the editors for 1.6.1.

bye, Dirk


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



From chipper at llamas.net  Fri Oct 30 09:49:54 2009
From: chipper at llamas.net (Chris 'Chipper' Chiapusio)
Date: Fri, 30 Oct 2009 09:49:54 -0400
Subject: [geeklog-devel] [geeklog-cvs] geeklog: Experimental: Give
	the	user an idea how long they have ...
In-Reply-To: <20091029173541.1055943830@smtp.haun-online.de>
References: <hg.37fcd14cdee2.1256836340.1485632861@qs1489.pair.com>
	<20091029173541.1055943830@smtp.haun-online.de>
Message-ID: <20091030134954.GA17463@chipsworld.llamas.net>

On Thu, Oct 29, 2009 at 06:35:41PM +0100, Dirk Haun wrote:
>>url:  http://project.geeklog.net/cgi-bin/hgwebdir.cgi/geeklog/rev/
>37fcd14cdee2
>
>>description:
>>Experimental: Give the user an idea how long they have until the
>>security token expires
>
>So Tony and myself were discussing CSRF and the dreaded usage problems
>they cause when trying to make things secure. This was one idea we had.
>
>I'd consider this an intermediate step until we get around to
>overhauling the editors. But it will at least prevent some nasty
>surprises (I would hope).
>
>What does everybody think? Also, how's that message?
>
>>+    91 => 'You have until %s to make changes. After that time, the
>>security token embedded into this page will expire and you will lose
>>your changes. You can always hit "Preview" to extend the expiry time.'
>
>This would need some adjustment for forms without a preview option, of
>course. I was thinking of adding such a message to all the editors for 1.6.1.
>
>bye, Dirk
>


Can you display the countdown timer somehow?


Chip
-- 
------
				**** Warning ****
This e-mail message, without warrant or warning, and despite US law as set
forth in the Foreign Intelligence Surveillance Act of 1978, may be subject
to monitoring by the United States National Security Agency and/or the
Department of Defense. Information contained in this message may be used
against any senders or recipients, now or in the future, in a public trial
or secret tribunal.
                       Please encrypt anything important.
    PGP Key: http://wwwkeys.pgp.net:11371/pks/lookup?op=get&search=0x6CFA486D


From cordiste at free.fr  Fri Oct 30 10:28:35 2009
From: cordiste at free.fr (cordiste)
Date: Fri, 30 Oct 2009 15:28:35 +0100
Subject: [geeklog-devel] [geeklog-cvs] geeklog: Experimental: Give the
	user an idea how long they have ...
In-Reply-To: <20091030134954.GA17463@chipsworld.llamas.net>
References: <hg.37fcd14cdee2.1256836340.1485632861@qs1489.pair.com>
	<20091029173541.1055943830@smtp.haun-online.de>
	<20091030134954.GA17463@chipsworld.llamas.net>
Message-ID: <364575ed0910300728g28b9fcc1r2dc6007573e6dd7d@mail.gmail.com>

Hello,

Could we imagine an auto preview to extend the expiry time, or this is not
secure?

::Ben

2009/10/30 Chris 'Chipper' Chiapusio <chipper at llamas.net>

>
>
> Can you display the countdown timer somehow?
>
>
> Chip
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://pairlist8.pair.net/pipermail/geeklog-devel/attachments/20091030/02bd2f12/attachment.html>

From dirk at haun-online.de  Fri Oct 30 11:38:55 2009
From: dirk at haun-online.de (Dirk Haun)
Date: Fri, 30 Oct 2009 16:38:55 +0100
Subject: [geeklog-devel] [geeklog-cvs] geeklog: Experimental: Give the
 user an idea how long they have ...
In-Reply-To: <e4e171f0910300659u38820939h800445d2102c059b@mail.gmail.com>
References: <hg.37fcd14cdee2.1256836340.1485632861@qs1489.pair.com>
	<20091029173541.1055943830@smtp.haun-online.de>
	<e4e171f0910300659u38820939h800445d2102c059b@mail.gmail.com>
Message-ID: <20091030153855.753786748@smtp.haun-online.de>

Tony Bibbs wrote:

>It think a better alternative is to give them how much time they have
>remaining

Guess I wasn't clear - that's what the message does, e.g.

    You have until 04:53pm to make changes.


>and, if it expires, make them submit their password again.

Yes, that's the best solution to the problem I've heard so far and
should be the final goal. But, as I said, this message is meant as an
intermediate step. Fixing the editors, including the password check,
etc. is a lot of (tedious) work and I don't see it happening anytime
soon. In the meantime, we need to push out a 1.6.1 soon now and this
simple message could be implemented easily and in time.

Welcome back, btw :)

bye, Dirk


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



From tony at tonybibbs.com  Fri Oct 30 12:09:40 2009
From: tony at tonybibbs.com (Tony Bibbs)
Date: Fri, 30 Oct 2009 11:09:40 -0500
Subject: [geeklog-devel] [geeklog-cvs] geeklog: Experimental: Give the
	user an idea how long they have ...
In-Reply-To: <20091030153855.753786748@smtp.haun-online.de>
References: <hg.37fcd14cdee2.1256836340.1485632861@qs1489.pair.com>
	<20091029173541.1055943830@smtp.haun-online.de>
	<e4e171f0910300659u38820939h800445d2102c059b@mail.gmail.com>
	<20091030153855.753786748@smtp.haun-online.de>
Message-ID: <e4e171f0910300909i72bc6febn7ac1337b04ebc8c2@mail.gmail.com>

On Fri, Oct 30, 2009 at 10:38 AM, Dirk Haun <dirk at haun-online.de> wrote:

> Yes, that's the best solution to the problem I've heard so far and
> should be the final goal.


Actually, the best solution to the problem would be an optional AJAX
auto-save features.  The JS to call a PHP auto-save PHP script is trivial.
During that request the CSRF token and timestamp values in the session can
be updated and the new token can be sent back where DOM manipulation would
replace the old token.

Of course <noscript> tags can be added to accomodate people that down allow
JS.   This does begin to touch on whether admins should simply be required
to allow JS.  At work (gov't with accessibility requirements) we use
graceful degredation for admin areas and progressive enhancement for
anything facing the public.  I'm thinking of formally adopting that for
AptitudeCMS but that comes at the expense of pissing off anybody with
accessibility concerns from administrating the system.  At work, this is a
customer-by-customer decision but for a project like this it's a much
muddier deal.


> Welcome back, btw :)
>

[grin].  It was good seeing you at Google. Given our conversations there,
the fact AptitudeCMS alpha is finally out this seemed appropriate again.

-- 
Tony Bibbs
Phone: (515) 259-0003
Twitter, Skype, Facebook: tonybibbs
Web: http://www.tonybibbs.com
        http://www.apteno.net
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://pairlist8.pair.net/pipermail/geeklog-devel/attachments/20091030/62f66693/attachment.html>

From joe at ThrowingDice.com  Sat Oct 31 05:14:32 2009
From: joe at ThrowingDice.com (Joe Mucchiello)
Date: Sat, 31 Oct 2009 05:14:32 -0400
Subject: [geeklog-devel] [geeklog-cvs] geeklog: Experimental: Give the
 user an idea how long they have ...
In-Reply-To: <hg.37fcd14cdee2.1256836340.1485632861@qs1489.pair.com>
References: <hg.37fcd14cdee2.1256836340.1485632861@qs1489.pair.com>
Message-ID: <0KSD00IP6GACZVD0@mta1.srv.hcvlny.cv.net>

As a suggestion, perhaps you should create a 
SEC_addTokenToTemplate($Template) function to lib-security. This way 
anywhere you need to add the security token to a form you don't need 
to add code for this. If the form has {gltoken_name} {gl_token}, 
{gltoken_expirynotice} and {gltoken_expirytime} variables, they get 
set. Then instead of generating the HTML as you have done here, you 
could just add the HTML to the template file.

If the form doesn't have any GET urls, the code doesn't even have to 
call SEC_createToken since this new function could take care of it. 
Also, this makes it easy to add the expiry information to any form 
and you can change how the expiration is handled without having to 
recode a lot of PHP.

You could also add a few more variables: {gltoken_timeleft} in 
seconds for use with javascript if someone wishes to add javascript 
to their form.

   Joe

At 01:12 PM 10/29/2009, geeklog-cvs at lists.geeklog.net wrote:
>diff -r 5260a7fb13df -r 37fcd14cdee2 public_html/admin/story.php
>--- a/public_html/admin/story.php       Thu Oct 29 14:47:18 2009 +0100
>+++ b/public_html/admin/story.php       Thu Oct 29 18:09:46 2009 +0100
>@@ -727,11 +727,22 @@
>      $story_templates->set_var('lang_cancel', $LANG_ADMIN['cancel']);
>      $story_templates->set_var('lang_delete', $LANG_ADMIN['delete']);
>      $story_templates->set_var('gltoken_name', CSRF_TOKEN);
>-    $story_templates->set_var('gltoken', SEC_createToken());
>+    $token = SEC_createToken();
>+    $story_templates->set_var('gltoken', $token);
>      $story_templates->parse('output','editor');
>
>      $display .= COM_startBlock ($LANG24[5], '',
>                          COM_getBlockTemplate ('_admin_block', 'header'));
>+
>+    $expirytime = SEC_getTokenExpiryTime($token);
>+    if ($expirytime > 0) {
>+        $txt = '<p id="token-expirynotice">' . '' . '</p>';
>+        $exptime = '<span id="token-expirytime">'
>+                 . strftime($_CONF['timeonly'], $expirytime) . '</span>';
>+        $display .= '<p id="token-expirynotice">'
>+                 . sprintf($LANG24[91], $exptime) . '</p>';
>+    }
>+
>      $display .= 
> $story_templates->finish($story_templates->get_var('output'));
>      $display .= COM_endBlock (COM_getBlockTemplate 
> ('_admin_block', 'footer'));


----
Joe Mucchiello
Throwing Dice Games
http://www.throwingdice.com