Opened 9 years ago
Closed 3 years ago
#35269 closed feature request (wontfix)
Check data type of wp_xmlrpc_server_class filter before instantiate wp_xmlrpc_server_class
Reported by: |
|
Owned by: | |
---|---|---|---|
Milestone: | Priority: | normal | |
Severity: | normal | Version: | 4.4 |
Component: | XML-RPC | Keywords: | |
Focuses: | Cc: |
Description
There is a filter 'wp_xmlrpc_server_class' in ./xmlrpc.php for a plugin to entirely replace the standard XML-RPC server implementation.
For some case we want to entirely disable XML-RPC server. So we pass a FALSE value through the wp_xmlrpc_server_class filter. And it causes a Fatal error in xmlrpc.php
To prevent this error we pass a fake class name that contains a blank method serve_request.
But it would better if there is a validity check of the return value of wp_xmlrpc_server_class filter.
If the return value is not a valid class_name then $wp_xmlrpc_server_class will not be instantiated and process will be exit there.
I have a patch for this.
Attachments (1)
Change History (4)
#2
@
8 years ago
- Keywords dev-feedback added
My first feedback still stand with the addition that xmlrpc_enabled only works for the XML-RPC methods and not for pingback as described in #36055.
Any lead that can share their opinion if we should or shouldn't do this?
#3
@
3 years ago
- Keywords dev-feedback removed
- Resolution set to wontfix
- Status changed from new to closed
I'm going to close this one out. The preferred way to disable XML-RPC is using the xmlrpc_enabled
filter as described above.
If someone can document in detail why this filter is insufficient, this can be reopened.
There is the filter 'xmlrpc_enabled' that handles this case. This is handled inside the class so it can pass a XML-RPC response that says "XML-RPC services are disabled on this site". Personally I think that would be the way to go.
So I'm tend to say that this is something we don't need but I would not have any problems with a class_exists check.