With the release of the SUPEE-6788 patch for Magento some functionality regarding admin routes and SQL statement filters have been deprecates for good, and even though they haven’t been encouraged for the past couple years there’s a list of over 800 extensions that are expected to break because they still follow some of these conventions.
For this reason I’d like to talk about some deprecated functionality in Magento (some are being addressed by SUPEE-6788 and some are not), but most importantly how to fix them so that your code is more resilient to future patches and updates.
1. Adminhtml router
This is probably the biggest ofender being addressed by the SUPEE-6788 patch, you might come across some extensions registering admin routes like this:
However the correct way to do it now is by rewriting the
This is the same approach we take when we want to rewrite any controller but in this case, instead of changing a previously defined route, we’re adding a new one.
Keep in mind that if you want to add new routes it’s recommended to use the
after property, that way you make sure that all built-in admin routes are loaded first so you don’t override them by mistake. However if you do want to override an admin route make sure to change the property to
before and adjust your route names accordingly.
2. SQL statements as field names
If you need to use SQL statements as field names in your collection filter queries you might have code la looks like this:
Instead the correct way to do it now is to make sure the statement is escaped before executing the SQL query:
I’ve personally never had to use SQL statements as field names in Magento but if your use case requires it then that’s the way to go about it.
3. MySQL specific resources
When registering resources it’s common to see them registered like this in the
However since Magento 1.6 it’s not necessary to specify the database implementation (in this case MySQL) this allows the resources to be database agnostic and makes sure they run in all the supported database engines (including Oracle and Percona). Also if you are using a single database for read and write operations you can further simplify the configuration file by removing the connection nodes.
This also applies to installation and upgrade scripts, if your filenames look like this:
You can safely remove the mysql4 prefix:
4. SQL queries in setup scripts
While on the subject of setup scripts, it is quite common to find SQL queries embedded directly in the installation and upgrade script files.
Even though there’s nothing technically wrong about this approach it can lead to:
- Easier to make mistakes.
- Harder to debug code, specially for more complex queries.
- Runtime errors if queries are ran in other supported SQL implementations.
Instead Magento provides a very powerful
Varien_Db_Ddl class to abstract the way we can interact with databases. It can be used to manipulate SQL tables without worrying about the underlying syntax complexities, so the above script could be roughly rewritten to:
No direct SQL queries thanks to the
Varien_Db_Ddl class handling the complexity for us.
5. Multi-store setups with symlinks
It’s complex enough to run a multi-store setup with Magento so there’s no need to create more complexity by bringing symlinks into the mix. Some developers recommend to create a new for each store domain and symlink Magento’s core files into each one of them but Magento has all the tools in place to handle this without including this extra step.
At the end of Magento’s
index.php file we will find the following lines:
This basically means that if the
MAGE_RUN_TYPE server variables are set then Magento will run the store or website set in those variables.
If we are using apache we can set environment variables in the
.htaccess file, so all we need to do is include the following lines:
SetEnvIf Host .*newstore.* MAGE_RUN_CODE=newstore
SetEnvIf Host .*newstore.* MAGE_RUN_TYPE=website # or store
This will make Magento display the store with the code
newstore code if the URL matches www.newstore.com for example.
If you have come across similar ways to improve our code quality when working with Magento feel free to let me know in the comments.