After installing the module, file 'type' field storage is not installed

We only need to install our own field storage definition, not try to apply any change.

There are examples here: https://www.drupal.org/node/2554097 (taken from core update functions)

I've applied #14 patch, I'm able to install the module WITHOUT the mismatched entity issue, however I get a fatal error if I then try to uninstall the module:

TypeError: Argument 1 passed to Drupal\Core\Entity\EntityDefinitionUpdateManager::uninstallFieldStorageDefinition() must implement interface Drupal\Core\Field\FieldStorageDefinitionInterface, null given, called in /modules/contrib/file_entity/file_entity.install on line 94 in Drupal\Core\Entity\EntityDefinitionUpdateManager->uninstallFieldStorageDefinition() (line 192 of /core/lib/Drupal/Core/Entity/EntityDefinitionUpdateManager.php).

I was still getting a fatal error when uninstalling the module after installing with patch #14, but I think the important error message was the following:

Drupal\Core\Field\FieldException: Attempt to create a field field_image_alt_text that does not exist on entity type file. in Drupal\field\Entity\FieldConfig->getFieldStorageDefinition() (line 286 of /var/www/drupaltest/drupal/web/core/modules/field/src/Entity/FieldConfig.php).

I've made some additions to hook_uninstall to delete the image file alt and title fields, which (as far as I can tell) is working.

Setting back to needs review. Also, I've moved a couple of the config YML files to /config/optional because I was having problems with these configs not being removed from active configuration when the module is uninstalled, and therefore not able to re-enable the module.

Could I manually solve this problem?..or future upgrading of this module will get the error to go away?
Will my data lose for disable and renable the module?

The attached patch has removed the error message from the status page, but only after I uninstalled and re-installed the module. After uninstalling/reinstalling the module, I could not reference any of my sites files via a file type field until I re-saved them all. Seems like we need an update hook implementation to fix the broken entity/field definitions and any files that were uploaded after this bug was introduced.

@jantoine, currently hook_install() queues all existing files to determine file type, which doesn't run until cron is executed. Can you run cron after install, and verify that this is the problem?

@epicpugh,

Running cron did not fix the error message on the status report page, but it did fix the files for reference fields after I uninstalled and reinstalled the module.

I am having this issue also, though slightly different, on a 8.x-2.0-beta2 installed with the new Drupal 8.2.1
I just get the message "The File type field needs to be installed." (and of course it is installed already). I've run Cron but not yet tried uninstalling, because the last time I did that my site died with WSOD.
Strangely, it doesn't stop anything from working or so it seems (this is only a little test site with nothing in it except some file entity test content)

@joel_guesclin Confirmed, I'm getting the same error on Drupal 8.2.x, I've updated the status as patch #19 is no longer working for me.

I'm having the same issue as the 2 guys above me on Drupal 8.2.1, and 8.x-2.0-beta2.

Another person seeing this issue on 8.2.1

You can solve this issue executing this comand in drush:

drush entity-updates

Can we create separate issues for uninstall/reinstall and go back to focus on fixing the install problem, which is a lot easier to deal with.

As per Berdir's request in #34, lets follow-up the uninstall/reinstall issues as a separate issue. I think #2767511: Uninstall error covers it?

The patch from claudiu.cristea in #10 applies cleanly, and fixes the install issue.

I'm hiding the later patches, as they try to resolve the uninstall/update issues, which will be followed up separately.

Having a weird issue with the patch, so just trying an update here.

Hi MiSc, can you elaborate on your comment in #36? What was the weird issue?

Your new patch introduces some extraneous changes with line breaks and whitespace that don't appear to be related to the core issue, so should be removed.

