Bug #91792

Automatically created redirects are not created using the DataHandler

Added by Oliver Eglseder about 1 year ago. Updated 12 months ago.

Status:
New
Priority:
Should have
Assignee:
-
Category:
Link Handling, Site Handling & Routing
Target version:
Start date:
2020-07-13
Due date:
% Done:

0%

Estimated time:
TYPO3 Version:
10
PHP Version:
Tags:
Complexity:
Is Regression:
Sprint Focus:

Description

Method this is about: \TYPO3\CMS\Redirects\Service\SlugService::createRedirect

Redirects created when a page slug was updated are directly written to the database via DBAL instead of the DataHandler ("DH").
This has following drawbacks:
  • There is no access check. Redirects are created even if the user is not allowed to create redirects.
  • You can not use any hook to intercept, alter or get notfied of the redirect creation
  • The sys_history entry is written by a different function than the DH would use. The manual implementation might be forgotten when changes are made to DH's implementation
  • You have no way of knowing the uid of the created redirect to do something with it after the creation.

Actions done by backend users should always be processed by the DH.


Related issues

Related to TYPO3 Core - Bug #91751: Redirects are not tied to site configuation breaking referential integrity and making it impossible to test on/transfer from staging systemsNew2020-07-06

Actions
Related to TYPO3 Core - Bug #91936: Documentation missing to disable automatic creation of redirects on slug changeNeeds Feedback2020-08-05

Actions
Related to TYPO3 Core - Feature #92004: Create redirect entry if updated slug is published to liveNew2020-08-14

Actions
Related to TYPO3 Core - Task #89301: Streamline automatic slug & redirects handlingAccepted2019-09-29

Actions
Related to TYPO3 Core - Task #90143: Redirects: Poor performance of redirect matching for large redirects tableUnder Review2020-01-17

Actions
#1

Updated by Andreas Kiessling 12 months ago

There is no access check. Redirects are created even if the user is not allowed to create redirects.

And this gets even worse: after a redirect is automatically created, the info popup offers to revert the created redirects.
But since this now uses the RecordHistory, the redirects can not be removed due to missing access rights.

#2

Updated by Andreas Kiessling 12 months ago

  • Related to Bug #91751: Redirects are not tied to site configuation breaking referential integrity and making it impossible to test on/transfer from staging systems added
#3

Updated by Andreas Kiessling 12 months ago

  • Related to Bug #91936: Documentation missing to disable automatic creation of redirects on slug change added
#4

Updated by Richard Vollebregt 12 months ago

As far as I can tell, when a new redirect is added, the redirect cache isn't cleared either. This causes a 404 until the frontend cache is cleared.

#5

Updated by Ingo Fabbri 12 months ago

Richard Vollebregt wrote:

As far as I can tell, when a new redirect is added, the redirect cache isn't cleared either. This causes a 404 until the frontend cache is cleared.

This is true too

#6

Updated by Guido Schmechel 7 months ago

  • Related to Feature #92004: Create redirect entry if updated slug is published to live added
#7

Updated by Daniel Goerz 4 months ago

  • Related to Task #89301: Streamline automatic slug & redirects handling added
#8

Updated by Daniel Goerz 4 months ago

  • Related to Task #90143: Redirects: Poor performance of redirect matching for large redirects table added

Also available in: Atom PDF