Archives for : September2013

Setting up Magento development environment, step by step. Part 2: Underlying systems and processes

Posted by :Sven Varkel On : 30.09.2013
0

Category: Uncategorized

Tags:, , , , , , , , , , , , ,

Underlying systems and processes

Welcome back to Measure9 blog. Here I continue with article series “Setting up Magento development environment, step by step“. Please read Part 1, too. In this post I’m going to shed some light to surrounding processes and most low level tools. So we go from  general to more specific with each subsequent article in this series.

Development process

A quite generic Magento Development Process looks like that. It involves an Issue Tracking System (ITS) and Version Control System (VCS). Also unit testing is in place. If you’re really after quality and fun in development then I do recommend to set up Continuous Integration solution. There is quite a number of solution like Bamboo, Jenkins and others.

Magento Development Process

 

 

Version control process

Version control is something that should be in place even if you’re working alone. It helps you to keep your work organised, establish good working habits and integrate your work thru various environments and phases of a project’s lifecycle.

There is a number of Version Control Systems available. To name a few that you already may have heard of:

  1. GIT
  2. Subversion
  3. Mercurial
  4. CVS
  5. ClearCase

See more from Wikipedia. The first 3 are quite modern while CVS is an old dinosaur and ClearCase is a proprietary yet very powerful and integrated system by IBM. Anyway, my gut feeling says that GIT is most widely used nowadays and there are reasons for that.

GIT is

  1. distributed – you can work offline and still keep stuff under control
  2. fast – I mean it’s really fast:)
  3. easy to use, supports easy branching and merging
  4. last but not least – invented by Linus “The Linux Guy” Torvalds himself. Quality…

Now about the process itself (when git is used):

VersionControlProcessGit

Explanation from left to right:

When you start a project you do git clone (1). This gives you working folder with all project’s files. You do it once. Then, every day after your morning coffee you do git pull (2). Git pull gives you updates that have been pushed to upstream by other developers. After that you do git branch (3) if you haven’t done it already. This gives you isolated branch where you can mess around with the code any way you want. There is a number of branching strategies around, you need to choose what suits you best. There’s also a good example of a successful git branching model. Now you’re working with the code and you do git commit (4) (save code version to git). It’s recommended to keep commits small, I’d say atomic. Minimum one commit per fix or per issue from the ITS or per file. You’ll see that it’s good to keep commits small because when they day of rollback comes (and it will!) then you’d be grateful you did small commits that can be rolled back one by one. Then you feel that you’re ready to share your work with others. So you do git pull (5) again to retrieve latest changes from the remote and master branch. Then you merge (6) master branch into your named branch and if it’s cool (no merging errors) you’ll merge your changes back to master. Then you do git push (7) and share your work with others.

Some day (when I have time) I’ll add command line examples here, too.

Choosing hardware and installing operating system

Magento is a resource hog and thus good development hardware is a must. I’m personally using Macbook Air that has SSD permanent storage. It’s fast but standard MB Airs have only 4 gigs memory that is too little:( So you better get yourself a machine with following specs:

  • >= 8 GB RAM
  • >=128 GB SSD disk
  • A good (dual head) video card (for dual monitors)
  • A good keyboard
  • A mouse
  • A pair of good speakers (in case you’re working in your own room;))

Operating system

OSX and Linux are both good choices for Magento (or any web) development. For OSX there’s excellent package manager homebrew that gives you all necessary tools if you’re not satisfied with already built-in Apache web server and somewhat oldish PHP 5.3.

With Linux it’s simple – choose a distro that you like. My recommendation is Ubuntu or Debian. The both have APT package manager that satisfies all your needs.

Installation and configuration of tools will be covered in future posts.

Command line, Terminal application

One more thing is the terminal application. I think the the Linux’ defaults are good but there’s a better alternative for OSX’ Terminal.app and this is iTerm2. Install and use this one instead of native Terminal.app. It provides a few very good convenience functions like “copy when select” and similar.

Resolving Magento extension rewrite conflicts using traits

Posted by :Sven Varkel On : 14.09.2013
0

