WordPress, Drupal თუ Joomla: რომელი CMS რომელი საიტისთვის

აირჩიე WordPress, თუ კონკრეტული მიზეზი არ გაქვს, რომ არ აირჩიო. W3Techs-ის კვლევის მიხედვით ის ყველა ვებსაიტის 40%-ზე მეტს ამუშავებს, ნებისმიერი თემა და plugin, რაც შეიძლება დაგჭირდეს, მისთვის არსებობს, და ვისაც მომავალში დაიქირავებ, ის ეცოდინება. აირჩიე Drupal, როცა საიტი სინამდვილეში სტრუქტურირებული კონტენტის აპლიკაციაა - ბევრი კონტენტის ტიპი ველებით, დეტალური უფლებები, სარედაქციო workflow, სერიოზული მრავალენოვნება - და გყავს დეველოპერი, რომელიც მას Composer-ით მოუვლის. აირჩიე Joomla, როცა გინდა იმაზე მეტი ჩაშენებული ფუნქცია, ვიდრე WordPress გთავაზობს (მრავალენოვნება, წვდომის დონეები, სტრუქტურირებული მენიუს სისტემა), Drupal-ის დეველოპერული ტვირთის გარეშე, და ეგუები გაცილებით პატარა ეკოსისტემას. სამივე PHP აპლიკაციაა MySQL-თან თავსებად ბაზაზე და სამივე ყოველთვიურად განახლებებზე გარკვეულ დროს წაგართმევს, რომელიც არ უნდა აირჩიო.

მოკლე შედარება#

ცხრილი მალავს ყველაზე მნიშვნელოვან განსხვავებას: საიტის რა ნაწილია თავად CMS და რა ნაწილი - გაფართოებები. WordPress საიტი ძირითადად plugin-ებია - საკონტაქტო ფორმა, SEO, ქეშირება, უსაფრთხოება, backup-ები, page builder - და მისი ხარისხი ამ plugin-ების ხარისხია. Drupal საიტი ძირითადად ბირთვი და კონფიგურაციაა, ნაკლები და უფრო დიდი მოდულებით. Joomla შუაშია. ეს ყველაფერ დანარჩენს განსაზღვრავს: უსაფრთხოების რისკს, განახლების ტკივილს და იმას, ვინ გჭირდება, რომ ის იმუშაოს.

მოთხოვნები: PHP, ბაზა და მეხსიერება#

სამივეს სჭირდება PHP ჩვეულებრივი გაფართოებებით (mysqli ან pdo_mysql, gd ან imagick, mbstring, xml, zip, curl, intl Drupal-ისთვის და რეკომენდებული დანარჩენებისთვის), ვებ სერვერი URL-ების გადაწერის მხარდაჭერით და MySQL-თან თავსებადი ბაზა. ვერსიების ზუსტი მინიმუმი ყოველ რელიზთან იცვლება, ამიტომ ჩათვალე, რომ ეს წერის მომენტისთვის აქტუალურია, და ინსტალაციამდე პროექტის მოთხოვნების გვერდი გადაამოწმე.

რეალური განსხვავებები მეხსიერებაში ჩანს. PHP ყოველ მოთხოვნას worker-ში ასრულებს საკუთარი memory_limit-ით, და CMS თავისი გაფართოებებით წყვეტს, რამდენი სჭირდება მოთხოვნას:

• WordPress მარტივ საიტს მოთხოვნაზე 64-128 MB-ით ამუშავებს; WooCommerce და page builder-ები ამას 256 MB-მდე ან მეტამდე ზრდიან. მთელი პატარა საიტი ბაზიანად 1 GB-ში ეტევა. რამდენი RAM სჭირდება WordPress-ს რიცხვებს ტრაფიკის მიხედვით ითვლის.
• Drupal მოთხოვნაზე უფრო მძიმეა - 128 MB რეალისტური მინიმუმია, 256 MB კი ნორმალურია ბევრმოდულიანი საიტისთვის - მაგრამ ჩაშენებული ქეშირების წყალობით ანონიმური მოთხოვნების უმეტესობა გვერდს საერთოდ არ აგებს.
• Joomla შესადარებელი საიტისთვის WordPress-თან ახლოსაა.

RE:NODE-ზე CMS ხაზი ზუსტად ამ მიზეზით 1 GB-დან იწყება: ერთი საიტი ბაზით ეტევა, ხოლო უფრო დიდი გეგმები plugin-ებით დატვირთული ინსტალაციებისა და გვერდიგვერდ რამდენიმე საიტისთვისაა. PHP ini პარამეტრები, რომლებსაც მნიშვნელობა აქვს ფარავს memory_limit-ს, upload_max_filesize-ს და ყველაფერ დანარჩენს, რისი შეცვლაც მოგინდება.

