Frustrated by Magento? Then you’ll love
- Magento Front Controller
- Reinstalling Magento Modules
- Clearing the Magento Cache
- Magento’s Class Instantiation Abstraction and Autoload
- Magento Development Environment
- Logging Magento’s Controller Dispatch
- Magento Configuration Lint
- Slides from Magento Developer’s Paradise
- Generated Magento Model Code
- Magento Knowledge Base
- Magento Connect Role Directories
- Magento Base Directories
- PHP Error Handling and Magento Developer Mode
- Magento Compiler Mode
- Magento: Standard OOP Still Applies
- Magento: Debugging with Varien Object
- Generating Google Sitemaps in Magento
- IE9 fix for Magento
- Magento’s Many 404 Pages
- Magento Quickies
- Commerce Bug in Magento CE 1.6
- Welcome to Magento: Pre-Innovate
- Magento’s Global Variable Design Patterns
- Magento 2: Factory Pattern and Class Rewrites
- Magento Block Lifecycle Methods
- Goodnight and Goodluck
- Magento Attribute Migration Generator
- Fixing Magento Flat Collections with Chaos
- Pulse Storm Launcher in Magento Connect
- StackExchange and the Year of the Site Builder
- Scaling Magento at Copious
- Incremental Migration Scripts in Magento
- A Better Magento 404 Page
- Anatomy of the Magento PHP 5.4 Patch
- Validating a Magento Connect Extension
- Magento Cross Area Sessions
- Review of Grokking Magento
- Imagine 2014: Magento 1.9 Infinite Theme Fallback
- Magento Ultimate Module Creator Review
- Magento Imagine 2014: Parent/Child Themes
- Early Magento Session Instantiation is Harmful
- Using Squid for Local Hostnames on iPads
- Magento, Varnish, and Turpentine
Just a quick note, but it seems that despite having the whole <version> thing going on in config files, Magento doesn’t actively do a version diff and reload a new module. If you want the system to reload the module (and re-run any database setup, etc.) take a look in the core_resource table.
+-------------------------+---------+
| code | version |
+-------------------------+---------+
| adminnotification_setup | 1.0.0 |
| admin_setup | 0.7.1 |
| etc ... | ... |
+-------------------------+---------+
mysql>
Just delete your module from this table and then clear Magento’s cache. That should be all it takes to re-load the new module into the system.
Update: What I said above about the versions being meaningless isn’t correct. The mysql4-install-X.X.X.php files will only be run once by the system. However, by changing the version value in your XML config, you’re telling the system which install file it should be looking for. So, for example
//this in your config
<version>0.2.1</version>
//would load this sql install file
mysql4-install-0.2.1.php
...
When you’re deploying new versions of a module, be sure to change the version of your install script. During development though, it’s still best to just delete the record from your core_resource table.
Like this article? Then you’ll love Commerce Bug, the must have debugging extension for anyone using Magento. Whether you’re just starting out or you’re a seasoned pro, Commerce Bug will save you and your team hours everyday. Grab a copy and start working with Magento instead of against it.