Mengapa Developer Membenci CMS Wordpress ?

Hallo gayn, kali ini saya akan membahas wordpress. Pada postingan ini, merupakan pendapat saya dan Nanobox , menganai CMS Wordpress, jika kalian tidak setuju dengan pendapat saya tidak apa - apa. Artikel ini saya buat dengan 2 bahasa. Yaitu bahasa Indonesia dan Inggris. 

Supaya tidak ada pihak yang dirugikan saya akan menjelaskan gagasan terlebih dahulu, disini saya juga pengguna Cms. Cms yang saya gunakan Wordpress tetapi, saya tidak terlalu mendalam tentang Wordpress, di satu sisi saya tidak menjelek - jelekan wordpress. Tapi saya hanya berbagi keluhan tentang worpdress, terutama di plugins, kenapa ? karena ketika saya menggunakan plugins. Load website menjadi berat dan memakan memori atau disk space, sehingga saya berniat mendalami Hand coding dan Framework. Di satu sisi saya juga ingin memperdalam ilmu pemograman dan juga development, jadi saya tidak terlalu memaku pada sebuah plugins. Sehingga saya dapat membuat sesuai keinginan saya sendiri dan juga menghemat disk space. Dan saya hanya ingin menjelaskan bahwa WordPress bukanlah platform yang buruk. Wordpress  memberikan solusi yang mudah diatur dan mudah digunakan untuk menerbitkan konten. Ibarat seperti Mie instant dalam makanan. Jika di implementasikan di dunia IT atau Developing seperti membuat web yang instan. Dan untuk macam - macam plugins yang tersedia di Worpress sudah bagus. Akan tetapi kita sebagai pihak Develper tidak leluasa untuk menata tampilan atau design dari blog di website kita. Maka dari itu silahkan Anda memilih sendiri menggunakan CMS atau Framework dan Hand coding, ini adalah kesimpulan dari saya jika saya mempunyai kesalahan mohon di maafkan, sekian dan terima kasih.

Sebelum masuk  inti yuk kenalan dengan Wordpress dan CMS. 

Dikutip dari wikipedia 

WordPress adalah sebuah aplikasi sumber terbuka (open source) yang sangat populer digunakan sebagai mesin blog (blog engine). WordPress dibangun dengan bahasa pemrograman PHP dan basis data (database) MySQL. PHP dan MySQL, keduanya merupakan perangkat lunak sumber terbuka (open source software). Selain sebagai blog, WordPress juga mulai digunakan sebagai sebuah CMS (Content Management System) karena kemampuannya untuk dimodifikasi dan disesuaikan dengan kebutuhan penggunanya. WordPress adalah penerus resmi dari b2/cafelog yang dikembangkan oleh Michel Valdrighi. Nama WordPress diusulkan oleh Christine Selleck, teman Matt Mullenweg. WordPress saat ini menjadi platform content management system (CMS) bagi beberapa situs web ternama seperti CNN, Reuters, The New York Times, TechCrunch, dan lainnya.

Setelah berkenalan dengan Wordpress, selanjutnya kenalan dengan CMS.

CMS (Content Manajemen System) adalah sebuah perangkat lunak atau sistem yang mengatur konten pada situs web, bisa situs web yang berupa company profile, e-commerce, blog, forum, dan lainnya.

Jika ada mie instan pada makanan, CMS menjadi pembuatan situs instan yang disediakan di internet. CMS dapat anda gunakan meskipun anda tidak mengetahui mengenai pemrograman sama sekali.  CMS juga menyediakan template layaknya WordPress.

Sampai pada bagian ini semoga sudah sedikit menjawab pertanyaan “apa itu cms?”. Setelah mengetahui pengertian CMS, selanjutnya akan saya coba jelaskan sedikit sebagian keuntungan yang bisa Anda dapatkan saat menggunakan CMS.

Dikutip dari :niaga hoster

Seperti yang dijelaskan di awal, bahwa Content Manajemen Sistem adalah perangkat lunak yang digunakan untuk menambahkan atau memanipulasi (mengubah) isi dari suatu situs web. Umumnya, sebuah CMS (Content Management System) terdiri dari dua elemen:

