Hi Everyone,
We've just installed a shiny fresh 2.7.1+ moodle onto Apache 2.4 on CentOS 7, using the latest PHP 5.4 and Postgres 9.2.7 (all firmly supported by all the docs we can find).
What we're seeing is lots of JSON related failures.
Has anyone else seen this, and knows the quick fix? Is this a library version thing in php-common?
We can't even view users that are enrolled onto courses until we fix this, which is a pain.
Many thanks,
--Rob.
Which errors and doing what?
Yes , that all sounds fine so what are the steps to reproduce your issue?
Hi Howard,
I login as a Site Admin, then click on Site Administration -> Users ->
.... UGH. The other annoying problem is now hitting me. I can't expand the Site Administration menu. It changes the triangle to a downwards triangle, but doesn't display any of the sub-menu options. Thius happens in Chrome and IE 10.
To continue (from memory), ...
Site Administration -> Courses -> Manage courses and categories
I then select a category, then a course. From the View/Edit/Enrolled users/Delete/Hide/Backup/Restore menu I select "Enrolled users".
It displays the currently enrolled users (there are 4), then produces the "SyntaxError" dialogue (I'm in IE10, so not getting the more helpful JSON error that Firefox provides).
I suspect, and hope, that the Site Administration phantom menu disappearance is related in some way to AJAX and Javascript processing of XML to/from the database. I am totally new to moodle, but a fairly competent PHP and Java guy. Would really appreciate some hints on where to look ...
Many thanks,
--Rob.
Hello Rob,
Regarding the links of the amin block not expanding, please see:
https://docs.moodle.org/27/en/Blocks_FAQ#My_Administration_block_links_don.27t_expand.21
Guillermo,
Hi - thanks for that link.
I've twiddled with most of it, but I'm still getting missing Administration blocks.
If I disable Javascript, it jumps me straight into "New Settings - LDAP enrollments", with no way to view any other Administration entries.
I can "fix" it sometimes by blowing away the entire cache in the IE10 browser, and logging in again, but that isn't a reliable fix and therefore not a service I can take "live" for users.
Utterly stuck with this
Thanks,
--Rob.
Nope - the sandbox deployment works just fine in my fully updated Chrome browser (as it should).
Aaaargh! So ... this is starting to look pretty bad for "enterprise deployment" folk using CentOS 7 with its standard deployment of Apache 2.4, PHP 5.4 and Postgresql 9.2.1.
Surely this shouldn't be this hard? Is there some "mass compare" I can do against the sandbox site, to see where it differs? As the sandbox is the latest stable version, that should be 2.7.1+, right?
Cheers,
--Rob
FYI - I am running a newer 2.7.1+ (Build: 20140821) compare to the sandbox which, for the next hour, is running 2.7.1 (Build: 20140714).
So your sandbox is running 2.7.1 and production 2.7.1+? Sandbox is working but production is not.
Hmmmm ... networking comes before application. Are the sandbox and the production servers on the same network? Does JSON call a remotely hosted library behind the scenes? Didn't think it did. Which leads to the next 'wonder' ...
There's a lot more caching going on ... have you cleared caches on production server ... even to the point of manually removing them and having Moodle rebuild them?
'spirit of thinkering', Ken
Hi Ken,
Sorry - I wasn't clear. The sandbox I am referring to is at demo.moodle.net - it isn't my own. My own server is running 2.7.1+.
Thx
Yep - caches all cleared, in all the different browsers I've been using, and on the server side.
I'm getting nowhere with this, so I'm starting to make my environment match the demo.moodle.net sandbox (more). I've just updated PHP to version 5.5.16 using the Remi repo.
No change. Still broken Administration block and JSON syntax errors when viewing the enrolled students on a course.
Flummoxed.
Hello Rob,
As I mentioned before, the issue is quite subtle and involves many (apparently unknown) factors. I've visited sites where owners reported having the same problem but where the admin block worked fine for me. Well, this is just to remark that the problem isn't, necesarilly, a server problem. For example, at one time I "suddenly" had that problem while accessing one of my installations; after trying as much as I could to figure out what could have changed it came to me that a few days back I had updated my browser (Firefox at that time); I downgraded it and voilà, the problem was "solved", the block worked as expected.
Hi Guillermo,
Thanks. Yep - I appreciate that, which is a real shame as this kind of inexplicable behaviour will likely be enough to kill moodle for my project. It isn't acceptable in the commercial world, nor should it be in the community/OpenSource one.
Surely somebody with enough time an patience to binary cut to the problem across the bag of browsers we all use, can or has worked out what's going on? It is reassuring to know I am not alone, so it's not some subtle skunk scent unique to my technology stack.
Rgds,
--Rob.
this is the same problem i faced... i want to configure one for my news site News Lobby. can you help me please
Hello Rob,
You could open one tab for each installation and visually compare the relevant setting pages.
Regarding the "starting to look pretty bad...", not necessarily. There must be quite many others working without issues. As mentioned in the FAQ, there are many possible variables to take into account.
At least you may discard then for the problem being in your browser (version and/or settings).
A very slight chance, but as this problem has been around for quite some time, I wouldn't say that the problem has to do with the different Moodle build.
What does php -m |grep json kick back?
or php -i |grep json
php-json is supposed to be compiled into version 5.4 of PHP. Got a json.ini in /etc/php.d/? Is first line enabling the .so? Is the .so found with the other .so's?
'spriit of sharing', Ken
Hi Ken,
Here are your sharing bits
# php -i | grep -i json
/etc/php.d/json.ini,
json
json support => enabled
json version => 1.2.1
# cat /etc/php.d/json.ini
; Enable json extension module
extension=json.so
# php -v
PHP 5.4.16 (cli) (built: Aug 6 2014 13:12:28)
Copyright (c) 1997-2013 The PHP Group
Zend Engine v2.4.0, Copyright (c) 1998-2013 Zend Technologies
#
This stuff was all installed with standard CentOS 7 RPMs ... so I'm a little nervous about resorting to tarballs or anything that isn't packaged with this release.
Thanks,
--Rob.
Understood about keeping a system as clean as one could, but might point out that CentOS is based on Red Hat Enterprise who have always been 'conservative' with upgrades to packages like PHP. Don't have a shiny new OS 7 to look at right now, but if RHE is 'behind' then CentOS will be also. I have preference for CentOS because it is 'conservative' but has the ability to use other repos to get higher versions of XYZ. Thus the use of a repo like remi. ONLY use remi for higher versions of PHP ... not anything else.
'spirit of thinkering', Ken
Have brought my PHP to the same level as the demo.moodle.net sandbox (5.5.16) using the remi repo.
No change
Grump grump grump diddly grump grump grump. Sigh.
How did you acquire the CentOS 7? Fresh install or did you do an upgrade from a 6 to 7 in place?
Turn on debugging.
Watch logs of apache in real time via a terminal session. Install multitail: http://www.vanheusden.com/multitail/
There is not an RPM for multitail but worth the efforts in getting it installed for troubleshooting. Does require ncurses which you can acquire from standard repos (I would hope).
Once multitail is installed:
login to system as root user.
Issue: multitail -i /var/log/httpd/error_log -i /var/log/httpd/access_log -i /var/log/messages
you could add other logs you think might be significant by adding -i /var/log/[whatever]
If you see anything related/significant, copy and paste the text of debug output or clips of logs back here.
'spirit of sharing', Ken
CentOS 7 was a fresh install from the latest "everything " DVD ISO - clean as a whistle.
FYI - there is an RPM for multitail that is technically for RHEL6, but it goes on fine and works a treat on CentOS7 also:
ftp://ftp.univie.ac.at/systems/linux/dag/redhat/el6/en/x86_64/dag/RPMS/multitail-5.2.9-1.el6.rf.x86_64.rpm
So ... I've now got FULL Developer level debugging enabled, and I'm watching my httpd logs intently. I used to use a bit of VB with SecureCRT and lots of windows, but multitail is v. nice.
I have seen this in my php_errors.log file:
[03-Sep-2014 01:54:42 UTC] PHP Warning: PHP Startup: json: Unable to initialize module
Module compiled with module API=20121212
PHP compiled with module API=20100525
These options need to match
in Unknown on line 0
This could be related to my diversion into the remi repo, to get PHP 5.5.16 ... so I thjink it's a red herring. The Administration block is still notable by its shyness on occasion, and I still get the JSON Syntax Error when attempting to view enrolled users for a course. Basically ... it's still a lame duck >quack<
Thanks,
--Rob.
Well, you've chosen to work with an OS which is 'leading edge' ... 7.0.1? Yeah, it's released, but ... maybe not that mature yet - not for what you want ... ie, Moodle 2.7.x! Anytime one goes for 'leading edge' it's quite possible to cross into 'bleeding edge'. Think that's where you are at right now! To be honest, CentOS 6.x has been around for a while and will be for a while longer. Stable too! Plus with other repos like remi/webtatic one can acquire what is needed to run a 2.7.x Moodle. But, let's stay with the 'bleeding edge' just a little while longer ...
Ahhhhh, but at least we are making progress as to the JSON errors. Yes, you are correct, the logs do give us a hint/clue. It's a warning in logs - not serious enough the prevent php from running and Apache from launching, but surely the source of those json errors!
When you last updated PHP from remi, did you get all the php extensions ... like php-json from remi?
Mind sharing the yum commands you used to acquire the PHP upgrades?
Now before doing anything more drastic, let's see what's in /etc/php.d/ ... see a json.ini or one that might saw json.ini.rpmsave (if 7 does that)?
What does: yum repolist show ya?
When ever I have to use other repos I make sure those are NOT active so I have to enable them to use. Don't want other conflicts with things. Only using the repo to acquire specifically what is needed. So in the repo for remi, is the enable line set to 0 (ie, unless called specifically do NOT use remi repo):
fgrep enabled /etc/yum.repos.d/remi.repo
I've found yum updating to be tricky at times ... especially when using other repos like remi. First, I had to remove the PHP installed on the system by CentOS ... not only the php but php-commons and all the other extensions related. I then do a search via yum enabling the repo desired to acquire from for php, php-* to test what would be acquired using that same parameter in the search only installing. Watch out for those 'dependencies'.
Now I know I was the one who mentioned remi, but maybe the better repo for what is needed is webtatic:
https://webtatic.com/projects/yum-repository/
They do have a repo for el7 and thus CentOS 7 and might be a little less risky than remi for PHP.
'spirit of sharing', Ken
About that warning ... specifically ... think what it means is the php main app running (it's compiled version) doesn't match the php-json extension compilation version. Fix is simple, remove php-json (and any extension you added in-correctly) and re-install the extension.
Again ... mind sharing the yum commands used to acquire PHP?
Hey, it's ok to make a mistake ... do it all the time!!! Sometimes another set of eyes on something helps!
'spirit of thinkering', Ken
About the json error in logs and compile version mis-match ... I had seen something similar before with another extension to PHP and forgot how I 'generally' solved it. First, json is supposedly built into php 5.2 and higher now (well most compilations of PHP on distros) ... no longer requires php-json extension to be acquired/loaded. So let's try this to see if it fixes. In /etc/php.d/ hide the json.ini file ... mv json.ini .json.ini (note the 'dot' in front of the second 'json.ini'). That hides it from apache/php.
Restart apache: /sbin/service httpd restart .
Check apache error logs.
tail -n 20 /var/log/httpd/error_log
That warning go away? Fingers cross, access your Moodle.
If it works, remove the .json.ini in /etc/php.d/
'spirit of sharing', Ken
Thanks for all the help Ken - really appreciate having your eyes as well as mine on this. It doesn't usually take me this long to solve a "frustrating" problem with a bit of Ajax/Javascript/JSON ...
So, good to see you approach "alternative" repos just the way I do. I keep them disabled, only enabling them specifically when I want to use them, on the command line. Here's what I did:
# rpm -Uvhhttp://rpms.famillecollet.com/enterprise/remi-release-7.rpm
# yum install php-gd --enablerepo=remi,remi-php55
That install, which I needed to resolve a libgd.so dependency, dragged with it all the remi php-5.5.16 and its dependencies which included php-common which now includes the php-json libs as you point out.
Verified here:
# rpm -qa | grep php-comm
php-common-5.5.16-1.el7.remi.x86_64
#
There is no change to the /etc/php.d/json.ini file. Just the so file extension declaration. BTW - the warning was temporary, and I no longer get it.
; Enable json extension module
extension = json.so
Interestingly, hiding the json.ini file causes the Syntax error error to change from a JSON mparse error to "Unexpected end of input" in a Yui library call. So I think the json.ini so lib is working just fine. Have put it back.
Here is the current PHP soup I'm working with now:
# rpm -qa | grep php
php-pear-MDB2-2.5.0-0.9.b5.el7.noarch
php-pecl-jsonc-1.3.6-1.el7.remi.5.5.1.x86_64
php-5.5.16-1.el7.remi.x86_64
php-xml-5.5.16-1.el7.remi.x86_64
php-process-5.5.16-1.el7.remi.x86_64
php-pear-1.9.4-21.el7.noarch
php-pear-MDB2-Driver-pgsql-1.5.0-0.8.b4.el7.noarch
php-pecl-zip-1.12.4-2.el7.remi.5.5.x86_64
php-cli-5.5.16-1.el7.remi.x86_64
php-pgsql-5.5.16-1.el7.remi.x86_64
php-gd-5.5.16-1.el7.remi.x86_64
php-ldap-5.5.16-1.el7.remi.x86_64
php-mbstring-5.5.16-1.el7.remi.x86_64
php-xmlrpc-5.5.16-1.el7.remi.x86_64
php-common-5.5.16-1.el7.remi.x86_64
php-pdo-5.5.16-1.el7.remi.x86_64
php-intl-5.5.16-1.el7.remi.x86_64
php-soap-5.5.16-1.el7.remi.x86_64
#
Only the pear framework stuff isn't from remi, and it seems to be fine.
I get your comments on the bleedin' edge, but I'd have to take PHP to the bleedin' edge to get the revisions needed for 2.6 or 2.7.1+ (or 2.7.1) which is considered "stable". Or is "stable" more akin to Hannibal Lector stable?
I do get a slightly more helpful (!?) stacktrace with the JSON parse error now that debug is on FULL.
ln: 33
https://m.lb.com/theme/yui_combo.php?m&#x
.getAssignableRoles/<.on.complete
ln: 21
https://m.lb.com/theme/yui_combo.php?roll
Y.Subscriber.prototype._notify
ln: 13
https://m.lb.com/theme/yui_combo.php?roll
Y.Subscriber.prototype.notify
ln: 9
https://m.lb.com/theme/yui_combo.php?roll
Y.CustomEvent.prototype._notify
ln: 1
https://m.lb.com/theme/yui_combo.php?roll
Y.CustomEvent.prototype._procSubs
ln: 13
https://m.lb.com/theme/yui_combo.php?roll
Y.CustomEvent.prototype.fireSimple
ln: 17
https://m.lb.com/theme/yui_combo.php?roll
Y.CustomEvent.prototype._fire
ln: 13
https://m.lb.com/theme/yui_combo.php?roll
ET.prototype.fire
ln: 13
https://m.lb.com/theme/yui_combo.php?roll
IO.prototype._evt
ln: 9
https://m.lb.com/theme/yui_combo.php?roll
IO.prototype.complete
ln: 17
https://m.lb.com/theme/yui_combo.php?roll
IO.prototype._rS/<
BTW: The m.lb.com is a replacement by me to obfuscate the actual URL.
My SSL $CFG variables are:
$CFG->wwwroot = 'http://m.lb.com';
$CFG->httpswwwroot = 'https://m.lb.com';
$CFG->loginhttps=true;
I didn't find a consistent story on how to implement SSL, so I pretty much just enabled httpd mod_ssl default listener on port 443, and added the above config to config.php in my moodle DocRoot. As so much of the site works, and correctly rewrites to the https URL, I think that looks OK, but open to suggestions of any bits I've missed.
Thanks again ...
--Rob.
PS: I do get a new error in my non-ssl httpd error_log file, which may be related to my $CFG variables I mention above, specifically httpswwwroot ...
[Thu Sep 04 00:19:24.479098 2014] [:error] [pid 31538] [client a.b.c.d:53905] PHP Notice: Most probably incorrect set_page() url argument, it does not match the httpswwwroot!<ul style="text-align: left" data-rel="backtrace"><li>line 1227 of /lib/pagelib.php: call to debugging()</li><li>line
105 of /course/management.php: call to moodle_page->set_url()</li></ul> in /var/www/moodle/lib/weblib.php on line 2866, referer: http://m.lb.com/course/management.php?categoryid=2
Holy bovine!
I just took a gamble, and instead of following most of the advice I could find on using SSL only for the login page, I decided to rewrite all my http URLs as https URLs in Apache 2.4, and at the same time remove my $CFG->httpswwwroot = 'https://m.lb.com';
I now have:
$CFG->wwwroot = 'https://m.lb.com';
//$CFG->httpswwwroot = 'https://m.lb.com'; REMOVED
$CFG->loginhttps=true;
And all my JSON woes, Administration block shyness *AND* my SCORM Javascript errors have evaporated leaving a blissful, serene landscape.
What is the downside, in real terms, relating to caching when SSL is used for ALL content?
And why did this cause weird and esoteric JSON format errors in specific parts of the site but not others?
Many, many thanks for your help Ken ... and Guillermo.
Rgds,
--Rob.
Hi Rob,
So now you see why I said that "the issue is quite subtle and involves many (apparently unknown) factors" Well, at least a new possible cause has been found and so a new item to add to the Administration block links don't_expand FAQ. Thanks for the feedback!
Regarding your second question:
a considerable performance hit
