بهینه وب
خانه » مقالات ترجمه شده » جوملا در مقابل دروپال

جوملا در مقابل دروپال

جوملا در مقابل دروپال: مقایسه ای فنی از بهترین سیستم های مدیریت محتوای متن باز

چند هفته پیش، لازم بود که مقایسه ای فنی بین جوملا و دروپال انجام دهم. طیق معمول همیشه جستجوی من به صورت آنلاین آغاز شد. با کمال تعجب، ارزیابی فنی مناسبی از این دو CMS محبوبِ متن باز یافت نشد. موارد یافت شده نیز، اکثرا مقایسه های سطحی بودند که توسط مدیران سایت ها و افرادی که طراح وب نبودند، نوشته شده بود. مقالاتی معدودی هم یافت شد که به مقایسه عملکرد آن دو با استفاده از استانداردها پرداخته بودند، اما چیزی نبود که برای ارزیابی عمیق فنی از جزییات CMS تحت اسکریپت PHP کافی باشد. به عنوان توسعه دهنده ای که هم بر روی جوملا و هم دروپال کار کرده است، زمان آن رسیده بود که یک مقایسه فنی قوی بین جوملا و دروپال بنویسم تا به جنگ بین این دو پایان دهم.

قبل از شروع کار، برخی از اصطلاحات ویژه سیستم مدیریت محتوا (CMS) باید توضیح داده شود:

  • نامی که برای ماژول ها در دروپال به کار می رود، بسیار شبیه به مفهوم کامپوننت (Component) در جوملا است.
  • نامی که برای ماژول ها در جوملا به کار می رود، بسیار شبیه به مفهوم Blocks در دروپال است.

سهولت استفاده در مقابل پیچیدگی

اکثر تحلیل گران از یک طیف برای تعیین اینکه کدام CMS برای مشخصه های متفاوت مناسب است، استفاده می کنند. برای مثال وردپرس در یک انتهای این طیف قرار دارد، که ساده ترین قابلیت استفاده را دارد و برای پروژه های پیچیده مناسب نیست. جوملا در میانه این طیف، و دروپال در انتهای دیگر آن است که سخت ترین قابلیت استفاده را دارد، اما برای استفاده در پروژه های پیچیده مناسب است. این طبقه بندی حقایقی را در خود دارد، اما تنها در سطح بسیار کلی در نظر گرفته می شود.

Developer installatior-configuration

نمودار بالا را ارزیابی کنید. جوملا نه تنها نصب و تنظیم آسان تری از دروپال دارد، بلکه هم چنین توسعه سفارشی سازی عملکردهای آن در مقایسه با دروپال و وردپرس آسان تر می یابد.

Hight Quality

سفارشی سازی برای سازگار شدن با نیازها

این پست به طور عمده با توسعه سفارشی سازی کیفیت بالا در ارتباط است. شما به راحتی می توانید با هک کردن هر یک از ۳ سیستم مدیریت محتوا هر آنچه را که مایلید، انجام دهید. اما این کار به قیمت به خطر افتادن امنیت، قابلیت نگهداری، و اعتبار شما تمام می شود.

این تصور غلط که دروپال برای پروژه های پیچیده مناسب تر از جوملا است نیز، ازطریق ارزیابی CMS از نگاه یک مدیر سایت، نه یک طراح بدست آمده است. این برداشت حاصل این واقعیت است که دروپال یک رویکرد ماژولار به طراحی رابط کاربری و بخش ورود اطلاعات ارایه می دهد. صفحات وب دروپال با استفاده از Block ها و View ها بوجود آمده اند که این به مدیران سایت آزادی عمل می دهد تا صفحات وب را بدون نیاز به ماژول های برنامه نویسی برای دروپال بسازند. در حالی که جوملا جعبه ابزارهای مشابهی را (کامپوننت و ماژول ها) به مدیران سایت ارایه می دهد، جوملا به اندازه دروپال قدرتمند نیست تا یک مدیر سایت توان مند توسط آن به سرعت صفحات وب سایت جدید پیچیده بسازد.

