Answered Quip with recaptcha V2

I played around with it a little bit more and it's now also posting the comment if the user verifies recaptcha. You can use the recaptchav2 plugin also


In core/components/quip/processors/web/comment/create.php you'll need to find this



and replace it with this:



If you're using recaptchav2 extra then to throw back an error just place the placeholder in your tpl as normal (without the fi prefix ofc).



Side note: I'm personally in favour of doing any kind of validations in the front end using javascript for instant feedback and a better UX.

Although it's now working it is currently throwing a bunch of makeurl() errors in the error log though, not sure why yet. It was doing it both with the recaptchav2 extra and with a custom snippet. If anyone else can shed light on what might be causing that then that would be great. [ed. note: lkfranklin last edited this post 6 years, 1 month ago.]

Quote from: lkfranklin at Mar 03, 2018, 11:45 AM

I played around with it a little bit more and it's now also posting the comment if the user verifies recaptcha. You can use the recaptchav2 plugin also

[[!QuipReply? &thread=`[[*pagetitle]]` &preHooks=`recaptchav2`]]

In core/components/quip/processors/web/comment/create.php you'll need to find this

$quip->preHooks->loadMultiple($this->getProperty('preHooks',''),$this->getProperties(),array(

and replace it with this:

$quip->preHooks->loadMultiple($this->getProperty('preHooks',''),$fields,array(

If you're using recaptchav2 extra then to throw back an error just place the placeholder in your tpl as normal (without the fi prefix ofc).

[[!recaptchav2_render]]
[[!+error.recaptchav2_error]]

Side note: I'm personally in favour of doing any kind of validations in the front end using javascript for instant feedback and a better UX.

Although it's now working it is currently throwing a bunch of makeurl() errors in the error log though, not sure why yet. It was doing it both with the recaptchav2 extra and with a custom snippet. If anyone else can shed light on what might be causing that then that would be great.

Many thanks @LK - we are very nearly there! Just implemented and tested and noticed 2 things which we still need to work on to make sure this is a fully working fix.

1. The quip comment is auto approved when using the method above - it should not be - it should be need to be moderated before its marked as approved - you can see this by viewing the quip comments in the manager - the new comment appears - but is marked as moderated when it has not yet been so. This of course can be resolved by forcing the comment to need moderation by adding the parameter to the quipReply code call so solvable.

And this one is a bit of a must have...

2. The quip comment does not appear in the comments for that blog post for some reason, even after it has been moderated as approved in the quip section of the manager - it appears in the manager in the quip list of comments though...

Thanks so much for your time and expertise on this so far - we are so close to a solution which I and I am sure many others will be hugely grateful if we can crack it!

Cheers,

dubbs.

Hmm I didn't experience that but I was working originally with the custom hook. I'm out at the moment but if you get time try the custom prehook again instead of recaptchav2

Quote from: lkfranklin at Mar 03, 2018, 03:10 PM

Hmm I didn't experience that but I was working originally with the custom hook. I'm out at the moment but if you get time try the custom prehook again instead of recaptchav2

Hi - no the custom prehook doesnt allow the comment to get displayed either... also doesnt work with the 'error' label for recaptchav2 so working less well than the tweaks you suggested most recently...

Something strange going on about the fact that the comments posted using the new method will not display on a blog post - if I go back and use the original method with recaptchav1 they display fine...

Interestingly... The comments made using the new recaptchav2 method DO get listed in the comments list - but not the list that is generated from the list of quip submitted and approved comments... this is strange! [ed. note: dubbs last edited this post 6 years, 1 month ago.]

Looking into this from looking at quip in the Manager - it looks like using the new method means the comments are being stored in a 2nd version of the comments thread for a blog post... so we have 2 versions, one using the quip comment id - e.g. "article-b32-137" and then also a version with the actual blog post title e.g. "Test blog post" - the comments that get placed inside the quip comment id version of the thread will appear if using [[+comments]] to fetch back comments, but not those using the page title... This is the issue I have here... Is there a way to force the [[+comments]] chunk to fetch both comments for the 2 versions of the thread???

So... the issue is as above - just hard coded a thread id and the comment was submitted correctly...

So... the issue seems to be with

Its trying to add comments to a thread using the pageTitle rather than the thread ID... how can I force it to add comments to the thread ID???

UPDATE - I've hacked around this using:

So replace 'BLOGARTICLEID' with the page ID of your blog/articles resource and it will work...

It works great!
Thank you all

Quote from: mediengaarage at Mar 05, 2018, 12:14 PM

It works great!
Thank you all

Glad we could help! - do you want to mark it as answered for others to find the solution from your original question? Thanks

Verified working. Note: because we used

&thread=`thread-[[*id]]` type thread naming, I did not see the issue about the ID, everything seems normal. I think the problem might have come simply from following the verbatim change in the example LK listed, rather than adapting it to your own settings, re creating two versions of the comments.

Thanks a lot, I had to put this off to the very last minute to test because of some unexpectedly heavy activity in another free software project I'm involved in, so I'm glad to report that this works as advertised.

Technically I should submit a patch to quip if there is a place I can do that in modx, I'm still unclear about where the actual repo for quip is. Since it's just that trivial line 90 patch to create.php that should not involve any difficulties. There's no point in leaving that patch out of quip since it won't work with recaptcha 1 any longer.

Something that may not have been clear, I tried it first by just removing the old recaptcha items from the QuipReply snippet call:



and replacing them with:



Everything seems the same, though I should test the disableRecaptchaWhenLoggedIn to see if it works.

Thanks for figuring this one out dubbs and LK.

I can't speak to the use of



because we always moderate our postings, so that remains working fine as far as I can tell. [ed. note: lizardx last edited this post 6 years, 1 month ago.]