Bug #45779

Blank page/Exception when referenced images are deleted in filesystem

Added by Sebastian no-lastname-given over 7 years ago. Updated over 2 years ago.

Status:
Closed
Priority:
Could have
Assignee:
-
Category:
File Abstraction Layer (FAL)
Target version:
-
Start date:
2013-02-23
Due date:
% Done:

0%

TYPO3 Version:
6.0
PHP Version:
Tags:
Complexity:
Is Regression:
No
Sprint Focus:

Description

What does it do:
If you have a Content on a Page, which does not exists, then the page can't be opened againm on Pageview. You have to change to List view, because the errormessage Oups takes the whole screen.

I will give two examples:
Ex 1.
You choose an Imagecontent on a site, set this and now delete the Imagefile, where its solved, so, that the Imagepath shows to nowhere. The error should now be displayed, if you are in the Tree on Page. Now you have to change to List. This is the onliest way to change the damaged Content.

Ex 2.
You go on Filesystem and rename an existing Folder that is set also in a BE User Group. I tested this with a BE User Account actually. Now, goto Back Endmode from this User, by simply switching or simulating from BE Admin User to this specific BE User. As you can see now, the System gives no Failure out, there is also nothing displayed and you can see a white page. No it is finished. The Login has broken down. You can only quit your Browser.

Typo3 6.02
PHP 5.3+

Would be great, if Typo3 would have a better Errorhandler in this two cases.

Schermata 2017-09-16 alle 19.38.07.png View (32.8 KB) Riccardo De Contardi, 2017-09-16 19:50


Related issues

Related to TYPO3 Core - Bug #45696: typo3 crashes (with exeption) if a Image is deleted in fileadmin Closed 2013-02-21
Related to TYPO3 Core - Bug #71686: Image ViewHelper throws excpetion if image is missing Closed 2015-11-19
Duplicated by TYPO3 Core - Bug #46535: Image rendering of non-existing files throws exception Closed 2013-03-22

History

#1 Updated by Andreas Wolf over 7 years ago

  • Project changed from Refactoring Bootstrap to TYPO3 Core

#2 Updated by Andreas Wolf over 7 years ago

  • Subject changed from A small error is found in BE to Blank page/Exception when referenced images are deleted in filesystem
  • Category set to File Abstraction Layer (FAL)
  • Status changed from New to Accepted

#3 Updated by Sebastian Fischer about 6 years ago

In current master it works perfectly on page module unless you dont click the info button. Clicking the info button results in an exception.

#4 Updated by Susanne Moog almost 5 years ago

  • Assignee set to Susanne Moog
  • Is Regression set to No

#1: PHP Warning: fileperms(): stat failed for /var/www/typo/fileadmin/user_upload/IMG_2916.JPG in /var/www/Core/typo3/sysext/core/Classes/Resource/Driver/LocalDriver.php line 118

#5 Updated by Riccardo De Contardi over 4 years ago

Isn't this solved maybe with #71686 ?

#6 Updated by Riccardo De Contardi over 2 years ago

I think I can close it now; I performed the following tests with TYPO3 7.6.22 and 9.0.0-dev (latest master):

EX 1

1) add an image with dimentsion 100px x 100px test.gif in a folder inside /fileadmin/Images/
2) create a text and image (or text and media) inside that page and add the image uploaded at 1) as reference
3) preview page: the image is present (with path /fileadmin/Images/test.gif)
4) go to the filesystem and delete the image
5) clear the browser cache
6) preview the page

Result:

no error thrown, the image is missing; browser console says 404 (resource not found); same thing if you preview the page inside TYPO3

If you go to the content element and use the "info" button on the side of the image relation, you open the info popup, but as before, no error is thrown; simply a "File is missing!" message instead of the file thumbnail.

It is still possible to edit the metadata of the file using the pencil, and this seems wrong (there is no indication that the file is missing, except no thumbnail is shown), but this should be considered a different issue about the backend interface.

EX 2

1) create a folder /fileadmin/test_todelete/ and put some files in it
2) create a filemount test_todelete that points to that folder
3) create a usergroup and assign test_todelete as filemount; assign the module filelist (at least)
4) create a user and assign the usergroup created at 3
5) if you switch to the user created at 4, you will only have the tes_todelete filemounts
6) switch back to admin
7) go to the filesystem and rename the folder /fileadmin/test_todelete/ into /fileadmin/WHATEVER/
8) switch to user created at 4) and click on filelist module

Result: no backend failure; see attached screenshot

The screenshot says that the folder is no longer available, correctly. If you open the filemount you will see that the folder has the value

folder: [INVALID VALUE ("/test/todelete/")]

Therefore, I think this is sufficient to consider this issue closed; if you think that this is the wrong decision or that a different test should be performed, please reopen it or open a new issue with a reference to this one.

Also available in: Atom PDF