I moved hosts and now no text labels appear!!! (FIXED!!!)

[eric.carlson]

I have been running 0.19.2 for a while now with no problems and am moving hosts. I copied the install tree to the new host and did the usual mysql dump/restore, and in fact the admin check.php reports all is well (mostly GREEN, no REDs, even the test email arrives ok). However, no captions appear anywhere! Even the login page just has the field entry boxes but no labels, and the button has no text either. Its behaving like it can't find any language.

Have I done something dumb in trying to just copy the tree over? Are there some permissions I need to look into which would have this effect? Also, in case its useful, php is installed and working but this is the first php app I tried, it will definitely have all its defaults in case php is looking for some global or whatever (its pretty much the plain Fedora Core 2 distribution).

Any tips gratefully recieived thanks.

[eric.carlson]

Its not the moving thats the problem as I just tried a clean install of 0.19.2 on the new host with the same effect. It seems PHP is installed but theres either another module or env setting I am missing - does the language setting rely on one please?

[eric.carlson]

A clean install of the latest (1.0.0a2) gives "APPLICATION ERROR 300" on the main page. I created a new db and went through a totally separate install. I'm sure the PHP install is screwed but know nothing of php at all (I usually use java for serverside stuff, but Mantis is so good I want to stick with it :-)).

If I set the original 0.18 install so its hosted on the new server but is pointing to the db on the old one, it makes no difference and the labels are still all blank.

Finally, the web server is reporting these errors :
[client w.x.y.z] PHP Notice: Undefined variable: Array in /www/issuetracker/core/lang_api.php on line 51
[client w.x.y.z] PHP Notice: Array to string conversion in /www/issuetracker/core/lang_api.php on line 49
[client w.x.y.z] PHP Notice: Array to string conversion in /www/issuetracker/core/lang_api.php on line 51

That must be a huge clue! Please - anyone ????

[Narcissus]

I'm wondering if your new server has a newer version of PHP installed on it (possibly PHP5)?

I believe that PHP5 gave those sorts of errors, especially with older versions of Mantis.

Can you check the versions of PHP on both servers and let us know if they are the same or not?

[eric.carlson]

Can you check the versions of PHP on both servers and let us know if they are the same or not?

Thanks very much for your help.

New server is PHP 4.3.10
Old one is PHP 4.0.6

If you can forgive me I've been doing some tests by looking at the actual error message and putting some logs in core/lang_api.php:

$g_active_language = $p_lang;
if ( isset( $g_lang_strings[ $p_lang ] ) ) {
return;
}

$t_lang_dir = dirname ( dirname ( __FILE__ ) ) . DIRECTORY_SEPARATOR . 'lang' . DIRECTORY_SEPARATOR;

require_once( $t_lang_dir . 'strings_' . $p_lang . '.txt' );

echo "<hr><p>SPOT CHECK bugnote_title: ".$s_bugnote_title."<p><hr>";

# Allow overriding strings declared in the language file.
# custom_strings_inc.php can use $g_active_language
$t_custom_strings = dirname ( dirname( __FILE__ ) ) . DIRECTORY_SEPARATOR . 'custom_strings_inc.php';
if ( file_exists( $t_custom_strings ) ) {
require( $t_custom_strings ); # this may be loaded multiple times, once per language
}

$t_vars = get_defined_vars();

echo "<hr><p> Defined VARS: ".$t_vars."<p><hr>";
print_r(array_keys($t_vars));
foreach ( array_keys( $t_vars ) as $t_var ) {
$t_lang_var = ereg_replace( '^s_', '', $t_var );

echo "<hr><p>t_lang_var: ".$t_lang_var." t_var:".$t_var."<p><hr>";

if ( $t_lang_var != $t_var || 'MANTIS_ERROR' == $t_var ) {
$g_lang_strings[ $p_lang ][ $t_lang_var ] = $$t_var;
}
}
echo "<hr><p>".$g_lang_strings."<p><hr>";


What I get is the SPOT_CHECK returning "Note handler" so that tells me we don't have any silly path problems and the english string file is included ok.

Defined VARS: Array - Does this mean the "Array" variable is set up correctly?

I then get a long list in the format: Array ( [0] => p_lang [1] => g_lang_strings [2] => g_active_language [3] => t_lang_dir [4] => s_charset [5] => s_actiongroup_menu_move [6] => s_actiongroup_menu_copy [7] => s_actiongroup_menu_assign [8] =>

etc which seems to mean the Array about to be populated has been constructed ok

Then I get many repeated lines like this:
t_lang_var: Array t_var:Array

Thats looking like the assignment at the end will fail as it tests for equality first.

Finally it reports "Array" for $g_lang_strings but I suspect me not knowing php means it might well do that anyway.

Thanks again for any help, if yu want to suggest more tests like this please go ahead...!!!

[Narcissus]

Hmmm... unless I'm mistaken in the way I've read that code, it's quite bizarre that when you print_r the array_keys of $t_vars you get the (seemingly) correct values but then when you run foreach on it, it seems to think that $t_var is an array.

In reality, $t_var within the foreach loop should be each value of the array_keys that you just print_r'ed.

Once we work out why that is (unless it's because I misread it) I'm sure everything will be resolved.

Firstly, a few comments:
1) When you print a variable and it prints 'Array', then 99% of the time it's because you are trying to print an array. As you found, it's better to print_r those variables as you will see exactly what's going on in there.

2) When debugging, it's not a bad idea to just run print_r on all variables. Arrays are treated better this way and normal variables aren't generally affected adversely anyway.

3) Where possible, print '<pre>' before a call to print_r and print '</pre>' after the call. That way, arrays being printed to screen are much easier to understand.


What I would do in this instance is follow the above comments to firstly determine exactly what is going on in those variables that print 'Array'. Then, and just as importantly, I would copy those changes into my other installation, and see what differences there are in the output.

Hopefully we will then work out what the issue is, and then go from there...

[eric.carlson]

Thanks again.

Ok, I tidied up my logging technique (!) and hope this test proves informative. Btw its very difficult to go back as the hostname needs changing in DNS. I added these lines just after the foreach block:

foreach ( array_keys( $t_vars ) as $t_var ) {
$t_lang_var = ereg_replace( '^s_', '', $t_var );

echo '<pre>';
print_r($t_lang_var);
print_r($t_var);
echo '</pre>';

And left eveything else as it is in the pristine lang_api.php file.

What I see is this:
ArrayArray
(
[0] => p_lang
[1] => 0
)

ArrayArray
(
[0] => g_lang_strings
[1] => 1
)

ArrayArray
(
[0] => g_active_language
[1] => 2
)

ArrayArray
(
[0] => t_lang_dir
[1] => 3
)
...

Does this look right?

[eric.carlson]

http://sourceforge.net/mailarchive/foru ... m_id=35147

Guess we can stop all this banging heads on walls.
Whats a guaranteed version of PHP to use then please?

[eric.carlson]

Damn - I moved up to php 4.3.11 and its still failing! I upgraded using yum, rebooted the server and a test page wth phpinfo() confirms I'm on the new version.

I do have easier access to the old and new installations though - any more tests ayone please?

[eric.carlson]

This is a managed php sserver.
It had a line in its php.ini which read:
zend_extension = /usr/lib/ioncube/Ioncube_loader_lin_4.3.so

Which another user said had been giving him trouble with squirrelmail. So I commented it out, restarted apache and my Mantis installation is ok now!