I have added to the bug report with the following information:
I think this has to be a database related problem as I was experiencing this error after upgrading from CE1.4x to 126.96.36.199 and then 188.8.131.52, At the stage of having upgraded to 184.108.40.206, I had not tested enabling/disabling modules, however I did after upgrading to 220.127.116.11 and it was consistently failing to save.
Rolling back to the 1.4x fileset under the upgraded database then allowed saving again without error, rolling forward to 18.104.22.168, save again suceeds, and finally forward again to 22.214.171.124 again suceeded where it hadn\’t before. So it seems some database configuration got saved with either the 1.4x or 126.96.36.199 fileset under the upgraded database which then allowed saving under 188.8.131.52.
The final oddity is when deploying this to a live test environment (as opposed to my local development environment) sving hadn\’t been tested until 184.108.40.206 and failed here also, however it suddenly just started working without rolling back the fileset at all however I had saved a few things in admin between it not working, and working though I can\’t remember what exactly.
Finally, the error originates from line 135 in app/code/core/Mage/Adminhtml/Model/Config/Data.php:
$backendClass = $fieldConfig->backend_model;
The problem here is that the $fieldConfig variable does not get set in the lines shortly before it to an object, and thus the call to backend_model fails. The strange thing is debugging this method shows everything to happen in exactly the same way both when the save fails, and when it suceeds (debugging under 220.127.116.11 in both cases), the only difference is the line above does not throw an exception when the save succeeds, but does when it fails so I can only assume something has changed with regards to exception handling between the two scenarios.
So not sure exactly what changed but it looks to be database related rather than a bug with the fileset. Rather than regressing the 18.104.22.168 code, you might first want to try rolling back to the 22.214.171.124 fileset and try saving under that which will hopefully succeed, then with a bit of luck returning to 126.96.36.199 will have resolved the issue.
Interesting, it may well be a db issue - but I\’ve just replicated this on a clean install of 188.8.131.52, so no DB upgrade at all involved.
Which suggests that if it comes from the db content the SQL setup scripts are where the bug lies
I have also a problem with magento 184.108.40.206… I can’t save products on backend after upgrade 1.6.2 to 220.127.116.11.
I got everytime the 500 server error page here : MY_MAGENTO/catalog_product/save/id/6110/key/cdf813436142e45d4971fd5ea70a662b/
I can create a new one but if i edit it i got same error.
someone can help me please, my website is on production
This override seems to cause issues with Admin->Config->Payment Methods->Paypal. When attempting to save a Paypal payment method, all changes will be not saved, and no error will be thrown. I have not looked into why. Removing the code restores Paypal configuration ability to admin panel.
The problem has been proven to be caused by a plug-in, so they are actually following the code or keep the original code is better.
There\’s a problem in magento 18.104.22.168, when trying to save disable module output.According to this threadUnable to save entries in Disable Modules Output after upgrading to 22.214.171.124, this is how to solve the problem
So copy app/code/core/Mage/Adminhtml/Model/Config/Data.php to app/code/local/Mage/Adminhtml/Model/Config/Data.php
In the local copy change the code from line 119 as follows: