File_entity : image_dimensions does not exists

Suite à une alerte de sécurité Drupal (PSA-2014-001), j'ai procédé à la mise à jour du module Media 7.1.x, et de File_entity, qui est compris dans ce module.

Problème en retournant sur les pages, une belle erreur :

PDOException: SQLSTATE[42S02]: Base table or view not found: 1146 Table 'mysite.image_dimensions' doesn't exist: SELECT * FROM {image_dimensions} id WHERE id.fid IN (:fids_0); Array ( [:fids_0] => 75 ) in file_entity_file_load() (line 225 of /home/mysite/domains/mysite.be/public_html/dev/sites/all/modules/media/file_entity/file_entity.module).

Identification du problème

Lorsqu'on vérifie dans la base de données, la table n'existe pas dans le schéma. Elle est pourtant créée dans le fichier .install de la nouvelle version de file_entity, qui fait partie du module Media 7.1.x. Dans l'update du module, elle porte la version 7101. On peut alors vérifier dans la base quel est le numéro de schéma référencé par Drupal. Par exemple avec une connexion MySQL ou MariaDB :

select name, type, schema_version from system where name = 'file_entity';
+-------------+--------+----------------+
| name        | type   | schema_version |
+-------------+--------+----------------+
| file_entity | module |           7215 |
+-------------+--------+----------------+
1 row in set (0.00 sec)

Dans le fichier file_entity.install, on trouve :

function file_entity_update_7101() 
{
...
}

Ce qui correspond à une version 7101,  inférieure à celle en base. Dans ce cas, le lancement de update.php ne va rien déclencher.

Solution

Forcer la version dans la table à une numéro inférieur à celui de l'update :

update system set schema_version = '7100' where name = 'file_entity';

On relance ensuite update.php et la table est alors créée.

Retour sur la cause du problème

Dans mon cas, la cause primaire était une première installation de Media 7.1 avec le module File Entity téléchargé séparément sur le site Drupal, qui est en version 7.2. En effet, dans la version Media 7.2, le module File entity n'est plus inclus.

Ce souci n'apparaît donc que dans un cas bien particulier : installation de Media 7.1 avec File_entity 7.2,(ce qui de toute manière pose des problèmes), puis désinstallation de file_entity 7.2, suppression du module, pour pouvoir utiliser le module inclus dans Media 7.1.

 

Catégorie
Permalien

For our english speaking users, the idea is to update the system table, and change schema_version to a number below the update (in .install file).

For example, in the example, in file_entity.install, we have update# 7101, but in system table, the schema_version was #7215.

I had to do :

update system set schema_version = '7100' where name = 'file_entity';

And then re-run update.php. Drupal will then search for all updates numbers which are more than 7100. And the new table will be created (the update_7101 will be triggered).

 

 

Permalien

Dear Vincent, Thank you so much for your post and also the email you sent me in response to my request for help. 

 I ended up going into phpmyadmin, found the row for "file_entity" in the "system" table and changed the "schema_version" column to "7000", which then triggered 4 updates when I ran update.php. Problem solved now. 
 
However, I now have the following question now: Do you think wise to upgrade to media 2.x ? I believe this problem is related to those of us who at one point upgraded to media 2.x and then downgraded back 1.x. I can't remember why I downgraded but I recall there were a lot of issues with the 2.x  when I tried it about a year ago. 
 
If you did upgrade yourself please let us know what was your experience. 
 
Also one more question: when I had the same file_entity issue a year ago, I changed the name on the media modules folder from 'media' to 'media_1.3'  That name seems to be have become hardcoded in drupal because when drush upgraded to media 1.4 recently (and changed the folder name back to 'media'), drupal could no longer find the media module. It was looking for .../media_1.3/...  Does this make any sense? I was under the impression that module folder names don't matter and drupal only cares about what it finds inside the folders. 
 
 
 
 

Well, if you look at system table structure, the first column is filename, which is the full path to the module file.

That means that if you rename your directory, then you will be facing a problem.

For example, for module popup_message, the content of the table is :

mysql> select filename, name, type from system where name = 'popup_message' ;
+------------------------------------------------------+---------------+--------+
| filename                                             | name          | type   |
+------------------------------------------------------+---------------+--------+
| sites/all/modules/popup_message/popup_message.module | popup_message | module |
+------------------------------------------------------+---------------+--------+
1 row in set (0.00 sec)

I guess Drupal is scanning directories in search of all *.info files, to check modules or themes.