HTTP error 500 with latest mersurial code

[jberanek]

I cannot get the latest mercurial code to work on my server, I'm using 1.7.4.1 normally, which works fine, but when I try the latest code I get an HTTP ERROR 500. In my logs I see:

[Tue Dec 17 08:13:42 2019] [error] [client redacted] PHP Fatal error: Uncaught exception 'Exception' with message 'MRBS: could not set language to 'en-GB'' in /var/www/html/scheduler_new/language.inc:162\nStack trace:\n#0 /var/www/html/scheduler_new/config.inc.php(982): require_once()\n#1 /var/www/html/scheduler_new/defaultincludes.inc(22): require_once('/var/www/html/s...')\n#2 /var/www/html/scheduler_new/index.php(8): require('/var/www/html/s...')\n#3 {main}\n thrown in /var/www/html/scheduler_new/language.inc on line 162

Using the same config.inc.php that works with 1.7.4.1. On my working environment, help shows:

Configuration details
MRBS version    MRBS 1.7.4.1
$auth['type']   none
$auth['session']    remote_user
Server details
Database    MySQL 5.5.66-MariaDB
System  Linux myservername 2.6.32-754.24.3.el6.i686 #1 SMP Thu Nov 14 16:00:38 UTC 2019 i686
Server time Tue 17 Dec 2019 08:26:18 GMT
Server software Apache/2.2.15 (CentOS)
PHP 5.6.40

What do I need to change?

Reported by: nmruser

Original Ticket: mrbs/support-requests/1932

[jberanek]

Oops, as well as the typo in the title, I missed off:

Your browser is set with the following language preference order: en-GB

Original comment by: nmruser

[jberanek]

From the stack trace it looks like you have an error in your config file which looks as though it has a require_once "language.inc"; line in it. The config format has changed since earlier versions of MRBS and it should not have this line in any more - though I'm a little puzzled as to why it worked with 1.7.4.1 because that change was made a while ago.

Original comment by: campbell-m

[jberanek]

Removing that line still leaves an error: [Tue Dec 17 09:19:50 2019] [error] [client redacted] PHP Fatal error: Uncaught exception 'Exception' with message 'MRBS: could not set language to 'en-GB'' in /var/www/html/scheduler_new/language.inc:162\nStack trace:\n#0 /var/www/html/scheduler_new/defaultincludes.inc(25): require_once()\n#1 /var/www/html/scheduler_new/index.php(8): require('/var/www/html/s...')\n#2 {main}\n thrown in /var/www/html/scheduler_new/language.inc on line 162

The relevent lines from config.inc.php are:

/**********
 * Language
 **********/
$unicode_encoding = 1;

// Set this to 1 to disable the automatic language changing MRBS performs
// based on the user's browser language settings. It will ensure that
// the language displayed is always the value of $default_language_tokens,
// as specified below
$disable_automatic_language_changing = 1;

// Set this to a different language specifier to default to different
// language tokens. This must equate to a lang.* file in MRBS.
// e.g. use "fr" to use the translations in "lang.fr" as the default
// translations.  [NOTE: it is only necessary to change this if you
// have disabled automatic language changing above]
$default_language_tokens = "en-GB";

// Set this to a valid locale (for the OS you run the MRBS server on)
// if you want to override the automatic locale determination MRBS
// performs.   Remember to include the codeset if appropriate.   For example,
// on a UNIX system you would use "en_GB.utf-8" for English/GB.
$override_locale = "en_GB.utf8";

Original comment by: nmruser

[jberanek]

Change

$default_language_tokens = "en-GB";

to

$default_language_tokens = "en";

It was failing because there isn't a lang.en-GB file - just a lang.en.

By the way, you've probably got lots of redundant settings in your config file, eg $unicode_encoding. And if you haven't changed your config file since the days when it had the require_once line in it, the way the config works has changed. You only need to put in it settings from systemdefaults.inc.php and areadefaults.inc.php that you want to override.

Original comment by: campbell-m

[jberanek]

Actually, you can remove the $default_language_tokens line completely because 'en' is the default setting in systemdefaults.inc.php.

Original comment by: campbell-m

