OroCRM Forums

Covering OroCRM topics, including community updates and company announcements.

Forums Forums OroCRM OroCRM – How do I? Questions Installing Beta 6: How to Fix Call to Undefined Method getExtendSource

This topic contains 8 replies, has 5 voices, and was last updated by Jary Carter Jary Carter 6 years, 8 months ago.

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

  • Creator
  • #27992

    After fixing numerous permissions issues per my previous thread, the OroCRM installation process still fails to run error free. Specifically, the sample data installation doesn’t complete.

    failed instalation

    Monitoring oro_install.log doesn’t reveal anything concrete, other than `OroCRM\Bundle\DemoDataBundle\DataFixtures\Demo\LoadLeadsData` is the last fixture to load before Oro moves on to the next step.

    However, looking at the PHP error logs from the same time reveals the following error.

    THe important bit being

    PHP Fatal error: Call to undefined method OroCRM\\Bundle\\SalesBundle\\Entity\\Lead::getExtendSource() in /Users/alanstorm/Sites2013/oro-beta6.dev/crm-application/vendor/oro/platform/src/Oro/Bundle/EntityConfigBundle/EventListener/OptionSetListener.php on line 46, referer: http://oro-beta6.dev/installer/flow/oro_installer/installation

    Is this a known issue? Is there a workaround that will let me successfully complete the installation of the sample data?

Viewing 8 replies - 1 through 8 (of 8 total)
  • Author
  • #27993
    Yevhen Shyshkin
    Yevhen Shyshkin

    Hello, alanstorm.

    Looks like there is some issue with extended entity cache.

    Solution 1. You can try to reinstall from scratch (new folder, new DB).

    Solution 2. You can manually clear and initialize extended entity cache:


    I appreciate the help — however, I’ve run through an installation from scratch several times, and this is always the same result.

    I’ve also tried running the command listed above, and

    Doing this always stops with an error for the `oro:entity-extend:init` command. (this error does not appear to occur during initial installation when monitoring
    the PHP error log and oro_install.log)

    What is the “extended entity cache”? What are these commands supposed to be doing behind the scenes? I realize this is beta software, and that for the team working on it day to day these must seem like trivial issues, but for someone trying to get into the platform without that institutional knowledge this (combined with the generally slow performance) is a frustrating experience.


    Additional debugging information: I jumped into the definition for the oro:entity-extend:init command, and change the Exception

    Into a writeln/continue (so execution wouldn’t halt)

    and I received the following messages

    So, again, not having an understanding of the custom ORM/entity stuff that’s been done in OroCRM, it seems like the problem is the system already thinks the account object has had those items added, when in fact it has not.


    Alexandr Smaga

    Hi Alan!

    I don’t think that this is obvious error, we are working with it every day, and re-installing a lot, also our demo instance re-installed every 30 minutes from the scratch. So errors that you caught are just exception, not the rule…

    My assumption that issue is related to permissions during installation. From what’s user/group server works? I’m working on OSX ML, apache works from my current user and I haven’t any troubles.
    The thing is that during installation some code are generated(similar as DI container cache) by EntityExtendBundle, can you check app/cache/dev/oro_entities/Extend/Entity/ this folder, after DB step is processed ? alias.yml should be there as well as generated entities, is it there ?

    Thanks for your help to do it better =)


    Appreciate the extra help on this, **and** I appreciate the code changes I’m already seeing filter in through the git repositories to address some of these issues.

    For anyone still following along, I bailed on getting the browser based installation working, and installed via the `app/console` program.

    This appears to have worked, and points the finger at something permissions based, as mentioned above. (also, per the comments above, my `app/cache/[dev|prod]/oro_entities/Extend/Entity` folders were empty — `Entity` existed, but contained nothing)

    I realize many developers run in a FastCGI environment where apache is running as the same user as the local shell user. If this is going to be a requirement for OroCRM it should be stated up front and made explicit.

    If (as I hope), it’s **not** a requirement, and you plan on supporting developers who use the `mod_php` unprivileged web-user development/production setup, I’d urge the team to build in a robust set of tools that

    1. Ensure permissions are correct

    2. Enable easy checking of permissions

    3. Enable some sort of “repair” functionality

    Similar issues dogged Magento through it’s life, and Magento Connect **still** suffers heavily from this problem. Silent, undiagnosable permissions issues are *the worst*. Beyond that, while it’s totally understandable at this stage, hearing “Maybe it’s permissions and you should blow away your installation and start over” is incredibly frustrating. I’d also encourage you to look into how the PHP CMS world handles this issue — Wordpress, Drupal, Joomla — each of these platforms accepts the problem of permissions and have explicit steps for dealing with it in their installations.

    I’m sure if you look at this from an executive level you could ignore the problem, and most developers interested in the platform would eventually slog through it — but it’s an incredibly frustrating slog, and it doesn’t need to be this way. There are patterns for dealing with these sorts of problems and it would be fantastic to see the OroCRM adopt them.

    Dima Soroka
    Dima Soroka

    Thanks for your feedback, Alan.

    For command line installation please use

    We are still working on oro:package:* commands and finalizing platform packages management for next release. Package manager will allow to install and upgrade platform packages and applications from CLI and web interface.

    This functionality will be used mostly by developers so it is very important to see this kind of feedback.


    Ah, sorry, that’s a bad copy/paste. `oro:install` was the command I used. Thanks for the correction.

    Jary Carter
    Jary Carter

    Thanks for your feedback on this Alan. This type of feedback is invaluable to product improvement.

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

The forum ‘OroCRM – How do I? Questions’ is closed to new topics and replies.

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

Yes No