Spam Karma GPL Modifications
Austin Matzko
There hasn't been much activity with Spam Karma GPL since July, but I
think it's a great plugin, and I'd like to get development moving.
Below I've listed some changes I'd like to see. I'm willing to take
the initiative myself to get them done, but I want your feedback
first.
* Remove references to Spam Karma "2."
Whatever the historical reasons were for including the version number
in the name of the plugin itself, I think an application's name should
be independent of its version. Also, since development is proceeding
under new auspices, it would probably be less confusing to release the
next stable version as "Spam Karma, version 3.0," rather than, say,
"Spam Karma 2 version 3.0."
* Use the WordPress HTTP API (since WP version 2.7) instead of calling
curl functions directly
This has the advantage of abstracting requests and allowing a wider
range of host configurations to take full advantage of SK's features.
It has the disadvantage of not supporting versions of WP prior to 2.7.
(I do think that starting with WP 2.8 Spam Karma should support back
to the previous major version of WordPress, which when 2.8 is stable
would mean supporting back to 2.7.)
* Simplify the admin menus and integrate them with the WordPress menu system.
Currently SK2 puts the same parent menu under both "Tools" and
"Settings." In my opinion, it would make more sense to put the
options page under settings and move comment management pages under
"Comments." In fact, with a couple of modifications, the core
WordPress spammed comments page could have most of the features of the
SK2 "recent spam harvest" menu, and the main WP comments page could
offer the SK features currently on the "Approved comments" page.
* Take up Matt Mullenweg's offer to host SK in the official WordPress
plugin repository [1].
We could continue to do the main development on the Google Code site
but check in stable versions to the WP extend site so that users get
automatic upgrade capability.
* Transition the "About" admin page to something more like a
documentation page. The current help links to wp-plugins.net are
dead, and it would be great to have most of the documentation included
with the plugin, maybe even using WP's contextual help menu system.
Perhaps we could move the thank yous to a readme file or the like.
* Follow the WordPress coding practices [2]
This would include things like using capitalized class names,
uppercase constants, etc.
Regards,
Austin Matzko
[1] http://groups.google.com/group/sk2-gpl-dev/browse_thread/thread/8157df8704ca9929#
[2] http://codex.wordpress.org/WordPress_Coding_Standards
Theo
only 2 html files that google thinks are attack sites.
Austin Matzko
> Where can we download this, when I go to the files section there are
> only 2 html files that google thinks are attack sites.
There are no downloads at this point, because there haven't been any releases.
You can check out the code using Subversion. Instructions are here:
http://code.google.com/p/spam-karma/source/checkout
Stephen Rider
Stephen Rider
On Feb 11, 2009, at 4:36 PM, Austin Matzko wrote:
> I'm willing to take the initiative myself to get them done, but I
> want your feedback
> first.
>
> * Remove references to Spam Karma "2."
Agreed. The plugin is "Spam Karma". Not sure we need to jump to 3.0
though. 2.4 ought to be fine.
Oh, we should also change the plugin directory from sk2 to spamkarma
or something....
> * Use the WordPress HTTP API (since WP version 2.7) instead of calling
> curl functions directly
> This has the advantage of abstracting requests and allowing a wider
> range of host configurations to take full advantage of SK's features.
> It has the disadvantage of not supporting versions of WP prior to 2.7.
> (I do think that starting with WP 2.8 Spam Karma should support back
> to the previous major version of WordPress, which when 2.8 is stable
> would mean supporting back to 2.7.)
Fine by me. I don't know HTTP issues that well, but I generally favor
abstraction that adds flexibility. As for supporting older versions,
I think as lone as we leave v2.3 available for download, that's fine.
(We should, however, promote the perpetual "release candidate" to full
version 2.3 status!)
Incidentally, I don't have a problem with releasing a plugin that only
works with the current version of WP, especially if the old version is
still available.
> * Simplify the admin menus and integrate them with the WordPress
> menu system.
> Currently SK2 puts the same parent menu under both "Tools" and
> "Settings." In my opinion, it would make more sense to put the
> options page under settings and move comment management pages under
> "Comments."
I submitted a patch a while back that consolidated the double-menu
item to a single place under "Comments". I'm okay with splitting it,
I guess.
At any rate, if we move it, we have to be careful of the plugins as
well -- for example the email notification plugin creates links to
particular pages, and if you move the page you have to fix that link
as well.
> In fact, with a couple of modifications, the core
> WordPress spammed comments page could have most of the features of the
> SK2 "recent spam harvest" menu, and the main WP comments page could
> offer the SK features currently on the "Approved comments" page.
So... completely integrate it into the standard WP Comments admin
instead of having a separate page for SK? Very cool idea! What wold
be missing from the Spam page (or is that a "we'll know when we try"?)
> * Take up Matt Mullenweg's offer to host SK in the official WordPress
> plugin repository [1].
> We could continue to do the main development on the Google Code site
> but check in stable versions to the WP extend site so that users get
> automatic upgrade capability.
A couple things -- regarding non-compatibility with older versions of
WP as mentioned above: Is there a way to set an update to not run if
it's not a compatible version of WP? If not then that becomes an
issue. Also...
If we host on WP-extend, we first MUST allow for a separate place for
SK plugins. This is, IMO, a failing of WP's auto-update. If a plugin
involves add-on files, they get deleted on update.
This is actually an issue with a couple other plugins of mine. I was
thinking that it might behoove us to create a standard location for
such files, such as /plugins/plugin data/. Thus, SK could look for
"third party" plugins in /plugins/plugin data/spamkarma/
Other plugins could use that same folder for their files -- e.g.
otherplugin could use /plugins/plugin data/otherplugin/. Yes it's a
question of getting other plugin authors to use the same standard, but
I think that a good idea spreads if someone just starts doing it --
and SK is a pretty prominent plugin. :)
> * Transition the "About" admin page to something more like a
> documentation page. The current help links to wp-plugins.net are
> dead, and it would be great to have most of the documentation included
> with the plugin, maybe even using WP's contextual help menu system.
> Perhaps we could move the thank yous to a readme file or the like.
No problem with that. Move the help stuff to the WP help system; move
acknowledgements to the Readme.
> * Follow the WordPress coding practices [2]
> This would include things like using capitalized class names,
> uppercase constants, etc.
Yeah, there's a lot of cleanup needed. Look at my patches -- there
are some that do this kind of thing to an extent.
Nice to see someone paying attention to good old Spam Karma. I've
been meaning to commit some of my changes, but I've never shared
ownership before -- didn't want to step on toes by just committing
anything I'd submitted....
Stephen
--
Stephen Rider
http://striderweb.com/
Xavier Borderie
Ditto, even though I agree with Stephen on the uselessness of going
3.0 unles something truly major happens.
> * Use the WordPress HTTP API (since WP version 2.7) instead of calling
> curl functions directly
I guess that's a must. Why not use the tools at hand.
2.3 remains compatible with previous versions of WP, so I'm fine with
going all 2.7.
> * Simplify the admin menus and integrate them with the WordPress menu system.
100% agree with this.
> * Take up Matt Mullenweg's offer to host SK in the official WordPress
> plugin repository [1].
Seems like an obligatory thing to at least have the stable version on
wp.org, for auto-upgrading goodness.
> * Transition the "About" admin page to something more like a
> documentation page. The current help links to wp-plugins.net are
> dead, and it would be great to have most of the documentation included
> with the plugin, maybe even using WP's contextual help menu system.
Uncertain about this. SK sure needs to have working links from within,
that's for sure, but in-plugin documentation?
Might be useful, yeah.
I'm willing to help work on that.
> Perhaps we could move the thank yous to a readme file or the like.
Awww, they bring me traffic! :)
> * Follow the WordPress coding practices [2]
Fine by me :)
--
Xavier Borderie
Austin Matzko
<wp-ha...@striderweb.com> wrote:
> On Feb 11, 2009, at 4:36 PM, Austin Matzko wrote:
>
> though. 2.4 ought to be fine.
>
> Oh, we should also change the plugin directory from sk2 to spamkarma
> or something....
On Thu, Feb 12, 2009 at 4:32 AM, Xavier Borderie <xav...@borderie.net> wrote:
> Ditto, even though I agree with Stephen on the uselessness of going
> 3.0 unles something truly major happens.
Okay, it sounds like we're agreed to change the name to "Spam Karma"
and just increment the version number. I've gone through and changed
all the instances except the ones for the database table and option
names. For those, I figured that we need first to figure out what to
do about upgrading previous versions' options.
On Wed, Feb 11, 2009 at 11:36 PM, Stephen Rider
<wp-ha...@striderweb.com> wrote:
> At any rate, if we move it, we have to be careful of the plugins as
> well -- for example the email notification plugin creates links to
> particular pages, and if you move the page you have to fix that link
> as well.
That's a good point. Related to this, I'd eventually like to develop
a test suite for Spam Karma, so that every time we make significant
changes we can first run the tests to make sure that there is no
breakage.
>> In fact, with a couple of modifications, the core
>> WordPress spammed comments page could have most of the features of the
>> SK2 "recent spam harvest" menu, and the main WP comments page could
>> offer the SK features currently on the "Approved comments" page.
>
> So... completely integrate it into the standard WP Comments admin
> instead of having a separate page for SK? Very cool idea! What wold
> be missing from the Spam page (or is that a "we'll know when we try"?)
Well, for example, since much of the WP comments admin is hard-coded,
there might be some difficulty integrating bulk bulk spam deletion for
those who have JavaScript disabled. But for the most part it should
be a smooth integration.
>> * Take up Matt Mullenweg's offer to host SK in the official WordPress
>> plugin repository [1].
>> We could continue to do the main development on the Google Code site
>> but check in stable versions to the WP extend site so that users get
>> automatic upgrade capability.
>
> A couple things -- regarding non-compatibility with older versions of
> WP as mentioned above: Is there a way to set an update to not run if
> it's not a compatible version of WP? If not then that becomes an
> issue. Also...
In the plugin repository's readme file, you can specify a minimum WP
version. However, I doubt that WP throws error messages if someone
tries to upgrade to a plugin with an incompatible minimum version.
> If we host on WP-extend, we first MUST allow for a separate place for
> SK plugins. This is, IMO, a failing of WP's auto-update. If a plugin
> involves add-on files, they get deleted on update.
>
> This is actually an issue with a couple other plugins of mine. I was
> thinking that it might behoove us to create a standard location for
> such files, such as /plugins/plugin data/. Thus, SK could look for
> "third party" plugins in /plugins/plugin data/spamkarma/
That would be one way to handle it. Another might be just to have
third-party SK plugins be standalone WordPress plugins. Once they
activate, they check to see if the SK plugin class exists and if so,
extend it, etc.
On Thu, Feb 12, 2009 at 4:32 AM, Xavier Borderie <xav...@borderie.net> wrote:
>> * Transition the "About" admin page to something more like a
>> documentation page. The current help links to wp-plugins.net are
>> dead, and it would be great to have most of the documentation included
>> with the plugin, maybe even using WP's contextual help menu system.
>
> Uncertain about this. SK sure needs to have working links from within,
> that's for sure, but in-plugin documentation?
> Might be useful, yeah.
> I'm willing to help work on that.
I do think we need external resources in addition to internal ones.
I've purchased the SpamKarma.org domain name, and my thought was that
we could set up a development blog, support forum, and documentation
wiki there.
Austin
Peter Westwood
On 15 Feb 2009, at 01:41, Austin Matzko wrote:
>
> On Wed, Feb 11, 2009 at 11:36 PM, Stephen Rider
> <wp-ha...@striderweb.com> wrote:
>> On Feb 11, 2009, at 4:36 PM, Austin Matzko wrote:
>>>
>>> * Take up Matt Mullenweg's offer to host SK in the official
>>> WordPress
>>> plugin repository [1].
>>> We could continue to do the main development on the Google Code site
>>> but check in stable versions to the WP extend site so that users get
>>> automatic upgrade capability.
>>
>> A couple things -- regarding non-compatibility with older versions of
>> WP as mentioned above: Is there a way to set an update to not run if
>> it's not a compatible version of WP? If not then that becomes an
>> issue. Also...
>
> In the plugin repository's readme file, you can specify a minimum WP
> version. However, I doubt that WP throws error messages if someone
> tries to upgrade to a plugin with an incompatible minimum version.
>
Personally, I think we should move all code to wp extend.
It is much better to store all your code in one svn-repo than to have
to keep copying things over from one to another when you want to do a
release.
>> If we host on WP-extend, we first MUST allow for a separate place for
>> SK plugins. This is, IMO, a failing of WP's auto-update. If a
>> plugin
>> involves add-on files, they get deleted on update.
>>
>> This is actually an issue with a couple other plugins of mine. I was
>> thinking that it might behoove us to create a standard location for
>> such files, such as /plugins/plugin data/. Thus, SK could look for
>> "third party" plugins in /plugins/plugin data/spamkarma/
>
> That would be one way to handle it. Another might be just to have
> third-party SK plugins be standalone WordPress plugins. Once they
> activate, they check to see if the SK plugin class exists and if so,
> extend it, etc.
>
SK2 plugins should become standalone plugins.
This would involve a very small change to SK2 itself:
Add a do_action('sk2_plugins_register') call.
And then the plugins themselves just need a standard WP plugin header
and to run the registration call on that action.
>
This will also make it much easier for people to write and distribute
sk2 plugins.
westi
--
Peter Westwood
http://blog.ftwr.co.uk | http://westi.wordpress.com
C53C F8FC 8796 8508 88D6 C950 54F4 5DCD A834 01C5
Stephen Rider
On Feb 15, 2009, at 2:14 AM, Peter Westwood wrote:
> On 15 Feb 2009, at 01:41, Austin Matzko wrote:
>>
>
>> On Wed, Feb 11, 2009 at 11:36 PM, Stephen Rider
>> <wp-ha...@striderweb.com> wrote:
>>> On Feb 11, 2009, at 4:36 PM, Austin Matzko wrote:
>>
>>>
>>>> * Take up Matt Mullenweg's offer to host SK in the official
>>>> WordPress plugin repository [1].
>>
>>> If we host on WP-extend, we first MUST allow for a separate place
>>> for
>>> SK plugins. This is, IMO, a failing of WP's auto-update. If a
>>> plugin involves add-on files, they get deleted on update.
>>
>>
>> That would be one way to handle it. Another might be just to have
>> third-party SK plugins be standalone WordPress plugins. Once they
>> activate, they check to see if the SK plugin class exists and if so,
>> extend it, etc.
>
> SK2 plugins should become standalone plugins.
I hope we're not talking about making all 10 default plugins into
standalones!
Personally I much prefer to not clutter up the plugins admin with sub-
plugins.
It might be worth thinking about putting something into WP core that
allows for plugin hierarchy. Then plugins that do what you suggest
could have a show/hide control for its sub-plugins.
Peter Westwood
On 15 Feb 2009, at 16:43, Stephen Rider wrote:
>
>
> On Feb 15, 2009, at 2:14 AM, Peter Westwood wrote:
>
>> On 15 Feb 2009, at 01:41, Austin Matzko wrote:
>>>
>>
>>> On Wed, Feb 11, 2009 at 11:36 PM, Stephen Rider
>>> <wp-ha...@striderweb.com> wrote:
>>>> On Feb 11, 2009, at 4:36 PM, Austin Matzko wrote:
>>>
>>>>
>>>>> * Take up Matt Mullenweg's offer to host SK in the official
>>>>> WordPress plugin repository [1].
>>>
>
>>>> If we host on WP-extend, we first MUST allow for a separate place
>>>> for
>>>> SK plugins. This is, IMO, a failing of WP's auto-update. If a
>>>> plugin involves add-on files, they get deleted on update.
>>>
>>>
>>> That would be one way to handle it. Another might be just to have
>>> third-party SK plugins be standalone WordPress plugins. Once they
>>> activate, they check to see if the SK plugin class exists and if so,
>>> extend it, etc.
>>
>> SK2 plugins should become standalone plugins.
>
> I hope we're not talking about making all 10 default plugins into
> standalones!
>
The default ones no. Well you could make them into one seperate WP
plugin but I don't think that is necessary.
What is necessary is avoiding losing installed plugins when an upgrade
happens the best way to do this is to enable SK plugins to be WP
plugins which just extend SK
Austin Matzko
<peter.w...@ftwr.co.uk> wrote:
> Personally, I think we should move all code to wp extend.
>
> It is much better to store all your code in one svn-repo than to have
> to keep copying things over from one to another when you want to do a
> release.
That's true, but with the current setup we can do what a number of
people have suggested: have an agnostic Spam Karma core that can be
used with a number of different PHP CMS applications.