Perbandingan Mendetail Antara WordPress dan CMS Oktober

Tiga bulan lalu, WordPress akhirnya merilis Gutenberg yang didukung oleh React untuk memperkuat pengalaman pengeditan konten default, memicu banyak orang yang tidak senang dengan perubahan ini untuk mencari alternatif. Beberapa orang memutuskan untuk melakukan fork dan merilis WordPress pra-Gutenberg, namun, bagi saya ini tidak masuk akal karena masih membawa utang teknis senilai 15 tahun. Jika saya menemukan alternatif untuk WordPress, saya akan mencoba untuk menghindari terjebak di masa lalu, dan bertujuan untuk memotong bersih melalui beberapa platform matang yang dibangun di atas fondasi modern.

Artikel ini membandingkan WordPress dengan CMS Oktober yang mirip namun lebih modern dalam berbagai topik teknis dan non-teknis. Tujuan artikel ini bukan untuk meyakinkan orang agar tetap menggunakan WordPress atau beralih ke CMS Oktober, tetapi hanya untuk menunjukkan aspek apa yang harus dipertimbangkan sebelum menyimpulkan perpindahan ke platform yang berbeda. Perbandingan yang sama dapat (dan harus) juga dilakukan dengan platform lain sebelum membuat keputusan yang masuk akal.

Mengapa Oktober CMS

Saya mengetahui tentang CMS Oktober ketika memenangkan penghargaan, setelah itu saya masuk ke mode penelitian dan menghabiskan banyak waktu untuk menggali jauh ke dalam CMS ini — dari perspektif pengguna dan pengembang. Ketika saya memperoleh pengetahuan tentang CMS ini, saya merasa yakin bahwa saya dapat memberikan evaluasi yang objektif tentang fitur-fiturnya dibandingkan dengan WordPress. Saya memilih CMS ini untuk perbandingan dibandingkan opsi alternatif seperti Grav, Statamic, ButterCMS, Joomla, Drupal, Jekyll, Hugo, dan lainnya, karena alasan berikut:

• Saya tahu cara kerja CMS ini (tidak seperti Grav);
• Ini gratis dan open source (tidak seperti Statamic dan ButterCMS);
• Pada lima tahun, ini "relatif" baru (tidak seperti Joomla dan Drupal);
• Ini adalah generator konten dinamis (bukan statis) dan berbasis di PHP (tidak seperti Jekyll dan Hugo).
  

Saya percaya bahwa Oktober CMS adalah kandidat yang baik karena didasarkan pada Laravel yang merupakan kerangka kerja yang digunakan untuk membangun aplikasi modern. Setelah tujuh tahun berdiri, ia telah menerima persetujuan positif dari pengembang (sebagaimana dibuktikan oleh komunitas dan ekosistemnya yang cukup besar), dan menandai perbedaan yang mencolok atas pengkodean di WordPress, yaitu WordPress sebagian besar merupakan pemrograman prosedural sementara Laravel jelas merupakan pemrograman berorientasi objek.

Apa Perbedaan Antara Keduanya?

Di bawah ini saya akan membandingkan WordPress dan CMS Oktober pada kategori yang berbeda dan menyoroti apa yang menurut saya baik dan tidak begitu baik tentang mereka. Namun, saya tidak akan memilih pemenang, karena itu bukan tujuan artikel dan, bagaimanapun, tidak ada CMS "terbaik" atau bahkan "lebih baik": setiap CMS memiliki kekuatan dan kelemahannya sendiri yang akan membuatnya kurang lebih cocok untuk setiap tugas, proyek, perusahaan, tim, dan lainnya. Selain itu, sebuah proyek dapat mengambil manfaat dari menggunakan lebih dari satu CMS, seperti menggunakan beberapa CMS untuk mengelola dan menyediakan data, dan CMS lain untuk membuat tampilan. Untuk memutuskan mana dari lusinan CMS di luar sana yang paling cocok untuk kebutuhan Anda sendiri sepenuhnya terserah Anda.

Selain itu, artikel ini tidak pernah bisa menarik kesimpulan yang pasti karena hanya membahas sebagian dari semua kemungkinan. Misalnya, kami juga dapat menemukan perbandingan online seperti "WordPress vs Drupal vs Joomla", "WordPress vs Generator Situs Statis" dan bahkan "WordPress vs Medium". Karena tidak satu pun dari artikel ini melihat gambaran lengkapnya, maka tidak satu pun dari perbandingan ini yang dapat disimpulkan, dan tidak boleh diperlakukan seperti itu.

Mari kita mulai dengan perbandingan.

Filosofi Dan Kelompok Sasaran

Bukan kebetulan bahwa WordPress mendukung hampir 1 dari 3 situs web. Sejak awal, ia telah berusaha untuk menjadi sangat ramah pengguna dan telah melakukannya dengan sukses, menghilangkan gesekan bagi pengguna teknis dan non-teknis serta orang-orang dari semua latar belakang — terlepas dari pendidikan dan tingkat ekonomi mereka. Pendiri WordPress Matt Mullenweg menyatakan bahwa motto WordPress “Democratize Publishing” untuk era saat ini berarti sebagai berikut:

“Orang-orang dari semua latar belakang, minat, dan kemampuan harus dapat mengakses perangkat lunak Free-as-in-speech yang memberdayakan mereka untuk mengekspresikan diri di web terbuka dan memiliki konten mereka.”

WordPress mudah digunakan untuk semua orang dan inklusivitasnya juga dibuktikan di sisi pengembangan: Tidak jarang menemukan orang tanpa latar belakang pemrograman (seperti pemasar, desainer, blogger, tenaga penjualan, dan lainnya) mengutak-atik instalasi WordPress mereka, mendesain tema mereka sendiri dan berhasil meluncurkan situs web mereka sendiri. WordPress berpusat pada pengguna, dan kebutuhan pengguna mengalahkan kebutuhan pengembang. Di WordPress, pengguna adalah raja (atau ratu).

Sebaliknya, CMS Oktober lebih diarahkan ke pengembang, seperti yang ditetapkan secara eksplisit sejak rilis pertamanya:

“Oktober membuat satu asumsi yang berani tapi jelas: klien tidak membangun situs web, pengembang yang melakukannya. Peran klien adalah mengelola situs web dan menyampaikan kebutuhan bisnis mereka. Pengembang web, dan industri itu sendiri, berkisar pada mediasi faktor-faktor ini.”

