2. Why? What about “Don’t Hack Core!” Contrary to what some people say, Drupal is not a one size fits all Swiss Army knife. Not all uses cases can be accounted for. Flexibility does come at a cost. Usually performance. Have you used Pressflow? Some very popular modules justdon’t get maintained.
3. Examples User Module On user registration, wanted a way to generate simpler random passwords. Drupal (core or otherwise) does not provide any way to override the complex passwords it generates. No choice but to ‘alter’ (hack) core. Another issue involved bad performance on user login (without a patch – Pressflow has a variant but Drupal 6.x still slow). Comment module No index on the user id. Another module using the comment module referencing the user id made it very slow. No choice but to ‘alter’ (hack) the indexes made by core.
4. Best practices Check the issue queue! If its in there, try and work towards a patch. Use that patch until its part of the project. Otherwise, create an issue if its something that could benefit rest of Drupal and work towards a patch.
5. Best Practices (cont’d) Very simple Copy the module you want to override into your sites/all directory. Recommend creating a new directory called ‘core_modified’. Similarly for contrib, have a directory called ‘contrib_modified’. Add any changes you make into a patch file. Use diff on the command line or a program like Diffmerge (OSX) or winmerge (Windows) or Guiffy (all). Commit the patch file to your codebase. Will allow you to merge your changes anytime module gets updated. Once things in the affected module are officially fixed, you can move back to the core version.
6. DEMO Going to go over image module change http://drupal.org/node/1015916 If you try to enter data longer than 128 characters, site dies. Don’t know if the patch will get accepted. Lets dive in.
