Project

General

Profile

Actions

Feature #65998

closed

TypeNum redirect on shortcut page

Added by Arek van Schaijk about 9 years ago. Updated over 6 years ago.

Status:
Closed
Priority:
Should have
Assignee:
-
Category:
Frontend
Target version:
-
Start date:
2015-03-24
Due date:
% Done:

0%

Estimated time:
PHP Version:
5.5
Tags:
Complexity:
Sprint Focus:

Description

Hi,

My pagetree looks like:

Website name [1] [shortcut:2]
- Home [2]
- ...

When registrering a new page type by TypoScript:

xml_sitemap = PAGE
xml_sitemap {
    typeNum = 123
    10 = USER_INT
    10 {
        userFunc = TYPO3\MyExtension\Controller\SitemapController
    }
    config {
        disableAllHeaderCode = 1
        additionalHeaders = Content-type:text/xml
        xhtml_cleaning = 0
        // additional configuration
    }
}

http://domain.com/?type=123 is redirected to http://domain.com/?id=2&type=123.

I've configured my typeNum as a filename in the realurl configuration.
So 'sitemap.xml' will be ?type=123

Because 'Website name [1]' is an shortcut to 'Home [2]' domain.com/sitemap.xml is redirected to domain.com/home/sitemap.xml which is obvious pretty ugly :(

After spending some time in the core I figured out that the 'redirect' happens in typo3/sysext/cms/tslib/index_ts.php on line 190.
[[https://forge.typo3.org/projects/typo3cms-core/repository/entry/typo3/sysext/cms/tslib/index_ts.php?rev=TYPO3_6-2#L190]]

When I remove this function here I get my sitemap.xml working under domain.com/sitemap.xml.

I suggest a new page.config like:

xml_sitemap = PAGE
xml_sitemap {
    typeNum = 123
    10 = USER_INT
    10 {
        userFunc = TYPO3\MyExtension\Controller\SitemapController
    }
    config {
        // ...
        *ignorePageRedirect = 1*
    }
}

The TypoScriptFrontendController has already access to this configuration. So checkPageForShortcutRedirect() should be extended with a check like:

Ref: [[https://forge.typo3.org/projects/typo3cms-core/repository/entry/typo3/sysext/frontend/Classes/Controller/TypoScriptFrontendController.php?rev=TYPO3_6-2#L3195]]

    public function checkPageForShortcutRedirect() {
        if(!$this->$this->pageRenderer->getIgnorePageRedirect()) {
            if (!empty($this->originalShortcutPage) && $this->originalShortcutPage['doktype'] == PageRepository::DOKTYPE_SHORTCUT) {
                $this->redirectToCurrentPage();
            }
        }
    }

This is backward compatible and does not affect anything.

Actions #1

Updated by Mathias Schreiber about 9 years ago

  • Assignee set to Benni Mack

@Benni Mack: thoughts?

While I like the general approach which is rather unobstrusive, adding new options is something I kinda want to avoid.

Actions #2

Updated by Arek van Schaijk about 9 years ago

In my opinion you should treat this as a bug since a type-called-page has nothing to do with the page settings (especially nothing with the shortcut/redirect).
But it can affect developers who did tricky stuff to avoid this problem or who are depending on it (fe. template engines). My approach doesn't affect them.

Actions #3

Updated by Georg Ringer about 9 years ago

I would vote against! A type is just a view of a page which is in that case a shortcut.
But won't block any other opinions!

Actions #4

Updated by Arek van Schaijk almost 9 years ago

Any update on this?
I really need "something" to get rid of the redirection thing on page type numbers, please consider my easy to implement page.config option.

Actions #5

Updated by Susanne Moog over 8 years ago

We usually solve this differently, by reversing the shortcut (Home2 is a shortcut to Website name1) and menu active states and the like are handled via condition and alwaysActivePIDlist - then you don't have that problem, no matter the page type ;)

In general I'm pretty much against this feature as a page type just represents a different representation of the same page tree structure and should not behave differently where routing is concerned.

Actions #6

Updated by Riccardo De Contardi over 6 years ago

  • Status changed from New to Closed
  • Assignee deleted (Benni Mack)

I hope it is ok for you if I close this issue for now. It has been open for such a long time and nothing really happened;

What Georg Ringer wrote is correct: types are bound to pages, so any page behavior should be applied to all types.
In your specific case, you should use an eID script instead which bypasses all of this.

You could also consider the suggestion from Susanne Moog.

Feel free to open a discussion or a new issue on that if you feel that is important for you, writing in detail your concept and ideas.

Thank you and best regards.

Actions

Also available in: Atom PDF