Dalam kata-kata pendirinya, misi CMS adalah untuk “membuktikan bahwa membuat situs web bukanlah ilmu roket.” Berbasis pada Laravel, October CMS dapat mengklaim memiliki fondasi kuat dari kode modular yang dapat digunakan kembali yang dapat menghasilkan aplikasi yang dirancang dengan benar, dapat dipelihara dalam jangka panjang dan sepenuhnya dapat disesuaikan tanpa memerlukan peretasan — jenis yang menarik pemrogram serius. CMS Oktober juga dapat memberikan pengalaman pengguna yang luar biasa, namun tidak sesederhana atau tanpa gesekan seperti yang disediakan oleh WordPress. Pengguna mungkin perlu dijelaskan cara menggunakan fungsionalitas tertentu sebelum dapat menggunakannya. Misalnya, menyematkan formulir dari beberapa plugin memiliki penjelasan panjang tentang cara melakukannya, yang lebih rumit daripada fungsionalitas seret dan lepas yang disediakan oleh beberapa plugin formulir di WordPress.

Instalasi

WordPress terkenal dengan instalasi 5 menitnya, meskipun banyak orang menunjukkan bahwa (dengan mempertimbangkan semua plugin yang harus diinstal) instalasi biasa membutuhkan 15 menit atau lebih. Selain itu, WordPress juga menawarkan fitur Multisite, yang memungkinkan kita membuat jaringan beberapa situs virtual dalam satu instalasi. Fitur ini memudahkan agensi untuk mengelola situs beberapa klien — di antara kasus pengguna lainnya.

Instalasi CMS Oktober juga sangat lancar: Instalasi Wizard itu sendiri membutuhkan waktu kurang dari lima menit, dan jika Anda menginstalnya melalui instalasi Konsol, itu bahkan lebih cepat. Anda dapat melakukan yang terakhir hanya dengan menavigasi ke direktori target dan kemudian menjalankan curl -s https://octobercms.com/api/installer | php curl -s https://octobercms.com/api/installer | php (setelah itu kita perlu memasukkan konfigurasi database, jika tidak maka akan berperilaku sebagai CMS flat-file). Setelah instalasi selesai, kami akan memiliki situs web yang berfungsi penuh, tetapi masih cukup kosong (jika Anda menambahkan waktu yang diperlukan untuk menginstal dan mengkonfigurasi plugin yang diperlukan, Anda dapat mengharapkannya memakan waktu setidaknya 15 menit).

Keamanan

WordPress telah dituduh tidak aman karena tingginya jumlah kerentanan yang terus-menerus ditemukan. Ini memaksa pengguna untuk memiliki perangkat lunak untuk CMS dan semua plugin yang diinstal selalu terbaru untuk menghindari eksploitasi keamanan. Di antara masalah utama adalah dukungan WordPress untuk versi PHP yang lebih lama yang tidak lagi didukung oleh komunitas pengembangan PHP (WordPress saat ini mendukung PHP 5.2.4, sedangkan versi PHP terbaru yang didukung penuh adalah 5.6). Namun, masalah ini harus diselesaikan pada April 2019 ketika WordPress secara resmi akan mulai mendukung PHP versi 5.6 dan lebih tinggi.

Jika tidak, WordPress belum tentu tidak aman karena dirinya sendiri, tetapi karena popularitasnya yang tinggi, yang menjadikannya target utama para peretas. Namun, ini memainkan dua arah: WordPress di mana-mana berarti bahwa tim keamanannya harus benar-benar menganggap serius pekerjaan mereka dengan terus-menerus mencari eksploitasi dan memperbaikinya sesegera mungkin, jika tidak hingga sepertiga web berisiko. Taruhannya terlalu tinggi.

CMS Oktober, di sisi lain, tidak memiliki reputasi tidak aman. Namun, karena ada sekitar 27.000 situs langsung yang menggunakan Oktober dibandingkan dengan jutaan WordPress, kami tidak dapat menilai keduanya dengan istilah yang sama. Namun demikian, tim di belakang October CMS benar-benar memperhatikan keamanan, sebagaimana dibuktikan oleh perintah instalasi Wizard untuk memasukkan URL backend CMS, ditetapkan sebagai /backend secara default tetapi dapat diubah menjadi apa pun, sehingga mempersulit peretas untuk menargetkan situs . Sebaliknya, mengubah URL login dan backend WordPress dari /wp-login.php dan /wp-admin masing-masing ke sesuatu yang lain harus dilakukan melalui plugin. Selain itu, CMS Oktober dapat berfungsi sebagai CMS flat-file (yaitu tanpa database) dan menghindari kerentanan terkait database seperti injeksi SQL.

Tumpukan Teknologi

Baik WordPress dan CMS Oktober berjalan di tumpukan LAMP tradisional: Linux, Apache, MySQL, dan PHP. (Namun, hanya PHP yang diperbaiki: kami juga dapat menggunakan Windows, Nginx, MariaDB, dan lainnya.) October CMS juga dapat berfungsi sebagai CMS flat-file, artinya ia dapat melakukannya tanpa database, namun dengan mengorbankan banyak fungsi (seperti posting blog dan pengguna) satu-satunya fungsi yang dijamin adalah halaman, yang dianggap sebagai unit dasar untuk pembuatan dan penerbitan konten dan dikirimkan sebagai fitur inti.

Mengenai tumpukan bahasa, situs yang dibuat dengan WordPress dan CMS Oktober didasarkan pada HTML, CSS, dan JavaScript (perhatikan bahwa PHP digunakan untuk menghasilkan HTML). CMS Oktober juga memudahkan penggunaan file KURANG dan SASS.

Paradigma Pemrograman

WordPress mengikuti paradigma pemrograman fungsional, berdasarkan perhitungan perhitungan dengan memanggil fungsi tanpa status aplikasi. Meskipun pengembang WordPress tidak perlu terpaku pada pemrograman fungsional (misalnya, untuk mengkodekan tema dan plugin mereka), kode inti WordPress mewarisi paradigma ini dari 15 tahun mempertahankan kompatibilitas mundur, yang telah menjadi salah satu pilar kesuksesan WordPress tetapi yang memiliki konsekuensi yang tidak diinginkan dari akumulasi utang teknis.

Di sisi lain, October CMS mengikuti paradigma pemrograman imperatif, berdasarkan perhitungan perhitungan dengan memanipulasi keadaan objek. October CMS berada di atas Laravel, kerangka kerja web yang sepenuhnya didasarkan pada prinsip Pemrograman Berorientasi Objek yang memungkinkan produksi aplikasi modular berdasarkan konsep seperti Model-View-Controller untuk memisahkan antarmuka pengguna dari data aplikasi, Dependency Injection ke mengkonfigurasi dependensi kelas, dan Prinsip Pemisahan Antarmuka untuk mendefinisikan layanan inti yang disediakan oleh kerangka kerja, di antara banyak lainnya.

