CE Phoenix Cart Forum

Posted: **Wed Jul 20, 2022 9:28 am**

hi All

i user at the moment version 1.0.8.5

I had it now twice, that my homepage did show a white page instead of the homepage.
in the error log i found:
[Wed Jul 20 10:05:28.053317 2022] [php7:warn] [pid 158103] [client 172.19.0.7:49064] PHP Warning: require(/var/www/html/includes/languages/de/index.php): failed to open stream: No such file or directory in /var/www/html/index.php on line 15

so what happend is / was, that in the language.php

Code: Select all

public static function map_to_translation($page, $language = null) {
      if (is_null($language)) {
        $language = $_SESSION['language'];
      }

      $page = ('.php' === $page)
            ? "includes/languages/$language.php"
            : "includes/languages/$language/$page";
      $Template =& Guarantor::ensure_global('Template');
      $translation = $Template->map($page, 'translation')
                  ?? DIR_FS_CATALOG . $page;

      return file_exists($translation) ? $translation : DIR_FS_CATALOG . $page;
    }

the $language=de and that's why it didn't found the tempalte, instead of $language = "german"

inkognito tab worked my homepage normal, so something changed my $language=german to $language=de

whenn i put in the browser on the url "?language=de" everything was back to normal and i didn't could reproduce the problem.

does anybody has a idea, how this can happen and how to fix that? one idea is to change the "map_to_translation" function to only accept "german", "english", "french" but that does not fix the prolbem, it's only symtom...

it happends on my browser 3 times in the last 5 days....and 1 on a friends browser while he helped me debugging. One thing we have multiple phoenixcart instances (test / productive) where i switch with my browser, but that shouldn't change the variable...

Posted: **Wed Jul 20, 2022 10:04 am**

I don't know of anywhere that map_to_translation is called with a language parameter. So that code would be using the session language. Look for things that change either $_SESSION['language'] or $language in a global context.

Note that map_to_translation changes $language in a local context, inside the method. That's fine. What's problematic would be if there was a global $language; in the method or if the same thing was done outside the method.

Looking in core and Pro, there are no incidences of the language being set incorrectly that I can find. This suggests that the problem lies in either a third-party add-on or custom code of your own.

Posted: **Wed Jul 20, 2022 10:22 am**

i found the reason of the crash, but i did not know why this have this effect and probably it's also a "bug" that if i write that in the file, that this happends...

the reason is, i had a script, which produce a csv file, and in the top of the php it was:

Code: Select all

require 'includes/application_top.php';

$id = $_GET['id'];
$language = $_GET['language'] ?? "de";

as soon as i used this url in my webbrowser my website was "white" with the error until i reoaded the session

i changed now the code to

Code: Select all

require 'includes/application_top.php';

$id = $_GET['id'];
$_GET['language']  = $_GET['language'] ?? "de";

and used in the script $_GET['language'] instead of $language and now it works as it should.

That means, that the line:
$language = $_GET['language'] ?? "de";

overwrote somehow the session language. is this ok like this?

(my problem is solved, but i'm not sure if this is ok)

Posted: **Wed Jul 20, 2022 11:21 am**

loop wrote: ↑Wed Jul 20, 2022 10:22 am overwrote somehow the session language. is this ok like this?

It's expected. I don't think it is OK. I have been going through a long process of making it not work like that, as it's not a simple change. The problem goes back to register globals. Originally, PHP registered all the GET, POST, and session variables as globals with the same name (with an order to handle collisions that would produce a single winner). That was convenient for some things, but then people noticed that there were ways to make that have undesirable consequences. So PHP moved away from register globals. Meanwhile, osC used the register globals paradigm to manage its session variables. To make this work with register globals off, it had https://github.com/CE-PhoenixCart/Phoen ... p#L56..L59

I've been going through and replacing all the session variable globals with elements of the session superglobal. E.g. $language with $_SESSION['language']. I'm probably close to being done and plan to finish that in the 1.0.8.* series. Once all those are gone, I will be able to get rid of the extract lines from the session segment. Probably in the 1.0.9.* series, perhaps in 1.0.9.1.

Anyway, my point is that it has always worked that way, since before there was a community edition version. Making it work differently is desirable but not simple. Because there were simply too many places making use of it. If you want, you could remove the highlighted lines from the link. I haven't tried it, so I'm not sure if anything will break or not. I may have already fixed it for catalog. I haven't done the final check pass to see.

Posted: **Wed Jul 20, 2022 12:14 pm**

for me it's "ok" i changed it to $_GET and i'm happy with it, but i wondered, that this $language broke the full cart.
maybe a check where the $language templates are loaded to "if it's a legal language directory" otherwise take standard directory would solve the issue...but you know what you do

so thank you for your time and help

CE Phoenix Cart Forum

Possible Bug with $language variable - but cannot tell whenn it's happen..

Possible Bug with $language variable - but cannot tell whenn it's happen..

Re: Possible Bug with $language variable - but cannot tell whenn it's happen..

Re: Possible Bug with $language variable - but cannot tell whenn it's happen..

Re: Possible Bug with $language variable - but cannot tell whenn it's happen..

Re: Possible Bug with $language variable - but cannot tell whenn it's happen..