Bug #44795

Page tree - Copy page (and paste) - preview images (often missing)

Added by Andreas Allacher almost 7 years ago. Updated about 1 year ago.

Status:
Closed
Priority:
Must have
Assignee:
-
Category:
FormEngine aka TCEforms
Target version:
-
Start date:
2013-01-25
Due date:
% Done:

100%

TYPO3 Version:
6.1
PHP Version:
Tags:
Complexity:
medium
Is Regression:
No
Sprint Focus:

Description

Hello,

this problem does not seem to happen all the time but quite often.
I have a page with an image, copy that page and paste it.
Then I open the pasted page in Columns or Language view.
On that view the preview image is missing. However, if I open the page in the frontend it is there. If I open the content elment and save it, the preview image is again there too.

I am using the current git master branch.

AfterSave.png View - This is the backend view after I press save on the content element that misses the preview image (93.5 KB) Andreas Allacher, 2013-01-28 11:04

BeforeCopy.png View - Displays page used to copy before copied (82.9 KB) Andreas Allacher, 2013-01-28 11:04

BeforeInsert.png View - Just shows how I inserted the copied page (76.4 KB) Andreas Allacher, 2013-01-28 11:04

AfterInsert.png View - Shows how the copied page looks like (67 KB) Andreas Allacher, 2013-01-28 11:04

Frontend.png View - This is the frontend view where the image is displayed correctly (it is only missing in the backend) (63.8 KB) Andreas Allacher, 2013-01-28 11:04

ButImageIsThere.png View - Although no preview image, the image reference is copied correctly. (92.2 KB) Andreas Allacher, 2013-01-28 11:04


Related issues

Related to TYPO3 Core - Bug #44964: DataHandler - process_cmdmap - Canceled during execution - multiple images on original content New 2013-01-30
Related to TYPO3 Core - Bug #56284: Copied references keep reference to original Closed 2014-02-25
Related to TYPO3 Core - Bug #55700: Copy Pages loose images Closed 2014-02-05

Associated revisions

Revision c81102bf (diff)
Added by Alexander Stehlik over 5 years ago

[BUGFIX] Avoid superfluous IRRE child record duplication

If copying a page, all records on that page will be copied to
the accordant destination page. IRRE parent-child structures
are cloned along the way as well. However, if a table (that is
defined a IRRE child) is processed before the accordant parent
record, the parent itself will duplicate its children again.
This behaviour leads to superfluous duplicates and is wrong.

A check in DataHandler::copyRecord_procBasedOnFieldType() now
ensures that records are only copied once during the accordant
DataHander copy process.

Resolves: #44795
Releases: 6.2
Change-Id: Ia1e4129432f37c0dd6bfedb5fd69394e2c244d34
Reviewed-on: https://review.typo3.org/26552
Reviewed-by: Oliver Hader
Tested-by: Oliver Hader

Revision c517f74b (diff)
Added by Alexander Stehlik over 5 years ago

[BUGFIX] Avoid superfluous IRRE child record duplication

If copying a page, all records on that page will be copied to
the accordant destination page. IRRE parent-child structures
are cloned along the way as well. However, if a table (that is
defined a IRRE child) is processed before the accordant parent
record, the parent itself will duplicate its children again.
This behaviour leads to superfluous duplicates and is wrong.

A check in DataHandler::copyRecord_procBasedOnFieldType() now
ensures that records are only copied once during the accordant
DataHander copy process.

Resolves: #44795
Releases: 6.2, 6.1
Change-Id: Iebc22529a98b73cc55396de0718fee9aa877b5bb
Reviewed-on: http://review.typo3.org/30469
Reviewed-by: Felix Jacobi <>
Tested-by: Felix Jacobi <>
Reviewed-by: Oliver Hader <>
Tested-by: Oliver Hader <>

History

#1 Updated by Oliver Hader almost 7 years ago

  • Status changed from New to Needs Feedback

I could not reproduce this behaviour on current Git master.
Can you please add screenshots to see, what's going on?

#2 Updated by Andreas Allacher almost 7 years ago

  • File AfterSave.png added
  • File BeforeCopy.png added
  • File BeforeInsert.png added
  • File AfterInsert.png added
  • File ButImageIsThere.png added
  • File Frontend.png added

No Problem.
Here are some screenshots.

