3

If it's a new environment with your staging database, then run this on your new production environment: ./craft project-config/rebuild This will force-dump the config into the project-config YAML files from scratch, and include any small changes that might have happened to make way for the new environment, including pesky caches.


2

I'm not familiar with this plugin, but could probably do this in your template where the plugin is called: // Get the environment {% set env = getenv('ENVIRONMENT') %} // If anything but dev, then load the plugin {% if env != 'dev' %} {% include ['_recaptcha/frontend'] %} {% endif %} You can also get the environment from the config: {% set env = ...


2

If I create a folder assets at that location it works. I don't know what this asset folder is about.


2

You have options, but most people probably do the following... Apply the updates locally. Push those changes to the server. Have Craft run any necessary migrations. My deployment process ends with the following command being executed on the server: composer install --no-interaction --prefer-dist --optimize-autoloader --no-dev And in my composer.json file,...


2

You can rebuild your project.yaml by running ./craft project-config/rebuild. In terms of workflow here's a good article that discusses it.


2

P&T recently released an update with a new console command: project-config/rebuild This does exactly what it sounds like, it rebuilds the config ...


2

Even if useProjectConfig was set to false, it's not a good idea to update Craft on a live site because, as you've discovered, errors sometimes happen. There's even an allowUpdates config setting that we recommend people setting to false on the live site just so someone doesn't accidentally update Craft from the control panel. The safer workflow is to have ...


2

Based on your comment that you get an error saying Craft is not installed, to me that suggests the bash script does not have access to your environment variables, (this can also be a problem when running cron jobs). To remedy this, create an env text file to export all the same values as those in your production env variables. For this example name it ...


2

No, you would not check these files into Git. I have a .gitignore rule to just ignore everything in storage/ and so I treat it as a cache directory. Which it is... except for the unfortunate fact that any rebrand (logo, icon) files are stored in storage/ as well. But I just manually add them in via git add -f


2

You could achieve this using Aliases. In your .env, you could set DEFAULT_DOMAIN="yourdomain.com" then in your config/general.php you would do: 'aliases' => [ 'siteAbc' => 'http://abc.' . getenv('DEFAULT_DOMAIN'), 'siteXyz' => 'http://xyz.' . getenv('DEFAULT_DOMAIN') ], With this in place, you will be able to use @siteAbc and @...


2

Craft 3.6.10 is out now with a fix for #7657. Note that the fix is not retroactive, so if you already have multiple sites in your project config YAML with primary: true, you should run php craft project-config/rebuild to fix that.


1

Manually updating the project.yaml file is not recommended, in my opinion, especially if adding your own custom settings. It is not intended for manual editing and can be rebuilt from the database, if prompted to. Instead, I would create a config settings file in the /config directory and pull in the settings, similar to how the plugins service does (another ...


1

You can use the plugin/install command for the ./craft cli utility, I'm not sure if you're aware of this: https://craftcms.com/docs/3.x/console-commands.html#plugin-install You'll need to know the plugin's handle, but that's all you need. I've never tried specifying multiple plugins in the one command, but that's an easy one to test. Now, as to why you're ...


1

You probably just need to clear the Craft storage/cache folder on production. Licensing info is cached for 24 hours at a time.


1

solved it with a rebuilded project file locally.


1

I think P&T changed the behavior in Craft 3.1.0 and newer. Before 3.1.0 it was necessary to have 'allowAdminChanges' => true with updates in/to project config. To be 100% safe you can always enable admin changes when you're on the command line by using this config line in production environments: 'allowAdminChanges' => (php_sapi_name() === 'cli'),...


1

Just stick with the .gitignore of Craft. https://github.com/craftcms/craft/blob/main/storage/.gitignore I assume it's better to commit the folder, as config-deltas is not in the official .gitignore.


Only top voted, non community-wiki answers of a minimum length are eligible