[ZendTo] Patch for recaptcha and tne new_dropoff.js problem (for the beta)
Jules
Jules at Zend.To
Thu Sep 3 16:26:04 BST 2020
Manty,
On 03/09/2020 10:36, Santiago Garcia Mantinan wrote:
> Hi!
>
> I'd like to make you a new suggestion and also comment on your mail.
> The suggestion would be this:
>
> --- templates/header.tpl 2020-09-03 10:17:32.884356266 +0200
> +++ templates/header.tpl~ 2020-09-02 10:06:14.000000000 +0200
> @@ -184,7 +184,7 @@
> name: 'localeForm',
> id: 'localeForm',
> method: 'post',
> - action: '{call name=hidePHPExt t='changelocale.php'}',
> + action: '{$zendToURL}{call name=hidePHPExt t='changelocale.php'}',
> enctype: 'multipart/form-data',
> style: 'display:none'
> }));
>
> I have tested this change and it works, I'm having the external site
> redirect you to the internal URL if you are coming from the intranet
> and without that change I was redirected to the external site again
> every time i switched locale, with this change I stay inside without
> any problem.
That change is already done. I think you might be running with an out of
date header.tpl.
I detest the deb method of handling modified config files in package
upgrades. They ask the user, who most likely won't have a clue what the
correct answer to the question is. Just put them both in like rpm does,
and at least give the packager the power to set the default choice!
>
> I also have a question on translations, where should one mail updates
> on them, to the list or to you directly?
Individual text changes, probably just me.
But your next topic definitely needs a thread of its own on the mailing
list. I openly admit the existing zendto.conf constants could be better.
But at the time I didn't know any useful definition of "better", and so
did what I did.
If between you all, you can come up with a better solution that works
for more people and doesn't make it impossible for me (and we need a way
to automatically migrate existing sites in the "upgrade" command), then
I'm all in favour of it.
You guys know far more about this stuff than I do (being a simple
English speaker who has never had to worry about genders of words, among
other things).
> And about translations... I'm adapting all of our translated templates
> because the wording that I can get to doesn't make any sense in
> Spanish or Galician (to which I'm translating) but I've seen similar
> trouble on other languages I understand, the thing is that maybe we
> should start a discussion with translators to see if we can get some
> flexibility with variables for the company stuff, I'll try to
> illustrate this with an example:
>
> I'm using zendto at work, the company should be pretty similar to your
> setup as I work for the Council of A Coruña, well, if I setup the
> variables like this:
>
> OrganizationShortName = "A Coruña"
> OrganizationShortType = "the Council"
>
> Things look a bit odd even in english, but in spanish or similar...
> they just don't go.
>
> Maybe the best solution is to edit the templates like I'm doing it
> already, but maybe we could come up with something better without
> needing too much work on code that would allow this, or maybe there is
> no good way.
>
> Some of the problems I find is with that article, "the Council" in
> spanish is "el Ayuntamiento" which then has contractions if you stick
> it to "users of", which is "usuarios de", as it would make "usuarios
> del Ayuntamiento", but if the company has a femenine article it
> wouldn't make a contraction and so it happens with plural (masculine
> and femenine) and those adjectives would have to get translations as
> well, ... so it is basically very difficult, don't know if it really
> makes sense even to try to make any changes, but maybe we can discuss
> it a bit and try to get to something :-?
>
> Anyway... back to the old email...
>
>> Using recaptcha.net instead of recaptcha.google.com is the change recommended by Google so that the reCAPTCHA service works for users in China, who cannot reach 99% of Google services. Because it's on a separate domain name, China allow that 1 Google service through their firewall.
> Ok then, but you are still using www.google.com on the CurlPost.php, so then...
>
> --- p/opt/zendto/www/ReCaptcha/RequestMethod/CurlPost.php
> 2020-03-04 16:56:42.000000000 +0100
> +++ /opt/zendto/www/ReCaptcha/RequestMethod/CurlPost.php 2020-08-17
> 11:42:15.947472184 +0200
> @@ -40,7 +40,7 @@
> * URL to which requests are sent via cURL.
> * @const string
> */
> - const SITE_VERIFY_URL = 'https://www.google.com/recaptcha/api/siteverify';
> + const SITE_VERIFY_URL =
> 'https://www.recaptcha.net/recaptcha/api/siteverify';
>
> /**
> * Curl connection to the reCAPTCHA service
Well spotted!
Fixed for the next release.
Cheers,
Jules.
Jules
--
Julian Field MEng CEng CITP MBCS MIEEE MACM
'Give a man a fish, and you feed him for a day.
Teach a man to fish, and he'll sit in a boat and drink beer all day.'
- Anon
www.Zend.To
Twitter: @JulesFM
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://jul.es/pipermail/zendto/attachments/20200903/6ad1cacb/attachment-0001.html>
More information about the ZendTo
mailing list