Database Upgrade to v9.1.3

Developing with Concrete
1

Hey Community

As a few of you have noticed from my earlier posts i am upgrading some apps to v9.1.3.

My process is the following:

  1. copy the live Site to a similar local dev env
  2. upgrade concrete (we use composer)
  3. fix all the things that needs fixing
  4. create a new instance on a php8 server > composer the whole shablang there

now is the problematic part: i need an upgraded db for the v9 site. i get that from my local setup that is sucessfully upgraded BUT between steps 1 and 4 there might be days (weeks) where the customer has made changes so i need to pull the live db again and set up a dummy concrete instance on v8 to connect to the production db and upgrade it again so i have a ready db for production v9

Is there any way to upgrade a v8 (8.5.9 / 8.5.7 / …) database to be used in a v9 app? Or are there better alternatives to my workflow?

Thanks

2

You don’t need php8 for v9. Making php8 a second exercises will avoid too many changes in one go.

After steps 1,2,3 in php7.4 most of the fixes you will have made will be in code, but there may have been some database fixes. Keep a step-by-step record for code & database fixes.

At that point repeat 1,2,3, but using your already updated code on a clone of the latest database & files copied from the live site. Use your record to re-make any database fixes. This should be fairly quick and can be done with the client told not to make any changes and/or the live site in maintenance mode. Less than a day.

Then update the live site from the successful offline update. The client can now resume editing content.

Then do the second exercise of updating the v9 site to php8. This will be a code only change, so doesn’t involve copying a database back to the live site. Just copying updated code from dev to live.

1 Like
3

Thanks for your reply.

I do not alter anything on the db by hand while fixing/prepping the site for v9. The only changes to the db (structurally) are done in the upgrade process.

“At that point repeat 1,2,3 …” so that is the part i want to avoid. I agree to a maintenance window of a day or so where te client stops editing, that is not the problem. I want to avoid racking up another concrete instance on the version before and update that locally to have a v9 ready db. So i am looking for alternatives so i don’t have to repeat steps 1-2.

4

I don’t think there is any shortcut to that.

However, if the first pass of 1,2,3 takes < 1 day, you could update the live site from that and skip the second pass. But to make that possible the client would be unable to edit or site in maintenance mode from the start.

Worst case, you would realise it would be > 1 day, so let the client back in cancel any maintenance mode, then need to fallback on a second pass and the client would have a second period of no editing or maintenance mode later on.

5

Well i just sped up the process a bit by doing this:

  1. composer create-project concrete5/composer=1.2.0 c5_to_upgrade
  2. connect the v8.X.X db i exportet from live
  3. composer require -W concrete5/core:9.1.3 (might have to kick out doctrine/dbal from composer.json so it does not clash)
  4. log in to the dashboard at the site. it will be botched and looks super messy since there are no packages installed that are required and present in the db but whatever
  5. the db is now ready for the “real” v9.1.3 concrete app and the local “c5_to_upgrade” instance can be razed

so basically it seems not to be required to set up the whole app with packages and all, just get a v8.5.[7/12] instance running and update that with te database to be upgraded connected.

i guess without composer it could be similar but not tested

edit: after step 4 i can disconnect the db and do

composer require concrete5/core:8.5.12

to downgrade again (better have the db disconnected so nothing happens there). now rm -rf public/application/files/cache and you are ready for another run. No need to compose a new app.