Typecho route matching conflict: Why is my /test/tag/his/10086 matching TestTagIndex instead of TestTagPage?

Typecho routing matching rules analysis and problem investigation

This article will analyze and answer questions about the inconsistent results of the typecho plug-in routing registration and the actual matching results. The problem is mainly reflected in the matching accuracy of custom routing rules. In some cases, routing rules fail to accurately match the expected request path.

In the problem description, the developer registered four routing rules: testindex, testpage, testtagindex, and testtagpage, which correspond to the four paths of /test/, /test/page/[page:digital]/, /test/tag/[keywords]/, /test/tag/[keywords]/[page:digital]/ respectively. The developer provides test cases where most route matching results are as expected, but the actual match result of /test/tag/hello/10086 is testtagindex, not the expected testtagpage, which indicates that there is a conflict or inaccuracy of route matching rules.

Typecho's routing matching mechanism follows certain rules, which will try to match the requested URL with the registered routing rules. It should be noted that [keywords] and [page:digital] are parameter placeholders in the typecho routing system, where the [page:digital] limiting parameters must be numbers. During the matching process, typecho will match according to the order of routing rules, and find the first match rule, that is, stop the match.

The reason for the problem is the order of routing rules and the priority of parameter matching. /test/tag/[keywords]/ and /test/tag/[keywords]/[page:digital]/. When the request path is /test/tag/hello/10086, typecho first matches /test/tag/[keywords]/. Because Hello, it meets any character matching rule of [keywords], the match is successful and returns testtagindex. Although /test/tag/[keywords]/[page:digital]/ This rule also meets, it is not executed due to the matching order.

To solve this problem, it is recommended to adjust the registration order of routing rules and put more specific routing rules in front. For example, you can register /test/tag/[keywords]/[page:digital]/ before /test/tag/[keywords]/. In this way, when the request path contains numeric page parameters, typecho will preferentially match the more specific rule testtagpage. By adjusting the order of routing rules, rule conflicts can be effectively avoided and the accuracy of routing matching results can be ensured.

The modified activate() function is as follows:

 public static function activate() {
    Helper::addRoute('TestIndex', '/test/', 'Test_Widget_Contents_Rows', 'render');
    Helper::addRoute('TestPage', '/test/page/[page:digital]/', 'Test_Widget_Contents_Rows', 'render');
    Helper::addRoute('TestTagPage', '/test/tag/[keywords]/[page:digital]/', 'Test_Widget_Contents_Rows', 'render');
    Helper::addRoute('TestTagIndex', '/test/tag/[keywords]/', 'Test_Widget_Contents_Rows', 'render');
}

By adjusting the registration order of routing rules, the problem of inconsistent routing matching can be effectively solved. It should be noted that when writing typecho routing rules, the order of rules and priority of parameter matching should be carefully considered to avoid conflicts and inaccurate matching results.

The above is the detailed content of Typecho route matching conflict: Why is my /test/tag/his/10086 matching TestTagIndex instead of TestTagPage?. For more information, please follow other related articles on the PHP Chinese website!