Common convention for namespaces in PHP is to start with
Vendor\Package, capitalized (
CamelCase ) with “vendor” and “package” analogous to the composer package name.
There is a bad habit I see often, probably coming from the ZF1 and Pear days, where every word in the class name is a new sub namespace (and a new subdirectory), or child classes are moved into a namespace with the name of the parent class. All this is leading to deeply nested namespaces and class names that have no meaning without their namespace.
Examples from Zend Framework 1 (pseudo namespaces):
Zend_Db_Table_Row_Abstract an abstract base class for
Zend_Db_Table_Row, representing a database table row. There are also
Zend_Pdf_FileParser_Font_OpenType_TrueType a parser for true type font files. The class extends
Zend_Pdf_FileParser_Font_OpenType which extends
Zend_Pdf_FileParser_Font which extends
And a current example from Magento 2:
Magento\Catalog\Model\Product\Option\Type\File\Validator – A validator for product options of the type “file”
Continue reading “Sensible Namespaces in PHP”
This Tweet in 2015 blew my mind. I learned a bit about designing interactive systems and psychology in design, so I could relate immediately. It inspired me to a talk “Usability for Programmers” at WebCon Aachen, that unfortunately never went public because the event was cancelled, and I am yet waiting for a new chance to deliver it.
But I find the content too interesting to leave it hidden any longer, so here’s a blog post!
Continue reading “Usability for Programmers – UX Is Not Just Frontend!”
For me, the first step before starting work on an unknown existing Magento installation, is always a shop analysis. Not only to understand the requirements and processes of the merchant, but also and above all to evaluate the quality and recognize possible problems early on. Unfortunately, many shops are tinkered without any knowledge of conventions and best practices, which leads to:
- Suffering performance
- Security vulnerabilities
- Impossibility to update
- Unmaintainable code
Points 1 and 2 directly affect the merchant, point 3 and 4 lead to bugs being accumulated over time, which results in new changes causing bugs in different places, that get harder and harder to solve.
This bug-ridden cycle is often the reason merchants try a new agency or developer to “fix everything”, so it is no coincidence that most shops that land on my desk are in such a degenerated state. The more important it is to analyze first, before any quote for further development and maintenance, to not fall into the same trap as the predecessor and to add clarity on both sides.
The analysis has a three-tier design such that after the first tier (1 to 2 hours of effort) there is already a rough estimation of quality and need for action, and after the second tier it is possible to make a quote for cleaning and updating the shop.
Read more at magenticians.com →
Continue reading “My Checklist For Magento Shop Analysis”
A very common issue in 2014 was „I updated to Magento 1.8 and now my (login|cart) form is not working anymore”. The reason for this happening was that starting with Magento 1.8, the form key was used in more forms as a security feature (it prevents CSRF attacks). But any theme that had its own version of the according templates did not include the form key, so that the server side validation of the form silently failed.
Of course there are themes whose markups are so different from the default theme, that most templates are overridden with good reason. However I see at least as many themes, especially custom themes, where all templates were copied from base/default and then modified. There is almost no excuse to overwrite layout XML files because one can modify the layout in many ways with an additional theme specific local.xml file.
The issue mentioned above is a good example of the reasons for the „pay attention to updatability“ mantra. The errors could have been avoided if only files had been copied, that really required adjustment(s).
With this article I want to explain the process I’m following for theme refactoring (just the structural part, the HTML source will look exactly as before afterwards — except from changes in newer versions of the default templates).
Read more at integer-net.com →