اگرچه، سفارشی سازی قاابلیت های جدید داستان دیگری دارد. در جهان امروز که همه چیز توسط نرم افزار مدیریت می شود، آزادی عمل در حرکت دادن محتوا پیرامون صفحه وب و داشتن یک رابط کاربری ماژولار به تنهایی کافی نیست. زمانی که نیازهای کسب و کار تکامل می باید، لازم است که عملکردهای CMS برای تطابق با نیاز ها به اندازه کافی انعطاف پذیر باشد.

مقایسه فنی جوملا و دروپال

به محض این که برنامه نویس جرات آغاز به کار از طریق منبع دروپال را می کند، با یک کابوس مواجه می شود. سفارشی سازی (Customizing) در دروپال آسان نیست، زیرا که دروپال بر پایه طراحی ضعیف و چارچوب رویه ای است، در حالی که جوملا بر پایه ی یک طراحی خوب، شی گرا یا object-oriented (شیوه برنامه نویسی است که ساختار یا بلوک اصلی اجزای آن، شی‌ها می‌باشند.) و با چارچوب MVC می باشد. جوملا هم چنین تعدادی از الگوهای طراحی مانند شنونده (listener)، و غیره را اجرا می کند.

حتی اگر برنامه نویسان بسیار ماهر (با دستمزد بالا) دروپال را هم استخدام کنید، احتمال بالایی وجود دارد که کد شما هنوز هم شبیه رشته های درهم پیچیده ای باشد که اگر بخواهید تغییرات بیشتری انجام دهید، موجب بروز مشکلات بسیاری در آینده خواهد شد.

  1. پایگاه داده (database)

الف) در دروپال، view ها به صورت پیش فرض در پایگاه داده ذخیره می شود. این به این معناست که شما نمی توانید کنترل نسخه نرم افزارهایی (مانند SVN یا GIT) را داشته باشید و توسعه دهندگان نمی توانند در مورد viewهای در حال افزایش دخالتی داشته باشند. هسته دروپال قابلیت لغو کردنview های پیش فرض در کد را فراهم می کند، اما این فرآیند نیازمند مراحل پیشرفته تری است.

ب) هر نوع محتوای جدید در دروپال با دو نمودار پایگاه داده ای در ارتباط است. این به این معنی است در طول زمان، هم زمان که مدیر سایت محتوا را ایجاد می کند و یا تغییر می دهد، ساختار پایگاه داده ها هم تغییر می کند. این کابوسی برای طراحان وب سایتی است که می خواهند در حین ساخت برنامه های وب، نمودار موجودیت- ارتباط (ERD) را ترسیم کنند. شما هرگز نمی توانید به نمودار ER خود تکیه کنید، زیرا که دفعه ی بعدی که به پایگاه داده ای خود نگاه کنید، تعداد نمودارها و طرح ها متفاوت خواهد بود.

ج) در دورپال لاگ ها در پایگاه داده ها ذخیره می شود. اما تمام سیستم های مدرن لاگ ها را در فایل ها ذخیره می کنند. ذخیره سازی لاگ ها در پایگاه داده ها بدین معنی است که دسترسی، تجزیه و تحلیل و نمایه آن ها بسیار دشوار می گردد. یک توسعه دهنده نمی تواند از ابزار لینوکس (مثل SED و غیره) برای پردازش و تحلیل لاگ ها استفاده کند. پروسه کند تر است و فضای زیادی از دیسک (گیگابایت زیادی ) را برای ذخیره سازی پایگاه داده اشغال می کند که موجب می شود سیستم پایگاه داده به کندی رشد کند و در نتیجه آن را ناکارآمد می سازد. برای یک سایت با ترافیک بالا بررسی و تجزیه و تحلیل لاگ ها تقریبا غیرممکن است. هم چنین نمی توان از Log rotation (فرایندی اتوماتیک است که لاگ ها را بر اساس تاریخ آرشیو می کند.) و آرشیو لاگ های قدیمی پشتیبانی کرد. اصلا هیچ عقل سالمی لاگ ها را در پایگاه داده ذخیره نمی کند. دروپال برای حل این مشکلات، syslog را معرفی کرده است، اگرچه syslog برای محیط های میزبانی مشترک توصیه نمی شود و شما باید بعد از طی مراحل بسیاری dblog را غیر فعال و به جای آن syslog را راه اندازی کنید.

  1. الگوهای طراحی

