🍱 🚛 💅🏼 Problemas e princípios de personalização da versão em caixa do Bitrix24 🧕🏾 🔤 🔍

Em algum momento, muitas empresas chegaram à conclusão de que vários processos de negócios precisam ser automatizados para não perder seu lugar ao sol e a seus clientes. Portanto, os clientes estão cada vez mais começando a "digitalizar" seus negócios.

Existem diferentes plataformas para esse fim, o Bitrix24 é um dos mais populares. A velocidade do desenvolvimento e o surgimento de novos recursos, o suporte de alta qualidade e um rico conjunto de ferramentas que, mesmo com personalização mínima, atendem às necessidades básicas das mais diferentes empresas, fazem dessa plataforma uma solução quase perfeita para os negócios.

Mas, infelizmente, não para desenvolvedores, especialmente iniciantes.

Os especialistas escrevem artigos de treinamento sobre o 1C-Bitrix e vários módulos do sistema, mas depois de lê-los, os iniciantes ainda não têm uma imagem comum e entendem como tudo funciona nesta plataforma. Existem artigos na Internet sobre o desenvolvimento de melhores práticas em estruturas, mas o desenvolvimento no B24 é ignorado. Existem empresas que aprenderam a fabricar um produto de qualidade, mas mantêm suas melhores práticas em segredo.

Se você quiser saber como pode trabalhar com o Bitrix24, mantendo a cor original do cabelo, seja bem-vindo ao gato.

Julia Silantieva é desenvolvedora líder do Bitrix24 na agência digital de ciclo completo da ITECH.

O que é o Bitrix24

Provavelmente, todos que, por seus serviços ou interesses, ao menos uma vez encontraram o desenvolvimento do Bitrix24, conhecem o produto 1C-Bitrix: Gerenciamento de Site (BUS) . Este é um CMS para a criação de sites ou, pela definição do próprio Bitrix, um sistema de gerenciamento de recursos da Internet.

Mas poucas pessoas sabem que o portal corporativo Bitrix24 é um serviço escrito em 1C-Bitrix.

Bitrix24 tem 2 soluções: nuvem e caixa. Eles diferem, como o nome indica, pelo local do código do portal: nos servidores Bitrix ou no servidor cliente. A caixa oferece mais espaço para a imaginação, mas possui uma licença mais cara e precisa de suporte do servidor, e a nuvem é mais barata, mas possui várias restrições de personalização.

Em geral, você pode modificar as versões em nuvem e em caixa. Qual solução usar depende das necessidades do cliente.

Na estrutura deste artigo, quero considerar mais detalhadamente as abordagens gerais de desenvolvimento na versão em caixa do Bitrix24 .

Solução Box: Arquitetura do Produto

Dentro do serviço, encontra-se o Bitrix Framework , que é o núcleo do site.

O Bitrix Framework contém módulos e componentes:

Um módulo é um modelo de dados e API para acessar esses dados. Todo o produto é dividido estruturalmente em módulos responsáveis por uma área específica de aplicação: Intranet, Tarefas, CRM, Processos de negócios e outros.
Um componente é um controlador e visualização para uso em uma seção pública. Um componente usando a API de um ou mais módulos manipula dados. O modelo do componente (exibição) exibe dados na página. Os componentes fazem parte dos módulos, mas resolvem um problema mais restrito e específico, por exemplo, exibem uma lista de tarefas ou um cartão de oferta. Toda a parte pública do serviço é construída em uma chamada a partir da página de vários componentes. Por exemplo, uma página de lista de ofertas de CRM consiste em componentes de menu, filtro e lista.

O núcleo do Bitrix Framework são arquivos localizados no diretório / bitrix . Você não pode fazer alterações no kernel ( geralmente. Nunca. Nem pense nisso ) por vários motivos:

ao atualizar o sistema, as alterações feitas serão apagadas;
;
, — , .

No entanto, há outra grande ressalva.

