Updated x-http-method-override rules for rest-api usage:

[joostdekeijzer]

Tested for WordPress setup:

1. without permalinks (rule 9507144)
2. With permalinks (rule 9507146)

The permalink setup now works for:

• Multisite (regex ^/([_0-9a-zA-Z-]+/)?wp-json/ based on WordPress multisite .htaccess rule)
• Saving custom post types (eg. POSTs to http://mysite.com/wp-json/wp/v2/events/4693?_locale=user)
• Actually any wp-json call based on info on https://developer.wordpress.org/rest-api/using-the-rest-api/global-parameters/#_method-or-x-http-method-override-header

The developer info states the header should only be used in POST requests, so added that requirement.

[azurit]

@joostdekeijzer Can you fix errors? Thanks.

Lint Yaml: tests/regression/wordpress-rule-exclusions-plugin/9507144.yaml#L45
45:1025 [line-length] line too long (2752 > 1024 characters)

Lint Yaml: tests/regression/wordpress-rule-exclusions-plugin/9507144.yaml#L25 
25:1025 [line-length] line too long (1523 > 1024 characters)

[joostdekeijzer]

@joostdekeijzer Can you fix errors? Thanks.

Lint Yaml: tests/regression/wordpress-rule-exclusions-plugin/9507144.yaml#L45
45:1025 [line-length] line too long (2752 > 1024 characters)

Lint Yaml: tests/regression/wordpress-rule-exclusions-plugin/9507144.yaml#L25 
25:1025 [line-length] line too long (1523 > 1024 characters)

Yes, I got a report from the workflow 😄

[joostdekeijzer]

Thinking a bit more about this (while making my own installation support 3rd party plugins and custom development):

With this patch, in a WordPress install "without permalinks" (rule 9507144) any POST to the WordPress REST API may use the x-http-method-override while WordPress installations "with permalinks" (rule 9507146) there is only limited support (only core WordPress requests).

So:

• rule 9507144 supports both core WordPress + any custom development or 3rd party
• rule 9507146 only supports core WordPress as is implemented at this moment.

Wouldn't it be most logical to have both rules support the same REST API requests?

[EsadCetiner]

@joostdekeijzer

With this patch, in a WordPress install "without permalinks" (rule 9507144) any POST to the WordPress REST API may use the x-http-method-override while WordPress installations "with permalinks" (rule 9507146) there is only limited support (only core WordPress requests).

This is just an unintended side effect of the rule. if you want to, add an extra chain rule for 9507144 to allow the rule for a handful of rest_routes you can see some of the other rules in the plugin to see how this is done.

[joostdekeijzer]

I think I understand your "unintended side effect" argument.

But, so I don't have to add a custom rule to my config for every WordPress site I host, I would like rule 9507146 to have the same "side effect" 😄

[joostdekeijzer]

Updated due to fb32c34 renumbering.

[EsadCetiner]

@joostdekeijzer

But, so I don't have to add a custom rule to my config for every WordPress site I host, I would like rule 9507146 to have the same "side effect" 😄

I understand the reasoning as to having the rules a bit laxer to allow for custom post types, can you open another PR for that?

But this won't mean that we're supporting 3rd party plugins, we don't have the manpower to maintain and test all of these 3rd party plugins.

[joostdekeijzer]

@EsadCetiner

I'll create another PR for relaxing the wp-json x-http-method-override rule after this PR (so they don't interfere).

And I really do understand you don't want to open a door to supporting 3rd party plugins.

[EsadCetiner]

@joostdekeijzer Looks ready to merge, ignore the failure from the syntax check workflow it's broken.

@airween Can you take a look at this https://github.com/coreruleset/wordpress-rule-exclusions-plugin/actions/runs/19062257393/job/54447882123?pr=96 valid syntax is being marked as invalid