Project

General

Profile

Actions

Feature #82855

closed

Update preview image of online media files on save

Added by Tobias Schmidt about 7 years ago. Updated 10 months ago.

Status:
Closed
Priority:
Should have
Assignee:
-
Category:
File Abstraction Layer (FAL)
Target version:
-
Start date:
2017-10-25
Due date:
% Done:

100%

Estimated time:
PHP Version:
Tags:
Complexity:
Sprint Focus:

Description

If you add an online media file (YouTube or Vimeo) via file list module in TYPO3 backend a preview image is saved to typo3temp/online_media. This file will be used as a preview image until the end of time unless it is deleted. In my use case an editor adds an online media file and later changes the preview image on the YouTube website. This new preview image will never be used in TYPO3 because there is a check for an existing preview image (file_exists) in method getPreviewImage(File $file) in class TYPO3\CMS\Core\Resource\OnlineMedia\Helpers\YouTubeHelper (it's the same for Vimeo):

public function getPreviewImage(File $file)
{
    $videoId = $this->getOnlineMediaId($file);
    $temporaryFileName = $this->getTempFolderPath() . 'youtube_' . md5($videoId) . '.jpg';

    if (!file_exists($temporaryFileName)) {
        $tryNames = ['maxresdefault.jpg', '0.jpg'];
        foreach ($tryNames as $tryName) {
            $previewImage = GeneralUtility::getUrl(
                sprintf('https://img.youtube.com/vi/%s/%s', $videoId, $tryName)
            );
            if ($previewImage !== false) {
                file_put_contents($temporaryFileName, $previewImage);
                GeneralUtility::fixPermissions($temporaryFileName);
                break;
            }
        }
    }

    return $temporaryFileName;
}

This method is called everytime a backend user opens the file list view. I suggest to call a slightly modified version of this method on online media file save without the check for an existing preview image. This way an editor would be able to update preview images without asking a administrator to delete the preview file from typo3temp/online_media.


Related issues 2 (0 open2 closed)

Related to TYPO3 Core - Bug #99312: PSR-14 Event for fetching YouTube/Vimeo preview imageClosed2022-12-08

Actions
Related to TYPO3 Core - Bug #101968: Exception in filelist for storages with baseUri setClosedOliver Bartsch2023-09-20

Actions
Actions #1

Updated by Tobias Schmidt about 7 years ago

  • Description updated (diff)
Actions #2

Updated by Frans Saris about 7 years ago

Hi, this is indeed a (by me at least) known issue.

Do you have a suggestion how we could tackle this?

Personally I was thinking about adding some lifetime to the downloaded image so it's refreshed automatically.

What do you think.

Actions #3

Updated by Tobias Schmidt about 7 years ago

I'm not sure if adding a lifetime helps a lot. There is a check for the preview image in backend everytime you open a folder in file list module with an online media file. So a check for a lifetime would only happen if an editor opened that folder which might not happen for a long time. In the frontend the preview image itself is not used but a processed version that is saved unter /fileadmin/_processed_. It doesn't make a difference if the original file is missing. As long as the processed version exists the frontend view is fine. And probably an editor wouldn't know about the lifetime of a preview image. If changing the preview on YouTube website becomes visible only after one or two days it is simply not what an editor expects.

Updating the preview image on save at least updates the original image at a specific time. I know next to nothing about the handling of processed files. Is there a regular mechanism to delete and recreate those images if the original file is updated? Does a lifetime for those files exist? Updating the original preview image is one problem. Using the updated preview image in the frontend another.

What about removing the check at all so preview images are recreated everytime their folder is opened in file list module? Probably not a good idea if a folder contains a lot of online media files. Maybe a combination of updating on save and a lifetime would be a good idea for updating the original file. I have no idea how to handle the update of the processed files for frontend view.

Actions #4

Updated by Susanne Moog about 7 years ago

  • Category set to File Abstraction Layer (FAL)
Actions #5

Updated by Gerrit Code Review about 7 years ago

  • Status changed from New to Under Review

Patch set 1 for branch master of project Packages/TYPO3.CMS has been pushed to the review server.
It is available at https://review.typo3.org/54555

Actions #6

Updated by Guido S. over 6 years ago

I see these options:

1.) Automatically Lifetime Check
Switch - configurable via InstallTool (Default = false)
Cycle - configurable via InstallTool (Default = 1day)

