<p>My guess ... this has nothing todo with project config:</p>
<ul>
<li><p>The missing plugins might have to do with a missing or corrupt file <code>vendor/craftcms/plugins.php</code> which is written by a Craft script and triggered by composer during <code>composer install</code></p>
</li>
<li><p>There was a recent change with composer which requires to explicitly whitelist every composer package (e.g. Craft) which is allowed to execute those scripts and therefor create this file</p>
</li>
<li><p>please check if you have the following lines in your <code>composer.json</code> (there might be more) within the config node of your <code>composer.json</code> file, they do this whitelisting:</p>
<pre><code>&quot;config&quot;: {
  &quot;allow-plugins&quot;: {
    &quot;craftcms/plugin-installer&quot;: true,
    &quot;yiisoft/yii2-composer&quot;: true
  }
</code></pre>
</li>
<li><p>now try your deployment again</p>
</li>
<li><p>the errors 500 might result from TWIG commands provided by one of your plugins which are not available due to the missing plugins</p>
</li>
</ul>

CC BY-SA 4.0
2022-07-19T01:18:31.983Z
Hi Matthias, thank you for the answer, this did solve my deployment issue - I'm running `composer v2.0.13` which according to the Craft docs you should only need to explicitly allow plugins if you're running `composer v2.2+`... or maybe I'm missing something? Anyways, I rebuilt the project config locally and added your recommended changes to `composer.json` and this fixed the issue. Thanks
Kyle Lambert
CC BY-SA 4.0
2022-07-18T11:08:08.250Z
2022-07-18T14:35:53.357Z
2022-07-18T14:35:53.357Z
Matthias Redl-Mann
<p>It might be a good idea before doing anything to understand what the specific 500 error being raised is. Enable dev mode so you can see the full error output, or look in the log files and paste the specific error here.</p>
<p>If it is project config related, to recover the dev environment, the best way is probably to apply a fresh copy of the database to your dev environment. You might also want to complete remove the contents of the config/project directory and once the restore completes let Craft rebuild it, which should be the same values in the production database. This gets triggered when loading the control panel.</p>
<p>Although project config is designed in the direction of propagating upwards, this can be occasionally done to recover from situations, but normally project config should be in source control and you shouldn't need to do this. Equally, make sure project config changes happen on local environments which then get pushed up to each environment in the chain ending at production.</p>
<p>Other than dev, make sure you don't allow admin change with the config setting, as this is potentially how project config can get messy:</p>
<p><a href="https://craftcms.com/docs/3.x/config/config-settings.html#allowadminchanges" rel="nofollow noreferrer">https://craftcms.com/docs/3.x/config/config-settings.html#allowadminchanges</a></p>

CC BY-SA 4.0
2022-07-19T01:24:07.497Z
Thanks for the answer James - I don't think my issue was config related after all, it seemed to be a composer package issue. Our project config is managed in git and `allowAdminChanges` is only applied in local environments so we generally don't have issues with the config - but yeah this only threw me a bit... possibly because of our overcomplicated Docker setup. Thanks
Kyle Lambert
CC BY-SA 4.0
2022-07-19T07:11:06.030Z
@KyleLambert Glad you sorted it, it's always good to have devMode on to see the full error trace in local/dev. "Internal Server Error" is just generic when not running devMode and won't tell you much without looking through logs.
James White
CC BY-SA 4.0
2022-07-18T07:06:37.000Z
2022-07-18T21:22:19.193Z
2022-07-18T21:22:19.193Z
James White
<p>Looking to get some advice on fixing some issues I'm having with my Craft DEV environment. I merged some changes which worked fine locally, but are causing some issues on my deployed version.</p>
<p><strong>Problems include:</strong></p>
<ol>
<li>Internal server errors when trying load entries</li>
<li>None of my plugins are showing in the dashboard (but appear to be included in the loaded project config). Re-applying the project config via the dashboard also causes 500 internal server errors.</li>
</ol>
<p>These changes have since been reverted, however the problems are still persisting.</p>
<p><strong>Things I've tried:</strong></p>
<ol>
<li>Revert the DB to a previous snapshot (same problems still persist).</li>
<li>Rebuild the project config locally then push the changes to DEV (same problems still persist).</li>
<li>Reapply project config via DEV dashboard (results in fatal server error)</li>
</ol>
<p><strong>I'm not really sure what to do now?</strong></p>
<ol>
<li>Rebuild the DEV branch from the PROD branch?</li>
<li>Nuke the DEV DB and clone the PROD DB?</li>
</ol>
<p>Any help is appreciated, thanks everyone!</p>
<p><strong>Error</strong>
<a href="https://i.sstatic.net/xKqKf.png" rel="nofollow noreferrer"><img src="https://i.sstatic.net/xKqKf.png" alt="enter image description here" /></a></p>
<p><strong>Plugins in loaded project config</strong>
<a href="https://i.sstatic.net/egoUh.png" rel="nofollow noreferrer"><img src="https://i.sstatic.net/egoUh.png" alt="enter image description here" /></a></p>
<p><strong>Craft version and no loaded plugins</strong>
<a href="https://i.sstatic.net/sVWlz.png" rel="nofollow noreferrer"><img src="https://i.sstatic.net/sVWlz.png" alt="enter image description here" /></a></p>

<database><projectconfig><project.yaml>
How to fix corrupted Craft project config files
# How to fix corrupted Craft project config files

(Asked by: username_0 on 2022-07-18)

Looking to get some advice on fixing some issues I'm having with my Craft DEV environment. I merged some changes which worked fine locally, but are causing some issues on my deployed version.

**Problems include:**

1. Internal server errors when trying load entries
2. None of my plugins are showing in the dashboard (but appear to be included in the loaded project config). Re-applying the project config via the dashboard also causes 500 internal server errors.

These changes have since been reverted, however the problems are still persisting.

**Things I've tried:**

1. Revert the DB to a previous snapshot (same problems still persist).
2. Rebuild the project config locally then push the changes to DEV (same problems still persist).
3. Reapply project config via DEV dashboard (results in fatal server error)

**I'm not really sure what to do now?**

1. Rebuild the DEV branch from the PROD branch?
2. Nuke the DEV DB and clone the PROD DB?

Any help is appreciated, thanks everyone!

**Error**
[![enter image description here](https://i.sstatic.net/xKqKf.png)](https://i.sstatic.net/xKqKf.png)

**Plugins in loaded project config**
[![enter image description here](https://i.sstatic.net/egoUh.png)](https://i.sstatic.net/egoUh.png)

**Craft version and no loaded plugins**
[![enter image description here](https://i.sstatic.net/sVWlz.png)](https://i.sstatic.net/sVWlz.png)

**Tags:** database, projectconfig, project.yaml

---

## 2 answers

### Answer by username_1 on 2022-07-18. Score: 2 | Accepted answer

My guess ... this has nothing todo with project config:

The missing plugins might have to do with a missing or corrupt file vendor/craftcms/plugins.php which is written by a Craft script and triggered by composer during composer install

There was a recent change with composer which requires to explicitly whitelist every composer package (e.g. Craft) which is allowed to execute those scripts and therefor create this file

please check if you have the following lines in your composer.json (there might be more) within the config node of your composer.json file, they do this whitelisting:
"config": {
  "allow-plugins": {
    "craftcms/plugin-installer": true,
    "yiisoft/yii2-composer": true
  }


now try your deployment again

the errors 500 might result from TWIG commands provided by one of your plugins which are not available due to the missing plugins

> **Comments:**
> **username_0**: Hi Matthias, thank you for the answer, this did solve my deployment issue - I'm running `composer v2.0.13` which according to the Craft docs you should only need to explicitly allow plugins if you're running `composer v2.2+`... or maybe I'm missing something? Anyways, I rebuilt the project config locally and added your recommended changes to `composer.json` and this fixed the issue. Thanks  

---

### Answer by username_2 on 2022-07-18. Score: 0

It might be a good idea before doing anything to understand what the specific 500 error being raised is. Enable dev mode so you can see the full error output, or look in the log files and paste the specific error here.

If it is project config related, to recover the dev environment, the best way is probably to apply a fresh copy of the database to your dev environment. You might also want to complete remove the contents of the config/project directory and once the restore completes let Craft rebuild it, which should be the same values in the production database. This gets triggered when loading the control panel.

Although project config is designed in the direction of propagating upwards, this can be occasionally done to recover from situations, but normally project config should be in source control and you shouldn't need to do this. Equally, make sure project config changes happen on local environments which then get pushed up to each environment in the chain ending at production.

Other than dev, make sure you don't allow admin change with the config setting, as this is potentially how project config can get messy:

<https://craftcms.com/docs/3.x/config/config-settings.html#allowadminchanges>

> **Comments:**
> **username_0**: Thanks for the answer James - I don't think my issue was config related after all, it seemed to be a composer package issue. Our project config is managed in git and `allowAdminChanges` is only applied in local environments so we generally don't have issues with the config - but yeah this only threw me a bit... possibly because of our overcomplicated Docker setup. Thanks  
> **username_2**: @KyleLambert Glad you sorted it, it's always good to have devMode on to see the full error trace in local/dev. "Internal Server Error" is just generic when not running devMode and won't tell you much without looking through logs.  

---

