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.
On Wed, Feb 11, 2009 at 5:12 PM, Theo <theo.d....@gmail.com> wrote: > 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.
> 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....
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.
<wp-hack...@striderweb.com> wrote: > On Feb 11, 2009, at 4:36 PM, Austin Matzko wrote: >> * 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.... 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-hack...@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.
> On Wed, Feb 11, 2009 at 11:36 PM, Stephen Rider > <wp-hack...@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.
>> On Wed, Feb 11, 2009 at 11:36 PM, Stephen Rider >> <wp-hack...@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.
> 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-hack...@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
<peter.westw...@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.
