Help with Doctrine \ORM \Mapping \MappingException: Class "Concrete\Core\Entity\Package" is not a valid entity or mapped super class

Developing with Concrete
1

I’m completely at a loss at to why this is happening and how to solve this.

The context : I have developed a website that works fine on my computer and I am deploying on DigitalOcean. The dev was done on a docker compose stack and deployment is under docker compose too, so this should be uneventful.
The error happens on all the pages, on all the dashboard pages and on the CLI. The call stack does not go through my custom code.

What I tried without success :

  • reimporting the database from DEV (where everything works fine)
  • rebuilding all the docker images
  • running the CLI to refresh the entities, which does not work since the CLI crashed too

The problem is that I can’t find mentions of that error message or have any idea of what causes it, so it’s pretty hard to solve… Anyone has any idea on what causes this ?

Full call stack :

Doctrine\ORM\Mapping\MappingException: Class “Concrete\Core\Entity\Package” is not a valid entity or mapped super class. in file /var/www/html/updates/concrete-cms-9.2.8-remote-updater/concrete/vendor/doctrine/orm/lib/Doctrine/ORM/Mapping/MappingException.php on line 364
Stack trace:

  1. Doctrine\ORM\Mapping\MappingException->() /var/www/html/updates/concrete-cms-9.2.8-remote-updater/concrete/vendor/doctrine/orm/lib/Doctrine/ORM/Mapping/MappingException.php:364
    | array(1) {
    | [0]=>
    | string(81) “Class “Concrete\Core\Entity\Package” is not a valid entity or mapped super class.”
    | }

  2. Doctrine\ORM\Mapping\MappingException->classIsNotAValidEntityOrMappedSuperClass() /var/www/html/updates/concrete-cms-9.2.8-remote-updater/concrete/vendor/doctrine/orm/lib/Doctrine/ORM/Mapping/Driver/AnnotationDriver.php:119
    | array(1) {
    | [0]=>
    | string(28) “Concrete\Core\Entity\Package”
    | }

  3. Doctrine\ORM\Mapping\Driver\AnnotationDriver->loadMetadataForClass() /var/www/html/updates/concrete-cms-9.2.8-remote-updater/concrete/vendor/doctrine/persistence/src/Persistence/Mapping/Driver/MappingDriverChain.php:79
    | array(2) {
    | [0]=>
    | string(28) “Concrete\Core\Entity\Package”
    | [1]=>
    | string(34) “Doctrine\ORM\Mapping\ClassMetadata”
    | }

  4. Doctrine\Persistence\Mapping\Driver\MappingDriverChain->loadMetadataForClass() /var/www/html/updates/concrete-cms-9.2.8-remote-updater/concrete/vendor/doctrine/orm/lib/Doctrine/ORM/Mapping/ClassMetadataFactory.php:133
    | array(2) {
    | [0]=>
    | string(28) “Concrete\Core\Entity\Package”
    | [1]=>
    | string(34) “Doctrine\ORM\Mapping\ClassMetadata”
    | }

  5. Doctrine\ORM\Mapping\ClassMetadataFactory->doLoadMetadata() /var/www/html/updates/concrete-cms-9.2.8-remote-updater/concrete/vendor/doctrine/persistence/src/Persistence/Mapping/AbstractClassMetadataFactory.php:415
    | array(4) {
    | [0]=>
    | string(34) “Doctrine\ORM\Mapping\ClassMetadata”
    | [1]=>
    | NULL
    | [2]=>
    | bool(false)
    | [3]=>
    | string(8) “Array(0)”
    | }

  6. Doctrine\Persistence\Mapping\AbstractClassMetadataFactory->loadMetadata() /var/www/html/updates/concrete-cms-9.2.8-remote-updater/concrete/vendor/doctrine/persistence/src/Persistence/Mapping/AbstractClassMetadataFactory.php:281
    | array(1) {
    | [0]=>
    | string(28) “Concrete\Core\Entity\Package”
    | }

  7. Doctrine\Persistence\Mapping\AbstractClassMetadataFactory->getMetadataFor() /var/www/html/updates/concrete-cms-9.2.8-remote-updater/concrete/vendor/doctrine/orm/lib/Doctrine/ORM/EntityManager.php:318
    | array(1) {
    | [0]=>
    | string(28) “Concrete\Core\Entity\Package”
    | }

  8. Doctrine\ORM\EntityManager->getClassMetadata() /var/www/html/updates/concrete-cms-9.2.8-remote-updater/concrete/vendor/doctrine/orm/lib/Doctrine/ORM/Repository/DefaultRepositoryFactory.php:32
    | array(1) {
    | [0]=>
    | string(29) “\Concrete\Core\Entity\Package”
    | }

  9. Doctrine\ORM\Repository\DefaultRepositoryFactory->getRepository() /var/www/html/updates/concrete-cms-9.2.8-remote-updater/concrete/vendor/doctrine/orm/lib/Doctrine/ORM/EntityManager.php:825
    | array(2) {
    | [0]=>
    | string(26) “Doctrine\ORM\EntityManager”
    | [1]=>
    | string(29) “\Concrete\Core\Entity\Package”
    | }

  10. Doctrine\ORM\EntityManager->getRepository() /var/www/html/updates/concrete-cms-9.2.8-remote-updater/concrete/src/Package/PackageList.php:74
    | array(1) {
    | [0]=>
    | string(29) “\Concrete\Core\Entity\Package”
    | }

  11. Concrete\Core\Package\PackageList->get() /var/www/html/updates/concrete-cms-9.2.8-remote-updater/concrete/src/Application/Application.php:231
    | array(0) {
    | }

  12. Concrete\Core\Application\Application->setupPackageAutoloaders() /var/www/html/updates/concrete-cms-9.2.8-remote-updater/concrete/src/Foundation/Runtime/Run/CLIRunner.php:79
    | array(0) {
    | }

  13. Concrete\Core\Foundation\Runtime\Run\CLIRunner->run() /var/www/html/updates/concrete-cms-9.2.8-remote-updater/concrete/src/Foundation/Runtime/DefaultRuntime.php:102
    | array(0) {
    | }

  14. Concrete\Core\Foundation\Runtime\DefaultRuntime->run() /var/www/html/updates/concrete-cms-9.2.8-remote-updater/concrete/dispatcher.php:45
    | array(0) {
    | }

  15. require() /var/www/html/updates/concrete-cms-9.2.8-remote-updater/concrete/bin/concrete:87
    | array(1) {
    | [0]=>
    | string(79) “/var/www/html/updates/concrete-cms-9.2.8-remote-updater/concrete/dispatcher.php”
    | }

  16. require() /var/www/html/concrete/bin/concrete:80
    | array(1) {
    | [0]=>
    | string(77) “/var/www/html/updates/concrete-cms-9.2.8-remote-updater/concrete/bin/concrete”
    | }

