How to validate Magento configuration values format?

Magento provides a very easy way to use API to set up configurations values. But really often, in additionnal packages you may develop, expected format is not checked before submitting configuration. You added a text field to allow entereing a webservice URL and can enter only numerics in this field ? Why ?

How to set up a validator for my configuration text field?

This is very easy: we must only add the appropriate css class to our configuration field. All is done in the system.xml file. Take a look at the example: Here’s an example in Magento configuration which validates a field value as an email value:

If we provide an unexpected value, we have an error before submitting post:

Here’s an example of an email format validation for the trans_email/ident_custom1/email configuration value: we must only define <validate> XML node and set up the validation class we want for our field

After rendering, we have the following output:

A new css has been added to our input field. Before submitting, Magento will check this CSS and run the appropriate validation.

It’s fine isn’t it? But how can we define our validator?

Embbeded configurations values validator in Magento

First, let’s look at the embedded validators. They are numerous. You can fiund them in the js/prototype/validation.js file

  • validate-select
  • required-entry
  • validate-number
  • validate-digits
  • validate-digits-range
  • validate-alpha
  • validate-code
  • validate-alphanum
  • validate-street
  • validate-phoneStrict
  • validate-phoneLax
  • validate-fax
  • validate-date
  • validate-email
  • validate-emailSender
  • validate-password
  • validate-admin-password
  • validate-cpassword
  • validate-url
  • validate-clean-url
  • validate-identifier
  • validate-xml-identifier
  • validate-ssn
  • validate-zip
  • validate-zip-international
  • validate-date-au
  • validate-currency-dollar
  • validate-one-required
  • validate-one-required-by-name
  • validate-not-negative-number
  • validate-new-password
  • validate-greater-than-zero
  • validate-zero-or-greater
  • validate-cc-number
  • validate-cc-type-select
  • validate-cc-exp
  • validate-cc-cvn
  • validate-ajax
  • validate-css-length
  • validate-length
  • validate-percents
  • validate-cc-ukss

Very interesting list isn’t it?

Can we use multiples validators for one field?

The answer is yes. If we check the class which convert your system.xml in a pretty form (Mage_Adminhtml_Block_System_Config_Form), this class takes the <validate> field content and appends its value to the CSS class field.

So if you want to add multiples validators to one field, you must separate them by one space

Limitations of validation usage in Magento admin configuration panel

The problem is that we can’t do what we want with the validate XML node:

Only some validators can be used to administrate your configuration values

Yes it’s a shame, but you cannot use all the validators listed above when you set up an administrable configuration value: You can only used those which take one parameter. I let you check which one you can use in admin. The other ones are used in templates and more expected parameters are provided manually

Define its own validator

Damned, my validator is not in the embedded list. I have to define my own validator. No problem, it’s very easy; I’ll take for example what I’ve done for the criteo module MExplained_Criteo (published soon) to validate some Criteo specific variables

Write it’s own validator

Here’s what I’ve done to define my own validators:

First, all these validators must have the following syntax: an identifier, an error message if field value doesn’t validate, and a function which runs the validation.When done, they must be added to global Validation javascript object (loaded by Magento). When javascript is loaded in the page, these validator definitions will be added to the available validation methods and so can be used in submission form if they are defined

Load validator in config admin page

So we just need to load our javascript file in admin configuration page. Very easily with layout:

With that, we have defined our specific validators, loaded them in configuration page and we have provided their usage in our system.xml file. It should work fine 🙂

Just note that you cannot load your new validations methods only for one section or group: if you load js with layout syntax, your new validators can be used in each section / group

Conclusion

Don’t forget to organize correctly your code: if you define some generic validators, perhaps it could be interesting to organize them in one dedicated module to ensure that you can reuse them when you want

This is the client side validation. This does not do the server-side validation. I’ll probably do a little post on this subject in the next few weeks. But with that, we should have the expected submitted data format

Yes I agree with you, these validations are not mandatory. But it improves your administrative panel no? And honestly, how long do you take to write a validator and load it? 5 minutes? 10? Is it comparable to the time spent to resolve a support ticket linked to a wrong configuration value?

Using libmemcached in Magento with versions before CE 1.6 / EE 1.11

My feedback is that it’s easily possible. Here’s the requirements

Summary of the cache usage in Magento

