0

Ok, so several times now I've had magento be a utter b**** when it comes to updating my custom modules and it would save me an awful amount of time if i could just remove them completely. Important to note these always include a database table.

Currently to uninstall I delete the relevent files in app/etc/modules, app/design/adminhtml/default/default/layout and the folder in app/code/local/namespace/.

I also delete the table (modules contain install script anyway) and the reference in core_resource. I also delete the var folder, clear the cash and index to be damn sure it should all be gone.

Now if i were to then try to re-add an up dated module (with the same version number) with new fields in the model, it will somehow know what the original fields were and not add the new fields. This screams to me that I've not removed all the data in the database regarding this module.

What am i missing?

Improve this question
6
  • 2
    What do you want to add? If you want to run install scripts, all you have to do is remove the entry in core_resource and clear the cache. After install clear the cache again, so magento recognizes the new module#
    – Fabian Blechschmidt
    Mar 27, 2013 at 13:14
  • 1
    Are you flushing the cache or flushing the cache storage? Magento has a DDL cache which can cause problems like this if not flushed because the RDBMS layer will believe you have one schema when you really have another.
    – davidalger
    Mar 27, 2013 at 13:42
  • I've tried using all the cache clearing options, before removal,after removal and after installation and nothing seems to work. It's fully deleted, removed from the database, cache cleared, double checked the database, re installed then cache cleared again and yet it stays with its original fields so not being fully uninstalled for some ungodly reason
    – Chris Morris
    Mar 27, 2013 at 14:44
  • Are you utilizing any extended caching with APC and/or Memcache? The last time I ran into a similar issue with an admin module going awry in the way you describe I wiped out both of those caches and restarted Apache. Nuking the server state was the final thing that worked for me.
    – user587
    Mar 27, 2013 at 15:16
  • Well I've not set either of them up so i don't think so...
    – Chris Morris
    Mar 27, 2013 at 15:26

2 Answers 2

Reset to default
2

As already explained in your other question and as @Fabian Blechschmidt states, you simply just disable module (admin > config > system > advanced) and then remove the entry from the database table core_resource and clear cache/sessions as necessary. This removes the install information for that extension from Magento. Then you would delete the necessary files and folders relating to that extension.

If this isn't working for you, then you've either done something wrong, your Magento install has more serious issues or your extension is inserting multiple traces and references to it in other places in the structure/database.

Improve this answer
3
  • 2
    That config option only disables block output for modules, it doesn't actually disable the module itself.
    – Daniel Sloof
    Mar 27, 2013 at 18:46
  • Sure, but if the module is disabled, when the front / back end is refreshed, the extension won't try to reinstall itself again with the mysql install/upgrade hence my only reason for suggesting disabling it here first.
    – zigojacko
    Mar 28, 2013 at 8:43
  • 3
    Not true, install/upgrade logic makes no distinction between modules that have block output enabled or not.
    – Daniel Sloof
    Mar 28, 2013 at 16:06
1

A good practice is to create upgrade scripts to your module when you do updates instead of trying to remove it and install it from scratch. So if you have a module that is at version 1.0, you change the version to 1.1 and create a mysql4-upgrade-1.0-1.1.php file that does the upgrade (if you are not familiar with this, read http://www.magentocommerce.com/knowledge-base/entry/magento-for-dev-part-6-magento-setup-resources). In this case, putting your module on a system that has version 1.0 installed will run only the 1.0-1.1 upgrade while putting it on a system where the module is not present will run both the install (1.0) file and the 1.0-1.1 upgrade, which is pretty neat. I find myself doing this often as it is a lot easier to distribute the module to dev/qa/production servers without touching the database.

In the case you want to re-test the full install locally, the best way is to start with a clean database. Just install Magento, create a database dump right after and replace your db with this one when you need to. Magento has no support for "real" uninstallers. For example, if you add a table column in your installer, there is not standard way to remove that at uninstall. Until Magento comes up with an uninstall system, wiping the database is the safest way to make sure you revert an install.

Improve this answer
1
  • This is pretty much what I've been doing so far, however now this module is a bit of a wreck after following everyone's advice. My module was a update of 0.2.0 from 0.1.9, then my updates just didn't work and that was when I tried to just remove the damned thing and start from scratch. Though do i need a SQL upgrade php file if i am not changing the database at all?
    – Chris Morris
    Mar 28, 2013 at 15:08

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.