Kait/Acara

Pemrograman di WordPress dapat dicirikan sebagai HDD yang merupakan singkatan dari "Pengembangan Berbasis Kait". Hook adalah mekanisme yang memungkinkan perubahan perilaku atau nilai default dan memungkinkan kode lain untuk mengeksekusi fungsionalitas terkait. Kait dipicu melalui "tindakan" yang memungkinkan eksekusi fungsionalitas tambahan, dan "filter" yang memungkinkan pengubahan nilai.

Hooks, yang tersebar luas di seluruh basis kode WordPress, adalah salah satu konsep yang paling saya sukai dari pengkodean di WordPress. Mereka memungkinkan plugin untuk berinteraksi dengan plugin lain (atau dengan inti atau tema) dengan cara yang bersih, memberikan beberapa dukungan dasar Pemrograman Berorientasi Aspek.

Kabar baiknya adalah Laravel (dan sebagai konsekuensinya October CMS) juga mendukung konsep hook, yang disebut "events". Peristiwa menyediakan implementasi pengamat sederhana, memungkinkan kode untuk berlangganan dan mendengarkan peristiwa yang terjadi dalam aplikasi dan bereaksi sesuai kebutuhan. Peristiwa memungkinkan untuk membagi fungsionalitas kompleks menjadi komponen, yang dapat diinstal secara independen namun berkolaborasi satu sama lain, sehingga memungkinkan pembuatan aplikasi modular.

Ketergantungan pada Pustaka JavaScript

Versi terbaru WordPress menggabungkan Gutenberg yang didukung oleh React untuk pengalaman pembuatan konten defaultnya. Oleh karena itu, pengembangan WordPress sekarang sebagian besar bergantung pada JavaScript (terutama melalui React), meskipun juga dimungkinkan untuk menggunakan kerangka kerja atau pustaka lain (sebagaimana dibuktikan oleh Elementor Blocks untuk Gutenberg yang didasarkan pada Marionette). Selain itu, WordPress masih bergantung pada Backbone.js (untuk Media Manager) dan jQuery (kode lama), namun, kita dapat berharap ketergantungan pada perpustakaan ini akan hilang karena Gutenberg dikonsolidasikan sebagai norma baru.

CMS Oktober bergantung pada jQuery, yang digunakannya untuk mengimplementasikan kerangka kerja AJAX opsional untuk memuat data dari server tanpa penyegaran halaman browser.

Halaman, Tema, dan Plugin

Baik WordPress dan October CMS memperlakukan halaman sebagai unit dasar untuk membuat dan menerbitkan konten (dalam kasus WordPress, selain posting), mendukung perubahan tampilan dan nuansa situs melalui tema, dan memungkinkan untuk menginstal dan memperluas fungsionalitas situs melalui plugin . Meskipun konsepnya sama di kedua CMS, ada beberapa perbedaan dalam implementasi yang menghasilkan perilaku yang agak berbeda.

Di WordPress, halaman didefinisikan sebagai konten dan disimpan dalam database. Akibatnya, konten halaman hanya dapat dibuat melalui CMS (misalnya di area dasbor), dan beralih dari satu tema ke tema lainnya tidak membuat halaman yang ada menjadi tidak tersedia. Ini menghasilkan pengalaman tanpa gesekan secara keseluruhan.

Di CMS Oktober, di sisi lain, halaman adalah file statis yang disimpan di bawah direktori tema. Sisi positif dari keputusan arsitektur ini, konten halaman dapat dibuat dari aplikasi eksternal, seperti editor teks seperti Sublime atau Visual Studio Code. Di sisi negatifnya, ketika beralih dari satu tema ke tema lainnya, diperlukan untuk membuat ulang atau menyalin halaman secara manual dari tema saat ini ke tema baru, atau jika tidak, halaman tersebut akan hilang.

Secara signifikan, CMS Oktober menyelesaikan perutean melalui halaman, oleh karena itu halaman digunakan tidak hanya sebagai wadah untuk konten tetapi juga untuk fungsionalitas. Misalnya, sebuah plugin untuk blogging bergantung pada halaman untuk menampilkan daftar posting blog di bawah URL yang dipilih, halaman lain untuk menampilkan satu posting blog di bawah URL lain yang dipilih, dan seterusnya. Jika salah satu halaman ini hilang, fungsionalitas terkait dari plugin menjadi tidak tersedia, dan URL tersebut akan menghasilkan 404. Oleh karena itu, pada bulan Oktober tema dan plugin CMS tidak dipisahkan secara menyeluruh, dan peralihan tema harus dilakukan dengan hati-hati.

Fungsionalitas Inti vs Plugin

WordPress mencoba memberikan fungsionalitas inti minimal yang ditingkatkan melalui plugin. WordPress bergantung pada “aturan ⁸⁰ ₂₀ ” untuk memutuskan apakah akan menyertakan beberapa fungsionalitas dalam pengalaman intinya atau tidak. Jika itu menguntungkan 80% pengguna yang masuk, jika tidak, itu milik plugin-land. Saat menambahkan plugin ke situs, mereka dapat menyebabkan kembung jika terlalu banyak plugin yang diinstal. Plugin mungkin juga tidak bekerja dengan baik satu sama lain, atau menjalankan kode serupa atau memuat aset serupa, sehingga menghasilkan kinerja yang kurang optimal. Oleh karena itu, meskipun meluncurkan situs WordPress relatif mudah, tantangan yang lebih besar adalah pemeliharaannya secara umum dan kemampuan untuk mempertahankan keadaan yang optimal dan berkinerja baik saat menambahkan fitur baru.

Demikian juga, October CMS juga mencoba memberikan fungsionalitas inti minimal, tetapi pada steroid: satu-satunya fungsionalitas yang dijamin adalah pembuatan dan publikasi halaman, dan untuk semua hal lainnya kita perlu menginstal satu plugin atau lainnya, yang dinyatakan sebagai:

"Semua yang Anda butuhkan, dan tidak ada yang tidak Anda butuhkan."

Tujuannya jelas: sebagian besar situs sederhana hanya terdiri dari halaman, tanpa posting blog, pengguna, atau area login. Jadi mengapa aplikasi harus memuat sumber daya untuk ini ketika tidak diperlukan? Akibatnya, fungsionalitas untuk blogging, manajemen pengguna, terjemahan, dan beberapa lainnya dilepaskan melalui direktori plugin.