First remember how cache management in Magento works : Magento has the advantage to allow to choose your cache storage model. Some are better with only one server, others are better when you use many web servers. You can easily set up your cache management with your own requirements only by updating your local configuration file app/etc/local.xml: you have a template of configuration node you require to configure a specific cache storage management, located in the app/etc/local.xml.additional

Here’s a screenshot of the configuration you can set up to change your cache engine:

What is the interest of using libmemcached in Magento?

This extension is more up to date according with memcached server and so, provides enhanced functionnalities and fix than in php_memcache_extension

How to setup libmemcached as cache storage in Magento versions before 1.6?

All cache storage engine are those embedded in Zend Framework. But prior to Zend Framework 1.11 version, libmemcached backend was not embedded.

Do I need to upgrade Magento Zend Framework to enable libmemcached usage?

The first question we can ask is: “Ok, libmemcached is embedded in ZF 1.11 but not in my magento’s version. Do I need to upgrade all ZF to embedded libmemcached?

Answer is no: we do not need to upgrade all ZF in your Magento version, for multiples reasons:

  • ZF Cache API has not change its signature: so even if we add a new backend, we do not need to upgrade all ZF
  • Upgrading all ZF can have many other effects like in form build for example: upgrading ZF is not a simple operation which requires expertize

So ok, we do not need to upgrade all ZF. But how to?

How to install libmemcached support in Magento?

Well, for now, we know that Cache API has not change. So we need to do only the following things:

  • Add libmemcached support to our Magento
  • Allow to use libmemcached in our Magento

Add libmemcached support on our Magento

We just need to provide a libmemcached backend support. Nice, recent ZF versions have one. We can use it 🙂 But where do I put it? In lib/Zend/Cache??? no, please, use the overloading mechanism embedded in Magento and copy it in local folder

Ok, with that, our Magento has a backend able to communicate with libmemcached

Allow libmemcached support in Magento configuration

For the moment, if we update our local.xml to enable libmemcached support, we can’t use it: our new backend is not known by magento


We just have to allow libmemcached loading in this class (by a clean overload 🙂 ), and we will able to use libmemcached.

Conclusion

For now, even if libmemcached is in a beta state we can use it. My first tests are fine on Magento for cache storage, but I add exception for session storages.

The only thing we can regret is that automatic cleaning is not always available in libmemcached…

Magento modules versions

If you produce some modules for Magento connect, you have perhaps test your modules under differents releases.

In major and minor upgrades, you know that there is some upgrade in code source and so, if you want to have only one module version instead of using branchs, you must test in which case you are.

I’ve made here a summary of available module versions defined from 1.3 to current version (1.5 when I wrote this post), and for the related enterprise versions.

Magento core module versions summary

