Hi, I'm trying to uninstall the 'meta tags (quick)' module from my site. I've uninstalled the 'upgrade from nodewords' and 'extra functionality' (the two modules dependent on it.). However, I can't uninstall the main module because the check box is disabled. I could just remove the module folder, but don't want to break the site.

Please see my screenshot attached. Help would be appreciated.

Files: 
CommentFileSizeAuthor
metatags_quick_issue.jpg146.93 KBetavener

Comments

etavener’s picture

Apologies. I hadn't realised that I needed to remove the fields from my content types as well. Was there no way of doing this automatically?

valthebald’s picture

Status:Needs work» Closed (works as designed)

It's a bit dangerous to remove module-related fields (with all data) automatically, so - no

alby111’s picture

Hi, Im having the same problem
I'm trying to uninstall the 'meta tags (quick)' module from my site. I've uninstalled the 'upgrade from nodewords' and 'extra functionality' (the two modules dependent on it.). However, I can't uninstall the main module because the check box is disabled.

I removed Meta fields from my content types, the other fields are the ones I created , what else do I have to do?

valthebald’s picture

Try to clean Drupal cache, this will probably clean dependencies set by field data.

Murz’s picture

Got the same issue, remove all metatags fields manually from every entity type, so in "Field list" there are no any metatag field seen. Also clear Drupal cache.
But can't disable and uninstall module, in module I see string "Drupal (Fields pending deletion),".

Murz’s picture

After removing all fields I have found info about fields in tables:
field_config
field_config_instance
I have removed manually records from this tables, after that I can successfully disable and uninstall module.

Murz’s picture

Hmm, also I have find tables:
field_deleted_data_48
field_deleted_data_49
field_deleted_revision_48
field_deleted_revision_49
those id are like in field_config field ids. So this tables must be removed manually too. But, I think, better is to find how correctly remove all of this data via Drupal API or in admin panel.

Murz’s picture

Seems we must run cron many times for cleanup this tables, because after each cron run Drupal removes 10 items:

<?php
function field_cron() {
 
field_sync_field_status();
 
$limit = variable_get('field_purge_batch_size', 10);
 
field_purge_batch($limit);
}
?>
OPIN’s picture

Similar problem on this end. I can't get rid of the field "Rule Configuration" from our Fields List.

tomcatuk’s picture

Sorry, I'm trying to uninstall this module too. Do I really have to manually remove the tables referenced in #6 & #7 to get rid of it?

tuyre’s picture

Installed metatags_quick a few days ago. Didn't use it yet, and decided to remove it in favour of another solution. have attempted the above suggestions to little avail.

Can someone (maybe the author of metatags_quick) please kindly post a set of clear instructions how to get rid of this module once and for all? I don't think I've had this muchy of a problem removing any other module. Certainly frustrating.

Thanks

kehogo’s picture

I was able to disable / uninstall metatags_quick by deleting all the meta tag fields from my content types and then running cron a dozen or so times, then clearing the cache, and then I used drush to disable it.

Thanks @Murz for the cron suggestion.

And, thanks @valthebald for the module!

digitalecartoons’s picture

Status:Closed (works as designed)» Active

Opened it again as it needs a major update. Not a workaround by clearing caches or running crons multiple times.
Did the module uninstall option: it said the module was uninstalled but it still appeared in the module section.
Deleted all fields: still couldn't deselect the meta tags quick option as seen in the screenshot.
Had to delve in the database and remove all rows with 'meta' in them.
Removed the meta tags quick folder in de modules folder
Finally everything was gone.

Running cron a few times might have helped unselecting the module but a module that takes so much work to uninstall, even having to go through the Drupal database, doesn't deserve this topic to be closed. It demands a major update!

In the mean time I'll try the regular meta tags module...

valthebald’s picture

Status:Active» Closed (works as designed)

People. Seriously. Please stop that.
The issue with inability to disable module that provides fields, has nothing to do with metatags_quick, but belongs to the core. More than that, that was something added in 7.x series, not in original 7.0 release (I think this happened somewhere at 7.4 or 7.5)
"Did the module uninstall option: it said the module was uninstalled but it still appeared in the module section." - well, you expect to see the modules that were never installed, don't you? So, what's the point?
If you choose to use metatag module, that's your choice.

stevep’s picture

Yes we call all do a search, but for those wanting quick reference

the function field_cron (post #8) is in core modules/field/field.module

I don't know if it helped but I increased 10 -> 30, ran cron, flushed cache and now can uninstall the meta tags quick module. Reset back to 10.

Checked (shared) server load -- barely any different cpu usage etc.

deanflory’s picture

Here are the steps I had to perform to disable this one module:

1) Delete all instances of all meta_ fields from all entities.
If you're using Display Suite you can view and choose to "Manage Form" for all entities (I think all entities) on this Display Suite List admin page: /admin/structure/ds
One can also view all fields and where all instances are used on the Field list page here: /admin/reports/fields

Once that step was completed I was still unable to disable the module on the Modules page. I ran cron at least 16 times as I had a number of entity types.

2) I then deleted all meta_ rows from the tables "field_config" and "field_config_instance" using phpMyAdmin.