October CMS juga menyertakan fitur-fitur tertentu pada intinya yang (walaupun tidak selalu dibutuhkan) dapat meningkatkan aplikasi secara signifikan. Misalnya, ini menyediakan dukungan siap pakai untuk mengunggah file media ke Amazon S3 dan mengaksesnya melalui Rackspace CDN. Ini juga mencakup Manajer Media yang sebagian besar digunakan melalui plugin, misalnya untuk menambahkan gambar ke dalam posting blog. (Halaman juga dapat menggunakan Pengelola Media untuk menyematkan file media, namun, CMS juga dikirimkan dengan bagian Aset untuk mengunggah file media yang tampaknya lebih sesuai.)

Saya percaya bahwa opini Oktober dapat dengan sempurna memungkinkan kami untuk menghasilkan aplikasi yang ramping mungkin — kebanyakan tentang situs sederhana. Namun bisa juga menjadi bumerang dan mendorong kembung, karena garis mana yang dibutuhkan dan mana yang tidak merupakan garis yang sewenang-wenang, dan sulit diatur terlebih dahulu oleh CMS. Kesulitan ini dapat diapresiasi ketika mempertimbangkan konsep "pengguna": Di WordPress, pengguna situs web dan admin situs web milik entitas pengguna yang sama (dan melalui peran dan hak istimewa kita dapat membuat pengguna menjadi admin). Pada CMS Oktober, keduanya diimplementasikan secara terpisah, mengirimkan implementasi inti untuk administrator situs web yang dapat masuk ke area backend dan mengubah pengaturan, dan melalui plugin implementasi pengguna situs web. Kedua jenis pengguna ini memiliki proses login yang berbeda dan tabel database yang berbeda untuk menyimpan data mereka, sehingga bisa dibilang melanggar prinsip KERING (Jangan Ulangi Diri Sendiri).

Masalah ini muncul tidak hanya mengenai perilaku suatu entitas tetapi juga bidang data apa yang harus dikandungnya. Misalnya, haruskah bidang data pengguna situs web sudah ditentukan sebelumnya? Apakah bidang telepon diperlukan? Bagaimana dengan kolom URL Instagram, mengingat Instagram baru-baru ini menjadi keren? Tapi kemudian, ketika membangun situs web profesional, bukankah seharusnya kita menggunakan bidang URL LinkedIn? Keputusan ini jelas bergantung pada aplikasi dan tidak dapat diputuskan oleh CMS atau plugin.

Plugin CMS Oktober yang disebut Pengguna mengimplementasikan pengguna tetapi tanpa bidang pengguna apa pun, di atasnya plugin User Plus menambahkan beberapa bidang pengguna yang sewenang-wenang, yang mungkin tidak cukup, jadi plugin User Plus+ menambahkan bidang pengguna lainnya. Kapan, di mana, dan bagaimana kita menghentikan proses ini?

Masalah lain adalah ketika tidak ada ruang untuk menambahkan kemampuan baru ke suatu entitas, yang mengarah pada penciptaan entitas lain yang sangat mirip, hanya untuk mendukung kemampuan yang diperlukan tersebut. Misalnya, October CMS dikirimkan dengan halaman, dan memungkinkan untuk membuat "halaman statis" melalui plugin. Sifatnya sama: halaman dan halaman statis disimpan sebagai file statis. Satu-satunya perbedaan di antara mereka (sejauh yang saya tahu) adalah bahwa halaman statis diedit dengan editor visual alih-alih editor HTML, dan dapat ditambahkan ke menu. Menurut pendapat saya, hanya perbedaan struktural, seperti memiliki satu entitas yang disimpan sebagai file statis dan yang lainnya disimpan dalam database, yang dapat membenarkan pembuatan entitas kedua untuk sebuah halaman (ada permintaan tarik untuk melakukan ini), tetapi untuk sederhana fitur, seperti yang terjadi saat ini, itu merupakan pengembangan mengasapi.

Singkatnya, aplikasi CMS Oktober yang diimplementasikan dengan baik bisa sangat ramping dan efisien (misalnya dengan menghapus database saat tidak diperlukan), tetapi sebaliknya itu juga bisa menjadi membengkak yang tidak perlu, memaksa pengembang untuk mengimplementasikan beberapa solusi untuk entitas serupa, dan yang dapat sangat membingungkan untuk digunakan (“Haruskah saya menggunakan halaman atau halaman statis?”). Karena baik WordPress maupun October CMS tidak menemukan solusi sempurna untuk menghilangkan bloat, kita harus mendesain arsitektur aplikasi dengan hati-hati untuk menghindari kesulitan di jalan.

Pembuatan Konten

Gutenberg membuat dua kontribusi penting untuk WordPress: Menggunakan komponen sebagai unit untuk membangun situs (yang menawarkan beberapa keuntungan dibandingkan coding gumpalan HTML), dan memperkenalkan entitas yang disebut "blok" yang, setelah Gutenberg Fase 2 selesai (mungkin di 2019), akan memberikan cara terpadu untuk memasukkan konten ke dalam situs, sehingga memungkinkan pengalaman pengguna yang lebih sederhana dibandingkan dengan proses penambahan konten yang lebih kacau melalui kode pendek, tombol TinyMCE, menu, widget, dan lainnya.

Karena blok Gutenberg dapat menghasilkan dan menyimpan HTML statis sebagai bagian dari posting blog, maka menginstal banyak blok Gutenberg tidak serta merta berarti mengasapi situs web di sisi pengguna, tetapi dapat disimpan terbatas pada sisi admin. Oleh karena itu, Gutenberg dapat dianggap sebagai pendekatan yang baik untuk menghasilkan situs web secara modular, dengan pengalaman pengguna yang sederhana namun kuat untuk membuat konten. Mungkin kelemahan terbesar adalah (tidak dapat dihindari, tetapi tidak mudah begitu) persyaratan untuk belajar React, yang kurva belajarnya agak curam.

Jika komponen React adalah unit dasar untuk membuat konten di WordPress, CMS Oktober didasarkan pada premis bahwa mengetahui HTML lama yang baik sudah cukup untuk membangun situs. Memang, saat membuat halaman, kami hanya disajikan editor HTML (Markup):

