Beta 6: Incorrect orocrm_account Table when Installing From Browser

[astorm]

When using the browser based installer to install OroCRM, the orocrm_account table is not populated with the correct fields. "Correct Fields" means the fields required to save an account via the admin user interface, and the ones that are installed when using app/console oro:install. (actual fields listed below)

Steps to Reproduce

1. Checkout OroCRM repository
2. Add correct ACL permissions to all files and folders using three one-liners listed below (system ACL, not Oro ACL)
3. Run composer.phar install to install vendor folder
4. Load http://oro.example.com/install.php in browser
5. Run through installation

Expected Behavior: orocrm_account table contains the following columns

id
user_owner_id
shipping_address_id
billing_address_id
default_contact_id
name
createdAt
updatedAt
field_extend_description
field_extend_phone
field_extend_email
field_extend_fax
field_extend_website
field_extend_employees
field_extend_ownership
field_extend_ticker_symbol
field_extend_rating

Actual Behavior: orocrm_account table contains only these columns

id
user_owner_id
shipping_address_id
billing_address_id
default_contact_id
name
createdAt
updatedAt

What Needs to be Fixed

This was an ordeal to find, but I tracked the problem down to the current implementation of the ensureCacheInitialized method in

#File: vendor/oro/platform/src/Oro/Bundle/EntityExtendBundle/OroEntityExtendBundle.php
function ensureCacheInitialized()
{        
    //...
    $console = escapeshellarg($this->getPhp()) . ' ' . escapeshellarg($this->kernel->getRootDir() . '/console');
    $env     = $this->kernel->getEnvironment();
    $process = new Process($console . ' oro:entity-extend:dump' . ' --env ' . $env);
    $process->setTimeout(100000);
    $process->run();
    //...
}

When running from the command line, the fields mentioned above are normally added by the doctrine:schema:update command. Prior to doctrine:schema:update running, the extended entity cache in

app/cache/prod/oro_entities/Extend/Entity/

is empty. When doctrine:schema:update starts, the Symphony bootstrap triggers the ensureCacheInitialized method. The launches a second process (via proc_open), which generates the oro_entities/Extend/Entity cache (via the oro:entity-extend:dump command). With this cache in place, the doctrine:schema:update command correctly creates the extended attributes/properties.

However, when running from a browser, the oro_entities/Extend/Entity cache is not generated. In my specific instance it's because the Process class uses /usr/bin/php to execute PHP. On my system /usr/bin/php is an older PHP 5.3 binary. This breaks due to the following bug. Since oro:entity-extend:dump never finishes running, the extended entity cache is never created.

The obvious fix here is to resolve the specific PHP 5.3 incompatibility. However, I'd also propose that an approach other than the proc_open approach be used to generate the oro_entities/Extend/Entity cache. Opening shell processes in a browser context is always a sketchy issue.

• There's my specific problem above
• There's the more general problem of not known which system PHP is "the right" one to run
• Even if you can identify "the right" one to run, CLI PHP often runs with a different php.ini file, creating a different execution context
• Finally, the possibility of a race condition is created — if the doctrine:schema:update command executes before proc_open is done, similar "bad things" would have happened.

I'd strongly urge a move away from this approach for the installer. If that's not possible or feasible, I'd recommend an explicit call to oro:entity-extend:dump before running doctrine:schema:update.

ACL One Liners

Using a modified version of the standard steps for installing symfony, the following three commands were used to ensure all files/folders had ACL rights for both the developer's user and the anonymous _www user for apache/mod_php

$ APACHEUSER=`ps aux | grep -E '[a]pache|[h]ttpd|[_]www|[w]ww-data' | grep -v root | head -1 | cut -d\  -f1`
$ sudo find . -type f -exec chmod +a "$APACHEUSER allow delete,write,append,file_inherit,directory_inherit" '{}' +
$ sudo find . -type f -exec chmod +a "`whoami` allow delete,write,append,file_inherit,directory_inherit" '{}' +

[dxops]

Hi, @astorm !

Accounts table is ok now. Thanks!