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:


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".

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

Scott J’s picture

Is there a list somewhere of all Commerce database tables? I want to delete them all so I can do a clean reinstall.

rszrama’s picture

The 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_.

Scott J’s picture

Thanks 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 ...?

rszrama’s picture

I'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

bojanz’s picture

Assigned: Unassigned » bojanz

Totally forgot about this. The issue is from July.

Will handle it in the near near future.

rszrama’s picture

hehe 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

bojanz’s picture

Now 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...

lathan’s picture

Not 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

The following modules will be uninstalled: commerce_product_ui
Do you really want to continue? (y/n): y
PHP Fatal error:  Call to undefined function commerce_product_types() in /var/www/D7/sites/all/modules/commerce/modules/product/commerce_product_ui.module on line 25


The following modules will be uninstalled: commerce_order_ui
Do you really want to continue? (y/n): y
PHP Fatal error:  Call to undefined function commerce_order_new() in /var/www/D7/sites/all/modules/commerce/modules/order/commerce_order_ui.module on line 21

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.

scotwith1t’s picture

it 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.

rszrama’s picture

Yeah, 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.

scotwith1t’s picture

thanks 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!

rszrama’s picture

You'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.

bojanz’s picture

Uninstalling 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...

scotwith1t’s picture

thanks 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.

bojanz’s picture

Next 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 ;)

rszrama’s picture

lol That's awesome. Thanks for keeping up with those issues, Bojan. : )

aidanlis’s picture

Uninstalling 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.

Scott J’s picture

I just tried uninstall, and it does give a warning:

The following modules will be completely uninstalled from your site, and all data from these modules will be lost!

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.

rszrama’s picture

Don'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.

recidive’s picture

Status: Active » Needs review

I'm not sure I covered all fields. But here's a start:

https://github.com/recidive/drupalcommerce/tree/858722

recidive’s picture

Assigned: bojanz » recidive
Issue tags: +dcsprint5
rszrama’s picture

Issue tags: +beta blocker

Tagging.

recidive’s picture

I 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:

[14-Feb-2011 12:09:56] PHP Fatal error:  Call to undefined function commerce_tax_rates() in /Users/henrique/Workspace/drupalcommerce/modules/tax/commerce_tax_ui.module on line 40
recidive’s picture

The 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.

rszrama’s picture

Wait... 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.

recidive’s picture

Yes, 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?

rszrama’s picture

I'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. : )

recidive’s picture

I'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

recidive’s picture

recidive’s picture

I'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.

rszrama’s picture

Issue tags: -beta blocker

As 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.

aidanlis’s picture

The core bug is pretty easy to workaround, a quick if (module_exists('')) in hook_menu will do it.

uberhacker’s picture

Basic SQL uninstall instructions:

  • show tables like '%commerce%';
  • drop every table displayed
  • 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 variable where name like 'commerce_%';
  • show tables like 'cache%';
  • truncate every table displayed
edg1’s picture

hi uberhacker is it using the same syntax in mysql 5 ?
i'm getting trouble with drop every table displayed

recidive’s picture

@edg1: funny, this may be due to "drop every table displayed" not being a SQL command but a human one.

Tebb’s picture

Following.

uberhacker’s picture

Yes, 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.

edg1’s picture

Tough it was an easy command.. could be one ;-)

edg1’s picture

isn't there a command like drop tables like '%commerce%';
??

edg1’s picture

a 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;

edg1’s picture

OK , 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).

rszrama’s picture

Whoa, yeah, you definitely shouldn't delete the cache tables. The keyword there is "truncate", i.e. empty, not drop.

Tebb’s picture

@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;

edg1’s picture

Can i fix this in some way ?

rszrama’s picture

Recreate 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.

Tebb’s picture

@edg1

Perhaps you could restore your backup?

This module is very good http://drupal.org/project/backup_migrate for creating scheduled and manual backups.

edg1’s picture

yeah 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

Scott J’s picture

FileSize
619 bytes

I have a cache_image but neither of the other two. What module could they be from?

edg1’s picture

@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

edg1’s picture

i 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.

Scott J’s picture

That was from my own D7 installation. I just exported it using phpMyAdmin.

edg1’s picture

ok thanks, i got everything fixed now.. ;-)
I learned my lesson for backing up tings!!!

rcross’s picture

Just 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.

aidanlis’s picture

@rcross, no.

rcross’s picture

@aidanlis - other discussions around this point have pointed to this core discussion - http://drupal.org/node/943772#comment-4197688

bojanz’s picture

Status: Needs review » Postponed

Yes, 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.

rfay’s picture

A workaround that looks like it's going to go for me. Before reinstalling:

drop table field_data_commerce_unit_price;
delete from field_config where field_name="commerce_unit_price";

Edit - pseudocode:

DELETE FROM field_config WHERE field_name LIKE "commerce%";
DELETE FROM field_config_instance WHERE field_name LIKE 'commerce%';
show tables like "field_data_commerce_%";
foreach table
  drop table $table;

show tables like "field_revision_commerce_%";
foreach table
  drop table $table;
bojanz’s picture

Deleting the matching row from field_config_instance would be a good idea then.

rfay’s picture

Thanks for that, @bojanz. I updated #57

rfay’s picture

Getting 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.

rfay’s picture

This 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.

rfay’s picture

Title: The uninstall routines should delete previously created fields » Uninstall problems: Deleting fields, PHP Fatals because of hook_menu, Don't use Drush to uninstall
Component: User experience » Developer experience

Per 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:

Jerome F’s picture

Having 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.

NPC’s picture

Subscribing.

David D’s picture

The 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.

rfay’s picture

