Masalah dan prinsip penyesuaian versi kotak Bitrix24



Banyak perusahaan pada titik tertentu sampai pada kesimpulan bahwa sejumlah proses bisnis perlu diotomatisasi agar tidak kehilangan tempat mereka di bawah sinar matahari dan pelanggan mereka. Karena itu, pelanggan semakin mulai "mendigitalkan" bisnis mereka.

Ada berbagai platform untuk tujuan ini, Bitrix24 adalah salah satu yang paling populer. Kecepatan pengembangan dan kemunculan fitur-fitur baru, dukungan berkualitas tinggi, dan seperangkat alat yang kaya bahkan dengan penyesuaian minimal mencakup kebutuhan dasar sebagian besar perusahaan yang berbeda, menjadikan platform ini solusi yang hampir sempurna untuk bisnis.

Tapi, sayang sekali, bukan untuk pengembang, terutama pemula.

Para ahli menulis artikel pelatihan tentang 1C-Bitrix dan berbagai modul sistem, tetapi setelah membacanya, pemula masih belum memiliki gambaran umum dan memahami bagaimana semuanya bekerja pada platform ini. Ada artikel di Internet tentang pengembangan praktik terbaik pada kerangka kerja, tetapi pengembangan pada B24 dilewati. Ada perusahaan yang telah belajar membuat produk yang berkualitas, tetapi mereka merahasiakan praktik terbaiknya.

Jika Anda ingin tahu cara bekerja dengan Bitrix24, sambil mempertahankan warna rambut asli, selamat datang di kucing.

Julia Silantieva adalah pengembang terkemuka Bitrix24 di agensi digital siklus penuh ITECH.

Apa itu Bitrix24


Mungkin, setiap orang yang, karena layanan atau minat mereka, setidaknya sekali mengalami pengembangan untuk Bitrix24, mengetahui produk 1C-Bitrix: Manajemen Situs (BUS) . Ini adalah CMS untuk membuat situs web atau, dengan definisi Bitrix sendiri, sistem manajemen sumber daya Internet.

Tetapi hanya sedikit orang yang tahu bahwa portal perusahaan Bitrix24 adalah layanan yang ditulis dalam 1C-Bitrix.

Bitrix24 memiliki 2 solusi: cloud dan box. Mereka berbeda, sesuai namanya, berdasarkan lokasi kode portal: pada server Bitrix atau pada server klien. Kotak memberi lebih banyak ruang untuk imajinasi, tetapi memiliki lisensi yang lebih mahal dan membutuhkan dukungan server, dan cloud lebih murah, tetapi memiliki sejumlah batasan pada kustomisasi.

Secara umum, Anda dapat memodifikasi versi cloud dan versi kotak. Solusi mana yang digunakan tergantung pada kebutuhan klien.

Dalam kerangka artikel ini, saya ingin mempertimbangkan secara lebih rinci pendekatan umum untuk pengembangan pada versi kotak Bitrix24 .

Solusi Kotak: Arsitektur Produk


Di dalam layanan terdapat Bitrix Framework , yang merupakan inti dari situs.

Bitrix Framework berisi modul dan komponen:

  1. Modul adalah model data dan API untuk mengakses data ini. Seluruh produk secara struktural dibagi menjadi modul yang bertanggung jawab untuk area aplikasi tertentu: Intranet, Tugas, CRM, proses bisnis dan lain-lain.
  2. Komponen adalah pengontrol dan tampilan untuk digunakan di bagian publik. Komponen yang menggunakan API dari satu atau lebih modul memanipulasi data. Templat komponen (tampilan) menampilkan data pada halaman. Komponen adalah bagian dari modul, tetapi menyelesaikan masalah yang lebih sempit, lebih spesifik, misalnya, menampilkan daftar tugas atau kartu kesepakatan. Seluruh bagian publik dari layanan dibangun berdasarkan panggilan dari halaman berbagai komponen. Misalnya, halaman daftar transaksi CRM terdiri dari komponen menu, filter, dan daftar.



Inti dari Bitrix Framework adalah file yang terletak di direktori / bitrix . Anda tidak dapat membuat perubahan pada kernel ( Umumnya. Tidak pernah. Jangan pernah memikirkannya ) karena beberapa alasan:

  • saat memperbarui sistem, perubahan yang dilakukan akan dihapus;
  • ;
  • , β€” , .

Namun, ada peringatan besar lainnya.

