Drupal a CMS to love or Hate
I have been working on a Drupal commerce website recently and I must say that drupal is a great tool. You can do so much with very little effort without touching any lines of code. The community provides thousands of modules which can be simple to install. There are many great principles behind drupal and it allows you to create a good website with very little effort.
If you wish to do something particular you can always create a new module and basically do anything. You will find plenty of tutorials online and there is plenty of helpful people.
Creating a module in drupal isn't that hard and you can achieve results very quickl. Some entities to store your data, a few views and a few template files to display the entity and you are rolling. Even if you are working on something more complicated like imports you can always use the migration module that once mastered can make you gain a lot of time.
But as you go on you will start to understand why I don't like drupal.
There are some basic reasons like it isn't OOP and the few places objects are use looks like crapy code? Well I can live with that. I can also live with the fact that it requires more memory to run then a operating system(slight exaggeration). Or that reloading a page takes more time then rebooting my PC(again I exagerate, if caches are built it is fine). I hate drupal because of small things like translations; the translations system is sketchy at it's best and there are a few places were they simply won't work.
I hate drupal due to the way it logs. Who's brilliant idea was to log stuff in the database? they probably never used tail command. On the same subject if you actually don't take care and pass wrong parameters to watchdogs you can crash the log page of drupal. That is simply hilerious. I know you can log in files as well but the organisation is still not top notch. But I must give credit to drupal, the fact that you can hook to watch dogs is great.
Staying on logs, drupal dosen't know what stack traces are. How can you debug an error in the core if you don't have the stack trace? I tell you how I do it when I can reproduce the error. I just edit the place where there is the error add a condition and add a my own stacktrace to display it on the front. I know I can use php xdebug, but it is a bit of an overkill. There is also the devel module that allows the stack trace to be displayed but sometimes it still doesen't so it isn't the solution.
Anyway in either case the error isn't logged properly which means if it happens on production we have no information about it.
Earlier I said how wonderful those community modules were but some of them aren't that well coded. So you start using them export a few part of them with features everything looks great but then you try and export a remote setting somewhere and it doesn't work. Either features don't find or it can't revert it properly. It is incredible the number of developers who reinvents the wheel making some interactions with the module impossible.
There are also all those modules that have some parts that don't translate or that breaks other stuff without you even noticing.
The other problem with those modules at work is that people see them and they say well there is a module doing nearly what I asked therefore it should be easy. Well they don't understand that it isn't necessarily easy. When you start trying to make a module do stuff they weren't built to make you will probably brake them. This is the case for all CMS and plugins. For some reasons I have the impression this is even more true with drupal because you don't alter the original codes design patter, you override what it did.
Another thing is the way you access the data, there are no normalization to make it easy, the solution entity_wrappers. Those classes are jokes, they help a lot but when you start changing stuff they don't always adapt well and requires you to add manual checks to see if stuff exist or no, those test aren't always that simple.
There is also the issue with iso prod environments. Well features are at their best a help, but not a solution. It is simple there are no solution. Features won't export everything and you will need to use the update hooks to fix your issues and wonder why you have such a BO if you need to code all those things. There are also cases were features will make you crazy because they will export stuff but not revert them back properly because some other manual changes prevents it. There are also those modules that for some strange reasons use their own tables to store data.
Finally I must say that coding for drupal can very quickly turn into a very big mess of hooks with dependencies you don't even realize. Keeping it clean is hard.
Also even through drupal allows a lot of flexibility it has a limit, and when you try and go beyond that you start doing crap or loos a great amount of time.
I will give an example, with a colleague we had a page view with some products on it and some facet. The data comes from the data indexed in solr. Everything worked fine, until we added a block on that page. The block was another view with another search on the indexed solr data but the constraints on the data of the block should be constant.
At first the issue seemed to be the facet affecting both views, a small configuration in the facet's global settings fixed that.
But that wasn't enough the facet generated their self based on the data of the first view and not the second one. The solution we were able to come up with was to change the order of our views. The block was placed in the before content, once moved after the content the facets were correct.
After quite some search the solution we came up with was to move the block to it's true position with Javascript. It works, it looks good, it doesen't affect performace as some other solutions proposed, but it is ugly and I have trouble sleeping with it.
Overall I think drupal is a great tool, but people must understand that there are limitations, each tool has some. Nothing is impossible but some very complicated stuff are very easy and within the reach of the tool, other that things that might look simple might take a lot of development and create a lot of frustration before being completed.
That said, I still think that there are better tools today for commerce website having lot's of custom components. Magento is one of them even if it doesn't offer the versatility drupal offers. It is better if you know how to code (Magento and a Blog?).
The main issue is we are in very tight budgets and the more custom code we do the more expensive it becomes, therefore for many projects the main objective is to have something that works and that has reasonable performances. My issue with this is the satisfaction, I spend huge amounts of time in the code of other people to understand and see if I can bend it to my needs. And quite often I find myself coding something I wish I hadn't. But before I know it there is another task ahead and I must keep on moving.
There must be a balance between what we do from scratch vs what we bend to our will. This is true for any project but even more so for projects based on a CMS.
I know I have gotten away from the Drupal subject towards the end, but what I said concerns drupal more then Magento and other technologies I have worked on because drupal has more modules and drupal modules are more often created for end users. Drupal s a bit lost between being a CMS & being a CMS framework. It offers to much stuff in BO, that should be in nice classes.
There are so many other things I hate about Drupal. If you wish to do a simple website gogo for Drupal, but if you intend lot''s of features and stuff, stop and think about it. That is my advice.