victorove

Edit. I tried to use cookie exclusion option, but it seems once you get the cookie cache stops working for that user.

Most probably they are the dates of last edit on particular post, the wordpress’ history of changes function.

The best would be to exclude entire admin panel from translations, we only need to translate the front end.

Hi @quadlayers
You can actually see it on your test website as well. Checking this link in rich test results checker returns, among others, the same error: Invalid object type for field “brand” (optional).

The markup is “brand”:[“MegaTron”,”Your Store Brand”]. I believe since October 1st it should be “brand”:{“@type”: “Brand”, “name”: “MegaTron”}.

From Google support forums.

Hi,

Guidance has changed here recently, before “brand”: “The Brand” was fine, but the recommendation now is to use a brand type. You are also using the product name as the brand, use the actual brand name, so in your mark-up, change:

“brand”:”ageLOC Galvanic Body Trio”,

to

“brand”: {“@type”: “Brand”, “name”: “Nu Skin”},

And that should sort that.

@quadlayers Could you please address this in an update?

What I meant is in the options to limit paths is path like https://example.com/wp-admin a valid path? Because it didn’t work and maybe it would solve the problem.

Same question in different wording: if we do not want the translate press to work in admin section of the website, what address would we type in limit paths?

I am asking because it seems all the date entries are fetched by your plugin directly from the admin panel.

• This reply was modified 3 years, 6 months ago by victorove.

Yes, we use translatepress. Our current solution is to send email notifications written in two languages, but we are looking for a better solution to this.

Muchas gracias @jconti me has ahorrado un trabajo. Lo tuvimos deshabilitado para redsys, pero seguía marcado para bizum. Al desmarcarlo notificaciones llegan sin problema. Un saludo.

Unfortunately with all the plugins disabled (including woocommerce, only translatepress on) and with twenty twenty theme turned on, the translated pages still can be accessed via http. Original version of the page redirects http requests correctly to https.

Puede depender de como realizas las redirecciones. Ahora tenemos un problema con translatepress, porque la página traducida permite conexiones https:// y no debería. Cuando habilitamos forzar el https a nivel de hosting, una opción que permite siteground, notificaciones de redsys dejan de funcionar. De momento lo quitamos y ahora estoy pensando como arreglar el tema de redirigir http a https, voy a probar a nivel de htaccess, pero bueno, esto ya no es relacionado con este problema.

En fin, redirecciones del http a https pueden provocar problemas con notificaciones. ?Por qué? Pues la verdad que no sé, porque no sé como funciona el “https enforce” de siteground, pero es una cosa para tener en cuenta.

Si tienes habilitada alguna opción que fuerza https es cuando fallan las notificaciones.

In addition, we are working on a tool to clean the database build up.

Great to hear that. Right now we are thinking about deleting all the dictionary entries where the target field is empty, but we have to revise it in order to not delete some string that hasn’t been translated yet.

data-no-translation attribute on the HTML

This sounds like a good idea to be honest, but making the content not translatable is a big downside, since it will also affect genuine content that we want translated. We got no idea how TranslatePress fetches those entries at the moment, some of them seem to be captured directly from admin panel. Is it possible to blacklist wp-admin only? We were trying to accomplish it through limiting the paths in plugin’s options, but the dates are still being added to the db. Is https://example.com/wp-admin a valid path?

Is this the exact same problem as the one described on the post you linked?

Yes, I guess it is the same problem. Since the payment plugin sends the order number to the payment processing entity what you see normally is “Pedido XXXX” (our website default locale is Spanish). When the request is sent from /pt/ version of the website TranslatePress’ strings are passed along with the order and it is sent in English (in Portuguese it should say “Encomenda”).

The strings are always the same:

trpst trp-gettext data-trpgettextoriginal=2537 trpen Order trpst /trp-gettext trpen 4185

^This is what is sent, so, not only the strings are sent with the request, it seems the language also defaults to English locale.

Hello. Since it doesn’t work well we haven’t moved the page to live yet, but after troubleshooting and compatibility checks and contacting with the support of WooCommerce Redsys Gateway Light plugin it seems that TranslatePress is causing the problem.

The notification from payment processing entity is normally sent as an array

(
    [Ds_SignatureVersion] => whatever value
    [Ds_Signature] => whatever value
    [Ds_MerchantParameters] => whatever value
)

The notification is received correctly only for the main domain https:\\[domain.com], when payment is done from the translated part of the website, i.e. https:\\[domain.com]\[lang]/checkout/order-pay/ the notifications is sent back to translated version of the website and the array is emptied.

After checking the database for the dictionary there are new entries with php errors, one of them
: array_filter() expects parameter 1 to be array, string given in
which is really strange because with debugging enabled those errors aren’t logged in.

Also TranslatePress adds to the dictionary database entire /checkout/ site creating lots of entries with entire /checkout/ page structure with average length of 35000 characters. Please see here for reference: https://postimg.cc/F7LC5Hgk

• This reply was modified 3 years, 9 months ago by victorove.
• This reply was modified 3 years, 9 months ago by victorove.
• This reply was modified 3 years, 9 months ago by victorove.

Creo que tiene que ver con la manera de como funciona el TranslatePress. Este plugin no crea un contenido por separado como WPML por ejemplo, guarda las frases traducidas en la base de datos y luego muestra estas entradas. Esto significa que para cada cadena de texto se realiza una consulta a base de datos, en la página principal la traducción no ocurre, por lo tanto todo funciona bien. Quizás intenta recuperar traducciones del array con notificación y así lo rompe, porque estos textos no están traducidos y devuelve ”.

Lo he mirado en la base de datos y aparecieron nuevas entradas y creo que este tiene que ver con el problema

: array_filter() expects parameter 1 to be array, string given in

No sé si buscar solución para esto o usar otro plugin para traducir la página. Imposible hacer un debugging, porque cuando habilito el log de wordpress estos errores no aparecen ahí. Ni idea por dónde empezar. Si se me ocurre algo te comento, gracias por todo.

Solo comentar que las notificaciones para dominio principal, sin el /pt/ en la dirección, llegan y se procesan correctamente, la notificación es un array normal, con datos.

Mirando la notificación enviada por RedSys está correcta, tanto para el dominio principal como el /pt/.