Portal Bitrix24, seperti situs lain yang ditulis dalam 1C-Bitrix, termasuk templat situs, bagian publik (yaitu bagian dan halaman), komponen dan templat komponen. Dan ini berbeda dari situs biasa ketika menginstal pembaruan semua hal di atas juga diperbarui. Oleh karena itu, bagian publik, template Bitrix24 dan komponen standar juga dapat dianggap sebagai inti dari Bitrix24 . Dan ini berarti Anda tidak dapat membuat perubahan di dalamnya (setidaknya karena akan dihapus selama pembaruan berikutnya).



Tetapi masih ada celah, dan itu nyata untuk membuat perubahan tanpa rasa sakit.

Pembaruan


Pembaruan produk sangat penting. Mereka memecahkan masalah keamanan, menutup bug yang ada (namun, kadang-kadang mereka menghasilkan yang baru di sana :)). Terkadang roti keren baru tiba dengan pembaruan.

Produk-produk utama Bitrixoid baru disajikan di konferensi mereka, yang diadakan setiap enam bulan (yang terakhir diadakan pada bulan April online ), tetapi mereka dirilis dengan patch hampir setiap hari. Mengikuti perkembangan membantu pembaruan email. Anda dapat menghubungkannya di panel admin portal apa pun di Bitrix24: Marketplace -> Platform Update -> Advanced -> Berlangganan untuk menerima informasi tentang pembaruan melalui surat .



Bitrix menyarankan untuk menginstal pembaruan segera setelah tersedia. Tetapi saya akan merekomendasikan untuk tidak selalu mematuhi saran ini. Dianjurkan untuk menginstal pembaruan pada saat beban minimal di server, misalnya, pada akhir pekan atau malam hari - menurut hukum Murphy, pada saat Anda harus melakukan semuanya dengan cepat dan pelan, Bitrix lumpuh dengan kesalahan saat memperbarui. :) Tentu saja, ini jarang terjadi, tetapi tidak ada salahnya untuk bermain aman. Dan jangan lupa untuk membuat cadangan sebelum memulai pembaruan.

Prinsip Kustomisasi


Semua pengembangan harus dilakukan dalam satu folder - / lokal .

Untuk menambahkan fungsionalitas Anda ke situs yang ditulis dalam BUS, cukup temukan komponen yang Anda butuhkan, salin ke folder / lokal , sesuaikan kelas dan templat komponen.

Di Bitrix24, pendekatan ini pada dasarnya salah.

Pertama, jika Anda menyalin template ke direktori / local , sistem akan selalu menggunakannya daripada yang standar. Ini berarti bahwa setelah pembaruan berikutnya, klien tidak akan melihat fungsi-fungsi baru yang dapat ditambahkan ke komponen ini, dan kesalahan, jika ada, tidak akan diperbaiki. Mempertahankan relevansi komponen secara manual itu sulit, dan jika perubahannya bersifat global, maka tidak mungkin.

Kedua, komponen layanan adalah sistem yang lengkap, dan kode mereka ditulis dengan asumsi bahwa sistem asli digunakan di seluruh sistem. Ini berarti bahwa templat khusus dapat menyebabkan ketidakcocokan informasi dengan sistem lainnya dan menjadi sumber kesalahan yang sulit ditangkap.

Lalu, apa yang harus diubah atau ditambahkan semacam logika oleh pengembang?

Ada beberapa solusi untuk masalah ini:

  • memanfaatkan titik penyisipan tertentu yang diizinkan ke dalam antarmuka dan fungsi yang tertunda;
  • ubah hasil eksekusi komponen dan tambahkan gaya dan skrip Anda sendiri ke dalamnya;
  • buat proses bisnis Anda sendiri atau buat robot;
  • ikat ke acara di sisi PHP atau JS;
  • buat jenis bidang Anda sendiri (misalnya, widget);
  • tulis aplikasi Anda;
  • tulis modul Anda.

Untuk setiap tugas Anda harus memilih alat yang paling cocok.

Lokal


Folder utama tempat pengembang dapat dan harus menjalankan tangannya adalah / lokal . Awalnya, ini bukan pada proyek, sehingga Anda dapat mengisi folder sesuai kebijakan Anda, tetapi dalam hal jalur, penting untuk mengikuti instruksi Bitrix, jika platform tidak akan melihat komponen dan modul khusus.

Kami menawarkan struktur folder universal / lokal :



  • kegiatan berisi tindakan proses bisnis.
  • komponen berisi komponen yang ditulis sendiri (jangan dikacaukan dengan komponen Bitrix yang disesuaikan!).
  • css , font , gambar , js berisi file dan sumber daya yang sesuai.
  • modules . , .
  • php_interface php-. ajax-, , , .
    • init.php β€” Bitrix Framework. . , , . init.php , , , init.php . , , __autoload composer.

  • templates .
  • tools cron .

