For Moodle 4.1 and up, the php-xmlrpc is not needed anymore:
- All the MNet stuff has been moved to use php library (MDL-76055).
- The webservice/xmlrpc has been moved from core to contrib (MDL-76052).
So we just remove the check here. Starting with 4.1, it's not
needed for any core functionality.
No lang string changes in this branch, only in master (4.1dev).
Because @coversDefaultClass doesn't indicate any coverage (it's
just an alias to avoid having to write the class name in @covers),
this commit fixes all the files that were using that annotation
and missing any @covers.
Basically, replacing one by the other and done.
* When the language pack being deleted is
- the same as the site default language, we must set the site default
language to 'en'.
- fix the user's current language to the default site language.
Adjusts the testing scenarios so that we don't rely on endpoint
discovery being run during an issuer edit, which is no longer the case.
For scenarios that need a userinfo endpoint, set this manually.
When an HTML content area contains invalid HTML, some editors will clean
and validate the content upon submission.
In this case the content was:
<b>Test content</b>
But this should be wrapped in some form of container which accepts
phrasing content (such as a <p> tag).
Some editors, such as TinyMCE, will normalise the content and add the
wrapping paragraph tags to it.
Furthermore, the bold tag is purely stylistic and does not have semantic
meaning. As a result, the <strong> tag is favoured and some editors,
again such as TinyMCE, will replace bold tags with strong tags.
We should update the content here to be valid HTML (wrap the bold tag
in a para), and use a strong tag rather than bold. This allows this test
to pass both with Atto, and other stricter editors such as TinyMCE 6.
This issue just goes over all the currently incorrect
namespaces in test cases and:
1. Change the namespace to the correct one.
2. Move/rename it to correct location if needed (level 2 and down).
3. Remove not needed MOODLE_INTERNAL check when possible.
4. Remove file phpdoc when the file only has one class.
5. Make small adjustments in case the change of namespace requires it.
There is an upgrade to clean the moodlenetprofile field which
performs very poorly, but it is also not needed because an upgrade
further down sets this field to empty string anyway.
The enabled state of a plugin is a tri-state value (boolean or
null). We should be consistent with elsewhere by only considering
boolean false as an actually disabled plugin.
See also cdcb53a1 for similar change in task management.
When resetting report filters, we need to include the original report
parameters in the external method call to ensure all those that are
required during validation are present (e.g. when determining if user
can view the current system report).
This is a partial backport of MDL-73270 to ensure that the
check_xmlrpc_usage custom check is present in all the supported
branches and it's applied to all branches able to run php80:
- MOODLE_311_STABLE
- MOODLE_400_STABLE
- master (aka, 4.1 and up)
Note that the whole patch has not been backported, only the
environmental check (xml file and check implementation).
Applied the following changes to various testcase classes:
- Namespaced with component[\level2-API]
- Moved to level2-API subdirectory when required.
- Fixed incorrect use statements with leading backslash.
- Remove file phpdoc block
- Remove MOODLE_INTERNAL if not needed.
- Changed code to point to global scope when needed.
- Fix some relative paths and comments here and there.
- All them passing individually.
- Complete runs passing too.
Special mention to:
- Some fixtures, initially defined in the test files have been
moved to new files in fixtures subdirectory, leaving the unit
test files clearer:
- moodle2_course_format_test.php
- Rename wrong named test:
- baseoptiogroup_test = baseoptigroup_test
Adds a callback xxx_pre_enable_plugin_actions in admin/modules.php
which plugins can use to force additional actions before enabling the
plugin. The return value (bool) from the plugin callback method
specifies whether the process of enabling the plugin should continue
after the added actions or not.
Sara Arjona