I have a site that is on 9.2.5. The client was on 5.6 until I rebuilt it from scratch in V9. The client hates V9 so much I almost lost him but since there’s a lot he doesn’t like, I’ve been waiting to see if the UX improves before upgrading the site. We can’t wait any longer so I need to upgrade for security even if UX hasn’t changed much. The Dashboard is telling me I can jump right to 9.5.4 but my past experience tells me that oftentimes that’s a bad idea. Anyone have any experience jumping this far in one shot?
Within v9 jumping straight to latest is safer than introducing intermediaries. Take the usual backup and go for it in one big bang.
If there are any overrides or extensions of core classes in application or packages, some function signatures have changed, so there may be some minimal fixes needed, especially to do with how block templates are resolved.
Thx. I appreciate your advice. I’ll back it up to my localhost and give it a shot locally first. There has been a few mods put into this this site but it was a few years ago so I can’t remember them all.
Running updates locally is our standard procedure. At least you have a chance to see what might break before committing to a production server.
Obviously, once you’ve done it on the production site, you could still run into other problems due to differences in server configuration, but at the least, you’ll have confidence on the majority of functionality.
Curious as to why skipping inbetween updates within v9 is the better approach.
Doing it all in one go is a lot less work. Its faster and simpler so considerably less vulnerable to human error or interruption.
The actual migrations applied are usually the same whether you go through steps, or do it in one big jump. But occasionally a migration has a bug, and the next migration fixes that bug. Jumping through skips such bugs.
Later minor versions are usually later because bugs in previous minor versions have been fixed. One big jump to the latest minor version skips such bugs.
Each update can leave debris. One big jump is usually cleaner because it skips intermediate debris.
As an example, in early v8.5 there was a bug in the automated update process that prevented further update. The next 8.5 version fixed that, but for anyone going through the problem version they were stuck and had to update manually.
All working. Thanks. I had to update Container Magic for 9.5 because it was killing the dashboard so I bought a new copy and installed it manually and all is well. Thx everyone.
On the doctrine thing. This is the first time I’ve had an update fail and leave the proxies crippled. I copied them back from a backup but why are they in the application folder to begin with? This sort of breaks the architecture so it’s not so easy reverse a failed update by pointing the update.php file back to the old version. Am I being dense?
I think they are generated files.
In the dashboard try turning off database entities or refreshing database entities (or both).
If necessary, you can also hack the flag in application/config/generated overrides/…
I couldn’t get to the dashboard and I didn’t see any hackable entries in the config files. So I think you might be suggesting that the crash was not because the proxies didn’t get generated? I can’t really tell if that was the problem at all.
Yes, in the dash db entities need to be set as Doctrine Development Mode - On before the update.
Hacking config, genertated_overrides/concrete.php, the key is concrete.cache.doctrine_dev_mode, set it to true.
In the CLI, you can use
concrete/bin/concrete c5:entities:refresh --help
concrete/bin/concrete c5:config --help
In addition to the excellent points John made, there is another good reason:
Let’s assume there are three versions of Concrete.
- Version 1 is the one you have installed.
- Version 2 is released with a “migration” (i.e., code that performs specific data migrations).
- Version 3 might contain fixes related to that migration (fixing bugs found after 2 was released).
Therefore, by jumping straight to the latest version, you could benefit from improved intermediate migrations.