In PHP 8.2 and later, setting a value to an undeclared class property is
deprecated and emits a deprecation notice.
So we need to add missing class properties that still need to be declared.
This partially reverts MDL-73270, where some useful environmental
checks and notifications in the admin UI were added to inform
about different parts of Moodle relying on the "unsupported"
php-xmlrpc extension.
Since then, some changes have happened in core, only available
for Moodle 4.1 and up (see the MDL-70889 mini-epic). Namely:
- MNet (SSO, roaming, auth, enrol and Mahara portfolio) are not
using the php-xmlrpc extension anymore, but a pure php library.
- The xmlrpc webservices protocol, has been move from core to
the plugins directory, although it continues using the php-xmlrpc
extension.
Because of that here we are removing all the checks and notifications
related with MNet (not using the extension anymore), but keeping the
webservice plugin ones (still using the extension). Surely if some day the
protocol stops using the extension, we'll be able to remove the
corresponding checks too. But that's future.
Note the associated lang strings have been also removed (not deprecated)
because they were highly specific and hardly reusable:
- xmlrpcmaharaenabled
- xmlrpcmnetauthenticationenabled
- xmlrpcmnetenabled
And very same applies, because MNet doesn't contain anything deprecated
or not supported anymore, hence, straight deletion, to the function:
- mnet_get_deprecation_notice()
Also, related tests using any of the removed stuff above have been deleted.
In the other side, the "check_xmlrpc_usage" continues existing and
being used both by environment checks and admin notifications but,
as commented above, now it only looks for the xmlrpc webservice
protocol now.
This service is different from the rest because it
doesn't run encrypted, but plain xmlrpc. Hence, we
cannot use the normal mnet_xmlrpc_client (that provides
on-the-fly encryption and signing).
So, instead, let's instantiate a custom client here
and use it for this pure xmlrpc request and response.
PS: It's curious that this exact sevice has support
for proxies but the mnet_xmlrpc_client one has not. I'm not
going to modify that here, but have left a comment
in the code about that.
PS: Some small style changes have been applied around
the modified code (spacing, &&, comments...)
Using moodle_url where possible is preferable to hardcoding uri's as
moodle_url is able to take care of alot of the formatting for us.
In this instance, it handles the $CFG->admin url path for us.
Several places in admin/mnet pull in required files using a hardcoded
admin dir string, as this is configurable it needs to use $CFG->admin
instead.
Places where the url is passed through moodle_url don't need to be
updated as that already automatically translates the urls for us.
dirname() is a slow function compared with __DIR__ and using
'/../'. Moodle has a large number of legacy files that are included
each time a page loads and is not able to use an autoloader as it is
functional code. This allows those required includes to perform as
best as possible in this situation.
While fixing MDL-30170, the following tiny usability details were
improved along the way:
* the maximum length of the peer site title and the hostname is now
validated (this was actually a real bug as the default value is pre-loaded
from the peer) so the admin gets a nice validation error instead of
the database write exception when trying to register a host with a
longer site title.
* hard-coded English string 'All Hosts' is now localized
* the hostname link in the list of MNet peers leads to the peer itself
The patch highlights the undelete radio selector at the host edit form.
It moves it to the end of the form (near the submit button) and displays
an explanation above the radio selector.
Also, the list of deleted hosts is now displayed below the table of
active peers at the Manage peers page.
The data returned by mnet_get_hosts() function now contain the deleted
status, too. It is possible to obtain deleted hosts from that function
now.
Please note all plugin references from core should use callbacks, it is not ok to use capabilities or links to plugins because they may not be present in customised installs.
