OXID bug in 4.4.8?

English forums
1

While trying to include “klarna” into a 4.4.8 installation, I got the error condtion, that class “klarnabasket” were to be loaded twice.

(This module is loaded via “oxbasket => klarna/core/klarnabasket”.)

Debugging the process I found out the following reason:

when the basket is restored from the session (oxsession::getbasket), class “klarnabasket” ist “autoloaded” via “function oxAutoload” in oxcfuntions.

However, the “autoload”-process does not store any “loaded” info in oxutilsobject…

So, when later in the process, oxbasket is to be initialized, “klarnabasket” is loaded again, which yields the error mentioned.

I have temporarily fixed (in the core code) this problem, by checking “class_exists” before trying to load the override modules, which seems to work,

Has any one else experienced this problem?

2

[QUOTE=avenger;58716]Has any one else experienced this problem?[/QUOTE]
Has anybody got “klarna” running at all?

3

[QUOTE=avenger;58716]Has any one else experienced this problem?[/QUOTE]
I have now tracked down the cause of the problem:

this occurs, if “oxbasket” is overloaded, and you have logged in setting the “Keep me logged-in” option…

Solution:

In “[B]oxutilsobject.php => _makeSafeModuleClassParents[/B]” replace

                $sParentPath = $myConfig->getConfigParam( 'sShopDir' )."/modules/".$sModule.".php";

                //including original file
                if ( file_exists( $sParentPath ) ) {
                    include_once $sParentPath;
                } elseif ( !class_exists( $sModuleClass ) ) {
                    //to avoid problems with unitest and only throw a exception if class does not exists MAFI
                    $oEx = new oxSystemComponentException();
                    $oEx->setMessage('EXCEPTION_SYSTEMCOMPONENT_CLASSNOTFOUND');
                    $oEx->setComponent($sModule);
                }

with

            if (!class_exists($sModuleClass))  
            {
              $sParentPath = $myConfig->getConfigParam( 'sShopDir' )."/modules/".$sModule.".php";

              //including original file
              if ( file_exists( $sParentPath ) ) {
                  include_once $sParentPath;
              } elseif ( !class_exists( $sModuleClass ) ) {
                  //to avoid problems with unitest and only throw a exception if class does not exists MAFI
                  $oEx = new oxSystemComponentException();
                  $oEx->setMessage('EXCEPTION_SYSTEMCOMPONENT_CLASSNOTFOUND');
                  $oEx->setComponent($sModule);
              }
                        }
4

Good morning Avenger,

I cannot really get the point. Why shall I change something in a core class of the shop to get a “3rd party”-module running? Did you talk to the Klarna-guys already?

Regards

5

[QUOTE=Marco Steinhaeuser;58941]Good morning Avenger,

I cannot really get the point. Why shall I change something in a core class of the shop to get a “3rd party”-module running? Did you talk to the Klarna-guys already?

Regards[/QUOTE]
It has nothing to do with this special module, but IMO is a genuine OXID problem with oxbasket overloading happening under the conditions described.

As the overloading oxbasket module is already invoked via autoload on getting the basket from the session, the shop will fail, if it is attempted to load it again in the normal oxbasket overloading process later on.

So I have to make sure, that this class does not exist already, when oxbasket activation is processed.

Doing it that way, the process throws no error.

But you can’t control that from within the overloading module…

6

[QUOTE=Marco Steinhaeuser;58941]
I cannot really get the point.[/QUOTE]

Dito,
you clean the browser-cockies (better complete private date)?
… oxbasket ist stored in session and make problems if a ‘old’ version is stored in cockies.

7

[QUOTE=MBa;58945]Dito,
you clean the browser-cockies (better complete private date)?
… oxbasket ist stored in session and make problems if a ‘old’ version is stored in cockies.[/QUOTE]
Sure, you and I can do that…

But not an unsuspecting visitor of the shop…

What do you mean by “old version stored in the cookies”?

8

Old versions of oxbasket-object(without new module) associated with the cookie.

9

[QUOTE=MBa;58947]Old versions of oxbasket-object(without new module) associated with the cookie.[/QUOTE]
I doubt, that this is the reason…

Again, this is what’s happening:

When the basket is retreived from the session, “oxbasket” ist auotloaded, and during that process also the klarna basket-module is activated (“oxbasket => klarna/klarnabasket”).

So far, so good, everythings is fine.

The problem arises, when the shop tries to initiate oxbasket later in the process again…

When activating “oxbasket”'s overloading module, this fails, becaue the klarna-basket class already exists…

10

But the code already uses “include_once”, so there should be no double inclusion possible, or am i missing something?

11

and what is different to other modules, which as well overload oxbasket?

12

[QUOTE=leofonic;58958]But the code already uses “include_once”, so there should be no double inclusion possible, or am i missing something?[/QUOTE]
Mmh, good point…

But why am I getting this “double class load” error???