Unable to uninstall Fivestar. Required by Drupal (Fields Pending Deletion).

This is not a bug.

If you want to uninstall, you will see there's a a link called Field list. If you click on that link you will see the entity types that have a fivestar field in it. You must remove the fields before uninstalling.

I'm honestly not sure when the feature when in. But this seems to be a requirement not before removing uninstalling field modules.

I just want to disable the module, not remove it, So what should I do? I cant see any option to do this.
Thanks

Faced the same problem with another module (Organic Groups). Probably this issue belongs to D7 core?

Run cron. That will complete the deletion.

Run cron MULTIPLE times, I should add. In my case, 5 times wasn't enough, so I thought something is broken.

So how do you only disable a module that is linked to the field list in this way?

dixhuit, you have to delete all this module-provided fields (and all data in it, obviously), and then run cron multiple times. After that you'll be able to disable this module (though, de-facto, it is nearer to uninstallation, as you have to delete all data). Now you can't disable field-providing module, but to store the data in it's fields. This controversial behaviour was introduced in core after heated debates.

Blimey. Well that makes troubleshooting a little tougher these days then.

So to upgrade such a module you no longer have to disable it? Just overwrite the previous module directory and run update.php?

Well, I have never disabled modules before the upgrade. Usual I do use Drush, though, it makes all routine tasks for me.

And yes, there are one method to disable field-providing module for testing purposes without deletion of it's fields - you should delete module's folder. But it is suitable not for all modules. Most complex and deep-integrated with your site will kill it after such "shutdown".

This really isn't a fiveatar issue. So I'm closing this.

#6 - Running cron multiple times did the trick!

No amount of cron runs (100's) worked for me.

So I removed the module from my modules directory, ran cron, then put it back, and it let me disable it. I then ran the Uninstall.

#5 Thanks for the Cron hint. Worked for me.

So I removed the module from my modules directory, ran cron, then put it back, and it let me disable it. I then ran the Uninstall.

Good tip. This has worked for a couple modules now where "Fields pending deletion" seems to be stuck.

So, How can I upgrade this module if I can not uninstall it first, really confused...

I have the same problem with latest fivestar-dev version.
I deleted the fields, I run cron, I cannot disable it

Thank u, This fixed my problem.

this solution worked for me #1530812: Field collection cannot uninstall cleanly due to "Required by: Drupal (Fields pending deletion)"

Running cron did the trick -- thanks!

#14 worked for me. Thanks

hi everyone. I am currently using 7.x-2.0-alpha2 in production and wanted to install to the latest dev to get some of the newer functionality that ties in with the micodata module. If I were to wait until this module goes from dev to a recommeded release then would I be able to run the update automatically without having to delete the fields, re-install the module, and then recreate the fields?

Also, it sounds like if I want to go from 7.x-2.0-alpha2 to the 7.x-2.x-dev version then I need to actually delete those fields from my custom content types that have data (as explained in previous posts), then update the module, and then somehow reimport all the lost fivestar data into the database that I have lost from deleting those fields? Can someone confirm that data has to be deleted and then manually reimported if we want to keep this in the database? That seems like a lot of work just to get the newest dev module. If the next recommended release upgrades without this drawback then I will wait for it, if not then I will just do it now.

thanks for your input.

thanks worked for me!

run sql query:

DELETE FROM `field_config` WHERE `field_config`.`deleted` = 1;

#26 worked for me, thank you!

#6 worked for me.. I had a similar issue with Vote Up/Down module for D7.

#26 works.Had the same error from a different module. I am using Postgresql and the same query would read;

DELETE FROM field_config WHERE field_config.deleted = 1;

>you have to delete all this module-provided fields (and all data in it, obviously), and then run cron multiple times. After that you'll be able to disable this module (though, de-facto, it is nearer to uninstallation, as you have to delete all data). Now you can't disable field-providing module, but to store the data in it's fields. This controversial behaviour was introduced in core after heated debates

*facepalm* Did whoever won this debate do so by pulling out a loaded firearm?

#26 thanks!

#26 worked for me, but I added an additional clause to make sure that only the rows I was concerned with would be deleted. And before I ran that, I first ran a SELECT version of the query, replacing DELETE with SELECT *. That way I was able to eyeball the affected rows before doing the irreversible delete.

SELECT * FROM field_config WHERE (field_config.deleted = 1) AND (field_config.type = "video_filter");

When I was comfortable with the affected rows, I ran this...

DELETE FROM field_config WHERE (field_config.deleted = 1) AND (field_config.type = "video_filter");

#5: Worked for me.Thank You

Worked for me when I ran this several time:

drush php-eval 'field_purge_batch(100);'

See https://api.drupal.org/api/drupal/modules%21field%21field.crud.inc/funct...

Thanks, #26 worked for me!

#14 worked (for some other random module), nice trick, thanks!

#26 worked for me, yes!

Had to run cron 8 times (Radioactivity).

This has nothing to do with fivestar, it is not a bug, and it should remain closed.

#26 worked for me. This bug can be somehow connected with the situation when you have same field used in more content types.

Thanks! #34

many thanks #14

#34 worked! Thanks

Notice that this issue has been posted in issue queue for a sandbox project without code. It's not an issue queue to ask support for, or post bugs in, Drupal core or third-party modules.

Despite the project name, this sandbox project is not linked to Drupal core in any way, and it may be removed at any time.

In my case, I first manually deleted the fields in the entity type. Then I manually emptied (not deleted!) the corresponding data tables in the database and subsequently ran the cron job for field purging ("Purges deleted Field API data"). I'm using ultimate_cron. It was enough to run the cron job once.