اولا، جوملا شی گرا است، اما دروپال بر پایه ی PHP4 قدیمی برنامه نویسی رویه ای (Procedural) است. (دوران سیاه PHP)

 

خواندن PHP4 در دوران سیاه

PHP

 خواندن PHP4 دراین روزها

 PHP4

دروپال این الگوهای طراحی را که قدیمی هستند و به عملکرد بد شناخته شده اند، پیاده سازی می کند:

  1. رویه ای (Procedural)
  2. Hooking

اما جوملا الگوهای طراحی مدرن و با عملکرد خوب را پیاده سازی می کند، که توسط بهترین چارچوب ها ازقبیل Symfony2، Zend، و زبان های برنامه نویسی سازمانی مانند جاوا (از جمله Struts و Spring) به کار می روند :

  1. شیء گرا، از جمله چند ریختی (Polymorphism) ، کپسوله سازی (Encapsulation) ، ارث بری (Inheritance) و غیره.
  2. MVC (مدل کنترل کننده نمایش)
  3. رویداد محور(Event Driven) ، رویداد اعزام ( Event Dispatcher) و بیننده ((Observer
  4. سینگلتون Singleton))
  5. کارخانه متد (Factory method)

برخی از الگوهای طراحی مانند الگوی DBAL (لایه پایگاه انتزاعی)، که بر اساس هر دو چارچوب پیاده سازی شده اند، در جوملا بهتر اجرا شده اند. DBAL در جوملا تقریبا به اندازه ی ORM (نقشه برداری در رابطه با شی) مناسب است. و اگر شما واقعا قصد دارید از ORM استفاده کنید، جوملا به راحتی با Doctrine ادغام خواهد شد.

پیاده سازی این شیوه های مدرن در نتیجه ی پیشرفت مستمری است که چارچوب جوملا و CMS در طول سال ها داشته اند. در حالی که دروپال رکود داشته است. این هم چنین نمایانگر ماهیت فعال جامعه جهانی جوملا است.

  1. معماری هسته

جوملا هسته ی بسیار منظم API دارد اما هسته ی دورپال به صورت رشته های در هم پیچیده است. معماری جوملا شبیه به درخت کریسمس و معماری دورپال مثل باکی بال است.

joomla       معماری هسته جوملا

wordpress معماری هسته دورپال

در جوملا یک ساختار درختی برای طبقه بندی محتوا دارید که تنه اصلی آن هسته ی جوملا است. این ساختار شاخه هایی (API) دارد که می توانید به آن شاخه ها (کامپوننت) و یا برگ های (ماژول ها یا ویجت ها) بیشتری اضافه کنید. بنابر این یک کامپوننت (کامپوننت ایجاد سطح دسترسی) می تواند افزوده شود و خود را با امنیت جوملا و عملکرد های مدیریتی محتوا یکپارچه سازد. و برای مثال یک شاخه، ممکن است زیرشاخه هایی داشته باشد و حتی ممکن است پلی به شاخه ی دیگری هم داشته باشد. اما در نگاه وسیع تر، رابطه ی حداقلی بین شاخه های کامپوننت های مختلف وجود دارد.

شکل معماری دورپال به صورت دایره بزرگی است که در سراسر سطح آن نقاط متعددی به نام ماژول وجود دارد که هنگام ساخت یک افزونه، شما می توانید آن را به یک یا همه ی این ماژول ها متصل کنید. این یکپارچه سازی تنگاتنگ به این معناست که همه ی عناصر با هم در ارتباط اند. این معماری ظرافت کم تری دارد و کیفیت کدِ هریک از مشخصه های سفارشی را کاهش می دهد. حفظ طولانی مدت و همیشگی از پیامد این نوع ساختار است.