Jika halaman hanya HTML statis, maka CMS tidak diperlukan. Sebaliknya, halaman CMS Oktober ditulis menggunakan templat Twig yang dikompilasi ke kode PHP yang dioptimalkan. Mereka dapat memilih tata letak untuk menyertakan perancah halaman (yaitu elemen berulang, seperti header, footer, dan sebagainya), dapat menerapkan placeholder, yang ditentukan pada tata letak untuk memungkinkan halaman menyesuaikan konten, dan dapat menyertakan parsial, yang merupakan potongan kode yang dapat digunakan kembali. Selain itu, halaman dapat menyertakan blok konten, yang berupa file teks, HTML, atau penurunan harga yang dapat diedit sendiri dan dapat melampirkan komponen yang merupakan fungsionalitas yang diimplementasikan melalui plugin. Dan akhirnya, ketika HTML tidak cukup dan kita perlu menghasilkan kode dinamis, kita dapat menambahkan fungsi PHP.

Editor adalah semua tentang HTML. Tidak ada textarea TinyMCE untuk menambahkan konten secara visual — setidaknya tidak melalui pengalaman default (fungsi ini milik plugin-land). Oleh karena itu, memiliki pengetahuan tentang HTML dapat dianggap sebagai suatu keharusan untuk menggunakan CMS Oktober. Selain itu, beberapa input berbeda untuk membuat konten (halaman, tata letak, placeholder, parsial, blok konten, komponen, dan fungsi PHP) mungkin sangat efektif, namun tentu tidak sesederhana melalui antarmuka blok terpadu dari WordPress. Itu bahkan bisa menjadi lebih kompleks karena elemen lain juga dapat ditambahkan (seperti halaman dan menu statis, dan cuplikan), dan beberapa di antaranya, seperti halaman dan halaman statis, tampaknya menyediakan fungsi yang sama, sehingga membingungkan untuk memutuskan kapan harus menggunakan satu atau yang lain.

Akibatnya, saya berani mengatakan bahwa sementara hampir semua orang dapat menggunakan situs WordPress dari sisi admin, CMS Oktober lebih ramah pengembang daripada ramah pengguna non-teknis, jadi programmer mungkin merasa senang menggunakannya, tetapi pasti lainnya peran (pemasar, tenaga penjualan, dan sejenisnya) mungkin menganggapnya tidak intuitif.

Manajer Media

Baik WordPress dan October CMS dikirimkan dengan Media Manager yang memungkinkan penambahan file media ke situs dengan mudah, mendukung penambahan beberapa file secara bersamaan melalui antarmuka drag-and-drop dan menampilkan gambar di dalam area konten. Mereka terlihat dan berperilaku serupa; satu-satunya perbedaan penting yang saya temukan adalah bahwa Manajer Media WordPress memungkinkan untuk menyematkan galeri gambar, dan Manajer Media Oktober memungkinkan untuk secara manual membuat struktur folder tempat menempatkan file yang diunggah.

Namun, sejak diperkenalkannya Gutenberg, kemampuan media WordPress telah sangat ditingkatkan, memungkinkan untuk menyematkan video, gambar, dan galeri foto di tempat dibandingkan dengan dalam textarea TinyMCE (yang hanya menyediakan versi yang tidak akurat tentang tampilannya. di situs), dan membuka kunci fitur yang kuat, namun mudah digunakan seperti yang ditunjukkan dalam video ini.

Penginternasionalan

Inti WordPress menggunakan gettext untuk mengaktifkan terjemahan tema dan plugin. Mulai dari file .pot yang berisi semua string untuk diterjemahkan, kita perlu membuat file .po yang berisi terjemahannya ke bahasa/lokal yang sesuai, dan file ini kemudian dikompilasi ke file biner .mo yang cocok untuk ekstraksi terjemahan cepat. Alat untuk melakukan tugas ini termasuk GlotPress (online) dan Poedit (aplikasi yang dapat diunduh). Mudahnya, mekanisme ini juga berfungsi untuk pelokalan sisi klien untuk Gutenberg.

WordPress saat ini tidak mengirimkan solusi apa pun dalam inti untuk menerjemahkan konten, dan tidak akan melakukannya hingga Fase 4 Gutenberg (ditargetkan untuk tahun 2020+). Sampai saat itu, fungsi ini disediakan oleh plugin yang menawarkan strategi berbeda untuk menyimpan dan mengelola konten yang diterjemahkan. Misalnya, sementara plugin seperti Polylang dan WPML menyimpan setiap terjemahan pada barisnya sendiri dari tabel database khusus (yang bersih karena tidak mencampur konten bersama-sama, tetapi lebih lambat karena memerlukan INNER JOIN tambahan dari dua tabel saat menanyakan database), plugin qTranslate X menyimpan semua terjemahan pada bidang yang sama dari tabel database asli (lebih cepat untuk mengkueri data, tetapi konten yang dicampur bersama-sama dapat menghasilkan puing-puing di situs jika menonaktifkan plugin). Oleh karena itu, kita dapat melihat-lihat dan memutuskan strategi yang paling sesuai dengan kebutuhan kita.

October CMS tidak mengirimkan fungsionalitas multibahasa melalui intinya, tetapi sebagai plugin yang dibuat oleh tim October CMS yang menjamin integrasi sempurna ke dalam sistem. Dari sudut pandang fungsional, plugin ini memberikan apa yang dijanjikannya. Dari sudut pandang pengembangan, cara kerja plugin ini tidak terlalu ideal. Di WordPress, halaman hanyalah sebuah posting dengan "halaman" jenis posting dan ada mekanisme terjemahan tunggal untuk mereka, tetapi di CMS Oktober, ada entitas "halaman", "halaman statis" dan "posting blog" dan, meskipun sangat mirip, mereka membutuhkan tiga implementasi berbeda untuk terjemahannya! Kemudian, konten dari “halaman” dapat menyertakan kode pesan (misalnya kode yang disebut nav.content , header.title , dan sebagainya), yang masing-masing berisi terjemahannya untuk semua lokal sebagai objek JSON bersambung di tabel database rainlab_translate_messages . Konten dari "halaman statis" dibuat menjadi file statis baru per lokal, namun, semua URL yang diterjemahkan untuk semua lokal tidak disimpan dalam file yang sesuai, melainkan pada file bahasa default. Konten untuk "postingan blog" disimpan sebagai objek JSON serial dengan satu baris per lokal di tabel database rainlab_translate_attributes dan URL yang diterjemahkan disimpan dengan satu baris per lokal di tabel database rainlab_translate_indexes . Saya tidak tahu apakah kerumitan ini disebabkan oleh bagaimana plugin diimplementasikan atau karena arsitektur CMS Oktober. Apapun masalahnya, ini adalah contoh lain dari kembung yang tidak diinginkan di sisi pengembangan.

Manajemen Plugin

