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 his).
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 have to decide whether they need to upgrade from Drupal 5 or 6. Drupal is good if you make a lot of sites and need to create new sites quickly and without much writing code, or if you just need blog-on-steroids.

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

I am the Technical Director of the site that moved from Drupal to Yii on April 30, 2010. At the time when we were still discussing the transfer, it was difficult to find suitable information, there were not even books about Yii. There were several references to the transition from Drupal to Yii, but they did not 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 the whole functionality) in 30 days. It would seem a great way to check the productivity and performance of the framework, and if Yii does not work after a month of work, we can always go back to Drupal and transfer back any new data.

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 for these 30 days (and the next 15), but it was worth it. The time that we used to spend on catching and fixing slow queries in Drupal, we are happy to spend developing on Yii. The real benefit from Yii came later when we redesigned our site.
With Yii MVC, we changed only 2 layout files against several dozen in Drupal.

I wish we had crossed the previous year. Here is what we learned:

1. Drupal is not the best way to start from scratch . The main selling point of Drupal is “ Why make your 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 handle authentication, validation, SQL injections, etc.
   The company, which I helped found in early 2007, had a prototype of a Drupal site, and I was ready to see what Drupal can do before dropping it for Ruby On Rails. Ruby's craze reminded me of Java in 1997. I was an intern at WebEx competitor in 1997-99, which killed my productivity by starting to write my server in Java before server hardware and VM optimizations allow us to scale. PHP showed itself when remaking Friendster and on Facebook, and our users don’t want to see fail whale if we run into Ruby scalability issues.
   
   Of course, it’s easier to start with Drupal than to write 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 build 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 Ruby Goldberg Machine will love it (A machine that performs simple actions in a complex way ). Drupal is designed to be extensible without much knowledge in PHP programming. This is good if you just stylize a site with simple content or you have a little visited site. If you are working full-time writing modules to change forms and add functionality, you will spend more time suppressing Drupal functionality that you don’t need, rather than creating it in a framework. Yii has the opposite approach - you can use Ruby on Rails-like ORM if it is fast enough and only optimize 10% of the queries that you just need to rewrite in MySQL.
   
3. Community-contributed modules are prone to featuritis ("fichemania"?) And errors that are the result of excessive complexity.
   There are so many contrib modules for Drupal, and if you have full-time developers, you probably just decide, as we did, to assimilate some of the additional modules into your own. Modules for modifying and caching images in Drupal are a prime example. Since 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 thumbnails of several sizes, which we 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 is broken when updating a part of the module chain, it will take much longer to find the reasons, instead of doing only what you need.
   
   Yii also has an extension for working with images (adapted from Kohana), but it does not include the functionality we 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 resizing the image on the fly using the RewriteRule if the thumbnail does not exist.
   So I just created an index.php file that processes the RewriteRule requests on a dedicated server for images and sends a screened shell command to convert the binary directly. This means that these RewriteRule requests do not affect the index.php Yii file, reducing the overhead and time required to resize images and flush the cache. This is just one page on php that accepts arguments that are passed in one call to the binary, and it is much easier with support and testing if ImageMagick is updated.
   
4. Drupal contains baggage PHP 4 compatibility. Once, when I decided to take a look at the PHP framework, I quickly realized that I wanted only 100% of the PHP5 OOP framework. You will not meet many people who claim that the procedural 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 compatibility baggage. Who wants such baggage?
   
5. Do you want Drupal 6 or 7 to slow down your Drupal 5 site? Don't want to deal with outdated jQuery? For most sites, this is normal. We really care about speed, as Google and Microsoft have shown that users are more loyal to faster 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 that 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 API fields / (CCK) in Drupal will drive you crazy, and this is part of the core Drupal 7 . 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 delightful column names (field_ip_value). Of course, Drupal can understand this mess when the node is loaded, but it is not beautiful to look at. 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 logs of slow queries. 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.
   Migration of our data to Yii took as much time as if we were getting rid of the CCK module while remaining on Drupal. Nevertheless, we were able to start with a clean database without all the additional tables that Drupal uses for its internal needs. In our old DB there were 173 tables, in new 54.
   
7. Drupal is much slower than Yii.
   
   Drupal is extensible if you cache ALL with memcached and APC aboard and rewrite all slow queries. Caching is especially important if you use SEO addresses for all links, since each call to l () generates another database query. So, the average page has 50+ queries, compared to 3-5 in Yii. After the transition, our average download time was reduced from 163ms to 63ms in accordance with 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. Memory usage is about 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%