[geeklog-devel] PLG_commentPreSave

Tony Bibbs tony at tonybibbs.com
Thu Jan 27 14:31:56 EST 2005


This also brings up the issue of plugin dependencies.  We have this in 
mind for GL2 on how to have some plugins either require or optionally 
use features from other plugins.  That's essentially what we want.  
After I thought about the message below I sent I realized we can't 
assume the spamx plugin is installed (even if it is a plugin).  Seems 
like an elegant fix might not be possible with the current paradigm.

--Tony

Tony Bibbs wrote:

> Hrm, k I see.  So the question for me is do we really need the SPAMx 
> function in the API at all.  What's wrong with exposing the checkSpam 
> in lib-common.php (or some other library)?  Seems like this method 
> (check for spam) isn't an API specific thing, it is a feature that we 
> would like to expose to other plugins.
>
> Thus, I say it would be up to the plugin author to explicitly check 
> for spam from within their own appropriate methods.  Am I missing 
> anything?
>
> --Tony
>
> Blaine Lang wrote:
>
>> Uh ok - went back through my emails and it was last Sept/Oct that I 
>> worked on this.
>> Here was the email I sent to Dirk that raised this very question when 
>> I was adding the spamx API's.
>>
>> Have a read and see if this made sense.
>>
>> -----
>> I'm wondering if there is a reason to preserve the new API that Tony 
>> added to support the SPAMX feature in comments. Tony wrote a API that 
>> is very generic and can be used for other purposes. It's passed a lot 
>> of PARMS which would be useful by a Plugin if it needed to do 
>> something with that coment.
>>
>> function PLG_commentPreSave($uid, $title, $comment, $sid, $pid, 
>> $type, $postmode)
>>
>> The SPAMX API now only needs 2 parms ($text and $action)
>>
>> Tom's first idea was to change the PLG_commentPreSave API and I'm 
>> wondering if we should keep it. This API is only called from 
>> comment.php - since that is the only un-moderated way to add content 
>> to stories. But if we really want a generic hook then it should be 
>> for new stories as well as comments I think. I don't quite have the 
>> application in mind of how this would be used other then for parsing 
>> bbcode tags or wiki language. In both those cases, I think only the 
>> textual content would need to be passed as well.
>>
>> So I'm not sure what to do with the PLG_commentPreSave API.
>>
>> I'm thinking of adding a new PLG_checkforSpam($content,$action) API 
>> and that would be called from comment.php. The PLG_checkforSpam is a 
>> wrapper to call the plugin_checkforSpam_spamx()
>>
>> The other idea is to add the call to plugin_checkforSpam_spamx in the 
>> PLG_commentPreSave() so that it will be called plus what ever plugin 
>> related functions that may be available.
>>
>> Sorry to make this sound more complex - it's the current API and what 
>> to do with it that make me stop and ask.
>>
>> Blaine
>> ------
>>
>> ----- Original Message ----- From: "Tony Bibbs" <tony at tonybibbs.com>
>> To: <geeklog-devel at lists.geeklog.net>
>> Sent: Thursday, January 27, 2005 1:22 PM
>> Subject: Re: [geeklog-devel] PLG_commentPreSave
>>
>>
>> Right, Vinny's question is why couldn't the spamx plugin just have used
>> PLG_commentPreSave then?
>>
>> --Tony
>>
>> Vincent Furia wrote:
>>
>>  
>>
>>> On Thu, 27 Jan 2005 12:00:27 -0500, Blaine Lang 
>>> <geeklog at langfamily.ca> wrote:
>>>
>>>
>>>   
>>>
>>>> Dirk, Tom and I talked about this when implementing the new SPAMX 
>>>> API's and
>>>> decided that it was best to still have a Non-Spamx API to allow other
>>>> plugins to add any other comment related filtering or handling that 
>>>> may be
>>>> required.
>>>>
>>>>
>>>>
>>>>     
>>>
>>> I'm still confused as to why different APIs are needed since they
>>> appear to do the same thing.  They are even called one after the
>>> other.
>>>
>>> I think one plugin call would be enough, something like:
>>>
>>> PLG_commentPreSave(title, comment, ...) and have it return HTML to
>>> output if there is an error (this can include a COM_refresh) otherwise
>>> just return 0.  If I can work it into the plugin API to pass the
>>> comment and title by reference, plugins could modify those and still
>>> return a "success" status.
>>>
>>> Thoughts?
>>>
>>> -Vinny
>>> _______________________________________________
>>> geeklog-devel mailing list
>>> geeklog-devel at lists.geeklog.net
>>> http://lists.geeklog.net/listinfo/geeklog-devel
>>>
>>>
>>>   
>>
>>
>> _______________________________________________
>> geeklog-devel mailing list
>> geeklog-devel at lists.geeklog.net
>> http://lists.geeklog.net/listinfo/geeklog-devel
>>
>> _______________________________________________
>> geeklog-devel mailing list
>> geeklog-devel at lists.geeklog.net
>> http://lists.geeklog.net/listinfo/geeklog-devel
>>  
>>
>
> _______________________________________________
> geeklog-devel mailing list
> geeklog-devel at lists.geeklog.net
> http://lists.geeklog.net/listinfo/geeklog-devel





More information about the geeklog-devel mailing list