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.

metatags_quick_issue.jpg146.93 KBetavener
Members fund testing for the Drupal project. Drupal Association Learn more


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

function field_cron() {
  $limit = variable_get('field_purge_batch_size', 10);
chris.smith’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.


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


$modules = array('metatags_quick');

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?


mexicoder’s picture

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

mudasirweb’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


that were preventing it from being disabled. I navigated to


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.

computerbarry’s picture

Slightly curious why everybody is removing it?
I thought this is a much needed module for every site regarding metadata, is everybody switching to a different module, a new way of adding your sites metadata?


webservant316’s picture

Great as Drupal 7 is, it is amazing to me there this meta data module does not even work. I just manually added meta data in my template file as follows...

function YOUR_THEME_preprocess_html(&$vars) {
//other stuff already here
// meta tags added by me
$_meta = array( '#type' => 'html_tag', '#tag' => 'meta', '#attributes' => array( 'name' => 'description', 'content' => 'your words here', ) );
drupal_add_html_head($_meta, 'description');
$_meta = array( '#type' => 'html_tag', '#tag' => 'meta', '#attributes' => array( 'name' => 'keywords', 'content' => 'your words here', ) );
drupal_add_html_head($_meta, 'keywords');
$_meta = array( '#type' => 'html_tag', '#tag' => 'meta', '#attributes' => array( 'name' => 'robots', 'content' => 'index, follow, noarchive', ) );
drupal_add_html_head($_meta, 'robots');
$_meta = array( '#type' => 'html_tag', '#tag' => 'meta', '#attributes' => array( 'name' => 'copyright', 'content' => 'all rights reserved', ) );
drupal_add_html_head($_meta, 'copyright');   
vls’s picture

computerbarry wrote
> Slightly curious why everybody is removing it?

In my case, one day I tried disabling it on one of our sites prior to upgrading it, and it would not disable. This raised red flags. I don't want any module that cannot be disabled. What if I just find an alternative module I like better or, much worse, there is a big security hole found and the author never fixes it for whatever reason?

I changed to the metatag module (http://drupal.org/project/metatag) which is quite feature rich and appears to be the most popular. At first I thought I liked the metatags_quick module better because it appeared simpler on the surface and seemed to fulfill my needs, but after working more with metatag after the metatags_quick disable problem, I discovered that I actually like metatag better. It integrates nicely with per-node settings at the bottom of the edit page along with the Menu settings, etc., and it has full control over all the default settings to automatically generate meta tags.

BTW, also I tested disabling and re-enabling the metatag module and it did it gracefully with no loss of data so far as I can tell.

computerbarry’s picture

It integrates nicely with per-node settings at the bottom of the edit page along with the Menu settings, etc.

Thats what I like to hear :)

I see your point with a strong case against this module.

I changed to the metatag module (http://drupal.org/project/metatag) which is quite feature rich and appears to be the most popular.

I'm also looking to setup metadata myself for a new Drupal project, what you suggest sounds like a much better option I'll give this a look.

Thanks for sharing!


DrupalDavie’s picture

The only reason I want uninstall the module, is to hide the "path-based metatags" tab on the front page. Surely there is an easy way to configure the module to make this tab go away? I can't believe going through the recommended, complicated process of uninstalling the module is the only way to resolve the problem.

I read https://www.drupal.org/node/1433138 and don't understand how to implement the patch. Is there something in Configure-Search and Metadata- Meta tags (quick)-settings that can do this? There must be a simple way.

Well, a week later, and I found this solution: Go to Home-Administration-Meta tags (quick) settings-Global Settings tab-Select "Hide Path-based Metatags tab" There was an easy way!

computerbarry’s picture

Thanks for your update DrupalDavie.
Myself, I've downloaded Metatag which has some powerful features and seems to be working ok, lots of options easily customizable.

Regarding your update, I read somewhere that Drupal core RDF module causes some conflict with Metatag, the RDF module seems to be what adds Drupal's metadata, which is removed once you disable it. If this is of any help to yourself or people looking into this.


Goekmen’s picture

#18 worked for me!

darrell_ulm’s picture

Has anyone tried #18 and -not- have it worked?
Did anyone need to resort to custom PHP code to uninstall the Drupal module?

holyfire’s picture

Wow I think comment #29 hits the nail on the head. No matter a user needs to have the ability to uninstall a module in the interface with housekeeping taking care the backend and a warning acknowledging that data loss will occur with removal.

To me this is a conscious decision to disregard the end user.

In addition it should be very clearly documented on the project description that this module cannot be easily uninstalled (or ever installed depending on the skill of the site builder).

I appreciate the work done her but this is something that either should be really well documented and/or fixed. Another simple solution would be to add some sort of export import functionality.

osopolar’s picture

Title: Can't uninstall meta tags (quick) » Document how to uninstall Meta tags quick
Category: Bug report » Feature request
Priority: Major » Normal

The same as in #18 but with drush:

1. Delete the fields: drush ev "field_delete_field('meta_canonical'); field_delete_field('meta_description'); field_delete_field('meta_keywords');"
2. Run cron to actually delete the data and fields drush cron && drush cron. If there are lots of entries you need to run cron more often or purge the data manually by calling drush ev "field_purge_batch(5000)"; see also http://drupal.stackexchange.com/questions/38328/clean-deleted-field-from.... BTW: If you migrate metatags quick to metatag module, the migration script in #1282806: Upgrade path: Meta tags quick will delete the old metatags_quick records.
3. You should now be able to uninstall the module (drush dis metatags_quick && drush pm-uninstall metatags_quick).

I agree with valthebald that this shouldn't (and couldn't) happen automatically. The expected behavior for disabling modules is that data don't get lost. But you can't disable the module with prior deleting data. But there should be some help in the readme.

RAWDESK’s picture

#18 very simple, yet effective method
What i do not understand is why the author of this module is not using this method as a fork to work on a customized uninstall function exposed to the modules config UI ?

valthebald’s picture

@RAWDESK: the catch here is when to perform these actions. You, as the final user, can decide to completely uninstall the module, so you first delete fields, then disable the module, then uninstall it.
Module disabling should leave its data intact =>module can delete its own fields only on uninstall => Drupal doesn't allow module to be disabled if there is data => cursed circle

RAWDESK’s picture

i have no time nor the intention to have a discussion on this.
Me, as the final commentor here, am just suggesting a solution that might work for all of us :
- document in the installation notes that disabling (&uninstalling) requires fields deletion
- support fields deletion from within the config UI by the proposed fork implementation as suggested in #18
That's it! Have a nice day :)

vbard’s picture

#39 helped, thanx!
But had to additionally delete meta_meta_title field the same way.