Smart URL Rewriting

[dtdesign]

URL rewriting is a feature that causes quite some friction because it requires exact rules that must be adjusted whenever apps are added or removed. This forces users more often than not to reach out for help because their newly installed app is dysfunctional when the real reason is that the rewrite rules are simply outdated. Even tricks like predefining a set typical values falls short when custom directory names are being used.

Smart URL Rewriting

We can solve this issue by directing all rewritten requests to the core and take care of the application mapping ourselves. This requires that all apps are a direct or indirect child of a single app (“single root”) which allows us to require only a single rewrite rule while simultaneously avoiding any conflicts with other content on the same website.

Core at Root

Setup:

• Core installed at /.
• Forum installed at /forum/.

rewrite ^/([^.]*)$ /index.php?$1;

Request for	getPath()	getPathInfo()
/members-list/	/	members-list/
/forum/board/2-default-forum/	/	forum/board/2-default-forum/

Core in a Subdirectory

Setup:

• Forum installed at /.
• Core installed at /core/.

rewrite ^/([^.]*)$ /core/index.php?$1;

Request for	getPath()	getPathInfo()
/core/members-list/	/core/	core/members-list/
/board/2-default-forum/	/core/	board/2-default-forum/

[dtdesign]

One issue that arose from this is that we can no longer distinguish between rewritten calls and those that did not use a rewritten path. This is a problem when the core is not at the root because the path will always point to the core but without indicating what app was being used in the first place.

Request for	getPath()	getPathInfo()
/core/members-list/	/core/	core/members-list/
/board/2-default-forum/	/core/	board/2-default-forum/
/core/index.php?ajax-proxy/	/core/	ajax-proxy/

The last request will now resolve to the root app which is not what was invoked in the first place. This is the result of try_files hitting the index.php directly and thus the rewrite rule is not applied at all.

It appears to be that there are only two ways to mitigate this problem:

1. Use a special parameter to process rewritten requests which serves as an indicator. Something like index.php?__rewritten=%s could be sufficiently unique for this purpose.
2. Restrict smart rewrites to setups where the core is the root app. This does align with our long-term plans of having everything being “physically” below the core and use rewrites to virtualize different app paths. This would also require URLs to be rewritten at all times which has the benefit of reducing the complexity.

Considering that all newer installs already use (2.) as the default this can severely simplify the configuration for these cases. For all other cases we can still fallback to the existing implementation (which is supported nonetheless!) which is more rigid but works with arbitrary setups. Requiring the core to be the root app for smart URL rewriting also greatly simplifies the whole logic by having to deal with only one case going forward.