Rebuild Concrete5 in WAMP

Installation
1

Hello

I try to debug an existing Concrete5 Version.
The hoster changed php version to 7.4.x and now the site doesnt work anymore.

As suggested in /t/update-from-8-3-2-to-8-5-7-via-folder/2674/8
I try to rebuild concrete5 with WAMP, so I can upgrade the files and copy back to the hoster.

Here some specifications:
Concrete5 Version 8.2.1 which was upgraded to 8.3.2 (not sure if this important. And also not sure if the update was successfull.)
Inside concrete/config/conrete.php it says version 8.2.1
but there is also a updates/concrete5-8.3.2 folder
and
application/config/update.php file

Here are the settings of the current server and which one I chose in wamp:
MariaDB 10.3.34 → wamp mariadb 10.3.4
PHP ? → i try with 7.1.33 (but i have also 5.6.40, 7.2.x, 7.3.x, …)
phpmyadmin 5.1.1 → wamp phpmyadmin 5.1.1
webserver nginx/1.20.2 → wamp appache 2.4.51

I exported the database via phpmyadmin.
The import was done via mariaDB console without error.

When I copy the original files into wamp www folder, connect to database and open site I get the error:

Class Concrete\Core\Permission\Key\ExpressEntryKey does not exist

I tried to copy the file from a original downloaded concrete5 package as suggested here: Unexpected Error after Upgrade - concrete5

(I found the file inside 8.5.7 version but not inside 8.2.1 or 8.3.2) → Something wrong with correct version?

When I copy concrete5-8.5.7\concrete\src\Permission\Key\ExpressEntryKey.php
to
this folder in my installation:
updates\concrete5-8.3.2\concrete\src\Permission\Key

The error message turns into:
Class Concrete\Core\Permission\Access\Entity\SiteGroupEntity does not exist

Is the problem related to this?

Thanks in advance for any help.

2

With any cloning from a production site, things like the concrete cache and database entities often result in spurious errors. I am not saying that what you are experiencing is a spurious error, but a first step is always to reduce that possibility.

Before you go any further, you should disable all caches and put database entities into development mode.

If the source site was working, you could do that before making the backup. As it was not working, you will need to dig through /application/config files to find the settings and edit them directly.

If you have another working site, you can use that to create appropriate fragments of the records in /application/config php files and paste them in.

This probably won’t resolve your problem, but it will eliminate one group of possibilities and make subsequent debugging easier.

As you are on a WAMP host, you also need to make sure your database is configured to be case sensitive before importing. Otherwise you could get to the end of debugging, only to find your now fixed site fails to work when moved back to the live server.

3

I was able to get something appearing locall by dissabling the cache and putting the database entities in development mode. Thank you very much for pointing it out. It seems there are still some small errors in the design. (which we can probably solve with much less effort.)

As google suggests, I can’t turn on case sensitivity in wamp. :frowning:

but if I cant copy it back I probably have to abandon this idea.

4

Case sensitivity is somewhere in your MySQL configuration. The first result I found in Google should help.

You will need to do this before importing the database.