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.
The comment DataList filter applies ParentClass = $className - when this
is the base class, it fails to recognise comments for a BlogPost. This
change uses the late class name instead.
- XSS an be stored in a cookie and potentially abused in other ways, so
to prevent this we need to use session instead. This requires the user
to have a session with silverstripe, but this is better than saving
potentially malicious content in cookies. (Also some cookies have
limited length).
@see https://github.com/silverstripe/silverstripe-comments/issues/263
jQuery version was extremely old, and was probably stuck at that as a way
of enabling the frivilous use of entwine on the front end for somewhat
trivial ajax submisions. A mild refactor has taken place to leverage newer
jQuery features, and remove outdated dependencies.
Also accompanying this commit are alterations to the markup to make it
more semantically correct (probably not entirely though), and help with
testing the JS functionality of reply forms (when enabled).