Category: tutorials

Tags:, , , , , ,

A bit of history

On 5th of September I sent out a tweet:

Guys, this is serious. I guess, I just resolved Magento’s single intheritance problem by using traits. Details later. #magento #worksforme.

Those who have been serious in hacking Magento and 3rd party extensions know well what I’m talking about. But please let me explain further.

Magento extension rewrite conflicts

You have a Magento instance. You have created a custom module My_Custom that happens to rewrite a core model, let’s say Mage_Catalog_Model_Product. So you have following lines in your module’s config.xml:

Then you have have a 3rd party extension that rewrites the same core class. You’re stuck now? Not quite. You now have 3 good methods to fix the problem. So good so far. But then you need another 3rd party extension that does the same – rewrites catalog/product. Now you’re stuck, right!?
You cannot make your code extend the 1st extension because the the second wouldn’t work and you cannot make yours to extend the second either because the 1st wouldn’t work then. Chicken and egg problem or “nokk kinni, saba lahti” as we say in Estonian.

The solution – PHP 5 feature “traits”

There’s a solution to PHP’s single inheritance feature and Magento rewrites that together make a problem. The solution is achieved by utilizing PHP 5.4 (or newer) feature called traits. So get a coffee (it’s pretty long post) and let’s start.
We have a situation where 3 classes want to rewrite and extend Magento’s Mage_Catalog_Model_Product:
My_Custom_Model_Product (this is mine that I can freely change)
Extension_A_Model_Product
Extension_B_Model_Product
Let’s say Extension_A_Model_Product adds the following methods to catalog/product:
And let’s assume Extension_B_Model_Product wants to add the following methods to catalog/product:
And at last my custom module wants to add something extra to the core product model:

The idea is to make only My_Custom_Model_Product to rewrite catalog/product or at least to be the first one selected for rewrites. The other 2 3rd party module classes would just extend it and be used inside my product model via traits.

Add dependencies to your module

First it’s necessary to add dependencies to your module XML. This is to ensure the loading order of classes and rewrites.

Add traits

Folder Traits should be created under extension’s folder in similar manner to Block, Product and Helper:
My/Custom/Trait.
For naming we follow the same logic as other Magento building blocks but there’s no shorthand for traits as it exists for blocks, models and helpers (e.g catalog/product etc). No worries, the trait would still be found and loaded by the autoloader.
Under that folder create the trait folders and files for classes Extension_A_Model_Product and Extension_B_Model_Product
My/Custom/Trait/Extension/A/Model/Product.php

My/Custom/Trait/Extension/B/Model/Product.php

Trait for Extension_A_Model_Product

Trait for Extension_B_Model_Product

Add traits to My_Custom_Model_Product

Voilaa!:) Now you have all the 3rd party module functionality available in your extension. When Magento is calling getModel(‘catalog/product’) it will actually load My_Custom_Model_Product. My_Custom_Model_Product extends Mage_Catalog_Model_Product and it also exposes all methods from Extension_A_Model_Product and Extension_B_Model_Product.

A note about traits

With traits you can avoid duplicating original class method implementation’s part. You’ll just create a proxy for original class method’s thru the trait. However you need to maintain the traits whenever Extension_A or Extension_B are upgraded or changed. So you should document it that you created traits and solved multiple rewrite problem this way. Then you can look up the documentation when doing upgrade to extensions next time.

As always – feedback is welcome!

Setting up Magento development environment, step by step. Part 1: Introduction

Posted by :Sven Varkel On : 08.09.2013
0

Category: tutorials

Tags:, , , , ,

Intro to article series

In this serie of articles I’m going to provide step by step instructions for setting up a fully working development environment for your Magento (or actually ANY PHP5) development project.
I start from the lowest level – from choosing the hardware and the article series will be finished with tips for tuning your Nginx, PHP5 and MySQL (MariaDB) to squeeze out the maximum performance that you need whole developing Magento.

About naming things

