Covering OroCommerce, OroCRM, OroPlatform topics, including community updates and company announcements.

Forums OroCommerce Issue when warming up the cache (post-installation)

This topic contains 6 replies, has 2 voices, and was last updated by  jonas3 11 months ago.

  • Creator
  • #32233


    1. Application related information:
    Application Type: OroCommerce
    Application Version: 1.4
    Application Edition: Community
    2. Environment related information:
    OS, name and version: Debian Jessie (through Docker on OSX)
    Web server, name and version: Nginx 1.12.1
    Database, name and version: MySQL 5.7
    PHP, version: 7.1
    3. Also, for questions about error, issue or unexpected behavior, please, describe the way to reproduce it.
    Example (but you may use your own pattern or free-form description):
    Steps to reproduce:
    1) Install application (with or without sample data)
    2) Run php app/console oro:api:doc:cache:clear
    Expected result:
    1) Command should run without error
    Actual result:
    1) Command exits with error Processor failed: “oro_api.collect_subresources.initialize_subresources”. Reason: Processor
    failed: “oro_api.get_config.add_owner_validator”. Reason: Property “inventory_status” does
    not exist in class “Oro\Bundle\ProductBundle\Entity\Product”

Viewing 6 replies - 1 through 6 (of 6 total)
  • Author
  • #32234


    Hello, jonas3.

    Most likely – it’s some kind of problem with caches. Please, try to clear caches and reinstall vendors:

    Please, let me know if this helped. Thank you.



    Thanks, that sorted that problem and created a bunch of new ones:

    This installation procedure is a PITA to be honest with a new problem arising after every step taken.



    Hi, jonas3.

    The first error indicates that DB migrations during installation process weren’t performed correctly.
    So, I recommend you to reinstall the application from scratch (and recreate DB also in this case) if you have such ability.
    It would be most simple and reliable fix.

    The second error is not an error, actually: indeed, there is no route for /admin/login URL.
    Correct URL for admin area is /admin/.
    If you not logged in, from this URL you will be redirected to /admin/user/login.
    The URL /admin/login actually not exists.



    There were no errors at all during the installation process, so that seems a bit strange, but i’ll try and rerun the installation. As to the route not existing, that would be a bug then because if i visit http://project.domain/admin i am redirected to http://project.domain/admin/login if i’m not logged in and not http://project.domain/admin/user/login as intended.



    Hm. It’s interesting. Ok, let’s wait for results of reinstall for now.

    If you can, please show here the list of migrations that will be performed during the installation process.



    Okay, so the migrations performed are:

    Haven’t gotten to test the installation yet as i ran into a memory error when clearing the cache.

Viewing 6 replies - 1 through 6 (of 6 total)

You must be logged in to reply to this topic.

You will be redirected to [title]. Would you like to continue?

Yes No