CE 1.3.2.4
CE 1.3.3.0
CE 1.4.0.1
CE 1.4.1.0
CE 1.4.1.1
CE 1.4.2.0
CE 1.5.0.1
CE 1.5.1.0
EE 1.6.0.0
EE 1.7.0.0
EE 1.8.0.0
EE 1.9.0.0
EE 1.9.1.1
EE 1.10.0.1
EE 1.10.0.2
EE 1.10.1.1
EE 1.11.0.0
Enterprise_AdminGws
Enterprise_Banner
Enterprise_CatalogEvent
Enterprise_CatalogPermissions
Enterprise_Cms
Enterprise_CustomerBalance
Enterprise_CustomerSegment
Enterprise_Checkout
Enterprise_Customer
Enterprise_Eav
Enterprise_Enterprise
Enterprise_GiftCard
Enterprise_GiftCardAccount
Enterprise_Giftregistry
Enterprise_GiftWrapping
Enterprise_ImportExport
Enterprise_Invitation
Enterprise_License
Enterprise_Logging
Enterprise_PageCache
Enterprise_Pci
Enterprise_Persistent
Enterprise_PricePermissions
Enterprise_PromotionPermissions
Enterprise_Reminder
Enterprise_Reward
Enterprise_Rma
Enterprise_SalesArchive
Enterprise_Search
Enterprise_Staging
Enterprise_Targetrule
Enterprise_Pbr/idge
Enterprise_WebsiteRestriction
Mage_Admin
Mage_Adminhtml
Mage_AdminNotification
Mage_AmazonPayments
Mage_Api
Mage_Authorizenet
Mage_Backup
Mage_Bundle
Mage_Catalog
Mage_CatalogIndex
Mage_CatalogInventory
Mage_CatalogRule
Mage_CatalogSearch
Mage_Centinel
Mage_Checkout
Mage_Cms
Mage_Compiler
Mage_Connect
Mage_Contacts
Mage_Core
Mage_Cron
Mage_Customer
Mage_Dataflow
Mage_Directory
Mage_Downloadable
Mage_Eav
Mage_Giftcert
Mage_GiftMessage
Mage_Giftregistry
Mage_GoogleAnalytics
Mage_GoogleBase
Mage_GoogleCheckout
Mage_GoogleOptimizer
Mage_ImportExport
Mage_Index
Mage_Install
Mage_Log
Mage_Media
Mage_Newsletter
Mage_Ogone
Mage_PageCache
Mage_Page
Mage_Paygate
Mage_Payment
Mage_Paypal
Mage_PaypalUk
Mage_Persistent
Mage_Poll
Mage_ProductAlert
Mage_Rating
Mage_Reports
Mage_Review
Mage_Rule
Mage_Rss
Mage_Sales
Mage_SalesRule
Mage_Sendfriend
Mage_Shipping
Mage_Sitemap
Mage_Tag
Mage_Tax
Mage_Usa
Mage_Widget
Mage_XmlConnect
Mage_Weee
Mage_Wishlist
        0.0.11.11.0.0
        1.6.0.0.41.11.0.0
        0.0.61.11.0.0
        0.0.80.0.91.11.0.0
        1.6.0.0.41.6.0.0.91.11.0.0
        0.0.111.11.0.0
        0.0.81.6.0.01.6.0.0.11.11.0.0.2
1.8.0.0.01.11.0.0
           0.1.10.1.21.11.0.0
1.11.0.0
        0.0.21.11.0.0
        0.0.80.0.91.11.0.0
        0.0.131.11.0.0
           1.9.0.0.41.9.0.0.51.11.0.0
1.10.0.0.81.11.0.0
1.11.0.1
        0.0.31.11.0.0
1.7.0.0.01.11.0.0
        0.2.20.2.31.11.0.0
         1.6.0.0.01.11.0.0
        0.0.30.0.41.11.0.0
1.0.0.0
1.11.0.0
1.11.0.0
1.8.0.0.01.11.0.0
         1.7.0.0.141.7.0.0.151.11.0.0
1.11.0.8
1.7.0.01.11.0.0
1.8.0.0.01.8.0.0.21.11.0.0
        0.1.151.11.0.0.1
        1.6.0.0.11.6.0.0.21.6.0.0.31.6.0.0.41.11.0.0
           1.8.0.0.0
        0.0.11.11.0.0
0.7.10.7.21.6.0.0
0.7.1
1.0.01.6.0.0
0.1.20.1.21.6.0.0
0.8.11.6.0.0
0.0.10.0.11.5.0.0
0.7.01.6.0.0
0.1.70.1.110.1.120.1.130.1.140.1.100.1.110.1.120.1.130.1.141.6.0.0
0.7.691.4.0.0.211.4.0.0.281.4.0.0.381.4.0.0.431.4.0.0.441.4.0.0.141.4.0.0.181.4.0.0.261.4.0.0.331.4.0.0.381.4.0.0.431.4.0.0.441.6.0.0.5
0.7.101.6.0.0
0.7.50.7.80.7.50.7.81.6.0.0
0.7.70.7.80.7.100.7.80.7.101.6.0.0
0.7.60.7.71.6.0.0
 1.4.0.0.0  1.4.0.0.01.6.0.0