WordPress: ნაგულისხმევი არჩევანი კარგი მიზეზებით#

WordPress ბლოგის ძრავაა, რომელიც ზოგად CMS-ად გაიზარდა, და ეს ისტორია ეტყობა: კონტენტი არის პოსტები და გვერდები, მომხმარებლის პოსტის ტიპებითა და ველებით (Advanced Custom Fields-ის მსგავსი plugin-ებით), რომლებიც თავზე აქვს მიმაგრებული. საიტების უმეტესობისთვის ეს საკმარისია და მისი უპირატესობების გადაჭარბება ძნელია:

• ეკოსისტემა. რაც არ უნდა დაგჭირდეს - დაჯავშნა, მაღაზია, წევრობა, ფორუმი, მრავალენოვნება - რამდენიმე plugin არსებობს და მათგან ზოგი შესანიშნავია.
• რედაქტორი. ბლოკების რედაქტორი კარგია მათთვის, ვინც წერს, და არატექნიკური თანამშრომლები WordPress-ს ნებისმიერ სხვა რამეზე სწრაფად სწავლობენ.
• სპეციალისტების რაოდენობა. ის ყველა ვებ სააგენტომ და ბევრმა ფრილანსერმა იცის.
• ავტომატური განახლებები. ბირთვის მცირე რელიზები, რომლებსაც უსაფრთხოების გასწორებები მოაქვს, ნაგულისხმევად ავტომატურად ყენდება. plugin-ებისა და თემების ავტომატური განახლება თითოეულისთვის ცალკე შეგიძლია ჩართო.

ხარჯები მედლის მეორე მხარეა. WordPress-ის გატეხვების უმეტესობა plugin-ებით ხდება და არა ბირთვით: მიტოვებული plugin ცნობილი ხვრელით ჩვეულებრივი შესასვლელია. ორმოციპლაგინიან საიტს ორმოცი მომწოდებელი ჰყავს, რომელთა კოდიც შენს ბაზაზე სრული წვდომით მუშაობს. წარმადობის პრობლემები ჩვეულებრივ ერთი მძიმე plugin-ია. გამოსავალი დისციპლინაა და არა სხვა CMS - ნაკლები plugin, შერჩეული მოვლის ისტორიის მიხედვით, და ყოველკვირეულად დაყენებული განახლებები - დანარჩენს კი ფარავს WordPress-ის უსაფრთხოების გაძლიერება.

ინსტალაცია არის zip ფაილი და ბრაუზერის ინსტალერი: შექმენი ბაზა და მომხმარებელი, ატვირთე ფაილები, შეავსე wp-config.php ან ინსტალერს მიეცი მისი დაწერის საშუალება. WordPress-ის ხელით ინსტალაცია ამას ნაბიჯ-ნაბიჯ გადის ჰოსტზე, სადაც ერთი დაწკაპუნებით ინსტალერი არ არის.

Drupal: სტრუქტურირებული კონტენტი და სერიოზული უფლებები#

Drupal კონტენტის ფრეიმვორკია. შენ განსაზღვრავ კონტენტის ტიპებს ტიპიზებული ველებით, ტაქსონომიებს, ერთეულებს შორის კავშირებს, view-ებს, რომლებიც მათ ჩამოთვლის და ფილტრავს, და უფლებების სისტემას, რომელსაც შეუძლია ზუსტად ერთ როლს მისცეს ზუსტად ერთი ტიპის კონტენტის რედაქტირების უფლება. ბირთვი შეიცავს იმას, რისთვისაც WordPress-ს plugin-ები სჭირდება:

• მრავალენოვნება - ბირთვის ოთხი მოდული თარგმნის კონტენტს, კონფიგურაციას და ინტერფეისს.
• კონტენტის მოდერაცია და workflow-ები - draft, review, published, უფლებებით თითოეული გადასვლისთვის.
• Views - query builder სიებისთვის, feed-ებისა და REST გამოსავლისთვის, ბირთვში Drupal 8-დან.
• Layout Builder და ქეშირება - გვერდის მიხედვით განლაგებები, პლუს Internal Page Cache და Dynamic Page Cache, რომლებიც მოთხოვნების უმეტესობას გვერდის თავიდან აგების გარეშე ემსახურება.
• JSON:API ბირთვში, რაც Drupal-ს გონივრულ headless back end-ად აქცევს.