Elemen CMA memperbolehkan si manajer isi -yang mungkin tidak memiliki pengetahuan mengenai HTML (HyperText Markup Language)-, untuk mengatur pembuatan, modifikasi, dan penghapusan isi dari suatu situs Web tanpa perlu memiliki keahlian sebagai seorang Webmaster. Elemen CDA menggunakan dan menghimpun informasi-informasi yang sebelumnya telah ditambah, dikurangi atau diubah oleh si empunya situs web untuk meng-update atau memperbaharui situs Web tersebut. Kemampuan atau fitur dari sebuah sistem CMS berbeda-beda, walaupun begitu, kebanyakan dari software ini memiliki fitur publikasi berbasis Web, manajemen format, kontrol revisi, pembuatan index, pencarian, dan pengarsipan. Wikipedia Indonesia.

Karena CMS memisahkan antara isi dan desain, konsistensi tampilan dapat senantiasa dijaga dengan baik.Setiap bagian dari website dapat memiliki isi dan tampilan yang berbeda-beda, tanpa harus khawatir kehilangan identitas dari website secara keseluruhan. Oleh karena semua data disimpan dalam satu tempat,pemanfaatan kembali dari informasi yang ada untuk berbagai keperluan dapat dengan mudah dilakukan. CMS juga memberikan kefleksibelen dalam mengatur alur kerja atau ‘workflow’ dan hak akses, sehingga memperbesar kesempatan berpartisipasi dari pengguna dalam pengembangan website. Hal ini akan sangat menguntungkan bila website yang dikelola memiliki kompleksitas yang tinggi dan mengalami kemajuan yang cukup pesat.

Manfaat CMS : 

Pemanfaatan CMS : 

CMS pada prinsipnya dapat dipergunakan untuk berbagai macam keperluan dan dalam berbagai kondisi, seperti untuk:

Dan juga Content Manajement System didefenisikan sebagai Sebuah System yang memberikan kemudahan kepada penggunanya dalam mengelola dan mengadakan perubahan isi sebuah website dinamis tanpa tanpa sebelumnya dibekali pengetahuan tentang hal – hal yang bersifat teknis dalam sebuah mendesign sebuah website. Contoh CMS diantaranya WordPress,Joomla, Mambo, Drupal dll.

CMS (Content Management System) dapat membantu kita untuk membangun suatu website dengan harga yang relatif murah dan open source lagi. Menggunakan CMS memang mudah dalam jangka pendek

Pada saat ini banyak sekali pemanfaatan dari penggunaan cms, diantaranya adalah untuk membuat website perusahaan, bisnis, organisasi atau komunitas. Lalu juga dimanfaatkan untuk Portal, Galeri foto, Aplikasi E-Commerce, dan Mengelola website pribadi / blog serta masih banyak lagi yang bisa kita fungsikan pada penggunaan cms ini.

Framework adalah sekumpulan library yang diorganisasikan pada sebuah rancangan arsitektur untuk memberikan kecepatan, ketepatan, kemudahan dan konsistensi di dalam pengembangan aplikasi dari definisi tersebut, framework mengandung unsur-unsur berikut :

Framework menyediakan librari yang lengkap dan terintegrasi. Unsur inilah yang paling banyak memberikan keuntungan bagi pengembang aplikasi. Sebagai contoh, framework aplikasi web menyediakan librari-librari dasar berkaitan layanan web, seperti authentication, database access, html generation, template engine, session management, caching, searching, email, http, pdf, zip dan ajax. Framework juga menyediakan sarana extension untuk librari-librari yang belum tersedia atau librari yang perlu ditingkatkan kemampuannya.

Arsitektur. Sebuah aplikasi membutuhkan rancangan bagaimana sistem dibangun, yaitu bagaimana elemen-elemen di dalam aplikasi disusun dan diintegrasikan, seperti pengorganisasian file dan librari, dan bagaimana librari-librari digunakan. Framework menyediakan struktur aplikasi dan bagaimana interaksi di dalam struktur tersebut. MVC [Model View Controller] adalah salah satu pola rancangan [design pattern] yang banyak digunakan dalam arsitektur aplikasi saat ini. Jika digambarkan akan seperti berikut :

Input > Processing > Output = Controller > Model > View

Controller mencakup semua proses yang terkait dengan pemanggilan database dan kapsulisasi proses-proses utama. Jadi semisal di bagian ini ada file bernama member.php, maka semua proses yang terkait dengan member akan dikapsulisasi/dikelompokan dalam file ini.