Here and there I call the database server as “MySQL” but what I mean is MariaDB 5.5.
Here and there I may call PHP5-FPM “PHP5” for the sake of shortness.
When I say PHP or PHP5 I mean the most recent version PHP 5.5.
OSX – I mean the current official version 10.8 Mountain Lion as of time of writing this post.
Linux – I mean Debian 7 – “Wheezy”.

Words of warning or The Disclaimer

First – nobody is (unfortunately:)) paying me anything to promote their software. All choices have been made based on my loooong experience in this industry and some research I’ve done before and during writing if this article series. I’ll try to provide some more justification of choices made under every section for every important component.
Everything described in this blog must be taken with caution. I mean – think twice (and measure 9 times!) before you put anything to production environments. I don’t take any responsibility or blame for data loss or loss of your job or whatever loss that may or may not be caused by following my instructions. In short – I write whatever I want and you’re the one that must think before executing anything written here. This is called “talupojatarkus” or “common sense” in Estonia🙂

Now when this is clear let’s get the hands dirty!

The structure of articles

I’ll give you instructions for 2 major development platforms – Linux and OSX. In general these 2 are perfect platforms for web development. One is free and open source while the other is commercial yet very good.  So you have choice.
The articles are organised like this where all major bullets are articles:

  1. Introduction (current article)
    1. A few words about suitable hardware
    2. No promises made but still … (planning following articles)
  2. Underlying systems and processes
    1. Development process
    2. Version control process
    3. Choosing hardware and installing operating system
    4. Remove unwanted stuff
    5. Command line, Terminal app
  3. Naming and structure
    1. Development folders
    2. Development hostnames (virtual hosts)
    3. Usernames, passwords
    4. SSH keys
  4. Components installation & configuration
    1. MariaDB
    2. PHP5-FPM
    3. Socket or TCP?
    4. Nginx
    5. a special file /etc/hosts
    6. Openssl for HTTPS
    7. keys, self-generated certificates
    8. optional – phpMyAdmin
  5. Source Code Version Control
    1. git …
    2. … or svn. No and why?
    3. Bitbucket
    4. Github
    5. Beanstalk
  6. Security
    1. Bind MySQL to localhost
    2. Keep your sites closed when in public WIFI-s
    3. Use HTTPS
  7. Installing Magento
    1. create database, db user and password
    2. file permissions
    3. special folders
    4. .gitignore
    5. useful utilities
  8. Choosing the IDE
    1. Netbeans
    2. PHPStorm
    3. Others (Komodo, Zend Studio)
  9. Setting up xDebug for debugging your solution
    1. “Local” remote debugger
    2. Breakpoints
    3. Call stack
    4. Variables
    5. Remote debugger
  10. Performance tuning, tips and tricks
    1. MariaDB
    2. Nginx
    3. PHP5-FPM
I leave myself freedom to make improvements to the topics while the serie is developing. 

A few words about suitable hardware

Currently I use Macbook Air with 4 GB RAM and I must say it’s too little. Magento is a big and hungry beast , all IDE-s are in hunger for more and more memory (Java!) and when you want to use xDebug then you’re pretty much stuck. So MB Air can almost do with SSD saving the day but my next machine will be something with 8 GB of RAM or more. I guess nobody’s talking about desktops nowadays any more, right? Still – an iMac is good choice in case you don’t need to move around to much. Since I do a lot of consultation and solutions architecture I have to be in the meetings and it would be a bit tedious to haul an Imac or – even worse – a PC with a monitor around, right…:) OK, I’m joking but in short – a good laptop is a good choice nowadays. Choose a PC laptop or a Mac laptop based on budget or whatever the reasons are – I’ll provide instructions for both.

No promises made but still …

As a busy guy I cannot make big promises but I’ll do my best to provide you a minimum 1 article a week. Hopefully I can do better than this. Feedback is very much appreciated as my ultimate goal is to develop a solution that would be kind of standard for all Magento development projects that are yet to be launched. So all help and feedback and comments are welcome.

Provide feedback

Here’s the first request to you, dear readers – please provide your wishes in the comments about what you’d like to read about in this serie or if there’s anything important that I forgot from the TOC. Thanks!