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

4 Answers

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 11 hours ago
    
Self helped that that last one — the CE patches do this automated (see: magentocommerce.com/index.php/getmagento/ce_patches/…) –  Alan Storm 11 hours ago
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 11 hours ago
1  
Unfortunately most EE patches that we have got, don't have this functionality –  Allan MacGregor 10 hours ago
1  
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 9 hours ago
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
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 11 hours ago
    
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 6 hours ago
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

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.