0.9.30.9.50.9.40.9.51.6.0.0
0.7.80.7.130.7.120.7.131.6.0.0
0.1.01.6.0.0
1.4.01.4.01.6.0.0
0.8.01.6.0.0
0.8.130.8.260.8.270.8.280.8.140.8.250.8.260.8.270.8.281.6.0.1
0.7.11.6.0.0
0.8.111.4.0.0.61.4.0.0.71.4.0.0.131.4.0.0.141.4.0.0.41.4.0.0.61.4.0.0.71.4.0.0.121.4.0.0.131.4.0.0.141.6.0.0
0.7.41.6.0.0
0.8.50.8.100.8.110.8.80.8.100.8.111.6.0.0
0.1.140.1.161.4.0.11.4.0.21.4.0.30.1.161.4.0.11.4.0.21.4.0.31.6.0.0.1
0.7.130.7.150.7.160.7.150.7.161.6.0.0
0.7.0
0.7.20.7.60.7.20.7.61.6.0.0
0.1.00.1.0
0.7.01.6.0.0
0.1.10.1.20.1.10.1.21.6.0.0
0.7.30.7.40.7.30.7.41.6.0.0
0.1.21.6.0.0
0.1.00.1.01.6.0.2
  1.4.0.21.6.0.0
0.7.0
0.7.60.7.71.6.0.0
0.7.01.6.0.0
0.8.00.8.20.8.30.8.10.8.20.8.31.6.0.0
         0.0.1 0.0.1 1.6.0.0
1.5.0.0.0         
0.7.01.6.0.0
0.7.00.7.11.6.0.0
0.7.01.6.0.0
0.7.20.7.41.4.0.11.4.0.20.7.20.7.41.4.0.01.4.0.11.4.0.21.6.0.0
0.7.01.6.0.0
1.0.0.0
0.7.21.6.0.0
0.7.21.6.0.0
0.7.21.6.0.0
0.7.70.7.101.6.0.0
0.7.40.7.60.7.50.7.61.6.0.0
0.7.01.6.0.0
0.8.01.6.0.0
0.9.380.9.390.9.561.4.0.151.4.0.211.4.0.250.9.440.9.561.4.0.81.4.0.171.4.0.21.4.0.251.6.0.3
0.7.70.7.121.4.0.0.41.4.0.0.60.7.90.7.121.4.0.0.41.4.0.0.61.6.0.0
0.7.20.7.40.7.30.7.41.6.0.0
0.7.01.6.0.0
0.7.21.6.0.0
0.7.20.7.50.7.70.7.30.7.50.7.71.6.0.0
0.7.80.7.111.4.0.01.4.0.10.7.100.7.111.4.0.01.4.0.11.6.0.0
0.7.00.7.11.6.0.1
  1.4.0.0.01.6.0.0
1.4.0.131.4.0.131.6.0.0
0.131.6.0.0
0.7.40.7.70.7.80.7.90.7.50.7.70.7.80.7.91.6.0.0

Magento module versions usage

In previous Magento versions, there was some source code updates but no update in module version. So use module version carrefully

I'll upgrade this listing frequently

Magento connect: the worst and the best

Introduction to Magento connect

Magento connect is the module’s repository for the Magento community.
Wether they’re free or offered with a commercial licence, you will for sure find here what you’re looking for.

The modules available here affect as well the translations, the themes, or features enrichment of Magento.
It gathers today more than 2,000 modules.

With one click, you’ll be able to setup this wonderfull feature your were dreaming of to be on your Magento and that will save you precious days of developpement :no need to read every code line, to have access to your environment sources, one click and the dream’s here…
But sometimes it turns out into a nightmare…

Magento connect, the worst…

Magento connect: Production or test?

Magento connect is a setup system based on the PHP Pear library.

