Bug #60919

References to files are sometimes wrong

Added by Reinhard Führicht about 6 years ago. Updated almost 5 years ago.

Must have
File Abstraction Layer (FAL)
Target version:
Start date:
Due date:
% Done:


TYPO3 Version:
PHP Version:
Is Regression:
Sprint Focus:


A client called and asked me why he cannot delete a file in the file list.
I found out, that there is a reference to this file and told him to remove the reference to be able to delete the file.

But the reference information says the file is referenced in an "Address Group" record. There is no possibility to reference a file in this record.
I found out that this record has a link field. The field links to "901" (The PAGE 901). Somehow the reference index seems to think, that the field links to the FILE 901, allthough the field content clearly is NOT "file:901", but "901".

Can anyone reproduce this and confirm this as a bug?

Capture1.JPG View (118 KB) Reinhard Führicht, 2014-09-22 17:22

Capture1a.JPG View (56.4 KB) Reinhard Führicht, 2014-09-22 17:22

Capture2.JPG View (67.4 KB) Reinhard Führicht, 2014-09-22 17:22

refindex_60919.diff View (777 Bytes) Caspar Stuebs, 2014-09-29 12:53

Related issues

Related to TYPO3 Core - Bug #58913: Missing and invalid warnings on referenced files Closed 2014-05-19
Related to TYPO3 Core - Bug #60226: Content Element header_link to a page also adds a references to the file with same id Closed 2014-07-10


#1 Updated by Mansoor Ahmad about 6 years ago

Hello Reinhard,

yes, i can reproduce this issue in the TYPO3 Version 6.2.4

the Linkfields have the correct Configs like:
"softref => typolink"

but the FAL use the Pagelinks ID and missmatch them with the Fileids... (means the softref are not working)
I testet this also with the TYPO3 Default fields like tt_content->header_link...same issue

Is there any Idea/Patch?

With best regards,

#2 Updated by Oliver Hader about 6 years ago

Maybe (parts) of this issue are related to issue #58913
Please give feedback if it looks like that and if you have a chance to test the related bugfix for the mentioned issue

#3 Updated by Oliver Hader about 6 years ago

  • Status changed from New to Needs Feedback

#4 Updated by Reinhard Führicht about 6 years ago

Thank you for your responses.

I tested the mentioned patch, but it has no impact on the described issue.

The problem is:

In the file list there is a PDF with 1 reference to it (Capture1.jpg).
When opening the referencing record, one sees that the ID of a page is used, not a file (Capture1a.jpg).
When looking into the database, it turns out, that the field "link" of this record references a page AND a file, which is wrong! (Capture2.jpg).

Maybe this happens when saving the data into the sys_refindex table?

#5 Updated by Caspar Stuebs about 6 years ago

Hi Folks,

I digged into this matter and I think I have found the reason.

Within class \TYPO3\CMS\Core\Database\ReferenceIndex there is a function getRelations_procDB() (line 592) which gets the database relations of a record to be stored into the refindex table.

And within that function, line 616 ff:

        } elseif ($conf['type'] == 'input' && isset($conf['wizards']['link']) && trim($value)) {
            try {
                $file = \TYPO3\CMS\Core\Resource\ResourceFactory::getInstance()->retrieveFileOrFolderObject($value);
            } catch (\Exception $e) {

            if ($file instanceof \TYPO3\CMS\Core\Resource\FileInterface) {
                return array(
                    0 => array(
                        'table' => 'sys_file',
                        'id' => $file->getUid()

I really do not understand, why this code block exists. I do not know any usecase where an input field with a link wizard provides a file link without prepeding it with 'file:'.

If I add

 && !$conf['softref']
to the elseif statement, the bug is solved. @see added diff

But imho the complete elseif block could be removed. Maybe some one of the core team knows more about it.

Kind regards.

#6 Updated by Frans Saris about 6 years ago

Why do you think the elseif part can be removed?

After a quick look the code you posted, this looks like setting reference to input fields with direct link/reference to a file.

For instance if you link a header to a file.

#7 Updated by Caspar Stuebs about 6 years ago

The code block tries to get the target of an input field which has a 'link'-wizard.

But if you add a file link, there should be 'file:UID' within the link field and not just an UID. Both results in the same file.

And as far as I understand the link generation, every internal link field should have the config 'softref'=>'typolink'.

Then it is handled by BackendUtility::softRefParserObj('typolink')->findRef(...) (line 434 / 505) and it should not handled by ReferenceIndex class itself.

If it does not have the config 'softref'=>'typolink', why it has to be a file link? I could be a page link, which is the 'normal' behavior of a link field with just an UID in it.

And is it possible, that a link field is not a typolink? Or is that a misconfiguration?

I try to summarize:

1. Is it possible, that a input field with link wizard is not a "typolink" field?
  • NO:
    • The code block should be removed, because it always has to be handled by BackendUtility::softRefParserObj('typolink')->findRef(...)
    • Maybe add an warning about a TCA misconfiguration
    • EXIT
  • YES:
    • The elseif statement has to check that $conf['softref'] is not set
    • GOTO 2
2. How does the value of the link has to be handled?
  • It has to be a file (or folder):
    • Nothing to do
  • It could be other database objects:
    • Which objects are allowed?
    • How are they handled?

If this discussion is to big for the moment I will just push the small bugfix to gerrit.

Kind regards

#8 Updated by Markus Klein about 6 years ago

I guess this is a broader topic, where I don't have enough knowledge in.
Please lets move this to Slack and take Olly Hader and Marc Bastian Heinrichs into this discussion.

#9 Updated by Alexander Opitz almost 6 years ago

What's the state of this issue?

#10 Updated by Sascha Schieferdecker over 5 years ago

I can confirm the issue, same effect here.

#11 Updated by Florian Seirer over 5 years ago

Same here.

A Templavoila FCE has a link field pointing to the page #40760, and the file with the ID 40760 claims to have a reference to this FCE.

#12 Updated by Frans Saris over 5 years ago

  • Sprint Focus set to On Location Sprint

#13 Updated by Anja Leichsenring over 5 years ago

  • Category set to File Abstraction Layer (FAL)

#14 Updated by Mathias Schreiber over 5 years ago

  • Status changed from Needs Feedback to Accepted

#15 Updated by Nicole Cordes over 5 years ago

  • Status changed from Accepted to Closed

Closed as duplicate to #60226

#16 Updated by Anja Leichsenring almost 5 years ago

  • Sprint Focus deleted (On Location Sprint)

Also available in: Atom PDF