თანამედროვე Drupal Composer-ით იგება და ახლდება. ახალი საიტი იწყება composer create-project drupal/recommended-project-ით, მოდულები ემატება composer require drupal/<module>-ით, ხოლო განახლება არის composer update, რასაც მოსდევს drush updatedb. ეს PHP აპლიკაციის მართვის სწორი გზაა და არასწორი გზა საიტის მფლობელისთვის, რომელსაც ტერმინალი არასოდეს გამოუყენებია. თუ პროექტზე Composer-თან არავინაა კომფორტულად, Drupal გახდება საიტი, რომლის განახლებასაც ვერავინ ბედავს.

Drupal 8-დან მოყოლებული დიდი განახლებები ეტაპობრივია: ყოველი მთავარი ვერსია შლის კოდს, რომელიც წინაში deprecated იყო, ამიტომ საიტი, რომელიც deprecation-ებს დროულად ასწორებს, 10-დან 11-ზე თავიდან აგების გარეშე გადადის. მტკივნეული მიგრაცია იყო Drupal 7-დან 8-ზე, და Drupal 7-ის მხარდაჭერა 2025 წლის იანვარში დასრულდა - ნებისმიერი Drupal 7 საიტი, რომელიც ჯერ კიდევ მუშაობს, მხარდაჭერის გარეშეა. Drupal-ის ჰოსტინგის გზამკვლევი დეტალურად ფარავს settings.php-ს, cron-ს და ქეშირებას.

Joomla: მეტი ყუთში, ნაკლები ხალხი#

Joomla-ს ბირთვი ყუთიდანვე WordPress-ისაზე ფართოა: მრავალენოვანი საიტები ენების ასოციაციებით, მენიუს სისტემა, რომელიც გვერდის განლაგებას მართავს, მომხმარებელთა ჯგუფები და ნახვის წვდომის დონეები, მომხმარებლის ველები, workflow-ები და ჩაშენებული განახლების კომპონენტი, რომელიც ბირთვსაც და დაყენებულ გაფართოებებსაც ადმინისტრატორის პანელიდან ანახლებს. კლუბისთვის, სკოლისთვის, წევრობის საიტისთვის ან მრავალენოვანი სავიზიტო საიტისთვის Joomla-ს გაფართოებების გარეშე შეუძლია ის, რისთვისაც WordPress-ს სამი-ოთხი plugin სჭირდება.

ფასი ეკოსისტემაა. გაფართოებები და შაბლონები გაცილებით ნაკლებია, მათი უფრო დიდი წილი კომერციულია და ნაკლები ადამიანი იცნობს სისტემას კარგად. Joomla 3-დან 4-ზე გადასვლამ ბევრი შაბლონი და გაფართოება გატეხა და ბევრი საიტი თავიდან აგებისკენ უბიძგა; 4-დან 5-ზე განახლება უფრო რბილი იყო, უკუთავსებადობის plugin-ით, რომელიც ძველ გაფართოებებს ამუშავებდა, სანამ მათი დეველოპერები დაეწეოდნენ. განახლებამდე შეამოწმე, რომ გაფართოებები, რომლებზეც დამოკიდებული ხარ, მიმდინარე მთავარ ვერსიას უჭერენ მხარს.

Joomla WordPress-ის მსგავსად ყენდება: ატვირთე პაკეტი, შექმენი ბაზა, გაუშვი ვებ ინსტალერი და წაშალე installation საქაღალდე, როცა ამას გეტყვის. Joomla-ს ჰოსტინგის გზამკვლევში კონფიგურაციისა და განახლების დეტალებია.

მოვლა: რა გიჯდება თითოეული ყოველთვიურად#

სამივე პროგრამაა, რომელსაც ავტომატურად, მთელი დღე უტევენ სკანერები, რომლებიც ცნობილ ხვრელებს ეძებენ. რომელ CMS-ს აირჩევ, ნაკლებად მნიშვნელოვანია, ვიდრე ის, განახლებულს თუ შეინახავ.

რაც არ უნდა გაუშვა, რუტინა იგივეა: backup ყოველი განახლების წინ, განახლებები ყოველკვირეულად და არა მაშინ, როცა ვინმეს გაახსენდება, მოკლე შემოწმება, რომ საიტი შემდეგაც მუშაობს, და გაფართოებების წაშლა - არა მხოლოდ გამორთვა - როცა მათ აღარ იყენებ. ბაზა საიტის ნახევარია, ამიტომ backup-მა ისიც უნდა მოიცვას; იხილე ბაზის backup-ები და აღდგენა.

რა ღირს ისინი ჰოსტინგის გარდა#