Contra: If you have thousand youtube videos, there are a lot of requests which you might won't have.

2.) Lifetime Check via Scheduler Task
Like proposal 1.) but images are proceed in blocks.

3.) "Refresh" at Edit Dataset
Automatically on save or via "refresh" button. I think the first proposal has fewer dependencies for a patch.

My favorite is a combination of 2 and 3.

Actions #7

Updated by Gerrit Code Review over 6 years ago

Patch set 2 for branch master of project Packages/TYPO3.CMS has been pushed to the review server.
It is available at https://review.typo3.org/54555

Actions #8

Updated by Susanne Moog over 5 years ago

  • Status changed from Under Review to New

Patch has been abandoned.

Actions #9

Updated by Anonymous about 4 years ago

I suggest to require a manual action to refresh the preview-image. This guarantees that preview images can't "accidentally" change to something unwanted.
Basically: Someone manually changes the preview-image on youtube - someone needs to notify TYPO3 manually.

So I propose to extend the OnlineMediaHelperInterface

    public function cleanPreviewImage(File $file);

Concrete implementations like YouTubeHelper may directly unlink the generated local preview-image file - or whatever suits best to "revert" whatever is done inside getPreviewImage.

The next hit will trigger re-generation via getPreviewImage.

For user interface, I would suggest placing a remove local preview image-button directly on the file-info dialog (filelist -> youtube-file -> click on info-button) - as the file-info-dialog is also reachable via concrete file-references.

There is already a Show-button - maybe place the remove local preview image-button next to it.

Just one problem...

I would really like to implement that myself, but I am afraid this task may need to write some TypeScript (yikes) - and even weirder - some JS AMD module shizzle. No - run run run!

But I hope my "vision" of how it may be implemented already helps someone to do the actual work.

Actions #10

Updated by Rémy DANIEL over 1 year ago

  • Related to Bug #99312: PSR-14 Event for fetching YouTube/Vimeo preview image added
Actions #11

Updated by Gerrit Code Review about 1 year ago

  • Status changed from New to Under Review

Patch set 1 for branch main of project Packages/TYPO3.CMS has been pushed to the review server.
It is available at https://review.typo3.org/c/Packages/TYPO3.CMS/+/81083

Actions #12

Updated by Gerrit Code Review about 1 year ago

Patch set 2 for branch main of project Packages/TYPO3.CMS has been pushed to the review server.
It is available at https://review.typo3.org/c/Packages/TYPO3.CMS/+/81083

Actions #13

Updated by Gerrit Code Review about 1 year ago

Patch set 3 for branch main of project Packages/TYPO3.CMS has been pushed to the review server.
It is available at https://review.typo3.org/c/Packages/TYPO3.CMS/+/81083

Actions #14

Updated by Gerrit Code Review about 1 year ago

Patch set 4 for branch main of project Packages/TYPO3.CMS has been pushed to the review server.
It is available at https://review.typo3.org/c/Packages/TYPO3.CMS/+/81083

Actions #15

Updated by Oliver Bartsch about 1 year ago

  • Status changed from Under Review to Resolved
  • % Done changed from 0 to 100
Actions #16

Updated by Oliver Bartsch about 1 year ago

  • Related to Bug #101968: Exception in filelist for storages with baseUri set added
Actions #17

Updated by Benni Mack 10 months ago

  • Status changed from Resolved to Closed
Actions

Also available in: Atom PDF