2

I’m not sure I have the immediately solution, but a few ideas:

  • the doctrine proxies that are generated live in /application/config/doctrine/proxies, and can be generated on any site/domain - they really just need to match the Concrete version and installed add-ons. So it might be worth checking that those files are making their way into your deployment image. You can generate them locally and include them with deployment, you don’t have to generate them ‘live’.
  • you appear to be running the concrete core out of an updates folder. That’s not wrong as such, but perhaps it’s worth updating the normal /concrete folder to 9.2.8 and removing the config that points the install to the /updates folder (off the top of my head I can’t remember what that config is, but I think it’s an obvious file in /application/config that you can just rename or delete)
  • If you’ve got any custom add-ons installed, check that there’s no mix-up with the casing of things like paths to files in their respective src directories. I’ve seen cases where everything works on one machine/server, but not on another, simply due to case-sensitivity becoming a new factor and a few files not being cased properly.
3

Thanks for your reply. I managed to “solve” the problem by reinstalling from scratch, that’s one of the advantages of using Docker, it’s quick. But it’s not a very satisfying “solution”, especially if it happens again when in production.

Yes, I see what you are talking about for the updates, it’s the application/config/update.php file. Can you just overwrite the concrete folder with the content of the latest folder in updates or is it more complex than that ? What would the the problem of using the update folder ? Other that disk space which I have plenty of (I needed CPU and RAM for other stuff on the stack, so I have a pretty big DigitalOcean instance disk wise). Does the indirection cause a slow down ?

I only have a third-party addon (block developer), otherwise my own code is inside my own package. Since I develop and test inside Docker, that would be unlikely, the case sensitivity is the same. However moving from MacOs to Linux to run Docker, I might have had a problem with access rights. I suspect that might have been the cause. Now that I have the information of where the problem might be, I will look into access rights if the problem happens again.

4

Yes, you can just replace the /concrete directory with the latest one (and remove the update.php file). For updates in general, that’s what you can do, just swap over the concrete folder and simply view a page - the update automatically triggers.

There shouldn’t be any issues at all using the updates folder, and there’s no overhead of running concrete out of there. I simply suggested it in case there were permission related issues with that folder.

I’ve seen a few Concrete issues over the years where some cryptic error like this is actually a side-effect of another error, but with where the exception gets caught it sort of hides the original problem. So it may be that there was some sort of permissions issue, with some files not being able to be read, but then it triggers a broader issue. Still just a guess though.

Glad to hear you’ve made some progress.

1 Like