My hosting recently migrated from Mysql 5.7 to Mysql 8, since so my website that have been working perfectly is now broken / down (i m freelance architecte specialized into CG, so my website is mostly a portfolio gallery).
i came across some threads on the forum talking about known issues with migrating to Mysql 8, but for older versions on Concrete5 (5.x versions), the fix was to edit all the files containing “group” word to replace each occurence with “‘group’”, since for mysql 8 “group” or “groups” is reserved keyword.
Badly, the directories and files pointed in this thread do not match 8.x version directories.
Can someone point me to the easiest way to fix this problem, without having to remake the whole website from scratch ?
I m not a professionnal dev, i have spent various monthes learning and working on a theme design and customization of some addons, but there is 3 years that i didnt look at it, so i feel totally rusty and near to desperate.
Since my website is down, ofcourse i cant login to try updating concrete5 (even if i m afraid of not getting a smooth upgrate, regarding addons compatibility and customizations i made, that is part of the reason i didnt update the core until now).
I m not sure how a fresh install + restoring backup from actual version could work.
I also would like to know what is the oldest concrete5 version that can run under Mysql8 (for compatibility reasons i would choose the next to 8.3.2 version that can handle mysql8 with no problems) ?
Once again, I would really appreciate if someone can help me to solve this issue the most simple way.
I expect the MySQL issues are with something to do with you being logged in and hence seeing the dashboard bar and panels.
If you have cPanel and CLI access, I would try updating concrete to 8.5.14 using the ’ Replacing the original Concrete Directory ’ and ’ Upgrading via the command line’ sections of How to Upgrade Concrete CMS
Take a database backup first.
Prepare the new core in a /concrete_new dir.
Keep your old concrete by renaming the /concrete dir to /concrete_old
Then rename /concrete_new to /concrete.
Then run the CLI update command.
Then once you are confident the site is all well, remember to clear out /concrete_old
It is a kind of “bad timing”, at the same time i started to investigate the problem, i managed with my hosting service to be able to use the old version of mysql at least the time to find a solution to upgrade my site.
As i said to TMDesigns, my hosting decided to keep some servers with the old Mysql for a while, so at the time you checked the site it was up again.
That will let me have the time to upgrade i hope the most smoothly possible, and i will have a look at your post again when i can take care of that (tho i m not sure i can have CLI access and i m not used at all to this).
Please try updating your Concrete5 version to the latest release compatible with MySQL 8. As for the group keyword conflict, you might need to manually review your files for any occurrences of group and enclose them in backticks to resolve MySQL 8 reserved keyword conflict.
I m about to make the move to upgrade my site (i didnt have time to deal with this until now).
I have access to dashboard and my site is working fine, so i m not sure i need to upgrade using the ‘Replacing the original Concrete Directory’ (since i dont know anything about CLI access), i really want to use the most simple and secure method.
So i guess i can download the concrete version i want, and copy it to my upgrade directory, this is correct ?
Do you or anybody else know what is the oldest Concrete version that works fine with Mysql 8 ?
Because it seems 8.5.14 is a big step from 8.3.2, and i use at least one block addon (Whale Grid gallery) that is not updated from long time, i would really like to keep using this gallery, because i customized it to use Express objet to associate and display datas linked to each image files.
About the process itself, i already made a database backup, is it ok to also backup only the ‘Application’ directory of my site ?
Latest v8 is now 8.5.17 and should be compatible with MySQL 8.
If you use the ‘Replacing the original Concrete Directory’ method, the upgrade will use all-new code when it then runs. If you use any other method, some of the existing code will be involved to varying degrees.
I would expect the upgrade to work in one big jump, but I have never needed to find this out the hard way (anyone else - please correct me on this). The whale gallery should continue to work with any v8 and compatible php version, but check with the developer to make sure.
Turn off and clear caches before making a backup of the /application directory. Put database entities into development mode. Enable full debug output. Set maintenance mode.
I usually upload the new core as /concrete_new
Then when everything else is ready rename /concrete to /concrete_old and rename /concrete_new to /concrete.
Run the manual CLI update
Be prepared to revert by recovering the database and reversing the renames.
The most likely issues are character set errors with oAuth and Express. There are forum threads on dealing with that.
How and from where do you do that ? You first talked about CLI access, and i dont know what it is or how to use it.
From your first link and ‘Replacing the original Concrete Directory’ method, the last step might be 4. Visit your site in a browser.
For ‘Upgrading via the command line’, i m lost from here :
3. ssh into your web server and enter the web directory
And i dont know where to type command lines like ./concrete/bin/concrete5 c5:update
I have another dumb question, i m actually making a backup of /application directory via FTP client, it takes ages with thousands directories that are in /files, is there a way to speed up this backup ?
ssh is jargon for a command line secure terminal login. In many cases cPanel provides a web interface with a terminal already logged in, which saves a lot of bother.
The cPanel file manager can be used to get and unzip the v8.5.17 core, which is usually easier than doing so through the terminal
The part that you really do need the terminal for is to actually run the update command.
Yes it does, but its not as robust. When visiting in a browser the php execution time is limited. Hence the migrations (a series of files implementing aspects of the update) get spread across multiple page views. It is supposed to be proof against such, but …
When run from the command line, there is no execution limit, so all the migrations run in one batch. Altogether a more robust and reliable method.