Model mencakup semua proses yang terkait dengan pemanggilan struktur data baik berupa pemanggilan fungsi, input processing atau mencetak output ke dalam browser.

View mencakup semua proses yang terkait layout output. Bisa dibilang untuk menaruh template interface website atau aplikasi.

PHP Framework menggunakan metode pengembangan berbasis MVC. Namun apa itu MVC ? MVC merupakan suatu metode untuk memisahkan bagian-bagian dari suatu web aplikasi. MVC adalah kependekan dari Model View Controller. MVC terdiri dari tiga bagian yaitu;

Model : Model mewakili struktur data. Biasanya model berisi fungsi-fungsi yang membantu kita dalam pengelolaan database seperti memasukkan data ke database, update data dan lain-lain.

View : View adalah bagian yang mengatur tampilan ke user. Bisa di katakan berupa halaman web.

Controller : Controller merupakan bagian yang menjembatani model dan view. Controller berisi script-script php yang berfungsi untuk memproses suatu data dan mengirimkannya ke halaman web.

Disinilah letak perbedaan utama antara framework dengan CMS atau PHP konvensional. Dengan metode MVC, bagian tampilan, logika serta query database diletakkan secara terpisah namun tetap sinkron sehingga pembuatan aplikasi menjadi lebih terstruktur dan sederhana. Model digunakan dalam menuliskan script database, Controller untuk mengembangkan logika pemrogramannya, sedangkan View berfungsi dalam menampilkan layout dari aplikasi yang kita buat. Kelebihan framework antara lain sebagai berikut :

Dikutip dari : abiyyukz.blogspot.com

Nah setelah berknelan dengan Wordpress, Framwork, Cms. Selanjutnya kita masuk ke inti dari postingan ini.

 

Hallo gayn, kali ini saya akan membahas wordpress. Pada postingan ini, merupakan pendapat saya dan https://content.nanobox.io/why-developers-hate-wordpress/  , menganai CMS Wordpress, jika kalian tidak setuju dengan pendapat saya tidak apa - apa. Yuk simak penjelasna berikut.

Saya merasa jika Anda di sini, Anda sangat setuju atau tidak setuju dengan judul artikel ini. Tidak apa-apa. Ini adalah opini, jadi silakan rasakan sesuka Anda. Tapi saya punya data untuk mendukung saya! Menurut Survei Pengembang Stack Overflow 2017, 64,5% responden mengatakan mereka takut akan WordPress. Ini adalah platform ke-3 yang paling ditakuti dari yang mereka masukkan dalam survei mereka.

Saya ingin berbicara tentang mengapa pengembang - orang-orang yang sangat memahami kode; siapa yang bisa dan lebih suka membangun solusi khusus; mereka yang diharapkan untuk membuatnya bekerja dan bekerja dengan baik - benci WordPress. Daftar ini sama sekali tidak lengkap, tetapi mewakili masalah umum yang saya temukan dari pengalaman dan pengalaman pribadi saya sendiri dan pengalaman yang dibagikan orang lain kepada saya.

Sebelum membahas masalah ini, saya merasa saya harus menyebutkan hal-hal yang dapat dilakukan WordPress dengan baik.

Untuk memulai, sangat mudah untuk menginstal dan mengatur. Dengan tumpukan Apache / MySQL / PHP dasar, Anda dapat aktif dan berjalan dalam hitungan menit.

WordPress sangat mudah untuk disesuaikan. Katalog tema dan plugin sangat besar dan terus berkembang. Membangun tema Anda sendiri sangatlah sederhana. Membangun plugin kustom tidak sesederhana itu, tetapi tetap sederhana.

Dan alasan utama menurut saya WordPress telah menjadi platform masuk bagi banyak orang - penghalang masuk yang rendah bagi pengguna non-teknis. Setelah aktif dan berjalan, hampir semua orang dapat mengelola dan menerbitkan konten dengan WordPress.

Namun WordPress gagal dalam banyak hal. Meskipun ini mungkin terlihat sebagai kata-kata kasar, itu dimaksudkan sebagai kritik yang membangun dan saya berharap tim dan komunitas WordPress menganggapnya seperti itu. Inilah alasan mengapa saya, dan pengembang lain, membenci WordPress.