دروپال برای پیاده سازی این معماری قلابی شکل از گزینه call_user_func و سایر روش های عملکردی پویای invocation / reflection استفاده می کند. این به معناست که اشکال زدایی دروپال کابوسی است که از ابزار مدرن اشکال زدا (debugger) استفاده می کند. اگر بخواهید بیشتر در مورد ابزار اشکال زدا بدانید، به بخش زیر مراجعه کنید: چگونه VIM و PhpStorm را توسط xDebug برای اشکال زدایی تنظیم کنید.

(اشکال زدایی یا debugging در نتیجه آزمایشی موفق انجام می شود یعنی هنگامی که ابزار آزمایش خطایی را کشف می کنند اشکال زدایی فرآیندی است که باعث  حذف خطا می شود. اگر چه اشکال زدایی فرآیندی پوشاننده است ولی تا حد زیادی هنر است.)

علاوه بر این، این به این معناست که شما نمی توانید در حین کدسازی از کلیک بر روی مشخصهmodern IDE استفاده کنید. همچنین اگر شما از PHP Storm و یا دیگر مشخصه های کاملا اتوماتیک و کنترل کننده IDE modern استفاده می کنید، دیگر همانند افرادی که چیزی در مورد نوع بازگشت از کارکردهای پویا نمی دانند، رفتار نخواهید کرد.

PHP Storm: PHP Storm یک محیط برنامه نویسی PHP ساده و هوشمند را که با هدف افزایش بهره وری توسعه دهنده ها تمرکز یافته و عمیقاً کدهای شما را درک می کند، ایجاد کرده و امکان تکمیل کدها را به صورت هوشمندانه فراهم می کند، مراجعه سریع و بررسی خطاها به صورت بی درنگ از ویژگی های این نرم افزار است که همیشه برای کمک به شما در شکل دهی کدها، اجرای واحد تست و یا اشکال زدایی شهودی آماده است.

۴. استاندارد های کد گذاری

هر زبان برنامه نویسی، دارای استانداردها و قوانین مربوط به خودش است که زبان PHP نیز از این قاعده مستثنی نیست. استانداردهای PSR که مخفف PHP Standards Recommendation هستند، استانداردهایی معمول در PHP هستند که اکثر توسعه دهندگان PHP از آن ها تبعیت می کنند. اما استانداردهای سری PSR ، استانداردهای لازم الاجرا نیستند و هرکسی می تواند آن ها را نادیده بگیرد و از استانداردهای خودش استفاده کند، اما از آنجا که استفاده از این استانداردها باعث یکپارچی کد های PHP خواهد شد، بنابراین استفاده از آن ها توصیه می شود. در حال حاضر ۵ استاندارد PSR از PSR-0 تا PSR-4 وجود دارد.

جوملا سازگار با PSR-1 است که چارچوبی را برای گسترش سفارشی سازی PSR-0 ارائه می دهد، با وجود این که هسته جوملا هنوز PSR-0 نیست. یک رابط کاربری PSR-3 و یک بارگذار خودکار(Autoloader) PSR-4 نیز در چارچوب جوملا ارائه شده است.

در حال حاضر دروپال سازگار به هر PSR استانداردی نیست، اما نسخه ۸ آن شامل PSR-0 خواهد بود.

عملکرد و کش کردن (Caching)

دروپال به طور متوسط در هر بارگذاری ۱۰۰ پایگاه داده ای را در صفحه، نمایش می دهد (برای صفحات ساده). به دلیل این موضوع و دیگر مسائل عملکردی مربوط به معماری قلابی شکل، همه چیز با حجم بالا و سنگین خلاصه و ذخیره سازی می شود که پیچیدگی بیشتر و نیاز به منابع (سخت افزار) بیشتری را موجب می شود.

