Take the 2-minute tour ×
Magento Stack Exchange is a question and answer site for users of the Magento e-Commerce platform. It's 100% free, no registration required.

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?

share|improve this question
add comment

6 Answers 6

up vote 12 down vote accepted

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.

share|improve this answer
    
Neat! I did not know that. Do you know if this is part of the actual .patch — or does support do it manually? Or (probably?) both? Looking at some old .patch files and not seeing any changes to an applied.patches.list file. –  Alan Storm Jul 8 at 19:18
    
Self helped that that last one — the CE patches do this automated (see: magentocommerce.com/index.php/getmagento/ce_patches/…) –  Alan Storm Jul 8 at 19:20
1  
It appears (and @joshua-s-warren seems to confirm) that not all patch files are created equal. If we're "lucky" the patch will have this functionality built in. Here's a sample of one that has it: magentocommerce.com/index.php/getmagento/ce_patches/… It also only lists the files that changed and not the changes you'd have to try to track the patch to know what changed, even then there's no "guarantee" it was the same one used. –  beeplogic Jul 8 at 19:22
1  
Unfortunately most EE patches that we have got, don't have this functionality –  Allan MacGregor Jul 8 at 20:23
2  
All the patches distributed as .sh files, for SUPEE tickets should have this functionality (unless old ones). Surprised @AllanMacGregor you don't see it. Do you have an example of a patch that has been applied (SUPEE-number) but not listed? –  Piotr Kaminski Jul 8 at 21:24
show 1 more comment

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.

share|improve this answer
1  
With the github repository of magento versions, it's trivial to let git do the work. No custom hashing needed. Just add remote, fetch remote and git diff depot/master origin/master. The challenge is the .gitignore. Another option, is to clone the version into a seperate dir, then copy the sites' app/code/core directory over it. git diff -w will then tell you. –  Melvyn Jul 10 at 21:08
    
We did it this way because we're often testing this remotely on servers that don't allow us to install software and may not have git installed. In an environment where git is present though, you're right, you can use git diff. –  Joshua S Warren Jul 10 at 23:58
    
Ah yes, I see your point. In fact I'm gonna think about how to get something like this into magerun. –  Melvyn Jul 12 at 1:44
add comment

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.

share|improve this answer
add comment

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

share|improve this answer
1  
Agreed, but it's how to tell which is which after the fact. –  Alan Storm Jul 8 at 19:11
    
I would probably do a compare your compare on the base installation and then an additional compare against an install with each patch applied separately (or just the end result of all the patches applied). It's probably going to be a few order of magnitudes more work, but it's the only way I can think of. –  Josh Pennington Jul 9 at 0:18
add comment

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.

share|improve this answer
add comment

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.

share|improve this answer
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.