სამივე უფასოა და GPL ლიცენზიით ვრცელდება. ფული სხვაგან მიდის და არჩევამდე ღირს მისი შეფასება, რადგან ჰოსტინგის ანგარიში ჩვეულებრივ ყველაზე პატარა ხაზია.

• WordPress დასაწყებად იაფია და ზრდასთან ერთად ძვირდება. ფორმების, SEO-ს, backup-ების, მრავალენოვნებისა და მაღაზიების საუკეთესო plugin-ებს აქვთ უფასო ვერსიები და ფასიანი დონეები, რომლებიც წლიური ლიცენზიებით იყიდება, და განახლებებისა და მხარდაჭერისთვის სწორედ ფასიანი დონე გჭირდება. ბიზნეს საიტს ხშირად სამიდან ექვსამდე ასეთი აქვს. თუ ლიცენზიას ვადა გაუვა, ეს plugin განახლებებს აღარ იღებს, რაც მიტოვებული plugin-ის პრობლემასთან გაბრუნებს.
• Drupal-ს კომერციული მოდულების ბაზარი თითქმის არ აქვს; drupal.org-ზე თითქმის ყველაფერი უფასოა. ხარჯი ადამიანებია: კონტენტის ტიპების, view-ებისა და უფლებების კარგად აგებას დეველოპერი სჭირდება, ისევე როგორც Composer-ით მართული საიტის აქტუალურად შენახვას. Drupal საიტი, რომლის უკანაც დეველოპერის ბიუჯეტი არ დგას, ტვირთია.
• Joomla-ს კომერციული გაფართოებების უფრო დიდი წილი აქვს, ვიდრე WordPress-ს, ხშირად პატარა მომწოდებლებისგან, გამოწერით გაყიდული. სანამ საიტს მათ გაფართოებაზე ააგებ, შეამოწმე, რამდენი ხანია მომწოდებელი განახლებებს უშვებს.

საკუთარი დროც დაითვალე. თვეში ერთი საათი განახლებებსა და შემოწმებებზე რეალისტური მინიმუმია ნებისმიერი მათგანისთვის, და საათი, რომელსაც გამოტოვებ, სწორედ ის არის, რომელსაც მნიშვნელობა აქვს.

რომელიმე მათგანის ჰოსტინგი nginx-ზე#

სამივეს Apache-სთვის წესები .htaccess ფაილში მოყვება (Joomla-ს - htaccess.txt-ად, რომელსაც სახელი უნდა გადაარქვა). nginx .htaccess-ს საერთოდ არ კითხულობს. nginx-ზე იგივე წესები - ლამაზი URL-ები და, არანაკლებ მნიშვნელოვანი, წესები, რომლებიც პირად ფაილებზე პირდაპირ წვდომას კრძალავს - სერვერის კონფიგურაციაში უნდა არსებობდეს. სამივესთვის ამის ბირთვი front-controller-ის შაბლონია:

location / {    try_files $uri $uri/ /index.php?$args;}location ~ \.php$ {    include fastcgi_params;    fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;    fastcgi_pass php-fpm;}

Drupal-ს ასევე სჭირდება, რომ მისი settings.php და პირადი ფაილების დირექტორია ვებიდან დაშორებული იყოს, ხოლო Joomla-ს htaccess.txt-ის უსაფრთხოების წესები უნდა გადაითარგმნოს. ჰოსტს, რომელიც nginx-ზე დაფუძნებულ CMS ჰოსტინგს ყიდის, ეს უკვე დაყენებული უნდა ჰქონდეს; თუ ახალ ინსტალაციაზე ლამაზი permalink-ები 404-ს გაძლევს, მიზეზი ეს არის.

RE:NODE-ზე CMS ხაზი - კატალოგში Engines - nginx-სა და PHP-ზე მუშაობს და CMS-ს თავად აყენებ ფაილების მენეჯერით ან SFTP-ით. ერთი დაწკაპუნებით ინსტალერი არ არის, რაც იმასაც ნიშნავს, რომ ვერსიაზე არავინ გაბამს. ყოველ გეგმას აქვს ბაზის slot-ები საიტის ბაზისთვის და proxy slot: მიმართე A ჩანაწერი მისამართზე, რომელსაც პანელი გაჩვენებს, და სერტიფიკატი ავტომატურად გაიცემა და განახლდება.

არჩევა: სწრაფი გზამკვლევი#

