Attempting to refresh my local dev environment with data from production, I restored a production backup to the local database. I encountered this error when trying restart the local site:
“Call to a member function getConfigRepository() on null”
This apparently occurred when trying to retrieve timezone configuration:
From the stack trace:
5 Error
…\src\Foundation\Runtime\Run\DefaultRunner.php166
4 Concrete\Core\Foundation\Runtime\Run\DefaultRunner initializeSiteTimezone
…\src\Foundation\Runtime\Run\DefaultRunner.php326
It seems that there may be configuration information in the database that conflicts with my local site. I wondered if there is a way to restore the content data without site configuration that might conflict.
An additional note. It occurs to me that this might be due to a missing file referenced by something in the database. I wonder anyone has a clue for me about configuration associated with site timezone, or any other suggestions to solve this error.
Take a look at the app.php file in the application/config/generated_overrides folder.
Helpful suggestion. The app.php file is identical with the production site. However, there were some differences in concrete.php and site.php. May be worth a try to synchronize this with the production version. I’ll post my results.
The usual issues with cloning a site are to do with cache settings and database entities.
Before making the copy, disable and clear all caches and put database entities into development mode (find it with the dashboard search).
Then your cloned site should only need to set the local database credentials in config and it will be ready to run.
I have often cloned sites into different timezones. You may need to change timezone settings, but should not get such a code error. That could be a secondary error.
Syncronizing the overides directory and deleting cache directory did not help. Johnthefish was right about it being a secondary error. On closer inspection of the stack trace I see that the exception occurs on:
$siteConfig = $this->app->make('site')->getSite()->getConfigRepository();
concrete\src\Foundation\Runtime\Run\DefaultRunner.php 166
The subsequent line loads the timezone. So apparently, the real problem is that we cannot instantiate the site config repository itself.
The suggestion made by johnthefish sounds promising. I’ll do another production backup with the procedure he outlined.
If you dig through the application/config php file, you can put the database into dev mode and disable caches on your clone. But making a clone without the settings is a better approach.
When cloning a site with many old page versions etc, I also use my Extreme Clean addon to get rid of any history I don’t need for the clone. It can make a big difference to the time to backup, download, import a database.
Thanks johnthefish. I’m back in business now. Very helpful suggestion. I’ll make it part of my check list for site cloning.
As JohnTheFish said, it looks like cache problem.
You can try to clear cache with following two methods.
If you know how to handle CLI via SSH terminal.
You can run cache clear command
concrete/bin/concrete5 c5:clear-cache`
*if you are running web server as apache or nginx user, you must execute the cli as those users.
If you don’t know how to run CLI command, no worries…
Go to application/files/cache folder and delete everything underneath.
Depends on how many files the directory has, it may take some time to delete.