جوملا سبک تر و بهینه تر است و یک هسته بسیار با سرعت دارد. حافظه پیشنهادی جوملا MB 512 است در حالی که در دروپال GB 2 است.

بیشتر استانداردها در این مورد که بدون ذخیره سازی، جوملا سریع تر است و فشردگی منابع کمتری از دروپال دارد، اتفاق نظر دارند. با این حال برخی استانداردها دروپال را زمانی که Caching آن روشن است، سریعتر در نظر می گیرند.

کش کردن (caching) جوملا نیز ساده تر و فشردگی منابع کمتری از دروپال دارد که باعث می شود جوملا آسان تر استفاده، به روز رسانی و سفارشی سازی شود.

زمانی که شما در دروپال Solr را برای تقویت عملکرد خود درمورد وب سایت هایی با پایگاه داده ای عظیم و شمار کاربران بالا در اختیار دارید، در جوملا Sphinx را که در کد ++C بومی (native) نوشته شده و سریع تر و راحت تر از Solr است، در اختیار خواهید داشت.

در جوملا نیازی به نصب Sphinx در بسیاری از وب سایت ها وجود ندارد، زیرا که جوملا سریع و به اندازه کافی قدرتمند است و قادر به کنترل پایگاه های داده ای بسیار عظیم و تحت ترافیک سنگین است. با این حال در مواقع لزوم، Sphinx می تواند موجب افزایش عملکرد گسترده ای در جوملا شود که چند بار سریع تر از بسته نرم افزاری Solr در دروپال است.

تمامی موارد بالا نشانه ای قوی بر خلاف باور رایج است. به این معنا که جوملا برای توسعه وب سایت های بزرگتر و پیچیده تر بسیار بهتر از دروپال است.

آن چه متخصصان انجام می دهند

یکی از وب سایت های معروف موفق جوملا linux.com است. افرادی که در linux.com مشغول به فعالیت اند، به نوعی وسواس در مورد کیفیت کد مشهورند و از بهترین و باهوش ترین برنامه نویسان می باشند. مهم نیست که چه تعداد وب سایت دولتی را می توانید در دروپال ذکر کنید ، واقعیت این است که linux.com بر روی جوملا مهم تر از همه آنهاست.

حقیقتی جالب اما اندکی خارج از بحث این که بنیاد لینوکس، یعنی سازمان حمایت کننده از linux.com، لینوس توروالدز (یکی از باهوش ترین برنامه نویسانی که در قید حیات اند)، کسی را که سیستم عامل لینوکس و GIT را به وجود آورده است، به کار گرفته است.

لینوس توروالدز در واقع یکی از چهار نفر نهایی در رقابت Geek Madness در مجله Geekwire می باشد که در حال رقابت در برابر آلبرت اینشتین، نیکولا تسلا، و آلن تورینگ است.

Geek Madnesshttp://www.geekwire.com/2013/geek-madness-final

در دفاع از دروپال، بنیاد لینوکس، دو مورد از وب سایت های کوچک تر دروپال (به عنوان مثال video.linux.com) را نیز به اجرا در آورده است. اما واقعیت این است که آنها برای عملکرد وب سایت های اصلی سنگین خود از جوملا (linux.com) و نه دروپال استفاده می کنند ، که این برای من نشانه مثبت بزرگی در طرفداری از جوملا است.

همچنین لازم به ذکر است که همکاران بنیاد لینوکس برای جوملا ۵ ستاره در نظر گرفته اند، در حالی که به دروپال تنها ۳ ستاره اختصاص داده اند.

از نظر تجاری

اگر چه دروپال بیشترین انعطاف پذیری را در اختیار وب مستر قرار می دهد، اما اجرای آن بسیار پیچیده است و منحنی یادگیری آن شیب بسیار تندی است. مشتریان نیاز به استخدام یک وب مستر کارشناس دروپال دارند و کاربران معمولی نمی توانند خودشان به سادگی روش استفاده از دروپال را مثل استفاده از جوملا فرا بگیرند. کنسول های اجرایی دروپال، در مقایسه با جوملا همانند کنسول یک جت جنگنده است.

