Is it only the folder in assets/components that is missing?
Was the folder core/components/babel created successfully during the installation?
Does the assets folder have the correct file permissions?
Were there error messages during the installation?
Yes
Yes
Earlier it was 705, and I made it 755 now and reinstalled but the same issue.
And during the installation, I didn’t see any error.
The transport package doesn’t seem to be the problem. (It works correctly when I test it.)
My guess is still, that it is a permissions issue. Maybe the folder assets/components has the wrong permissions.
I see that other extras (like FormIt or MIGX successfully copied their files to the assets folder during install. Did you change the server in the meantime?
If nothing else works, you can copy the files manually.
You should find the files in the core/packages/babel-3.1.1-pl folder. (Probably in core/packages/babel-3.1.1-pl/modCategory/e1e644a285e24cb56cca047c794970c3/0/
Or alternatively load them from Github.
@halftrainedharry
I have changed the directory permission and the files have been loaded but showing an error in the console.
Most likely it’s this bug in Babel (that hasn’t been fixed yet):
@halftrainedharry
Still showing the same error.
Did you do a “hard refresh” (or alternatively clear the browser cache), so that the changed JS-file gets used?
@halftrainedharry
My apology, It’s working now.
-
But when I click on the Babel link to see another language page it redirects me to the homepage
-
And the page which is not linked doesn’t display the Babel language label. eg:EN/DE.
I need to display all language contexts if there is no translation page this should redirect to the default version.
Thanks.
This sounds more like a problem with your router plugin and not with Babel.
Make sure that you can successfully request all the resources (in all the contexts) by clicking the “View” button in the manager.
In the “en” context, can you request a resource from this context directly? What’s the URL?
When you click the Babel link (that redirects to the homepage), how is the URL different from the correct URL?
Should go to this link but doesn’t go.
https://www.dentallabor-koenig.de/en/for-dentists
If you go to the “for-dentists” page and click the “View” button, does it open the same URL? Is the page visible or does it also give a 404 error (like for the URL you posted above)?
To debug problems with the routing plugin, maybe add some code in the plugin “switchContext” to log the request information (the parameters “cultureKey” and “q” and whether the context was switched) to the MODX error log. This could help you understand what’s happening.
Consider also adding a context setting error_page to the “en” context, to make it clearer that an error occurred.
It gives a 404 error.
I don’t know where to write and where to check.
I added but that didn’t work. That’s why edited the system settings.
It will also be great if you help me to set the error page for different languages
With your current setup, when you call
https://www.yoursite.de/en/for-dentists
this request gets rewritten in the .htaccess file to
https://www.yoursite.de/index.php?cultureKey=en&q=for-dentists
using the rule RewriteRule ^(de|en)?/?(.*)$ index.php?cultureKey=$1&q=$2 [L,QSA]
In the routing plugin “switchContext”, based on the request parameter “cultureKey”, the context gets switched.
Later the request parameter “q” is used to find the correct resource to display.
You can add log statements to the code in the routing plugin to check if the request parameters are correct.
For example lines like these (at the top of the code)
if($modx->context->get('key') != "mgr"){
$modx->log(modX::LOG_LEVEL_ERROR, "cultureKey = {$_REQUEST['cultureKey']} | q = {$_REQUEST['q']}");
}
log the request parameters “cultureKey” and “q” to the MODX error log.
Make a request, then check the error log to see if the values of “cultureKey” and “q” are as expected.
Also (temporarily) replace the line $modx->switchContext('en'); with code like this:
$success = $modx->switchContext('en');
if ($success) {
$modx->log(modX::LOG_LEVEL_ERROR, "switched to context 'en'");
} else {
$modx->log(modX::LOG_LEVEL_ERROR, "Unsuccessfully tried to switch to context 'en'");
}
This logs whether the context was successfully switched.
MODX uses the “q” request parameter to find the correct resource.
Check the column “uri” of the database table modx_site_content for the requested resource, to make sure that the values of “q” and “uri” are the same.
The error_page system setting is for all the contexts. If you add a context setting error_page, then it overwrites the system setting (with the same name) for this context.
If you don’t see the correct context error page, then probably the routing plugin didn’t switch the context correctly.
I downloaded the log file from Manager -> Reports -> Error-log and imported in the Chrome extension.
Actually, I don’t know how to view the log file or how to debug it.
Is this possible to debug using print_r() or var_dump()?
The issues I am facing are going to be harder for me to solve.
I asking you repeatedly that may bother you but I need your assistance.
You don’t need a Chrome extension. It’s just a text file. You can open it in any Editor you like.
The error messages in the screenshot are from October 2023. (They’re probably not that interesting anymore.) Go to the end of the file to see the latest messages.
Or even better (now that you have downloaded the error log), click the “Clear” button (in “Manage” → “Reports” → “Error log”). Make the request (for en/for-dentists) on the front-end and then click the “Refresh” button. (If the size of the error log is small enough, the messages are directly displayed in the page and you don’t have to download the log file.)
Also, the code
$success = $modx->switchContext('en');
if ($success) {
$modx->log(modX::LOG_LEVEL_ERROR, "switched to context 'en'");
} else {
$modx->log(modX::LOG_LEVEL_ERROR, "Unsuccessfully tried to switch to context 'en'");
}
should be integrated into the code at the position where $modx->switchContext('en'); is executed. The way you have it now, the context always gets switched to en.
It might be easier to use a proven solution like LangRouter, instead of this custom solution (you probably copied from somewhere). Especially if you’re not that familiar with coding in PHP/MODX.
(If you decide to use LangRouter, make sure that you change the line
RewriteRule ^(de|en)?/?(.*)$ index.php?cultureKey=$1&q=$2 [L,QSA]
in the .htaccess file back to the initial state.)