WordPress dimulai hanya sebagai platform blog sederhana - cara mudah untuk mempublikasikan konten. Tapi selama bertahun-tahun, ia telah berkembang menjadi semacam bunglon. Saya telah melihatnya digunakan sebagai sistem manajemen situs sederhana, platform e-niaga, generator situs statis (ya, menurut saya yang ini sangat aneh), sistem manajemen penjualan, agregator prospek, sistem inventaris mobil bekas, dan mengelupas hal-hal lain.

Orang dapat berargumen bahwa ini hanya menggambarkan betapa fleksibelnya WordPress - dan saya setuju - tetapi ketika Anda mencoba melakukan semuanya, sulit untuk melakukan apa pun 100%. Berbagai macam plugin yang tersedia adalah bukti dari orang-orang yang mencoba menyematkan WordPress menjadi sesuatu yang mereka butuhkan.

Pada intinya, WordPress melayani pendekatan plug and play ini. Jangan salah paham, fleksibilitas itu bagus, tetapi saya merasa WordPress kehilangan fokusnya sejak lama dan tanpanya, telah berusaha menemukan jalannya. Alih-alih berfokus menjadi platform blog yang hebat, mereka mencoba menjadi platform segalanya yang hebat. Gol luhur, tidak diragukan lagi, yang sayangnya menyebabkan banyak kekurangan.

Untuk apresiasi Wordpress, WordPress masih berfungsi dengan sangat baik sebagai platform blogging .

Sejauh ini, ini adalah keluhan nomor satu yang pernah saya dengar dari pengembang. Peretasan WordPress terjadi setiap hari, jika tidak setiap jam, jika tidak terjadi setiap menit. Sentimen yang umum adalah bahwa WordPress adalah keju swiss dalam hal keamanan. Itu mungkin berlebihan, tapi tetap saja, itu masalah.

Masalahnya sebagian besar berasal dari seberapa banyak digunakan dan terkenal WordPress dan fakta bahwa itu open-source. Siapapun dapat mengunduh dan melihat kode sumber. Ini jelas tidak dimaksudkan sebagai sedikit proyek open-source. Saya adalah pendukung sumber terbuka yang besar dan memberikan alat peraga kepada WordPress karena menjadi sumber terbuka, tetapi itu membuat menemukan kerentanan sangat mudah.

Menurut w3techs.com, WordPress saat ini menyumbang 27,7% dari semua situs di internet. 27,7% !! Saya tahu tim WordPress bekerja siang dan malam untuk memastikan semuanya aman, dan mereka melakukan pekerjaan dengan sangat baik. Tetapi karena sifat siklus perkembangan yang cepat, banyak hal dapat dilalui. Dan ketika mereka melakukannya, itu menempatkan banyak informasi yang berpotensi sensitif dalam bahaya.

Tidak ada solusi yang benar-benar sederhana dan sistemik untuk masalah ini selain "terus memperbarui WordPress", tetapi siklus rilis cepat WordPress mengarah ke masalah lain (lebih lanjut tentang itu nanti).

Ada orang di luar sana yang akan berkata "Lakukan hal-hal sederhana ini untuk mengamankan situs WordPress Anda ..." Mereka benar. Mereka sederhana. Tetapi mengapa saya harus melakukannya? Mengapa mereka tidak dibangun menjadi intinya?

Ini adalah beberapa hal yang secara pribadi saya tangani :

Batasi pengunggahan file yang dapat dijalankan secara default. Yang harus dilakukan oleh script-kiddie adalah membuat WordPress mengunggah file PHP berbahaya dan BAM, situs Anda diretas. Menurut pengalaman saya, ini adalah pesawat serang yang paling umum digunakan.

Jauhkan opsi yang dapat dikonfigurasi dari sistem file dan anggap sistem file hanya-baca. Inti WordPress melakukan ini dengan cukup baik, tetapi plugin tidak. Jika plugin mengubah file konfigurasi dalam produksi, jangan gunakan itu. Ini membutuhkan sistem file yang dapat ditulis, dan jika sistem file dapat ditulis, maka perubahan berbahaya pada file tersebut dapat dilakukan tanpa banyak usaha.

Batasi upaya login secara default untuk mengurangi serangan brute force.

Hanya untuk beberapa nama. Anda tidak dapat mengharapkan proyek open-source sebesar WordPress menjadi sepenuhnya tahan terhadap serangan, tetapi itulah maksud saya. Itulah alasan pengembang sangat bosan. Mereka lebih suka membangun sesuatu dari awal, khusus untuk kebutuhan mereka, yang dapat mereka kunci tanpa takut kerentanan baru diperkenalkan pada pembaruan berikutnya.

