SugarIcons and FontAwesome in the same definition

Rafael Fernandes as Francesca Shiekh noted. I need one set of code that will work with both on-premise instances of Sugar and On-Demand instances. On-Premise customers have FA and will most likely for the next 10 years. How do I add code to handle both situations? Having 2 sets of code is very difficult to manage. We are already running into this for Sugar 11.2.0 Sugar Cloud and Sugar 9 on-premise. 

Hi everyone,

Took me a bit longer to get all the answers I needed to reply it back to you on this matter.

- To reiterate, SugarIcon is our standard icon library going forward and we expect to expand the number of available icons over time.
- FontAwesome is deprecated and we plan to remove it as per earlier announcement
- Here are some alternative paths to explore:
- You can include FontAwesome in your MLPs as you would with any other code library that isn't part of Sugar core.
- During a previous FontAwesome upgrade from v3 to v4, we created an open source "Compatibility MLP package" that could be installed to add back v3 icon support for instances that needed that. We're currently exploring doing something similar for this icon library upgrade. : (sugarclub.sugarcrm.com/.../font-awesome-3-2-1-compatibility-package-for-sugar-7-6)

We do not need multiple versions of FontAwesome, we need to support both Font Awesome and Sugaricon in a single package. It seems that SugarCRM believes that everybody will upgrade their on-premise versions of Sugar when Sugar 12 comes out. There are plenty of Sugar 8, 9, 10 Sugar installations in the wild that we support with our module loadable packages. 

Your suggestion is that we maintain a Font Awesome version and a Sugar Icon version. We need Sugar to be smart enough that we can use a single code base and that the core of Sugar is smart enough to use sicon if that is present in a definition. 

In my example, I'd like to define the icon as fa-plus sicon-plus

array(
        'route' => "#$moduleName/create",
        'label' => 'LNK_NEW_RECORD',
        'acl_action' => 'create',
        'acl_module' => $moduleName,
        'icon' => 'fa-plus sicon-plus',
    ),

Hopefully, sugar would see this and display the correct icon. 

/cc Rafael Fernandes 

We do not need multiple versions of FontAwesome, we need to support both Font Awesome and Sugaricon in a single package. It seems that SugarCRM believes that everybody will upgrade their on-premise versions of Sugar when Sugar 12 comes out. There are plenty of Sugar 8, 9, 10 Sugar installations in the wild that we support with our module loadable packages. 

Your suggestion is that we maintain a Font Awesome version and a Sugar Icon version. We need Sugar to be smart enough that we can use a single code base and that the core of Sugar is smart enough to use sicon if that is present in a definition. 

In my example, I'd like to define the icon as fa-plus sicon-plus

array(
        'route' => "#$moduleName/create",
        'label' => 'LNK_NEW_RECORD',
        'acl_action' => 'create',
        'acl_module' => $moduleName,
        'icon' => 'fa-plus sicon-plus',
    ),

Hopefully, sugar would see this and display the correct icon. 

/cc Rafael Fernandes 

just an update here, I'm working with multiple teams internally to find solutions and alternatives for this, I'll keep you all posted as soon as those meetings happen.

Hi Jeff Bickart,

I'd like to give you a feedback on this topic.

We met internally today to go over this problem. In the call, the problem and possible solutions were exposed and discussed (including your scenarios). We are taking a step forward to come up with a solution for it now with the right people and teams involved.

I'll let the community know what we come up with soon.

rafa

Hey Jeff Bickart

I use this in our add-ons to adjust the links in the new admin-page menu :

global $sugar_config;
if (!empty($sugar_config['sugar_version'])
    && version_compare($sugar_config['sugar_version'], '11.3.0', '<')
) {

....

The file is located in
custom/Extension/modules/Administration/Ext/Administration/

Hopefully it might help pending an official answer, but could quickly become tiresome if you need to change many viewdefs from the Extension directories.

Best Regards,
Laurent

PS : an other way to do it would be to prepare both versions of the file and delete the 'wrong" one from the manifest array in the pre-install package, so that only the adequate version install.

Hello Rafael Fernandes,

is there maybe already something new regarding to this problem?

This might not work in newer versions as they will have a package scanner on upgrades which will fail if it detects fa- in your custom work.