Project

General

Profile

Actions

Feature #24926

closed

Allow identical page aliases on different domains

Added by Ralf Strobel about 13 years ago. Updated almost 5 years ago.

Status:
Closed
Priority:
Should have
Assignee:
-
Category:
Frontend
Target version:
-
Start date:
2011-02-02
Due date:
% Done:

0%

Estimated time:
PHP Version:
5.3
Tags:
Complexity:
medium
Sprint Focus:

Description

I would like to make a notion to adopt the behavior of the extension "ods_multiple_pagealias" into the Typo3 core, since I believe it does something very reasonable:

It allows you to assign a page alias more than once, as long as both pages are in separate parts of the page tree, assigned to different domains.

The extension currently does not work for Typo3 4.3+ and the author is not going to fix it, but I will take a look at it over the next weeks. Any help in this would be greatly appreciated.

Like many others, I do not want to use realurl for a simple website, because there is a straightforward inbuilt option to make Typo3 generate very elegant URLs:

simulateStaticDocuments = 1
simulateStaticDocuments_noTypeIfNoTitle = 1

However, since my installation hosts multiple domains, I run into the issue that I cannot assign the same page alias in a second domain, when it is already in use by another. For common names like "contact" this is very annoying, since my customers don't want to go by a "contact0.html".

The approach of ods_multiple_pagealias does not seem very complicated, so I think integrating it into the core should be worth the effort:
http://typo3.org/extensions/repository/view/ods_multiple_pagealias/current/info/class.tx_multiplepagealias.php/
(issue imported from #M17441)


Related issues 1 (0 open1 closed)

Related to TYPO3 Core - Epic #84728: Introduce speaking URLs for pages ClosedBenni Mack2018-08-22

Actions
Actions #1

Updated by Ralf Strobel about 13 years ago

Ok, the issue with Typo3 4.3+ was actually smaller than I expected...

The problem was that ods_multiple_pagealias relies on the output of simulatestatic in terms of resolving the URI. Since simulatestatic is now an extension itself and uses the same hook as ods_multiple_pagealias, the two may be executed in the wrong order .

All you have to make sure of, is that "ods_multiple_pagealias" is listed after "simulatestatic" in $TYPO3_CONF_VARS['EXT']['extList'] and ['extList_FE']. Then the extension still works flawlessly.


Regardless of this, I still think this behavior should become the default. To achieve this, it would be best to first modify the function "class.t3lib_page->getPageIdFromAlias" accordingly.

After that, you would of course also have to adopt the advanced alias duplicate check the extension now implements through processDatamap_preProcessFieldArray.

Actions #2

Updated by Andreas Wolf over 12 years ago

  • Category deleted (Communication)
  • Status changed from New to Needs Feedback
  • Target version deleted (0)
  • Complexity set to medium

Any news on that? I'm going to close this issue if there's no feedback within one week (nothing personal, just regular BT housekeeping). If you need help when digging further into that (or even providing a patch, which would be great), just contact me this week (or the respective friendly ghost the next weeks).

Regarding the problem with simulatestatic, it should be sufficient to list that extension as a prerequisite for ods_multiple_pagealias. That way simulatestatic will be installed before ods_multiple_pagealias when installing via the EM.

Actions #3

Updated by Alexander Opitz over 10 years ago

  • Status changed from Needs Feedback to Closed

No feedback for over 90 days.

Actions #4

Updated by Ingo Renner over 10 years ago

  • Status changed from Closed to New

still valid. Alexander, could you please stop closing valid issues? I agree with closing old issue, but at least try to reproduce them please.

Actions #5

Updated by Mathias Schreiber about 9 years ago

  • Category set to Frontend
  • Target version set to 7.2 (Frontend)
Actions #6

Updated by Benni Mack almost 9 years ago

  • Target version changed from 7.2 (Frontend) to 7.4 (Backend)
Actions #7

Updated by Thomas Oliver Moll over 8 years ago

This is also very desirable in 6.2

Actions #8

Updated by Susanne Moog over 8 years ago

  • Target version changed from 7.4 (Backend) to 7.5
Actions #9

Updated by Benni Mack over 8 years ago

  • Target version deleted (7.5)
Actions #10

Updated by Riccardo De Contardi over 5 years ago

  • Related to Epic #84728: Introduce speaking URLs for pages added
Actions #11

Updated by Benni Mack over 5 years ago

Hey,

this issue should be fixed with 9 LTS and site handling by using the new Page based URL routing. Please let us know if the new version will solve your issue, otherwise we'll close this ticket in the next weeks.

Benni.

Actions #12

Updated by Benni Mack over 5 years ago

  • Status changed from New to Needs Feedback
Actions #13

Updated by Sebastian Schawohl over 5 years ago

Benni Mack wrote:

this issue should be fixed with 9 LTS and site handling by using the new Page based URL routing. Please let us know if the new version will solve your issue, otherwise we'll close this ticket in the next weeks.

I think it's fixed, aliases were treated as a slug before 9 LTS.

With 9 LTS the alias feature is gone, there is no field anymore.

I've not tested yet, but is the handler syntax with alias still working?

What I'm missing is a real alias which is transformed in the uid and only that (no URL handling).

My use case is: with a multiple root pages, it's common to have a contact page (for example) for each site. Today I need TypoScript constants for each contact page, but it would be nice to have an alias field for each page, and in my Fluid templates be able to link to the alias, like the handler syntax t3://page?alias=contact.
The URL would be handled by the slug.

For two contact pages in two sites, same alias, but different URL:

Maybe I should open a new issue for that case.

Actions #14

Updated by Benni Mack almost 5 years ago

  • Status changed from Needs Feedback to Closed

yeah, let's open up a new ticket for this. It's more like a "Use human-readable shortcut ID instead of numeric ID to reference pages in Backend" Feature, right?

Actions

Also available in: Atom PDF