Baik WordPress dan October CMS menawarkan pengelola plugin canggih yang memungkinkan untuk mencari plugin, menginstal plugin baru, dan memperbarui plugin yang saat ini diinstal ke versi terbaru — semuanya dari dalam backend.

Manajemen Ketergantungan

Oktober CMS menggunakan Composer sebagai manajer paket pilihan, memungkinkan plugin untuk mengunduh dan menginstal dependensinya saat diinstal, sehingga memberikan pengalaman yang tidak menyakitkan.

WordPress, di sisi yang berlawanan, belum secara resmi mengadopsi Composer (atau pengelola ketergantungan PHP apa pun) karena komunitas tidak dapat menyetujui apakah WordPress adalah situs atau ketergantungan situs. Oleh karena itu, jika mereka membutuhkan Komposer untuk proyek mereka, pengembang harus menambahkannya sendiri. Dengan beralih ke Gutenberg, npm telah menjadi pengelola ketergantungan JavaScript yang disukai, dengan toolkit pengembang populer bergantung padanya, dan pustaka sisi klien dirilis secara stabil sebagai paket otonom di registri npm.

Interaksi Dengan Basis Data

WordPress menyediakan fungsi untuk mengambil data database (seperti get_posts ) dan menyimpannya (seperti wp_insert_post dan wp_update_post ). Saat mengambil data, kita dapat melewatkan parameter untuk memfilter, membatasi, dan mengurutkan hasil, untuk menunjukkan apakah hasil harus diteruskan sebagai turunan dari kelas atau sebagai larik properti dan lainnya. Ketika fungsi tidak sepenuhnya memenuhi persyaratan kami (misalnya ketika kami perlu melakukan INNER JOIN dengan tabel khusus) maka kami dapat menanyakan database secara langsung melalui variabel global $wpdb . Saat membuat plugin dengan jenis posting khusus, kode kemungkinan besar akan mengeksekusi kueri SQL khusus untuk mengambil dan/atau menyimpan data ke dalam tabel khusus. Singkatnya, WordPress mencoba menyediakan akses ke database melalui fungsi generik di tahap pertama, dan melalui akses tingkat rendah ke database di tahap kedua.

Oktober CMS menggunakan pendekatan yang berbeda: Alih-alih langsung terhubung ke database, aplikasi dapat menggunakan Eloquent ORM Laravel untuk mengakses dan memanipulasi data database melalui instance kelas yang disebut Model, membuat interaksi dengan database juga didasarkan pada Pemrograman Berorientasi Objek . Ini adalah akses tingkat tinggi; hanya dengan mengikuti aturan tentang cara membuat tabel dan mengatur hubungan antar entitas, plugin dapat mengambil dan/atau menyimpan data tanpa menulis baris SQL. Misalnya, kode di bawah ini mengambil objek dari database melalui model Flight , memodifikasi properti, dan menyimpannya kembali:

 $flight = Flight::find(1); $flight->name = 'Darwin to Adelaide'; $flight->save();

Meningkatkan Model Data

Alasan lain untuk kesuksesan WordPress (selain tidak merusak kompatibilitas ke belakang) adalah arsitektur basis datanya, yang dirancang untuk memungkinkan aplikasi tumbuh seiring waktu. Tujuan ini dicapai melalui properti "meta", yaitu properti yang dapat ditambahkan secara bebas ke objek database setiap saat. Properti ini tidak disimpan dalam kolom dari tabel entitas yang sesuai (baik wp_posts , wp_users , wp_comments atau wp_terms ), melainkan sebagai baris dalam tabel "meta" yang sesuai ( wp_postmeta , wp_usermeta , wp_commentmeta atau wp_termmeta ) dan diambil dengan INNER JOIN . Oleh karena itu, meskipun mengambil nilai meta ini lebih lambat, mereka memberikan fleksibilitas tak terbatas, dan model data aplikasi jarang perlu diarsitektur ulang dari awal untuk mengimplementasikan beberapa fungsi baru.

Oktober CMS tidak menggunakan properti meta tetapi sebaliknya dapat menyimpan beberapa nilai arbitrer, yang tidak langsung dipetakan sebagai kolom dalam tabel database, sebagai objek JSON serial. Otherwise, when an object needs some new property, we need to add a new column on the corresponding table (which is the reason behind plugins User Plus and User Plus+, mentioned earlier on). To update the application's database schema, October CMS relies on Laravel's Migrations, which are sets of instructions to execute against the schema (such as add or drop a column, rename an index, etc) and which are executed when upgrading the software (eg when installing a plugin's new version).

Headless Capabilities

Both WordPress and October CMS can be used as headless, ie treating the CMS as a content management system that makes content accessible through APIs, which allows to render the website on the client-side and can power other applications (such as mobile apps). Indeed, WordPress is steadily heading towards headless, since the Gutenberg content editor itself treats WordPress as a headless CMS (and, as a consequence, Gutenberg can also work with any other CMS too, as Drupal Gutenberg demonstrates).

A headless system needs to implement some API to return the data, such as REST and GraphQL. WordPress supports REST through WP REST API (merged in core), exposing endpoints under some predefined route /wp-json/wp/v2/... ; October CMS supports REST through plugins RESTful and API Generator, which allow to create custom endpoints and, as a consequence, support versioning as part of the endpoint URL and can offer a better security against bots. Concerning GraphQL, WordPress supports it through WPGraphQL, while October CMS currently has no implementations for it.

Quite importantly, a headless system needs to offer powerful content management capabilities. As mentioned earlier on, WordPress has a very solid database architecture, offering a plethora of data entities (users, posts and custom posts, pages, categories, tags and custom taxonomies, comments) over which the application can be reasonably well modelled, meta properties to extend these data entities (enabling the application to upgrade its data model accordingly and without major changes), and with plugin Advanced Custom Fields filling the gap to construct relationships among the data entities. In addition, plugin VersionPress allows to version control the database content using Git. Hence, WordPress is undoubtedly a good fit for managing content, as demonstrated in several projects in the wild.

On its part, and as mentioned earlier on, October CMS can omit the database and behave as a flat-file system, or it can have a database and behave as a hybrid, storing the content from pages as static files and blog posts (and others) on the database. As a consequence, content is not centralized, and its management involves a different approach. For instance, while we can use Git to version control pages, there is no support to version control the database per se; the solution to this is to populate data into the database through Seeders which, being code, can be put under version control and executed upon deployment. In addition, October CMS doesn't offer a baked-in database model featuring predefined data entities that can support the needs of most applications. Hence, more likely than not the application will need custom development to implement its data model, which means more work, but also means that it can be more efficient (eg accessing a property from a column is faster than from a row in another table through an INNER JOIN , which is the case with WordPress' meta properties).

