This will find all data generators that can be used in behat via the
'the following "something" exist:' step, and display them in a select
list on the step definitions page.
When a generator is selected, it will fetch the required fields for that
generator and display them on the page.
Under some linux versions, and depending of the configured
locale categories, it's possible to get a current locally
which length > 255 when calling to setlocale(LC_ALL, 0).
Later, if that long locale is tried to be restored, there
is a "setlocale(): Specified locale name is too long" warning
error.
When that happens we need to split the long locale into
individual chunks and set all the (six) locale categories
supported one by one.
Covered with tests, note that, in practice, this only
happens with linux because it supports 12 locale categories
@ OS level. Both BSD (6) and Windows (5) hardly can reach the limit.
No matter of that, the tests have been designed to ensure that
they pass on all OSs, just the new code only will be executed
on linux.
Including in this commit:
- Convert existing Behat scenario to use Data generators
- Convert existing Behat scenario to use Provider
- Add new scenario for Include users setting in General restore page
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.
Sara Arjona