The Field list page still notes these field dependencies/instances were still in place for those fields even though there were no Meta tag (quick) fields on the OG membership type default Manage Form page. Note that it states "OG membership type" and the only membership type that was in place was the default which is "OG membership type default", thus clearly a difference of "default" being missing. Rules configuration, ah, didn't even try to remove those, shouldn't have to, should be part of the module uninstall process.

meta_abstract (module: ) , OG membership type, , , , Rules configuration
meta_canonical (module: ) , OG membership type, , , , Rules configuration
meta_copyright (module: ) , OG membership type, , , , Rules configuration
meta_description (module: ) , OG membership type, , , , Rules configuration
meta_keywords (module: ) , OG membership type, , , , Rules configuration

3) Once this second step was completed those field dependencies on the Field list page were still there, but I was indeed able to deselect Meta tags (quick) on the Modules page. From there I was able to successfully save the Modules page form and disable the module, then uninstall the Extra functionality module, then uninstall the the Meta tags (quick) module, then remove the module folder from the server (quick). The result on the Field list page was now gone for the meta_ fields, unsure if the actual fields reported as still dependent had their instances removed.

I agree with everyone commenting on this issue except for the module maintainer that there appears to be a few missing steps to module disabling/uninstalling that would make the user experience more pleasant and productive. I completely understand removing all the fields from all entities, but the fact that field dependencies were still in place on the Field list page shows there are hidden dependencies on forms mere mortals cannot access through the Field list or the Display Suite List pages. No Drupal user should have to remove rows from tables in the database manually to disable a module, defeats part of the purpose of using "modules" being easy enable, easy disable. I figure now I have some lingering code for those OG membership type and Rules configuration issues that will never get cleaned-out and just hoping they don't cause errors as I installed this module 12 months ago and can't go back to a backup that has all my effort but not this module.

I believe this issue should stay open even if the maintainer believes this removal process is somehow acceptable, even though it may not remove everything and requires considerable time and effort on the end user's part above simply disabling it.

Keeping this issue open will make it easy and (quick) for users to find when perusing the issue queue instead of having to search for an issue the maintainer deems is "closed (works as designed)", and thus hidden from the open issues queue.

Thanks for the module valthebald. I'm sure the per-field functionality can be useful to those that only need a few key meta tags and custom formatters.

glass.dimly’s picture

Status:Closed (works as designed)» Active

Uninstalling is not a feature, it's a module requirement. Please update your module to allow for uninstallation (all the fields were added programmatically, they can be removed!) or make a note of the uninstallation process in the readme. Thank you for your work on this module!

nicholasThompson’s picture

I just ran this via /devel/php

<?php
field_delete_field
('meta_canonical');
field_delete_field('meta_description');
field_delete_field('meta_keywords');

$modules = array('metatags_quick');
module_disable($modules);
drupal_uninstall_modules($modules);
?>

No need to run Cron or anything - however that MAY be because I'd not put any data into it yet?

valthebald’s picture

Version:7.x-2.2» 7.x-2.x-dev

@nicholasThompson: nice trick, but yes, I think that's because you don't have data in your installation.
Actually, it is possible for module to report to Drupal that there is no data, but this can lead to data loss.
I still don't see any viable solution of disabling/uninstalling module that provides non-empty field data. If someone can point me to solutions in other modules, I would be happy

mexicoder’s picture

While this isnt a perfect situation it isnt unique to this module. Please dont start removing the module without clean up or start to delve into the db directly. Its a route to disaster. Just use the ui to delete the fields then run cron as many times as it takes to clean the fields pending deletion. This is the safest solution until the issue is resolved.

webservant316’s picture

Issue summary:View changes

this module is off limits to me until it can be disabled from the ui. however, currently I cannot diable the thing due to unwittingly enabling the rules integration. I think I am just restoring from backup.

brodiebrodie’s picture

#18 worked for me... thank you

bgrega’s picture

I'm a newbie at this stuff. I'm totally NOT understanding what anyone is talking about with this module as far as removal. But, I do know I need to remove it, is there a step by step set of instructions for removal as of yet?

Thanks

mexicoder’s picture

Hi @bgrega all you should need to do is in #20

logichacker’s picture

I uninstalled it easily follow this

Remove all the fields created by this module, like if you the meta tag fields to nodes or pane, try to delete all the fields one by one from content type of each node, then you uncheck the checkbox.

vls’s picture

I had the same problem. I finally got it to allow me to disable it. All the extra cache flushes, etc., suggested by others had no effect. The solution was, as mentioned by deanflory in #16,

You must delete all instances of all meta_ fields from all entities.

In my case, In addition to deleting the metatag fields from all content types, I had fields still in

Structure->Taxonomy->Tags

that were preventing it from being disabled. I navigated to

admin/structure/taxonomy/tags/fields

and deleted the metatag quick fields. At that point, it finally allowed me to disable the module.

vilepickle’s picture

This is just bad practice. The module needs to be uninstallable after being used, regardless if it's "dangerous".

Stuff like this turns people off of Drupal. Seriously.

mexicoder’s picture

@vls, @vilepickle did you read and perform the steps in #20 ?

vilepickle’s picture

Yeah, I did. I still stand by that this module should be removing its own cruft and being able to be uninstalled like every other module.

Note that if we're worried about "data loss", prompting a user before removing their generated fields makes the most sense.