Modx packet manager ext-all.js error

0
votes

I have a problem with fresh installed modx site. Package manager stucks at "loading" status.

Sniffing some packets reveals that data exchange goes well, so there is no curl problem or something.

There is ext-all.js error in browser console says: "SyntaxError: expected expression, got '}' ext-all.js:1:41"

Searching modx github for similliar issues, resulted this https://github.com/modxcms/revolution/issues/12093 Is it timezone problem? Have no idea how to test if it is, or how to avoid it. (tried to change timezone and reinstall xampp, takes no effect)

Does anyone have such problems or has a solution?

  • win 8.1 sl, xampp local server
  • curl enabled
  • timezone UTC+3 Moscow RTZ2
  • modx version: 2.3.3-pl
  • compress_css = no
  • compress_js = no

js error fires in all browsers

2
javascriptextjsmodxmodx-revolution
Измени часовой пояс на "Багдад". Если в часовом поясе дело, то поможет. - Vasis
@Vasis, changing timezone does not have effect both on server side and client side - SergeyK
Error fires while handling some kind of XMLHttpRequest in ext-base.js, witch returns response:"{"success":true,"total":"15","results":}" - SergeyK

2 Answers

0
votes

It is a known issue on GitHub (https://github.com/modxcms/revolution/issues/13079). Please change the locale system setting to en_EN for a test. Since that locale produces no UTF8 signs in the output, the error could go away.

0
votes

Since the problem is still unsolved, i'll post some research on it.

The root of problem is the setLocale() php function can't set any utf8 compatible locales under such servers environments as windows 7 for example. So there are errors when converting to json output of locale-dependent functions such as strftime:

strftime('%b %d %Y', 1471864827)
"��� 22 2016"

So fixing this problem "for now" is about changing your server environment, sinсe thre is no solution to get setLocale() work properly with utf8 on windows.

Update:

Exploring my system culture settings with Powershell reveals that global setting locale to English_United States.1252 solves the problem with packet manager for me. But i think it is just a lucky case because calling for exmaple json_encode(strftime("%h", 1471864827)) still returns false due to incompatibility of cp1252 with utf-8, so this setting can be only a dangerous, weird behavior temporal solution.

As far as i know there is no way to install utf8-compatible locale on windows system(that setLocale can use), so there is still no any hack to avoid this error until the bugfix.