• ბლოგი, პატარა ბიზნესის საიტი, პორტფოლიო, WooCommerce მაღაზია: WordPress.
• საიტი, სადაც მთელ რედაქტირებას არატექნიკური თანამშრომლები გააკეთებენ და დეველოპერი არ გეყოლება: WordPress, რაც შეიძლება ნაკლები plugin-ით.
• ბევრი კონტენტის ტიპი კავშირებით, რთული როლები, სარედაქციო დამტკიცება, რამდენიმე ენა და ხელთ არსებული დეველოპერი: Drupal.
• მრავალენოვანი ან წევრობის საიტი დეველოპერის გარეშე, სადაც plugin-ებს ბირთვის ფუნქციები გირჩევნია: Joomla.
• რუსულენოვანი ახალი ამბების ან მედია პორტალი არსებული DataLife Engine ლიცენზიით: DLE, რომელსაც ფარავს DataLife Engine-ის ჰოსტინგი.
• საიტი, რომელიც იშვიათად იცვლება და არც ავტორიზაცია აქვს, არც ფორმები: შესაძლოა საერთოდ არანაირი CMS - სტატიკური საიტი უფრო სწრაფია, უფრო იაფია და არაფერი აქვს გასასწორებელი. იხილე სტატიკური საიტის ჰოსტინგი.

ყველაზე ცუდი არჩევანი ისაა, რომლის მოვლაც გუნდში არავის შეუძლია. კარგად მოვლილი WordPress საიტი მიტოვებულ Drupal საიტს უსაფრთხოებით, სიჩქარითა და ფასით ყოველთვის ჯობნის.

FAQ#

WordPress ნაკლებად უსაფრთხოა, ვიდრე Drupal ან Joomla?

WordPress-ის ბირთვს უსაფრთხოების კარგი ისტორია აქვს. მას უფრო ხშირად უტევენ, რადგან ყველგანაა, და რეალური გატეხვების უმეტესობა მოძველებული ან მიტოვებული plugin-ებით ხდება. Drupal-ის უსაფრთხოების რეპუტაცია ნაწილობრივ მისი უსაფრთხოების გუნდიდან მოდის, ნაწილობრივ კი იქიდან, რომ საიტებს ნაკლები და უკეთ შემოწმებული მოდულები აქვთ. განახლებული WordPress საიტი ცოტა plugin-ით არსებითად ნაკლებად უსაფრთხო არ არის.

შემიძლია მოგვიანებით ერთი CMS-დან მეორეზე გადავიდე?

კი, მაგრამ ეს მიგრაციის პროექტია და არა ღილაკი. კონტენტის გადატანა იმპორტერებითა და მიგრაციის ხელსაწყოებით შეიძლება - Drupal-ის Migrate API ძლიერია, WordPress-ს კი ბევრი წყაროსთვის აქვს იმპორტერები - მაგრამ თემები, URL-ები, ფორმები და გაფართოებების მონაცემები თავიდან უნდა აიგოს. აირჩიე რამდენიმე წლის პერსპექტივით.

რომელი CMS არის ყველაზე სწრაფი?

გვერდის ქეშირების ჩართვისას სამივე ანონიმურ ვიზიტორებს სწრაფად ემსახურება, რადგან ქეშირებული გვერდი PHP-სა და ბაზას გვერდს უვლის. განსხვავებები ავტორიზებული მომხმარებლებისა და არაქეშირებული გვერდებისთვის ჩნდება, სადაც გაფართოებების რაოდენობასა და ხარისხს CMS-ზე მეტი მნიშვნელობა აქვს. Drupal-ის ჩაშენებული ქეშები მას კარგ ნაგულისხმევ მდგომარეობას აძლევს; WordPress-ს ქეშირების plugin ან სერვერის მხარის ქეში სჭირდება - იხილე WordPress-ის სიჩქარე და ქეშირება.

ყველა მათგანი მუშაობს MySQL 8.4-თან?

სამივეს მიმდინარე რელიზები MySQL 8.0-სა და უფრო ახალს უჭერს მხარს, და MySQL 8.4 ამ სერიაშია. ძველი ვერსიები - Drupal 7, Joomla 3, ძალიან ძველი WordPress plugin-ები - შეიძლება იყენებდნენ წაშლილ SQL ფუნქციებს ან ძველ ავთენტიფიკაციას, რაც ჰოსტის შეცვლამდე განახლების კიდევ ერთი მიზეზია.

შემიძლია ერთ გეგმაზე რამდენიმე CMS საიტი განვათავსო?

ტექნიკურად კი, თუ საცავი, მეხსიერება და ბაზის slot-ები იძლევა ამის საშუალებას. ჩვეულებრივ უმჯობესია, ერთმანეთთან დაუკავშირებელი საიტები ცალ-ცალკე შეინახო, რომ ერთი საიტის გატეხილმა plugin-მა მეორე საიტის ფაილებსა და ბაზას ვერ მიაღწიოს.