O portal Bitrix24, como qualquer outro site escrito em 1C-Bitrix, inclui um modelo de site, uma parte pública (ou seja, seções e páginas), componentes e modelos de componentes. E difere de um site comum, pois ao instalar atualizações, todos os itens acima também são atualizados. Portanto, a parte pública, o modelo Bitrix24 e os componentes padrão também podem ser considerados o núcleo do Bitrix24 . E isso significa que você também não pode fazer alterações (pelo menos porque elas serão excluídas durante a próxima atualização).

Mas ainda existem brechas, e é real fazer alterações sem problemas.

Capacidade de atualização

As atualizações do produto são muito importantes. Eles resolvem problemas de segurança, fecham os bugs existentes (no entanto, às vezes eles produzem novos logo ali :)). Às vezes, novos pães legais chegam com atualizações.

Os principais novos produtos bitrixóides são apresentados em suas conferências, que são realizadas a cada seis meses (a última foi realizada on-line em abril ), mas são lançadas com patches quase todos os dias. Manter-se atualizado ajuda a atualizações por email. Você pode conectá-lo no painel de administração de qualquer portal do Bitrix24: Marketplace -> Atualização da plataforma -> Avançado -> Inscrever-se para receber informações sobre atualizações por email .

A Bitrix aconselha a instalação de atualizações assim que estiverem disponíveis. Mas eu recomendaria nem sempre seguir esse conselho. É aconselhável instalar atualizações em horários de carga mínima no servidor, por exemplo, nos finais de semana ou à noite - de acordo com a lei de Murphy, no momento em que você precisa fazer tudo de forma rápida e silenciosa, o Bitrix trava com um erro ao atualizar. :) Obviamente, isso acontece com pouca frequência, mas não faz mal jogar pelo seguro. E não se esqueça de fazer backup antes de iniciar as atualizações.

Princípios de personalização

Todo o desenvolvimento deve ser realizado em uma pasta - / local .

Para adicionar sua funcionalidade ao site escrito em BUS, localize o componente necessário, copie-o para a pasta / local , personalize a classe e o modelo do componente.

Na Bitrix24, essa abordagem é fundamentalmente errada.

Primeiramente, se você copiar o modelo para o diretório / local , o sistema sempre o usará em vez do padrão. Isso significa que, após a próxima atualização, o cliente não verá novas funções que podem ser adicionadas a esse componente e os erros, se houver, não serão corrigidos. Manter a relevância manualmente dos componentes é difícil e, se as alterações forem globais, serão impossíveis.

Em segundo lugar, os componentes de serviço são um sistema completo e seu código é escrito na suposição de que o sistema original é usado em todo o sistema. Isso significa que um modelo personalizado pode levar à incompatibilidade de informações com o restante do sistema e se tornar uma fonte de erros difíceis de capturar.

O que, então, é um desenvolvedor que precisa alterar ou adicionar algum tipo de lógica?

Existem várias soluções para o problema:

tirar proveito de certos pontos de inserção permitidos na interface e funções adiadas;
altere o resultado da execução do componente e inclua seus próprios estilos e scripts;
crie seu próprio processo de negócios ou configure robôs;
vincular a eventos no lado do PHP ou JS;
crie seu próprio tipo de campo (por exemplo, um widget);
escreva sua aplicação;
escreva seu módulo.

Para cada tarefa, você deve escolher a ferramenta mais adequada.

Local

A pasta principal onde o desenvolvedor pode e deve executar suas mãos é / local . Inicialmente, ele não está no projeto, portanto, você pode preencher a pasta a seu critério, mas em termos de caminhos, é importante seguir as instruções do Bitrix, caso contrário, a plataforma não verá componentes e módulos personalizados.

Oferecemos uma estrutura universal de pastas / local :

atividades contém ações de processos de negócios.
componentes contém componentes auto-gravados (não devem ser confundidos com componentes Bitrix personalizados!).
css , fontes , imagens , js contêm os arquivos e recursos correspondentes.
modules . , .
php_interface php-. ajax-, , , .
- init.php — Bitrix Framework. . , , . init.php , , , init.php . , , __autoload composer.
templates .
tools cron .