جوملا از لحاظ جوامع متن بازِ (open source) حمایت کننده CMS، یک جامعه توسعه دهنده بسیار بزرگتری در مقایسه با دروپال دارد. این نشان می دهد که توسعه دهندگان متن باز کار بر روی جوملا را به کار بر روی میز کار دروپال ترجیح می دهند.

انتخاب دروپال حتی برای کسب و کار هم نامناسب تر است، زیرا که توسعه دهندگان با تجربه و با کیفیت دروپال سخت تر یافت می شوند و از توسعه دهندگان جوملا گران تر می باشند. توسعه دهندگان باتجربه کار بر روی جوملا را به دروپال ترجیح می دهند.

من هم از این قاعده مستثنی نیستم و دو پیشنهاد کاری با حقوق عالی را رد کردم، چون نمی خواستم دوباره درگیر سختی توسعه دروپال شوم.

دروپال می تواند در آینده بهبود یابد

با این همه نسخه جدید دروپال ۸ به زودی منتشر خواهد شد (هنوز هیچ تاریخ رسمی در مورد انتشار آن وجود ندارد) این نسخه بهبود قابل توجهی یافته و به بسیاری از مسائل ذکر شده پرداخته شده است. هسته دروپال دوباره طراحی و توسعه یافته است و قرار است که به میزان زیادی از چارچوب Symfony2 استفاده کند.

با این حال، تا زمانی که دروپال ۸ منتشر شود، دروپال حتی ارزش آن را هم ندارد که برای یک پروژه سیستم مدیریت محتوایی (CMS) سفارشی در نظر گرفته شود.

هنگامی که دروپال ۸ منتشر شد، مایلم دوباره دنیای دروپال را بررسی کنم و پروژه ای بر روی آن انجام دهم، اما کاملا مطمین هستم که تا آن زمان جوملا بهبود بیشتری یافته است. حتی ممکن است در آن زمان TDD به صورت کامل جوملا را پشتیبانی کند. (TDD یا توسعه آزمون محور بهترین روش توسعه در جهان است).

 نتیجه گیری

در پایان اگر شما هنوز هم در این مورد شک و تردید دارید، این را از یک توسعه دهنده باتجربه که هم با جوملا و هم دروپال کار کرده است، داشته باشید: جوملا است مسیر بهتری از دروپال است. و این بدون در نظر گرفتن اندازه و الزامات وب سایت صحت دارد.

مگر در مواردی که شما دلایل غیر حرفه ای داشته باشید. (به عنوان مثال کاربران من در حال حاضر به چگونگی استفاده از دروپال آگاهند) من همیشه جوملا را توصیه می کنم.

اگر جایی در اینترنت خواندید که دروپال برای پروژه های بزرگ و پیچیده بهتر از جوملا است، فورا مدارک و شواهد آن را بررسی کنید. آیا آن ها بر اساس جزئیات فنی به این نتیجه دست یافته اند؟ یا به سادگی تنها عقیده خود را بدون ارایه هیچ گونه مدرکی و یا ارجاعی به کد زیر بنایی CMS اظهار داشته اند ؟

بارها افرادی را دیده ام که معتقد بودند دروپال به خاطر قوی تر بودن و کارآمدی بیشتر بهتر است. این دلیل قانع کننده ای برای من نیست. زیرا وقتی که از همین افراد می پرسم که چه چیزی باعث کارآمدی و یا قوی تر بودن دروپال می شود، در حالی که پنج مزیت فنی جوملا را که در بالا گفته شد، بازگو می کنم، در پاسخ به آن ناکام می مانند.

مترجم: معصومه منصورنژاد

منبع: http://www.butterfly.com.au

یک نظر

  1. خیلی خوب بود. سپاس از شما

جوابی بنویسید

ایمیل شما نشر نخواهد شدخانه های ضروری نشانه گذاری شده است. *

*