Can't install flag module via Drush

It sounds like your database somehow has been put into a state where Flag module thinks its been installed (it still has an entry in the "system" database table) but the actual Flag database tables are missing. You can fix this by disabling the Flag module and then completely uninstalling it by visiting admin/modules/uninstall. The module must be disabled before it can be uninstalled. Then enable the module again and it will create all its tables from scratch.

Same problem here. Plain impossible to install module. The table doesn't get created before it's used. The 'hook_install' function is empty... no dependency on Features... How is the table created?

The table doesn't get created before it's used. The 'hook_install' function is empty... no dependency on Features... How is the table created?

Modules no longer need to have a hook_install() in D7. The contents of hook_schema() are automatically created when enabling any module. Considering thousands of sites use Flag module for D7, I'm certain that this module installs properly. I suggest following the steps in #3 above to completely uninstall and reinstall the module.

I came across this issue on a recent site. I got the above errors when trying to install via drush, but installing through the UI worked just fine. Will post back if I find more.

It happens for example if by using an installation profile, you instantiate features with flag components used (for example in Views) in the .info file of the profile. (The same thing happens with Views containing Media, for example). Reference : #1311828: Installation fails with SQLSTATE[42S02]: Base table or view not found: 1146 Table 'database.media_type' doesn't exist.

Changing back to support request.

If this is a bug in flag, please feel free to change it back, but only if you can provide clear and precise steps to reproduce the problem.

@simon_georges I see the same thing. Did you find a way around it?

@diwant, by changing the order of module installation, I managed to have everything working smoothly. Maybe updating to the last version of the module changed some things too...

When Upgrading from D6 to D7 I got this error.
DB has flag table. No flags table.

Edit: Sorry, My error was because of another fbss_flag module.

I had this issue and due to the errors I couldn't even get to the module admin page mentioned in #3 I worked around this by copying the schema from another site for the 4 flag tables to the messed up one and that allowed the page to load to disable and uninstall after that.

Hope that helps, here's the create syntax as well as of7.x-3.5:

