Failed update 8.4.4 -> 9.2.8 + deleted folder in updates directory

Installation
1

Unfortunately I cannot report what I’ve done exactly but my original endeavor was to update from 8.4.4 to 9.2.8.

  • I put the 9.2.8 package to the updates folder and removed all directories except for the concrete directory in the extracted folder I got.
  • stupidly, I also deleted the two folders of some older upgrades (they were named something along the lines of concrete5-<version>_remote_updater, not completely sure)
  • Then I changed the referenced core in application/config/update.php from the (now deleted) directory to concrete-cms-9.2.8.
  • When I tried to update, I got a message that my php version was too old so I changed it from my provider’s control panel to php 7.4
  • After that I got some error saying the base_dir restriction was active and since it seemed to have something to do with the memcached caching method I changed that to filesystem on my provider’s control panel.
  • Then I got some errors apparently related to missing columns in the mysql db:
 Doctrine \ DBAL \ Exception \ InvalidFieldNameException
An exception occurred while executing 'SELECT t0.siteID AS siteID_1, t0.pThemeID AS pThemeID_2, t0.pThemeSkinIdentifier AS pThemeSkinIdentifier_3, t0.siteIsDefault AS siteIsDefault_4, t0.siteHandle AS siteHandle_5, t0.siteTypeID AS siteTypeID_6 FROM Sites t0': SQLSTATE[42S22]: Column not found: 1054 Unknown column 't0.pThemeSkinIdentifier' in 'field list'
Previous exceptions

    SQLSTATE[42S22]: Column not found: 1054 Unknown column 't0.pThemeSkinIdentifier' in 'field list' (42S22)
    SQLSTATE[42S22]: Column not found: 1054 Unknown column 't0.pThemeSkinIdentifier' in 'field list' (42S22)

Now I can’t access my site, let alone the control dashboard anymore. I learned after the fact I shouldn’t have deleted the folders in the updates directory.

I then tried to extract a 8.4.4 package to the updates directory (and referenced it in update.php) in the hopes of getting my installation to work again. I had to change some continue statements to continue 2 in some obscure file, after which I arrived at this error (application/config/doctrine/proxies/__CG__ConcreteCoreEntityFileFile.php:9):

Whoops \ Exception \ ErrorException (E_WARNING)
Declaration of DoctrineProxies\__CG__\Concrete\Core\Entity\File\File::delete() should be compatible with Concrete\Core\Entity\File\File::delete($removeNode = true)

So my question is – am I screwed? Is my site lost or in an unrecoverable state (I spent quite some time customizing the Elemental theme to my requirements)? If not, is there a way to actually get it to update to 9.2.8, or at least back to 8.4.4 or the latest version in the 8 series?

2

You can’t go direct from 8.4.x to v9. The update path would be in 2 steps from 8.4.x to 8.5.latest. Then 8.5.latest to 9.2.latest.

As these are big steps and likely to timeout, best to use the CLI method How to Upgrade Concrete CMS.

The v8 to v9 update will usually also need to manually fix the character sets for oAuth tables and possibly some Express tables (whether you use them or not). There have been recent forum threads on fixing such.

As for your failed update. There is no easy recovery from where you are at. An experienced developer may be able to hack various files and database tables into shape, but I don’t think anyone can offer a guarantee of success and it is not something that can be done with a few tips through the forums. Best to recover the 8.4 site from a backup and start the process again.

Some of your error messages suggest the theme may not be compatible with v9. So also check theme and addon compatibility and update paths before trying again.

3

First off: thanks for the quick reply!
I also tried to update to 8.5.16 now but I got a different error (updates/concrete-cms-8.5.16/concrete/vendor/tedivm/stash/src/Stash/Driver/FileSystem/NativeEncoder.php):

 Whoops \ Exception \ ErrorException (E_WARNING)
include(<root>application/files/cache/expensive/0fea6a13c52b4d47/25368f24b045ca84/38a865804f8fdcb6/57cd99682e939275/2ddb27c5cdf0b672/745d4c64665be841/50c918ae53514cb2/4443a5f892a089b3.php): failed to open stream: No such file or directory

Can I do something about that?

4

Disable all caches in the dashboard before updating. Clear the caches so no ghosts remain. Also put the database entities into development mode. Put the site into maintenance mode so no users get in the way.

5

I now got another error (updates/concrete-cms-8.5.16/concrete/vendor/doctrine/dbal/lib/Doctrine/DBAL/DBALException.php):
´``
Doctrine \ DBAL \ DBALException
Unknown column type “datetime_immutable” requested. Any Doctrine type that you use has to be registered with \Doctrine\DBAL\Types\Type::addType(). You can get a list of all the known types with \Doctrine\DBAL\Types\Type::getTypesMap(). If this error occurs during database introspection then you might have forgot to register all database types for a Doctrine Type. Use AbstractPlatform#registerDoctrineTypeMapping() or have your custom types implement Type#getMappedDatabaseTypes(). If the type name is empty you might have a problem with the cache or forgot some mapping information.

6

You may be able to get round the error message post-update by manually editing the config to disable the caches and then deleting all sub-directories beneath /cache/

7

The DateTime exception may be because the databse entities are not in development mode

8

