Project

General

Profile

Actions

Bug #56284

closed

Copied references keep reference to original

Added by Philipp Wrann about 10 years ago. Updated over 6 years ago.

Status:
Closed
Priority:
Must have
Assignee:
-
Category:
File Abstraction Layer (FAL)
Target version:
Start date:
2014-02-25
Due date:
% Done:

0%

Estimated time:
TYPO3 Version:
6.2
PHP Version:
5.3
Tags:
Complexity:
easy
Is Regression:
No
Sprint Focus:

Description

When copying a record which holds sys_file_reference records the reference is copied with wrong relation data, so the original has 2 references but the copy none.


Related issues 1 (0 open1 closed)

Related to TYPO3 Core - Bug #44795: Page tree - Copy page (and paste) - preview images (often missing)Closed2013-01-25

Actions
Actions #1

Updated by Thomas Hempel about 10 years ago

We can reproduce this behavior and it's still valid for 6.2beta6

As far as I can see, the relation to the sys_file_reference simply has the wrong uid_foreign after copy.

Actions #2

Updated by Thomas Hempel about 10 years ago

Alright, we tracked it down, and this is a serious issue as far as I can tell.

This is what we think right now:

When you copy a page, the core duplicates all records in order of their respective table in the TCA. The problem with this is, that tt_content is defined in "frontend" and sys_file_references are defined in the extension "core". By default core is loaded first, which means that tt_content records are copied AFTER all records defined in "frontend". The result is, that sys_file_references get copied but the relation can not be updated because the new tt_content record does not exist yet.

The problem can be solved by moving "frontend" before "core" in the packageStates.php. This is of course not a real solution but demonstrates the effect.

We could also observe another strange behavior. When you copy the original page again and paste it again, it will all file references but one. So if you start with

Page1 - tt_content:File1

-- first copy --

Page 1 - tt_content:File1, File1 (copy 1)
Page 1 (copy 1) - tt_content:

-- second copy of Page 1 --

Page 1 - tt_content:File1, File1 (copy 1), File1 (copy 2)
Page 1 (copy 1) - tt_content:
Page 1 (copy 2) - tt_content:File1

-- n copy of Page 1 --

Page 1 - tt_content:File1, File1 (copy 1), File1 (copy 2), File (copy 1), File (copy 2)
Page 1 (copy 1) - tt_content:
Page 1 (copy 2) - tt_content:File1
Page 1 (copy n) - tt_content:File1, File (copy 1), File (copy n)

This can be done indefinitely.

This is a major design flaw in the copy routine as it practically prevents related records to be copied with a page if they are not defined in ext:core.

Another small remark. This only occurs when copying the page. If you copy only the tt_content element, everything works fine.

Actions #3

Updated by Patrick Kollodzik about 10 years ago

The position of the $table inside the TCA is importent in the following code position:

In \TYPO3\CMS\Core\DataHandling\DataHandler, method copySpecificPage

The method iterates over all possible tables and tests if a record is on the page.
Because EXT:core is loaded before EXT:frontend the sys_file_refernce are copied before tt_content.

Actions #4

Updated by Nicole Cordes about 10 years ago

  • Assignee set to Nicole Cordes
Actions #5

Updated by Nicole Cordes about 10 years ago

  • Status changed from New to Accepted
Actions #6

Updated by Martin Ficzel about 10 years ago

What can we do to help fixing this issue. It is really a huge problem for us since editors cannot copy pages with images at all at the moment.

Regards Martin

Actions #7

Updated by Alexander Stehlik about 10 years ago

Is this problem fixed with https://review.typo3.org/26552/ ?

Actions #8

Updated by Martin Ficzel about 10 years ago

Yes it seems https://review.typo3.org/26552/ fixes this aswell.

Actions #9

Updated by Ernesto Baschny about 10 years ago

  • Status changed from Accepted to Needs Feedback
  • Target version deleted (next-patchlevel)

If this is fixed by the just merged #44795, we have this problem solved for 6.2.0 - great! :)

Confirmed? We could then close this issue.

Actions #10

Updated by Daniel Ostmann about 10 years ago

I can confirm this issue for 6.2.beta7.

The patch in https://review.typo3.org/#/c/26552/ solved it! Thank you :-)

Actions #11

Updated by Martin Ficzel about 10 years ago

For me this is solved after #44795. I cannot reproduce the Problem any more.

Actions #12

Updated by Ernesto Baschny about 10 years ago

  • Status changed from Needs Feedback to Resolved
  • Assignee deleted (Nicole Cordes)
  • Target version set to 6.2.0

Great stuff, solved finally :)

Actions #13

Updated by Frank Gerards about 9 years ago

Any updates on this ? Is this fixed in TYPO3 6.2.12 ???

Actions #14

Updated by Frank Gerards about 9 years ago

is this solved now ?

Actions #15

Updated by Daniel Ostmann about 9 years ago

Frank, please note the last update before yours. It is marked as solved :-)

Actions #16

Updated by Riccardo De Contardi over 6 years ago

  • Status changed from Resolved to Closed
Actions

Also available in: Atom PDF