During the setup of one of my Magento, I once went wrong in the repository I wished to consult with the Pear setup : it so listed the packages available on the Varien core repository.
I was expecting to see the entire list of packages from the Magento connect administration interface. They were here, that’s for sure, but they were not the only ones hosted in this repository : a countless number of packages looking like testing packages were there in this repository too. Here’s the available list in 2011, May.

  • Blah
  • Channel_Test1
  • Core_Test
  • dfg56456
  • dsdsdssdfdsf
  • e
  • Find_Feed
  • Interface_Frontend_Blank
  • Interface_Frontend_Default_Blank
  • Interface_Frontend_Default_Default_Blue
  • Interface_Frontend_Default_Iphone
  • Interface_Frontend_Default_Modern
  • joejoe
  • Lib_Google_Checkout
  • Lib_Js_Calendar
  • Lib_Js_Ext
  • Lib_Js_Mage
  • Lib_Js_Prototype
  • Lib_LinLibertineFont
  • Lib_Phpseclib
  • Lib_ZF_Locale
  • Locale_Mage_Core_da_DK
  • Locale_Mage_Core_de_DE
  • Locale_Mage_Core_fr_FR
  • Locale_Mage_Core_no_NO
  • Locale_Mage_Core_th_TH
  • Magento_Extension_Test_3
  • Magento_Mobile
  • Magento_Mobile2
  • Mage_All_Latest
  • Mage_AmazonPayments
  • Mage_Checkout
  • Mage_Chronopay
  • Mage_Compiler
  • Mage_CoreTest
  • Mage_Core_Adminhtml
  • Mage_Core_Modules
  • Mage_Cybermut
  • Mage_CybermutExt
  • Mage_Cybersource
  • Mage_Downloader
  • Mage_Eway
  • Mage_Flo2Cash
  • Mage_Ideal
  • Mage_Ogone_Official
  • Mage_Oscommerce
  • Mage_Paybox
  • Mage_Protx
  • Mage_Strikeiron
  • Michael_Test
  • Michael_Test2
  • Mobile_Admin_Panel
  • My_Magento_Extension_Test
  • new1
  • new3
  • new_extension1
  • Old_Core
  • patsanchik_com
  • Phoenix_Moneybookers
  • rondatatest2
  • rtyrtyyrt
  • sadasdasd
  • sample name
  • Sample_WidgetOne
  • Sample_WidgetOne-0_0_1
  • Sample_WidgetTwo
  • sdfdsf_dfdfd
  • show_maintainers2
  • Snowcore_CommunityTest
  • Snowcore_CoreRedesign2
  • Snowcore_CoreRedesign3
  • Snowcore_Includepath
  • Snowcore_Newpacktest
  • Snowcore_RssReader
  • test123bbk
  • test3
  • testets
  • testing
  • testi_m_trying__but_some_idiots_in_the_yard_dont_want_me_
  • test_-_Jan01
  • test_1
  • Test_Extension_By_Alok_Just_For_Fun_Yeah
  • test_extension_one
  • tet
  • ttt
  • volik_test
  • Xml_Connect

As a consequence we’re free to ask how setup tests are done…

These are to my opinion historic sources, but honestly, they have nothing to do on a production environment.

I guess one day the channel will be cleaned, but I made this remark to myself more than one year ago, and regrettably it still hasn’t been corrected.

An “Apple Store” model type

Extensions offered on Magento connect are distributed under two kind of licence: commercial or community. The community kind is free of rights, whereas commercial extensions may be sold as a payable product.

Unfortunately, it’s not yet possible to try the payable extension within your project context : you have to buy it first.
So we are again in the same model as with the Apple Store, where if you want to try an application, you have to pay for it first.

Of course, some companies offer to refund their clients, but regrettably not all of them do that.

And sometimes this extension that looked so well corresponding to your need turns out to be a hoax, or will require some important rewriting work which lessens the real interest of its purchase.

No validation of the extensions

Unfortunately, once proposed the extension is offered unchanged : it will be visible in the Magento connect repository.

This of course exonerates Varien of the validation of a large number of modules, which would surely be tedious according to the number of contribution.

As a result, anyone who feels like contributing, whether he’s really expert in this technology or if his only knowledge is about templating or setup, will be able to offer his work to the community. Despite a vote establishment about the extensions on the magento connect site, no other comment will be available.
And that’s the real drawback of these extensions : quality’s not here…APIs aren’t respected, configuration system are non-existent, and worse, versions are mentionned compatible although most of features generate bugs or induce a loss of fonctionnality, and all of this leaves you with a bitter taste in mouth…

A most risky submission

How complex is this to submit a module !

First, the generation of the archive to provide. Basing on Pear, you have to provide a PEAR package. How do we generate it ?
Most Magento versions embed a feature in the back-office that allows creating its own pear archives. But this interface is really complicated to use:

  • the mentioned fields expect some values, some format, that are not explained. Therefore you search, you try (desperatly) to find…
  • the picking of embedded files in your archive is done manually. So you have to choose one after the other the directories and files to add.

If your project has got many css, javascript files, etc..it will take a lot of time to pick all those files. Morever your interface could become less readable. In short, you will loose time and increase the risk of making a mistake.

Magento connect for entreprise edition ?

Magento is distributed under two licences : community opensource and licencied enterprise. This second edition has got more features and a technical support in addition to the first edition.