Just have the same problem on 8.2.2. / 8.2.3 too :-(

Problems to uninstall file entity and media module :-(

Maybe following errror was related to same problem. After dropping every field_deleted_data_xxxx table i could uninstall file entity (for a first time) (if i dropped field_deleted_data_aeaa99328a then error message came with next table ...)

rupal\Core\Entity\EntityStorageException: Exception thrown while performing a schema update. The table file__field_image_alt_text could not renamed to field_deleted_data_aeaa99328a: The table field_deleted_data_aeaa99328a still existists. [retranslated it from German]

I'm just only a website maintainer/producer, not a programmer, so I just make some experiments ;-)

Also found in message log:

Drupal\Core\Field\FieldException: Attempt to create a field field_image_alt_text that does not exist on entity type file. in Drupal\field\Entity\FieldConfig->getFieldStorageDefinition() (Zeile 286 in /xxx/xxx.at/core/modules/field/src/Entity/FieldConfig.php).

and (many times)

Recoverable fatal error: Argument 2 passed to Drupal\Core\Controller\TitleResolver::getTitle() must be an instance of Symfony\Component\Routing\Route, null given, called in /xxx/xxx.at/modules/token/token.tokens.inc on line 740 and defined in Drupal\Core\Controller\TitleResolver->getTitle() (line 39 of /medjxcwh/drupal.mediaweb.at/core/lib/Drupal/Core/Controller/TitleResolver.php) #0 /xxx/xxx.at/core/includes/bootstrap.inc(548): _drupal_error_handler_real(

Just new findings:

also hat problems to remove token module, just had to remove a field_deleted_data_xx but media module - which didnt work proper (couldnt upload files) - still remained uninstallable.

The "The date type field needs to be installed" dissapeared but after uninstalling contact storage (to uninstall token) I got following message on status report:

contact message
The message-ID field needs to be uninstalled.
file
The file.field_image_alt_text field needs to be uninstalled.

Just give it up now ;-)

@nicrodgers Ignore my patch, internal caching problem, not problem with the patch it self.

@MiSc ok thanks, no problem. I'll hide it and go back to the RTBC'd patch from #10.

re the comment in #38, this relates to uninstall, which we have descoped from this issue.

After installed, this is what I get in admin/reports/status.

User warning: The following module is missing from the file system: block_page_layout in drupal_get_filename() (line 236 of C:\inetpub\wwwroot\dev\core\includes\bootstrap.inc) #0 C:\inetpub\wwwroot\dev\core\includes\bootstrap.inc(548): _drupal_error_handler_real(512, 'The following m...', 'C:\\inetpub\\wwwr...', 236, Array) #1 [internal function]: _drupal_error_handler(512, 'The following m...', 'C:\\inetpub\\wwwr...', 236, Array) #2 C:\inetpub\wwwroot\dev\core\includes\bootstrap.inc(236): trigger_error('The following m...', 512) #3 C:\inetpub\wwwroot\dev\core\includes\bootstrap.inc(259): drupal_get_filename('module', 'block_page_layo...') #4 C:\inetpub\wwwroot\dev\core\includes\module.inc(134): drupal_get_path('module', 'block_page_layo...') #5 C:\inetpub\wwwroot\dev\core\includes\module.inc(93): module_load_include('install', 'block_page_layo...') #6 C:\inetpub\wwwroot\dev\core\includes\install.inc(82): module_load_install('block_page_layo...') #7 C:\inetpub\wwwroot\dev\core\modules\system\src\SystemManager.php(109): drupal_load_updates() #8 C:\inetpub\wwwroot\dev\core\modules\system\src\Controller\SystemInfoController.php(49): Drupal\system\SystemManager->listRequirements() #9 [internal function]: Drupal\system\Controller\SystemInfoController->status() #10 C:\inetpub\wwwroot\dev\core\lib\Drupal\Core\EventSubscriber\EarlyRenderingControllerWrapperSubscriber.php(123): call_user_func_array(Array, Array) #11 C:\inetpub\wwwroot\dev\core\lib\Drupal\Core\Render\Renderer.php(574): Drupal\Core\EventSubscriber\EarlyRenderingControllerWrapperSubscriber->Drupal\Core\EventSubscriber\{closure}() #12 C:\inetpub\wwwroot\dev\core\lib\Drupal\Core\EventSubscriber\EarlyRenderingControllerWrapperSubscriber.php(124): Drupal\Core\Render\Renderer->executeInRenderContext(Object(Drupal\Core\Render\RenderContext), Object(Closure)) #13 C:\inetpub\wwwroot\dev\core\lib\Drupal\Core\EventSubscriber\EarlyRenderingControllerWrapperSubscriber.php(97): Drupal\Core\EventSubscriber\EarlyRenderingControllerWrapperSubscriber->wrapControllerExecutionInRenderContext(Array, Array) #14 [internal function]: Drupal\Core\EventSubscriber\EarlyRenderingControllerWrapperSubscriber->Drupal\Core\EventSubscriber\{closure}() #15 C:\inetpub\wwwroot\dev\vendor\symfony\http-kernel\HttpKernel.php(144): call_user_func_array(Object(Closure), Array) #16 C:\inetpub\wwwroot\dev\vendor\symfony\http-kernel\HttpKernel.php(64): Symfony\Component\HttpKernel\HttpKernel->handleRaw(Object(Symfony\Component\HttpFoundation\Request), 1) #17 C:\inetpub\wwwroot\dev\core\lib\Drupal\Core\StackMiddleware\Session.php(57): Symfony\Component\HttpKernel\HttpKernel->handle(Object(Symfony\Component\HttpFoundation\Request), 1, true) #18 C:\inetpub\wwwroot\dev\core\lib\Drupal\Core\StackMiddleware\KernelPreHandle.php(47): Drupal\Core\StackMiddleware\Session->handle(Object(Symfony\Component\HttpFoundation\Request), 1, true) #19 C:\inetpub\wwwroot\dev\core\modules\page_cache\src\StackMiddleware\PageCache.php(99): Drupal\Core\StackMiddleware\KernelPreHandle->handle(Object(Symfony\Component\HttpFoundation\Request), 1, true) #20 C:\inetpub\wwwroot\dev\core\modules\page_cache\src\StackMiddleware\PageCache.php(78): Drupal\page_cache\StackMiddleware\PageCache->pass(Object(Symfony\Component\HttpFoundation\Request), 1, true) #21 C:\inetpub\wwwroot\dev\core\lib\Drupal\Core\StackMiddleware\ReverseProxyMiddleware.php(47): Drupal\page_cache\StackMiddleware\PageCache->handle(Object(Symfony\Component\HttpFoundation\Request), 1, true) #22 C:\inetpub\wwwroot\dev\modules\devel\webprofiler\src\StackMiddleware\WebprofilerMiddleware.php(43): Drupal\Core\StackMiddleware\ReverseProxyMiddleware->handle(Object(Symfony\Component\HttpFoundation\Request), 1, true) #23 C:\inetpub\wwwroot\dev\core\lib\Drupal\Core\StackMiddleware\NegotiationMiddleware.php(50): Drupal\webprofiler\StackMiddleware\WebprofilerMiddleware->handle(Object(Symfony\Component\HttpFoundation\Request), 1, true) #24 C:\inetpub\wwwroot\dev\vendor\stack\builder\src\Stack\StackedHttpKernel.php(23): Drupal\Core\StackMiddleware\NegotiationMiddleware->handle(Object(Symfony\Component\HttpFoundation\Request), 1, true) #25 C:\inetpub\wwwroot\dev\core\lib\Drupal\Core\DrupalKernel.php(652): Stack\StackedHttpKernel->handle(Object(Symfony\Component\HttpFoundation\Request), 1, true) #26 C:\inetpub\wwwroot\dev\index.php(19): Drupal\Core\DrupalKernel->handle(Object(Symfony\Component\HttpFoundation\Request)) #27 {main}.

Very strange: After successfully uninstalling the module, the message is still on my config report page :-(

@rivedav that message is not related to this module, it complains about block_page_layout module.

Here's test for this.

We can remove the existing update call actually, this is triggered by the other one.

Committed.

I'm getting the following error when trying to apply the patch!?

error: patch failed: file_entity.install:4
error: file_entity.install: patch does not apply
error: patch failed: src/Tests/FileEntityFileTypeClassificationTest.php:60
error: src/Tests/FileEntityFileTypeClassificationTest.php: patch does not apply