tobiaswinter

Hi,

I just deleted another bunch of 114000 of those decoded captcha images from my database after getting information from my backup plugin that my backup storage is running out of space…

So I just wanted to ask if you have any idea on where those image strings find their way into the database?

Thanks.

I confirm that the bug is fixed – Thankyou! ??

Regarding the images stored in the database I’ll create a new bugreport for not mixing things up.

Hi Marc @forge12,

thanks for your update and motivation to debug and improve the plugin!

In fact, I found another issue were terms from this plugin get stored in my database that I want to share with you. I use the Captcha Image method and all the images are stored in my translation database table like this:

data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAAH0AAA…

the full decoded image is saved, I only post the beginning here.

I searched the code but I was not able to identify the place where this happens. Before I dig deeper into it I’d like to ask you if you have a clue where the captcha plugin does something with this string that could make TranslatePress via hook etc. believe that this is a translatable string?

With kind regards, Tobias

Hi Mamunur,

thanks for your fast reply. Looking at your screenshot about the upcoming fix I wonder why ?Gallery With (medium device)“ is the only one left with pixels instead of %, this is still a little bit confusing. But may be the other % values refer to this absolute width? Or to what value does the % refer?

Also, the text still mentions ?in pixel“ instead of ?in %“.

• This reply was modified 1 year, 1 month ago by tobiaswinter.

I’ve tried my very best, but there’s always a 404 error when submitting my topic to your support forum.

https://villatheme.com/supports/topic/test-2/

Thank you @diegoversiani for your quick reply!

I’ve already tested and it works as indicated, deactivating the button until last step.
I’m even able to completly hide it if I want using this CSS:

/* FluidCheckout Hide Button */
.fc-wrapper .wc-gzd-order-submit {
	display: none;
}
.fc-checkout-step-current--payment .fc-wrapper .wc-gzd-order-submit {
	display: block;
}

I consider my request as solved. Again thank you very much for this great plugin!

Hi @alexcozmoslabs,
thanks for letting me know. This is perfectly understandable, as I’ve actually other issues with Translatepress with higher priorities.
Thank you for the information about the effects of the “Disable post container tags for post title” setting. So I know I can use that but I may implement another solution to workaround the issue with glossary.

Thank you!

Hi @diegoversiani,
thank you for letting us know a solution is in the works, that is higly appreciated!

I use the setting “Use theme’s page header and footer” so this way I have all legally required links and information without having to manage another block. A good solution for @redorca would probably to be able to set “Use theme’s page footer only”.

Hi @redorca,
I’ve already posted the same problem and my idea of a possible solution here:
https://www.ads-software.com/support/topic/disable-place-order-button-when-not-in-last-step/

I too hope it will be implemented soon. Implementing an additional CSS class to hide the button depending on the current step shouldn’t take too much time…

WPML or Polylang do have different concepts for translation and they often have limitations what can’t be translated. For example, Polylang does not allow to translate non-global product attributes in WooCommerce. This is the reason why I use Translatepress. It just tries to translate everything.

As example if you need to do a wp_query and print all the title of a post somewhere else everything won’t work.

Not quite right, because if you print that out on the webpage, Translatepress will take care of those <trp-post-container data-trp-post-id=’1617′> tags later on, filter them out and use the information it has put in there before to find the right translation in the translation database.
The only issue is when it’s not printed on the webpage but used in the code (of Glossary in this example) to match possible terms in a text with it.

I think we agree here that it’s not the fault of Glossary or Glossary doing anything wrong, it’s just the fact that it’s not working out of the box right now and the Translatepress authors should find the right place to fix that. May be you can help and add a filter or something (for example a filter so one can replace the_title with a custom function to deliver the title of a given post instance), so in the end customers are happy, but first let’s see what they say, my post is here:
Translatepress Support Forum

Hi,

A side note to take into account: while emails that get sent after a user action are translated correctly, out of order emails like reminders (if you use subscriptions) will always be sent in the default language as we don’t store the user language in order to know in what language we should send the email.

There is a solution for that:

https://gist.github.com/dartrax/85b3ab77b8210e92cc50e1b68de83c73

Hi Daniele,
as promised, I’ve looked into the code to find the problem.

In the function do_wp_query() (Terms_List.php, line 139) you create a Query to get all the glossary posts. The term is retrieved by \get_the_title(); inside the loop of that query (line 150).

With Translatepress enabled and being on a tranlated page, Translatepress filters the title via its wrap_with_post_id function (class-translation-render.php) where it adds some additional tags. So the post title “my-Term” gets filtered to “<trp-post-container data-trp-post-id=’1617′>my-Term</trp-post-container>”. Then, you build a regex with this value to find this term on the current page, but of course that is never found.

There are several possibilities to fix this:

• Check “Disable post container tags for post title” in Translatepress’ Advanced settings tab. This removes the filter globally. Currently I don’t know what sideeffects this has since it affects all post titles, not only glossary terms. However, with this option checked, Glossary perfectly works together with Translatepress. All Terms, term content and so on can be translated, even translated terms will be matched correctly.
• Translatepress tries its best to avoid this situation. For example, it checks if the query is the main query or if the post id matches the global $post id. Unfortunately, Translatepress can only check the global $wp_query if that’s the main query, and it is, because you use a secondary query. The other way around is true for $post id, since the global $post gets overwritten with the glossary term post, the ids do match. You can see those checks in the wrap_with_post_id function. I don’t know wordpress good enough to judge if there is anything that should be fixed in your code that will make one of those Translatepress checks work.
• Ask Translatepress to implement another check or compatibility functions. I’ll reference this post in their forum.
• I can use your glossary_terms_results filter to remove all the Tags Translatepress added before. However, I would also need to fix the regex. Performance-wise removing what was added earlier seems not to be a good idea.
• I can add another filter to the_title which removes the Translatepress modifications if it’s a glossary post type. That would need to be checked in every call of the_title. Not ideal.
• I can use your glossary_custom_terms filter to implement my own Query without using the_title hook at all (or at least remove and readd the Translatepress filter before and after). Performance-wise this should be the best option, when the first point on this list fails.

Do you have any other ideas?

Hi Daniele,
thanks for the explanation.
I’ll take a look into the code and figure out why it doesn’t work. I’ll report back in a few days.

Hi Daniele,
thanks for your fast reply.

I think you might be misunderstanding what Translatepress refers to in this sentence. This only affects the translation input which happens on the frontend.
The output of (translated) text later on happens server side.

Do I don‘t think this is s showstopper of a Translatepress compatibility.
Also, all other plugins that I‘ve tested do work (more or less) with Translatepress, like Tooltips by Tomas, CM Tooltip Glossary, and a third one I can‘t remember any more.

I hope you can take a look at Translatepress again and tell if a compatibility is possible.

Thanks!

Hi, that are great news! Thanks, looking forward to it!