Struktur ini sangat fleksibel: bila perlu (misalnya, ketika tugas baru muncul), Anda dapat menambahkan bagian baru ke folder, daripada menghabiskan waktu mengembangkan struktur baru.

Saat memproses folder, prioritas selalu diberikan ke / local folder over / bitrix . Ini berarti bahwa jika templat situs dengan nama yang sama terletak di / local / templates / dan / bitrix / templates / , maka templat dari / local akan terhubung .

Pengamatan penting berikut dari sini : agar Bitrix memahami bahwa perlu untuk mengambil templat komponen khusus dari folder / lokal , itu harus memiliki struktur tertentu:

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

Pada saat yang sama, folder templat situs di / lokal (kita berbicara tentang Bitrix24, bukan BUS) harus berisi templat yang dibuat oleh Bitrix ( / bitrix / templates / bitrix24 / ). Hanya dalam kasus ini, sistem akan memahami bahwa komponen harus disambungkan dari / lokal .

Apa lagi yang penting untuk diingat saat mendesain?


1. Semua variabel bahasa harus disimpan dalam file lang yang sesuai. File bahasa adalah skrip php yang menyimpan terjemahan frasa bahasa ke dalam bahasa tertentu. Script ini terdiri dari array $ MESS, kunci yang merupakan pengidentifikasi dari frase bahasa, dan nilainya adalah terjemahan ke dalam bahasa yang sesuai.

Setiap bahasa memiliki set sendiri file bahasa yang disimpan dalam subdirektori / lang / dari struktur file sistem atau modul.

Mengapa penting untuk membawa semua teks ke file terpisah? Saat menerjemahkan portal Anda ke bahasa lain, cukup mengumpulkan dan menerjemahkan hanya frasa dari file bahasa, sembari membuat bagian baru untuk bahasa yang sesuai. Tidak perlu mencari tempat di mana teks dapat muncul dalam kode, dan membuat perubahan langsung ke kode portal.

Baca lebih lanjut tentang cara menggunakan file bahasa dalam dokumen resmi .

2. Saat bekerja dengan komponen, Anda tidak perlu mengakses database secara langsung. Konsep bekerja dengan produk melibatkan bekerja dengan data melalui fungsi API. Struktur data dapat bervariasi dari versi ke versi, dan fungsi mempertahankan kompatibilitas ke belakang. Bitrix sangat tidak mendukung penggunaan permintaan basis data langsung, karena hal ini dapat melanggar integritas data dan menyebabkan sistem tidak dapat dioperasikan.

Selain itu, jika kita berbicara tentang tabel sistem dari Bitrix Framework itu sendiri, ini bukan saja tidak disambut, tetapi pada prinsipnya tidak didukung. Penting untuk bekerja dengan mereka melalui API sistem, karena struktur fisik basis data dapat berubah, dan pekerjaan bahkan API tertua dijamin.

3. Versi bekerja pada proyek menggunakan sistem kontrol versi. Pada saat yang sama, karena kekhasan pengembangan pada Bitrix, masuk akal untuk menyediakan "kekhasan" dalam menyiapkan repositori untuk proyek: pisahkan file inti dan yang khusus.

4. Baca dermaga. Pada banyak masalah lokal, terutama yang umum dengan 1C-Bitrix, Anda dapat menemukan artikel atau dokumentasi terpisah. Untuk pengembang yang terbiasa dengan google segera dalam bahasa Inggris, akan mengejutkan bahwa sebagian besar artikel ditulis dalam bahasa Rusia. :)

Dan Anda perlu mengingat aturan emas yang disarankan pengembang untuk mematuhi: lebih sedikit kode - lebih sedikit bug .

Total


Hari ini Anda dapat mengamati ketidakseimbangan antara penawaran dan permintaan di pasar pengembangan untuk Bitrix24. Kebutuhan akan pengembang berkembang pesat, dan banyak ahli tidak ingin terlibat dengan produk dari Bitrix, karena mereka terbiasa dengan gagasan tertua dan sudah praktis mati - BUS.

Tetapi iblis tidak begitu mengerikan, dan bahkan pengembang pemula akan dapat terbiasa dan menghasilkan produk berkualitas tinggi yang β€œtidak malu untuk menunjukkan kepada anak laki-laki” Β© pengguna habr.

All Articles