Project

General

Profile

Actions

Bug #90736

open

Wrong slug fields for siteroots (level > 1) in multidomain environment and no possibility to modify them

Added by Jan Kornblum over 4 years ago. Updated about 2 years ago.

Status:
New
Priority:
Must have
Assignee:
-
Category:
Site Handling, Site Sets & Routing
Target version:
Start date:
2020-03-11
Due date:
% Done:

90%

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

Description

In a multidomain environment (where the sites are not located in the first level) the "is_siteroot" pages slugs are generated wrong. In addition, there is currently no possibility to manage them without directly modifying the slug in the database.

For example, if a new page is created in level 2, depending on the way it is created (wizard and from type of the parent from which executed) the slug field is shown in tca form. Even if slug is set to "/" here, "/1" or similar is saved instead. After that the field is not shown ony more at all.

Suggestion: At least when the created page is set to "is_siteroot", the slug should automatically bet set to "/".

Regarding multi language sites (like in my case), the behaviour should be checked, too. But it looks like the translated pages slug ist correctly set to "/".

I am using version 9.5.14.

- Root [0]
-- Start [1] (Just for assigning some global TS, often use case)
--- Domain A [is_siteroot + site configuration] -> Slug is set to "domaina" or (if set to "/" if form is shown) to "/1" 
--- Domain B [is_siteroos + site configuration] -> Slug is set to "domainb" or (if set to "/" if form is shown) to "/2" 

Files

Schermata 2020-03-29 alle 17.38.57.png (188 KB) Schermata 2020-03-29 alle 17.38.57.png Riccardo De Contardi, 2020-03-29 17:40

Related issues 5 (1 open4 closed)

Related to TYPO3 Core - Feature #86216: Allow empty slug for root pages and sysfoldersNew2018-09-10

Actions
Related to TYPO3 Core - Bug #89485: Editing a slug field on a root page (page with SiteConfiguration) is not possible if parent uid of this root page is > 0 and TreeRoot has no site configurationClosed2019-10-23

Actions
Related to TYPO3 Core - Bug #86727: Numeric in slugs on multidomain instances.Closed2018-10-24

Actions
Related to TYPO3 Core - Bug #90932: PseudoSiteTcaDisplayCondition always checks l10n_parentClosed2020-04-02

Actions
Related to TYPO3 Core - Bug #89311: Flaws in site configuration when creating new page on root-levelRejected2019-09-30

Actions
Actions #1

Updated by Jan Kornblum over 4 years ago

  • Related to Feature #86216: Allow empty slug for root pages and sysfolders added
Actions #2

Updated by Jan Kornblum over 4 years ago

  • Related to Feature #86216: Allow empty slug for root pages and sysfolders added
Actions #3