Ini bukanlah hal pertama yang dipikirkan pengembang saat memecahkan masalah. Ini bertentangan dengan pola pikir pengembang yang khas - merancang solusi yang sederhana, elegan, dan dibuat khusus. Beralih ke plugin untuk fungsionalitas membutuhkan perubahan pemikiran yang signifikan.

Pada akhirnya, plugin memang menyediakan cara untuk memperluas WordPress dengan cepat dengan fungsionalitas tertentu. Orang pasti bisa berargumen bahwa ekosistem plugin WordPress adalah kekuatan, tapi itu pedang bermata dua. Dengan kemudahan dan kecepatan plugin, muncul potensi kerentanan keamanan, batasan versi, dan pembengkakan.

Menurut laporan terbaru oleh wpscan.org, 52% dari kerentanan WordPress yang diketahui berasal dari plugin. Sebagai pengembang, Anda terikat pada praktik pengkodean, baik atau buruk, dari pengelola plugin. Jika keamanan menjadi perhatian, yang seharusnya menjadi perhatian pengembang mana pun, proses memperkenalkan plugin baru memerlukan pemeriksaan. Jika dilakukan secara menyeluruh, ini dapat meniadakan manfaat dari plugin yang menghemat waktu.

Siklus rilis WordPress terkadang bisa ... agresif. Tidak jarang melihat beberapa tambalan dan / atau peningkatan versi kecil dalam satu bulan. Ini benar-benar diharapkan karena tim WordPress terus-menerus menemukan dan memitigasi pesawat serangan di inti WordPress. Tetapi sangat membuat frustrasi betapa sering pembaruan ini merusak plugin - 'percikan di mana-mana.

Sangatlah penting untuk selalu memperbarui WordPress, tetapi ini bisa mengakibatkan situs rusak karena kendala versi plugin. Ada "eselon atas" dari pengelola plugin yang terus-menerus menguji dan memperbarui plugin mereka terhadap kandidat rilis terbaru WordPress, tetapi sebagian besar plugin tidak melakukannya dan ketika WordPress merilis pembaruan, harap silangkan itu tidak mengganggu situs Anda .

Saya rasa saya aman dalam mengasumsikan bahwa sebagian besar pengembang ingin menjaga proyek tetap ramping dan bersih. Meskipun beberapa plugin sesuai dengan paradigma ini, banyak plugin yang dibuat untuk menyelesaikan "semua hal". Biasanya ada satu masalah yang perlu diselesaikan oleh pengembang dan plugin akan menyelesaikannya ... dan lima puluh masalah lain yang bukan masalah.

Pengalaman Pengguna yang Obtrusif

Agak terkait dengan masalah pembengkakan adalah seberapa menonjolnya beberapa plugin ke alur kerja WordPress. Saya telah dipaksa untuk menggunakan plugin yang benar-benar mengubah cara posting dibuat dan dipublikasikan. Dan saya tahu saya bukan satu-satunya yang mengalami hal ini.

Keluhan umum yang pernah saya dengar adalah bahwa pengembang, dan bahkan pengelola situs, akhirnya bekerja dengan plugin daripada dengan mereka. Anda mungkin bertanya, "Lalu mengapa menggunakan plugin itu?" Nah, karena itu memecahkan satu masalah itu.

Tapi cukup tentang plugin ...

WordPress dibangun dengan asumsi bahwa sebuah situs akan berjalan di satu server dengan satu sistem file. Semakin banyak pengembang yang bergerak menuju arsitektur multi-node, layanan mikro, dan modern karena fleksibilitas dan skalabilitas yang disediakannya. Membuat WordPress berfungsi dalam jenis arsitektur ini bisa jadi rumit karena satu alasan - ketergantungannya yang dalam pada FTP untuk pembaruan.

Memperbarui kode langsung melalui FTP terasa kotor dan kuno hari ini. Dalam upaya untuk menemukan dan menyelesaikan masalah sebelum kode ditayangkan, pengembang telah mengadopsi alur kerja yang biasanya melibatkan pengembangan lokal, kode yang dikontrol versi, pengujian otomatis, dan integrasi berkelanjutan. Mengupload kode secara langsung ke lingkungan yang sedang berjalan menghilangkan semua ini, menyisakan banyak ruang untuk kesalahan.

