Rewrite field Image Erroe

Created on 2 May 2025, 11 days ago

Problem/Motivation

I believe we are having an issue with the replacement pattern field on the rewrite field plugin. The issue appears to only occur for nodes with image files. We have a similar pattern in place for .txt files and it appears to work without issue for that file type.

Our feeds import process generates node content automatically . The nodes have several simple field values making up records which are add via a csv import file and for more detailed records .txt files and .jpg files that added via the feed tamper rewrite plugin. The import is run once a week and adds new records or updates existing records.

The image upload is generating errors and preventing updates to the nodes.

When the feed tamper replacement pattern uses private:// folder/[images] the following error occurs.
cURL error 1: Protocol "private" not supported or disabled in libcurl. // It throws the same error if public:// is used.

When the alternative replace pattern is used
siteurl/sites/default/files/public_recordsfolder/[images]. I get the following error:

File 'temporary://filegqK5QQ' could not be copied because a file by that name already exists in the destination directory ('').

If a record is generated without an image reference, updates all go through. Both methods had been working in the past. Almost all real data imports are updating existing records, so the images have been added already and should be skipped over in most cases.

How should I configure replacement pattern or make adjustments to get it to accept one of the above paths.

Notes
private:// is used to add .txt files without error and feed import source is also references private:// so I don’t have believe the private folder is inaccessible.

I have not found very useful references to the temp file error. I asked Pantheon support and they had not seen the temp file error code in this context.

Drupal 10
Feeds Version: 8.x-3.0
tamper 8.x-2.0-beta4
Pantheon Server hosted

πŸ› Bug report
Status

Active

Component

Code

Created by

Live updates comments and jobs are added and updated live.
Sign in to follow issues

Comments & Activities

  • Issue created by @dcdev11
  • πŸ‡³πŸ‡±Netherlands megachriz

    Can it be that some records reference text files that are in a different directory, but with the same name?

    The error message says that a file from the temporary directory could not be written to either the public or private file system because on that file system there already exists a file with the same name.

    I'm unable to reproduce the error however. Even when I try to import a CSV file like the following, I don't get an error:

    guid,title,file
    1,A,http://example.com/feeds/txt/a/sample.txt
    2,B,http://example.com/feeds/txt/b/sample.txt
    

    Or this:

    guid,title,file
    1,A,http://example.com/sites/default/files/bijlagen/sample.txt
    2,B,http://example.com/sites/default/files/bijlagen/sample.txt
    

    Can you try to reproduce the issue on a clean install? Maybe a file related module is configured in a way that causes this issue.

    Using private:// or public:// as file source is indeed not yet supported. Only http sources are supported at the moment. There is a request to support the local file path a source: ✨ File target: add support for local file path as source Needs work .

  • I have used a multidev to remove the translation module, thinking it might be generating a temp file request that is problematic, but it didn't impact the error. If there are other modules that are likely suspects, I can remove there. I was considering making a fresh install and trying to recreate the error. I'll probably do that, but it's a fair bit of set up.

    RE

    Using private:// or public:// as file source is indeed not yet supported. Only http sources are supported at the moment. There is a request to support the local file path a source: #2968671: File target: add support for local file path as source.

    Not trying to be difficult, but I don't understand how this is the case. The feeds source that runs the import file references private://ourfeedsdata/importfile.txt. Immediately above the feeds tamper for images, is the feed tamper for .txt file which uses private://ourfeedsdata/[textfiletoken] and works if image import field is unused.

    The image field used to replacement pattern private://ourfeedsdata/[imagefiletoken] in D8 and D9 on our internal nginx servers for around 18 months and worked without issue. It also worked when we set it up in pantheon in 2023 (not totally sure when it stopped working but we moved to the above direct public file reference last year)

  • Can it be that some records reference text files that are in a different directory, but with the same name?

    Hi,

    So duplicate names file does seems to be the issue. Still working on pinning down the exact process that hits the error, but I cleared the most recent real world error set by making sure the file name wasn't duplicated anywhere.

    Let me know if you have experience clearing that problem. The duplicate image files are sometimes the same img src that show on the site, so I can't erase in bulk.

  • πŸ‡³πŸ‡±Netherlands megachriz

    Did you try to reproduce the issue on a clean install? Because when I import two items with the same exact file (with the same name), then I get as result that both items reference the same file entity. In your case, you get an error. So there must exist a difference between my setup and your setup. The most likely difference is that you:

    • Have a module installed that I have not.
    • And/or have configured a file related setting differently.

    To find out what that difference is, try to replicate the error on a clean install so we know which module or setting causes a different behavior.

    Based on the current info, the only possible solution that I see is making sure that file names are unique. But there could perhaps exist an other solution if we can find out what causes a different behavior.

Production build 0.71.5 2024