Title: Uninstall problems: Deleting fields, PHP Fatals because of hook_menu, Don't use Drush to uninstall » Multiple uninstall problems: Deleting fields, PHP Fatals because of hook_menu, and drush uninstalls make it even worse
keithm’s picture

subscribe

heyyo’s picture

after 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 :

Additional uncaught exception thrown while handling exception.
Original

PDOException: SQLSTATE[42S02]: Base table or view not found: 1146 Table 'essence_com.commerce_product_type' doesn't exist: SELECT * FROM {commerce_product_type}; Array ( ) in commerce_product_ui_commerce_product_type_info() (line 320 of /home/quickstart/websites/essence.com/sites/all/modules/commerce/modules/product/commerce_product_ui.module).
Additional

PDOException: SQLSTATE[42S02]: Base table or view not found: 1146 Table 'essence_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/essence.com/sites/all/modules/commerce/modules/tax/commerce_tax_ui.module).
rszrama’s picture

Issue tags: -dcsprint5 +dcsprint6

@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.

rfay’s picture

@rszrama, except I don't think we can ever do a successful uninstall can we?

rszrama’s picture

@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?

David D’s picture

I 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.

rfay’s picture

Hmm, @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.

heyyo’s picture

it 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 ?

aidanlis’s picture

@heyyo What are you talking about?

heyyo’s picture

@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)

bojanz’s picture

That has nothing to do with this issue.
A feature is still a module.

aidanlis’s picture

You don't have to use the profile heyyo, that is for "kick starting".

rszrama’s picture

fwiw, even if you make a Features module that installs the Commerce modules, uninstallation still won't work if you try to uninstall that Feature.

heyyo’s picture

@rsrama I hope that it will work one day...

rszrama’s picture

It will. : P

Dries is back in action on committing patches to D8 that will be backported to D7 to resolve these issues.

rfay’s picture

FileSize
1.06 KB

Here 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.

bojanz’s picture

Title: Multiple uninstall problems: Deleting fields, PHP Fatals because of hook_menu, and drush uninstalls make it even worse » Uninstall problems when deleting fields, and drush uninstalls make it even worse

The hook_menu() fix was committed to D7 last friday.
This leaves the field uninstall and drush problems remaining.

rfay’s picture

And Yay! Thanks, @bojanz, for the followup there (and lots of places like VBO too!) You're a rock star.

recidive’s picture

Status: Postponed » Needs review
FileSize
3.2 KB

Here 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.

rfay’s picture

Status: Needs review » Needs work

@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.

recidive’s picture

@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?

rfay’s picture

I'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.

recidive’s picture

ok, so maybe it should be postponed then?

rszrama’s picture

The 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?

rfay’s picture

I 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.

rfay’s picture

This 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.

rfay’s picture

Title: Uninstall problems when deleting fields, and drush uninstalls make it even worse » Cannot reinstall Commerce modules after uninstall due to field deletion failure

Ryan 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:

WARNING: Due to core issues in Drupal 7 regarding menu rebuilding and field disbaling, the uninstall process has not been resolved. Please use caution when installing and/or be prepared to wipe and rebuild your site. Follow #858722: Uninstall problems when deleting fields, and drush uninstalls make it even worse for updates on the process.

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.

chrisjlee’s picture

#82 @rfay Finally got around to trying your script. I tried running your script but i'm getting syntax mysql errors.

rfay’s picture

@chrisjlee, I assume you're saying you tried the script in #82. Please provide the actual errors.

jerry’s picture

Subscribing.

latulipeblanche’s picture

I 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.

G. Noel Gross’s picture

Priority: Normal » Critical

Got snakebit by this too. Worth waiting it out or should I cut my losses?

rszrama’s picture

Assigned: recidive » Unassigned
Priority: Critical » Major
Issue tags: -dcsprint6 +rcblocker, +dcsprint7

Until #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.

Taxoman’s picture

Subscribing

bmx269’s picture

Sub

pardalman’s picture

Subscribing

vsmiller’s picture

Sharing 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`;

rszrama’s picture

Status: Needs work » Fixed

Well, 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

rfay’s picture

Wow, fantastic. Thanks for taking on this thankless but important issue.

Status: Fixed » Closed (fixed)

Automatically closed -- issue fixed for 2 weeks with no activity.

RKS’s picture

Status: Closed (fixed) » Active

I 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.

rfay’s picture

I 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.

rszrama’s picture

Status: Active » Closed (fixed)

Hmm, 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. : )

RKS’s picture

It 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.

rfay’s picture

@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?

chromix’s picture

I 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.

rfay’s picture

I wrote up an issue summary which tells the ins and outs of this one and points to the uninstall script options.

rfay’s picture

BTW, 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.

sun’s picture

chx’s picture

Relation module would love to donate a few guns to a Module Destroyer ship.

derekw’s picture

Sorry to say but I could use Commerce Destroy

anderso’s picture

Commerce 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.

djh007’s picture

Removing 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.

djh007’s picture

Issue summary: View changes

Added a summary

shaisamuel’s picture

MXT’s picture

Status: Closed (fixed) » Active

Trying to disable/re-enable commerce modules, I encountered the issue described here:

http://drupal.org/node/1272560#comment-6082564

bojanz’s picture

Status: Active » Closed (fixed)
Pere Orga’s picture

Version: 7.x-1.x-dev » 7.x-1.4
Status: Closed (fixed) » Active
FileSize
10.67 KB
10.83 KB

I don't think it's fixed. It happens in my installation.

bojanz’s picture

Status: Active » Closed (fixed)

This 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.

bojanz’s picture

Issue summary: View changes

Added link to step-by-step uninstall

kiwad’s picture

Sorry 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%"