ugrading 1.4.x to 1.4.13, leaving Fantastico behind

[henry]

Folks:

My hosting service provided cpg 1.4.12 via Fantastico;  I've seen the arguments for upgrading to 1.4.13 and for leaving Fantastico behind; I've read the upgrade docs (http://coppermine-gallery.net/demo/cpg14x/docs/index.htm#14) and I'm almost ready to do a manual upgrade. 

Except... I'm concerned about the transition away from whatever Fantastico has done in the way of setup. Before I upgrade, I'd like assurances that the existing setup will be brought forward as long as the old include/config.inc.php and anycontent.php are preserved.   I'm thinking of the connections to mySQL, and worried about how I would re-establish these if the upgrade procedure goes awry.

Assurances?   Does the upgrade usually go smoothly? What most commonly goes wrong?  Anything further to do to make success even more likely?

Note:  for all the criticisms of Fantasico I've found on this board, it did provide cpg, a recent version -- I might have never found cpg if a Fantastico installation had not existed, and the installation process was trivial.

TIA,

Henry

[Joachim Müller]

Please read the page about Fantastico in the preliminary docs for cpg1.5.x - the explanation there is valid for cpg1.4.x as well. Pay attention to the section at the very bottom:

But do not worry: we won't leave you unsupported. Usually, you don't have to un-install your auto-installed Coppermine gallery and re-install our version; just perform an upgrade as suggested in the upgrade section of the documentation (even though the version number of your auto-installed gallery appears to be the same as they most recent "original" Coppermine package) and you should be fine.

So basically, you can rest assured: nothing can go wrong if you do exactly as suggested in the docs; after all, you're required to backup everything before upgrading - if anything should go wrong, you can savely go back.
Usually, there's nothing to be concerned about.

[henry]

GauGau:

Thanks for your reply, the information in the 1.5.x docs, and the assurance of help!

Well, as it turns out, I ran out of time and I went ahead and did the manual upgrade, and I had no real problem. 

It was a momentary mystery how to backup the database, but I eventually found a host control panel that did the trick. (Maybe  the doc could say something brief about how this is done generally, what to look for.)

I also had a brief bad moment when I couldn't locate "anycontent.php", which I'm supposed to save -- but I discovered it is optional and I had not created one. (Be nice for the doc to mention "optional -- won't exist unless you create it").   

As I said in my original post, I was a bit nervous about the mysterious bits, such as how I would re-establish a connection to the database had my upgrade attempt failed and I was forced to start from scratch.   I have no idea whatsoever how a php app talks to a database; I don't expect you to teach me in the cpg docs, but, I dunno, maybe a pre-install script to reveal potentially useful information -- other side of the coin to the "check file versions" run afterwards, maybe.

The largest "issue" was managing files between the folder containing the new version, the local copies of the installation, and the server files.  It's a bit unnerving to have to sort these out manually, seems accident-prone, to be done only when one is fresh and coffee'd up.     

If the install/upgrade procedure is going to require such hands-on care, maybe it could be structured to merge into a new directory, so the old installation could be left functioning until a very specific, unitary switch-over action, one that's easy to reverse, too.  Just an idea.

Solved!

Thanks,

Henry
 

[Joachim Müller]

I went ahead and did the manual upgrade, and I had no real problem.

Good to hear that.

It was a momentary mystery how to backup the database, but I eventually found a host control panel that did the trick. (Maybe  the doc could say something brief about how this is done generally, what to look for.)

There are several different possible options, all of them being covered in detail on the board. For reference: best options are "Plugin Backup: backup and restore the database", "Tools recommended by the devs -> mySqlDumper" and "Tools recommended by the devs -> phpMyAdmin"

I also had a brief bad moment when I couldn't locate "anycontent.php", which I'm supposed to save -- but I discovered it is optional and I had not created one. (Be nice for the doc to mention "optional -- won't exist unless you create it").

That's not true: the coppermine package we provide contains the file anycontent.php, which is by default empty and not being taken into account, so it won't hurt if your package didn't contain such a file. However, there's no fix needed for the docs - the file anycontent.php comes with coppermine out of the box, but is optional.

how I would re-establish a connection to the database had my upgrade attempt failed and I was forced to start from scratch.   I have no idea whatsoever how a php app talks to a database;

The mysql data that are used to establish the connection are being stored in include/config.inc.php, that's why you're supposed to save that file. It is being created during install, so it doesn't come with the package. Therefor, you can hardly overwrite it by accident. That's one of the many reasons why we're convinced that our app is well-designed: you can hardly break it by accident.

maybe a pre-install script to reveal potentially useful information -- other side of the coin to the "check file versions" run afterwards, maybe.

Is already in the dev-pipeline for the next coppermine version cpg1.5.x 

The largest "issue" was managing files between the folder containing the new version, the local copies of the installation, and the server files.  It's a bit unnerving to have to sort these out manually, seems accident-prone, to be done only when one is fresh and coffee'd up.     

If the install/upgrade procedure is going to require such hands-on care, maybe it could be structured to merge into a new directory, so the old installation could be left functioning until a very specific, unitary switch-over action, one that's easy to reverse, too.  Just an idea.

Can't replicate the issues you had. Simple process imo: make the backup using your FTP app * upload the fresh files from the fresh package * perform the database update. Can't get much easier than that. Even more advanced way is bound to break for other reasons (ownership and permission issues on webserver level that would be even harder to troubleshoot for newbies).