Bug #72273

In 6.2.16, publishing a deleted page containing a moved subpage will delete the whole web site!

Added by STI UdeS over 3 years ago. Updated 8 months ago.

Status:
Closed
Priority:
Must have
Assignee:
Category:
Workspaces
Target version:
Start date:
2015-12-16
Due date:
% Done:

100%

TYPO3 Version:
6.2
PHP Version:
5.5
Tags:
Complexity:
medium
Is Regression:
Yes
Sprint Focus:

Description

Publishing a deleted page from a workspace may recursively delete the whole website. This happens if the deleted page contains a child page that has been moved in the workspace.

This happens only since 6.2.16. In 6.2.15, we have an error that we cannot move a page that has been deleted but only the good pages are deleted.

How to reproduce:

In Live, create a page structure like this:

|-page1 |-page2 |-page3 |- subpage3-1 |- subpage3-2

Now go in a workspace, and do the following:
1) move subpage3-1 after subpage3-2 (this will create a move placeholder in the workspace for subpage3-1)
2) delete page3 (the page is marked as deleted in the workspace) (note: user must have recursive delete allowed to do that)

Now go to the workspace menu and publish all changes. This should delete page3 and all it's children in live
-> this is what happen in 6.2.15
-> in 6.2.16, ALL live pages are deleted recursively!! (including page1, page2 and their subpages...)

It seems that while recursively deleting the subpages of page3, the new code now deletes the move place holder, but then continues to recursively delete pages with a PID of 0.

This might be related to the fix introduced by #39383 ?


Related issues

Related to TYPO3 Core - Bug #39383: Cannot delete record moved in draft Closed 2012-07-30
Related to TYPO3 Core - Task #72291: Extend workspace functional tests on placeholder deletion Closed 2015-12-17

Associated revisions

Revision 72bf7473 (diff)
Added by Oliver Hader over 3 years ago

[!!!][BUGFIX] Severe data-loss on workspaces publishing action

If pages records in a given scenario are published this causes
a severe data-loss for the whole TYPO3 installation since all
records are deleted. Actually they are marked as deleted, but
that's not less problematic.

The scenario for this in a draft workspace is having reordered
sub-pages (move-placeholder) and a parent-page that is marked
for deletion. On publishing the parent-page, the delete process
iterates over all pages on the root-level due to some essential
missing checks and an implicit type-cast from null to interger
zero (0) on the pages.pid value.

The accordant places are validated now. In addition to that the
possibility to delete everything implicitly from the root-page
is disabled to prevent other programmatic flaws like this.

Resolves: #72273
Releases: master, 6.2
Change-Id: I175f220cc0939124e34713fff07685ba902ad385
Reviewed-on: https://review.typo3.org/45321
Reviewed-by: Alexander Opitz <>
Tested-by: Alexander Opitz <>
Reviewed-by: Oliver Hader <>
Tested-by: Oliver Hader <>

Revision b2b531cf (diff)
Added by Oliver Hader over 3 years ago

[!!!][BUGFIX] Severe data-loss on workspaces publishing action

If pages records in a given scenario are published this causes
a severe data-loss for the whole TYPO3 installation since all
records are deleted. Actually they are marked as deleted, but
that's not less problematic.

The scenario for this in a draft workspace is having reordered
sub-pages (move-placeholder) and a parent-page that is marked
for deletion. On publishing the parent-page, the delete process
iterates over all pages on the root-level due to some essential
missing checks and an implicit type-cast from null to interger
zero (0) on the pages.pid value.

The accordant places are validated now. In addition to that the
possibility to delete everything implicitly from the root-page
is disabled to prevent other programmatic flaws like this.

Resolves: #72273
Releases: master, 6.2
Change-Id: I175f220cc0939124e34713fff07685ba902ad385
Reviewed-on: https://review.typo3.org/45320
Reviewed-by: Oliver Hader <>
Tested-by: Oliver Hader <>

History

#1 Updated by Oliver Hader over 3 years ago

  • Status changed from New to Accepted
  • Assignee set to Oliver Hader
  • Target version set to next-patchlevel
  • Complexity set to medium

The described behavior is true unfortunately. I'm investigating it it's caused by the mentioned issue or something else...
The behavior has been released with TYPO3 6.2.16 and 7.5.0 (and thus was in 7.6.0 and 7.6.1 as well).

#2 Updated by Gerrit Code Review over 3 years ago

  • Status changed from Accepted to Under Review

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

#3 Updated by Gerrit Code Review over 3 years ago

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

#4 Updated by Gerrit Code Review over 3 years ago

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/45321

#5 Updated by Gerrit Code Review over 3 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/45321

#6 Updated by Gerrit Code Review over 3 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/45321

#7 Updated by Gerrit Code Review over 3 years ago

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

#8 Updated by Gerrit Code Review over 3 years ago

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

#9 Updated by Gerrit Code Review over 3 years ago

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

#10 Updated by Oliver Hader over 3 years ago

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

#11 Updated by Benni Mack 8 months ago

  • Status changed from Resolved to Closed

Also available in: Atom PDF