Updated by Jan Kornblum over 4 years ago

  • Related to deleted (Feature #86216: Allow empty slug for root pages and sysfolders)
Actions #4

Updated by Jan Kornblum over 4 years ago

I can show an example (desktop sharing) if somebody is interested (contact me in slack).

Actions #5

Updated by Jan Kornblum over 4 years ago

  • Related to Bug #89485: Editing a slug field on a root page (page with SiteConfiguration) is not possible if parent uid of this root page is > 0 and TreeRoot has no site configuration added
Actions #6

Updated by Jan Kornblum over 4 years ago

  • Related to Bug #86727: Numeric in slugs on multidomain instances. added
Actions #7

Updated by Jan Kornblum over 4 years ago

  • Description updated (diff)
Actions #8

Updated by Jan Kornblum over 4 years ago

  • Description updated (diff)
Actions #9

Updated by Riccardo De Contardi over 4 years ago

Is this issue still present on latest master? Could you add a step-by-step guide about how to reproduce it?

In a configuration like the one in my attached file (Schermata 2020-03-29 alle 17.38.57.png) the slug field seems available and editable.

Am I missing something?

Actions #10

Updated by Juan Manuel Vergés Solanas over 4 years ago

Hi,

I can reproduce this issue in 9.5.14 and I would say it persist in latest taking a look to the code.

Files affected are

/backend/Resources/Private/TypeScript/FormEngine/Element/SlugElement.ts
/backend/Classes/Controller/FormSlugAjaxController.php
/core/Classes/DataHandling/SlugHelper.php

This line should return '/' for the case described in the issue
https://github.com/TYPO3/TYPO3.CMS/blob/master/typo3/sysext/core/Classes/DataHandling/SlugHelper.php#L161

However, is_siteroot is not populated nor in /backend/Classes/Controller/FormSlugAjaxController.php
neither sent in the ajax call done in /backend/Resources/Private/TypeScript/FormEngine/Element/SlugElement.ts

I would say that this could be fixed in SlugHelper.php doing an additional database request if isset( $recordData['is_siteroot'] ) == false if this issue can be reproduced in other scenarios.
If not, populating it in any of the 2 other files involved.

My scenario is slightly different: we have a is_siteroot inside a is_siteroot tree. The slug of the subtree is getting the whole path from the upper level tree instead of returning '/'

Actions #11

Updated by Juan Manuel Vergés Solanas over 4 years ago

I just found an easier fix

https://github.com/TYPO3/TYPO3.CMS/blob/1d11c3131e302360c96fb39ecacee18fd88099b1/typo3/sysext/core/Configuration/TCA/pages.php#L162
'fields' => ['title','is_siteroot']

However, as is_siteroot is a checkbox

<div class="checkbox checkbox-type-toggle">
<input type="checkbox" class="checkbox-input" value="1" data-formengine-input-name="data[pages]3089[is_siteroot]" onclick="document.editform['data[pages]3089[is_siteroot]'].value=this.checked?(document.editform['data[pages]3089[is_siteroot]'].value|1):(document.editform['data[pages]3089[is_siteroot]'].value&amp;0);TBE_EDITOR.fieldChanged('pages','3089','is_siteroot','data[pages]3089[is_siteroot]');" 1="" id="data_pages_3089_is_siteroot_0_5e851dae5f797895765675">
<label class="checkbox-label" for="data_pages_3089_is_siteroot_0_5e851dae5f797895765675">
<span class="checkbox-label-text"> </span>
</label>
</div>

the SlugElement.ts is not checking if it is checked and then returning always is_siteroot=1

Actions #12

Updated by Riccardo De Contardi over 4 years ago

  • Status changed from Needs Feedback to New
Actions #13

Updated by Riccardo De Contardi over 4 years ago

Is this issue related? #89311

Actions #14

Updated by Markus Klein over 4 years ago

  • Related to Bug #90932: PseudoSiteTcaDisplayCondition always checks l10n_parent added
Actions #15

Updated by Juan Manuel Vergés Solanas over 4 years ago

  • Related to Bug #89311: Flaws in site configuration when creating new page on root-level added
Actions #16

Updated by Juan Manuel Vergés Solanas over 4 years ago

Riccardo, yes it is

Actions #17

Updated by Gerrit Code Review over 4 years ago

  • Status changed from New to Under Review

Patch set 1 for branch 9.5 of project Packages/TYPO3.CMS has been pushed to the review server.
It is available at https://review.typo3.org/c/Packages/TYPO3.CMS/+/65066

Actions #18

Updated by Gerrit Code Review over 4 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/c/Packages/TYPO3.CMS/+/65116

Actions #19

Updated by Gerrit Code Review over 4 years ago

Patch set 1 for branch 10.4 of project Packages/TYPO3.CMS has been pushed to the review server.
It is available at https://review.typo3.org/c/Packages/TYPO3.CMS/+/65192

Actions #20

Updated by Helmut Hummel over 4 years ago

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

Updated by Benni Mack about 4 years ago

  • Status changed from Resolved to Closed
Actions #22

Updated by Joe Jones about 2 years ago

  • Priority changed from Should have to Must have
  • Target version changed from Candidate for patchlevel to next-patchlevel
  • % Done changed from 100 to 90
  • TYPO3 Version changed from 9 to 11
  • PHP Version changed from 7.2 to 7.4

Hallo Gerrit, Helmut and Benni,

thanks for working on this Problem. Unfortunately it is not solved finaly. I am working with TYPO3 11.5.16 and want to build a multidomain website. Today I startet the second Rootline. After configuring I open the Frontend and at the URL the slug with the titel if the rootpage was added. I opend the page properties and tried to delete the slug, but when I tried to delete the slug, an /1 was added. I can not delete the slug.

I set is_siteroot to true
I setup second site configuration
I checkt root template clear constants, setup and set root to true.

Sorry, but the second siteroot is not level > 1!

I can provide further information if needed.

Thanks to you
Martin

Actions #23

Updated by Riccardo De Contardi about 2 years ago

  • Status changed from Closed to New
Actions

Also available in: Atom PDF