OroCRM Forums

Covering OroCRM topics, including community updates and company announcements.

Forums › Forums › OroCRM › OroCRM – Installation/Technical Issues or Problems › Error when clearing cache after upgrade

This topic contains 17 replies, has 2 voices, and was last updated by  zach1 3 years, 10 months ago.

Starting from March 1, 2020 the forum has been switched to the read-only mode. Please head to StackOverflow for support.

  • Creator
    Topic
  • September 14, 2019 at 4:59 pm #40437

    zach1
    Participant

    I’ve recently upgraded an Oro CRM install from 2.4.1 to 3.1.14. Running oro:platform:upgrade worked and that process completed, but trying to clear/warmup the cache afterwards generates this error each time, even after manually deleting the var/cache:

    ———–
    // Clearing the cache for the prod environment with debug false

    In AbstractManagerRegistry.php line 166:
    Class Oro\Bundle\MailChimpBundle\Entity\Campaign does not exist

    cache:clear [–no-warmup] [–no-optional-warmers] [-h|–help] [-q|–quiet] [-v|vv|vvv|–verbose] [-V|–version] [–ansi] [–no-ansi] [-n|–no-interaction] [-e|–env ENV] [–no-debug] [–disabled-listeners DISABLED-LISTENERS] [–current-user CURRENT-USER] [–current-organization CURRENT-ORGANIZATION] [–] <command>
    ———–

    Also, when attempting to access the web frontend, I get this error; probably a result of the incomplete cache warmup, but included just in case:

    ———–
    Uncaught PHP Exception Symfony\Component\Debug\Exception\UndefinedMethodException: “Attempted to call an undefined method named “getGuestRole” of class “Oro\Bundle\WebsiteBundle\Entity\Website”.” at /data/websites/upgrading/oro31.local/vendor/oro/customer-portal/src/Oro/Bundle/CustomerBundle/Security/Firewall/AnonymousCustomerUserAuthenticationListener.php line 137
    ———–

    The only item that turns up in searching for MailChimpBundle in the Oro directory is a migration removing it. Is there any way to get some insight into why it might be looking for it, or how to successfully get the cache warmed up and functional?

  • Creator
    Topic
