Patch or Core Hack

Question

When I'm on a system upgrade project, one of the things I do is diff a client's system against a fresh Magento installation. I'm looking for core hacks or additional files that aren't part of standard Magento to make sure I catch any shody-but-business-critical-work done by a previous freelancer, contractor, consultant, or agency.

One thing that always stumps me though is patches. Over the years Magento has issued "between-version" patches — usually to address a security fix, or a change in a shipping/payment vendor's API.

The problem is, from the point of view of a diff, patches are indistinguishable from core hacks — especially when you don't know which patches (if any) have been applied to the system.

Which leads to my question.

How do you differentiate between a core hack and a patch?

Answer 1

Magento patches supplied by support will append a log of sorts to app/etc/applied.patches.list. I don't know when or how long the patch "scripts" have been doing this. The CE patches also seem to do this.

Answer 2

This is something I deal with often (and I'm working on right now), and unfortunately, thus far it's a completely manual process - we have an automated process that flags every file that might be modified as part of our initial automated audit for a new support client. We then have someone diff those files, and rule out any obvious false positives (i.e., whitespace changes).

Then, the fun part - a senior member of our team who has been working with Magento for quite some time has to take a look at the results to determine if any of the modified files could be the result of a patch. We've looked at updating our system to check against all of the patches we're aware of/can get our hands on, and that might work for CE, but on EE it's even more challenging, since EE support does sometimes issue patches directly to clients that are never released any other way or cataloged in a consistent manner.

So, when we do this level of review, we rely on past experience applying these patches + common sense (i.e., is it just a change to an API's endpoint? If so, is that changed endpoint present in the updated version? If so, it was a patch and can be ignored).

It would be theoretically simple to apply all of the patches available on the CE download page, etc., to every applicable version of CE and check against those (FYI, we don't use diff for the first pass - we use hashing, in part because we built this technology into a tool that can remotely check on a site without needing to download it first). That would rule out a majority of the patches, but it still doesn't help for any CE or EE patches that aren't posted to the public download area for CE or the client/protected download area for EE. That would require Magento to make a consistent policy that ALL patches be made available to ALL customers, and get those posted to where we could get to them.

So, I don't think there's a way to 100% automate this until changes happen on the Magento side of things, unfortunately.

Answer 3

One way that I approached this when I was doing a lot of upgrades and trying to systematize the process was to actually commit the patches directly into your core code repository that you're using to diff against.

This actually has two benefits:

1. No more false positives showing up in your diffs.

2. Let's say that you have a site that doesn't have a certain patch. You might say that's a problem because it will show up as missing code in your diff even though technically they aren't missing anything as compared to a fresh unpatched download. But in fact, that they're missing a patch is actually a problem that should be resolved - so it's perfect that it shows up in your diff for you to fix along with the upgrade.

Answer 4

I don't think that having a Magento in your project repo is a good idea initially, in case if you manage more than 2-3 clients. Since it is always easier to mess up applied system patches with core hacks.

The best option, in my opinion, is to have a composer Magento repository mirror with version tags, that point to a particular Magento version with possible official patches applied.

Also it would make easier to maintain your own patches to files, like Mage_Core_Model_Config for high loaded websites and some others, by introducing their installment via composer with a version number that matches your Magento instalment.

So in this case your upgrade of all the customer projects to a patched Magento code will result only in version bump of your composer file. Also keeping project code apart from the core, will force your developers to not hack the core.

As for definition of patch and a hack, I would prefer to call it like this:

1. A change in original core file by official patch file - it is a patch
2. A change in original core file by your team - it is a hack.
3. A change in local copied core file for purpose of bug fix - it is a patch
4. A change in local copied core file to supply new functionality - it is a hack

So by moving core to a separate repo you will get make sure you have only patched version according to item 1. And you can easily install your own patches over composer into local code pool, so you have everything according point 3. In case of 2 and 4 you can create a git commit hook in project repo to prohibit any code commit into that dir.

Answer 5

I look to the applied patches file in that /app/etc/ folder and work backwards. But as I learned from upgrading I can just delete the file on a version that has the patched file in them and next time it's patched it's clean.

Answer 6

Anything from Magento I'd call a patch. Everything else is a hack.