[jberanek]

Thank-you, that works.

No, I haven't changed my config file for a very long time, as I've updated to new versions I've always just copied over the old file. Provided MRBS continued to work (it always has up to 1.7.4.1) I've assumed it was OK and any obsolete settings didn't matter.

Original comment by: nmruser

[jberanek]

You're right, the obsolete settings don't matter. But you can reduce the size of your config file by eliminating all the obsolete and default settings, which would make it easier to se what you're changing. Also going through systemdefaults and areadefaults sometime might reveal some useful new settings.

Original comment by: campbell-m

[jberanek]

Changing my default_language_tokens to "en" has the undesirable side-effect of changing all my date formats to US style i.e. M/D/Y. How do I get D/M/Y?

Original comment by: nmruser

[jberanek]

I will need to think about why that is happening, but in the meantime try setting

$disable_automatic_language_changing = 0;

Original comment by: campbell-m

[jberanek]

That takes me back to HTTP error 500.

Original comment by: nmruser

[jberanek]

I can't reproduce your M/D/Y date format problem. Does your system have the 'intl' extension loaded or not? (Login to MRBS as an admin and look at the Help page). MRBS should cope either way, but it would help to know to reproduce the problem.

Original comment by: campbell-m

[jberanek]

I can't reproduce this problem either. Just to check, what config settings do you have here?

Original comment by: campbell-m

[jberanek]

My extensions are:

Extensions Core, PDO, Phar, Reflection, SPL, SimpleXML, apache2handler, bz2, calendar, ctype, curl, date, dom, ereg, exif, fileinfo, filter, ftp, gettext, gmp, hash, iconv, json, libxml, mhash, mysql, mysqli, mysqlnd, openssl, pcre, pdo_mysql, pdo_sqlite, posix, session, shmop, sockets, sqlite3, standard, sysvmsg, sysvsem, sysvshm, tokenizer, wddx, xml, xmlreader, xmlwriter, xsl, zip, zlib

Are there any settings apart from the language ones I've already posted that would affect the date display?

Original comment by: nmruser

[jberanek]

OK, I've installed php-intl, restarted apache, set "$disable_automatic_language_changing = 0;", and now my dates are displaying with the correct (British) format of D/M/Y. Thank-you, I think that solves all my issues with 1.8.0, I'll be ready for when it is released!

Original comment by: nmruser

[jberanek]

Good. Can you just confirm please what your config settings were (just the language/locale related ones) before you had installed 'intl' that produced the wrong format of date? MRBS should work properly whether or not 'intl' is installed, so I'd like to investigate the problem.

Original comment by: campbell-m

[jberanek]

They were:

/**********
 * Language
 **********/
$unicode_encoding = 1;

// Set this to 1 to disable the automatic language changing MRBS performs
// based on the user's browser language settings. It will ensure that
// the language displayed is always the value of $default_language_tokens,
// as specified below
$disable_automatic_language_changing = true;

// Set this to a different language specifier to default to different
// language tokens. This must equate to a lang.* file in MRBS.
// e.g. use "fr" to use the translations in "lang.fr" as the default
// translations.  [NOTE: it is only necessary to change this if you
// have disabled automatic language changing above]
// $default_language_tokens = "en-GB";
$default_language_tokens = "en";

// Set this to a valid locale (for the OS you run the MRBS server on)
// if you want to override the automatic locale determination MRBS
// performs.   Remember to include the codeset if appropriate.   For example,
// on a UNIX system you would use "en_GB.utf-8" for English/GB.
// $override_locale = "en_GB.utf-8";
$override_locale = "";

// faq file language selection. IF not set, use the default english file.
// IF your language faq file is available, set $faqfilelang to match the
// end of the file name, including the underscore (ie. for site_faq_fr.html
// use "_fr"
$faqfilelang = "";

Original comment by: nmruser

[jberanek]

OK, I understand what was happening.

The 'intl' extension was irrelevant. What made it work was setting $disable_automatic_language_changing = 0 which meant that the language and locale were set automatically according to your browser preferences which were 'en-GB'.

