In articles the de langfiles do not get loaded, see screenshot without buttontexts. After clearing the cache or changing the default language its working fine. But after a while the buttontexts are lost again. As I do not get any error in Chrome’s console I think that the text is not rendered into the markup at serverside.
Anything in the MODX error logs?
Nope. No errors that have to do with articles or languages.
Sounds like something is messing up the cache. Have you got any custom plugins installed?
If not, it might be worth adding as issue to the Articles repo.
Turn on dev. tools in Chrome or Firefox (Ctrl-shift-i). Watch the network tab as the page loads for responses other than 200. And after it’s done loading, check the console for JS errors.
Yes, of course. But none in direct relation to articles.
I already checked the network tab. All files were ok.
I cleared the cache and now the tabs/buttons are ok. The lang.js.php e.g. has the correct entry with ‘articles.article_create’. Maybe it was missing before clearing the cache, I have to wait until the problem comes back. Is it possible, that the articles lang file did not get into the lang.js.php or just with empty entries?
Sorry, I don’t understand the question. What is the location of the lang.js.php file?
connectors/lang.js.php
Where is the connectors directory?
(sorry for late reply, had some days off)
connectors directory is in the modx directory. It has an idividualized name, that is reflected in core/config/config.inc.php. Core directory is outside of modx directory.
That file (connectors/lang.js.php) contains no language strings. It just loads language files specified in the $_REQUEST and makes them available to any running JavaScript. A problem with lang.js.php would cause many missing language strings outside of Articles.
All Articles language files would be in this directory:
core/components/articles/lexicon
So, I now can reproduce the error.
When a user with manager role and restricted rights clears the cache the lang.js.php does not aggregate the articles translations
File in Networktab: lang.js.php?ctx=mgr&topic=topmenu,file,resource,trash,resource,articles:default,quip:default,imageplus:default,mapstv:default,mapstv:default,mapstv:default&action=resource/update
In the Preview all enteries like articles.xxx are missing.
No error are logged.
Clearing the cache as a sudo restores the output and all articles.xxx are in the preview output.
Cannot tell, why a different role should render the lang file differently.
Does the user have empty_cache permission?
Yes, permission is checked in role policy
First, to see if it’s really a permission problem, I would temporarily make the user a sudo user. If that solves it, it’s definitely a MODX access permissions problem.
Second, (assuming that it is a permission problem) just to make sure we can rule it out, does the user have empty_cache permission in the correct context (the front-end context where the user is viewing pages).
One foolproof test of that is a custom snippet on the page with this code:
if ($modx->user->hasPermission('empty_cache')) {
return 'Has empty_cache permission';
} else {
return 'Does not have empty_cache permission';
}
FIWI, I can’t find any reference to lang.js.php anywhere in the Articles code, and the only place I can find where Articles messes with the cache is during resource create and resource update, and as far as I can tell, it never messes with the language file cache. So it’s unlikely that it’s an issue with Articles itself, but rather (maybe) an issue with how MODX refreshes the cache for users with different permissions.
Another thing to try is to create your own plugin attached to OnCacheUpdate that manually deletes the Articles lexicon cache files.
If all that fails: in similar situations, I’ve had to run the manager/index.php file in a debugger (inside PhpStorm in my case, running the file in a browser and switching back and forth between the code and the browser window) and step through the code in both conditions to see what’s happening. A breakpoint in core/model/modx/modcachemanager.class.php at the top of the refresh() method might help. I’d add a line $xxx = NULL; at the top of the method and set the breakpoint there. It’s a huge pain, but sometimes there’s no other way.
Making the user to a superuser solves the problem.
Checking all permission in the policy not.
gives me an error:
Fatal error : Uncaught Error: Call to undefined method modUser_mysql::hasPermission()
did you mean $modx->hasPermission(‘empty_cache’)? Which turns in 1 for the specific user.
[2019-08-28 13:34:07] (INFO @ /www/htdocs/core/model/modx/modaccessibleobject.class.php : 40) Principal 10 does not have permission to load object of class modNamespace with primary key: articles
Bit weird. After modifing the settings I get this in the error logs. 10 is the specific user. But what is the load object of class permission?
Aha. Check for the namespace permission in the relevant context policies. If it’s not there, add it to the Policy Template and make sure it’s checked.
(And yes, I did mean $modx->hasPermission() – my bad.)
Hm. Dont get it fixed, do i miss the point?
In the context I have a group with it’s policy. I used the administrator template for the policy and unchecked some permissions, so all possible permissions should be in the policy. The permission “namespaces” is checked. But still the problem occures. Even when I check all permission. So what am I missing out?