CLI Support

Both WordPress and October CMS can be interacted with from the console through a Command Line Interface (CLI): WordPress through WP-CLI and October CMS through Laravel's Artisan. In addition to Laravel's commands, October CMS implements several custom commands for updating the system, migrating the database, and others. These tools make it very convenient to access the site from outside a browser, for instance for testing purposes.

Managed Hosting

It is not a problem finding a managed hosting provider for a WordPress site: given WordPress' market share, there are dozens (if not hundreds) of providers out there vying with each other for the business, constituting a very dynamic market. The only problem is finding the most suitable provider for our specific sites based on all of their offerings, which can vary based on price, quality, type (shared or dedicated services), bandwidth and storage size, customer support, location, frequency of renewal of equipment, and other variables which we can navigate mainly through reviews comparing them (such as this one, this one or this one).

Even though nothing near as many as WordPress, October CMS still enjoys the offering from several hosting providers, which allows for some consideration and selection. Many of them are listed as October Partners, and several others are found DuckDuckGoing, but since I haven't found any independent review of them or article comparing them, the task of finding out the most suitable one will take some effort.

Marketplace, Ecosystem And Cost

WordPress' commercial ecosystem is estimated to be USD $10 billion/year, evidencing how many people and companies have managed to make a living by offering WordPress products and services, such as the creation of sites, hosting, theme and plugin development, support, security, and others. Indeed, its size is so big it is even bloated, meaning that it is very common to find different plugins solving the same problem, plugins that underdeliver, underperform or have not been updated for years, and themes which seem to look-alike each other. However, when creating a new site, the size and variety of the ecosystem also means that we will most likely find at least one plugin implementing each of the required functionalities, enabling us to save money by not having to develop the functionality ourselves, and the availability of customizable themes enables to produce a reasonably distinctive-looking site with minimal effort. As a consequence, we can easily create and launch a WordPress site for less than USD $100, making WordPress a sensible option for projects of any budget.

Being relatively new (only five years so far), OctoberCMS certainly doesn't enjoy anything near WordPress' marketplace and ecosystem sizes, however, it has been growing steadily so its size is bound to become bigger. Currently, its marketplace boasts 600+ plugins, and only a handful of themes. Concerning plugins, the October CMS team is requesting the community to put their effort into the creation of original plugins, delivering functionality not yet provided by any other plugin.

Hence, even though 600+ plugins doesn't sound like much, at least these translate into 600+ different functionalities. This way, even though it is not possible to choose among several vendors, at least we can expect to have those basic website features (such as blogging, comments, forum, integration with social media, e-commerce, and others) to be covered. Also, since October's founders are personally reviewing all submitted plugins and judging them according to quality guidelines, we can expect these plugins to perform as expected. As another plus, October plugins can incorporate elements from Laravel packages (even though not all of them are compatible with October, at least not without some hacks). Concerning themes, the low number of offerings implies we will most likely need to develop our own theme by hiring a developer for the task. In fact, I dare say that the theme in October CMS will most likely be a custom development, since themes and plugins are not thoroughly decoupled (as explained earlier), with the consequence that a market for easily-swappable themes is more difficult to arise. (This is a temporary problem though: once this pull request is resolved, pages will be able to be stored in the database, and swapping themes should not disrupt functionality.)

In my opinion, because of the smaller offerings of themes and plugins, creating a simple site with OctoberCMS will be more expensive than creating a simple WordPress site. For complex sites, however, October's better architecture (Object-Oriented Programming and Model-View-Controller paradigms) makes the software more maintainable and, as a consequence, potentially cheaper.

Masyarakat

Being a part of and having access, WordPress' community represents one of the most compelling reasons for using WordPress. This is not simply as a matter of size (powering nearly one third of all websites in the world, there are so many stakeholders involved with WordPress, and its community is representatively big) but also as a matter of diversity. The WordPress community involves people from many different professions (developers, marketers, designers, bloggers, sales people, and so on), from all continents and countries, speaking countless languages, from different social, educational and economic backgrounds, with or without disabilities, from corporate, not-for-profit and governmental organizations, and others. Hence, it is quite likely that, for whatever problem we encounter, somebody will be able to help on any of the support forums. And contributing to WordPress is pretty straightforward too: The Make WordPress group congregates stakeholders interested in supporting different projects (accessibility, design, internationalization, and many others) and organizes how and how regularly they communicate — mostly through some dedicated channel on its Slack workspace.

Furthermore, the WordPress community is real and tangible: it doesn't exist just online, but it gathers offline in WordCamps and meetups all over the world; in 2018, there were a total of 145 WordCamps in 48 countries with over 45,000 tickets sold, and a total of 5,400 meetup events from 687 meetup groups. Hence, it is likely that there is a local chapter nearby which anyone can join to ask for help, learn how to use the platform, keep learning on a regular basis, and teach others as well. In this sense, WordPress is not just a CMS but, more importantly, it's also people, and considering to leave WordPress should never be done only on its technical merits but on the power of its community, too.

October CMS' community is nothing near in size or diversity as WordPress', even though it has been growing steadily following the increasing popularity of the software. October provides a support forum to ask for help, however, it is not very active. A Slack workspace exists which is pretty active and where, quite importantly, October's founders participate regularly, helping make sure that all enquiries are properly addressed. This channel is a great source for learning low-level tips and tricks about the software, however, it is geared towards developers mainly: There are no channels concerning accessibility, design, internationalization, and other topics as in the WordPress community, at least not yet. Currently, there are no conferences concerning October CMS, but there is Laracon, the conference for the Laravel community.

Maintainers And Governance

Can we trust that the software will be maintained in the long term, so that if we decide to start a project today, we will not need to migrate to some other platform down the road? How many people are taking care of developing the software? And who is deciding in what direction the software moves towards?

