Hacking the Core
Hacking EE core is OK. The CMS isn’t perfect. Just document your changes and carry on. #eecms
— Ryan Masuga (@masuga) April 29, 2012
Whether it was a homegrown hack or one we found somewhere to work around a limitation or bug in ExpressionEngine, we’ve all done it at some point. The thing with hacking the EE core files is this: if you hack it, you own it.
You own the responsibility for letting those that come after you know about the hack. If it’s your site or one you will always maintain (unlikely), then you own the responsibility to always re-patch the core files with your hack when upgrading to a newer version of ExpressionEngine.
Rob Sanchez had a good response and technique for making upgrading site with hacks a little easier (this is only applicable to people who use Git or other version control system):
@masuga do EE as submodule w/ a hack branch, then you can merge newer EE versions back in later. plus your diff is your document of changes.
— Rob Sanchez (@_rsan) April 29, 2012
If you hack the core EE files, where do you document those changes so developers that come after you can know about them?
Posted on Apr 30, 2012 by Ryan Irelan
Share on Twitter
Sean — 11:14 on 04.30.2012
I fortunately havne’t had the need to hack the core yet and hope I don’t have to. However in the event that it becomes a necessity then I’ll add the information to the site docs so that I or a future developer will know where to find the hack.
Am currently using Erik Reagans Dev Docs add-on for documentation.
Bj — 03:14 on 05.01.2012
On a large project I’m working on we have a folder called “patches” where we place all our core hacks (for the EE core itself or any third party addons used). These are .patch files which we run automatically after upgrading EE to apply the fix over again. If it fails we will investigate why it failed (maybe EllisLab has fixed that bug, or the source has changed so much that we have to create a new patch for it, etc.)
This allows us to find bugs, report them to EllisLab, but then quickly implement a fix ourselves without waiting for the next release - also ensuring that all team members get the fix on their local dev environments.
Of course in some cases our patches are feature requests that are never implemented by EllisLab, in which case the patch will follow us forever. The other patches are moved into a “historical folder” when they are no longer needed.
More info about patch files: http://laughingmeme.org/2004/02/18/how-to-make-a-patch-file/
Christopher Imrie — 09:30 on 05.01.2012
We’ve had situations whereby we’ve had to make multiple core modifications, but we always ensure its documented at the top of the config.php file since it is the file that is most likely to be looked at, and will always survive the update process.
The config documentation always includes the filepath, the line numbe, a description of the change made and why it was needed.
With the information laid out in the config, along with the code being version controlled in Git, we have never had problems in maintaining patches across EE upgrades.
Nateronn — 14:18 on 05.08.2012
This article is only highlighting part of the story.
The original tweet which started this conversation was linking to a hack (gist) which was done because the hacker didn’t want to spend the money for this “feature” via a commercial add-on. That’s understandable no? I think so!
However, after I saw the gist (and it’s comment) I did have to ask the tweeter/hacker if there was a reason they didn’t add this to an add-on (especially since ExpressionEngine provides such a great platform to do so versus core hacks and we already know there is a commercial add-on so, it’s been proven possible via the add-on route and even more reason for my curiosity.)
Okay, let’s ask my question the other way around this time: why use an add-on over hacking the core and documenting?
Hacking the core is quick, documenting is quick. You may say you are saving your client time. Maybe your client isn’t even paying you for this. Maybe this is your own site and if you die, your site dies along with you. Maybe placing your hack documentation in a *README.txt* file is so much easier than documenting an entire add-on. Maybe you don’t know how to build add-ons. You get the point, there are a number of possibly reasons for using the hack core route over an add-on. I get it!
So, that leads me back to my original question of why hack core versus building an add-on?
Maybe every other CMS out there has a *README.txt* file and maybe you, being new to EE, assume that’s a similar readme.txt file and completely over look it (shame on them for ass-uming?) Maybe you put your hack docs above root and I didn’t see them. Maybe your client, now my client asked me to update their site and you forgot to list every hack that you made because you were busy thinking about getting off work to go feed “Reggy Horse.” Maybe I understand how to use EE template/add-on tags though I’m new to PHP and don’t fully understand your hacks. Maybe I do understand PHP though, have to tell the client that this will take longer than expected as I need to un-hack first before upgrade(client then asks “my site has been hacked, when, where, what, how!?”) Maybe you and the client just had a falling out and you decided to delete all the hack docs as a final fair-well. Maybe…okay, I think you get the point, there are a lot of “maybe” this or that here.
Maybe hacking and documenting *is* okay, I don’t know. (And let me go on record right now to say that I hacked an add-on just last week!)
Publicly announcing core hacks and thinking that everyone will document as well as you do or did is very assuming in my opinion. I’m not saying don’t hack or get your hands dirty. And I agree getting the job done at the time it needed to be done is the right thing to do. What I am question is why this couldn’t be put into an add-on almost as easily to save someone from one of my “maybe” headaches I listed above? I understand the hacker is trying to help others by sharing said hack though, is that truly helping?
Good journalism tries to tell the whole story. Take what you will and or take none, I’ve added my piece.
th3mus1cman — 09:42 on 05.12.2012
I will generally put a .changelog file in the root of the site and notate any changes to EE, third party add-ons, or hacks for JS libraries.