View Issue Details

Jump to Notes
IDProjectCategoryView StatusDate SubmittedLast Update
0007968OXID eShop (all versions)2.2. Shop settingspublic2026-06-29 11:132026-07-08 15:08
ReporterSleTp Assigned To 
PrioritynormalSeverityminorReproducibilityalways
Status feedbackResolutionopen 
Product Version7.5.0 
Summary0007968: The assignment windows do not display any data anymore
DescriptionWith "assignment window" i mean the small windows that open after you click something like the "assign countries to a payment method" or "assign categories to a product" buttons.
After we updated to Oxid metapackage-ee version 7.5 these assignment windows stop displaying any data.

This seems to happen because the the Core/Config.php has been adjusted so that in the getConfigParam() does not call "init()" anymore. Instead it only calls "initVars()". This makes it so that the session does not get properly initialized in the source/oxajax.php anymore. For now we fixed it ourselves by directly calling Config->init() in oxajax.php.
Steps To Reproduce- Go into the admin backend of an OXID 7.5 instance
- Goto shop config > payment methods
- Select any payment method
- Go into the countries tab
- Click on the assign countries button
- The window now opens, you see the two assignment columns but they are empty
TagsAdmin, AJAX
ThemeNot defined
BrowserNot defined
PHP Version8.4
Database VersionNot defined

Activities

SvenBrunk

2026-07-01 08:40

administrator   ~0018567

I can not reproduce this. I admit my current 7.5 development environment is not completely clean, but the list fills fine.
@SleTp maybe some module is intervening here?

SleTp

2026-07-01 08:56

reporter   ~0018568

@SvrenBrunk - i do not think that any module is intervening. The problem occures quite early in the oxajax.php, since the session can not be initialized and it thinks that the user is not logged in:

    // authorization
    if (
        !(
            Registry::getSession()->checkSessionChallenge() &&
            count(Registry::getUtilsServer()->getOxCookie()) &&
            Registry::getUtils()->checkAccessRights()
        )
    ) {
        header("location:index.php");
        Registry::getUtils()->showMessageAndExit("");
    }

After debugging the issue myself i could not determine where the oxajax.php initializes the session since Core/Config.php has been changed to not do that anymore:

    public function getConfigParam($name, $default = null)
    {
        $this->initVars($this->getShopId()); // <=== This previously was a call to "init()" which initialized the session in oxajax.php, even if incidentally

        if (isset($this->_aConfigParams[$name])) {
            $value = $this->_aConfigParams[$name];
        } elseif (isset($this->$name)) {
            $value = $this->$name;
        } else {
            $value = $default;
        }

        return $value;
    }

Would it be possible to gain access to a test OXID admin backend that is mostly empty to verify that the issue is really unique to us?

michael_keiluweit

2026-07-08 15:08

administrator   ~0018588

Hi,

thanks a lot for the detailed report and especially for pointing at the Config change, that made this very easy to trace. You are right about what changed, but I think the conclusion needs a small correction, and I hope the following clears it up.

In 7.4, Config::getConfigParam() called $this->init() on its first line, so the session was started as a side effect the first time any config value was read:

7.4 Config::getConfigParam() -> $this->init()
https://github.com/OXID-eSales/oxideshop_ce/blob/v7.4.2/source/Core/Config.php#L285

Because of that, oxajax.php did not need to start the session itself. It just read a config value and the session came up implicitly:

7.4 oxajax.php (no explicit init(), goes straight to getConfigParam) https://github.com/OXID-eSales/oxideshop_ce/blob/v7.4.2/source/admin/oxajax.php#L24-L27

In 7.5 that implicit side effect was removed. getConfigParam() now only calls initVars(), which loads the config variables but does not start the session:

7.5 Config::getConfigParam() -> $this->initVars($this->getShopId()) https://github.com/OXID-eSales/oxideshop_ce/blob/v7.5.1/source/Core/Config.php#L247

So your analysis of the root cause is correct.

But the same change that removed the side effect also added the compensating call directly into oxajax.php. The session is now started explicitly right after
Registry::getConfig():

7.5 oxajax.php -> $myConfig->init() https://github.com/OXID-eSales/oxideshop_ce/blob/v7.5.1/source/admin/oxajax.php#L25

This is exactly the "temporary fix" you describe (directly calling Config->init() in oxajax.php). Both changes are part of the same commit and are already shipped in the 7.5.0 and 7.5.1 tags, so on a clean install the line is already there. Net behaviour is the same as in 7.4.

Since adding init() to oxajax.php fixes it for you, that line seems to be missing or not effective in your environment. The usual causes are:
  * a customised or older source/admin/oxajax.php that predates this change
  * a module that overrides Config or oxajax and prevents init() from running

If the line is present and it still fails with modules off, we would have a genuine regression and I will happily dig deeper. In that case, please contact the OXID Support: [email protected]

Best regards