-- Create syntax for TABLE 'flag'
CREATE TABLE `flag` (
  `fid` smallint(5) unsigned NOT NULL AUTO_INCREMENT COMMENT 'The unique ID for this particular flag.',
  `entity_type` varchar(128) NOT NULL DEFAULT '' COMMENT 'The flag type, such as one of "node", "comment", or "user".',
  `name` varchar(32) DEFAULT '' COMMENT 'The machine-name for this flag.',
  `title` varchar(255) DEFAULT '' COMMENT 'The human-readable title for this flag.',
  `global` tinyint(4) DEFAULT '0' COMMENT 'Whether this flag state should act as a single toggle to all users across the site.',
  `options` text COMMENT 'The options and configuration of this flag.',
  PRIMARY KEY (`fid`),
  UNIQUE KEY `name` (`name`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8 COMMENT='All available flags in the system.';

-- Create syntax for TABLE 'flag_counts'
CREATE TABLE `flag_counts` (
  `fid` smallint(5) unsigned NOT NULL DEFAULT '0',
  `entity_type` varchar(128) NOT NULL DEFAULT '' COMMENT 'The flag type, usually one of "node", "comment", "user".',
  `entity_id` int(10) unsigned NOT NULL DEFAULT '0' COMMENT 'The unique ID of the content, usually either the cid, uid, or nid.',
  `count` int(10) unsigned NOT NULL DEFAULT '0' COMMENT 'The number of times this object has been flagged for this flag.',
  `last_updated` int(10) unsigned NOT NULL DEFAULT '0' COMMENT 'The UNIX time stamp representing when the flag was last updated.',
  PRIMARY KEY (`fid`,`entity_id`),
  KEY `fid_entity_type` (`fid`,`entity_type`),
  KEY `entity_type_entity_id` (`entity_type`,`entity_id`),
  KEY `fid_count` (`fid`,`count`),
  KEY `fid_last_updated` (`fid`,`last_updated`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8 COMMENT='The number of times an item has been flagged.';

-- Create syntax for TABLE 'flag_types'
CREATE TABLE `flag_types` (
  `fid` smallint(5) unsigned NOT NULL DEFAULT '0' COMMENT 'The unqiue flag ID as defined for the flag in flag.',
  `type` varchar(128) NOT NULL DEFAULT '' COMMENT 'The entity bundles that can be flagged by this fid.',
  KEY `fid` (`fid`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8 COMMENT='The entity bundles that are affected by a flag.';

-- Create syntax for TABLE 'flagging'
CREATE TABLE `flagging` (
  `flagging_id` int(10) unsigned NOT NULL AUTO_INCREMENT COMMENT 'The unique ID for this particular tag.',
  `fid` smallint(5) unsigned NOT NULL DEFAULT '0' COMMENT 'The unique flag ID this object has been flagged with, from flag.',
  `entity_type` varchar(128) NOT NULL DEFAULT '' COMMENT 'The flag type, eg "node", "comment", "user".',
  `entity_id` int(10) unsigned NOT NULL DEFAULT '0' COMMENT 'The unique ID of the object, such as either the cid, uid, or nid.',
  `uid` int(10) unsigned NOT NULL DEFAULT '0' COMMENT 'The user ID by whom this object was flagged.',
  `sid` int(10) unsigned NOT NULL DEFAULT '0' COMMENT 'The user’s numeric sid from the session_api table.',
  `timestamp` int(10) unsigned NOT NULL DEFAULT '0' COMMENT 'The UNIX time stamp representing when the flag was set.',
  PRIMARY KEY (`flagging_id`),
  UNIQUE KEY `fid_entity_id_uid_sid` (`fid`,`entity_id`,`uid`,`sid`),
  KEY `entity_type_uid_sid` (`entity_type`,`uid`,`sid`),
  KEY `entity_type_entity_id_uid_sid` (`entity_type`,`entity_id`,`uid`,`sid`),
  KEY `entity_id_fid` (`entity_id`,`fid`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8 COMMENT='Objects that have been flagged.';

Can you explain how the normal install process failed to create the tables? Were there any error messages?

Also, did you try uninstalling Flag and reinstalling it? You can do that very easily using Devel module's menu.

These debugging steps would help us figure out if there is a problem that should be fixed in the module code!

So I just downloaded it (there may have been reminiscence of an old one but I don't remember installing it and this is a big commerce project), then went and clicked the flag and flag bookmark modules, and it just failed there or after the confirm message I think. Then because it was throwing that error I couldn't uninstall or disable it. So I had to copy the tables to stop the errors and then I could disable and uninstall. Now it's up an re-installed and working fine.

Likely leftover stuff though just not sure where from.

It borked drush commands and the entire site it seemed, so no devel module or drush command or cache clear seemed to let it get by that error message.

> there may have been reminiscence of an old one but I don't remember installing it and this is a big commerce project

That sounds like the potential problem. The tables have all changed between Flag 2 and Flag 3. If your system had previously had Flag 2 on it, and it wasn't properly uninstalled, then enabling Flag 3 would NOT create the tables.

Sorry can't be more help than that, just giving people a suggestion in passing with the same issue incase they get stuck. But if someone else sees this please do provide steps that lead to the error.

What does your {system} table say for the flag module -- does it have a schema version? Also, do you have any {flag_FOO} tables that are not part of Flag 3 -- such as {flags} (plural) or {flag_content}? Those would both be definite signs that you previously had Flag 2 installed.

I don't but I likely deleted them if I noticed them using the schema module (extra tables). I bet you're right though it may have been leftovers from 2.x

Fresh install of Flag, this is the error:

Error: Call to undefined function flag_get_flags() in /docroot/sites/default/modules/contrib/flag/flag.info.inc, line 19

flag_get_flags() is defined in flag.module. If the module was properly installed, there's no way that's not loaded!

I downloaded the module with Drush, and did drush en -y flag. It said it installed (v 7306). Then I cleared cache, and got that error.

Fresh installation of 7.x-3.5 is broken for me as well.

I can't reproduce this problem.

Here's what I did:

* installed Drupal core 7.28 from scratch
* enabled Flag 7.x-3.5
* cleared all caches at admin/config/development/performance

No error messages.

I enabled it via Drush and not the UI if that makes a difference.

It shouldn't, but I can give that a try too.

Note the condition with db_table_exists...

function flag_entity_info() {
  if(db_table_exists('flag')){
    $return = array(
      'flagging' => array(
        'label' => t('Flagging'),
        'controller class' => 'FlaggingController',
        'base table' => 'flagging',
        'fieldable' => TRUE,
        'entity keys' => array(
          'id' => 'flagging_id',
          'bundle' => 'flag_name',
        ),
        // The following tells Field UI how to extract the bundle name from a
        // $flag object when we're visiting ?q=admin/.../manage/%flag/fields.
        'bundle keys' => array(
          'bundle' => 'name',
        ),
        'bundles' => array(),
        // The following tells EntityAPI how to save flaggings, thus allowing use
        // of Entity metadata wrappers (if present).
        'save callback' => 'flagging_save',
        'creation callback' => 'flagging_create',
      ),
    );

  // Add bundle info but bypass flag_get_flags() as we cannot use it here, as
  // it calls entity_get_info().
    $result = db_query("SELECT name, title FROM {flag}");
    $flag_names = $result->fetchAllKeyed();
    foreach ($flag_names as $flag_name => $flag_title) {
      $return['flagging']['bundles'][$flag_name] = array(
        'label' => $flag_title,
        'admin' => array(
          'path' => FLAG_ADMIN_PATH . '/manage/%flag',
          'real path' => FLAG_ADMIN_PATH . '/manage/' . $flag_name,
          'bundle argument' => FLAG_ADMIN_PATH_START + 1,
          'access arguments' => array('administer flags'),
        ),
      );
    }
  }

  return $return;
}

> if(db_table_exists('flag')){

Why on earth would you need that? Installing the module creates that table.

That is what breaks upon install when using drush. For some reason, it's being triggered before the tables are created. I know it seems surprising, but it works.

Same problem here when I install the latest flag version via Drush in a new Drupal 7.30 environment.

Confirming I get this with Drush:

drush en -y flag
The following extensions will be enabled: flag
Do you really want to continue? (y/n): y
WD php: PDOException: SQLSTATE[42S02]: Base table or view not found: 1146 Table 'drupal-lab-7.flag'    [error]
doesn't exist: SELECT name, title FROM {flag}; Array
(
)
 in flag_entity_info() (line 42 of
/Users/joachim/Sites/workshop/sites/all/modules/contrib/flag/flag.module).
Cannot modify header information - headers already sent by (output started at                          [warning]
/Users/joachim/Sites/_sandbox/drush/includes/output.inc:38) bootstrap.inc:1212
PDOException: SQLSTATE[42S02]: Base table or view not found: 1146 Table 'drupal-lab-7.flag' doesn't exist: SELECT name, title FROM {flag}; Array
(
)
 in flag_entity_info() (line 42 of /Users/joachim/Sites/workshop/sites/all/modules/contrib/flag/flag.module).
Drush command terminated abnormally due to an unrecoverable error.

So the thing is that our entity info uses the {flag} table to define its entity bundles. But that's not unusual: profile2 and node do the same thing.

First thing to investigate therefore would be how Profile2 avoids this problem (or even, does it?!) if anyone cares to do some investigating.

Had a look at Profile2's code. It's exactly the same as ours in this respect:

- hook_schema() defines a table that holds data that defines bundles
- hook_entity_info() queries this table to declare the bundles

Just tried this again and I can't reproduce it now.

Could this be related to upgrading from older versions of Flag?

i had the same problem. had to repeat the advice given above several times. one problem that had to be solved was that drush stopped completely to run after it threw that error message about the flag table not being found and the site just delivered a WSOD, so the already enabled module could not be disabled. i removed the flag folder from sites/all/modules, i went to the database and deleted the flag tables and thanks to @quickscetch #3 also visited the system table to delete all entries where filename contained the string "flag". what possibly also helped was usind drush registry_rebuild as suggested (in other circumstances) by @eosrei here: https://www.drupal.org/node/2161847#comment-8552543
great thing to have you around, guys! thank you!

Could this be related to upgrading from older versions of Flag?

Possibly a residual effect, yes. I get in this bind now and then, registry rebuild gets me out of it.

A *registry* rebuild?

That's not the same problem as the OP then -- a registry rebuild lets Drupal know about classes, whereas the OP is about database tables.

I have just experienced this exact error (through the UI, I didn't try it via drush) and I tried a few things before finding that installing Flag 2.2 first and then Flag 3.6 worked.

For what it's worth, here are some details in case it gives any hints as to the cause:

• The site was an old back-office site that hadn't been updated in a long time (Core was 7.18)
• I'm 99% sure Flag had never been on the site. It wasn't available to "uninstall" and there were no tables prefixed with flag.
• When I tried to install the module I selected Flag and Flag Bookmark and tried to install them at the same time.
• The site returned the same message as the OP. No other errors in the error log.
• I updated Core and tried again, but returned the same error.
• I read this issue https://www.drupal.org/node/1870300 which seems to be a problem with upgrading but it made me wonder if the problem was along similar lines (i.e. updates running in an unusual order).
• So I installed Flags 2.2, ran update.php, everything installed fine.
• Then upgraded to Flags 3.6, ran update.php, everything upgraded fine.

Given that 3.6 installs fine on a clean Drupal install I'm not sure what the difference was with my old site, but hopefully this should be a workaround for some people in the same situation.