Else look back through the forums, the DateTime column type error has shown up on updates for others and I think solutions have been posted.

9

Hey, that actually worked! I’m so happy! Thank you!
I did

php ./concrete/bin/concrete5 c5:config -g set concrete.maintenance_mode true

and just reloaded the page that had shown the error.

10

site maintenance mode is not the same as database entities development mode.

11

Still it worked for some reason…
I wonder whether I should dare to upgrade to 9 now.

12

Test thoroughly at 8.5.latest and make sure what you have is reliable for a few days. Then make a new backup before attempting v9.

Research the oAuth tables issue on the forums.

13

I spoke too soon )o: After I logged out and logged back in again, I got

 Whoops \ Exception \ ErrorException (E_COMPILE_ERROR)
Doctrine\Common\Proxy\AbstractProxyFactory::getProxyDefinition(): Failed opening required '<root>/application/config/doctrine/proxies/__CG__ConcreteCoreEntitySiteType.php' (include_path='<root>/updates/concrete-cms-8.5.16/concrete/vendor:.')

I’ll do that although it looks like yet some different problem now.

14

You have a classic manifestation of not doing the above

15

OK, thanks! I’ll research how to do that.

16

Disable all caches in the dashboard before updating. Clear the caches so no ghosts remain. Also put the database entities into development mode. Put the site into maintenance mode so no users get in the way.

I can’t seem to find a way how to do that from the cli (I cannot log in to my admin account anymore) )o:

All I found was:

./concrete/bin/concrete5 c5:clear-cache
./concrete/bin/concrete5 c5:entities:refresh

When I tried the latter I got:

                                                                            
  Unknown column type "datetime_immutable" requested. Any Doctrine type th  
  at you use has to be registered with \Doctrine\DBAL\Types\Type::addType(  
  ). You can get a list of all the known types with \Doctrine\DBAL\Types\T  
  ype::getTypesMap(). If this error occurs during database introspection t  
  hen you might have forgot to register all database types for a Doctrine   
  Type. Use AbstractPlatform#registerDoctrineTypeMapping() or have your cu  
  stom types implement Type#getMappedDatabaseTypes(). If the type name is   
  empty you might have a problem with the cache or forgot some mapping inf  
  ormation.
17

This is what I get when I try to log in to the admin account (but I guess that’s a symptom of not having the “database entities in developer mode”):

An exception occurred while executing 'SELECT t0.iaccID AS iaccID_1, t0.iaccHandle AS iaccHandle_2, t0.iaccName AS iaccName_3, t0.iaccEnabled AS iaccEnabled_4, t0.iaccMaxEvents AS iaccMaxEvents_5, t0.iaccTimeWindow AS iaccTimeWindow_6, t0.iaccBanDuration AS iaccBanDuration_7, t0.iaccSiteSpecific AS iaccSiteSpecific_8, t0.iaccLogChannel AS iaccLogChannel_9, t0.iaccPackage AS iaccPackage_10 FROM IpAccessControlCategories t0 WHERE t0.iaccHandle = ? LIMIT 1' with params ["failed_login"]:

SQLSTATE[42S02]: Base table or view not found: 1146 Table 'mydb.IpAccessControlCategories' doesn't exist
18

As suggested in Update concrete 8.5.1 to concrete5 9.0.1 - #9 by AsnanBilal01 the cache should be disabled and “doctrine/entities” should be put in development mode.

I tried now to put something in development mode but I don’t know whether that is the “doctrine/entities” or “database entities”:

./concrete/bin/concrete5 c5:config set -g concret
e.cache.doctrine_dev_mode true

I grepped for _dev_mode and this was the only option I could find.

The values in application/config/generated_overrides/concrete.php seem to suggest that caches are disabled and that development mode is enabled:

'cache' => [
    'blocks' => false,
    'assets' => false,
    'theme_css' => false,
    'overrides' => false,
    'pages' => '0',
    'full_page_lifetime' => 'custom',
    'full_page_lifetime_value' => '0',
    'last_cleared' => 1714931730,
    'themecss' => false,
    'themecsss' => false,
    'doctrine_dev_mode' => true,
],

I cleared the cache:

./concrete/bin/concrete5 c5:clear-cache

And I still get the error when logging in:

SQLSTATE[42S02]: Base table or view not found: 1146 Table 'mytableIpAccessControlCategories' doesn't exist

And when trying c5:entities:refresh Unknown column type "datetime_immutable" requested.

I found this thread IpAccessControlCategories - concrete5 with the suggestion to set values in a table using an SQL command but that table does not exist, so I tried to create that table but apparently I need to know the data types of the columns which I could guess from the values (bools, ints and strings) except for the last column whose data type I can’t fathom (blob? If so, which size?).

I’m confused/stuck here.

19

Do you mean 1 : mytableIpAccessControlCategories
or 2 : IpAccessControlCategories ?

The first definitely is not a core table. Any code referring to that is erroneous.

The second is a core table. The easiest way to recreate it is to dump the schema for that table from another site (just the schema, not the content) and then import the schema to the site you are updating.

20

I meant 2 (IpAccessControlCategories).
Unfortunately, I don’t have access to the db of another site.

So it looks like my only option is to try to get hold of a backup of my site from my provider prior to my screw-up.