/
Cleanup redirect code [5.3.0-B1]
Cleanup redirect code [5.3.0-B1]
Redirect is a way for In-Portal to show user the content, that otherwise might be lost if user accesses the wrong page url. Here are redirects, that are currently made:
When Redirected | Redirect Place (in code) | Why Redirected | To Where Redirected |
---|---|---|---|
maintenance mode is enabled | kApplication::Run | Accessing any, but "Maintenance Mode" page | "Maintenance Mode" page |
kRedirectException exception is thrown | kRedirectException::run | Somebody threw the kRedirectException exception | Wherever kRedirectException wants |
after event is finished executing | RequestManager::performRedirect | To avoid double form submit problem on F5 press | Same page |
| kRewriteUrlProcessor::_redirectToDefaultUrlEnding | To ensure page url in browser always have ".html" | Same page, but with ".html" appended |
| kHTTPQuery::AfterInit | To ensure all pages on website have mod-rewrite urls | Mod-rewrite url equivalent of visited page |
IP address of the visitor matches IP range from Site Domain | SiteDomainEventHandler::querySiteDomain | Because Site Domain IP redirect feature was enabled |
|
| LanguagesItem::Load (via kRedirectException) | To show website content on user preferred language automatically | Same page, but on different language |
It's clearly seen based on above table, that there is no single solution/place for doing redirects and they can happen any time without developer even knowing/willing.
Solution
- create extension point in "kApplication::Run" method (where we know, that user wants to see the page)
- move "redirect or not redirect" decision making to that extension point
This way:
- there will be a central place to find all possible redirects
- if we're not showing any content back to user, then we even don't bother checking if a redirect should be happening
- instead of doing several redirects in a row (to match a Site Domain and user language) we can combine them into one