Cannot determine language

cmonie · August 24, 2013

Upgraded an osCommerce store from 2.3.1 to 2.3.2 but now the store can no longer determing the store's language.

What should I look for when attempting to fix the problem. First encountered in admin/includes/application_top.php around line 170 ( require(DIR_WS_LANGUAGES . $language . '.php'); ) where $language is blank.

tgely · August 24, 2013

Is it Chrome?

cmonie · August 24, 2013

Yes I am using chrome but I just got the same error using IE

tgely · August 24, 2013

Do you have installed language? You could check with PhpAdmin languages table.

1 English en icon.gif english 1

cmonie · August 24, 2013

Yes Gergely that was the first place I checked. The store used to work but the host is forcing

the store owner to upgrade to 2.3.3 so I am doing it manually 2.3.1 to 2.3.2 then 2.3.3.

Per the upgrade instructions I have to go into the Admin tool and activate enable the Customer

Password Reset Action Recorder Module and that is where I hit the language error

Jack_mcs · August 25, 2013

Try editing the database and turning off cache, gzip and sessions in the configure table, if any are set.

MrPhil · August 25, 2013

This $language problem is supposed to be fixed in 2.3.3. Any chance that you can ignore the problem and carry through with the 2.3.3 upgrade?

tgely · August 25, 2013

Is it work?

http://yoursite/youradmin/login.php?language=en

cmonie · August 26, 2013

Gergely I tried that and got yet another error, see below

Error!

Unable to determine the page link!

Function used:

tep_href_link('', '', 'NONSSL')

MrPhil at this point I am not comfortable going on to 2.3.3 without understanding the reason for the language error

Jack_mcs I did not see any setting for cache, gzip and sessions in the configure table,

burt · August 26, 2013

Update to 2.3.3, move on and get this clients shop working again.

cmonie · August 26, 2013

I installed a fresh copy of 2.3.3 and was able to enter the store so yes I am going to continue with the upgrade to 2.3.3

One issue though, I was unable to log into the Admin tool though I was using the correct ID and password. Any thoights?

cmonie · August 26, 2013

I hard coded $language = 'english'; and $languages_id = 1; and the store is back online while I continue the upgrade to 2.3.3

the unforunate thing is that even with the hard coded language I still cannot get into the Admin tool, but I will deal with that later

unless someone has suggestions for me.

When I log into the Admin tool with language hard coded, I get the same error I had before.

Error!

Unable to determine the page link!

Function used:

tep_href_link('', '', 'NONSSL')

tgely · August 26, 2013

do you use htaccess layer?

cmonie · August 26, 2013

Yes the admin folder has a dot htaccess file in it and here are the contents and I am sure I am using a valid ID/password.

# $Id$

#

# This is used with Apache WebServers

#

# For this to work, you must include the parameter 'Options' to

# the AllowOverride configuration

#

# Example:

#

# <Directory "/usr/local/apache/htdocs">

# AllowOverride Options

# </Directory>

#

# 'All' with also work. (This configuration is in the

# apache/conf/httpd.conf file)

# The following makes adjustments to the SSL protocol for Internet

# Explorer browsers

#<IfModule mod_setenvif.c>

# <IfDefine SSL>

# SetEnvIf User-Agent ".*MSIE.*" \

# nokeepalive ssl-unclean-shutdown \

# downgrade-1.0 force-response-1.0

# </IfDefine>

#</IfModule>

# If Search Engine Friendly URLs do not work, try enabling the

# following Apache configuration parameter

# AcceptPathInfo On

# Fix certain PHP values

# (commented out by default to prevent errors occuring on certain

# servers)

# php_value session.use_trans_sid 0

# php_value register_globals 1

##### OSCOMMERCE ADMIN PROTECTION - BEGIN #####

AuthType Basic

AuthName "osCommerce Online Merchant Administration Tool"

AuthUserFile /home2/nblfmhwz/public_html/admin/.htpasswd_oscommerce

Require valid-user

##### OSCOMMERCE ADMIN PROTECTION - END #####

tgely · August 26, 2013

The best would be to switch off htaccess password layer for a while.

if is not work...

Harald often said that this is session close problem, but nobody could present the fix.

Could you print out the $_SESSION variable?

You should put the code before

 $action = (isset($HTTP_GET_VARS['action']) ? $HTTP_GET_VARS['action'] : '');

for debug

print_r($_SESSION);

in admin/login.php

I wonder the output.

cmonie · August 27, 2013

Gergely et al thanks for all your help. I upgraded the store to 2.3.3 and the store works OK thus far.

I am still having some issues with the Admin tool and will try Gergely's latest suggestion to see it that helps.

My host just upgraded PHP to 5.4, does this have any bearing on my issues?

♥joli1811 · August 27, 2013

may be wrong here but the upoaded

The best would be to switch off htaccess password layer for a while.

if is not work...

Harald often said that this is session close problem, but nobody could present the fix.

