Comments System
36 views
Skip to first unread message
Will Rossiter
Sep 11, 2010, 10:00:04 PM9/11/10
to SilverStripe Development
Hi,
I was discussing recently the idea of stripping out the built in commenting system from the cms folder into its own module. I would like to hear your thoughts on such a idea and whether it would be something people would be interested in
Key pros:
* Decoupling comments away from pages to dataobjects: I want to change it so comments are tied to dataobjects (instead of pages) and in this particular site we're not even using the CMS (sapphire only) so would be nice to have comments accessible.
* Could publish features, bugfixes and enhancements to comments system without being 'burdened' by the core release process / timelines.
* Lighter default install (well at least for people who don't use comments)
* Current commenting system is tricky to customize. While having it as a module won't make this 'easier', during the module development we can implement extension hooks and allow easier customization.
Key cons:
* Its an extra step (svn:external, download link..) which you would need to do to have comments enabled. The default phpinstaller could include a version of comments module (like googlesitemaps) so making that easy for most downloaders.
* Modules (such as spam protection) can't rely on comments existing so we get even more class_exists()....
So your thoughts?
Mobile: +64 27 389 3454
Office: +64 4 978 7330 ext 58
Skype: will.rossi
Level 5, 97-99 Courtenay Place
Wellington, New Zealand
Office: +64 4 978 7330 ext 58
Skype: will.rossi
Level 5, 97-99 Courtenay Place
Wellington, New Zealand
Matt Bower
Sep 11, 2010, 10:20:55 PM9/11/10
to silverst...@googlegroups.com
I've always been a little frustrated with the built-in Comment system since it is so hard to customize or implement your own. Plus, not every site needs it so it would be less overhead. I'm all for pulling it into it's own module and being tied in via DODs.
One piece of feedback is that I would vote that the module have a more abstracted framework for implementing your own Comment DataModels if you don't like using Name, Website, Message (I'm more of a fan of Name, Email, Message since Emails are unique, everyone has one, and you can block them from commenting if you need to).
Matt
--
You received this message because you are subscribed to the Google Groups "SilverStripe Core Development" group.
To post to this group, send email to silverst...@googlegroups.com.
To unsubscribe from this group, send email to silverstripe-d...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/silverstripe-dev?hl=en.
Hamish Campbell
Sep 11, 2010, 11:22:17 PM9/11/10
to SilverStripe Core Development
+1 Will, although can I add that it might be time to have a rethink
about module management. I know this has been on the cards for some
time, and steps have been taken to get there (SiteConfig is a help),
but dependency management is become an increasing issue, and will only
get worse the more that gets abstracted from the core.
Maybe the move to the comment module could happen with a new module
manager in the core.. good way to show everyone how it's done.
Regards
Hamish
On Sep 12, 2:00 pm, Will Rossiter <w...@silverstripe.com> wrote:
> Hi,
>
> I was discussing recently the idea of stripping out the built in commenting system from the cms folder into its own module. I would like to hear your thoughts on such a idea and whether it would be something people would be interested in
>
> Key pros:
>
> * Decoupling comments away from pages to dataobjects: I want to change it so comments are tied to dataobjects (instead of pages) and in this particular site we're not even using the CMS (sapphire only) so would be nice to have comments accessible.
>
> * Could publish features, bugfixes and enhancements to comments system without being 'burdened' by the core release process / timelines.
>
> * Lighter default install (well at least for people who don't use comments)
>
> * Current commenting system is tricky to customize. While having it as a module won't make this 'easier', during the module development we can implement extension hooks and allow easier customization.
>
> Key cons:
>
> * Its an extra step (svn:external, download link..) which you would need to do to have comments enabled. The default phpinstaller could include a version of comments module (like googlesitemaps) so making that easy for most downloaders.
>
> * Modules (such as spam protection) can't rely on comments existing so we get even more class_exists()....
>
> So your thoughts?
>
> --
> Will Rossiter | Developer
> SilverStripehttp://www.silverstripe.com
about module management. I know this has been on the cards for some
time, and steps have been taken to get there (SiteConfig is a help),
but dependency management is become an increasing issue, and will only
get worse the more that gets abstracted from the core.
Maybe the move to the comment module could happen with a new module
manager in the core.. good way to show everyone how it's done.
Regards
Hamish
On Sep 12, 2:00 pm, Will Rossiter <w...@silverstripe.com> wrote:
> Hi,
>
> I was discussing recently the idea of stripping out the built in commenting system from the cms folder into its own module. I would like to hear your thoughts on such a idea and whether it would be something people would be interested in
>
> Key pros:
>
> * Decoupling comments away from pages to dataobjects: I want to change it so comments are tied to dataobjects (instead of pages) and in this particular site we're not even using the CMS (sapphire only) so would be nice to have comments accessible.
>
> * Could publish features, bugfixes and enhancements to comments system without being 'burdened' by the core release process / timelines.
>
> * Lighter default install (well at least for people who don't use comments)
>
> * Current commenting system is tricky to customize. While having it as a module won't make this 'easier', during the module development we can implement extension hooks and allow easier customization.
>
> Key cons:
>
> * Its an extra step (svn:external, download link..) which you would need to do to have comments enabled. The default phpinstaller could include a version of comments module (like googlesitemaps) so making that easy for most downloaders.
>
> * Modules (such as spam protection) can't rely on comments existing so we get even more class_exists()....
>
> So your thoughts?
>
> --
> Will Rossiter | Developer
Martijn Van Nieuwenhoven
Sep 12, 2010, 3:25:40 AM9/12/10
to silverst...@googlegroups.com
+1 for me.
Its one of the things that I turn off by default, since comments are mostly used for blog or news pages.
I also think abstracting the commentsystem more and tie them to dataobjects is a good thing. In that way you can use it for productreviews or when one have a DO based newssystem add the commentsystem as an extension.
Martijn
Its one of the things that I turn off by default, since comments are mostly used for blog or news pages.
I also think abstracting the commentsystem more and tie them to dataobjects is a good thing. In that way you can use it for productreviews or when one have a DO based newssystem add the commentsystem as an extension.
Martijn
Sam Minnee
Sep 12, 2010, 3:43:25 AM9/12/10
to SilverStripe Core Development
I agree with both points.
Regarding module management, I think a good high level structure would
be:
* An underlying "model layer" for module management, some kind of
object where you can call install / rem methods.
* A set of sake-friendly commands, for things line "sake dev/modules/
add ecommerce"
* A UI for the same; this would be lower priority than the first two
items.
In terms of features, I think we'd want to see:
* Dependency management; ideally we can rely on someone else's hard
work here, at least for the design if not the implementation. Bundler,
from the Ruby folks, might be a good place to start.
* Different installation mechanisms: simple download & copy,
svn:externals, and piston.
* Support for loading in different module indexes, with the default
one running on silverstripe.org.
This might also be a good time to think about allow for interaction
with the webroot filesystem via FTP or SCP, for set-ups where the
webserver user doesn't have write access to the webroot.
I would see this as a 3.0 feature, which will be the next release made
from the current trunk code.
Regarding module management, I think a good high level structure would
be:
* An underlying "model layer" for module management, some kind of
object where you can call install / rem methods.
* A set of sake-friendly commands, for things line "sake dev/modules/
add ecommerce"
* A UI for the same; this would be lower priority than the first two
items.
In terms of features, I think we'd want to see:
* Dependency management; ideally we can rely on someone else's hard
work here, at least for the design if not the implementation. Bundler,
from the Ruby folks, might be a good place to start.
* Different installation mechanisms: simple download & copy,
svn:externals, and piston.
* Support for loading in different module indexes, with the default
one running on silverstripe.org.
This might also be a good time to think about allow for interaction
with the webroot filesystem via FTP or SCP, for set-ups where the
webserver user doesn't have write access to the webroot.
I would see this as a 3.0 feature, which will be the next release made
from the current trunk code.
Nicolaas Thiemen Francken - Sunny Side Up
Sep 12, 2010, 10:31:29 PM9/12/10
to silverst...@googlegroups.com
+1
Definitely a good idea. I dont mind having 20 svn:externals as they are easily added and removed.
Sigurd Magnusson
Sep 13, 2010, 1:28:30 AM9/13/10
to silverst...@googlegroups.com
Sounds like re-architecting it as new module, which is enabled and installed by default, is the plan.
When a module manager is developed it need not be bundled directly.
Social networking and commenting isn't exactly going to go away ... so it'd be great to have this functionality easy to install, but also progress and become richer and better architected :)
Sig
dalesaurus
Sep 13, 2010, 10:20:20 AM9/13/10
to SilverStripe Core Development
+1 for factoring Comments out to a separate (and optional, ie not
bundled with ss.org download) module.
Sam's outline sounds awesome. For recent references I have come
across; Presta Cart has a simple yet effective plugin manager/
dependency system which stays out of the way. Drupal's is more
invasive and less intuitive but makes up for it with drush.
Either way working off another dependency lib is something to consider
since they aren't exactly tailored for SS. For baby steps with SS 3.0
perhaps just declaring a name, version, compatible SS version in an
identifier or meta class would suffice. Then use _config.php to fire
an internal static call to handle the IF version AND
other_module_installed, etc. My $0.02.
bundled with ss.org download) module.
Sam's outline sounds awesome. For recent references I have come
across; Presta Cart has a simple yet effective plugin manager/
dependency system which stays out of the way. Drupal's is more
invasive and less intuitive but makes up for it with drush.
Either way working off another dependency lib is something to consider
since they aren't exactly tailored for SS. For baby steps with SS 3.0
perhaps just declaring a name, version, compatible SS version in an
identifier or meta class would suffice. Then use _config.php to fire
an internal static call to handle the IF version AND
other_module_installed, etc. My $0.02.
Marcus Nyeholt
Sep 15, 2010, 12:23:15 AM9/15/10
to silverst...@googlegroups.com
I've been using a phing build environment as a way to manage required modules, which covers versions and dependencies. The main goal with it being to provide a consistent development environment for anyone who checks a project out of our git environment, and to be able to hook SilverStripe into our Hudson CI server better.
A quick summary of things
- Required module management
- Module version management
- Module dependency management
- Patch management for externally maintained packages
- Various packaging options - Full developer environment, deployment packages for new site installations, update packages containing module + mysite updates, individual module packaging
- Tweaked testing structure to allow for better integration with Hudson (and other CI tools)
There's more info at http://github.com/silverstripe-australia/silverstripe-base/wiki if anyone's interested. It's not overly polished, but gets the job done - though there's still a few things that need to be cleaned up and (functionally) added.
Marcus
Will Rossiter
Dec 7, 2010, 4:28:24 PM12/7/10
to SilverStripe Development
I've published some initial work for the comments module on https://github.com/willrossi/comments
Still needs a ton of work to get it usable but if anyones interested in helping feel free to fork, patch, submit ideas.
Once I get tests up and getting functions working in a solid state I'll remove the existing functionality from cms/trunk and sapphire/trunk (probably wait till SS is all on github)
Cheers
dalesaurus
Dec 10, 2010, 12:03:36 PM12/10/10
to SilverStripe Core Development
Lots of great re-working here! The CommentTablefield is a nice touch
as is the Decorator for notes/tracking. Everything looks well
organized and cleanly separated. Just two things that are glaring to
me:
1. Is SSAkisment being rolled out of the core and in to this module?
I assume that is why it is here as thirdparty
2. Regarding the use of DB::Query with count(*) in the Num****() calls
in the CommentAdmin.php: This could get unweidly as comments grow.
MySQL + MyISAM tables is one of the few stacks that handle count(*)
efficiently. It will be a corner case to have 100k+ rows here but it
is worth mentioning.
Instead of hard coding a SQL count here is there a way to leverage the
ORM to allow the most efficient count to be done for the current
engine? I'm not sure of the Postgresql or MSSQL implementations, but
could it make use of building a DataObjectSet and allowing the ORM to
do an appropriate lazy count for whatever SQL Server is underneath (as
supported)?
Alternatively, the easier solution is to move these counts to an
aggregate table that is updated via cron, trigger, or similar. Maybe
add a 'Refresh Counts' button for the impatient. Either way they are
not critical numbers to have but the queries may cripple the DB in
very large tables.
Of course, I could be entirely overthinking things...
On Dec 7, 3:28 pm, Will Rossiter <w...@silverstripe.com> wrote:
> I've published some initial work for the comments module onhttps://github.com/willrossi/comments
as is the Decorator for notes/tracking. Everything looks well
organized and cleanly separated. Just two things that are glaring to
me:
1. Is SSAkisment being rolled out of the core and in to this module?
I assume that is why it is here as thirdparty
2. Regarding the use of DB::Query with count(*) in the Num****() calls
in the CommentAdmin.php: This could get unweidly as comments grow.
MySQL + MyISAM tables is one of the few stacks that handle count(*)
efficiently. It will be a corner case to have 100k+ rows here but it
is worth mentioning.
Instead of hard coding a SQL count here is there a way to leverage the
ORM to allow the most efficient count to be done for the current
engine? I'm not sure of the Postgresql or MSSQL implementations, but
could it make use of building a DataObjectSet and allowing the ORM to
do an appropriate lazy count for whatever SQL Server is underneath (as
supported)?
Alternatively, the easier solution is to move these counts to an
aggregate table that is updated via cron, trigger, or similar. Maybe
add a 'Refresh Counts' button for the impatient. Either way they are
not critical numbers to have but the queries may cripple the DB in
very large tables.
Of course, I could be entirely overthinking things...
On Dec 7, 3:28 pm, Will Rossiter <w...@silverstripe.com> wrote:
> I've published some initial work for the comments module onhttps://github.com/willrossi/comments
>
> Still needs a ton of work to get it usable but if anyones interested in helping feel free to fork, patch, submit ideas.
>
> Once I get tests up and getting functions working in a solid state I'll remove the existing functionality from cms/trunk and sapphire/trunk (probably wait till SS is all on github)
>
> Cheers
>
> --
> Will Rossiter | Developer
> SilverStripehttp://www.silverstripe.com
> Still needs a ton of work to get it usable but if anyones interested in helping feel free to fork, patch, submit ideas.
>
> Once I get tests up and getting functions working in a solid state I'll remove the existing functionality from cms/trunk and sapphire/trunk (probably wait till SS is all on github)
>
> Cheers
>
> --
> Will Rossiter | Developer
Will Rossiter
Dec 10, 2010, 4:50:52 PM12/10/10
to silverst...@googlegroups.com
1. Is SSAkisment being rolled out of the core and in to this module?
I assume that is why it is here as thirdparty
Yes part of the plan is to strip it out. You will also see that there is no mathspamprotection baked into the comments now. It is it's own spam protection module, which will be released as well so you can use it like you do for mollom / recaptcha.
2. Regarding the use of DB::Query with count(*) in the Num****() calls
in the CommentAdmin.php: This could get unweidly as comments grow.
MySQL + MyISAM tables is one of the few stacks that handle count(*)
efficiently. It will be a corner case to have 100k+ rows here but it
is worth mentioning.
I haven't actually got round to tidying up CommentAdmin yet. One issue with the DataObjectSet count is it has to build that DOS just to get the count which is extremely slow (must more so than a direct DB::query())
Cheers,
--
Will Rossiter | Developer
SilverStripe
Will Rossiter | Developer
SilverStripe
Brice Burgess
Dec 12, 2010, 1:12:42 PM12/12/10
to silverst...@googlegroups.com
Will,
The new commenting system is very exciting -- and already looks to be a
huge improvement. About a week ago we had a client that wanted to filter
[auto-mark as spam] comments based off an internal list of keywords
and/or an IP address. This was fairly trivial to implement under the
current system with the exception of extending the CommentAdmin
interface to allow for filter and notification management -- which was
pushed to the global Site Config (a less ideal/intuitive spot IMO).
Perhaps CommentAdmin can incorporate an extensible DataObject in your
new version that would make something like this easier?
Comment Filter/Notification code is available @
https://github.com/briceburg/silverstripe/tree/master/digome-commentfilter
-- and perhaps useful/usable.
I also see that the Akismet integration is similar to the old. Is there
a reason to avoid submitting the author IP, URL, and email (if
available)? Also it seems more natural for Akismet to exist within the
Spam Protection module(?).
Thanks as ever. Silverstripe is great & getting more-so!
Will Rossiter
Dec 12, 2010, 8:04:51 PM12/12/10
to SilverStripe Development
FYI the comments module has now been moved to the official SilverStripe Github account
I also see that the Akismet integration is similar to the old. Is there a reason to avoid submitting the author IP, URL, and email (if available)? Also it seems more natural for Akismet to exist within the Spam Protection module(?).
Good point, it does seem more useful for general spam protection.
Comment Filter/Notification code is available @ https://github.com/briceburg/silverstripe/tree/master/digome-commentfilter -- and perhaps useful/usable.
Email notifications would be a useful feature to have built in. Patches welcome as always. We will still use trac for issues rather than github just yet and I've created a 'Modules - Comments' component in trac if anyone wants to raise issues, patches etc.
Thanks for the feedback.
Reply all
Reply to author
Forward
0 new messages