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.
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).
Currently this is a link. Users will expect this link to take them to another part of the page or another page altogether.
There is no indication that it opens or closes an associated form on the same page, nor does it indicate the current state of the “reply to” form.
So, instead of a link, use a button. Add to that button an aria-controls attribute that references the id of the associated form’s container, and an aria-expanded attribute that indicates (true or false) the state of the associated form.
The JS logic didn't account for edge cases like scrolling
to the inserted comment, or attaching the comment in the right sorting logic,
on the right pagination page. It also doesn't show any "loading" indication,
so is bad usability for the majority of users. A standard form submission
does the same job better in this case. Note that this doesn't affect
the ability to moderate/delete comments via ajax.
Replaced 'use_ajax_commenting' with 'include_js',
since its important for behaviour other than comment submission itself,
e.g. showing previews (doesn't work without JS)
FIX Also fix up preview to only output the comment content rather than the whole template.
FIX Hide preview after posting comment.
API Move AllowHtml to field to prevent issues with altering Html configuration after comments have been posted.
FIX If moderation is turned on for commenting, still render comments in preview mode.
