These methods can be called via UI, and would throw confusing exceptions
if a user entered "unsafe" characters in a search input (e.g. "<").
Defer cleaning of supplied text to inside the methods.
- Introduce core_course_category::get_nearest_editable_subcategory()
- This function will return the first creatable/manageable category
for current user
- With this new function, we can fix the issue that the users with
course management or creation permision at category level cannot see
the manage menu on My courses page
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:
- When belonging to other components and being valid api:
- analytics related tests have been moved to tests/analytics subdir.
- backup & restore related tests have been moved to tests/backup subdir.
- events related tests have been moved to tests/event subdir.
- privacy related tests have been moved to tests/privacy.
- task related tests have been moved to tests/task subdir.
- Some simple renames, not including the component part anymore (not
needed now that they are namespaced):
- some xxxlib_test.php have been renamed lib_test.php
(when they where testing the corresponding lib.php).
- cache stores tests have been all renamed store_test, originally
each one had its own name (file_test, apcu_test, redis_test...)
- assign feedback tests have been all renamed feedback_test, originally
each one had its own name (file_test, editpdf_test...)
Test data providers are executed before `setUpBeforeClass`, so any
library constants used by the providers must already be present.
Reverts part of the change in 691c5b83.
Course formats may want to preserve the existing section information,
but either change the wrapper (.section .course-section-header), or
prepend and append additional content to it.
Prior to this change, the only way to do this was by copying the entire
content of the template.
This change moves the content of the .course-section-header to a
separate template.
This means that a course format can replace the .section
.course-section-header wrapper whilst retaining its content by
overriding the content/section template and including the
content/section/content template. For example:
```
<li id="section-{{num}}"{{!
}} class="section course-section main clearfix{{!
}}{{#onlysummary}} section-summary{{/onlysummary}}{{!
}}{{#ishidden}} hidden{{/ishidden}}{{!
}}{{#iscurrent}} current{{/iscurrent}}{{!
}}{{#isstealth}} orphaned{{/isstealth}}{{!
}}"
data-sectionid="{{num}}"
data-sectionreturnid="{{sectionreturnid}}"
data-for="section"
data-id="{{id}}"
data-number="{{num}}"{{!
}}>
<!--
Add a custom div to the existing wrapper, without replacing the
entire content of the section/content.
-->
<div class="my-custom-content">
<!--
The upstream content is here:
-->
<div class="course-section-header d-flex"
data-for="section_title"
data-id="{{id}}"
data-number="{{num}}"
>
{{$ core_courseformat/local/content/cm/section/content }}
{{> core_courseformat/local/content/cm/section/content }}
{{/ core_courseformat/local/content/cm/section/content }}
</div>
</div>
</li>
```
It also means that a course format can append additional information to
this wrapper, for example:
```
{{< core_courseformat/local/content/section }}
{{$ core_courseformat/local/content/cm/section/content }}
<div class="some-custom-class">
<!--
Some custom content appended _before_ the course section
content but within the wrapper
-->
</div>
{{> core_courseformat/local/content/cm/section/content }}
<div class="some-custom-class">
<!--
Some custom content appended _after_ the course section
content but within the wrapper
-->
</div>
{{/ core_courseformat/local/content/cm/section/content }}
{{/ core_courseformat/local/content/section }}
```
Course formats may want to preserve the existing activity information,
but either change the wrapper (.activity-item), or prepend and append
additional content to it.
Prior to this change, the only way to do this was by copying the entire
content of the template.
This change moves the content of the activity-item to a separate
template.
This means that a course format can replace the activity-item wrapper
whilst retaining its content by overriding the cm template and including
the cm/activity template. For example:
```
<div class="my-custom-activity-item {{!
}}{{#modstealth}}hiddenactivity{{/modstealth}}{{!
}}{{#modhiddenfromstudents}}hiddenactivity{{/modhiddenfromstudents}}{{!
}}{{#modinline}}activityinline{{/modinline}}" data-activityname="{{activityname}}">
{{#moveicon}} {{{moveicon}}} {{/moveicon}}
{{$ core_courseformat/local/content/cm/activity }}
{{> core_courseformat/local/content/cm/activity }}
{{/ core_courseformat/local/content/cm/activity }}
</div>
```
It also means that a course format can append additional information to
this wrapper, for example:
```
{{< core_courseformat/local/content/cm }}
{{$ core_courseformat/local/content/cm/activity }}
{{> core_courseformat/local/content/cm/activity }}
{{#cmmeta}}
<div class="ct-activity-meta-container">
{{{cmmeta}}}
</div>
{{/cmmeta}}
{{/ core_courseformat/local/content/cm/activity }}
{{/ core_courseformat/local/content/cm }}
```
Including in this commit:
- Modify the UI to make the section dropzone more visible
- Prevent the direct image dragging in Chrome, Safari by improving the check
For legacy reasons, the course renderings uses a format setting to know
if the page is multiple sections per page or a single section per page.
This format specific dependency is not solved using a get_course_display
format method any plugin can extend.
For the three unit tests that are going to be modified in future
commit, I first changed them to use a namespace and class name
matching filename, as per current standard.
Moodle announced that support for IE would be dropped back in August
2020 with Moodle 3.9 but not active steps were taken at that time. That
decision was made in MDLSITE-6109 and this particular step was meant to
be taken in Moodle 3.10.
This is the first step taken to actively drop support for IE.
This commit also bumps the browser support pattern from 0.25% to 0.3%.
The percentage here includes any browser where at least this percentage
of users worldwide may be using a browser. In this case it causes
support for Android 4.3-4.4 to be dropped, which relate to Android
KitKat (released 2013).
This combination of changes means that all of the supported browsers in
our compatibility list support modern features including async,
for...of, classes, native Promises, and more which has a huge impact on
the ease of debugging code, and drastically reduces the minified file
size because a number of native Polyfills included by Babel are no
longer included.
Unfortunately the babel minify-mangle plugin seems to be abandoned and
in certain circumstances can be very buggy. The only safe options are to
disable it, or to switch to a different minification library.
Not minifying our javascript is not ideal, so this commit updates the
javascript tasks to use a rollup, combined with babel, and terser.
Babel still converts code from ES/UMD/AMD to AMD modules with the
relevant browser support, whilst terser minifies the code.
The rollup bundler handles tracking and creation of sourcemaps, and
supports better parallelisation of the tasks.
Since the upgrade to Node LTS/Gallium requires an upgrade to @babel/core
and eslint, which change the built files anyway, this seems like the
ideal time to make this change.
