7 reasons to upgrade from Drupal to Yii

    Based on Why I Love Drupal .
    Published at the request of JiLiZART (translation, as I understand it, also him).
    Original: erickennedy.org .



    The article is dated a year earlier, so that the time frame in the translation is saved.


    Drupal 7 will be released soon, so many organizations must decide whether they should upgrade from Drupal 5 or 6. Drupal is good if you create many sites and you need to create new sites quickly and quickly. without much writing code, or if you just need a blog on steroids.

    Working with Drupal is like living in a double-wide (house of cards), if you cannot afford a traditional house. If you have a site that was built on Drupal and grown enough to use the full time developers, then you need to migrate your site to the Yii PHP framework. (PHP haters can follow Onion and use the Django Python framework, although it will take more time, change of language and framework)

    I am the technical director of the sitewho switched from Drupal to Yii on April 30, 2010. At that time, when we were just discussing the transfer, it was difficult to find the right information, there were not even books about Yii. There were some references to switching from Drupal to Yii, but they didn’t contain enough data to keep me calm. I was worried that Yii might be slower than our highly optimized Drupal installation, so I decided to rewrite 20% of the core of our site (which gave us 80% of all the functionality) in 30 days. It would seem to be a great way to test the productivity and productivity of the framework, and if Yii does not give a result after a month of work, we can always go back to Drupal and transfer any new data back.

    Yii was much faster than our Drupal site with 150,000 nodes (each with a rewritten URL) and 50,000 visitors per day. Yes, we worked like crazy these 30 days (and the next 15), but it was worth it. We used to spend time that we used to catch and fix slow queries in Drupal when developing on Yii. The real benefits of Yii came later when we redesigned our site.
    With Yii MVC, we changed just 2 layout files against dozens in Drupal.

    I'm sorry that we did not cross a year earlier. Here is what we learned:
    1. Drupal is not the best way to start from scratch . Drupal's main selling point is “ Why make your own CMS?” " Like many web developers, I wrote all web applications from scratch (in 1999 and 2000 ) and appreciate the opportunity to focus on the unique business needs of the application, rather than writing my own code to process authentication, validation, SQL injection, etc.
      The company that I helped found in early 2007, there was a prototype site on Drupal, and I was ready to see what Drupal could do before dropping it for Ruby On Rails. The Ruby craze reminded me of the Java craze in 1997. I was an intern at WebEx competitorin 1997-99, which killed its productivity by starting to write its server in Java before the server hardware and VM optimizations allowing scalability. PHP has proven itself in remaking Friendster and on Facebook, and our users don't want to see fail whale if we run into scalability issues in Ruby.

      Of course, it is easier to start with Drupal than writing each line in PHP yourself. But, there are a bunch of PHP 5 frameworks started in 2008 and tested in 2009 . A PHP developer, starting to create a web application now (and continuing to work on the site in the future), will either choose a framework or start from scratch using PHP libraries (PECL or PEAR).
    2. If the Drupal framework, then only the Ruby Goldberg Machine will love it ( Machine that performs simple actions in a complicated way ). Drupal is designed to be extensible without much knowledge of PHP programming. It’s good if you just style a site with simple content or if you have a low traffic site. If you work full time writing modules to change forms and add functionality, you will spend more time suppressing the Drupal functionality that you do not need, rather than creating it on the framework. Yii has the opposite approach - you can use Ruby on Rails-like ORM if it is fast enough and optimize only 10% of the queries that you just need to rewrite to MySQL.
    3. Community-contributed modules are prone to featuritis ("fraud"?) And errors that result from excessive complexity.
      There are so many contrib modules for Drupal, and if you have full-time developers, you probably just decide how we did it, to assimilate some of the additional modules into your own. Modules for modifying and caching images in Drupal are a prime example. Since the modules are designed to solve common problems (so that they can work with an arbitrary number of other modules!), They include tons of functionality that you will never use. In our case, we need to make previews of several sizes, which we will get using ImageMagick. To do this, we had to include 4 modules, each with a bunch of PHP files: ImageAPI, ImageAPI for ImageMagick, ImageCache, and ImageCache UI, instead of the actual commands for creating thumbnails in 2 database tables. If something breaks when updating a part of the module chain, it will take a lot longer to find the reasons, instead of doing just what you need.

      Yii also has an extension for working with images (adapted from Kohana), but it includes functionality that we do not need (rotate! Flip!) And is complicated by the fact that it is designed to transparently switch between ImageMagick and GD (GD has file problems larger than 2MB ) Despite all this, it still does not allow you to resize images on the fly using a RewriteRule if the preview does not exist.
      So I just created an index.php file that processes RewriteRule requests on a server dedicated to images and sends a shielded shell command to convert directly to the binary. This means that these RewriteRule requests do not affect the index.php file of Yii, reducing the overhead and the time required to resize images and reset the cache. This is just one page on php that takes arguments that are passed in a single call to the binary, and it is much easier to support and test if ImageMagick is updated.
    4. Drupal contains PHP 4 baggage compatibility. Once, when I decided to take a look at PHP frameworks, I quickly realized that I only want 100% PHP5 OOP framework. You will not meet many people who claim that the hook system is superior to the OOP approach. Although Drupal 7 requires PHP5, like CodeIgniter 1.0 and other old PHP frameworks, they still carry a lot of compatibility. Who wants this baggage?
    5. Don't want Drupal 6 or 7 to slow down your Drupal 5 site? Don't want to deal with obsolete jQuery? For most sites, this is normal. We really care about speed, as Google and Microsoft have shown that users are more loyal to fast sites. In 2009, when Drupal 6 became stable, we were stuck on Drupal 5 because of measurable speed advantages. The problem is that Drupal 5 includes jQuery 1.0. You can install the contrib module, which patches jQuery to 1.2 (and updates the Drupal functions that reference it), but this version is also old. Forget about jQuery 1.3x and Drupal 5.
    6. The Drupal Field / (CCK) API in Drupal will drive you crazy, and this is part of the Drupal 7 core . Why use $ node-> ip when you can use $ node-> field_ip [0] ['value']. And if you want two different types of content to have a field with the same name, CCK will put them in its own table (content_field_ip) with amazing column names (field_ip_value). Of course, Drupal can understand this mess when a node loads, but it's not nice to look at it. MySQL queries need a lot of LEFT JOINs to process all additional CCK tables, and those unnecessary complex queries that end up too often in the slow query logs. I finally got tired of trying to optimize all these slow queries and I decided to get rid of CCK, which led me to PHP frameworks, and then to Yii.
      Migrating our data to Yii took the same amount of time as if we were getting rid of the CCK module while staying on Drupal. Nevertheless, we were able to start with a clean database without all those additional tables that Drupal uses for its internal needs. In our old database there were 173 tables, in the new 54.
    7. Drupal is much slower than Yii.

      Drupal is expandable if you cache ALL with memcached and APC on board and rewrite all slow requests. Caching is especially important if you use SEO addresses for all links, as each call to l () generates another database query. So, the average page has 50+ requests, compared to 3-5 in Yii. After the transition, our average download time decreased from 163ms to 63ms according to Google Webmaster Tools. Even better, Yii + APC is so fast that we don’t need to use memchached, simplifying code and operations.


    Our server statistics speak for themselves. For the same number of simultaneous requests from visitors (Apache processes), the use of the database and CPU went down. The memory usage remains roughly the same. Over the past year, our traffic increased by 60% to 1.5 million visits per month, while the load on MySQL fell by 66%

    image

    Also popular now: