This issue, which is now resolved for most people with current versions of commerce and Drupal, continues to come up from time to time.
At one time there were several ways that a Drupal 7 module could be prevented from uninstalling. See #53 and #56. The core issues have now been resolved, and now the only problem is that you have to uninstall an awful lot of modules in the correct order.
There are brute-force uninstall mechanisms in this issue that may still solve somebody who just wants to make it all go away. #82 contains a script which may be used to brute-force uninstall Commerce modules and their fields. #104 contains another (similar?) description of a successful approach.
Here's a summary of the (resolved) major problems in this issue:
- Fields weren't deleted on uninstall, meaning that you couldn't reinstall. This was a D7 problem. This was the original topic of this issue, and an approach to a workaround is in #61 here and earlier. The core issue we tracked to resolve this one was #943772: field_delete_field() and others fail for inactive fields.
- hook_menu() was called on uninstallation, and it shouldn't have been. This led to PHP fatals when uninstalling many commerce modules. The commerce issue was #1017006: Unable to uninstall due to PHP fatals because hook_menu() is called by core when uninstalling. The core issue we were tracking for this was #1029606: Regression: Not loading the .module file causes a fatal error when uninstalling some modules (as does loading it).
- Drush doesn't do uninstalls correctly on D7, so if you use drush for uninstalling, you're just adding to the pain. The drush issue is #1119686: pm-uninstall doesn't respect module dependencies (at least for D7).
- A step-by-step uninstall technique is presented in #120
OP by bojanz:
Here's a fun game to play:
1) Enable and install Drupal Commerce
2) Now, disable all Drupal Commerce modules, and uninstall them.
3) Decide that you want Drupal Commerce after all, so enable them again.
4) Watch as installation fails with the message:
FieldException: Attempt to create field name line_items which already exists, although it is inactive. in field_create_field() (line 273 of /home/bojan/public_html/d7/modules/field/field.crud.inc).
Fun, huh?
We need to add some uninstall code which deletes all of the previously created fields, such as the above mentioned "line_items".
Comment | File | Size | Author |
---|---|---|---|
#124 | error disabling reenabling drupal commerce.png | 10.83 KB | Pere Orga |
#124 | error disabling reenabling drupal commerce2.png | 10.67 KB | Pere Orga |
#93 | commerce.reinstall_after_uninstall_partial.patch | 2.25 KB | rfay |
#85 | 858722.patch | 3.2 KB | recidive |
#82 | commerce_uninstall.sh_.txt | 1.06 KB | rfay |
Comments
Comment #1
Scott J CreditAttribution: Scott J commentedIs there a list somewhere of all Commerce database tables? I want to delete them all so I can do a clean reinstall.
Comment #2
rszrama CreditAttribution: rszrama commentedThe problem is there's also field data that you have to take care of, meaning removing specific rows from some of the core field tables in addition to some field data tables. Any tables added specifically for Commerce entities begin with commerce_.
Comment #3
Scott J CreditAttribution: Scott J commentedThanks for the tip.
Yes I saw the commerce_ tables, and I spotted:
field_data_product
field_data_field_catalog
field_data_customer_billing
field_data_billing_address
field_data_line_items
field_data_purchase_price
field_data_total
field_data_unit_price
But I missed those rows in field_config and field_config_entity_type and ...?
Comment #4
rszrama CreditAttribution: rszrama commentedI'm not sure what else will be leftover, but you'd also need to clear your caches. If you didn't disable these through the UI, you'd also have junk left over in your system table. Basically, it's not a pretty process. : P
Comment #5
bojanz CreditAttribution: bojanz commentedTotally forgot about this. The issue is from July.
Will handle it in the near near future.
Comment #6
rszrama CreditAttribution: rszrama commentedhehe No worries... it's been on my radar, I just didn't feel like deciding what to do with field data when the modules are uninstalled. : P
Comment #7
bojanz CreditAttribution: bojanz commentedNow we can feel like not deciding together :D
I'll see what core does in that regard.
I'm generally okay with just droping the data. The user *did* click Uninstall...
Comment #8
lathanNot sure if this is a new bug. Upon uninstall there is an order of uninstalling modules. Some are grey'ed out other not, when I get down to the UI modules.. they simply can not be uninstalled at this point
Drush throws error's like this
I'm running the Dec-02 dev drop with the core patch... no view love yet. Was trying to uninstall and reinstall to see if that was the issue.. then ran into this.
Comment #9
scotwith1tit pains me to even bring this up, because i admire you guys so much (i can't code worth a crap, nevermind such a complicated undertaking as this!), but since Ryan commented above that it's "not a pretty process", I'll add my 2 cents to that. This is a serious understatement as it takes a crazy amount of repeatedly checking boxes and clicking update to get the whole package installed, then uninstalling is just as bad and probably worse as many of the sub-modules i can't get to uninstall at all. i got a bunch of them uninstalled, but i am getting
Fatal error: Call to undefined function commerce_product_types() in ....../httpdocs/sites/all/modules/commerce/modules/product/commerce_product_ui.module on line 25
and i'm unable to uninstall customer UI, order UI and product UI at all. this is in alpha3 though and not -dev...i suppose i should create a separate issue against that? anyway, hoping that improvements are made to the install and uninstall processes during the development of the final product.
appreciate you guys and what you're doing with this project! it's gonna be great, i know it.
Comment #10
rszrama CreditAttribution: rszrama commentedYeah, don't worry about opening a separate issue. This is a very big known issue with no code given to undoing fields created on install. It hasn't been a big deal in alpha development, b/c sites have to be completely rebuilt from scratch on each new schema change. I'll make a note in the beta roadmap that this needs to be settled (or at least attempted : ) before then, though.
Comment #11
scotwith1tthanks Ryan. unfortunately, you're going to probably have a lot of people installing, trying it out and deciding they're not up to the task of configuring their products the "new way" and uninstalling and then running into this problem pretty quickly. i just removed the module files for the site i was testing on and manually removed the tables, but many won't have a clue how to do this who installed via the module install UI, so i dare say this ought to be critical, but i'll leave that to your judgement. i'll keep testing out the different releases along the way...keep it up!
Comment #12
rszrama CreditAttribution: rszrama commentedYou're right - no need to hose someone's D7 test site unnecessarily. I'll update the project page to reflect the fact that uninstall routines do not properly clear away our fields; as for actually removing tables and all, that part should work just fine.
I'm actually not sure how you managed to uninstall them out of order - Drupal itself should prevent that from happening, and uninstalling modules beneath deep dependencies has always been an issue. I'm not sure this project is really the one to address full package installation; I half wonder if someone else isn't already doing this - I've seen mock-ups in the past for issues that would simplify general package / dependency installation and uninstallation, but I'm not sure how far they ever got.
Comment #13
bojanz CreditAttribution: bojanz commentedUninstalling out of order should be a core bug... I mean, that should really never happen, and there's not much we can do in that regard.
Anyway, core fixed the last field deleting bug two days ago in: #915906: Deleting node type with only instance of a field leaves the field in a strange zombie state. Now when you delete the last instance, it will automatically delete the field itself, making our job in Drupal Commerce uninstall much easier.
Still planning to give this attention...
Comment #14
scotwith1tthanks guys. there seemed to be no problem with disabling in the right order, as only certain sub-modules were available at a time, i unchecked the ones available, update, come back, more are available, uncheck those, update, repeat until all are disabled (again, still to long of a process IMHO to disable the thing). then i went to the uninstall tab and was able to uninstall quite a few of the sub-modules, but got to a point where i was left with only the 3 UI modules mentioned and any that you have to uninstall after, but each attempt to uninstall those 3 gave the error message (see #9). i believe this installation is using an out of date core d7-dev too, so that could be a big factor...i'll get to updating that and try again from scratch and see what happens. good temp fix to put the known bug on the project page though. i will continue to test the heck out of this as much as i can.
Comment #15
bojanz CreditAttribution: bojanz commentedNext related core bug: #943772: field_delete_field() and others fail for inactive fields.
This one is all about hook_uninstall(), so it affects us directly.
After that one is fixed, we might just not have anything else to do here ;)
Comment #16
rszrama CreditAttribution: rszrama commentedlol That's awesome. Thanks for keeping up with those issues, Bojan. : )
Comment #17
aidanlis CreditAttribution: aidanlis commentedUninstalling has an expectation that it will remove all data associated with a module - so I'm +1 for removing the fields and all data completely.
That said, Fields does provide a mechanism for deleting fields and storing their data. This is used with the core content types, when a field is deleted the database table is renamed fields_field_deleted_xx and the field registry is updated.
If we go with the second approach - a new installation will create new tables (not reusing the old ones), and the previous data would still be inaccessible - I don't think there's a lot to be gained that way.
Comment #18
Scott J CreditAttribution: Scott J commentedI just tried uninstall, and it does give a warning:
I would be much happier to try Commerce on a production site if I know that it can be cleanly removed if need be. Of course to go with that would be a method of exporting/importing products so that hours and hours of work is not lost in the process.
Comment #19
rszrama CreditAttribution: rszrama commentedDon't use it on a production site unless you're certain you want it for now... during alpha there is no update process, and the database schema and module names are likely to change.
Comment #20
recidive CreditAttribution: recidive commentedI'm not sure I covered all fields. But here's a start:
https://github.com/recidive/drupalcommerce/tree/858722
Comment #21
recidive CreditAttribution: recidive commentedComment #22
rszrama CreditAttribution: rszrama commentedTagging.
Comment #23
recidive CreditAttribution: recidive commentedI pushed some code to my branch, for removing commerce_customer_*, commerce_order_total, commerce_product fields renaming purchase_price field to commerce_price and prefixing other fields with "commerce_".
I can't really test uninstalling the modules, since I'm getting missing function errors of all kind. I've ran drush dis commerce, to get all modules disabled at once. And now when I go to the uninstall tab in module pages and try to uninstall the modules, I get:
Comment #24
recidive CreditAttribution: recidive commentedThe problem is that by design, Drupal calls hook_menu() on hook_uninstall() to remove menu_links paths defined by the module. See #603798: When a module is being uninstalled, it's hook_menu() is called. So this is a core issue. There may have a good discussion about this, but it should make sense removing menu_links paths on hook_disable() instead.
Comment #25
rszrama CreditAttribution: rszrama commentedWait... you had to rename fields? Was it just in an uninstall routine? Actually, looking at your repo, it looks like you made changes and then merged my commits into yours. If I pull from you now, I'll end up pulling in your merge of my commits, no? I think you might need to rebase on my repo before you do any further commits to avoid commit duplication in my stream... we might need to check w/ DamZ in IRC.
Comment #26
recidive CreditAttribution: recidive commentedYes, I've prefixed the fields in the uninstall routines, since field names changed since my last take on this.
Interesting, but I have been doing this way all the time, I pull from your master branch to local and push to my remote one. Even my master branch shows those as commits. Not sure if this will be a problem.
Is there a better way to do this?
Comment #27
rszrama CreditAttribution: rszrama commentedI'll give it a shot and see what happens. If it hasn't been a problem thus far, maybe it's nothing to worry about.
Thanks for the clarification. : )
Comment #28
recidive CreditAttribution: recidive commentedI've worked with randy into fixing the branch, it's now clean with my commits squashed into one on top:
https://github.com/recidive/drupalcommerce/commits/858722
Comment #29
recidive CreditAttribution: recidive commentedA core bug is causing undeclared function errors: #1029606: Regression: Not loading the .module file causes a fatal error when uninstalling some modules (as does loading it).
Comment #30
recidive CreditAttribution: recidive commentedI've updated the branch with a change on how to get profile types to uninstall their related reference fields.
https://github.com/recidive/drupalcommerce/commits/858722
Ps: forgot to hit "save" on this one. Too many tabs open.
Comment #31
rszrama CreditAttribution: rszrama commentedAs uninstallation is hindered by a core bug, I can't really hold up the beta. We'll just have to ensure people are aware of the risk before installing on a non-destructible site until we can develop a workaround or get a core patch committed.
Comment #32
aidanlis CreditAttribution: aidanlis commentedThe core bug is pretty easy to workaround, a quick if (module_exists('')) in hook_menu will do it.
Comment #33
uberhacker CreditAttribution: uberhacker commentedBasic SQL uninstall instructions:
Comment #34
edg1 CreditAttribution: edg1 commentedhi uberhacker is it using the same syntax in mysql 5 ?
i'm getting trouble with drop every table displayed
Comment #35
recidive CreditAttribution: recidive commented@edg1: funny, this may be due to "drop every table displayed" not being a SQL command but a human one.
Comment #36
Tebb CreditAttribution: Tebb commentedFollowing.
Comment #37
uberhacker CreditAttribution: uberhacker commentedYes, recidive is correct. What I meant was after executing show tables like '%commerce%';, you would then execute the following:
drop table commerce_calculated_price;
drop table commerce_checkout_pane;
drop table commerce_customer_profile;
...
And yes, these are MySQL 5 commands.
Comment #38
edg1 CreditAttribution: edg1 commentedTough it was an easy command.. could be one ;-)
Comment #39
edg1 CreditAttribution: edg1 commentedisn't there a command like drop tables like '%commerce%';
??
Comment #40
edg1 CreditAttribution: edg1 commenteda list of the first ones to make it easy:
drop table commerce_calculated_price;
drop table commerce_checkout_pane;
drop table commerce_customer_profile;
drop table commerce_customer_profile_revision;
drop table commerce_line_item;
drop table commerce_order;
drop table commerce_order_revision;
drop table commerce_payment_transaction;
drop table commerce_payment_transaction_revision;
drop table commerce_product;
drop table commerce_product_type;
drop table commerce_tax_rate;
drop table commerce_tax_type;
drop table field_data_commerce_customer_address;
drop table field_data_commerce_customer_billing;
drop table field_data_commerce_display_path;
drop table field_data_commerce_line_items;
drop table field_data_commerce_order_total;
drop table field_data_commerce_price;
drop table field_data_commerce_product;
drop table field_data_commerce_total;
drop table field_data_commerce_unit_price;
drop table field_revision_commerce_customer_address;
drop table field_revision_commerce_customer_billing;
drop table field_revision_commerce_display_path;
drop table field_revision_commerce_line_items;
drop table field_revision_commerce_order_total;
drop table field_revision_commerce_price;
drop table field_revision_commerce_product;
drop table field_revision_commerce_total;
drop table field_revision_commerce_unit_price;
Comment #41
edg1 CreditAttribution: edg1 commentedOK , i'm having a problem when i deleted the cache tables :
It seems that drupal ik looking for the chache_update table wich it can't find because it is deleted.
Can anyone help me out here??
I can acces my website but not the module section.
the error code:
PDOException: SQLSTATE[42S02]: Base table or view not found: 1146 Table 'db.cache_update' doesn't exist: SELECT cache_update.cid AS cid, cache_update.data AS data, cache_update.created AS created, cache_update.expire AS expire, cache_update.serialized AS serialized FROM {cache_update} cache_update WHERE (cache_update.cid LIKE :db_condition_placeholder_0 ESCAPE '\\') ; Array ( [:db_condition_placeholder_0] => available_releases::% ) in _update_get_cache_multiple() (line 794 of /modules/update/update.module).
Comment #42
rszrama CreditAttribution: rszrama commentedWhoa, yeah, you definitely shouldn't delete the cache tables. The keyword there is "truncate", i.e. empty, not drop.
Comment #43
Tebb CreditAttribution: Tebb commented@edg1:
Maybe I misunderstand, but why did you delete your 'cache' tables?
The instructions above say delete tables with names containing the word 'commerce'.
For example: drop table commerce_calculated_price;
Comment #44
edg1 CreditAttribution: edg1 commentedCan i fix this in some way ?
Comment #45
rszrama CreditAttribution: rszrama commentedRecreate the table(s)? Perhaps you have a DB bakup from before you started deleting things... but if not you can always reinstall to another database and copy the tables over.
Comment #46
Tebb CreditAttribution: Tebb commented@edg1
Perhaps you could restore your backup?
This module is very good http://drupal.org/project/backup_migrate for creating scheduled and manual backups.
Comment #47
edg1 CreditAttribution: edg1 commentedyeah i'm kinda in trouble... I've recreated the databases but i still need some tables that weren't there in my last back-up.
Could anyone help me out with the structure of the following tables:
cache_entity_user
cache_entity_files
cache_image
@rszrama: I'll try that now
@Dru-p: yeah i messed it up there , will have to take better care of my back-ups. restoring my last one isn't possible because i changed to many things already.
Thanks for the advice.
ed
Comment #48
Scott J CreditAttribution: Scott J commentedI have a cache_image but neither of the other two. What module could they be from?
Comment #49
edg1 CreditAttribution: edg1 commented@Scott J : i think from the entity cache module.
thanks for the zip!
Where exactly did you find that sql file?
Now I need the cache_styles table, but i went trough the Styles module but no .sql file there
Comment #50
edg1 CreditAttribution: edg1 commentedi fixed it using a new installation and then copying the cache tables that where asked for using the following sql commands:
an example (alter the the db names and table names to your own one)
CREATE TABLE toberecoverdbname.cache_update LIKE newinstaldbname.cache_update;
INSERT INTO oberecoverdbname.cache_update SELECT * FROM newinstaldbname.cache_update;
the first like is to make a new table exactly like the new one
the second one is to set the keys right and populmate the db with possible data.
@scott J: I would love to find out where you found this sql file this would have saved me a lot of time if I only knew where they are or even where to find the structure of these databases could also be very helpfull.
Comment #51
Scott J CreditAttribution: Scott J commentedThat was from my own D7 installation. I just exported it using phpMyAdmin.
Comment #52
edg1 CreditAttribution: edg1 commentedok thanks, i got everything fixed now.. ;-)
I learned my lesson for backing up tings!!!
Comment #53
rcross CreditAttribution: rcross commentedJust curious if there is a core issue here. There seems to be a similar problem for the media module. See #970696: Disabling and re-enabling media module throws exceptions, leaves website in unusable state.
Comment #54
aidanlis CreditAttribution: aidanlis commented@rcross, no.
Comment #55
rcross CreditAttribution: rcross commented@aidanlis - other discussions around this point have pointed to this core discussion - http://drupal.org/node/943772#comment-4197688
Comment #56
bojanz CreditAttribution: bojanz commentedYes, there's a core issue (linked above).
Short version: if your module is providing a field type, there's no way to delete fields of that type on module uninstall (because when hook_uninstall() has run, the module is already disabled and all of its fields marked as inactive)
So you can see why this breaks both Commerce and Media.
There's also another core issue: #1029606: Regression: Not loading the .module file causes a fatal error when uninstalling some modules (as does loading it) that guarantees broken uninstall for pretty much every module relying on the Entity API (even if we do create a workaround for our hook_menu() issue, as mentioned by aidanlis)
Marking this issue postponed.
Comment #57
rfayA workaround that looks like it's going to go for me. Before reinstalling:
Edit - pseudocode:
Comment #58
bojanz CreditAttribution: bojanz commentedDeleting the matching row from field_config_instance would be a good idea then.
Comment #59
rfayThanks for that, @bojanz. I updated #57
Comment #60
rfayGetting tired of doing this, so here's a raw script to do it all in one go. Be careful with it though. I damaged the wrong database by being in the wrong directory with this.
Comment #61
rfayThis may still not be perfect, but added clearing the cache_field table.
Note that issues like #1029606: Regression: Not loading the .module file causes a fatal error when uninstalling some modules (as does loading it) still lie in the way of uninstall in general.
Comment #62
rfayPer Ryan, changing the title since this has become a catch-all for uninstall issues.
Essentially, you shouldn't expect to be able to uninstall commerce at this pint unless you're willing to do a bunch of questionable database munging and are fairly expert in the D7 database schema.
Here's a summary of the major problems:
Comment #63
Jerome F CreditAttribution: Jerome F commentedHaving some problems with deleted fields described in : http://drupal.org/node/943772#comment-4342770
Firts I did enable the module again (hierarchical select in my case).
Then, I went in phpmyadmin to the field_config table and set the 2 disabled fields status back to active 1 with the edit tool (it was set to 0).
That did the trick for me, now the fields are visible again and I can delete them the drupal way.
Comment #64
NPC CreditAttribution: NPC commentedSubscribing.
Comment #65
David D CreditAttribution: David D commentedThe title of this issue really should have the reference to Drush removed, as it's quite irrelevant to the problem. I got caught up in this mess and didn't look at this Issue item because I wasn't using Drush, and I ignored the reference in the project page for the same reason.
Comment #66
rfayComment #67
keithm CreditAttribution: keithm commentedsubscribe
Comment #68
heyyo CreditAttribution: heyyo commentedafter applying the script in #61 and these 2 sql commands :
delete from rules_config where name like 'commerce_%';
delete from variable where name like 'commerce_%';
I tried to reinstall the last dev version of commerce:
but now i have this error on all pages of my site...
PDOException: SQLSTATE[42S02]: Base table or view not found: 1146 Table 'xxxx_com.commerce_tax_rate' doesn't exist: SELECT * FROM {commerce_tax_rate}; Array ( ) in commerce_tax_ui_commerce_tax_rate_info() (line 347 of /home/quickstart/websites/XXXX.com/sites/all/modules/commerce/modules/tax/commerce_tax_ui.module).
I tried to reclean my database as previous but this error is still present.
Any help will be welcome...
EDIT: I have also this error by just doing: drush dl modulename...
EDIT2: by truncating all my cache tables, i have an additional error which is displayed first :
Comment #69
rszrama CreditAttribution: rszrama commented@heyyo It seems pretty obvious that when the Tax module re-installed, it didn't treat it as a full install and missed adding some DB tables. When you wipe Commerce stuff from your DB, you should probably do a full uninstall through the UI first.
Comment #70
rfay@rszrama, except I don't think we can ever do a successful uninstall can we?
Comment #71
rszrama CreditAttribution: rszrama commented@rfay Ahh, that's right. I forgot about the menu item problem... really need those patches to get committed. : P
Just clean the Commerce entries out of the system table, then... does your script above already do that?
Comment #72
David D CreditAttribution: David D commentedI note in trying to scrub this stuff out of my db that there are several field names created by Commerce that don't follow the field_data_commerce_% format, and thus don't get caught by the scripts suggested here. Specifically, they are (as far as I've found):
field_data_billing_address
field_data_line_items
field_data_customer_billing
and of course,
field_revision_billing_address
field_revision_line_items
field_revision_customer_billing
Should these be changed to conform to the naming convention used for all other Commerce fields? Or perhaps they already have, and this is cruft from an earlier version in my db.
Comment #73
rfayHmm, @David D: Before beta, all the fields (I think) were renamed to have "commerce" in them.
@rszrama, As I remember I was able to kill all the fields, but I wasn't able to uninstall all the modules. However, I guess one could just set the relevant modules to uninstalled in the system table.
I guess we could expand that script to just go through and do everything the system should have done.
Comment #74
heyyo CreditAttribution: heyyo commentedit should be great if Drupal Commerce was a drupal features. Not everyone wants to start a new website with a profile, lots of people have already a website and want to add ecommerce feature...Is it in a futur roadmap ?
Comment #75
aidanlis CreditAttribution: aidanlis commented@heyyo What are you talking about?
Comment #76
heyyo CreditAttribution: heyyo commented@aidanlis Why are we deleting Drupal Commerce, because the install process is really not easy, not working correctly with drush because of drush bug, modules need to be activated one by one and in a specific order, and when we go wrong, it's not easy to revert back, because the uninstall process is buggy(because essentially of drupal 7 core problems).
So I was proposing to work on another method of installing drupal commerce as a feature. http://drupal.org/project/features.
Sothe installation of drupal commerce will be only one module to install this new feature.
EDIT: this feature will be an alternative to profile(commerce_kickstart)
Comment #77
bojanz CreditAttribution: bojanz commentedThat has nothing to do with this issue.
A feature is still a module.
Comment #78
aidanlis CreditAttribution: aidanlis commentedYou don't have to use the profile heyyo, that is for "kick starting".
Comment #79
rszrama CreditAttribution: rszrama commentedfwiw, even if you make a Features module that installs the Commerce modules, uninstallation still won't work if you try to uninstall that Feature.
Comment #80
heyyo CreditAttribution: heyyo commented@rsrama I hope that it will work one day...
Comment #81
rszrama CreditAttribution: rszrama commentedIt will. : P
Dries is back in action on committing patches to D8 that will be backported to D7 to resolve these issues.
Comment #82
rfayHere is an update to #67 that does a brute-force uninstall of everything I know of that is related to Drupal Commerce. Use at your own risk. No money-back guarantee.
Comment #83
bojanz CreditAttribution: bojanz commentedThe hook_menu() fix was committed to D7 last friday.
This leaves the field uninstall and drush problems remaining.
Comment #84
rfayAnd Yay! Thanks, @bojanz, for the followup there (and lots of places like VBO too!) You're a rock star.
Comment #85
recidive CreditAttribution: recidive commentedHere is a re-rolled patch I took from my old branch at github. I'm not sure if it cover all fields, any reviews are appreciated.
Comment #86
rfay@recidive, I thought the whole problem of #943772: field_delete_field() and others fail for inactive fields was that you couldn't delete inactive fields (which will be inactive when a module is disabled, before it is uninstalled). I don't believe that your hook_uninstall() implementations can actually execute on deleting those fields.
Update: I tested uninstall, and I am able to uninstall all modules via the user interface, so the fix in #1017006: Unable to uninstall due to PHP fatals because hook_menu() is called by core when uninstalling did help us as we hoped.
Unfortunately, due to #943772: field_delete_field() and others fail for inactive fields it's still impossible to reinstall, because the fields already exist.
A simple workaround, which we should do, is just to enable the fields if they exist already. Or to delete them while creating them, or ...
The summary is still in #62.
Comment #87
recidive CreditAttribution: recidive commented@rfay: are you saying that the code in my patch isn't necessary? Or that #943772: field_delete_field() and others fail for inactive fields needs to be fixed in order for my patch to work correctly?
Comment #88
rfayI'm saying that your patch can't solve this problem until #943772: field_delete_field() and others fail for inactive fields lands. I haven't studied what more we need to do in uninstalls.
Comment #90
recidive CreditAttribution: recidive commentedok, so maybe it should be postponed then?
Comment #91
rszrama CreditAttribution: rszrama commentedThe idea of simply re-enabling the field if it already exists isn't a bad one, tbh. Could we still delete the field data or would we end up retaining, for example, all the data for product references attached to nodes even if we uninstalled and reinstalled?
Comment #92
rfayI spent a little time yesterday with the re-enabling of fields. I didn't quite get it going.
There are the problems Ryan pointed out in #91. Then there is also the problem that we do all the work on module enable, and we can't really be deleting data on module enable. It would have to be on install.
Comment #93
rfayThis is a throwaway patch that demonstrates part of how to ignore the fact that there are existing fields. I'm not going to continue with this approach, but didn't want to throw away the work.
Comment #94
rfayRyan and I talked about this today, and here's the approach I'd like to take.
Turn the script in #82 into something that can be incorporated into the hook_uninstall() of either each module that implements fields or in commerce_uninstall() itself. This is a very hackish thing to do, but Drupal core seems to leave us no other way at this time (although #943772: field_delete_field() and others fail for inactive fields does seem to be making some progress).
Reviews and work toward RTBC on #943772: field_delete_field() and others fail for inactive fields are also quite welcome.
Ryan, I note on the project page:
Let's change that to
"Warning: Due to core issues in Drupal 7 you cannot reinstall commerce after uninstalling it. Follow #858722: Cannot reinstall Commerce modules after uninstall due to field deletion failure for updates."
Updating issue title to represent current status.
Comment #95
chrisjlee CreditAttribution: chrisjlee commented#82 @rfay Finally got around to trying your script. I tried running your script but i'm getting syntax mysql errors.
Comment #96
rfay@chrisjlee, I assume you're saying you tried the script in #82. Please provide the actual errors.
Comment #97
jerry CreditAttribution: jerry commentedSubscribing.
Comment #98
latulipeblanche CreditAttribution: latulipeblanche commentedI used http://drupal.org/node/858722#comment-4467042 from rfay to reinstall the shipping module.
I made an issue here http://drupal.org/node/1183432 to improve the steps, if necessary and to get it done by simply un-install and re-install the module.
Comment #99
G. Noel Gross CreditAttribution: G. Noel Gross commentedGot snakebit by this too. Worth waiting it out or should I cut my losses?
Comment #100
rszrama CreditAttribution: rszrama commentedUntil #943772: field_delete_field() and others fail for inactive fields is fixed in Drupal 7 core, you'll have this issue for any module that depends on fieldable entities. However, how likely is it that you're going to have a production site where you need to uninstall and reinstall Commerce? If you do your testing and development in a sandbox site, you should be just fine.
fwiw, critical is reserved for bugs that actually break the functionality of a module. Uninstalling and reinstalling is enough of an edge case in production that if we need to escalate this, we can just put it to major. If that core issue doesn't go anywhere, I suppose we can implement a direct DB query workaround for the RC1.
Comment #101
Taxoman CreditAttribution: Taxoman commentedSubscribing
Comment #102
bmx269 CreditAttribution: bmx269 commentedSub
Comment #103
pardalman CreditAttribution: pardalman commentedSubscribing
Comment #104
vsmiller CreditAttribution: vsmiller commentedSharing some experience on this: one of our designers installed and found errors, then removed and attempted to re enable the module and encountered many of the errors discussed here, so I got involved in manual cleanup.
Their initial errors (not known then) came from our views module: we're running the dev version of views. Installing rc1 views for this site resolved that issue.
They were playing with both the beta and dev copies off an on, so I merged my sql queries into one big fix all. If your tables have a prefix, you'll need to add them. Process was run this group of queries, and then flush cache from config/performance screen (cleanup admin bar items, never bothered digging them up in db).
Not all of this may be neccessary, but it was effective. Note: our module was in a 'contrib' directory: adjust your path below if using the filename referencing queries. Hope it helps.
delete from `system` where filename like '%contrib/commerce/%';
drop table if exists `commerce_product_type`, `field_data_commerce_customer_billing`, `field_data_commerce_customer_address`, `field_revision_commerce_customer_address`, `field_data_commerce_display_path`, `field_data_commerce_line_items`, `field_data_commerce_order_total`, `field_data_commerce_product`, `field_data_commerce_total`, `field_data_commerce_unit_price`, `field_revision_commerce_customer_billing`, `field_revision_commerce_display_path`, `field_revision_commerce_line_items`, `field_revision_commerce_order_total`, `field_revision_commerce_product`, `field_revision_commerce_total`, `field_revision_commerce_unit_price`, `commerce_calculated_price`, `commerce_checkout_pane`, `commerce_customer_profile`, `commerce_customer_profile_revision`, `commerce_line_item`, `commerce_order`, `commerce_order_revision`, `commerce_payment_transaction`, `commerce_payment_transaction_revision`, `commerce_product`, `commerce_tax_rate`, `commerce_tax_type`, `field_data_commerce_price`, `field_revision_commerce_price`;
delete from field_config where field_name like 'commerce_%';
delete from field_config_instance where field_name like 'commerce_%';
delete from rules_config where name like 'commerce_%';
delete from rules_trigger where event like 'commerce_%';
delete from variable where name like 'commerce_%';
delete from `registry` where filename like '%contrib/commerce%';
delete from `registry_file` where filename like '%contrib/commerce%';
delete from `block` where module like '%commerce_%';
truncate `cache`;
truncate `cache_block`;
truncate `cache_bootstrap`;
truncate `cache_field`;
truncate `cache_filter`;
truncate `cache_form`;
truncate `cache_image`;
truncate `cache_menu`;
truncate `cache_page`;
truncate `cache_path`;
truncate `cache_rules`;
truncate `cache_token`;
truncate `cache_views`;
truncate `cache_views_data`;
Comment #105
rszrama CreditAttribution: rszrama commentedWell, I realized the easiest workaround was to create API functions that simply run a database query to activate a field that needs to be deleted. Then it'll work just fine with the normal Field CRUD API. Additionally, I have instance deletion functions that can activate a field, delete the instance, and then disable the field again if it was disabled to begin with. This works fine by clearing the field cache and was inspired by work I've been doing these last few days on disabling and reactivating customer profile reference fields on orders when profile type modules are disabled and reenabled.
There may be something I've missed, but as far as I'm concerned this issue is fixed. The only requirement is that the Commerce module has to remain enabled while the other modules are uninstalled. Then it can be safely removed. I've tested this with several uninstalls and reinstalls on the same site. The only module I see generating notices is Product Reference because a module key is going to be missing in the return value of field_info_field() at one point. This doesn't affect anything, and I don't see an obvious way to hide these notices.
As an added bonus, I also added variable deletion for variables from settings forms that were missing. We'll probably need to find some safe direct query to delete the settings of things like checkout panes where I set them based on some string pattern instead of an absolute, reproducible name on uninstall.
Commit: http://drupalcode.org/project/commerce.git/commitdiff/3ce93c5
Comment #106
rfayWow, fantastic. Thanks for taking on this thankless but important issue.
Comment #108
RKS CreditAttribution: RKS commentedI believe this issue still exists although just let me know if this is separate.
Enabled the Commerce modules, tested it out a bit, and then disabled them. The following night (tonight) I went to enable them again and get
DatabaseSchemaObjectExistsException: Table <em class="placeholder">commerce_calculated_price</em> already exists. in DatabaseSchema->createTable() (line 652 of /var/www/html/el/eldorain.com/includes/database/schema.inc)
My site was Ubercart so learning how to work with Commerce was not a one night task thus my need to enable and then disable them because in the morning people still need to be able to buy things and if I'm not done with the migration I have to enable Ubercart again until I can take the site down for maintenance. After reading through this issue I went and uninstalled everything I had the option of uninstalling but still get this error.
I do not do any work in MySQL and am not confident in using rfay's script or manually deleting tables. Plus, I don't even know what to do with the script or where in input the delete commands.
Comment #109
rfayI think this may be a separate issue; if you can recreate it, please file a new issue with explicit instructions on how to recreate the problem. I may have stumbled on this myself lately and not taken it seriously.
Comment #110
rszrama CreditAttribution: rszrama commentedHmm, it sounds like you had a general problem with your uninstallation, nothing due to field deletion failure. In your case, a module's table was not uninstalled, which Drupal should do automatically any time a module that implements hook_schema() is uninstalled (like the Product Pricing module does). There's really no telling at this point why yours was skipped, but if you were to uninstall again and make sure the table was deleted (do it manually if necessary) then it should reinstall just fine.
That said... you should really do your testing on a separate dev site. : )
Comment #111
RKS CreditAttribution: RKS commentedIt may be a separate issue but it does appear related. What happens, and I tested again, is that enabling the Commerce modules, disabling them, and then trying to re enable them causes the error. Going into the Uninstall tab does not give all the available modules to let the system uninstall. So obviously when I don't see it there I assume there isn't a problem.
Last night I went through and deleted all the tables and enabled the modules. Worked as expected. I then disabled them, and then tried to enable them again. No dice. You get the error. But there error is just the first one Drupal runs into and then quits the process (normal) but I did go through and delete just the table it returns the error for and try again. I just get another error.
Having the tables remain might be as designed but reading this post I thought it was supposed to delete on uninstall, but not all the modules offer that option under Uninstall.
I did make the mistake of testing on a site that wasn't dev but I was just doing the migration and didn't see this problem coming. I know I'm changing to Commerce so it wasn't just to try and get a feel for it or test it or whatnot I just wasn't expecting to not understand everything right off like that and have to revert back to UC to get my site up in the morning.
Comment #112
rfay@RKS, enabling and disabling was completely unrelated to this one, which was about uninstalling.
However, if you can recreate this on a clean commerce install (especially if you do it with commerce kickstart), please do open an issue and link to it here. Please give explicit instructions. Did you use drush or the web ui? What modules did you disable and re-enable, in what order? Can you do this, for example, by just disabling commerce_product and then re-enabling it?
Comment #113
chromix CreditAttribution: chromix commentedI had this problem with the latest version, but I just wanted to point out that uninstalling manually via vsmiller's solution at comment #104 worked like a charm.
Comment #114
rfayI wrote up an issue summary which tells the ins and outs of this one and points to the uninstall script options.
Comment #115
rfayBTW, if people are still needing to do this, we could roll a Commerce Destroy module. But I'm hoping people really don't need this.
Comment #116
sun#468208: Allow uninstalling modules with dependents by offering to recursively uninstall their dependents as well.
Comment #117
chx CreditAttribution: chx commentedRelation module would love to donate a few guns to a Module Destroyer ship.
Comment #118
derekw CreditAttribution: derekw commentedSorry to say but I could use Commerce Destroy
Comment #119
anderso CreditAttribution: anderso commentedCommerce newbie here. I've been playing around with it for a week. Don't like it too much and now want to disable it while trying out Ubercart instead. Have only been able to disable about half of Commerce. Rest is greyed out. So Commerce Destroy would be great ... Thanks.
Comment #120
djh007 CreditAttribution: djh007 commentedRemoving Commerce is slightly long-winded - took about 20 minutes. Here's how:
Backup your database :)
1) Under Modules page, disable as many Commerce modules as permitted.
2) Go to uninstall and uninstall the disabled modules.
Repeat until all modules are removed. This took about 7 goes, each time you uninstall a module, new modules become available to be disabled.
Notes:
Do NOT disable *Commerce* module until very last! It will throw an error.
I had to RUN CRON twice during uninstall. If you get to s stage where you can't delete more modules try that, and clearing caches.
Comment #120.0
djh007 CreditAttribution: djh007 commentedAdded a summary
Comment #121
shaisamuel CreditAttribution: shaisamuel commentedCheck #1480106: "unexpected error" crash site when activate order #3 for a solution that works !
Comment #122
MXTTrying to disable/re-enable commerce modules, I encountered the issue described here:
http://drupal.org/node/1272560#comment-6082564
Comment #123
bojanz CreditAttribution: bojanz commentedSee #1361562: Re-enabling Commerce causes a PHP Fatal Error.
Comment #124
Pere OrgaI don't think it's fixed. It happens in my installation.
Comment #125
bojanz CreditAttribution: bojanz commentedThis issue was about disable -> uninstall -> install.
Your issue is about disable -> enable, and it is being worked on here: #1361562: Re-enabling Commerce causes a PHP Fatal Error.
Comment #125.0
bojanz CreditAttribution: bojanz commentedAdded link to step-by-step uninstall
Comment #126
kiwad CreditAttribution: kiwad commentedSorry to comment on such an old issue, but needed to add something in case someone faces this problem.
I used #104 but it wasn't enough,
1. I also had to delete few tables in the database named like this : field_deleted_data_134, field_deleted_data_20... field_deleted_revision_20 ...
2. I also had to delete some entries in menu_links
delete from `menu_links` where `link_path` like "%commerce%"