Thread

I’m updating from v1.4.1 to v1.7.1. The documentation refers repeatedly to the “/system” folder, but I have no such folder. My main folder is /exp. It contains index.php, path.php, and the subfolders admin, image, include, and themes. 
I don’t know whether the folder was renamed for some reason by the original developer of our site, or that’s the way the root folder was named in v1.4.1. 
I’m assuming that anything the documentation tells me to do in “/system”, I should do in “/exp/admin.” But I’m concerned that the name difference may mess up the Update Wizard. Should I leave the admin folder as it is, or rename it to system?

First, before you do any updating backup all files and databases.

Done? good.  A developer can opt to rename the system folder for a little added security. Simply follow the upgrade instructions but use your EE system path (/exp) in place of /system.

Yes, I’ve done all backups per standard instructions. And like I said, I’ll do whatever the instructions say to do in /admin instead of /system.  Good to know that developers sometimes rename /system. But none of that answers my question. What about the Update Wizard?  Will it run OK it I leave the name as /admin?

The question remains, will the Wizard run properly without me renaming this folder to /exp/system?  There are hard-coded references to admin in both the site pages and the config.php file, so I don’t really want to rename it. But I need the Wizard to work properly.

johnnyb,

The update wizard should have no problem with using a renamed system folder. I have done many upgrades in that same scenario without issues. Just be sure to back up everything before running the update. Please let me know how the update goes for you.

Sean

Sean - thanks for following up. I thought this post had reached a dead end so started a new one describing an error message. The wizard ran fine until somewhere in version 1.5, then froze because the table exp_sites was already existing. I figure I should delete the table and start the Wizard over again, but I’d like advice as deleting a table can really mess up a database.

Error: The following error was encountered:
Error Number: 1050
Description: Table ‘exp_sites’ already exists
Query: CREATE TABLE `exp_sites` ( `site_id` int(5) unsigned NOT NULL auto_increment, `site_label` varchar(100) NOT NULL default ‘’, `site_name` varchar(50) NOT NULL default ‘’, `site_description` text NOT NULL, `site_system_preferences` TEXT NOT NULL , `site_mailinglist_preferences` TEXT NOT NULL , `site_member_preferences` TEXT NOT NULL , `site_template_preferences` TEXT NOT NULL , `site_weblog_preferences` TEXT NOT NULL , PRIMARY KEY (`site_id`), KEY `site_name` (`site_name`))

Hi johnnyb,

it looks to me like when you reverted to your backup you left artifacts in the database from the upgrade. What I’d like you to do is revert to your original install and before doing the database completely delete it and then restore the back up.  Please see instructions on retrying after a failed up grade

Sean

Thanks - the link on retrying a failed upgrade makes it clear that I can’t just delete the table and restart the Wizard

However, I think I’m having problems understanding your language. First, I have no idea what you mean by “when you reverted to your backup.” 
I followed the update procedures at http://expressionengine.com/legacy_docs/installation/update.html exactly
  -  1. backup the database, config files & themes, and addons; take the site offline; clear caches.
  -  2. From the /system folder, upload the folders core, cp, db, language, lib, modules, plugins, updates, and utilities. and the file update.php.
  -  3. Verify file permissions.
  -  4. Run Update Wizard. 
None of that includes anything like “reverting to a backup.”  And I haven’t done anything further since the Wizard stopped.

Second, your suggestion to “revert to your original install” sounds like you want me to wipe everything I’ve done and start over from scratch using the backups. But that would wipe all the preparatory measures 1-4 noted above, and I’d have to do them again. That is no small task, and I don’t see the point. Seems to me the only problem is in the database, and the most I should have to do is wipe the existing database and restore the backup.

Except that if all I do after deleting the database is restore the backup, I’ll be recreating the exact conditions that caused the Wizard to fail the first time.  I’m going to have to remove the table exp_sites before the Wizard reaches the point at which it failed before, or it will simply fail again at that same point.

Again, this seems to be at least partly a language problem, the difference between where we’re at on the EE learning curve - I don’t get what you mean by “doing” in “before doing the database” either.

By the way, re: the exact version at which the Wizard failed: I opened the EE Control Panel for the updated site, and the current version is now 1.6. Apparently I misspoke about it failing at v1.5. I remembered the final 5, but it was apparently 1.6.5.

This raises another possibility.  What if I run the Wizard up to 1.6.4, and then stop there instead of pressing the button to continue to the next version?  Can that even be done? If so, how? If I could stop it at that point, it might make more sense to delete the exp_sites table from the database at that point.  If I re-started the Wizard after doing that, shouldn’t it automatically recognize the current version as 1.6.4, and continue the update from there?

Also, can you tell me exactly what exp_sites would be? It sounds like a config element.
Thanks

On inspecting my original database, it’s clear that it contains no “exp_sites” table whatsoever. Therefore, that table must have been added by the Update Wizard during one or the other of the earlier version updates.  Yet the presence of that table is exactly what caused the Wizard to fail on further version updates.  This seems like a complete Catch-22, a problem entirely within the Wizard, having nothing to do with the existing database.  Please advise.

We’re continuing this discussion in a new thread, so I’ll close this one for consistency’s sake.