Cancel commits on Magento core files with subversion hooks

As a best practice, it is not recommended to update Magento core files. This can be done by Magento overloading mechanism

This morning, an old colleague of mine mentioned that a developer committed some updates in the app/code/core files.

This could be blocked by subversions hooks scripts

What is a subversion hook?

Introduction to subversions hooks: the hook events

Subversion implement a hook mechanism which allows to call some externals scripts on some repository events. This functionality allows you to customize your repository work-flow. The most common hook usages are:

  • Sending email notification (on each commit, when a tag is done, …)
  • Control access to repository (when locking files, …)

List of available hooks events can be found in the subversion documentation

Hook event we’ll use to control our commit must be executed before transaction is completed: the pre-commit hook

What subversion does on a subversion hook event?

On this predefined event list, Subversion will check if there is an executable script in the hooks folder of your subversion repository with the name of the event

If yes, subversion user will call this script with some arguments. Arguments list sent to this script depends on the hook event. For example, for the pre-commit hook script, arguments are:

  • Full path to repository involved
  • Current transaction number
  • With these arguments, you can do what you want within, especially calling all the administrative subversion commands:

    • svnadmin
    • svnlook

    Setting up a subversion hook which cancels the transaction in case core files are updated

    Here’s an example of the script you can use as pre-commit hook for Magento projects

    #!/bin/bash
    ##################################
    # render more readable parameters
    ##################################
    REPOS="$1"
    TXN="$2"
    ################
    # configuration 
    ################
    # path to svnlook script
    SVNLOOK=/usr/bin/svnlook
    #############
    # librairies
    #############
    # a method to send message to client and end transaction
    show_error_message() {
        echo $1 1>&2;
        exit $2;
    }
    ###############################
    # run
    ###############################
    # fetch the account user from the current transaction informations
    AUTHOR=`$SVNLOOK author -t "$TXN" "$REPOS"`
    
    # check if we do not updating file in core files
    $SVNLOOK changed -t "$TXN" "$REPOS" | grep "^U \+app/code/core" > /dev/null
    if test $? -eq 0 
    then 
        show_error_message "$AUTHOR, You cannot update Magento core files" 2
    fi
    

    This script will look for files involved in current transaction with the svnlook script and look for path app/code/core in the output answer. (this svnlook command lists all files and their state in a transaction). If we find something matching, we send a message on the STDERR (STDERR will be sent to subversion client) and exit script with a non 0 error code, which will cancel the transaction and so block the commit

    To use it, just copy this script content in a hooks/pre-commit file of your repository folder and make it executable by the system

    Conclusion about usage of hooks on Magento scripts

    No more reasons to leave developers committing app/code/core files with this script!

    But you can extend hooks to do many other things on your repository: block Magento core files commit, block update on tagged versions, notifications of branch creation, block commit of PHP files which contains parse errors, etc…

    Do you use these events on your Magento repositories?

    Update Magento page structure by overloading the layout content

    There are many ways to update Magento page structure content: all lead to the same thing, a custom page, but not in the same ways. Each method has its own advantages and drawbacks.

    Within this topic we’ll overview overloading page structure by overloading native Magento layout files

    How to overload Magento page structure using loading mechanism ?

    All this process is based upon template loading mechanism which I explained before:

    • You define your design through back-office
    • You copy the Magento layout file to update in the layout folder of your custom design folder

    For example, if you want to overload Magento customer account page content, you can do it by copying the original customer.xml into your custompackage layout folder

    When Magento will be looking for the customer.xml file it will find yours before the default one: this is yours which will be used instead of the native one

    Very easy and quick method to update Magento layout…

    Advantages of updating Magento page content by overloading native layouts

    You are totally independent of the native page structure

    With this method, you are totally independent of the existing page structure: you can do what you want inside

    Quick way to update page structure content

    This is also the quickest way to update page structure: you’ve found which layout file contains the element you want to update, you just have to copy it and update it. No layout update definition, no new module to load to embed some update

    Code more clear

    Almost everybody knows now which files describe Magento page structure. Using this method makes the code reading easier: no many layout update to find which are involved in a page, this is our layout copy which is involved in your page. There are also less treatments to build your page because there are less files to parse to build your page

    Drawback of updating Magento page content by overloading native layouts

    Difficult to capitalize

    Your new layout page structure depends on the design applied. Even if you can add files of some specific packages in a Magento connect package, it’ll only work if the Magento has configured the same design: force users to use a specific value of design is a difficult choice and will make all other modules installation harder

    Difficult to maintain

    Creating a fork makes it more difficult to take advantage of developments that may contain Magento updates, and generally the community.

    Do you use this kind of method to overload Magento page structure?