Bug #60919: References to files are sometimes wrong - TYPO3 Core - TYPO3 Forge

Actions

Copy link

Bug #60919

closed

References to files are sometimes wrong

Added by Reinhard Führicht over 10 years ago. Updated about 9 years ago.

Status:

Closed

Priority:

Must have

Assignee:

Category:

File Abstraction Layer (FAL)

Target version:

Start date:

2014-08-12

Due date:

% Done:

Estimated time:

TYPO3 Version:

6.2

PHP Version:

Tags:

Complexity:

Is Regression:

Sprint Focus:

Description

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?

Files

Download all files

Capture1.JPG (118 KB) Capture1.JPG		Reinhard Führicht, 2014-09-22 17:22
Capture1a.JPG (56.4 KB) Capture1a.JPG		Reinhard Führicht, 2014-09-22 17:22
Capture2.JPG (67.4 KB) Capture2.JPG		Reinhard Führicht, 2014-09-22 17:22
refindex_60919.diff (777 Bytes) refindex_60919.diff		Caspar Stuebs, 2014-09-29 12:53

Related issues 2 (0 open — 2 closed)

Actions

Copy link

Updated by Mansoor Ahmad over 10 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,
Mansoor

Actions

Copy link

Updated by Oliver Hader over 10 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

Actions

Copy link

Updated by Oliver Hader over 10 years ago

Status changed from New to Needs Feedback

Actions

Copy link Download all files

Updated by Reinhard Führicht over 10 years ago

File Capture1.JPG Capture1.JPG added
File Capture1a.JPG Capture1a.JPG added
File Capture2.JPG Capture2.JPG added

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?

Actions

Copy link

Updated by Caspar Stuebs over 10 years ago

File refindex_60919.diff refindex_60919.diff added

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.
Caspar

Actions

Copy link

Updated by Frans Saris over 10 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.

Actions

Copy link

Updated by Caspar Stuebs over 10 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
Caspar

Actions

Copy link

Updated by Markus Klein over 10 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.

Actions

Copy link