If automatic language changing is disabled then MRBS first tries to set a locale, first according to $override_locale, and if there isn't one then according to $default_language_tokens. Having got a locale it will try and set a language according to $default_language_tokens.

In your case above you had $override_locale = ""; so it set the locale according to $default_language_tokens which was 'en' which was why you got US format dates (en is the same as en-US). So the following would have done what you wanted if you wanted to force all your users to get GB English:

$disable_automatic_language_changing = true;
$default_language_tokens = "en";
$override_locale = "en-GB";  // In 1.8.0 you don't need the suffix any more - just use a BCP47 style tag

Or else if you want your users to get their preferred language and locale according to their browser preferences set:

$disable_automatic_language_changing = false;

And as that's the default in systemdefaults.inc.php you don't need to set anything at all in the config file.

Hope that makes sense!

Original comment by: campbell-m

[jberanek]

Yes, I think I understand all that... but not why I got the original error (HTTP ERROR 500) with

$disable_automatic_language_changing = 1;

which I don't get with 1.7.4.1. Installing php-intl makes this error go away in 1.8.0 so I can use either of "1" or "0" as described above.

Original comment by: nmruser

[jberanek]

You got the original error because you had $default_language_tokens = "en-GB"; and there isn't a lang.en-GB file. The language and locale handling code has changed quite a bit between 1.7 and 1.8, so it doesn't surprise me that it did work in 1.7 (I've just tested and can confirm that it does). However it shouldn't really have worked: the comments in systemedefaults.inc.php for 1.7 say

// Set this to a different language specifier to default to different
// language tokens. This must equate to a lang.* file in MRBS.
// e.g. use "fr" to use the translations in "lang.fr" as the default
// translations.  [NOTE: it is only necessary to change this if you
// have disabled automatic language changing above]

That takes me back to HTTP error 500.

However, what I don't understand and can't reproduce (with no 'intl' extension) is why you got the second 500 error. What were your config settings then?

Original comment by: campbell-m

[jberanek]

Exactly as per my message of yesterday i.e. (comments removed):

$unicode_encoding = 1;
$disable_automatic_language_changing = true/false;
$default_language_tokens = "en";
$override_locale = "";
$faqfilelang = "";

Without php-intl the setting for $disable_automatic_language_changing of either true or false gave either a US format date (= true) or an HTTP error 500 (= false)... and it needs to be = false to show GB format dates. Installing php-intl was required to overcome the HTTP error 500.

Original comment by: *anonymous

[jberanek]

That's what I thought. I've tried those config settings with no php-intl and can't reproduce it. I'm a bit puzzled.

Original comment by: campbell-m

[jberanek]

Possibly an OS specific problem? My server settings can be seen in the original message.

Original comment by: *anonymous

[jberanek]

Yes, maybe. Do you still have the logs and if so could you look to see what the 500 error was the second time around please?

Original comment by: campbell-m

[jberanek]

I think it was this:

[Tue Dec 17 13:56:33 2019] [error] [client redacted] PHP Fatal error: Uncaught exception 'Exception' with message 'MRBS: could not set language to 'en-GB'' in /var/www/html/scheduler_new/language.inc:162\nStack trace:\n#0 /var/www/html/scheduler_new/defaultincludes.inc(25): require_once()\n#1 /var/www/html/scheduler_new/index.php(8): require('/var/www/html/s...')\n#2 {main}\n thrown in /var/www/html/scheduler_new/language.inc on line 162

Original comment by: nmruser

[jberanek]

OK, thanks. I'm afraid I can't reproduce the problem. If you were wiling to revert to not having 'php-intl' installed I could produce some test programs/diagnostics to try and track it down. However it may not be worth the effort.

I did notice that the code wasn't resilient to having $default_language_tokens = ""; and have made some improvements in the default branch.

Original comment by: campbell-m

[jberanek]

No, I don't think it's worthwhile removing php-intl (+ dependency libicu) to investigate further. Everything is working fine so I'm happier to leave it there. Thank-you for your help with this, which has solved the problem. In the new year I'll be upgrading my server to Centos 7/8 (probably 8) so any unresolved issues with Centos 6 will be even less significant.

Original comment by: nmruser