Confessions of a Core Modifier

Question

A few pertinent questions here:

• What's the best way to identify core changes and work them into modules? Is there a free alternative to http://www.fontis.com.au/mageaudit/ ?

• How about subversion/git pre-commit hooks to prevent commits to core files? Do you keep Magento core under source control at all?

• How does one prevent changes to core files by mistake -- perhaps a Sublime Text plugin that tells you if you're modifying a core file?

• Is it okay to copy core files to /local to inject a dispatch event for Observers?

...asking for a ...friend. Yeah.

Answer 1

I can't say we've ever gone to any lengths to prevent it - as we simply don't do it. Or worst case scenario (the underpant elves changed your core code) - you see it on the next Git commit that you issue.

But I guess there is a few ways to clean up/prevent it happening. So just to elaborate on your bullet points.

Finding modifications

Identifying changes is fairly easy, just download a clean equivalent release and perform a diff on the respective directories.

diff -r ./app/code/core ./clean_mage/app

You can find a more more guidance in the Magento debugging answer.

Preventing modifications

You could prevent edits to the core just by altering file permissions, make them read/execute only

chmod -R 555 ./app/code/core

Or go a step further and make them immutable

chattr +i -R ./app/code/core

Undoing modifications in real-time

If you are using Git, and your core is under version control, you could add a hook just to checkout the core prior to a commit

.git/hooks/pre-commit

#!/bin/bash
git checkout /home/path/public_html/app/code/core

Using local

Its a last resort really. The PHP include path (its not a Magento thing) will prevent you from being able to declare the same class twice.

Local > Community > Core

So the moment you add a class to local, the respective matching file won't be read from anywhere else. So you need to copy in the whole file contents.

For abstract/final classes - you don't have much of a choice, but for most other tasks, you can usually rewrite the class and bundle it into a module in community

Answer 2

Just an addition to Sonassi's post You can also use an SVN hook ( if you use svn ) to check read-only property and refuse to change files in certain folders

see this -> http://www.cita.utoronto.ca/~shirokov/soft/svn-hooks/svn-read-only/pre-commit

Answer 3

This is how I approach the same issues:

1. If I inherit a project that I suspect has core hacks, I will compare the files against vanilla Magento. I will sometimes do this when upgrading a store to a newer version. The following command is handy for comparing files in two directories:

   diff -rq magento-hacked magento-1.7ish | grep "Only in magento-hacked" > hacks.txt

2. I'm currently using SVN for a variety of reasons. I have vanilla versions of Magento set up in a repo. Each version is on it's own branch. For new projects, I include a chosen Magento branch as an SVN external. I use modman to package any extensions and themes into separate modules. Frequently used extensions can be included as additional SVN externals in my project. I only commit my IDE project file, modman directory and the store's etc directory (moved above httpdocs, path updated in index.php) to my project's repo.

3. By including a store's core files in an SVN external (with read only perms). I can't commit any changes to core files.

4. Don't copy the whole file (if possible). Extend the core class in local, and just copy the method you need to modify.

This is just my approach to these problems that suits both my own and my colleague's workflows.