This allows both pages and DataObjects to have comments without the ParentID clashing and showing comments on a page where the ParentID is the Same as a DataObjects or even two DataObjects having the sameID
This allows both pages and DataObjects to have comments without the ParentID clashing and showing comments on a page where the ParentID is the Same as a DataObjects or even two DataObjects having the sameID
Previous versions had individual spam and approve buttons for a comment
in the admin area on the GridField row. However with the upgrade to
SilverStripe 4, and particularly 4.2, these were having layout issues
with the new GridField Action Menu component that groups actions
together.
The solution here is to put them into aforementioned gridfield action
menu component, with the other actions for that row. However this
requires two separate grid field components (one each for the two
comment actions) - previously these were a single component that output
two buttons instead of one each. This also reduces coupling, which is
nice :)
The previous class is still maintained for backwards compatibilty, but
is deprecated.
When posting a comment on the a page with this module applied, there is
an optional input for the commenter to give their URL,presumably their
website. However this input currently validates (via JavaScript) to
allow URLs only iff they have a protocol.
Common use cases when someone is asked for their website in my
experience is to then receive a URL without a protocol, confounded in
that most web browsers will accept this form and automatically add the
http protocol, where a webserver may then redirect to https by default.
This means that all the magic happens behind the scenes and most folks
don't particularly care to think about protocols when entering web
addresses.
Yest this input will only validate true and allow comment submission if
they do.
So now it will allow a protocol-less entry into the URL box.
Anonymous comments (posted by the public at large) must have a name
and an email address associated with them. On the other hand, a logged
in user will have the `Member` record details used for this information,
via the Author relationship.
However the summary fields do not allow for this, and only reference
Name and Email on the Comment model directly, so any comment posted by a
logged in member has no data for name and email displayed in the various
GridFields in the CMS for administering comments (either per page, or in
the global ModelAdmin).
To recitfy this we can change the summary fields to use getter methods
that will return the Comment model info, or fall back to the Author
associated Member record if Name and Email are unset on the Comment.