But I haven’t understand why in the history of this release, why we should wait the 1.9.0.0 version, the fourth major release of the enterprise edition, to be able to use the same automatic installation setup than in community? You pay 9000$ / year for a license and you can’t access to magento connect repository?

Now, new releases embedded the installer, so we can install extension coming from magento connect. But it’s still lock to magento connect repositories, and so, for commercial extensions, we have no choice to provides our own setup system. For me, giving source to an enterprise which pay my extension require at least to have an automatic setup system (Some companies which develop commercials extensions have found a solution by selling also installation support, perhaps I should do that :))

Quality of the offered extensions

The submission process to the community must be done directly from the interface of the clients accounts on the Magento connect website.

Everyone can leave there its archive, and the day after, the package is visible on the repository.

But we’re in the end in a Drupal-like model, where contributions are not checked : documentation, setup process, quality of the feature enrichment, everything depends ont the good will of the community developers. And unfortunately, it’s clear that the quality of the extensions is sometimes unsatisfactory : one of the Magento’s asset is that you can overload a part of its working to adapt it to your needs.

But with this mechanism, only two overloading can be done. This will become a problem for objects that represent data which are frequently adapted : I think particularly of products and categories.
Developers often use shortcuts to overload Magento objects.

This will work once, possibly two, but thereafter if a third element should be overloaded you would have to do refactoring in the sources of the modules that you set up. Annoying, if you’re not a technical profile, and the gain of time you did is not as intereting as it should have been.

I frequently heard “We’re gonna developp this on our own” because of these problems, me first.

Varien, do you really feel like using PEAR?

With the new version v2 of the installer setup, mage (available since v1.5 community and v1.10 entreprise) we were hoping for being able to use at last the new features.

Regrettably, these new features aren’t included : this setup is only a rewrite of a previous version.

Yet this seemed at first interesting. But the API backside is incomplete : the announced features are the following :
Listed commands in Magento mage Installer

However, the features of authentication management to a pear channel, and of pear channel setup using a local configuration aren’t available.

Example of the doLogin command in the Magento mage installer

Is it a choice of the editor ?

And the best

Some very interesting extensions

I have found some very interesting modules which are almost clean for me and yes, they provides me the expected ean of time on my Magento’s projects.

Just a few example, the Embedded ERP module from the “La maison du Logiciel” is really well done. After tasting many bad extensions, I keep a little hope to have some valid modules 🙂

Magento enterprise developper

It seems that Varien start to saw that it’s very difficult to find some module with great quality and so some enterprises are validated as develop with the good practices. The modules developed by theses enterprises have the following label in Magento connect:

With this logo, we are sure that this extension will work fine

Growing community

On the other hand, I extremely appreciate watching this community grow increasingly, and seeing some extensions included in the Magento core. This proves that the quality of the extensions enhances gradually. Unfortunately, beyond the technical mistakes that may be observed in the poor quality modules (which often are algorythmic errors, or programming errors in general), most mistakes are conception errors due to the lack of knowledge about the APIs of this product : no documentation, not every module is compatible with the available versions of Magento, all of this brings the community to develop its own modules on “THEIR” version, on their own, for their projetcs, without thinking about making it evolve and live.

Conclusion

Yes you probably found that I’m very negative with magento connect. But it’s a shame that this tool does not provides which we can expected.

As far as I’m concerned, the magento connect observation results in a failure :extensions laborious to generate, poor quality of some of them or requiring technical profile to set up, all of this must be taken into account when you think of one of those extensions that seems promising on the repository but that you never tried.

Morever, this concept still lacks of ressources at Varien to be well-administrated : I don’t know the dedicated number of persons at Apple to manage their repository, but I absolutely understand that at the time Varien didn’t have at his disposal the required ressources to correctly administrate it.

I don’t know if we could have an automatic and reliable installation process for theses modules: by three times I have requested directly to some importants guys in Varien the problem we have to provides fiable setup for commercial modules and asked them which is the future for pear / mage installer, but each time I have no answer…

I just hope than E-bay will understand that a more reliable / flexible / automatic / sure deployment system could be benefit for the plateform: I don’t wants a repository like drupal’s one, but like wordpress one!

Let’s hope for a better future for the next few years 🙂

Magento Overloading mecanisms

