Magento

I’ve been trying to get everything setup on my test server for developing on a project…

I did a fresh install to an empty database, then after the install finished I archived the htdocs folder, and did a backup of the mysql database so that I could recover to that point… right…

I then did an import of the entire htdocs to an SVN repository for tracking changes. Then I removed all the original files and checked out the SVN repository to the htdocs folder so that it was being tracked by SVN. I then reset the file and folder permissions because SVN doesn’t keep track of that natively. Then after making the changes I used ASVN an SVN wrapper that does capture and store the file permissions in SVN to do a commit. This saved my entire htdocs permissions, users, groups and all into SVN so that I can track revisions to the site. I tested the site, and the basic pages load and everything seems to function fine… so I make another archive of the htdocs folder to capture the state as it is after the whole SVN setup.

So here I think I should be good and I’m ready to do anything I want even destructive and I can revert back to this state. 

I EVEN TESTED IT BY DELETING THE HTDOCS AND RESTORING FROM THE ARCHIVE.. AND I TESTED THE RESTORE OF THE DATABASE… >:-(

I got in and tried to install the osCommerce Import utility via Magento Connect and I get a few warnings throughout the process…

It says it downloads a whole bunch of stuff then installs them and all the installs are ok

At the end I get another odd warning:

but it gives me the little message saying everything in the world is awesome and it’s all done… click the neat little refresh button and be on your way, so I do… and the sky starts falling…

Right after that I got a page that loaded with just text errors no fancy pretty template or anything:

Ah… I broke it… I figured it was inevitable (though it would have been nice if it didn’t break so soon)… let’s just restore the backups and try again, or see if we can fix those errors right…

I wiped the htdocs directory and restored my backup to the state it was after I got my SVN setup… then I restored my database since I’m not sure if the extension install would have done anything to the database if the extension really got all the way installed properly.

I reload the page to find it still broke… just a different kind of broke. It gives me a pretty little templated page with the error:

This error I couldn’t find much on… but I tried loading the page in IE instead of firefox for a change to see if for some odd reason that would spark anything… and I noticed it displaying some text error and then doing the redirect to the pretty error that seems meaningless. I was able to stop IE so that I could view the real error that was happening behind the scenes and it was this:

I’ve tried several ways of restoring my backups… but it doesn’t seem to have any affect. If I go back and do another fresh install things seem to operate, so I’m not sure what’s changing outside of my htdocs folder and the mysql database that would be causing this. If I do a clean install it seems to be ok (until I try and install the osCommerce Import extension)…

Matt (mjohnsonperl)

I started kept trying ways to restore from my backup… and it turns out the culprit with my restore problems seemed to be from the database side of things, not the htdocs directory.

I was (now I don’t trust it) using Navicat 8 for backing up the database, and trying to restore it. Evidently it doesn’t restore things very well…

I now use the mysqldump command line tool exclusively for backing up my magento database since it actually works.

Database Backup

Database Restore

I’l probably end up putting together a nice little script to put the date in the filename automatically and all… but I can at least use this and modify it real quick in a pinch.

I got rid of the following warnings in the osCommerce Import extension install:

...but it didn’t help… after it “claimed” it installed successfully I got the same errors and the entire site breaks… AGAIN!

I tried my restore… this time using the backup from the mysqldump utility and I still got errors loading the page. So I restarted the apache processes hoping it would change something, and it did… I ended up with the same nasty results as before… errors about:

I don’t know what’s not working here, but I know I don’t have a good grasp on the whole backup and restore of a magento site… that’s for sure.

Matt (mjohnsonperl)

I think I have things working now… I think my issues were related to some file permissions that were getting saved in my SVN repository, and having the old cache and session directories restored.

I deleted the database and recreated an empty one.
I did a fresh install.
I restarted Apache.

This got me back to a new working install. Evidently I need to restart apache for something to take affect after I wipe everything in the htdocs directory and replace it with new files.

After I got this back up and running, I decided to avoid SVN and just try and install the osCommerce extension and see if it worked… and it did. I installed about 8 different extensions to see if it would break anywhere, and all was good.

I then got to reading up a few posts, and someone mentioned about deleting the cache and sessions directories in /var/ so I figured that might have been my problems with SVN. I also did a little more looking around on the forums for actual permissions, thinking that might have been part of my problem too.

I know I’m using FastCGI on this site… and I can’t remember but APC might also be installed for caching (someone else was working on setting up APC, so I don’t remember if it is or isn’t running). So because FastCGI is running I believe all the PHP code runs under the user’s permissions and not the user account that Apache is running under.

I then started over again… to get a fresh build for my SVN repository:
I deleted the database and recreated an empty one.
I extracted the Magento install files.
I restarted Apache.

After I extracted the Magento 1.0 files from the tar.gz archive and put them in htdocs, I ran this:

I think because I’m running FastCGI I can get away with the 775 and 664 permissions and not 777 and 666 respectively. This also means the files are a little more secure because not just any user account on the system is able to write to the files, and it also separates the access that is granted to the Apache process.

Before I did my initial SVN import I deleted the cache and session directories:

The initial SVN import resets all the file permission… so after the import, I deleted everything in htdocs and checked out what was in my SVN repository… then I reset the file permissions throughout the htdocs directory to match what the file permissions were prior to the initial SVN import.

Then I made sure the cache and session directories were empty and ran my ASVN commit after my permission changes.

This seemed to work, and I was able to install the osCommerce Import extension, and everything seems to be working fine now. So it looks like I can restore to my initial fresh install state from SVN and my mysql backup file… and i’m good to break anything I want now, revert back to my backup and try again.

Matt (mjohnsonperl)

I had a similar problem today and think I know what went wrong.

Before updating to the newest magento build, I made backups of my htdocs and the database.
The update was not successful. Ok, get back the old files, get the back-uped version of the database…
Horror! Everything stopped working with the same “Undefined index” error as above.

Problem: when I spooled the database back, all zero records (entries with primary key column value of 0) were not inserted with id 0, but as the last ones in the table. This way, website ‘admin’ got id 7 istead of 0 (being inserted after 6 other websites), and similar thing hapened with store groups and stores.

Solution: After I set the ids to 0 all was working fine.

To avoid this, use SET SESSION SQL_MODE="NO_AUTO_VALUE_ON_ZERO"; at the beginning of your backup SQL-script.

This way all the zero records should be properly inserted.

Hope this help someone.

Sincerely,

Bojan Hrnkas

The mysqldump command line tool does all the necessary details for preserving things like no_auto_value_on_zero and everything else.

mysqldump --host=xxxxxx --single-transaction --user=xxxxxx -p xxxxxx_dev_mage > /var/www/virtual/xxxxxx.com/dev/xxxxxx_dev_mage_backup_2008-04-25_fresh_install.sql

I have this particular error as well - and have been unable to fix it for the last 2.5 weeks. Project should have been live 2 weeks ago - and the site was all finished and setup. Am honestly getting desperate for a solution.

Here is the error:

This is what caused the error in my case (I used Installatron for both install, upgrades and reversions):

1. Backed up files + database (well, not part of the cause - but part of what I did)
2. Then upgraded from v. 1.2.1.2. to v. 1.3 (overwrote existing)
3. The upgrade turned our to have the bug of being unable of changing backend language via dropdown, so we decided to revert to the v. 1.2.1.2 backup
4. Bad idea - now error seems unfixable. Just like Bojan Hrnkas descripes.

Besides, I have tried:
A. Deleting the installation completely and the revert backup again - same error persists
B. Deleting the installation yet again and revert - following same pattern over again and attempting to revert all backups made during site development - still same error persists
C. Asking host for system backup reversion. I am not too techie to this seemed the best solution. However, their automated backups were not working as promised so could not do that (which was quite upsetting)
D. From filtering through the forums + Google for people having similar issue I have tried going to PHPmyAdmin examining the 2 tabels referred to in the error message:
- core_store
- core_website
A post in German (see here: http://www.magentocommerce.com/boards/viewthread/34652/) instructed that these 2 tables both should be set by these values:

id=0
code=admin

Since the values in these tables for “admin” were set to “3” rather than “0” I had hoped this would sort out the issue. The tables were adjusted to show these values:

“core_store”

store_id code website_id group_id name sort_order is_active
0 admin 0 2 Admin 0 1
1 default 1 1 Default Store View 0 1

“core_website”

website_id code name sort_order default_group_id is_default
0 admin Admin 0 0 0
1 base Main Website 0 1 1

Had to edit the “core_website” table first btw. The other way around was not possible.

STILL SAME ERROR PERSISTS … and this is where I am stuck!

This post is the closest I can get to a solution. So I am posting here hoping that some techies out there can help out. Would evidently REALLY appreciate some explicit directions. Please don’t assume I know stuff / ways to do stuff. Have signed up at a Magento Platinum partner hoping they would have a clue of how to get this solved. So far they have not come come up with anything though. I will update this post accordingly if I do get some feedback, but the last response I got for this one labelled it “unrecoverable”

I am on “Notify me..” on this post - hope for some community feedback on this one. Otherwise, I an basically schrewed - anyway, thanks a bunch in advance!

YEAAAAH… FINALLY!

Out of the blue I finally - finally succeeded in reverting the site. Man, what a relief!

At first nothing had changed on loading the page immidiately after - error persisted. Now a few hours later - site works. I suspect this is due to the site cache automagically refreshing at a given interval (?)

For info to everyone that may experience the same issue + others here have had - I did nothing beyond implementing the changes stated in my post above. Hope that as well as the advice given by others in this thread may be of benefit to some.

FIXED:

I know this update is late but if you don’t want to wait for the cache to update you can delete everything in var/cache.

Best Regards,

~cralls

These instructions were SPOT ON! Nice work.

I had to update one more table, though, core_store_group. The default group had an id not equal to 0, so I updated that.

Cleared the cache, and all things were made whole again.

Thanks for the solution!

i’m getting same problem but after altering the those table i got following erros. plz Help

SQLSTATE[23000]: Integrity constraint violation: 1062 Duplicate entry ‘1256653’ for key ‘PRIMARY’

#0 G:\vhost\thecar\lib\Zend\Db\Statement.php(300): Zend_Db_Statement_Pdo->_execute(Array)
#1 G:\vhost\thecar\lib\Zend\Db\Adapter\Abstract.php(479): Zend_Db_Statement->execute(Array)
#2 G:\vhost\thecar\lib\Zend\Db\Adapter\Pdo\Abstract.php(238): Zend_Db_Adapter_Abstract->query(’INSERT INTO `lo...’, Array)
#3 G:\vhost\thecar\lib\Varien\Db\Adapter\Pdo\Mysql.php(333): Zend_Db_Adapter_Pdo_Abstract->query(’INSERT INTO `lo...’, Array)
#4 G:\vhost\thecar\lib\Zend\Db\Adapter\Abstract.php(574): Varien_Db_Adapter_Pdo_Mysql->query(’INSERT INTO `lo...’, Array)
#5 G:\vhost\thecar\app\code\core\Mage\Log\Model\Mysql4\Visitor.php(125): Zend_Db_Adapter_Abstract->insert(’log_visitor_inf...’, Array)
#6 G:\vhost\thecar\app\code\core\Mage\Log\Model\Mysql4\Visitor.php(79): Mage_Log_Model_Mysql4_Visitor->_saveVisitorInfo(Object(Mage_Log_Model_Visitor))
#7 G:\vhost\thecar\app\code\core\Mage\Core\Model\Mysql4\Abstract.php(422): Mage_Log_Model_Mysql4_Visitor->_afterSave(Object(Mage_Log_Model_Visitor))
#8 G:\vhost\thecar\app\code\core\Mage\Core\Model\Abstract.php(318): Mage_Core_Model_Mysql4_Abstract->save(Object(Mage_Log_Model_Visitor))
#9 G:\vhost\thecar\app\code\core\Mage\Log\Model\Visitor.php(149): Mage_Core_Model_Abstract->save()
#10 G:\vhost\thecar\app\code\core\Mage\Core\Model\App.php(1265): Mage_Log_Model_Visitor->initByRequest(Object(Varien_Event_Observer))
#11 G:\vhost\thecar\app\code\core\Mage\Core\Model\App.php(1246): Mage_Core_Model_App->_callObserverMethod(Object(Mage_Log_Model_Visitor), ‘initByRequest’, Object(Varien_Event_Observer))
#12 G:\vhost\thecar\app\Mage.php(418): Mage_Core_Model_App->dispatchEvent(’controller_acti...’, Array)
#13 G:\vhost\thecar\app\code\core\Mage\Core\Controller\Varien\Action.php(502): Mage::dispatchEvent(’controller_acti...’, Array)
#14 G:\vhost\thecar\app\code\core\Mage\Core\Controller\Front\Action.php(59): Mage_Core_Controller_Varien_Action->preDispatch()
#15 G:\vhost\thecar\app\code\core\Mage\Core\Controller\Varien\Action.php(407): Mage_Core_Controller_Front_Action->preDispatch()
#16 G:\vhost\thecar\app\code\core\Mage\Core\Controller\Varien\Router\Standard.php(253): Mage_Core_Controller_Varien_Action->dispatch(’index’)
#17 G:\vhost\thecar\app\code\core\Mage\Core\Controller\Varien\Front.php(176): Mage_Core_Controller_Varien_Router_Standard->match(Object(Mage_Core_Controller_Request_Http))
#18 G:\vhost\thecar\app\code\core\Mage\Core\Model\App.php(340): Mage_Core_Controller_Varien_Front->dispatch()
#19 G:\vhost\thecar\app\Mage.php(629): Mage_Core_Model_App->run(Array)
#20 G:\vhost\thecar\index.php(80): Mage::run(’’, ‘store’)
#21 {main}

SQL DATA DUMP for Ref:

INSERT INTO `core_website` (`website_id`, `code`, `name`, `sort_order`, `default_group_id`, `is_default`) VALUES (1, ‘base’, ‘Main Website’, 0, 1, 1);
INSERT INTO `core_website` (`website_id`, `code`, `name`, `sort_order`, `default_group_id`, `is_default`) VALUES (0, ‘admin’, ‘Admin’, 0, 0, 0);

INSERT INTO `core_store` (`store_id`, `code`, `website_id`, `group_id`, `name`, `sort_order`, `is_active`) VALUES (0, ‘admin’, 0, 2, ‘Admin’, 0, 1);
INSERT INTO `core_store` (`store_id`, `code`, `website_id`, `group_id`, `name`, `sort_order`, `is_active`) VALUES (1, ‘default’, 1, 1, ‘Default Store View’, 0, 1);

INSERT INTO `core_store_group` (`group_id`, `website_id`, `name`, `root_category_id`, `default_store_id`) VALUES (1, 1, ‘The Car Cover’, 2, 1);
INSERT INTO `core_store_group` (`group_id`, `website_id`, `name`, `root_category_id`, `default_store_id`) VALUES (2, 0, ‘Default’, 0, 0);

I’ve been using the mysqldump command line tool for backups and its worked fine