Tetapi masalah yang lebih besar adalah asumsi sistem file-tunggal / node tunggal. Cluster web multi-node memberikan peningkatan throughput dan kegagalan perangkat keras. Karenanya pergeseran menuju pendekatan ini. Tetapi jika Anda menginstal plugin / tema atau memperbarui WordPress melalui FTP, itu hanya dapat menerapkan perubahan ke satu sistem file dalam satu waktu. Jika Anda menjalankan cluster web multi-node, Anda harus menjalankan update pada setiap node secara terpisah.

Ya, ada cara untuk mengatasi hal ini, tetapi ini masih menjadi masalah bagi pengembang. Ini juga membutuhkan filesystem yang dapat ditulis di lingkungan live Anda yang telah saya bahas sebagai masalah keamanan yang signifikan.

Ini sebenarnya sesuatu yang saya tangani baru-baru ini. Awalnya, struktur data WordPress terlihat cukup sederhana. Tapi saat Anda mulai mengerjakannya, Anda mulai melihat ... kebiasaan. Misalnya, apakah Anda benar-benar membutuhkan tabel wp_posts dan wp_postsmeta atau tabel wp_comments dan wp_commentsmeta? Tidak bisakah informasi meta dimasukkan dalam tabel dasar?

Ini mungkin tampak kecil, tetapi struktur ini membuatnya sangat mudah untuk meninggalkan data yatim piatu di seluruh database. Untuk mengurangi ini, WordPress telah menyediakan sekumpulan fungsi pembantu untuk membantu memanipulasi data. Tetapi ketika Anda harus memanipulasi ribuan baris, fungsi-fungsi ini tidak berfungsi. Mereka mengalami timeout PHP dan masalah memori dan ... mereka tidak berfungsi.

Mengedit data secara langsung melalui kueri SQL cukup mudah dan berfungsi dengan baik, tetapi untuk menghindari data yatim piatu di mana-mana, Anda harus benar-benar memahami hubungan yang saling berhubungan antara tabel dan menulis kueri agar cocok. Ini berlaku untuk database apa pun, tetapi begitu banyak pemisahan data di database WordPress tampaknya tidak diperlukan.

Dari kesimpulan saya, disini saya juga pengguna Cms. Cms yang saya gunakan Wordpress tetapi, saya tidak terlalu mendalam tentang Wordpress, di satu sisi saya tidak menjelek - jelekan wordpress. Tapi saya hanya berbagi keluhan tentang worpdress, terutama di plugins, kenapa ? karena ketika saya menggunakan plugins. Load website menjadi berat dan memakan memori atau disk space, sehingga saya berniat mendalami Hand coding dan Framework. Di satu sisi saya juga ingin memperdalam ilmu pemograman dan juga development, jadi saya tidak terlalu memaku pada sebuah plugins. Sehingga saya dapat membuat sesuai keinginan saya sendiri dan juga menghemat disk space. Dan saya hanya ingin menjelaskan bahwa WordPress bukanlah platform yang buruk. Wordpress  memberikan solusi yang mudah diatur dan mudah digunakan untuk menerbitkan konten. Ibarat seperti Mie instant dalam makanan. Jika di implementasikan di dunia IT atau Developing seperti membuat web yang instan. Dan untuk macam - macam plugins yang tersedia di Worpress sudah bagus. Akan tetapi kita sebagai pihak Develper tidak leluasa untuk menata tampilan atau design dari blog di website kita. Maka dari itu silahkan Anda memilih sendiri menggunakan CMS atau Framework dan Hand coding, ini adalah kesimpulan dari saya jika saya mempunyai kesalahan mohon di maafkan, sekian dan terima kasih.

Dikutip dari : https://content.nanobox.io/why-developers-hate-wordpress/

Hello gayn, this time I will discuss wordpress. In this post, it is my opinion and https://content.nanobox.io/why-developers-hate-wordpress/, regarding the CMS Wordpress, if you don't agree with my opinion it's okay. Let's look at the following explanation.

I have a feeling that if you're here, you either strongly agree or disagree with the title of this article. That's fine. This is an opinion piece, so feel free to feel however you'd like. But I have data to back me up! According to the 2017 Stack Overflow Developer Survey, 64.5% of respondents said they dread WordPress. It's the 3rd most dreaded platforms of those they included in their survey.