Magento is a really rich software application. However, its management rules may be diffrent from your own management.
Varien, Magento’s editor, forecasted this case and offers 2 overloading methods of its native working to allow you to adapt the solution to your specificities.

One of these mechanism is a passive overloading, whether the other needs your intervention.

Passive overloading

This overloading mechanism is closely related to Magentos’s autoload management.

Source code organization in Magento & Autoload

Reminder of source code organization in Magento

For recall, autoload is a mechanism born with PHP5 which embeds a dynamic class loader manager.
That is to say, if a class was never loaded, it’s the __autoload method which will search and find in which source if the required class exists. This method may be redefined to adapt your needs.

Magento’s source code is organized according to four repositories

  • Libraries. That’s where you will find, in particular, the Zend Framework which is a referencial for librairies in Magento
  • Magento’s core. It’s in the folder app/code/core
  • Community enrichment. They’re in the folder app/code/community
  • Local enrichment. They’re in the folder app/code/local


So these four folders are : lib, app/code/core, app/code/community, app/code/local

Magento defines its own autoloader in the Autoload class, located in the folder lib/Varien.

This autoloader will first look for classes in app/code/local, and then if it doesn’t find them, in app/code/community, and lastly in app/code/core if it still hasn’t found the right file. After all, if the file is still not found, it will be searched in the libs.

Working of passive overloading in Magento

Everything bases on this autoloader’s working : it’s therefore possible, by acting on the autoload priorities, to make a preferential choice about a local adaptation (which would be in app/code/local), rather than the native file which is in app/code/core.

This requires however that the local adaptation contains fully all the methods that are in the overloaded class.

An example of this kind of overloading is the file app/code/core/Zend/Mime.php which is used instead of the file lib/Zend/Mime.php.

Active overloading

This overloading mechanism is related to instanciation mechanism used in Magento.

Instanciation mechanism in Magento

For recall, Magento uses three generic methods to load its classes :

Mage::getModel() (and Mage::getSingleton)
Mage::getBlockSingleton
Mage::helper()

These methods will be in charge of determining the name of the class to be loaded.

What happens in case of two active overloading of the same class ?

Magento’s rules manager is confused and doesn’t know which class it has to load anymore. In this case you will surely note stange behaviours.

It’s then higly recommanded that you never fall in this case, and be therefore most carefull when you install modules from the community which might already overload the same objects as you.

Which overloading mechanism choose ?

It depends on what you wish to implement, and also on the type of class you wish to overload. Abstract classes for example cannot be overloaded with the active overloading mechanism, because they don’t have a real instanciation. To overload them, you have to choose passive overloading. With active overloading you don’t have to rewrite the full content of the overloaded class, unlike in the passive overloading case.
You also will have less compelling maintenance of your source code referring to this overloading concerning Magento upgrades.

This loading mechanism break also a common bias we can heard: “community folder is only for sources code coming from magento connect”. In this case, if we put our own development only in local folder, we avoid usage of passive overload. is it really the thing you wants?

Unix permissions policies on Magento

Recently, Prestashop has been attacked by a worm: this worm uploaded on the server was able to update the content of a template; this template load many iframe which make you request some unexpected things. Many users have been infected. According to the first feedback, it seems that a good unix permissions policy on Prestashop folder could have stopped this infection.

Magento‘s hosted on unix servers seem to have the same problem: even if there is – for the moment – no problem like Prestashop’s one, most of the plateforms I saw have unix permissions policy problems, and so provide attack facilities. This is the reason why I wrote this article.

Unix permissions resume

First remember the basic of unix permissions: For files and folders, they define if:

  • You can read a file / folder
  • You can write or delete a file / write in this folder
  • You can execute this file / browse the folder

They are defined for three users groups:

  • owner of the resource
  • one group of user
  • other users which are neitherbowner, nor member of the group defined

With this combination of users groups and roles, we can set the most common access permissions on our magento. But which one is the most secured one?

Unix permissions and Magento deployments methods

Permissions set are closely linked to your deployment method: Do you:

  • Upgrade magento directly with Magento connect?
  • Use the installer setup process and deploy your data with magento’s installers?
  • Copy a database coming from a previous server and update the configuration?

