Edson Galina Fortes
Forum Replies Created
-
Hi @skagia ,
hope you’re fine ? do you still facing your issue ?Hi,
Thanks for the detailed report — really appreciate you taking the time to trace it down.
To give you some context on the library version: Weglot still targets PHP 7.4 as its minimum requirement, and psr/cache 2.0+ dropped PHP 7 support
entirely. Jumping to a newer version would break compatibility for a significant portion of our users, so we’re intentionally staying on 1.0 for now.As a short-term workaround while we investigate, we have a filter called weglot/skip_contexts that lets you tell Weglot to skip its initialisation in
specific admin screens or pages. If the fatal happens on a predictable screen, that can at least keep the plugins screen stable:add_filter( ‘weglot/skip_contexts’, function( $contexts ) {
$contexts[‘screens’][] = ‘plugins’; // example: WP admin plugins screen
return $contexts;
} );That said, to properly reproduce and test a fix on our end, could you share:
- The name of the conflicting plugin (and ideally its version)?
- The exact screen or action that triggers the fatal (plugins page, a specific admin page, frontend, etc.)?
- The full error trace if you have it? With that we can set up the same environment locally and look at the best path forward.
Thanks again!
Hi @webmark487 ,
thanks for the feedback and the solution.
There may be a more precise approach. While excludingwp-admin/admin-ajax.phpworks in your case, it applies globally and prevents all AJAX requests from being translated.A better solution is to selectively exclude specific AJAX actions using the
weglot_ajax_no_translatefilter. For example:add_filter('weglot_ajax_no_translate', function($actions) { $actions[] = 'my_custom_ajax_action'; $actions[] = 'another_action_to_exclude'; return $actions; });This allows you to prevent translation only for targeted AJAX actions instead of disabling it entirely.
To identify the relevant action name, inspect the AJAX request payload in your browser’s developer tools (Network tab). Look for the
actionparameter sent with the request.Regards
- This reply was modified 1 month, 3 weeks ago by Edson Galina Fortes.
hi @yusefclass do you still facing your issue ? may i can help you ?
Hi @yusefclass ,
Thanks for your message! To better understand what’s going on, could you please share a URL where we can see the issue?
In this kind of situation, there are a few possible causes:
- It might be a parsing issue where the widget content isn’t detected correctly, in which case we may need to add a specific filter.
- It could be related to asynchronous content that isn’t translated by default.
- Or the element might be excluded from translation.
If you prefer, you can also reach out to us at [email protected] and mention this thread. That will make it easier to exchange URLs and investigate further.
In any case, we’ll make sure to update this thread with any findings.
RegardsHi @oluwatemilorun ,
Thanks again for your reply – we’re always happy to help!
If you’re happy with the support you received, would you mind leaving a quick review on WordPress?
We’d really appreciate it – your support means a lot to us and helps others discover Weglot too. 😊
Thanks a lot in advance, and have a great day!
Hi @oluwatemilorun ,
hope you’re fine? Do you still facing your issue ? don’t hesitate if you need more help
regardsHi @oluwatemilorun ,
hope you’re fine? Sorry for the issue you’re facing.The fatal error comes from a missing class
WeglotLanguages\Languages, which is expected to be autoloaded from:vendor/weglot/weglot-php/node_modules/@weglot/languages/dist/Languages.phpThis file is part of the Weglot PHP SDK dependency tree. Since it resides inside a
node_modulesdirectory, it is often excluded during deployments or migrations (e.g. via.gitignore, rsync filters, or CI pipelines).As a result, the Composer autoloader cannot resolve the class, leading to the fatal error.
Please verify that the file exists at the expected path. If it is missing, the recommended fix is to reinstall the plugin from the official source:
https://downloads.wordpress.org/plugin/weglot.5.4.zipThis will restore the full vendor tree, including the embedded
node_modules.For clarity: Weglot is fully compatible with PHP 8.3, so this issue is not related to PHP versioning but strictly to missing files.
don’t hesitate if you need more help
Regardsno worries, take your tme, you can add the version including staticCache here : https://we.tl/t-BKvgakKjdb
RegardsHi @comotive ,
are you able to test the version i provide ? Tell me if you need me to resend it.
RegardsI can’t edit my previous message, please test this version : https://we.tl/t-7palGPJrMJ
RegardsHi @comotive ,
are you able to test this version of the plugin : https://we.tl/t-7FAugGBLPH
i’ve just make a POC adding devicedetectorcaching feature.
Let me know if it’s better
RegardsThanks for the feedback 😉
Indeed, we had a manual user agent list and we switched to a library to have an up-to-date and maintained list, and I haven’t measured the impact. I’ll open the issue on my end to add caching or see if a lighter library is available. It will probably be released in 5.5 and not 5.4.
Regardsthank for the reply, keep me in touch if you need some help, i’ll keep the thread open for the moment.
Regards 😉Hi @comotive ,
hope you’re fine. Sorry for the issue you’re facing and thanks for the feedbacks it’s help. We planned a release of the 5.4 next week, but you can test the beta version here and tell me if you still see your massive increase : https://we.tl/t-DpGgB8gMRg?
On my side i’ll compare the 2 versions (5.2/5.3) code change on the repo to check what update can explain the increase your faces
regards