debugging functions in OXID eShop

debugging functions in OXID eShop

OXID framework has some private and lots of protected functions in it’s classes and often they are hard to debug because of code enryption in PE/EE or hard extendable dataflow inside the functions. Shortly OXID added an extra protection for several core classes to ensure the integrity and safety of the shop, which makes these classes not extendable with modules. Should you ever see an OXID developer crying, this will be the reason. This or the next paypal+ module.

Here is an example:

There is a function “oxArticle->getCustomerAlsoBoughtThisProducts()“. I had to debug this function to find out, why oxid displays inactive articles in crosselling products.

I found out, that getCustomerAlsoBoughtThisProducts() receives its sql query for loading “also bought articles” from another protected function and returns the loaded article list. There is no easy way for you to see the sql query generated by the protected function.

The common way for debugging:

Inserting vardump() at the end of *generateSearchStrForCustomerBought()* is the easiest way to debug this little piece of shop. Oh, you are using encoded PE or EE? Sorry for that. In this case you have to create new module and extend oxArticle e.g. with a custom public function calling _generateSearchStrForCustomerBought() and returning its response or extend _generateSearchStrForCustomerBought() with a var_dump like you could insert the code in CE.
Approx. time effort: 2 minutes for CE and 20 minutes for PE/EE. You can add additional 15 minutes for unexperienced developers and 25 minutes for tired developers.
Tired unexperienced developers will probably need tranquilizer and a new keyboard.

Debugging with dev-console:

The idea is the same: we will extend oxArticle but we do not need a module anymore. Its dead simple:

Thats it! You will see the generated sql query:

Short explanation of the query:
Subquery in rows 2-5 selects all orders contain current product or its variants.
row 7 adds article IDs of other products from the same orders
row 8 adds article data for loaded article IDs
row 9 removes the currect product and its variants from the list
row 10-13 allow only active searchable products or active variants on stock
row 14 checks if a parent article in list still has active variants

At the bottom line we get active+searchable parent articles with active variants and active+searchable variants.
But wait! If your article with variants is sold out or discontinued, would you deactivate the parent article only or also all its variants? People are lazy, nobody deactivates variants, believe me.

At this point we found the problem here: this query does not check if the parent article of the bought variant is active or not. So this function will load and display even variants if their parent isn’t active anymore. But when someone clicks on the article link in the crossselling box, he will be redirected to the start page because of deactivated parent article.

If you have the same problem, check my fix here:

You can get dev-console here:

For more information and installation instructions visit this page:
You can download devutils package from my github account:


0.00 avg. rating (0% score) - 0 votes
0 replies

Leave a Reply

Want to join the discussion?
Feel free to contribute!

Leave a Reply

Your email address will not be published. Required fields are marked *