Protect Custom directory

[mswoods2]

I want to upgrade from 7.7.3 to 7.8.5.

Is the upgrader going to overwrite anything in my “/custom/” dir?
Or write anything at all to “/custom/?”.

Or have we moved beyond that (back to the Sugar, “upgrade-safe” model).

Should I set “/custom/” to “unwriteable” (0400) before running the upgrade?

[roberto]

custom directory is “upgrade safe”, will not written.
If you want to controll, open the upgrade zip file to verify by your self.

Before every upgrade remember to make a backup of your suitecrm files and db

[mswoods2]

I cloned all files and database and created a new subdomain.
Then I chmod -R 0400 “/custom/” (just to be safe).

The upgrade went off without a hitch!

Well… almost.
A little bit of strangeness (see attachment).
All my custom field labels seem to have gotten “misplaced.”

Anyone have any thoughts on what might have happened here?

Thanks!

[roberto]

First try “quick repair and rebuild” (also “rebuild javascript language” can help) from repair section af the administration pannel.
Check also in the studio if your custom labels are ok.

[mswoods2]

Custom field labels are parsed properly in Studio > Leads > Labels

But not in
Studio > Leads > Layouts > whateverView

Have they changed the way the "ViewDefs.php files work (e.g.: “/custom/modules/leads/metadata/detailviewdefs.php”???

Mine look like they always have:
4 =>
array (
0 =>
array (
‘name’ => ‘phone_work’,
‘studio’ => ‘visible’,
‘label’ => ‘LBL_PHONE_WORK’,
),
1 =>
array (
‘name’ => ‘search_city_c’,
‘label’ => ‘LBL_SEARCH_CITY’,
),
),
5 =>
array (
0 =>
array (
‘name’ => ‘email1’,
‘customCode’ => ‘{$bean->email1} (primary)’,
‘label’ => ‘E-mail:’,
),
1 =>
array (
‘name’ => ‘email_validation_c’,
‘studio’ => ‘visible’,
‘label’ => ‘LBL_EMAIL_VALIDATION’,
),
),

[mswoods2]

I see now, that this is happening to ALL modules. Leads, Users, employees, etc.
Labels are not being translated/parsed

Anyone know where the logic is that’s responsible for this?

[mswoods2]

It seems that by write-protecting ‘/custom/’ dir, I botched the upgrade.

Looking at the installer, there are over 1,000 calls to ‘/custom/’ so I was basing everything I did on a false assumption.

*I’ll clone our 7.7.3 install again and try upgrading, ALLOWING it to mess with our “/custom/” directory.
I sure don’t feel good about this.

[roberto]

Probably there are some code in the installer script to allineate old version to new version…

[mswoods2]

Probably, yes.