I want to talk about why developers – the people who are knee-deep in the code; who could and would rather build a custom solution; those who are expected to make it work and work well – hate WordPress. This list is by no means exhaustive, but represents common pain-points I've found from my own personal experience and experiences others have shared with me.

Before getting into the pain-points, I feel I have to mention the things WordPress does well.

To start, it's dead simple to install and setup. With a basic Apache/MySQL/PHP stack in place, you can be up and running in a matter of minutes.

WordPress is really easy to customize. The catalog of themes and plugins is massive and continues to grow. Building your own theme is really simple. Building a custom plugin isn't as simple, but simple nonetheless.

And the main reason I think WordPress has become the go-to platform for so many people – the low barrier-to-entry for non-technical users. Once it's up and running, just about anybody can manage and publish content with WordPress.

But WordPress falls short in a lot of ways. While this may come off as a rant, it's meant as constructive criticism and I hope the WordPress team and community take it as such. These are the reasons why I, and other developers, hate WordPress.

WordPress started out as just a simple blogging platform – an easy way to publish content. But over the years, it has evolved into a chameleon of sorts. I've seen it used as a simple site management system, an ecommerce platform, a static site generator (yeah, I find this one really odd), a sales management system, a lead aggregator, a used-car inventory system, and a slough of other things.

One could argue this just illustrates just how flexible WordPress is – and I would agree – but when you try to do everything, it's hard to do anything 100%. The vast array of available plugins is evidence of people trying to shoehorn WordPress into something they need.

At its core, WordPress caters to this plug-n-play approach. Don't get me wrong, flexibility is good, but I feel like WordPress lost its focus a long time ago and without it, has been trying to find its way. Rather than focusing on being a great blogging platform, they've tried to be a great everything platform. A lofty goal, no doubt, that has unfortunately led to many shortcomings.

To their credit, WordPress still works really well as a basic blogging platform.

Security

This is by far the number one complaint I've heard from developers. WordPress hacks are a daily, if not hourly, if not an every-minute occurrence. The common sentiment is that WordPress is swiss-cheese when it comes to security. That may be an exaggeration, but still, it's a problem.

The problem largely stems from just how widely-used and well-known WordPress is and the fact that it's open-source. Anybody can download and view the source code. This is definitely not meant as a slight on open-source projects. I'm a big open-source proponent and give props to WordPress for being open-source, but it makes finding vulnerabilities really easy.

According to w3techs.com, WordPress currently accounts for 27.7% of all sites on the internet. 27.7%!! I know the WordPress team works day and night to make sure things are secure, and they do a really good job. But due to the nature of rapid development cycles, things get through. And when they do, it puts a lot of potentially sensitive information at risk.

There's no real simple, systemic solution to this problem other than to "keep WordPress up to date", but WordPress' rapid release cycle leads to other problems (more on that later).

There are those out there that will say "Do these simple things to secure your WordPress site..." They're right. They are simple. But why should I have to do them? Why aren't they just built into the core?

These are some of the things I've personally dealt with:

Restrict the upload of executable files by default. All a script-kiddie has to do is get WordPress to upload a malicious PHP file and BAM, your site is hacked. In my experience, this has been the most common attack plane used.

Keep configurable options out of the filesystem and assume the file-system is read-only. The WordPress core does this pretty well, but plugins don't. If a plugin modifies a config file in production, don't use it. This requires a writable filesystem, and if the filesystem is writable, then malicious changes those files can be made without much effort.

Limit login attempts by default to mitigate brute-force attacks.

Just to name a few. You can't expect an open-source project as large as WordPress to be completely impervious to attack, but that's exactly my point. That's a reason developers are so weary of it. They'd rather build something from scratch, specific to their needs, that they can lock down without the fear of new vulnerabilities being introduced with the next update.

This is not the first thing a developer thinks when solving a problem. It goes against the typical developer mindset – architect a simple, elegant, custom-built solution. Turning to plugins for functionality requires a significant shift in thinking.

Ultimately, plugins do provide a way to quickly extend WordPress with specific functionality. One could definitely argue that WordPress' plugin ecosystem is a strength, but it's a double-edged sword. With the ease and speed plugins provide comes the potential for security vulnerabilities, version constraints, and bloat.

