The previous iteration only calculated it's zIndex value on
initial load. This meant that any nodes added subsequent to this
would not be taken into account (e.g. modal forms).
* Allow the more menu to be rendered as a tablist when needed.
* Let menu_navigation handle keyboard navigation only when
menu items are not rendered as dropdowns. Otherwise, leave
the keyboard navigation handling via the default handlers
(e.g. dropdown.js/aria.js/tab.js).
* When the more menu is rendered as a tablist, use aria-selected
for the selected tab. When it's rendered as a menu, use aria-current
for the selected menu item. (The menuitem role supports aria-current and
not aria-selected)
* Make sure that the active tab is tabbable by default.
* Submenu items should always have tabindex=-1
* Update behat to use css_element instead of xpath. Also, improved it
to consider that it is the active element that should be tabbable.
Co-authored-by: Shamim Rezaie <shamim@moodle.com>
An icon has been added near the 'Help and documentation' link in the
site footer When the site admin setting 'Open in new window' (doctonewwindow)
is enabled, for consistency with other similar links like 'Give feedback
about this software'.
Apart from that, now the link will be opened using the standard target
'_blank' instead of using the new window Javascript, to let users decide
whether the new page should be opened in a new tab or a new window.
When "Path to PHP CLI" is not defined, an exception with the message
in cannotfindthepathtothecli should be displayed, and the page should
be redirected to System paths settings page.
Apart from that, this patch also replaced core_task to tool_task,
because this message wasn't traslated properly.
In certain cases where it doesn't already redirect to run the upgrade,
users could see an exception 'Unexpectedly found non-versioned cache
entry'. This change ensures the upgrade happens instead.
The 'mbstring.func_overload' php init setting was removed for
php80 (it was deprecated since php72). So it won't evaluate to
true ever, so the whole block can be put under php version condition.
Note that this is already fixed upsteam, for commit:
e7165a33b2
And it has been released with version 2.14.1 of the library, so, once
we upgrade to it, the fix will be incorporated.
The PHP_CodeSniffer @codingStandardsIgnore annotations are deprecated
and, since version 3.x, the new // phpcs:ignore comments should be used
instead.
This commits just reviews all the uses in core, replacing them for
the better new candidate, or removing when no longer needed.
Before the patch, transliteration was only happening when the
encoding of the string was utf-8. For other encodings only a
simpler conversion (iconv) to ascii was done. For some reason
iconv() own transliteration abilities are not consistent
between systems (depends of libraries installed, locales and
other bits).
So now we always convert the string to utf-8, in order to
transliterate it. And finally, also perform an iconv to
cover some characters that transliterate doesn't handle ok.
Also, remove a block of code that does nothing (previously
it was executing some code, but now it just sets and restores
the error level for nothing).
The OBv2.0 specification includes a field "Criteria" for
BadgeClass. Until now, this field was filled using the
URL of the badge assertion, but that is causing some issues
in Badgr because it linked to the badge assertion of the
first user sending this badge to the Badgr backpack (so then,
the following users linked to the first user assertion page
too).
This patch adds a new page, badgeclass.php which will be
used from now to display any badge information which is
not related to any assertion (like happens with the criteria
in BadgeClass).
It has been detected, thanks to php80 specially, that there are
various places in core where support for localised floats is
missing. Before php80, some locale-dependent conversions were
performed by PHP, allowing things to work. But with php80 all
those comparisons are now locale-independent. See:
https://wiki.php.net/rfc/locale_independent_float_to_string
That implies that we now need to, always, unformat floats to
be internally the correct (decimal point as separator) in
order to compare it.
While this was visited in the php80 epic (MDL-70745), nothing
was found, all automated tests were passing ok. Problem is that
we run behat tests with en-AU laguage that has the decimal point
separator.
So, in this issue we are fixing all the problems detected by
running those Behat tests using localised (comma) decimal
separator.
Note that there may be other places still causing problems, but
it's really hard to find them programmatically, so we'll have to
wait for real use reports / issues and go fixing them while they
happen.
Back to this commit, this is the list of changes performed (note that
in the next commit, we'll be adding scenarios explicitly using
a localised decimal separator to ensure that they work ok).
A. Changes to various grade forms to ensure that, on their validation
floats are unformatted properly. Also, changed the corresponding
form element from current text/PARAM_RAW to proper float ones that
take care of the conversion in a number of places (but when disabled,
that's the reason we still have to unformat in validation.
This includes the following forms:
- edit_category_form
- edit_item_form
(this is the original problem reported that cause all the research
to be performed against full behat runs)
B. Changes to edit_letter_form, so it uses a proper PARAM_LOCALISEDFLOAT
(note this is the type of change that surely should be used for all
the rest of /grade/edit/tree form, including those in the previous
point).
C. Changes to the grade_item behat generator, so it's able to work with
localised floats, un-formatting them when needed.
At lib/behat/classes/behat_core_generator.php
D. Fix problem passing localised floats to scales, not displaying
properly. At grade/report/singleview/classes/local/ui/finalgrade.php
E. Change the behat text matcher in order to allow comparison of
localised floats when they are the current ones. Before this change
the matches was using soft/lazy comparison, so '50' and '50.0000'
match. Now, when the comma (for example) is used (and only then),
'50' and '50,000' will also match. This comparison is in use in a
bunch of tests and makes sense to make it localisation-aware.
At grade/report/singleview/classes/local/ui/finalgrade.php
F. Fix a couple of number_format() uses in lesson, because they are
not localised-aware. Switched to format_float(). At mod/lesson/locallib.php
G. Change the quiz_contains_the_following_questions() step to accept
localised maxmark expectations. At mod/quiz/tests/behat/behat_mod_quiz.php
H. Change the quiz generator so it accepts localised gradepass.
At mod/quiz/tests/generator/lib.php
I. Change the edit question form to show proper localised penalties,
previously it was always showing point-decimal ones. Of course,
leaving the values of the select element unmodified (internal floats).
Related, also change a couple of tests to, instead of try to match the
value (always internal floats), match the description (now localised),
so we can test them with different separators. At:
- question/type/ddimageortext/tests/behat/backup_and_restore.feature
- question/type/ddmarker/tests/behat/backup_and_restore.feature
- question/type/edit_question_form.php