Could you print out the $_SESSION variable?

You should put the code before
$action = (isset($HTTP_GET_VARS['action']) ? $HTTP_GET_VARS['action'] : '');
for debug
print_r($_SESSION);
in admin/login.php

I wonder the output.

Hi just noticed a fix on the latest upgrade osCommerce Online Merchant v2.3.3.1 regarding session close

http://library.oscommerce.com/Online&en&oscom_2_3&release_notes&v2_3_3_1#upg3

no idea if that is relevant to this problem but just maybeee :)

regards

joli

cmonie · August 28, 2013

I upgraded to 2.3.3.1 but that did not help either.

My hosting company upgraded to PHP 5.4.18 and when I made a call to get_defined_vars,

the deprecated globals ( $HTTP_GET_VARS, $HTTP_POST_VARS etc ) were not there and

it looks the compatibility.php was not helping either, so I decided to change all deprecated

super globals to whatever they are supposed to be now i.e. HTTP_GET_VARS to $_GET,

HTTP_POST_VARS to $_POST etc, and that did the trick for me, so now I can get into the

store and the admin tool with no issues.

Thanks to everyone who helped me along the way.

CMonie

sormui · August 28, 2013

I hard coded $language = 'english'; and $languages_id = 1; and the store is back online while I continue the upgrade to 2.3.3

the unforunate thing is that even with the hard coded language I still cannot get into the Admin tool, but I will deal with that later

unless someone has suggestions for me.

When I log into the Admin tool with language hard coded, I get the same error I had before.

Error!

Unable to determine the page link!

Function used:

tep_href_link('', '', 'NONSSL')

I had similar problem and did the following to fix it. Hope it helps.

In admin/includes/functions/html_output.php:

function tep_href_link($page = '', $parameters = '', $connection = 'NONSSL') {

Find:

if ($page == '') { die('</td></tr></table></td></tr></table> Error! Unable to determine the page link! '); }

Replace this with : if($page == ''){

$page = basename($HTTP_SERVER_VARS['PHP_SELF']); }

tgely · August 29, 2013

I upgraded to 2.3.3.1 but that did not help either.

My hosting company upgraded to PHP 5.4.18 and when I made a call to get_defined_vars,

the deprecated globals ( $HTTP_GET_VARS, $HTTP_POST_VARS etc ) were not there and

it looks the compatibility.php was not helping either, so I decided to change all deprecated

super globals to whatever they are supposed to be now i.e. HTTP_GET_VARS to $_GET,

HTTP_POST_VARS to $_POST etc, and that did the trick for me, so now I can get into the

store and the admin tool with no issues.

Thanks to everyone who helped me along the way.

CMonie

Not need it because compatibility.php contains this transfer.

if (PHP_VERSION >= 4.1) {
$HTTP_GET_VARS =& $_GET;
$HTTP_POST_VARS =& $_POST;
$HTTP_COOKIE_VARS =& $_COOKIE;
$HTTP_SESSION_VARS =& $_SESSION;
$HTTP_POST_FILES =& $_FILES;
$HTTP_SERVER_VARS =& $_SERVER;
} else {
if (!is_array($HTTP_GET_VARS)) $HTTP_GET_VARS = array();
if (!is_array($HTTP_POST_VARS)) $HTTP_POST_VARS = array();
if (!is_array($HTTP_COOKIE_VARS)) $HTTP_COOKIE_VARS = array();
}

The next bugfix release v2.3.3.2 will contain the mysqli fix at approximately next week. You could follow on github the changes.

Could you switch off htaccess layer?

cmonie · August 29, 2013

I know I did not have to change the HTTP_POST_VARS to $_POST etc but I had to do anything to get the store back online.

I have created a parallel environment where I will reset the code I changed back to its original state and research why

compatibility.php is not doing the transfer like it is supposed to.

tgely · August 31, 2013

Deprecated constants ($HTTP_POST_VARS) are prohibited?

MrPhil · September 3, 2013

Unless @@cmonie's host has a strange configuration for PHP 5.4, I haven't heard of $HTTP_*_VARS being prohibited (as normal program variables). It has been a long time since PHP supplied these variables, and the osC compatibility layer has provided them. I would suspect that something went wrong with Carl's compatibility.php, or for some reason (server misconfiguration), $_POST etc. were for some reason unavailable. Carl, double check that compatibility.php (I think that's the name) is still being invoked, and it's available and readable, etc.

I hope that for osC 2.4, Harald finally bites the bullet, requires PHP 5, and replaces $HTTP_*_VARS by $_*. It would make the code much cleaner and bring osC out of the Stone Age.

Cannot determine language

Recommended Posts

cmonie

tgely

cmonie

tgely

cmonie

Jack_mcs

MrPhil

tgely

cmonie

burt

cmonie

cmonie

tgely

cmonie

tgely

cmonie

♥joli1811

cmonie

sormui

tgely

cmonie

tgely

MrPhil

Archived

Browse

Activity