Instâncias de desenvolvimento
Ao fazer alterações, você deve sempre usar uma instância de desenvolvimento ou teste primeiro. Isso permite que você teste todas as alterações de forma completa e segura.

Controle de versão
Ao desenvolver personalizações, é prudente usar alguma forma de controle de versão. O controle de versão permite rastrear alterações em sua base de código, além de reverter as alterações. Existem muitos sistemas de controle de versão disponíveis. SuiteCRM usa Git, embora eu também goste de Mercurial.

Se você estiver usando uma instância de desenvolvimento (como mencionado acima), o Controle de Versão geralmente permite que você envie alterações para outras versões ou para liberar tags. Isso fornece uma maneira de enviar alterações para instâncias ativas ou de teste com segurança. Crucialmente, também significa que, caso haja problemas graves com uma versão, isso pode ser facilmente revertido.

Cópia de segurança
SuiteCRM foi desenvolvido para ser personalizável. No entanto, erros, bugs e outras coisas desagradáveis ​​podem (e graças à lei de Murphy, vão) acontecer. Antes de fazer qualquer alteração, você deve sempre se certificar de que possui um backup de todos os arquivos e do banco de dados.

Para fazer backup dos arquivos, você pode simplesmente criar um arquivo zip do diretório SuiteCRM e copiá-lo para um local seguro. Em sistemas Linux, isso pode ser realizado usando o seguinte:
Exemplo 17.1: backup de arquivo
tar -czvf suitecrmfilebackup.tar.gz /path/to/suitecrm

O backup do banco de dados SuiteCRM irá variar dependendo de qual banco de dados você está usando. No entanto, os backups do MySQL podem ser executados usando o comando mysqldump no Linux, como visto aqui:
Exemplo 17.2: backup do banco de dados MySQL
mysqldump suitecrmdatabase -u databaseuser -p | gzip -c | cat> suitecrm.sql.gz

Seja um upgrade seguro
A menos que você esteja fazendo alterações em um módulo personalizado, você deve se esforçar em todos os casos para usar a estrutura personalizada e fazer alterações na pasta personalizada. Isso garante que, caso você cometa um erro, retificá-lo seja tão simples quanto remover a personalização.

No entanto, a principal vantagem de usar o personalizado é que, quando você atualizar o SuiteCRM no futuro, você não terá suas alterações sobrescritas pelos arquivos do SuiteCRM atualizados. Consulte o capítulo Extensões para obter mais informações.

Use níveis de registro apropriados
O uso de níveis de registro apropriados (consulte o capítulo sobre Registro) torna mais fácil rastrear problemas. Você não quer que mensagens muito importantes sejam registradas como depuração, pois isso dificultará sua localização. Da mesma forma, você não quer mensagens de registro sem importância bagunçando a saída do registro fatal.

Ganchos lógicos de longa duração
Se uma tarefa de gancho lógico é de longa execução, você deve colocá-la na fila de trabalhos (consulte os capítulos Ganchos Lógicos e Tarefas Agendadas).

Minimize SQL
Sempre que possível, você deve se esforçar para usar os métodos fornecidos pelo SuiteCRM para acessar dados. Isso inclui o uso de beans e da BeanFactory onde possível (consulte o capítulo Trabalhando com beans). Existem algumas razões para isso. A primeira é que o SQL geralmente é codificado ou deve ser construído dinamicamente. No caso em que o SQL está codificado, isso significa que as alterações nos campos não serão refletidas, tornando o código mais frágil.

O SQL dinâmico é melhor porque pode reagir às mudanças de campo e geralmente ser adaptado para se ajustar à situação. No entanto, isso requer a adição de código extra, muitas vezes complexo. Pode ser difícil explicar todas as situações (isso pode ser especialmente problemático ao tentar atravessar relacionamentos dinamicamente).

Outro problema é que, normalmente, o SQL acabará sendo específico do Banco de Dados (consulte o próximo ponto para atenuar isso, no entanto).

Finalmente, qualquer lógica customizada (como Logic Hooks) que normalmente seria disparada para salvar beans ou relacionamentos não será disparada para consultas SQL.

Uso de SQL
Em alguns casos, o uso de SQL bruto é inevitável. Se for esse o caso, você deve se esforçar para usar o SQL compatível com o padrão. Se recursos específicos do mecanismo de banco de dados precisam ser usados ​​e você deseja direcionar outros mecanismos de banco de dados, pode verificar o tipo de banco de dados. Por exemplo:
Exemplo 17.1: Verificando o mecanismo de banco de dados

function getSomeSQLQuery(){
      global $sugar_config;
      switch($sugar_config['dbconfig']['db_type']){
          case 'mssql':
              $sql = 'MSSQL specific SQL';
              break;
          case 'mysql':
          default:
              $sql = 'MySQL specific SQL';
              break;
      }
      return $sql;
 }

Verificação de entrada
A maioria dos arquivos SuiteCRM começará com alguma variação da seguinte linha:

Exemplo 17.2: Verificação de entrada
if (! defined (‘sugarEntry’) ||! sugarEntry) die (‘Não é um ponto de entrada válido’);

Isso evita o acesso direto ao arquivo garantindo que o SuiteCRM foi carregado por meio de um ponto de entrada válido (ou seja, foi carregado por meio de index.php, cron.php ou um ponto de entrada personalizado).

Redirecionar após a postagem
Às vezes, você pode ter ações de controlador personalizadas (consulte a seção de controladores) ou pontos de entrada personalizados (consulte o capítulo Pontos de entrada). Essas ações e pontos de entrada ou outras páginas geralmente são acessados ​​usando POST. Após uma solicitação POST, é uma prática recomendada da web redirecionar para uma página diferente, especialmente se sua página fizer alterações. Isso evita que o usuário atualize a página e cause uma ação duplicada. No SuiteCRM, é melhor usar o método SugarApplication :: redirect para redirecionar. Isso simplesmente aceita um URL. Do seguinte modo:
Exemplo 17.3: Redirecionando dentro do SuiteCRM
SugarApplication :: redirect (‘index.php? Module = ‘);