Mendukung sepertiga dari semua situs di dunia, WordPress tidak kekurangan pemangku kepentingan yang berkontribusi pada perangkat lunak; maka kita tidak perlu takut bahwa perangkat lunak akan jatuh ke dalam pembusukan. Namun, WordPress sedang melalui pertimbangan internal mengenai model tata kelolanya, dengan banyak anggota komunitas menyatakan bahwa keputusan mengenai arah WordPress diambil secara sepihak oleh Automattic, perusahaan yang menjalankan WordPress.com. Tahap pusat dari persepsi ini adalah keputusan untuk meluncurkan Gutenberg, yang tidak disetujui oleh banyak anggota, dan yang mengalami kurangnya komunikasi yang tepat oleh pimpinan proyek selama pengembangan dan peluncurannya. Akibatnya, banyak anggota komunitas mempertanyakan peran "diktator jinak", yang secara historis diberikan kepada pendiri WordPress dan CEO Automattic Matt Mullenweg, dan meneliti model tata kelola yang berbeda untuk menemukan model yang lebih cocok untuk masa depan WordPress. Masih belum terlihat apakah pencarian ini membuahkan hasil, atau apakah status quo bertahan.

Keputusan mengenai arah CMS Oktober sebagian besar diambil oleh pendiri Alexey Bobkov dan Samuel Georges serta manajer pengembang dan komunitas Luke Towers, yang membuat proyek tetap kuat. Oktober CMS belum memiliki kemewahan untuk memiliki masalah tata kelola: Perhatiannya saat ini adalah bagaimana membuat proyek berkelanjutan dengan menghasilkan pendapatan bagi pengelola perangkat lunak inti.

Dokumentasi

Dokumentasi WordPress di situsnya sendiri tidak terlalu komprehensif, tetapi melakukan pekerjaan dengan cukup baik. Namun, ketika mempertimbangkan semua dokumentasi tentang WordPress dari semua sumber, seperti situs umum (Smashing Magazine, trik CSS, dan banyak lainnya), situs khusus (WPShout, WPBeginner, dan banyak lainnya), blog pribadi, kursus online, dan seterusnya, praktis tidak ada aspek berurusan dengan WordPress yang belum dibahas.

October CMS tidak menikmati apa pun di dekat banyak kursus, tutorial, atau posting blog pihak ketiga tentang hal itu seperti halnya WordPress, namun, dokumentasi di situsnya cukup komprehensif dan tentu saja cukup untuk memulai pengkodean. Pendiri Oktober juga secara teratur menambahkan dokumentasi baru melalui tutorial. Salah satu aspek yang secara pribadi saya nikmati adalah duplikasi dokumentasi Laravel ke dalam dokumentasi October untuk segala hal yang relevan, jadi pembaca tidak harus mengisi celahnya sendiri dan harus menebak apa domain Oktober dan apa Laravel. Namun, ini tidak 100% sempurna. Dokumentasi Oktober menggunakan istilah yang berasal dari Laravel, seperti middleware, wadah layanan, fasad, dan kontrak, tanpa menjelaskan secara memadai apa itu. Kemudian, membaca dokumentasi Laravel sebelumnya dapat membantu (untungnya, dokumentasi Laravel sangat komprehensif, dan screencast Laravel, Laracasts, adalah sumber pembelajaran yang bagus, tidak hanya tentang Laravel tetapi pengembangan web secara umum).

Kesimpulan

Saya mulai menemukan fitur apa yang mungkin menarik bagi pengembang yang mencari alternatif untuk WordPress dengan membandingkan WordPress dengan CMS serupa, yang saya definisikan sebagai gratis dan open source, berbasis PHP dan menghasilkan konten dinamis, dan menikmati dukungan dari beberapa komunitas . Dari CMS yang memenuhi persyaratan ini, saya memilih CMS Oktober untuk perbandingan karena pengetahuan yang saya dapatkan tentangnya, dan karena saya menghargai pendekatan pengkodean yang bersih dan modular seperti yang disediakan oleh Laravel, yang dapat menawarkan perspektif baru dan modern untuk membangun situs.

Artikel ini tidak bermaksud untuk memilih pemenang, tetapi hanya menganalisis kapan masuk akal untuk memilih satu atau CMS lainnya, menyoroti kekuatan dan kelemahan mereka. Tidak ada CMS “terbaik”: hanya CMS yang paling cocok untuk situasi tertentu. Selanjutnya, siapa pun yang mencari CMS untuk digunakan pada proyek tertentu dengan tim tertentu dan diberi anggaran tertentu, harus melakukan riset dan membandingkan semua penawaran di luar sana untuk mengetahui mana yang paling cocok untuk konteks tertentu. Penting untuk tidak membatasi beberapa CMS seperti yang telah saya lakukan di artikel ini, tetapi berikan kesempatan kepada semuanya.

Sebagai catatan pribadi, sebagai pengembang, apa yang saya temukan di Oktober CMS sangat menarik bagi saya, sebagian besar kemampuannya untuk membangun aplikasi modular seperti yang disediakan melalui Laravel. Saya pasti akan mempertimbangkan CMS ini untuk situs web baru. Namun, dalam proses penulisan artikel ini saya juga “menemukan kembali” WordPress. Menjadi begitu populer, WordPress menerima lebih dari cukup kritik, sebagian besar mengenai basis kode lama dan, sejak baru-baru ini, pengenalan Gutenberg; namun, WordPress juga memiliki fitur unggulan tertentu (seperti model database super-scalable) yang jarang dipuji tetapi harus diperhitungkan juga. Dan yang paling penting, WordPress tidak boleh mempertimbangkan aspek teknisnya saja: khususnya, ukuran komunitas dan ekosistemnya menempatkannya satu atau dua tingkat di atas alternatifnya. Singkatnya, beberapa proyek mungkin mendapat manfaat dari tetap berpegang pada WordPress, sementara yang lain mungkin lebih baik mengandalkan CMS Oktober atau platform lain.

Sebagai catatan terakhir, saya ingin mengatakan bahwa menjelajahi cara kerja CMS lain adalah aktivitas yang sangat bermanfaat, terlepas dari keputusan yang diambil mengenai apakah akan menggunakan CMS tertentu atau tidak. Dalam kasus saya, saya telah bekerja selama bertahun-tahun di WordPress saja, dan mempelajari CMS Oktober sangat menyegarkan karena mengajari saya banyak hal (seperti keberadaan Rekomendasi Standar PHP) yang belum saya ketahui melalui WordPress. Saya sekarang dapat memutuskan untuk mengganti CMS, atau tetap menggunakan WordPress dengan mengetahui cara menghasilkan kode yang lebih baik.

Bacaan Lebih Lanjut tentang SmashingMag:

• Caching dengan Cerdas di Era Gutenberg
• Meningkatkan Kode WordPress Dengan PHP Modern
• Pelajaran yang Dipetik Saat Mengembangkan Plugin WordPress
• Cara Menggunakan Heatmaps Untuk Melacak Klik Di Situs WordPress Anda
• Waspada: Fungsi PHP dan WordPress yang Dapat Membuat Situs Anda Tidak Aman