The comments should appear above everything else when expanded, and expanding/collapsing comments
should not affect the position of anything else in the page.
All credit goes to Damyon Wiese.
Significant string changes:
* moodleorghubname,core_admin and
sitemustberegistered,message_airnotifier - 'Moodle.net' changed to
'Moodle'
* registration_help,core_admin and registermoochtips,core_hub - removed
erroneous 'access to Moodle.net our course sharing platform'
* trackingtype_help,mod_forum and formnotavailable,core_grading and
showgrades_help,core and rolewarning_help,core_rating -
'Administration block' changed to 'Actions menu or admin block',
'navigation block' changed to 'navigation drawer or block'
Use relatively positioned elements, not absolutely positioned to prevent
elements being visible when they are scrolled outside the containing drawing region.
Properly display the list of comments, but limiting their size (use title to indicate the full comments).
When there are too many comments, show a scrollbar in the menu.
Since error suppression was removed with the call to unlink() to make
sure that there are no previous test image files before testing for the
gs path, make sure that it exists first before deleting to prevent it
from throwing any errors.
In the same page it is normal (expected) to have multiple links to different annotated pdfs.
In the grading page, we also abort pending ajax progress when the current user is changed.
3.7 (min PHP 7.1) requires 3.2 (first version supporting PHP 7.1)
This just deletes all the upgrade steps previous to 3.2.0. Some
small adjustments, like adding missing MOODLE_INTERNAL or tweaking
globals can also be applied when needed.
Also includes an upgrade step to prevent upgrading from any
version < 2016120500 (v3.2.0) as anti-cheating measure.
Next commit will get rid of/deprecate all the upgradelib functions
not used anymore in codebase. (note there isn't any this time).
Basically we should produce a combined PDF from all the files that it was possible to convert.
If any one submission input file fails conversion, it should just be omitted in the result.
This commit reviews all continue uses in core happening within a
loop / switch / case hierarchy. This does not cover:
- Changes to libraries. Will be handled in another issue / commit.
- Uses out from loops, will be reviewed by other commit.
The policy followed has been:
- When possible, take rid of the continue.
- When clearly the intention was to jump to next element in loop
change to continue 2
- When it was not clear, keep old behavior switching to break, no
matter how weird the behavior may be.
If javascript is disabled, we don't need to open the menus at all. If it is enabled
we should use the custom step where possible.
In some tests (user profile) we have to use link_or_button because
the element that opens the menu will be a link or a button in different themes.
Identical submissions do not require individual conversions from the document converter. Text passing through
format_text cannot be trusted and is likely to be unique each time, even for the same text.
Without this, we have no coverage of the convert_submissions task. This test
validates it both works normally, and that it also skips queued items that have
exceeded the conversion attempt limit introduced in this improvement.
Without this, its possible to get a document in the editpdf conversion queue
that keeps failing - and in some cases completely crashing the PHP script
despite exception handling - which ends up blocking the processing of the queue
entirely.
This change allows for a configurable number of attempts the conversion
task will perform before removing the item from the queue.
