-
-
- 24 Posts
Send PM
I had to reinstall my database after a server crash and now I am getting this when I try to access my home page
(ERROR @ /directory/connectors/layout/modx.config.js.php) Error caching lexicon topic lexicon/en/core/resourceOther pages are fine, as long as I don’t access the home. Back end is fine also. It used to work perfectly before. What could be causing this issue?
Thanks in advance.
-
-
-
- 1,572 Posts
Send PM
Are there any errors in the manager error log? also delete everything in core >> cache via FTP and then retry the home page.
-
-
-
- 24 Posts
Send PM
I tried that, and the above is from the error log. It seems that it’s because of advanced search. Which is weird since I haven’t modified anything.
Quote from: paulp at Feb 15, 2013, 08:31 PM
Are there any errors in the manager error log? also delete everything in core >> cache via FTP and then retry the home page.
-
-
-
- 1,572 Posts
Send PM
Googling the error returns a known bug ( http://tracker.modx.com/issues/7324 ) so it might be worth running through the comments on there
Also what version of MODX, php info, server info might give us a bit more of a clue.
-
-
-
- 24 Posts
Send PM
I am using MODX Revolution
MODX Revolution 2.2.4-pl (traditional)After a little bit more digging, it would appear that this bit of code is what is preventing the page from displaying:
<ul class="advsea-results-list"> [[!getPage@custompaging? &elementClass=`modSnippet` &element=`getResources` &varTotal=`total` &parents=`[[~[[*id]]]]` &depth=`1` &limit=`10` &pageVarKey=`page` &includeTVs=`1` &includeTVs=`2` &includeTVs=`3` &includeTVs=`4` &includeTVs=`7` &includeTVs=`19` &includeTVs=`24` &includeTVs=`29` &includeTVs=`30` &tpl=`chunk.pages` ]] </ul>without it, no issue.
Quote from: paulp at Feb 15, 2013, 08:41 PM
Googling the error returns a known bug ( http://tracker.modx.com/issues/7324 ) so it might be worth running through the comments on there
Also what version of MODX, php info, server info might give us a bit more of a clue.
-
-
-
- 24 Posts
Send PM
actually, this: &parents=`[[~[[*id]]]]` more specifically. I need to retrieve the parent’s id and it doesn’t like it anymore, it would look like.
-
-
-
- 18 Posts
Send PM
Has anyone solved what’s going on here? I too keep on getting the following error in my MODX error log:
(ERROR @ /home/{hosting_account}/{modx_core_path}/model/modx/modcachemanager.class.php : 344) Error caching lexicon topic lexicon/en/core/default
—
Chris Holowatyj
Keddy & Associates — Web Design Professionals
https://keddyandassociates.com
chris@keddyandassociates.com -
-
-
- 24,544 Posts
Send PM
@helene: This is incorrect:
That will sent a *link* to the parent resource instead of its ID.
It should be:
[ed. note: BobRay last edited this post 5 years, 3 months ago.]
-
-
-
- 26 Posts
Send PM
Anynone has solved it? I still have the same error
Quote from: c5j4k5 at Oct 24, 2017, 04:45 PMHas anyone solved what’s going on here? I too keep on getting the following error in my MODX error log:
(ERROR @ /home/{hosting_account}/{modx_core_path}/model/modx/modcachemanager.class.php : 344) Error caching lexicon topic lexicon/en/core/default
-
-
-
- 24,544 Posts
Send PM
I get that «error caching lexicon topic» message occasionally. I’ve never seen an explanation for it.
-
- <
- 1
- 2
- >
One source of this issue would be a lexicon file that does not create a $_lang array.
Put return false; in one lexicon file or create a lexicon file without any content. After clearing the cache, that error message should be triggered. Maybe you have a file like this somewhere in the tree. But the name of the file should be logged.
Sorry this creates a different error message:
[2019-02-13 11:15:49] (DEBUG @ /somepath/core/model/modx/modlexicon.class.php : 259) An error occurred while trying to cache lexicon/de/core/trash (lexicon/language/namespace/topic)
Thank you very much @Jako for this information.
I’ll test/check this soon and will report back.
So in the last 3 days these logs accumulated:
[2019-01-27 18:14:31] (ERROR @ /somepath/www/core/model/modx/modcachemanager.class.php : 349) Error caching lexicon topic lexicon/en/babel/default
[2019-01-28 20:00:04] (ERROR @ /somepath/www/core/model/modx/modcachemanager.class.php : 349) Error caching lexicon topic lexicon/de/mxcalendars/default
[2019-01-28 20:00:04] (ERROR @ /somepath/www/core/model/modx/modcachemanager.class.php : 349) Error caching lexicon topic lexicon/en/batcher/default
[2019-01-28 20:00:05] (ERROR @ /somepath/www/core/model/modx/modcachemanager.class.php : 349) Error caching lexicon topic lexicon/de/core/trash
[2019-01-29 07:40:20] (ERROR @ /somepath/www/core/model/modx/modcachemanager.class.php : 349) Error caching lexicon topic lexicon/en/bigbrother/mgr
I’ve pasted and linked the contents of these files so you can check with me.
The title of the paste-bins are the paths to the files.
To me, these files all seem fine.
Also interestingly in some cases it tries to cache the «en» version,
although the manager and website are set up to «de».
Why is it still logging this error?
What other causes can this error have?
Not saying it’s related, but out of interest, what server stack are you using @sebastian-marinescu ?
Sometimes I experience the same issue. It’s totally random..
I get these all the time too and yes it’s seemingly random. I’d also love to find out what’s causing it.
Could that be caused by file locking?
I have this problem too:
[2019-02-13 14:12:48] (ERROR @ /somepath/core/model/modx/modcachemanager.class.php : 349) Error caching lexicon topic lexicon/ru/core/default
[2019-02-13 14:12:48] (ERROR @ /somepath/public_html/core/model/modx/modcachemanager.class.php : 399) Error caching action map mgr/actions
But I also have Error caching action map mgr/actions
I faced the same odd problem as well. I played around with the lexicons values. It seems to like that some character parsing issues is causing this issue.
Situation 1:
$_lang[‘some_uber_label’] = ‘Hi this is English’;
No caching issues appears
Situation 2:
$_lang[‘some_uber_label’] = ‘Hi this is English isn’t great?’;
Random caching errors
Situtaion 3:
$_lang[‘some_uber_label’] = «Hi this is English isn’t great?»;
So far during testing no caching errors.
It seems to be that the escape single quote is randomly be parsed wrong into the caching file.
Maybe other people can test this as well?
Just woke up to a site which overnight seemed to have a huge error log with these Error caching lexicon topic errors.
Every time I loaded a manager page a lot more of these errors appeared.
- I checked file and directory permissions which were fine.
- Clearing the cache didn’t affect it.
Manually deleting everything inside the cache directory DID fix it (at least for now). Though no idea why.
Hello. is there any progress in solving this issue?
We need a situation where we can reliably reproduce this issue.
This happens, when simultaneous writes into same cache file happen. To reproduce it, you need two concurrent requests to try and write into lexicon (or any other cache).
Default xPDOFileCache lockFile method does not work well, especially with php-fpm multithreaded setups. Even in cases, when instructions follow one-by-one, e. g. is_dir( $pathname = dirname( $filename ) ) || @mkdir( $pathname, 0777, TRUE ) such issues can happen.
Using use_flock option along with custom values for xPDO::OPT_CACHE_ATTEMPTS and xPDO::OPT_CACHE_ATTEMPT_DELAY in system/context settings can reduce number of errors to almost zero.
https://github.com/modxcms/revolution/blob/53c9fdd4ece5ae0a9cffd00477ba93af931020a0/core/xpdo/cache/xpdocachemanager.class.php#L233
This error level can be changed to xPDO::LOG_LEVEL_WARN, because eventually a cache file is written anyway by one of the threads.
@JoshuaLuckers It’s not easy. I’ll try to describe the problem. When you refresh the manager page many requests are sent. If lexicon cache is empty (for example, after changing any system setting) the modCacheManager try to renegerate the cache for all topics. And in some cases, the cache managers from different requests try to create a file for the same topic.
I think the lazy regeneration of lexicon cache will solve the problem. And the level of this error have to be changed to Warn level.
The default locking only works on systems that have flock available. If you are working with a filesystem that does not support flock, such as a shared network volume, you need to disable the use_flock setting. Regardless, the error message usually means that another thread is regenerating the cache already and any new ones that have not acquired a lock while it is being generated have been prevented from writing the cache simultaneously.
Default xPDOFileCache lockFile method does not work well, especially with php-fpm multithreaded setups. Even in cases, when instructions follow one-by-one, e. g.
is_dir( $pathname = dirname( $filename ) ) || @mkdir( $pathname, 0777, TRUE )such issues can happen.Using
use_flockoption along with custom values forxPDO::OPT_CACHE_ATTEMPTSandxPDO::OPT_CACHE_ATTEMPT_DELAYin system/context settings can reduce number of errors to almost zero.
https://github.com/modxcms/revolution/blob/53c9fdd4ece5ae0a9cffd00477ba93af931020a0/core/xpdo/cache/xpdocachemanager.class.php#L233This error level can be changed to xPDO::LOG_LEVEL_WARN, because eventually a cache file is written anyway by one of the threads.
Thank you _very_ much @wfoojjaec for shedding some light on that matter!
I’m also voting for changing it to a warning, as it is not a real error.
#1
Отправлено 21 Сентябрь 2012 — 14:12
Здравствуйте, коллеги!
Редактировал в блоге статью, после сохранения на странице появился код (в админке в редакторе его нет):
Array
(
[tpl] => blogPostTpl
[tplOdd] =>
[tplFirst] =>
[tplLast] =>
[sortby] => publishedon
[sortbyTV] =>
[sortbyTVType] => string
[sortbyAlias] =>
[sortbyEscaped] => 0
[sortdir] => DESC
[sortdirTV] => DESC
[limit] => 5
[offset] => 0
[tvFilters] =>
[depth] => 3
[parents] => 6
[includeContent] => 1
[includeTVs] => 1
[showHidden] =>
[showUnpublished] =>
[showDeleted] =>
[resources] =>
[processTVs] => 1
[tvPrefix] => tv.
[idx] => 1
[first] => 1
[last] => 5
[toPlaceholder] =>
[toSeparatePlaceholders] =>
[debug] =>
[where] =>
[namespace] =>
[page] => 1
[pageVarKey] => page
[totalVar] => total
[pageLimit] => 5
[elementClass] => modSnippet
[pageNavVar] => page.nav
[pageNavTpl] =>
[pageActiveTpl] =>
[pageFirstTpl] =>
Первая
[pageLastTpl] =>
Последняя
[pagePrevTpl] =>
<<
[pageNextTpl] =>
>>
[cache] => 1
[cache_key] => resource
[cache_handler] => xPDOFileCache
[cache_expires] => 0
[element] => getResources
[hideContainers] => 1
[total] =>
[cachePageKey] => web/resources/6/1/d41d8cd98f00b204e9800998ecf8427e
[cacheOptions] => Array
(
[cache_key] => resource
[cache_handler] => xPDOFileCache
[cache_expires] => 0
)
[id] => 54
[type] => document
[contentType] => text/html
[pagetitle] => название
[longtitle] => название
[description] => название
[alias] => название
[link_attributes] =>
[published] => 1
[pub_date] => 0
[unpub_date] => 0
[parent] => 33
[isfolder] =>
[introtext] =>
[content] =>
А в журнале ошибок появилось сообщение:
[2012-09-20 16:18:19] (ERROR @ /connectors/element/index.php) Error caching lexicon topic lexicon/en/core/default
[2012-09-20 16:18:19] (ERROR @ /connectors/element/propertyset.php) Error caching lexicon topic lexicon/ru/core/default
Версия MODX revolution 2.1.1-pl
Помогите разобраться, пожалуйста!
- Наверх
#2
rech
Отправлено 21 Сентябрь 2012 — 14:31
maraleks (21 Сентябрь 2012 — 14:12) писал:
…
Версия MODX revolution 2.1.1-pl
….
Оффтоп, конечно, НО:
revolution — унылое говно, Evo — рулезз.
А так, посмотрите, не кончилось ли у вас место на диске и не изменились ли каким-то образом chmod к папкам кеша и т.д. + не сбойнула ли файловая система при записи.
- Наверх
#3
maraleks
TC
Отправлено 21 Сентябрь 2012 — 15:08
rech (21 Сентябрь 2012 — 14:31) писал:
А так, посмотрите, не кончилось ли у вас место на диске и не изменились ли каким-то образом chmod к папкам кеша и т.д. + не сбойнула ли файловая система при записи.
Вроде бы всё в норме, откуда косяк вылез хз 
- Наверх
#4
rech
Отправлено 21 Сентябрь 2012 — 15:14
maraleks (21 Сентябрь 2012 — 15:08) писал:
Вроде бы всё в норме, откуда косяк вылез хз
ну логи говорят об ошибке кеширования… так, что смотрите в ту сторону…
- Наверх
#5
Sonya*
Sonya*
1 056
- Из(GMT + 1:00)
Отправлено 21 Сентябрь 2012 — 15:29
Текст статьи удалите и пересохраните, если ошибка исчезнет после этого, то в статье ищите специальные символы, типа { или ~ или ] или ….- это от них.
«Щоб не плакать, я сміялась» ©
- Наверх
#6
maraleks
TC
Отправлено 24 Сентябрь 2012 — 11:55
Sonya* (21 Сентябрь 2012 — 15:29) писал:
Текст статьи удалите и пересохраните, если ошибка исчезнет после этого, то в статье ищите специальные символы, типа { или ~ или ] или ….- это от них.
Не помогло 
- Наверх
#7
azsx
Отправлено 24 Сентябрь 2012 — 18:33
возможно ваша проблема описана здесь
надо сперва очистить кеш, а потом попробовать восстановить файлы из архива (+ настроить разрешения) и восстановить базу (если файлы не помогут)
http://forums.modx.c…p?topic=57192.0
- Наверх
topic» разного рода, в том числе «… lexicon/en/core/default» и «… lexicon/ru/minishop2/default». Как победить сие?
russian
programming
software
modx
05:13 04.09.2019
1
ответов
Будет исправлено в 2.7.2
05:14 04.09.2019