A estrutura é muito flexível: quando é necessário (por exemplo, quando novas tarefas aparecem), você pode adicionar novas seções à pasta, em vez de gastar tempo desenvolvendo uma nova estrutura.

Ao processar pastas, sempre é dada prioridade à pasta / local sobre / bitrix . Isso significa que, se os modelos de site com o mesmo nome estiverem localizados em / local / templates / e / bitrix / templates / , o modelo de / local será conectado .

Uma observação importante segue daqui : para que o Bitrix entenda que é necessário obter modelos de componentes personalizados da pasta / local , ele deve ter uma certa estrutura:

/ local / templates / site_template / components / namespace / component_name / template_name / .

Ao mesmo tempo, a pasta de modelo de site em / local (estamos falando do Bitrix24, não do BUS) deve conter um modelo criado pelo Bitrix ( / bitrix / templates / bitrix24 / ). Somente nesse caso, o sistema entenderá que é necessário conectar o componente a partir de / local .

O que mais é importante ter em mente ao projetar?

1. Todas as variáveis de idioma devem ser armazenadas nos arquivos lang correspondentes. O arquivo de idioma é um script php que armazena traduções de frases em um idioma específico. Esse script consiste em uma matriz $ MESS, cujas chaves são identificadores de frases de idiomas e os valores são traduzidos para o idioma correspondente.

Cada idioma possui seu próprio conjunto de arquivos de idiomas armazenados nos subdiretórios / lang / da estrutura de arquivos do sistema ou módulo.

Por que é importante colocar todos os textos em arquivos separados? Ao traduzir seu portal para outro idioma, será suficiente coletar e traduzir apenas frases de arquivos de idiomas, enquanto cria novas seções para o idioma correspondente. Não haverá necessidade de procurar lugares onde os textos possam ocorrer no código e fazer alterações diretamente no código do portal.

Leia mais sobre como usar arquivos de idioma em um documento oficial .

2. Ao trabalhar com componentes, você não precisa acessar o banco de dados diretamente. O conceito de trabalhar com o produto envolve trabalhar com dados através de funções da API. A estrutura de dados pode variar de versão para versão e as funções mantêm a compatibilidade com versões anteriores. O Bitrix desencoraja fortemente o uso de consultas diretas ao banco de dados, pois isso pode violar a integridade dos dados e levar à inoperabilidade do sistema.

Além disso, se estamos falando sobre as tabelas de sistema do próprio Bitrix Framework, isso não é apenas bem-vindo, mas, em princípio, não é suportado. É necessário trabalhar com eles por meio da API do sistema, pois a estrutura física do banco de dados pode mudar e o trabalho da API mais antiga é garantido.

3. O controle de versão trabalha em um projeto usando um sistema de controle de versão. Ao mesmo tempo, devido às peculiaridades do desenvolvimento no Bitrix, faz sentido fornecer uma “peculiaridade” na configuração do repositório para o projeto: separar os arquivos principais e personalizados.

4. Leia as docas. Em muitos problemas locais, especialmente comuns no 1C-Bitrix, você pode encontrar artigos ou documentação separados. Para desenvolvedores que estão acostumados ao google imediatamente em inglês, será uma surpresa que a maioria dos artigos seja escrita em russo. :)

E você precisa se lembrar da regra de ouro que desenvolvedores experientes aconselham a seguir : menos código - menos bugs .

Total

Hoje você pode observar o desequilíbrio entre oferta e demanda no mercado de desenvolvimento para o Bitrix24. A necessidade de desenvolvedores está crescendo rapidamente, e muitos especialistas não querem se envolver com o produto Bitrix, pois estão familiarizados com a ideia mais antiga e já praticamente morta - o BUS.

Mas o diabo não é tão terrível, e até mesmo desenvolvedores iniciantes poderão se acostumar e produzir um produto de alta qualidade que "não tem vergonha de mostrar aos garotos" © user habr.

Problemas e princípios de personalização da versão em caixa do Bitrix24