I added the corresponding descriptions to each file.
As said I am not always able to reproduce this bug myself.
Also I checked out the current version before creating those screenshots.

#3 Updated by Georg Ringer almost 7 years ago

  • File deleted (AfterSave.png)

#4 Updated by Georg Ringer almost 7 years ago

  • File deleted (BeforeCopy.png)

#5 Updated by Georg Ringer almost 7 years ago

  • File deleted (BeforeInsert.png)

#6 Updated by Georg Ringer almost 7 years ago

  • File deleted (AfterInsert.png)

#7 Updated by Georg Ringer almost 7 years ago

  • File deleted (ButImageIsThere.png)

#8 Updated by Georg Ringer almost 7 years ago

  • File deleted (Frontend.png)

#9 Updated by Andreas Allacher almost 7 years ago

#10 Updated by Georg Ringer almost 7 years ago

problem identifiet: tt_content, field image is empty in copy but should have the count of images inside

#11 Updated by Andreas Wolf almost 7 years ago

Georg Ringer wrote:

problem identifiet: tt_content, field image is empty in copy but should have the count of images inside

I think this is more an IRRE/TCEmain problem than really related to FAL, isn't it?

#12 Updated by Jigal van Hemert over 6 years ago

  • Status changed from Needs Feedback to New

#13 Updated by Ernesto Baschny about 6 years ago

  • Category changed from File Abstraction Layer (FAL) to 978
  • Priority changed from Should have to Must have

If I manually set the "image" field to "0" or "NULL" via SQL it does not affect the preview in the backend at all. So the reason must be somewhere else.

I could reproduce that only in a WORKSPACE situation (which from the screenshots is not the users use-case). Next time I see it happening I will try to figure out what's "in the database" at that time...

But I also agree that this is most probably an IRRE problem. :)

#14 Updated by Gerrit Code Review almost 6 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/26552

#15 Updated by Alexander Stehlik almost 6 years ago

I think I found the problem. Quote form core mailing list:

Hi guys,

I'm not sure but I think I found a conceptional problem with inline records that are stored in the same page as their parents.

I found this by researching the cause of:
http://forge.typo3.org/issues/44795 and
http://forge.typo3.org/issues/44964

Lets assume we have a page with a tt_content element that uses a sys_file_reference. We now copy that page. This is what happens:

DataHandler->copySpecificPage() loops over all configured tables and copies the records in that page.

If sys_file_reference appears first in the tables array (which seems to be the case currently) the sys_file_reference record is copied (a new record with identical data but a different PID appears in the sys_file_reference table). The records still points to the content element in the old page though.

Now the tt_content element is copied which has a reference to an inline sys_file_reference record. This is done by copyRecord_procBasedOnFieldType() which finally calls copyRecord_raw(). In this method it is checked, if the record is already copied by calling isRecordCopied(). Since the record WAS already copied further processing is skipped.

Has anyone a good idea how to solve this? Maybe in copyRecord_raw() override the data of the related record isRecordCopied() returns TRUE?

I wish you all a merry Christmas

Cheers,
Alex

The patch pushed to Gerrit makes sure that even if the records have been copied before when looping over the tables the inline records still get updated.

#16 Updated by Gerrit Code Review almost 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/26552

#17 Updated by Gerrit Code Review over 5 years ago

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

#18 Updated by Alexander Stehlik over 5 years ago

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

#19 Updated by David Gurk over 5 years ago

Is their a reason why this fix is not included in TYPO3 v6.1?

#20 Updated by Gerrit Code Review over 5 years ago

  • Status changed from Resolved to Under Review

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

#21 Updated by Gerrit Code Review over 5 years ago

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

#22 Updated by Alexander Stehlik over 5 years ago

Good point, David. Patch for 6.1 was pushed to Gerrit.

#23 Updated by David Gurk over 5 years ago

Hi Alexander,
will this patch be available with the next update?

Thanks and greetings

David


EDIT:
Ah, it's allready their. =) Thanks

#24 Updated by Oliver Hader over 5 years ago

  • Status changed from Under Review to Resolved
  • Complexity set to medium
  • Is Regression set to No

Alright, merged now for TYPO3 CMS 6.1.11 as well...

#25 Updated by Michiel Roos about 5 years ago

Andreas, did the patch solve your issue?

#26 Updated by Benni Mack about 1 year ago

  • Status changed from Resolved to Closed

Also available in: Atom PDF