Bug #90736

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

Added by Jan Kornblum almost 2 years ago. Updated over 1 year ago.

Status:
Closed
Priority:
Should have
Assignee:
-
Category:
Link Handling, Site Handling & Routing
Start date:
2020-03-11
Due date:
% Done:

100%

Estimated time:
TYPO3 Version:
9
PHP Version:
7.2
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

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.Needs Feedback2018-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-levelNeeds Feedback2019-09-30

Actions
#1

Updated by Jan Kornblum almost 2 years ago

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

Updated by Jan Kornblum almost 2 years ago

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

Updated by Jan Kornblum almost 2 years ago

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

Updated by Jan Kornblum almost 2 years ago

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

#5

Updated by Jan Kornblum almost 2 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
#6

Updated by Jan Kornblum almost 2 years ago

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

Updated by Jan Kornblum almost 2 years ago

  • Description updated (diff)
#8

Updated by Jan Kornblum almost 2 years ago

  • Description updated (diff)
#9

Updated by Riccardo De Contardi almost 2 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?

#10

Updated by Juan Manuel Vergés Solanas almost 2 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 '/'

#11

Updated by Juan Manuel Vergés Solanas almost 2 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&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

#12

Updated by Riccardo De Contardi almost 2 years ago

  • Status changed from Needs Feedback to New
#13

Updated by Riccardo De Contardi almost 2 years ago

Is this issue related? #89311

#14

Updated by Markus Klein almost 2 years ago

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

Updated by Juan Manuel Vergés Solanas almost 2 years ago

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

Updated by Juan Manuel Vergés Solanas almost 2 years ago

Riccardo, yes it is

#17

Updated by Gerrit Code Review over 1 year 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

#18

Updated by Gerrit Code Review over 1 year 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

#19

Updated by Gerrit Code Review over 1 year 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

#20

Updated by Helmut Hummel over 1 year ago

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

Updated by Benni Mack over 1 year ago

  • Status changed from Resolved to Closed

Also available in: Atom PDF