In the following article I’ll take the option that you test your updates on a non production server, push your source code through FTP, svn, or other file mechanism, and push your database upgrades with magento installers. Then, I’ll explain you which updates you require to be able to use other delivery mechanism.

Unix permissions Magento requirements

Unix permissions for Web server user in Magento

The most important thing from the point of view of your server security is the permissions defined for the owner of the files: this user run a server, so accept connexions. We must control which services can be provide by this server.
In most of the case this user is the user which run the webserver.

Common rules to apply

First, we will check what is requested for the webserver user to be able to use normally Magento scripts: this user needs to be able to read all files (this is the only requirement to be able to use PHP script) and be able to browse the magento directory tree. That’s all. So your PHP scripts must not have more than 4 octal permission. For your directory tree, we will give to your account access to read and browse, so 5 octal permission.

This is the most common structure for all Magento’s files and folders. Now we will take a look at some special cases.

Folders which require to be writable

Take a look now at the var and media subfolders; webserver user will write there its own data:

  • in var subfolder, he will write: backup files, log files, perhaps cache file, session user files, index process lock files, etc.
  • in media subofolder, he will write thumbnails and media librairy

So these two subfolders require the write permission.

Executables scripts by Webserver user

The question is : does your webserver user require to be able to execute scripts?
Depending on your Magento version, only two or four files require to be executable:

  • Installer script (pear for 1.4.2 or lower,  mage for the earlier versions): all to install modules from magento connect, or to be able to update directly from magento connect your magento
  • scheduler entry point cron.sh
  • pear embedded
  • pecl embedded

In our deployment model, pear is not used from back-office: so we do not set executable permission for our webserver to our webserver user: mage / pear / pecl won’t be executable by this user.
If you want to run scheduled tasks with this user, you must set up executable on the cron.sh file. But you can also run scheduled tasks with another account and so remove also this permission on this file for this user.

Unix permissions for group in Magento

Which group content ?

With group user, we will define all the permissions for administratives tasks: deploy, upgrade, maintenance management, etc.
This allow us to be really independant of the webserver user permissions.
So the group choice depends on who run these tasks. Most common thing is to set up the group of the administrative user as group.

Be able to upgrade source code

To be able to upgrade source code, this group must be able to write in all magento folders, delete, read files.

Be able to manage var data

Unix permissions for all others users in Magento

If all others users are not the owner of the file nor part of the group which realize the administrative tasks, they should not be able to access Magento directory tree: so no permissions

Unix permissions for others deployment methods

Deployment method with Magento connect

No, do you really update your source code from magento connect? Hope I won’t be on your website when you’ll do an upgrade 🙂

But anyway, in this case because it’s the webserver user which run magento connect, you must:

  • Give read / write on all files and folder (packages potentially contain files which can go in every folder).
  • Give the ability to execute mage / pear / pecl

This is one of the reason I don’t recommand this method: all your source files are potentially writeable by webserver user, and so, can be editable like in Prestashop worm.

Initial setup starting with Magento install program

In this case, there’s no big difference with the way I explained before: the only difference is on the app/etc/ folder which must be writeable during installation process to allow creation and update of the local.xml file. Then, when installtion process will finish, you can remove the write access on app/etc and app/etc/local.xml file.

Conclusion

You can find here a summary of the policy we should apply on our Magento folder.

#!/bin/bash
# 
# edit the following variables according with your server configuration
#
ROOT_UID="0"
GROUPUSERNAME=your_group
WEBSERVERUSERNAME=httpd
#
#Check if run as root
#
if [ "$UID" -ne "$ROOT_UID" ] ; then
   echo "You must be root to do that!"
   exit 1
fi
#
# ok, let's go for setting up permissions
#
chown $WEBSERVERUSERNAME:$GROUPUSERNAME "./*" -R
find . -type f -exec chmod 0460 {} \;
find . -type d -exec chmod 0570 {} \;
find var -type f -exec chmod 0660 {} \;
find var -type d -exec chmod 0770 {} \;
find media -type f -exec chmod 0660 {} \;
find media -type d -exec chmod 0770 {} \;
# set up installer script for our admin account
if [ -f pear ]; then
    chmod 0570 pear;
else 
   if [ -f mage ]; then
     chmod 0570 mage;
   fi
fi
if [ -f cron.sh ]; then
   chmod 0570 cron.sh
fi