Update from 8.3.2 to 8.5.7 via folder

Installation
#1

The provider of the site updated the php version to 7.4.28. which lead to the site not working anymore. I am no resposible for the site but i am helping to resolve the issue.

Because the site is not working anymore I am trying to update/upgrade it from 8.3.2 to 8.5.7.

According this page: System Requirements for concrete5 (concretecms.org)
I need at least version 8.5.0 to work with php 7.4.28.

I followed the instructions here: How to Upgrade Concrete5
where I replaced the concrete folder with a new one. (replacing the original concrete direcory (Version 8 and above))

When I open the page i get the following error:

screenshot
screenshot1427×884 94 KB

How can I resolve the issue and update to 8.5.7 correctly?

#2

image
image708×296 9.5 KB

I’m not sure 100% if concrete.charset debug output refers to the database collation. If it does, perhaps changing the database collation to utf8mb4 via Concrete or phpMyAdmin may help. If the current database is using utf-8 I think it can cause some problems, not being able to store some 4 byte characters that are now required.

Make a backup before testing.

This is what I’ve been using:

image

#3

Have you tried to lower php version to old 7.x version (whichever you have set earlier, I guess for example 7.1?). Full support of 7.4 was added later in lifecycle of concrete5.8, so maybe installation process requires lower version of it? Just a hunch.

You can try to update it on localhost environment, if it is not possible on server.

#4

I tried to convert the database to utf8mb4_unicode_ci which was not successfull.
I only have php version 7.4.28 as a choice or 8.0.16 or 8.1.3
I tried to upgrad with the version 7.4.28 with different settings the whole evening but it didnt work.

PS: I am not sure if the version 8.3.2 was/is the correct old version. (Probably is though because apparently it worked 2 weeks ago.)

I asked the provider which PHP Version was active on the account but they dont know.

I tried a lot tonight and I always get the error: daytime_immutable as shown in the original post.

PPS: I probably could try which php version works locallly, but I probablly have to do that tommorrow because I lack of motivation right now.

#5

Did the conversion attempt (phpMyAdmin?) generate some SQL errors? If so, carefully reading those errors may ID the fields/records that need correcting.

A Google search for ‘mysql error "datetime_immutable’ indicates the problem may be related to collation.

I needed to get a severely out of date site (not ConcreteCMS) through a multistep update for PHP compatibility. The newer CMS version required utf8mb4. The fails seemed significant at first, but all it required was checking each error and manually fixing them one by one, which turned out to only be about 10 records.

Another suggestion to test the hosting environment, does a new default instance of Concrete v8.5.7 install and run okay?

#6

@fixt.org
When I click: change all table collation but without the column option I get no errors.
When I activate both I get an error:

ALTER TABLE ‘atEspressSettings’ CONVERT TO CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci

#1832 Cannot change column ‘exEntityID’: used in a foreign key constraint ‘FK_E8F67F0FCE2D7284’

But afterwards the collation in the overview is set correctly to utf8mb4_unicode_ci.

→ I didnt have time to google the error right now, but I will for sure do some research later in the evening.

Good idea. Yes I was able to install a new version. But I had to switch to none for open_basedir in the php Settings.
(The database of the new version is utf8mb4_unicode_ci)

PS: Conrete5 still not working.

#7

I forgot to mention another potential source of dB problems, check to make sure the dB user you are using has been granted the proper permissions.

My hosting dB manager does not automatically grant these permissions and it causes problems unless I enable them (grant all permissions):

  • Structure
    ** REFERENCE
    ** LOCK TABLES
    ** INDEX
    ** CREATE TEMPORARY TABLES

If you are using two different users for the two dB (upgrade and new test install), compare the permissions. My new installs fail with SQL query errors if the dB user doesn’t have all the necessary permissions even thought the pre-install environment test doesn’t seem to flag any problems.