Eight common drupal dev issues as memes
Many Drupal developers are facing the same comon or uncommon issues in their career developing projects in a larger team. This short article is illustrating just a few situations as memes I made today in a short period of time.
#1 Custom PHP Code in .tpl.php files
You did it. I did it. We all did it in our early days diving into Drupal. As Drupal is hard to understand being a novice, finding the correct way of doing things can be quite frustrating. I started developing with Drupal before handy modules like Display Suite made it easy to customize output of node elements, heck, there wasn't even a field api but instead a early version of the CCK Module and a buggy alpha version of Panels. I figured that manipulating templates in the theme would enable me to modifiy the output of a node. Years later, Display Suite, Panels and Views are doing much of the needed work and writing plugins is the way to go. But it also happens that developers are still stuck in the past and do not want to change their style of developing because they know there way around.
#2 and #3 - The mysterious cache
"Keep calm and clear the cache" is the most used phrase when hinting someone to find and fix a bug. Since the cache system is not only one cache but several cache tables like the menu cache for example, clearing the complete cache is most of the time not neccessary.
Another great example is the "White Screen of Death" (WSOD) which may happen when clearing the cache. This is most likely a hint that an error in the theme or a theme function is causing the site to fail. Developers should disable the cache when developing (except when testing the cache of course) to avoid WSOD when clearing the cache. A quick look in the log of the webserver is the best way to discover the root of evil.
#4 , #5 and #6 The Features module
The Features module is one of the most used modules we use as a developer. It gives us the possibilty to export most of the configuration in files to be able to use GIT or SVN to manage our code and deploy changes properly. Features is not easy to learn and not easy to use especially when working in a team. We at undpaul are used to work with features a long time ago since and have a great expertise how to structure our features. We are very strict when it comes to creating features and handling content types. Every content type has its own feature which includes fields, permissions and other configuration tied to the content type. We often see other developers packing all content types in one feature and naming it "Content-Type Feature". This is not a good usage and should be avoided since it is very frustrating working on one feature with many developers. Reverting and managing all changes is quite tough then.
Well, sometimes it happens that a feature needs to be reverted because the codebase is not matching the database. This happens when another developer made a change on the feature and you just pulled the latest develop branch from the repository. Sometimes, the Diff module is not able to show you the changes and you need to look into git to understand it. This can happen if there are a lot of changes when exporting blocks or menu items. A common reason is also using git merge on a feature with lots of changes, especially after solving a merge conflict.
This feels like a no brainer but is often forgotten when creating features: Export ALL permissions. When working on the features. Not afterwards. Believe me, you do not want to recreate 30 features and try fitting permissions into all features afterwards.
Git is a great tool for managing your Drupal installation and keeping your work with your colleagues in sync. The common workflow is using feature branches and merging changes back into the develop or stable branch after being properly tested. It may happen that after developing a feature, the merge back will fail because the codebase of the feature branch is too old and is way back from the develop branch. Developers then should rebase there branch with the current develop/stable branch. For more, see the git rebase manual: http://git-scm.com/docs/git-rebase
#8 Uploading a patch
When creating a patch for Drupal Core, the patch needs to be tested by a patchbot which automatically creates a testing environment and runs test against your patch. I believe I never submitted a patch which passed all the test in the first try because of stupid minor mistakes.
Well, these are 8 memes for now. Do you have experienced some of those situations or do you know more common drupal mistakes which should be illustrated? Drop a comment!