According to a recent report by wpscan.org, 52% of known WordPress vulnerabilities come from plugins. As a developer, you're beholden to the coding practices, good or bad, of the plugin maintainer. If security is a cause for concern, which it should be for any developer, the process of introducing a new plugin requires vetting. If done thoroughly, this can negate the time-saving benefit plugins provide.

WordPress' release cycle can at times be... aggressive. It's not rare to see multiple patches and/or minor version bumps in a single month. This is completely expected as the WordPress team is constantly finding and mitigating attack planes in the WordPress core. But it's incredibly frustrating how often these updates break plugins – 'splosions everywhere.

It's incredibly important to keep WordPress up to date, but this can come at the cost of a broken site due to plugin version constraints. There is an "upper echelon" of plugin maintainers that are constantly testing and updating their plugins against the latest WordPress release candidates, but the vast majority of plugins do not and when WordPress releases an update, cross your fingers it doesn't bork your site.

I think I'm safe in assuming that the majority of developers like to keep projects lean and clean. While some plugins conform to this paradigm, so many are built to solve "all the things." There's usually one problem a developer needs solved and a plugin will solve it... and fifty other problems that aren't problems.

Somewhat related to the issue of bloat is how obtrusive some plugins can be to the WordPress workflow. I've been forced to use plugins that completely change how posts are built and published. And I know I'm not the only one who has run into this.

A common complaint I've heard is that developers, and even site maintainers, end up working around plugins rather than with them. You're probably asking, "Then why use that plugin?" Well, because it solves that one problem.

But enough about plugins...

WordPress is built with the assumption that a site will run on a single server with a single filesystem. More and more developers are moving towards a modern, micro-service, multi-node architecture because of the flexibility and scalability it provides. Getting WordPress to work in this type of architecture can be tricky for one reason – its deep reliance on FTP for updates.

Updating live code through FTP feels dirty and archaic these days. In an effort to find and resolve issues before code goes live, developers have adopted a workflow that typically involves local development, version controlled code, automated testing, and continuous integration. Uploading code directly into a running environment skirts all of this, leaving plenty of room for things to go wrong.

But a bigger issue is the assumption of a single-node/single-filesystem. Multi-node web clusters provide increased throughput and hardware failover. Hence the shift towards this approach. But if you install a plugin/theme or update WordPress through FTP, it can only apply the change to a single filesystem at a time. If you're running on a multi-node web cluster, you have to run the update on each and every node separately.

Yes, there are ways around this, but it's still a pain-point for developers. This also requires a writable filesystem in your live environment which I've already touched on as a significant security concern.

Data Structure & Orphaned Data

This is actually something I've dealt with recently. Starting out, the WordPress data structure seems pretty simple. But as you start to work with it, you start to see... quirks. For example, do you really need wp_posts and wp_postsmeta tables or wp_comments and wp_commentsmeta tables? Can't meta information be included in the base table?

It might seem minor, but this structure makes it really easy to leave crufty, orphaned data all over the database. To mitigate this, WordPress has provided a collection of helper functions to aid in manipulating data. But when you have to manipulate thousands of rows, these functions simply don't work. They run into PHP timeouts and memory issues and... they just don't work.

Editing the data directly through SQL queries is easy enough and works great, but to avoid orphaned data everywhere, you have to completely understand the interconnected relationships between tables and write queries to match. This is true for any database, but so much of the data separation in WordPress' database seems unnecessary.

From my conclusion, here I am also a Cms user. Cms that I use Wordpress but, I am not very deep about WordPress, on the one hand I do not badmouth wordpress. But I only share complaints about worpdress, especially in plugins, why? because when I use plugins. Load websites become heavy and take up memory or disk space, so I intend to explore Hand coding and Frameworks. On the one hand, I also want to deepen the knowledge of programming and development, so I don't get too hung up on plugins. So that I can make it my own way and also save disk space. And I just want to make it clear that WordPress is not a bad platform. Wordpress provides an easy to set up and easy-to-use solution for publishing content. Like instant noodles in food. If implemented in the world of IT or Developing, it is like creating an instant web. And the kinds of plugins available on Worpress are good. However, we as Develpers are not free to customize the appearance or design of the blog on our website. Therefore, please choose for yourself using a CMS or Framework and Hand coding, this is the conclusion from me if I have an error, please forgive me, that's all and thank you.

Source : https://content.nanobox.io/why-developers-hate-wordpress/