Viewing 15 replies - 1 through 15 (of 17 total)
1 2
  • Author
    Replies
  • September 17, 2019 at 12:58 am #40459

    Andrey Yatsenko
    Moderator

    Hi,

    Do you use MailChimp integration in the application?

    September 17, 2019 at 11:39 am #40473

    zach1
    Participant

    We don’t. After some investigation, I discovered that, though a migration removed MailChimp (and Abandoned Cart) items from several tables, there were still some residing in oro_entity_config. Clearing them from that table resolved that issue. It brought up another one, however. There are more errors after this about oro_api.collect_subresources.initialize_subresources and oro_organization.api.config.add_owner_validator failing, but they each point to this one.

    In PropertyMetadata.php line 40:

    [Symfony\Component\Validator\Exception\ValidatorException]
    Property “highlightLowInventory” does not exist in class “Oro\Bundle\ProductBundle\Entity\Product”

    Exception trace:
    () at /data/websites/upgrading/oro31.local/vendor/symfony/symfony/src/Symfony/Component/Validator/Mapping/PropertyMetadata.php:40
    Symfony\Component\Validator\Mapping\PropertyMetadata->__construct() at /data/websites/upgrading/oro31.local/vendor/symfony/symfony/src/Symfony/Component/Validator/Mapping/ClassMetadata.php:221
    Symfony\Component\Validator\Mapping\ClassMetadata->addPropertyConstraint() at /data/websites/upgrading/oro31.local/vendor/symfony/symfony/src/Symfony/Component/Validator/Mapping/Loader/YamlFileLoader.php:184
    Symfony\Component\Validator\Mapping\Loader\YamlFileLoader->loadClassMetadataFromYaml() at /data/websites/upgrading/oro31.local/vendor/symfony/symfony/src/Symfony/Component/Validator/Mapping/Loader/YamlFileLoader.php:52
    Symfony\Component\Validator\Mapping\Loader\YamlFileLoader->loadClassMetadata() at /data/websites/upgrading/oro31.local/vendor/symfony/symfony/src/Symfony/Component/Validator/Mapping/Loader/LoaderChain.php:54
    Symfony\Component\Validator\Mapping\Loader\LoaderChain->loadClassMetadata() at /data/websites/upgrading/oro31.local/vendor/symfony/symfony/src/Symfony/Component/Validator/Mapping/Loader/LoaderChain.php:54
    Symfony\Component\Validator\Mapping\Loader\LoaderChain->loadClassMetadata() at /data/websites/upgrading/oro31.local/vendor/symfony/symfony/src/Symfony/Component/Validator/Mapping/Factory/LazyLoadingMetadataFactory.php:105
    Symfony\Component\Validator\Mapping\Factory\LazyLoadingMetadataFactory->getMetadataFor() at /data/websites/upgrading/oro31.local/vendor/symfony/symfony/src/Symfony/Component/Validator/Validator/RecursiveValidator.php:83
    Symfony\Component\Validator\Validator\RecursiveValidator->getMetadataFor() at /data/websites/upgrading/oro31.local/vendor/oro/platform/src/Oro/Bundle/ApiBundle/Util/ValidationHelper.php:33
    Oro\Bundle\ApiBundle\Util\ValidationHelper->getValidationMetadataForClass() at /data/websites/upgrading/oro31.local/vendor/oro/platform/src/Oro/Bundle/ApiBundle/Util/ValidationHelper.php:66
    Oro\Bundle\ApiBundle\Util\ValidationHelper->hasValidationConstraintForClass() at /data/websites/upgrading/oro31.local/vendor/oro/platform/src/Oro/Bundle/OrganizationBundle/Api/Processor/Config/AddOwnerValidator.php:77
    Oro\Bundle\OrganizationBundle\Api\Processor\Config\AddOwnerValidator->addValidators() at /data/websites/upgrading/oro31.local/vendor/oro/platform/src/Oro/Bundle/OrganizationBundle/Api/Processor/Config/AddOwnerValidator.php:57
    Oro\Bundle\OrganizationBundle\Api\Processor\Config\AddOwnerValidator->process() at /data/websites/upgrading/oro31.local/vendor/oro/platform/src/Oro/Component/ChainProcessor/ChainProcessor.php:42
    Oro\Component\ChainProcessor\ChainProcessor->executeProcessors() at /data/websites/upgrading/oro31.local/vendor/oro/platform/src/Oro/Component/ChainProcessor/ChainProcessor.php:28
    Oro\Component\ChainProcessor\ChainProcessor->process() at /data/websites/upgrading/oro31.local/vendor/oro/platform/src/Oro/Bundle/ApiBundle/Provider/ConfigProvider.php:72
    Oro\Bundle\ApiBundle\Provider\ConfigProvider->getConfig() at /data/websites/upgrading/oro31.local/vendor/oro/platform/src/Oro/Bundle/ApiBundle/Processor/CollectSubresources/LoadSubresources.php:191
    Oro\Bundle\ApiBundle\Processor\CollectSubresources\LoadSubresources->getConfig() at /data/websites/upgrading/oro31.local/vendor/oro/platform/src/Oro/Bundle/ApiBundle/Processor/CollectSubresources/InitializeSubresources.php:60
    Oro\Bundle\ApiBundle\Processor\CollectSubresources\InitializeSubresources->createEntitySubresources() at /data/websites/upgrading/oro31.local/vendor/oro/platform/src/Oro/Bundle/ApiBundle/Processor/CollectSubresources/InitializeSubresources.php:37
    Oro\Bundle\ApiBundle\Processor\CollectSubresources\InitializeSubresources->process() at /data/websites/upgrading/oro31.local/vendor/oro/platform/src/Oro/Component/ChainProcessor/ChainProcessor.php:42
    Oro\Component\ChainProcessor\ChainProcessor->executeProcessors() at /data/websites/upgrading/oro31.local/vendor/oro/platform/src/Oro/Component/ChainProcessor/ChainProcessor.php:28
    Oro\Component\ChainProcessor\ChainProcessor->process() at /data/websites/upgrading/oro31.local/vendor/oro/platform/src/Oro/Bundle/ApiBundle/Provider/SubresourcesProvider.php:66
    Oro\Bundle\ApiBundle\Provider\SubresourcesProvider->getSubresources() at /data/websites/upgrading/oro31.local/vendor/oro/platform/src/Oro/Bundle/ApiBundle/Provider/ResourcesCacheWarmer.php:72
    Oro\Bundle\ApiBundle\Provider\ResourcesCacheWarmer->warmUpCache() at /data/websites/upgrading/oro31.local/vendor/oro/platform/src/Oro/Bundle/ApiBundle/Provider/ResourcesCacheWarmer.php:43
    Oro\Bundle\ApiBundle\Provider\ResourcesCacheWarmer->warmUp() at /data/websites/upgrading/oro31.local/vendor/symfony/symfony/src/Symfony/Component/HttpKernel/CacheWarmer/CacheWarmerAggregate.php:52
    Symfony\Component\HttpKernel\CacheWarmer\CacheWarmerAggregate->warmUp() at /data/websites/upgrading/oro31.local/vendor/oro/platform/src/Oro/Bundle/EntityExtendBundle/Cache/CacheWarmerAggregate.php:76
    Oro\Bundle\EntityExtendBundle\Cache\CacheWarmerAggregate->warmUp() at /data/websites/upgrading/oro31.local/vendor/symfony/symfony/src/Symfony/Bundle/FrameworkBundle/Command/CacheClearCommand.php:222
    Symfony\Bundle\FrameworkBundle\Command\CacheClearCommand->warmup() at /data/websites/upgrading/oro31.local/vendor/symfony/symfony/src/Symfony/Bundle/FrameworkBundle/Command/CacheClearCommand.php:134
    Symfony\Bundle\FrameworkBundle\Command\CacheClearCommand->execute() at /data/websites/upgrading/oro31.local/vendor/symfony/symfony/src/Symfony/Component/Console/Command/Command.php:255
    Symfony\Component\Console\Command\Command->run() at /data/websites/upgrading/oro31.local/vendor/symfony/symfony/src/Symfony/Component/Console/Application.php:978
    Symfony\Component\Console\Application->doRunCommand() at /data/websites/upgrading/oro31.local/vendor/symfony/symfony/src/Symfony/Bundle/FrameworkBundle/Console/Application.php:86
    Symfony\Bundle\FrameworkBundle\Console\Application->doRunCommand() at /data/websites/upgrading/oro31.local/vendor/symfony/symfony/src/Symfony/Component/Console/Application.php:255
    Symfony\Component\Console\Application->doRun() at /data/websites/upgrading/oro31.local/vendor/symfony/symfony/src/Symfony/Bundle/FrameworkBundle/Console/Application.php:74
    Symfony\Bundle\FrameworkBundle\Console\Application->doRun() at /data/websites/upgrading/oro31.local/vendor/symfony/symfony/src/Symfony/Component/Console/Application.php:148
    Symfony\Component\Console\Application->run() at /data/websites/upgrading/oro31.local/bin/console:30

    September 17, 2019 at 12:05 pm #40474

    Andrey Yatsenko
    Moderator

    We don’t

    Then try out these steps:
    – remove “oro/crm-abandoned-cart” extension from the composer.json file,
    – run composer update,
    – restore the database from the dump
    – and restart the upgrade process,

    So all the migration will be processed, including the creation of highlightLowInventory field.

    September 18, 2019 at 2:29 pm #40477

    zach1
    Participant

    First, thank you for your help so far!

    There’s a few wrinkles in these steps. With both the pre-upgrade and post-upgrade composer.json, running composer update causes this error:

    PHP Fatal error: Allowed memory size of 4294967296 bytes exhausted (tried to allocate 4096 bytes) in phar:///home/deploy/bin/composer/src/Composer/DependencyResolver/Solver.php on line 223

    I had been sidestepping this by running composer install, instead. Prior to the update though, it prevents the lock file from being updated, which obviously prevents the crm-abandoned-application removal from taking effect. The composer.json file matches this exactly, with no changes: https://github.com/oroinc/orocommerce-application/blob/1.4.1/composer.json. After the upgrade, it matches this exactly (with crm-abandoned-cart already gone): https://github.com/oroinc/orocommerce-application/blob/3.1.14/composer.json. Composer is the latest version (1.9.0). Could any that be a cause of these issues?

    Because it is already gone post-update, crm-abandoned-cart did not exist when I ran the platform update.

    For reference, this is how I am updating:

      Remove cache from the 2.4.1 install (rm -rf app/cache/*)
      Upgrade from git (git fetch, git checkout 3.1.14)
      Update src/AppKernel.php with custom bundles
      Install composer packages (composer install –prefer-dist –no-dev)
      Upgrade oro (bin/console oro:platform:update –env=prod –force)
      Clear/warmup cache (bin/console cache:clear –env=prod)

    The last step of which presents the highlightLowInventory error. Just to be sure, i re-ran these steps on a fresh copy of the original files and original database, and this is the output of the upgrade:

    Check system requirements
    +———+——————————————————————————————————–+
    | Check | Optional recommendations |
    +———+——————————————————————————————————–+
    | WARNING | To get the latest internationalization data upgrade the ICU system package and the intl PHP extension. |
    | WARNING | Disable Phar extension to reduce the risk of PHP unserialization vulnerability. |
    +———+——————————————————————————————————–+
    The application meets all mandatory requirements
    Process migrations…
    > Oro\Bundle\EntityExtendBundle\Migration\LoadEntityConfigStateMigration
    > Oro\Bundle\OrganizationBundle\Migrations\Schema\v1_7\UpdateFormTypeForExtendDescription
    > Oro\Bundle\OrganizationBundle\Migrations\Schema\v1_7\UpdateOrganizationFormType
    > Oro\Bundle\LoggerBundle\Migrations\Schema\OroLoggerBundleInstaller
    > Oro\Bundle\AttachmentBundle\Migrations\Schema\v1_5_1\AddParentEntityClassEntityIdColumns
    > Oro\Bundle\OroMessageQueueBundle\Migrations\Schema\v1_6\JobLastActiveAt
    > Oro\Bundle\OroMessageQueueBundle\Migrations\Schema\v1_6\StateConsumerInitialData
    > Oro\Bundle\OroMessageQueueBundle\Migrations\Schema\v1_7\AddScanIndex
    > Oro\Bundle\OroMessageQueueBundle\Migrations\Schema\v1_7\StateConsumerInitialData
    > Oro\Bundle\OroMessageQueueBundle\Migrations\Schema\v1_8\MessageQueueBundle
    > Oro\Bundle\EmailBundle\Migrations\Schema\v1_32\IncreaseEmailNameLength
    > Oro\Bundle\EmailBundle\Migrations\Schema\v1_33\AddCascadeDeletionMigration
    > Oro\Bundle\CronBundle\Migrations\Schema\v2_1\OroCronBundle
    > Oro\Bundle\UserBundle\Migrations\Schema\v2_2\UpdateFormTypeForExtendDescription
    > Oro\Bundle\UserBundle\Migrations\Schema\v2_2\UpdateUserFormType
    > Oro\Bundle\UserBundle\Migrations\Schema\v2_3\AddEmailLowercaseField
    > Oro\Bundle\UserBundle\Migrations\Schema\v2_3\MakeEmailLowercaseFieldNotNull
    > Oro\Bundle\UserBundle\Migrations\Schema\v2_4\OroUserBundle
    > Oro\Bundle\UserBundle\Migrations\Schema\v2_4_1\AddUsernameLowercaseField
    > Oro\Bundle\UserBundle\Migrations\Schema\v2_4_1\MakeUsernameLowercaseFieldNotNull
    > Oro\Bundle\LocaleBundle\Migrations\Schema\v1_4\UpdateLocalizationFormType
    > Oro\Bundle\EntityConfigBundle\Migrations\Schema\v1_14_1\UpdateConfigFieldBrokenEnum
    > Oro\Bundle\EntityConfigBundle\Migrations\Schema\v1_14_2\FixBrokenDeletedFields
    > Oro\Bundle\EntityConfigBundle\Migrations\Schema\v1_14_3\UpdateAttachmentFieldConfigForAttributeFamilyImage
    > Oro\Bundle\IntegrationBundle\Migrations\Schema\v1_16\OroIntegrationBundle
    > Oro\Bundle\RuleBundle\Migrations\Schema\v1_1\RemoveRuleAcl
    > Oro\Bundle\NotificationBundle\Migrations\Schema\v1_4\OroNotificationBundle
    > Oro\Bundle\ActivityListBundle\Migrations\Schema\v1_5\RemoveHeadColumn
    > Oro\Bundle\DataAuditBundle\Migrations\Schema\v2_3\AddAdditionalFieldsToDataAudit
    > Oro\Bundle\DataAuditBundle\Migrations\Schema\v2_4\AddTranslationDomainToAuditField
    > Oro\Bundle\DataAuditBundle\Migrations\Schema\v2_5\OroDataAuditBundle
    > Oro\Bundle\DataAuditBundle\Migrations\Schema\v2_6\OroDataAuditBundle
    > Oro\Bundle\ImapBundle\Migrations\Schema\v1_6\WrongCredentialsOriginTable
    > Oro\Bundle\ImapBundle\Migrations\Schema\v1_7\AddCascadeDeletionsMigration
    > Oro\Bundle\ReportBundle\Migrations\Schema\v2_3\OroReportBundle
    > Oro\Bundle\SearchBundle\Migrations\Schema\v1_5\OroSearchBundle
    > Oro\Bundle\SearchBundle\Migrations\Schema\v1_6\AddIndexes
    > Oro\Bundle\SearchBundle\Migrations\Schema\v1_7\AddSearchWeightField
    > Oro\Bundle\SearchBundle\Migrations\Schema\v1_8\AlterSearchWeightField
    > Oro\Bundle\SegmentBundle\Migrations\Schema\v1_9\AddSegmentNameValidationColumn
    > Oro\Bundle\TagBundle\Migrations\Schema\v1_10\UpdateTaxonomyFormType
    > Oro\Bundle\WebsiteSearchBundle\Migrations\Schema\v1_2\OroWebsiteSearchBundle
    > Oro\Bundle\WebsiteSearchBundle\Migrations\Schema\v1_3\AddIndexes
    > Oro\Bundle\WebsiteSearchBundle\Migrations\Schema\v1_4\AddSearchWeightField
    > Oro\Bundle\WebsiteSearchBundle\Migrations\Schema\v1_5\AlterSearchWeightField
    > Oro\Bundle\WindowsBundle\Migrations\Schema\v1_2\OroWindowsBundle
    > Oro\Bundle\WorkflowBundle\Migrations\Schema\v2_4\OroWorkflowBundle
    > Oro\Bundle\WorkflowBundle\Migrations\Schema\v2_5\ChangeLengthOfFields
    > Oro\Bundle\CRMBundle\Migrations\Schema\v1_7\RemoveMailChimpBundleAndAbandonedCartBundleConfigs
    > Oro\Bundle\CalendarBundle\Migrations\Schema\v1_19\CalendarEventOrganizer
    > Oro\Bundle\CalendarBundle\Migrations\Schema\v1_19\CalendarEventUid
    > Oro\Bundle\CalendarBundle\Migrations\Schema\v1_20\UpdateFormTypeForExtendDescription
    > Oro\Bundle\HangoutsCallBundle\Migrations\Schema\v1_1\ReplaceFormAliases
    > Oro\Bundle\ContactBundle\Migrations\Schema\v1_16\UpdateContactFormType
    > Oro\Bundle\ContactBundle\Migrations\Schema\v1_17\CreateIndexForFirstName
    > Oro\Bundle\NavigationBundle\Migrations\Schema\v1_8\AddNavigationHistoryItemIndex
    > Oro\Bundle\NavigationBundle\Migrations\Schema\v1_8_1\AddPinbarTabTitle

    September 19, 2019 at 5:47 am #40529

    Andrey Yatsenko
    Moderator

    running composer update causes this error

    To significantly reduce composer memory usage you can install symfony flex plugin globally before running composer commands

    It doesn’t matter what is the content of composer.json, because when you don’t run composer update – composer.lock file is used. Please try to fix the memory issue with the above solution and restart from running composer update.

    September 19, 2019 at 11:48 pm #40538

    zach1
    Participant

    Thank you again for your help, I really appreciate the support.

    I’ve installed symfony/flex, and a combination of that and running composer without a memory limit resolved that composer error. On my 2.4.1 install, I’m now getting an error about a package requiring php 7.3+, despite neither 2.4.1 nor 3.1.14 versions of Oro requiring that. I’d rather not bump the server to 7.3 for stability reasons. Is it safe to simply remove the package? Is editing the 2.4.1 install’s composer.json a misunderstanding of the instructions and unnecessary? Process and error below.

    The process:

      Start from a fresh copy of the original 2.4.1 files
      Clear cache (rm -rf app/cache/*)
      Remove the line “oro/crm-abandoned-cart”: “2.4.*”, from composer.json
      Update composer (php -d memory_limit=-1 composer update –prefer-dist –no-dev) (error happens without –prefer-dist, too)

    The error:

    Your requirements could not be resolved to an installable set of packages.

    Problem 1
    – sebastian/phpcpd dev-master requires php ^7.3 -> your PHP version (7.1.32) does not satisfy that requirement.
    – sebastian/phpcpd dev-master requires php ^7.3 -> your PHP version (7.1.32) does not satisfy that requirement.
    – Installation request for sebastian/phpcpd dev-master#cff7f36c2ae89d59987de25d14fd41a72dd4a703 as 3.1.0 -> satisfiable by sebastian/phpcpd[dev-master].

    Running update with –no-dev does not mean require-dev is ignored, it just means the packages will not be installed. If dev requirements are blocking the update you have to resolve those problems.

    September 23, 2019 at 11:06 am #40550

    zach1
    Participant

    Removing the package resolved it. So this is the full process:

      Start from a fresh copy of the original 2.4.1 files
      Clear cache (rm -rf app/cache/*)
      Remove crm-abandoned-cart and phpcpd lines from composer.json
      Update composer (php -d memory_limit=-1 composer update –prefer-dist –no-dev)
      Remove unstaged changes from standard git release (git stash)
      Upgrade from git (git fetch; git checkout 3.1.14)
      Update src/AppKernel.php with custom bundles
      Update composer once more (php -d memory_limit=-1 composer update –prefer-dist –no-dev)
      Fill in parameters from composer update script. Defaults for everything except db credentials and secret, which are copied over from the old install
      Update Oro (bin/console oro:platform:update –env=prod –force)
      Clear oro_entity_config rows where class_name is like MailChimpBundle or AbandonedCartBundle
      Clear/warmup cache (bin/console cache:clear –env=prod)

    Every step prior to the last one completes successfully. The last one fails with the same error:

    As always, thank you for your help so far, it’s greatly appreciated.

    September 25, 2019 at 6:10 am #40568

    Andrey Yatsenko
    Moderator

    Clear oro_entity_config rows where class_name is like MailChimpBundle or AbandonedCartBundle

    This is done automatically when you upgrade from clean 2.4 by this migration:
    https://github.com/oroinc/crm/blob/7e6fd38e9ee765df47c5c7bd702a3b4218bd66dc/src/Oro/Bundle/CRMBundle/Migrations/Schema/v1_7/RemoveMailChimpBundleAndAbandonedCartBundleConfigs.php

    And, another migration is responsible on creating a highlightLowInventory field if it was not added before:
    https://github.com/oroinc/orocommerce/blob/a5eeb154a0318f4c83765f584a64b94563a4ff48/src/Oro/Bundle/InventoryBundle/Migrations/Schema/v1_2/AddHighlighLowInventory.php

    So, it looks like you had outdated caches or the database was corrupted by a failed upgrade before you started the upgrade process from scratch.
    Make sure the database was restored before retrying to upgrade and after an upgrade theck the logs for the above migrations mentions, for instance, in a first log that you shared it was processed, and there is no need to do something with the database manually, but AddHighlighLowInventory has not been run there.

    September 25, 2019 at 7:58 pm #40576

    zach1
    Participant

    Thank you very much. I have a clear picture of the problem now at least, even though I haven’t yet solved it.

    My 2.4.1 install is running in production right now without issue. The database for that install is called “oro”. It is backed up every 6 hours in an sql dump. When I am testing an upgrade, I import the latest dump from that into a new database, “oro3”. Then, I take a copy of the existing files, change the db name in parameters.yml from “oro” to “oro3”, and continue from there using the oro3 database, leaving the original unaffected. It’s possible this setup is contributing to it; perhaps the database name is stored somewhere more deeply than parameters.yml.

    I noticed something curious. On both of these attempts, there is not actually a “platform upgrade successful” message, nor an error, but rather the command just exits after an apparently random migration; I had taken that to mean success, but now I am doubting that. If I run oro:platform:upgrade a second time after that, it will attempt to run all the same migrations again and (naturally) fail very early because a table already exists. That part isn’t too surprising, but it then prints out all of the migrations it skips; a list that is much, much longer than the migrations I am actually getting to happen.

    That list, including the skipped migrations, has 190 migrations on it. Over my last four attempts, the number of migrations I get to actually run are 57, 35, 73, and 38, ending on a different migration each time. So, the issue turns out to be that, for some reason, the process is dying during migrations.

    There are not any errors printed to the shell, nor to the mysql error log, nor to the application log in the oro directiory at var/logs, nor to the syslog on either the application or mysql servers. I tried running the upgrade command with -vvv in the hopes it might show something extra, but no luck there, either.

    As an example, my last attempt had this as the final line of the output:

    and then it exits to the shell. Any idea what could be causing this, or ways to debug it?

    October 1, 2019 at 3:04 am #40600

    Andrey Yatsenko
    Moderator

    It looks like the issue with the memory limit. Make sure the command line configuration for PHP has memory limit -1. It is possible that the migration has out of memory because it processed too much data.

    October 24, 2019 at 1:51 pm #40757

    zach1
    Participant

    Thank you for your help so far. I still have an issue, but most of the above is resolved. I’ll give my current issue up front, and explain my resolutions to the prior problems for posterity and future googlers.

    My current issue is that attempting to create an order (at /admin/order/create) gives a 500 error, and puts this error in var/logs/prod.log:

    Uncaught PHP Exception Symfony\Component\Form\Exception\LogicException: “You cannot add children to a simple form. Maybe you should set the option “compound” to true?” at /data/websites/upgrading/oro31.local/vendor/symfony/symfony/src/Symfony/Component/Form/Form.php line 819

    I’ve renamed all of the customizations in the src folder (i.e. EmailBundle to _EmailBundle) to prevent them from loading, cleared cache, and this still seems to be happening regardless. I’ve been attempting to trace down where that compound setting is becoming false but haven’t made much headway, I’m hoping you or someone might know where the culprit is.

    My previous issues were resolved. Running it without the memory limit didn’t prevent the issue, but monitoring memory while it was running indicated a –timeout=500 argument. I timed the upgrade process and, sure enough, the exit was happening at 5 minutes and change. Thankfully the platform upgrade command passes through the timeout argument, so running it with –timeout=99999 got rid of that issue.

    After that, I discovered I had to upgrade MySQL from 5.6 to 5.7. This is stated in the requirements for new versions of Oro so that’s fine; specifically, I needed the innodb_default_row_format option added in 5.7, in order to set it to dynamic, in order to allow large keys while using the utf8mb4 encoding/collation.

    October 25, 2019 at 3:44 am #40760

    Andrey Yatsenko
    Moderator

    Hi,
    Check the full stack trace of an error to find what exact form type or form type extension triggered an error. If it doesn’t help, we recommend using xDebug to trace an error.
    Removing the folder with a bundle that has customization usually will not work as there can be modifications in the database that already relly on a new code, so you should not use this technic as it could lead to new issues that are not related to the original one.

    October 28, 2019 at 7:44 pm #40766

    zach1
    Participant

    I’ve moved the customizations back, cleared cache, and here is a stack trace of the error in question.

    To see why this was happening, I also grabbed a backtrace of when compound was set to false, if that provides any further insight:

    I will continue to research this as I can, but would appreciate pointers in the right direction if anything jumps out.

    November 6, 2019 at 5:44 pm #40835

    zach1
    Participant

    After trying several avenues of investigation, I can’t seem to track down why the order form is getting set to compound=false. I’d appreciate pointers to where this might be originating.

    November 11, 2019 at 10:33 am #40860

    Andrey Yatsenko
    Moderator

    Unfortunately, this is not a common error and it seems it’s related to the customization as the newer version of ORO code must be already compatible with the Symfony forms changes. As I said before, the only option I see is to debug the error to find the cause.

    If you need professional help with an upgrade, it would be more effective with the paid team who has access to your project source code. You can contact one of ORO partners or get in touch with the sales department using the Contact Us form (https://www.orocommerce.com/contact-us) on the OroCommerce website. The sales team will be happy to assist you.

  • Author
    Replies
Viewing 15 replies - 1 through 15 (of 17 total)
1 2

The forum ‘OroCRM – Installation/Technical Issues or Problems’ is closed to new topics and replies.

Back to top