0

I have a shell script that should send an API request to a certain endpoint, using username and password in a simple HTTP auth. Everything works fine using hard-coded values, but of course we want to make those values configurable, so each time the credentials or the endpoint change, we can adjust using the Admin interface.

The relevant part of the script is the following:

$url = Mage::getStoreConfig('my_namespace/api_name/base_url');
$username = Mage::getStoreConfig('my_namespace/api_name/username');
$password = Mage::getStoreConfig('my_namespace/api_name/password');

if (!$url) {
    $this->log("`my_namespace/api_name/base_url` should be set");
    $this->error = true;
}

if (!$username) {
    $this->log("`my_namespace/api_name/username` should be set");
    $this->error = true;
}

if (!$password) {
    $this->log("`my_namespace/api_name/password` should be set");
    $this->error = true;
}

if ($this->error) exit(1);

All this is inside a public function run() method of a class that extends from Mage_Shell_Abstract. Trying to run this script ends up showing all the three error messages, just like the values didn't exist in DB.

But the values are present in the database:

mysql> SELECT * FROM core_config_data WHERE path LIKE '%my_namespace%';
+-----------+---------+----------+--------------------------------+-----------------------------+
| config_id | scope   | scope_id | path                           | value                       |
+-----------+---------+----------+--------------------------------+-----------------------------+
|      5986 | default |        0 | my_namespace/api_name/base_url | http://the.api-endpoint.com |
|      5987 | default |        0 | my_namespace/api_name/username | Picard                      |
|      5988 | default |        0 | my_namespace/api_name/password | NCC-1701                    |
+-----------+---------+----------+--------------------------------+-----------------------------+

Caches were clean multiple times, so it's all good from this part. I can't see what is wrong here. Any help is welcome.

  • Before calling Mage::getStoreConfig, try to use this in your code : Mage::app()->setCurrentStore(0); – Jonathan Ribas Jun 5 '18 at 18:46
0

It took me a while, but in the end we found a solution (which in my opinion feels more like a workaround, like everything in Magento). At the very beginning of the run() method, we added this line:

Mage::getConfig()->reinit();

This triggers a complete reload of the configuration, passing through all the hooks, like loading the local.xml, all the other modules' XMLs and config from DB.

So what was the problem and how did we find it?

After trying to clean the caches several times I decided to take a look in its actual contents. For my surprise there was no config cache at all! Weird. After running the script itself several time, still, no caches generated.

Important to mention that our infrastructure has proper separation of concerns. The PHP nodes supposed to render the frontend for the customers are not the same of the ones that run cronjobs, send emails and run scripts like this one. If we were running without this concern, any page load would have generated a config cache and the script would see the configuration entries from the database.

The fact is that, simply running a script that extends from Mage_Shell_Abstract will not give you the configuration state you would expect in a normal situation and, even worse, the configuration state depends heavily on other things your system might be doing, even if they are completely unrelated.

This is confirmed by the fact that the line added at the beginning of the run() method is only needed if the script is the first thing to run after a cache cleaning. And only in the first run. Even subsequent runs of the same script won't need the mentioned line (because the config cache was already generated by the previous run).

I can't understand why one would imagine that a shell script, based on the classes of the same code base, would not need to load the same configuration used by the rest of the system but that's (unfortunately) the behavior we found...

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.