Bug #45779
closed
Blank page/Exception when referenced images are deleted in filesystem
0%
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.
Files
Updated by Andreas Wolf over 11 years ago
- Project changed from 1856 to TYPO3 Core
Updated by Andreas Wolf over 11 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
Updated by Sebastian Fischer over 10 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.
Updated by Susanne Moog over 9 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
Updated by Riccardo De Contardi almost 9 years ago
Isn't this solved maybe with #71686 ?
Updated by Riccardo De Contardi about 7 years ago
- File Schermata 2017-09-16 alle 19.38.07.png Schermata 2017-09-16 alle 19.38.07.png added
- Status changed from Accepted to Closed
- Assignee deleted (
Susanne Moog)
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.