From 1e00687b9be4ef4af3e382ac3c39239156b3131b Mon Sep 17 00:00:00 2001 From: "Eloy Lafuente (stronk7)" Date: Tue, 30 Apr 2024 20:28:02 +0200 Subject: [PATCH] Rename as many as possible "master" occurrences to "main" - All those making reference to the master branch. - All those, part of a URL (usually git repository) also renamed. We have kept apart a few corresponding to: - Other "master" meanings, unrelated with the branches. - Some old release notes from 2.x versions. - general/development/tools/mdk.md (not sure what's changed there) - general/community/plugincontribution/master2main.md, because it explains exactly the move from master to main. --- docs/apis/_files/upgrade-txt.mdx | 16 ++--- docs/apis/core/customfields/index.md | 2 +- docs/apis/core/htmlwriter/index.md | 2 +- docs/apis/core/reportbuilder/index.md | 36 +++++------ docs/apis/plugintypes/assign/feedback.md | 2 +- docs/apis/plugintypes/assign/submission.md | 2 +- docs/apis/plugintypes/communication/index.md | 2 +- .../plugintypes/qtype/newquestiondefaults.md | 6 +- docs/apis/plugintypes/tiny/testing.md | 4 +- docs/apis/subsystems/admin/index.md | 2 +- docs/apis/subsystems/analytics/index.md | 2 +- docs/apis/subsystems/check/index.md | 2 +- .../subsystems/external/writing-a-service.md | 2 +- docs/apis/subsystems/form/index.md | 4 +- docs/apis/subsystems/form/usage/index.md | 4 +- docs/apis/subsystems/group/index.md | 2 +- docs/apis/subsystems/muc/index.md | 4 +- docs/apis/subsystems/output/inplace.md | 4 +- docs/apis/subsystems/task/index.md | 2 +- docs/guides/git/index.md | 64 +++++++++---------- docs/guides/upgrade/index.md | 6 +- .../plugins-development-guide/index.md | 4 +- general/app/development/scripts/gulp-push.md | 8 +-- .../app/development/setup/app-in-browser.md | 2 +- general/app/development/setup/index.md | 2 +- general/development/policies/backporting.md | 2 +- .../development/policies/codingstyle/index.md | 8 +-- .../development/policies/deprecation/index.md | 6 +- general/development/process.md | 4 +- .../development/process/integration/index.md | 28 ++++---- .../development/process/peer-review/index.md | 2 +- .../process/security/penetration-testing.md | 2 +- .../process/testing/integrated-issues.md | 2 +- general/development/process/testing/qa.md | 2 +- general/development/process/triage.md | 2 +- general/development/tools/behat/writing.md | 2 +- general/development/tools/cibot.md | 4 +- general/development/tools/composer.md | 2 +- general/documentation/contributing.md | 2 +- general/documentation/structure.md | 2 +- general/projects/api/amos.md | 2 +- general/projects/api/string-deprecation.md | 8 +-- general/releases/2.2.md | 2 +- versioned_docs/version-4.1/apis.md | 8 +-- .../version-4.1/apis/_files/upgrade-txt.mdx | 16 ++--- .../version-4.1/apis/core/htmlwriter/index.md | 2 +- .../apis/plugintypes/assign/feedback.md | 2 +- .../apis/plugintypes/assign/submission.md | 2 +- .../apis/plugintypes/tiny/testing.md | 4 +- .../apis/subsystems/admin/index.md | 2 +- .../apis/subsystems/analytics/index.md | 2 +- .../apis/subsystems/check/index.md | 2 +- .../subsystems/external/writing-a-service.md | 2 +- .../version-4.1/apis/subsystems/form/index.md | 4 +- .../version-4.1/apis/subsystems/form/usage.md | 4 +- .../apis/subsystems/group/index.md | 2 +- versioned_docs/version-4.1/devupdate.md | 4 +- .../version-4.1/guides/upgrade/index.md | 6 +- versioned_docs/version-4.2/apis.md | 8 +-- .../version-4.2/apis/_files/upgrade-txt.mdx | 16 ++--- .../version-4.2/apis/core/htmlwriter/index.md | 2 +- .../apis/plugintypes/assign/feedback.md | 2 +- .../apis/plugintypes/assign/submission.md | 2 +- .../apis/plugintypes/tiny/testing.md | 4 +- .../apis/subsystems/admin/index.md | 2 +- .../apis/subsystems/analytics/index.md | 2 +- .../apis/subsystems/check/index.md | 2 +- .../subsystems/external/writing-a-service.md | 2 +- .../version-4.2/apis/subsystems/form/index.md | 4 +- .../apis/subsystems/form/usage/index.md | 4 +- .../apis/subsystems/group/index.md | 2 +- .../version-4.2/apis/subsystems/task/index.md | 4 +- versioned_docs/version-4.2/devupdate.md | 2 +- .../version-4.2/guides/git/index.md | 64 +++++++++---------- .../version-4.2/guides/upgrade/index.md | 6 +- versioned_docs/version-4.3/apis.md | 2 +- .../version-4.3/apis/_files/upgrade-txt.mdx | 16 ++--- .../apis/core/customfields/index.md | 2 +- .../version-4.3/apis/core/htmlwriter/index.md | 2 +- .../apis/core/reportbuilder/index.md | 36 +++++------ .../apis/plugintypes/assign/feedback.md | 2 +- .../apis/plugintypes/assign/submission.md | 2 +- .../apis/plugintypes/communication/index.md | 2 +- .../apis/plugintypes/tiny/testing.md | 4 +- .../apis/subsystems/admin/index.md | 2 +- .../apis/subsystems/analytics/index.md | 2 +- .../apis/subsystems/check/index.md | 2 +- .../subsystems/external/writing-a-service.md | 2 +- .../version-4.3/apis/subsystems/form/index.md | 4 +- .../apis/subsystems/form/usage/index.md | 4 +- .../apis/subsystems/group/index.md | 2 +- .../apis/subsystems/output/inplace.md | 4 +- .../version-4.3/apis/subsystems/task/index.md | 2 +- .../version-4.3/guides/git/index.md | 64 +++++++++---------- .../version-4.3/guides/upgrade/index.md | 6 +- 95 files changed, 310 insertions(+), 310 deletions(-) diff --git a/docs/apis/_files/upgrade-txt.mdx b/docs/apis/_files/upgrade-txt.mdx index 5397e05ba0..a29d8cd37f 100644 --- a/docs/apis/_files/upgrade-txt.mdx +++ b/docs/apis/_files/upgrade-txt.mdx @@ -1,20 +1,20 @@ Each component and subsystem may make use of an `upgrade.txt` file in the top level folder. A section title is used to identify the Moodle version where the change was introduced, and significant changes for that version relating to that component or subsystem are noted. -For example, given an API change is applied for the upcoming Moodle version 4.1 which is still in the **master** branch (4.1dev), the version number on the `upgrade.txt`'s section title will be set to **4.1**. +For example, given an API change is applied for the upcoming Moodle version 4.1 which is still in the **main** branch (4.1dev), the version number on the `upgrade.txt`'s section title will be set to **4.1**. -```txt title="Example 1: Change applied to the master branch" +```txt title="Example 1: Change applied to the main branch" == 4.1 == An API change to empower educators! ``` #### Changes applied to multiple branches -When changes are integrated to multiple branches, for example a stable version and the master branch, then the relevant versions used to describe the change in the `upgrade.txt` file should be the next version to be released _for each branch_. The **master** branch should always use the next major version. +When changes are integrated to multiple branches, for example a stable version and the main branch, then the relevant versions used to describe the change in the `upgrade.txt` file should be the next version to be released _for each branch_. The **main** branch should always use the next major version. -For example, if a change is applied to the **MOODLE_400_STABLE** during the development of Moodle 4.0.2, and the **master** branch during the development of Moodle 4.1, then the relevant versions will be **4.0.2** and **4.1**, respectively. The section title for the **master** branch will be the same as the one in Example 1. The section title for the **MOODLE_400_STABLE** branch will indicate the next upcoming minor version (4.0.2 in this case): +For example, if a change is applied to the **MOODLE_400_STABLE** during the development of Moodle 4.0.2, and the **main** branch during the development of Moodle 4.1, then the relevant versions will be **4.0.2** and **4.1**, respectively. The section title for the **main** branch will be the same as the one in Example 1. The section title for the **MOODLE_400_STABLE** branch will indicate the next upcoming minor version (4.0.2 in this case): -```txt title="Example 2: Patch applied to master and MOODLE_400_STABLE" +```txt title="Example 2: Patch applied to main and MOODLE_400_STABLE" == 4.0.2 == An API change to empower educators! ``` @@ -23,7 +23,7 @@ An API change to empower educators! Multiple versions within the section title are **not** allowed. However, developers may note the Moodle versions that the change applies to within the upgrade note text itself. -```txt title="Example 3a: master (4.1dev)" +```txt title="Example 3a: main (4.1dev)" == 4.1 == An API change to empower educators! (This was fixed in 4.1 and 4.0.2) ``` @@ -43,9 +43,9 @@ An API change to empower educators! When Moodle is developing two major versions in parallel, for example Moodle 3.11.0, and Moodle 4.0.0, then the version in the earliest of the major version development branches will be used for both branches. -For example, given we are in a parallel development situation with **MOODLE_311_STABLE** (3.11dev) and **master** (4.0dev), with Moodle 3.11 as the next upcoming major Moodle version. If an API change is applied to **MOODLE_311_STABLE**, the version number on the section title will be **3.11** for both **master** and **MOODLE_400_STABLE** branches. +For example, given we are in a parallel development situation with **MOODLE_311_STABLE** (3.11dev) and **main** (4.0dev), with Moodle 3.11 as the next upcoming major Moodle version. If an API change is applied to **MOODLE_311_STABLE**, the version number on the section title will be **3.11** for both **main** and **MOODLE_400_STABLE** branches. -```txt title="Example 4a: master (4.0dev)" +```txt title="Example 4a: main (4.0dev)" == 3.11 == An API change to empower educators! ``` diff --git a/docs/apis/core/customfields/index.md b/docs/apis/core/customfields/index.md index a9b7ac5cd5..faaac256b6 100644 --- a/docs/apis/core/customfields/index.md +++ b/docs/apis/core/customfields/index.md @@ -25,7 +25,7 @@ New plugin type `customfield` was also added as part of the Custom fields API. A ## How to use custom fields -Component/plugin that uses custom fields must define a **handler class** for each area and a **configuration page**. Handler class must be called `/customfield/_handler` and be placed in autoloaded location `/classes/customfield/_handler.php`. This class must extend **\core_customfield\handler** . Configuration page may be located anywhere. For course custom fields configuration the admin settings page is used [/course/customfield.php](https://github.com/moodle/moodle/blob/master/course/customfield.php). If the area uses `itemid` this page should take `itemid` as a parameter. +Component/plugin that uses custom fields must define a **handler class** for each area and a **configuration page**. Handler class must be called `/customfield/_handler` and be placed in autoloaded location `/classes/customfield/_handler.php`. This class must extend **\core_customfield\handler** . Configuration page may be located anywhere. For course custom fields configuration the admin settings page is used [/course/customfield.php](https://github.com/moodle/moodle/blob/main/course/customfield.php). If the area uses `itemid` this page should take `itemid` as a parameter. Handler has protected constructor, to get a handler call `create()` method. Some areas may choose to return a singleton here: diff --git a/docs/apis/core/htmlwriter/index.md b/docs/apis/core/htmlwriter/index.md index 2a1188580f..4740676734 100644 --- a/docs/apis/core/htmlwriter/index.md +++ b/docs/apis/core/htmlwriter/index.md @@ -16,7 +16,7 @@ Please consider using [templates](../../../guides/templates/index.md) as an alte :::note -There is no documentation for most of this class. Please read [HTML Writer Class Reference](https://phpdoc.moodledev.io/master/d4/d78/classhtml__writer.html) for further information. +There is no documentation for most of this class. Please read [HTML Writer Class Reference](https://phpdoc.moodledev.io/main/d4/d78/classhtml__writer.html) for further information. ::: diff --git a/docs/apis/core/reportbuilder/index.md b/docs/apis/core/reportbuilder/index.md index e7aa25b789..a9117b1795 100644 --- a/docs/apis/core/reportbuilder/index.md +++ b/docs/apis/core/reportbuilder/index.md @@ -32,7 +32,7 @@ Column instances define the data captured/displayed within a report column typic #### Creating columns -To create a new column, just create a new instance of [`reportbuilder/classes/local/report/column.php`](https://github.com/moodle/moodle/blob/master/reportbuilder/classes/local/report/column.php) class with: +To create a new column, just create a new instance of [`reportbuilder/classes/local/report/column.php`](https://github.com/moodle/moodle/blob/main/reportbuilder/classes/local/report/column.php) class with: ```php * string $name @@ -80,20 +80,20 @@ Filters & columns are entirely separate concepts in the report, and each can be #### Filter types -- **Text** ([reportbuilder/classes/local/filters/text.php](https://github.com/moodle/moodle/blob/master/reportbuilder/classes/local/filters/text.php)) -- **Date** ([reportbuilder/classes/local/filters/date.php](https://github.com/moodle/moodle/blob/master/reportbuilder/classes/local/filters/date.php)) -- **Number** ([reportbuilder/classes/local/filters/number.php](https://github.com/moodle/moodle/blob/master/reportbuilder/classes/local/filters/number.php)) -- **Boolean Select** ([reportbuilder/classes/local/filters/boolean_select.php](https://github.com/moodle/moodle/blob/master/reportbuilder/classes/local/filters/boolean_select.php)) -- **Select** ([reportbuilder/classes/local/filters/select.php](https://github.com/moodle/moodle/blob/master/reportbuilder/classes/local/filters/select.php)) -- **Course selector** ([reportbuilder/classes/local/filters/course_selector.php](https://github.com/moodle/moodle/blob/master/reportbuilder/classes/local/filters/course_selector.php)) -- **Duration** ([reportbuilder/classes/local/filters/duration.php](https://github.com/moodle/moodle/blob/master/reportbuilder/classes/local/filters/duration.php)) -- **Tags** ([reportbuilder/classes/local/filters/tags.php](https://github.com/moodle/moodle/blob/master/reportbuilder/classes/local/filters/tags.php)) -- **Autocomplete** ([reportbuilder/classes/local/filters/autocomplete.php](https://github.com/moodle/moodle/blob/master/reportbuilder/classes/local/filters/autocomplete.php)) -- **Category** ([reportbuilder/classes/local/filters/category.php](https://github.com/moodle/moodle/blob/master/reportbuilder/classes/local/filters/category.php)) +- **Text** ([reportbuilder/classes/local/filters/text.php](https://github.com/moodle/moodle/blob/main/reportbuilder/classes/local/filters/text.php)) +- **Date** ([reportbuilder/classes/local/filters/date.php](https://github.com/moodle/moodle/blob/main/reportbuilder/classes/local/filters/date.php)) +- **Number** ([reportbuilder/classes/local/filters/number.php](https://github.com/moodle/moodle/blob/main/reportbuilder/classes/local/filters/number.php)) +- **Boolean Select** ([reportbuilder/classes/local/filters/boolean_select.php](https://github.com/moodle/moodle/blob/main/reportbuilder/classes/local/filters/boolean_select.php)) +- **Select** ([reportbuilder/classes/local/filters/select.php](https://github.com/moodle/moodle/blob/main/reportbuilder/classes/local/filters/select.php)) +- **Course selector** ([reportbuilder/classes/local/filters/course_selector.php](https://github.com/moodle/moodle/blob/main/reportbuilder/classes/local/filters/course_selector.php)) +- **Duration** ([reportbuilder/classes/local/filters/duration.php](https://github.com/moodle/moodle/blob/main/reportbuilder/classes/local/filters/duration.php)) +- **Tags** ([reportbuilder/classes/local/filters/tags.php](https://github.com/moodle/moodle/blob/main/reportbuilder/classes/local/filters/tags.php)) +- **Autocomplete** ([reportbuilder/classes/local/filters/autocomplete.php](https://github.com/moodle/moodle/blob/main/reportbuilder/classes/local/filters/autocomplete.php)) +- **Category** ([reportbuilder/classes/local/filters/category.php](https://github.com/moodle/moodle/blob/main/reportbuilder/classes/local/filters/category.php)) #### Creating filters -To create a new filter, just create a new instance of **[reportbuilder/classes/local/report/filter.php](https://github.com/moodle/moodle/blob/master/reportbuilder/classes/local/report/filter.php)** class with: +To create a new filter, just create a new instance of **[reportbuilder/classes/local/report/filter.php](https://github.com/moodle/moodle/blob/main/reportbuilder/classes/local/report/filter.php)** class with: ```php * string $filterclass @@ -125,7 +125,7 @@ All report elements can be defined within the reports themselves - but entities #### Create an entity -To create an entity, the new entity class must extend **[reportbuilder/classes/local/entities/base.php](https://github.com/moodle/moodle/blob/master/reportbuilder/classes/local/entities/base.php)** class and must include these methods: +To create an entity, the new entity class must extend **[reportbuilder/classes/local/entities/base.php](https://github.com/moodle/moodle/blob/main/reportbuilder/classes/local/entities/base.php)** class and must include these methods: ```php get_default_table_aliases() @@ -149,8 +149,8 @@ This is where we **add** the entity columns and filters. Check out these two entities as an example to start building reports: -- **User entity**: [reportbuilder/classes/local/entities/user.php](https://github.com/moodle/moodle/blob/master/reportbuilder/classes/local/entities/user.php) -- **Course entity**: [reportbuilder/classes/local/entities/course.php](https://github.com/moodle/moodle/blob/master/reportbuilder/classes/local/entities/course.php) +- **User entity**: [reportbuilder/classes/local/entities/user.php](https://github.com/moodle/moodle/blob/main/reportbuilder/classes/local/entities/user.php) +- **Course entity**: [reportbuilder/classes/local/entities/course.php](https://github.com/moodle/moodle/blob/main/reportbuilder/classes/local/entities/course.php) ### Actions @@ -174,7 +174,7 @@ System reports are a consistent way of providing reporting data, with paging, fi #### Create a new system report using entities -To create a new system report just create a new class extending [reportbuilder/classes/system_report.php](https://github.com/moodle/moodle/blob/master/reportbuilder/classes/system_report.php). +To create a new system report just create a new class extending [reportbuilder/classes/system_report.php](https://github.com/moodle/moodle/blob/main/reportbuilder/classes/system_report.php). The first method that we need is ***initialise()*** : @@ -285,5 +285,5 @@ $this->set_initial_sort_column('task_log:starttime', SORT_DESC); Check out these two system reports as an example: -- **Task logs**: [`admin/classes/reportbuilder/local/systemreports/task_logs.php`](https://github.com/moodle/moodle/blob/master/admin/classes/reportbuilder/local/systemreports/task_logs.php) -- **Config changes**: [`report/configlog/classes/reportbuilder/local/systemreports/config_changes.php`](https://github.com/moodle/moodle/blob/master/report/configlog/classes/reportbuilder/local/systemreports/config_changes.php) +- **Task logs**: [`admin/classes/reportbuilder/local/systemreports/task_logs.php`](https://github.com/moodle/moodle/blob/main/admin/classes/reportbuilder/local/systemreports/task_logs.php) +- **Config changes**: [`report/configlog/classes/reportbuilder/local/systemreports/config_changes.php`](https://github.com/moodle/moodle/blob/main/report/configlog/classes/reportbuilder/local/systemreports/config_changes.php) diff --git a/docs/apis/plugintypes/assign/feedback.md b/docs/apis/plugintypes/assign/feedback.md index 994795d32c..8b050a157a 100644 --- a/docs/apis/plugintypes/assign/feedback.md +++ b/docs/apis/plugintypes/assign/feedback.md @@ -19,7 +19,7 @@ An assignment feedback plugin can do many things including providing feedback to :::tip -For a good reference implementation, see the [file](https://github.com/moodle/moodle/tree/master/mod/assign/feedback/file) feedback plugin included with core because it uses most of the features of feedback plugins. +For a good reference implementation, see the [file](https://github.com/moodle/moodle/tree/main/mod/assign/feedback/file) feedback plugin included with core because it uses most of the features of feedback plugins. ::: diff --git a/docs/apis/plugintypes/assign/submission.md b/docs/apis/plugintypes/assign/submission.md index 4e69be0c40..d33be4991b 100644 --- a/docs/apis/plugintypes/assign/submission.md +++ b/docs/apis/plugintypes/assign/submission.md @@ -19,7 +19,7 @@ An assignment submission plugin is used to display custom form fields to a stude :::tip -For a good reference implementation, see the [onlinetext](https://github.com/moodle/moodle/tree/master/mod/assign/submission/onlinetext) submission plugin included with core because it uses most of the features of submission plugins. +For a good reference implementation, see the [onlinetext](https://github.com/moodle/moodle/tree/main/mod/assign/submission/onlinetext) submission plugin included with core because it uses most of the features of submission plugins. ::: diff --git a/docs/apis/plugintypes/communication/index.md b/docs/apis/plugintypes/communication/index.md index b97203586b..80b89180dd 100644 --- a/docs/apis/plugintypes/communication/index.md +++ b/docs/apis/plugintypes/communication/index.md @@ -153,6 +153,6 @@ All the necessary code to synchronise the room members should live here. :::info -For a real plugin example, please look at the [Matrix plugin](https://github.com/moodle/moodle/tree/master/communication/provider/matrix). +For a real plugin example, please look at the [Matrix plugin](https://github.com/moodle/moodle/tree/main/communication/provider/matrix). ::: diff --git a/docs/apis/plugintypes/qtype/newquestiondefaults.md b/docs/apis/plugintypes/qtype/newquestiondefaults.md index 011a2c1818..58cdb0b881 100644 --- a/docs/apis/plugintypes/qtype/newquestiondefaults.md +++ b/docs/apis/plugintypes/qtype/newquestiondefaults.md @@ -53,7 +53,7 @@ All the settings save here should match the ones fetched by `get_default_value` Because this feature works using user preferences, you need to declare that in your privacy provider. -This is boring but necessary. Easiest way to see what to do is to [copy another question type](https://github.com/moodle/moodle/blob/master/question/type/match/classes/privacy/provider.php). +This is boring but necessary. Easiest way to see what to do is to [copy another question type](https://github.com/moodle/moodle/blob/main/question/type/match/classes/privacy/provider.php). Note, it is necessary for your provider to declare the ones saved by core. (I suppose, ideally, someone would make a helpful base class, or trait, to make it easier to implement this.) @@ -61,7 +61,7 @@ Note, it is necessary for your provider to declare the ones saved by core. (I su Always a good idea. You are likely to need: -1. [Unit tests for the privacy provider](https://github.com/moodle/moodle/blob/master/question/type/match/tests/privacy/provider_test.php). -2. Behat test to show that the saved settings are re-used. Many question types have [a `behat/add.feature` file where it is easy to add coverage for this](https://github.com/moodle/moodle/blob/master/question/type/match/tests/behat/add.feature). +1. [Unit tests for the privacy provider](https://github.com/moodle/moodle/blob/main/question/type/match/tests/privacy/provider_test.php). +2. Behat test to show that the saved settings are re-used. Many question types have [a `behat/add.feature` file where it is easy to add coverage for this](https://github.com/moodle/moodle/blob/main/question/type/match/tests/behat/add.feature). The links in that list go to examples of how these are implemented in `qtype_match`. diff --git a/docs/apis/plugintypes/tiny/testing.md b/docs/apis/plugintypes/tiny/testing.md index ebea115999..b08ca16a41 100644 --- a/docs/apis/plugintypes/tiny/testing.md +++ b/docs/apis/plugintypes/tiny/testing.md @@ -29,7 +29,7 @@ By using these tags appropriately, Moodle will ensure that TinyMCE is set as the ### Useful steps -A number of useful Behat steps have been defined in [TinyMCE Behat context](https://github.com/moodle/moodle/blob/master/lib/editor/tiny/tests/behat/behat_editor_tiny.php). +A number of useful Behat steps have been defined in [TinyMCE Behat context](https://github.com/moodle/moodle/blob/main/lib/editor/tiny/tests/behat/behat_editor_tiny.php). :::caution Use generic steps where possible @@ -39,7 +39,7 @@ Typically, when interacting with an Editor, you should use the _generic_ step de #### Generic steps to interact with editors -Most of these steps are defined in the [Behat Forms context](https://github.com/moodle/moodle/blob/master/lib/tests/behat/behat_forms.php) and this documentation should not be treated as a complete list, rather an indication of approaches that you may consider taking. +Most of these steps are defined in the [Behat Forms context](https://github.com/moodle/moodle/blob/main/lib/tests/behat/behat_forms.php) and this documentation should not be treated as a complete list, rather an indication of approaches that you may consider taking. ##### Setting content of a field diff --git a/docs/apis/subsystems/admin/index.md b/docs/apis/subsystems/admin/index.md index e1c5bffa45..ca5e03e18c 100644 --- a/docs/apis/subsystems/admin/index.md +++ b/docs/apis/subsystems/admin/index.md @@ -117,7 +117,7 @@ Few things to highlight: ## Individual settings -Let us look at a simple example: [mod/lesson/settings.php](https://github.com/moodle/moodle/blob/master/mod/lesson/settings.php). This is included by admin/settings/plugins.php, which has already created $settings, which is an admin_settingpage that we can add to. The file contains lots of lines that look a bit like: +Let us look at a simple example: [mod/lesson/settings.php](https://github.com/moodle/moodle/blob/main/mod/lesson/settings.php). This is included by admin/settings/plugins.php, which has already created $settings, which is an admin_settingpage that we can add to. The file contains lots of lines that look a bit like: ```php $settings->add(new admin_setting_configtext('mod_lesson/mediawidth', get_string('mediawidth', 'lesson'), diff --git a/docs/apis/subsystems/analytics/index.md b/docs/apis/subsystems/analytics/index.md index 37408390a8..820f4bdf5f 100644 --- a/docs/apis/subsystems/analytics/index.md +++ b/docs/apis/subsystems/analytics/index.md @@ -362,7 +362,7 @@ public function processes_user_data(); /** * SQL JOIN from a sample to users table. * - * More info in [https://github.com/moodle/moodle/blob/master/analytics/classes/local/analyser/base.php core_analytics\local\analyser\base]::join_sample_user + * More info in [https://github.com/moodle/moodle/blob/main/analytics/classes/local/analyser/base.php core_analytics\local\analyser\base]::join_sample_user * * @param string $sampletablealias The alias of the table with a sampleid field that will join with this SQL string * @return string diff --git a/docs/apis/subsystems/check/index.md b/docs/apis/subsystems/check/index.md index 5b2db9943c..12be215c79 100644 --- a/docs/apis/subsystems/check/index.md +++ b/docs/apis/subsystems/check/index.md @@ -215,7 +215,7 @@ class foobar_result extends \core\check\result { For a real example see: -https://github.com/moodle/moodle/blob/master/lib/classes/check/access/riskxss_result.php +https://github.com/moodle/moodle/blob/main/lib/classes/check/access/riskxss_result.php ### Asynchronous checks diff --git a/docs/apis/subsystems/external/writing-a-service.md b/docs/apis/subsystems/external/writing-a-service.md index ecc5795d7c..e4a5cee4ad 100644 --- a/docs/apis/subsystems/external/writing-a-service.md +++ b/docs/apis/subsystems/external/writing-a-service.md @@ -54,7 +54,7 @@ If _any_ group creation fails, the function will throw an exception, and no grou ## Technical specification -- **the core function the external function will call**: `groups_create_group()` from [/group/lib.php](http://github.com/moodle/moodle/tree/master/moodle/group/lib.php). +- **the core function the external function will call**: `groups_create_group()` from [/group/lib.php](http://github.com/moodle/moodle/tree/main/moodle/group/lib.php). - **the parameter types**: a list of object. This object are groups, with `id`/`name`/`courseid`. - **the returned value types**: a list of objects (groups) with their id. - **the user capabilities to check**: `moodle/course:managegroups` diff --git a/docs/apis/subsystems/form/index.md b/docs/apis/subsystems/form/index.md index a446cb3d9b..1df2b9b8e7 100644 --- a/docs/apis/subsystems/form/index.md +++ b/docs/apis/subsystems/form/index.md @@ -209,8 +209,8 @@ $mform->addElement( For a real-life example, see: -- [Custom element definition](https://github.com/moodle/moodle/blob/master/admin/tool/lp/classes/course_competency_rule_form_element.php) -- [Custom element usage](https://github.com/moodle/moodle/blob/master/admin/tool/lp/lib.php#L157-L161) +- [Custom element definition](https://github.com/moodle/moodle/blob/main/admin/tool/lp/classes/course_competency_rule_form_element.php) +- [Custom element usage](https://github.com/moodle/moodle/blob/main/admin/tool/lp/lib.php#L157-L161) ## Commonly used functions diff --git a/docs/apis/subsystems/form/usage/index.md b/docs/apis/subsystems/form/usage/index.md index 8d374eb38b..cb9d4fc80f 100644 --- a/docs/apis/subsystems/form/usage/index.md +++ b/docs/apis/subsystems/form/usage/index.md @@ -16,8 +16,8 @@ Moodle will attempt to provide a more complete tutorial in this documentation wh Some good examples of usage of the Forms API can be found at the following locations: -- [Course edit form - definition](https://github.com/moodle/moodle/blob/master/course/edit_form.php) -- [Course edit form - usage](https://github.com/moodle/moodle/blob/master/course/edit.php) +- [Course edit form - definition](https://github.com/moodle/moodle/blob/main/course/edit_form.php) +- [Course edit form - usage](https://github.com/moodle/moodle/blob/main/course/edit.php) ::: diff --git a/docs/apis/subsystems/group/index.md b/docs/apis/subsystems/group/index.md index 95df14e34b..43f62590ff 100644 --- a/docs/apis/subsystems/group/index.md +++ b/docs/apis/subsystems/group/index.md @@ -74,7 +74,7 @@ The core API functions in `groupslib` such as `groups_get_all_groups()` and `gro ## File locations -The Groups API is currently defined in [lib/grouplib.php](https://github.com/moodle/moodle/blob/master/lib/grouplib.php). This contains global functions which have the `groups_` prefix, for example: `groups_get_group()`. +The Groups API is currently defined in [lib/grouplib.php](https://github.com/moodle/moodle/blob/main/lib/grouplib.php). This contains global functions which have the `groups_` prefix, for example: `groups_get_group()`. ## Examples diff --git a/docs/apis/subsystems/muc/index.md b/docs/apis/subsystems/muc/index.md index 9d42c1508d..244ee390fc 100644 --- a/docs/apis/subsystems/muc/index.md +++ b/docs/apis/subsystems/muc/index.md @@ -280,7 +280,7 @@ One potential benefit of a simple version number strategy if your cache misses a :::info -An example of this strategy in Moodle is the theme versions cache: https://github.com/moodle/moodle/blob/master/lib/outputlib.php#L88-L100 +An example of this strategy in Moodle is the theme versions cache: https://github.com/moodle/moodle/blob/main/lib/outputlib.php#L88-L100 Note this is not actually in MUC but the caching concepts are the same. @@ -309,7 +309,7 @@ It may look like Moodle theme-related caching uses this strategy, but actually i :::info -https://github.com/moodle/moodle/blob/master/lib/datalib.php#L1131-L1145 +https://github.com/moodle/moodle/blob/main/lib/datalib.php#L1131-L1145 It works best with a cache store that supports Least Recently Used garbage collection. ::: diff --git a/docs/apis/subsystems/output/inplace.md b/docs/apis/subsystems/output/inplace.md index ac07b780f4..11a4f4c131 100644 --- a/docs/apis/subsystems/output/inplace.md +++ b/docs/apis/subsystems/output/inplace.md @@ -140,7 +140,7 @@ class inplace_edit_text extends \core\output\inplace_editable { You may choose to set the UI for your inplace editable element to be a string value (default), toggle or dropdown. -Examples of dropdown setup (see also [example by overriding class](https://github.com/moodle/moodle/blob/master/tag/classes/output/tagareacollection.php)): +Examples of dropdown setup (see also [example by overriding class](https://github.com/moodle/moodle/blob/main/tag/classes/output/tagareacollection.php)): ```php $tagcollections = \core_tag_collection::get_collections_menu(true); @@ -163,7 +163,7 @@ $tmpl = new \core\output\inplace_editable( $tmpl->set_type_select($tagcollections); ``` -Example of toggle setup (see also [example by overriding class](https://github.com/moodle/moodle/blob/master/tag/classes/output/tagareaenabled.php)): +Example of toggle setup (see also [example by overriding class](https://github.com/moodle/moodle/blob/main/tag/classes/output/tagareaenabled.php)): ```php $tmpl = new \core\output\inplace_editable( diff --git a/docs/apis/subsystems/task/index.md b/docs/apis/subsystems/task/index.md index a0bd4b09e4..9c2ddb0fee 100644 --- a/docs/apis/subsystems/task/index.md +++ b/docs/apis/subsystems/task/index.md @@ -65,7 +65,7 @@ If you catch an exception, then you become responsible for things that the task For example, it is important to log all the details of the error, so problems can be investigated and fixed. The helper function `mtrace_exception` makes this easier. Also, you need to consider: if something has gone wrong with part of the processing, but other parts succeeded, should the overall state of the task run be success or failure? It will depend on how the task works, but you may need to ensure that the task -ends by throwing an exception if any part failed. There is a an example of all this in the [`\quiz_statistics\task\recalculate`](https://github.com/moodle/moodle/blob/master/mod/quiz/report/statistics/classes/task/recalculate.php). +ends by throwing an exception if any part failed. There is a an example of all this in the [`\quiz_statistics\task\recalculate`](https://github.com/moodle/moodle/blob/main/mod/quiz/report/statistics/classes/task/recalculate.php). ### Caches diff --git a/docs/guides/git/index.md b/docs/guides/git/index.md index 02055af585..e076fcb0ba 100644 --- a/docs/guides/git/index.md +++ b/docs/guides/git/index.md @@ -101,7 +101,7 @@ This command does several jobs for you: - Creates a new folder - Initialises a new local Git repository - Sets your GitHub repository as the remote repository called 'origin' -- Makes a local checkout of the branch 'master' +- Makes a local checkout of the branch 'main' :::tip [MDK](/general/development/tools/mdk) features many commands that aid in the creation and management of your Moodle branches. If you haven't checked it out already, see how MDK can streamline your Moodle development. @@ -109,7 +109,7 @@ This command does several jobs for you: ## Keeping your public repository up-to-date -Your fork at GitHub is not updated automatically. To keep it synced with the upstream Moodle repository, you have to fetch the recent changes from the official moodle.git repository. To avoid conflicts, it is strongly recommended that you never modify the standard Moodle branches. Never commit directly into `master` and `MOODLE_XXX_STABLE` branches, but instead create topic branches to work on. In Git terminology, the `master` branch and `MOODLE_XXX_STABLE` branches should always be fast-forwardable. +Your fork at GitHub is not updated automatically. To keep it synced with the upstream Moodle repository, you have to fetch the recent changes from the official moodle.git repository. To avoid conflicts, it is strongly recommended that you never modify the standard Moodle branches. Never commit directly into `main` and `MOODLE_XXX_STABLE` branches, but instead create topic branches to work on. In Git terminology, the `main` branch and `MOODLE_XXX_STABLE` branches should always be fast-forwardable. ![git-sync-github.png](./_index/git-sync-github.png) @@ -126,13 +126,13 @@ The following commands can be used to keep the your forked Moodle branches at yo ``` #!/bin/bash git fetch upstream -for BRANCH in MOODLE_{19..39}_STABLE MOODLE_{310..311}_STABLE MOODLE_{400..403}_STABLE master; do +for BRANCH in MOODLE_{19..39}_STABLE MOODLE_{310..311}_STABLE MOODLE_{400..403}_STABLE main; do git push origin refs/remotes/upstream/$BRANCH:refs/heads/$BRANCH done ``` :::caution -Never commit directly into `master` and `MOODLE_XXX_STABLE` branches +Never commit directly into `main` and `MOODLE_XXX_STABLE` branches ::: :::tip @@ -173,7 +173,7 @@ git push origin MOODLE_99_STABLE:MOODLE_99_STABLE The above code will create a new copy of the `MOODLE_99_STABLE` branch in your local repository. If you do not need to keep a local copy of the new branch (probably the case), you can remove it from your local repository as follows: ``` -git checkout master +git checkout main git branch -D MOODLE_99_STABLE ``` @@ -183,10 +183,10 @@ git branch -D MOODLE_99_STABLE As mentioned earlier, you never work on standard Moodle branches directly. Every time you are going to edit something, switch to a local branch. Fork the local branch off Moodle's standard branch that you think it should be eventually merged to. -For example, if you are working on a patch for **4.1**, fork the branch off `MOODLE_401_STABLE`. Patches for the next [major version](https://docs.moodle.org/dev/Moodle_versions) should be based on the `master` branch. +For example, if you are working on a patch for **4.1**, fork the branch off `MOODLE_401_STABLE`. Patches for the next [major version](https://docs.moodle.org/dev/Moodle_versions) should be based on the `main` branch. ``` -git checkout -b MDL-xxxxx-master_brief_name origin/master +git checkout -b MDL-xxxxx-main_brief_name origin/main ``` If you forget to specify the branch you want to fork from, the new branch will be based on the currently checked-out branch. It is recommended you always specify this. @@ -218,7 +218,7 @@ git log Your local branch changes may consist of several commits. Once you are happy with it, and you have checked it against Moodle's [Coding styles](/general/development/policies/codingstyle), publish your changes by pushing to your public repository. ``` -git push origin MDL-xxxxx-master_brief_name +git push origin MDL-xxxxx-main_brief_name ``` Now your branch is published and you can ask Moodle core developers to review it and eventually integrate it into Moodle's main repository. @@ -231,10 +231,10 @@ There are a couple of ways this can be achieved. #### Reset all changes and commit again -The following command will preserve your changes, but all commits on top of `master` branch will be gone and become **unstaged** and ready to be added and committed again. +The following command will preserve your changes, but all commits on top of `main` branch will be gone and become **unstaged** and ready to be added and committed again. ``` -git reset --mixed origin/master +git reset --mixed origin/main ``` #### Rebase your changes @@ -247,12 +247,12 @@ Rebase your branch using the following command: git rebase --interactive ``` -Whichever option you chose, you have "rewritten history". If you had already pushed your branch to your remote repository, you may encounter issues when trying to push the updated branch. If you try `git push MDL-xxxxx-master_brief_name` you will get an error message suggesting you to `force push`. +Whichever option you chose, you have "rewritten history". If you had already pushed your branch to your remote repository, you may encounter issues when trying to push the updated branch. If you try `git push MDL-xxxxx-main_brief_name` you will get an error message suggesting you to `force push`. To force push the changed commits use: ``` -git push -f origin MDL-xxxxx-master_brief_name +git push -f origin MDL-xxxxx-main_brief_name ``` If an error occurs because you are still using the git protocol (read only), use this command: @@ -273,16 +273,16 @@ After some time contributing to Moodle, you will have accumulated many branches, ``` git fetch upstream -git branch --merged upstream/master +git branch --merged upstream/main git branch --merged upstream/MOODLE_XXX_STABLE ``` #### Pruning local branches -The `git fetch upstream` command fetches the changes from your upstream repository (remember that `git fetch` does not modify your working directory, so it is safe to run it whenever). The `git branch --merged` commands displays all branches that are merged into the Moodle's upstream `master` branch and `MOODLE_XXX_STABLE` branch, respectively. To delete these local branches, use: +The `git fetch upstream` command fetches the changes from your upstream repository (remember that `git fetch` does not modify your working directory, so it is safe to run it whenever). The `git branch --merged` commands displays all branches that are merged into the Moodle's upstream `main` branch and `MOODLE_XXX_STABLE` branch, respectively. To delete these local branches, use: ``` -git branch -d MDL-xxxxx-master_accepted_branch +git branch -d MDL-xxxxx-main_accepted_branch ``` #### Pruning remote branches @@ -292,7 +292,7 @@ A similar approach can be used to check the branches published at your origin re ``` git fetch origin git fetch upstream -git branch -r --merged upstream/master +git branch -r --merged upstream/main git branch -r --merged upstream/MOODLE_XXX_STABLE ``` @@ -301,7 +301,7 @@ The `git fetch upstream` command makes sure that you have all your branches from To delete a branch on your origin repository, use: ``` -git push origin :MDL-xxxxx-master_branch_to_delete +git push origin :MDL-xxxxx-main_branch_to_delete ``` This syntax may look unfamiliar, however it is pretty logical. The general syntax of the `git push` command is: @@ -359,7 +359,7 @@ Once you have acquired the code and are ready to review it, reference Moodle's [ Rebasing is a process when you cut off the branch from its current start point and transplant it to another point. Let us assume the following history exists: ```mermaid -%%{init: { 'gitGraph': {'mainBranchName': 'master', 'mainBranchOrder': 2 }} }%% +%%{init: { 'gitGraph': {'mainBranchName': 'main', 'mainBranchOrder': 2 }} }%% gitGraph commit id: "D" commit id: "E" @@ -367,20 +367,20 @@ gitGraph commit id: "A" commit id: "B" commit id: "C" - checkout master + checkout main commit id: "F" commit id: "G" ``` -The result of the command `git rebase master topic` would transplant the `topic` branch on top of the `master` branch and look like this: +The result of the command `git rebase main topic` would transplant the `topic` branch on top of the `main` branch and look like this: ```mermaid -%%{init: { 'gitGraph': {'mainBranchName': 'master', 'mainBranchOrder': 2 }} }%% +%%{init: { 'gitGraph': {'mainBranchName': 'main', 'mainBranchOrder': 2 }} }%% gitGraph commit id: "D" commit id: "E" - checkout master + checkout main commit id: "F" commit id: "G" branch topic order: 1 @@ -393,10 +393,10 @@ gitGraph You may be asked to rebase your branch if the submitted branch was based on an outdated commit. Consider this example: -On Tuesday, we create a new topic branch, forked off the upstream `master` branch. On Wednesday, the upstream `master` branch is updated with all the changes from the last integration cycle. To make our branch easier to integrate, we rebase our branch against the newly updated `master` branch. +On Tuesday, we create a new topic branch, forked off the upstream `main` branch. On Wednesday, the upstream `main` branch is updated with all the changes from the last integration cycle. To make our branch easier to integrate, we rebase our branch against the newly updated `main` branch. ``` -git rebase master MDL-xxxxx-master_topic_branch +git rebase main MDL-xxxxx-main_topic_branch ``` Note that rebasing effectively rewrites the history of the branch. **Do not rebase the branch if there is a chance that somebody has already forked it and based their own branch on it.** For this reason, many Git tutorials discourage from rebasing any branch that has been published. @@ -419,7 +419,7 @@ git rebase --continue Most bugs are fixed on each stable branch (e.g. `MOODLE_400_STABLE`, `MOODLE_311_STABLE`). If you are working on an fix based on one of these branches, it is possible you will need to prepare a patch for other affected stable branches too. -In Moodle, we separately maintain the stable branches and the current development branch (master). We do not merge stable branches into the master one. Typically, the contributor prepares at least two branches: one with the fix for the affected stable branch(es), and one with the fix for the master branch. +In Moodle, we separately maintain the stable branches and the current development branch (main). We do not merge stable branches into the main one. Typically, the contributor prepares at least two branches: one with the fix for the affected stable branch(es), and one with the fix for the main branch. Let's assume you have a patch prepared, based on `MOODLE_400_STABLE`, called `MDL-xxxxx-400_topic`. It is possible to apply this patch to other stable branches. There are a few ways we could achieve this. @@ -428,18 +428,18 @@ Let's assume you have a patch prepared, based on `MOODLE_400_STABLE`, called `MD Let's assume we have two local Git repositories: 1. `~/public_html/moodle_400` containing a local installation of Moodle 4.0, and -2. `~/public_html/moodle_master` containing a local installation of the most recent development version of Moodle. +2. `~/public_html/moodle_main` containing a local installation of the most recent development version of Moodle. -They both use your public repository at github.com as the origin. You have a branch in `moodle_400` called `MDL-xxxxx-400_topic` that was forked off `MOODLE_400_STABLE`. It contains one commit. Now, you want to apply this commit to a new branch in `moodle_master` called `MDL-xxxxx-master_topic`. +They both use your public repository at github.com as the origin. You have a branch in `moodle_400` called `MDL-xxxxx-400_topic` that was forked off `MOODLE_400_STABLE`. It contains one commit. Now, you want to apply this commit to a new branch in `moodle_main` called `MDL-xxxxx-main_topic`. ``` -cd ~/public_html/moodle_master -git checkout -b MDL-xxxxx-master_topic origin/master +cd ~/public_html/moodle_main +git checkout -b MDL-xxxxx-main_topic origin/main git fetch ../moodle_400 MDL-xxxxx-400_topic git cherry-pick FETCH_HEAD ``` -1. The `git checkout -b MDL-xxxxx-master_topic origin/master` command creates new local branch, forked off `master`. +1. The `git checkout -b MDL-xxxxx-main_topic origin/main` command creates new local branch, forked off `main`. 2. The `git fetch ../moodle_400 MDL-xxxxx-400_topic` command fetches all data needed to apply the topic branch, and sets the pointer to the tip of that branch with `FETCH_HEAD` as a symbolic reference. 3. The `git cherry-pick FETCH_HEAD` command picks the tip of the branch (the top-most commit) and tries to apply it on the current branch. @@ -464,8 +464,8 @@ The `git format-patch -o .patches MOODLE_400_STABLE..MDL-xxxxx-400_topic` comman In this example, we will apply them to another repository. ``` -cd ~/public_html/moodle_master -git checkout -b MDL-xxxxx-master_topic origin/master +cd ~/public_html/moodle_main +git checkout -b MDL-xxxxx-main_topic origin/main git am -3 ../moodle_400/.patches/* ``` diff --git a/docs/guides/upgrade/index.md b/docs/guides/upgrade/index.md index 0c775f79ea..dc809aba03 100644 --- a/docs/guides/upgrade/index.md +++ b/docs/guides/upgrade/index.md @@ -166,11 +166,11 @@ In Moodle core, one of the standard simple rules is not to make any database cha :::warning Advanced -Suppose, in order to fix a bug, you need to make a database change in the Moodle 4.0 stable branch (and the master branch targetting Moodle 4.1). The root of the problem is that people may upgrade their Moodle in three different ways, which +Suppose, in order to fix a bug, you need to make a database change in the Moodle 4.0 stable branch (and the main branch targetting Moodle 4.1). The root of the problem is that people may upgrade their Moodle in three different ways, which - Upgrade from \<=4.0.2 to 4.0.3 - this executes the upgrade script on the 4.0 branch. -- Upgrade from \<=4.0.2 directly to >=4.1 - this executes the upgrade script on the master branch. -- Upgrade from 4.0.3 to >=4.1 - in this case, you must ensure that the upgrade on master is not executed. +- Upgrade from \<=4.0.2 directly to >=4.1 - this executes the upgrade script on the main branch. +- Upgrade from 4.0.3 to >=4.1 - in this case, you must ensure that the upgrade on main is not executed. The normal way to do this is ensure that your database upgrade is idempotent. That is, it does not matter if you do it twice. So for example, instead of doing diff --git a/general/app/development/plugins-development-guide/index.md b/general/app/development/plugins-development-guide/index.md index 0c3735431d..b4576d7047 100644 --- a/general/app/development/plugins-development-guide/index.md +++ b/general/app/development/plugins-development-guide/index.md @@ -898,8 +898,8 @@ Font icons are widely used on the app and Moodle LMS website. In order to suppor - Name prefixed with `fas-` or `fa-` will use [Font Awesome solid library](https://fontawesome.com/search?o=r&m=free&s=solid). - Name prefixed with `far-` will use [Font Awesome regular library](https://fontawesome.com/search?o=r&m=free&s=regular). - Name prefixed with `fab-` will use [Font Awesome brands library](https://fontawesome.com/search?o=r&m=free&f=brands) (But only a few are supported and we discourage to use them). -- Name prefixed with `moodle-` will use some svg icons [imported from Moodle LMS](https://github.com/moodlehq/moodleapp/tree/master/src/assets/fonts/moodle/moodle). -- Name prefixed with `fam-` will use [customized Font Awesome icons](https://github.com/moodlehq/moodleapp/tree/master/src/assets/fonts/moodle/font-awesome). +- Name prefixed with `moodle-` will use some svg icons [imported from Moodle LMS](https://github.com/moodlehq/moodleapp/tree/main/src/assets/fonts/moodle/moodle). +- Name prefixed with `fam-` will use [customized Font Awesome icons](https://github.com/moodlehq/moodleapp/tree/main/src/assets/fonts/moodle/font-awesome). - If the prefix is not found or not valid, the app will search the icon name on the [Ionicons library](https://ionic.io/ionicons). ```html title="Example of usage to show icon "pizza-slice" from Font Awesome regular library" diff --git a/general/app/development/scripts/gulp-push.md b/general/app/development/scripts/gulp-push.md index 84329543cd..98d1775468 100644 --- a/general/app/development/scripts/gulp-push.md +++ b/general/app/development/scripts/gulp-push.md @@ -6,7 +6,7 @@ tags: - Tools --- -The `gulp push` command automatically pushes a branch to a git remote and then updates the corresponding Moodle Tracker (Jira) issue with the diff URL or a patch file, similar to `mdk push -t`. This script was developed using [mdk](https://github.com/FMCorz/mdk) as an example. It's meant to be used for `MOBILE` issues, so it will only update the "master" fields in the tracker. +The `gulp push` command automatically pushes a branch to a git remote and then updates the corresponding Moodle Tracker (Jira) issue with the diff URL or a patch file, similar to `mdk push -t`. This script was developed using [mdk](https://github.com/FMCorz/mdk) as an example. It's meant to be used for `MOBILE` issues, so it will only update the "main" fields in the tracker. To run it, just go to the root of the project and run: @@ -17,7 +17,7 @@ gulp push By default, running `gulp push` without any parameter will push the **current branch** to the **origin** remote. Then it will guess the issue number based on the branch name and it will update the tracker issue to include the following fields: - If it's a security issue, it will upload a patch file. -- Otherwise it will update the fields: "Pull from Repository", "Pull Master Branch", and "Pull Master Diff URL". +- Otherwise it will update the fields: "Pull from Repository", "Pull Main Branch", and "Pull Main Diff URL". ## Parameters @@ -50,8 +50,8 @@ The script will use a file named `.moodleapp-dev-config` to store some configura - `tracker.url` — URL of the tracker to update. By default: [https://tracker.moodle.org/](https://tracker.moodle.org/). - `tracker.username` — Username to use in the tracker. - `tracker.fieldnames.repositoryurl` — Name of the tracker field where to put the repository URL. By default: "Pull from Repository". -- `tracker.fieldnames.branch` — Name of the tracker field where to put the branch name. By default: "Pull Master Branch". -- `tracker.fieldnames.diffurl` — Name of the tracker field where to put the diff URL. By default: "Pull Master Diff URL". +- `tracker.fieldnames.branch` — Name of the tracker field where to put the branch name. By default: "Pull Main Branch". +- `tracker.fieldnames.diffurl` — Name of the tracker field where to put the diff URL. By default: "Pull Main Diff URL". - `wording.branchRegex` — Regex to use to identify the issue number based on the branch name. By default: `(MOBILE)[-\_](\[0-9]+)`. If you want to use the script to handle issues that aren't `MOBILE` you'll need to update this field. For example, if you work on 2 projects: `(MOBILE|MYPROJECT)[-\_](\[0-9]+)`. - `{PROJECTNAME}.repositoryUrl` — To specify the git URL where to push changes for a certain project (`{PROJECTNAME}` is the name of the project). This can be used if you work on different projects and you want to push changes to different remotes depending on the project. For example: `MOBILE.repositoryUrl: https://github.com/moodlehq/moodleapp`. - `{PROJECTNAME}.diffUrlTemplate` — To specify the diff URL template to use for a certain project (`{PROJECTNAME}` is the name of the project). By default: `remoteUrl + '/compare/%headcommit%...%branch%'`. diff --git a/general/app/development/setup/app-in-browser.md b/general/app/development/setup/app-in-browser.md index b48ea23cb5..3568e83b3d 100644 --- a/general/app/development/setup/app-in-browser.md +++ b/general/app/development/setup/app-in-browser.md @@ -55,7 +55,7 @@ open -a /Applications/Chromium.app --args --allow-file-access-from-files --disab If you are using other operative system, check out [how to run chromium with flags](https://www.chromium.org/developers/how-tos/run-chromium-with-flags) in other environments. Depending on the version of your browser, you may get a warning message saying "You are using an unsupported command-line flag". This is expected and can safely be ignored (for development). -For more info about the user data dir, please read [the official documentation](https://chromium.googlesource.com/chromium/src/+/master/docs/user_data_dir.md). +For more info about the user data dir, please read [the official documentation](https://chromium.googlesource.com/chromium/src/+/main/docs/user_data_dir.md). ### Creating a shortcut diff --git a/general/app/development/setup/index.md b/general/app/development/setup/index.md index 8069528194..58f1b81c2e 100644 --- a/general/app/development/setup/index.md +++ b/general/app/development/setup/index.md @@ -40,7 +40,7 @@ If you intend to run the application in a native device, you will need to instal ### Windows only: Native build dependencies -`node-gyp` requires native build tools for your platform. If you're developing on Mac or Linux, you'll probably have these already ([refer to the docs if you don't](https://github.com/nodejs/node-gyp/blob/master/README.md)). On Windows, run the following command as administrator (in cmd or Powershell): +`node-gyp` requires native build tools for your platform. If you're developing on Mac or Linux, you'll probably have these already ([refer to the docs if you don't](https://github.com/nodejs/node-gyp/blob/main/README.md)). On Windows, run the following command as administrator (in cmd or Powershell): ```bash npm install --global --production windows-build-tools diff --git a/general/development/policies/backporting.md b/general/development/policies/backporting.md index 7fe377023f..76b073bef6 100644 --- a/general/development/policies/backporting.md +++ b/general/development/policies/backporting.md @@ -15,7 +15,7 @@ Our general policy is as follows: - Bug fixes will be backported to all (and only to) supported stable branches. - When fixing a bug, please provide a fix for all supported stable branches. - If a fix doesn't make sense to be backported to every branch, please make it clear in the issue. -- Improvements or new features will only land in master. +- Improvements or new features will only land in main. ## Process for requesting a non bug-fix backport diff --git a/general/development/policies/codingstyle/index.md b/general/development/policies/codingstyle/index.md index 991d08dc46..d64a2bf8d7 100644 --- a/general/development/policies/codingstyle/index.md +++ b/general/development/policies/codingstyle/index.md @@ -43,7 +43,7 @@ For details about using the Moodle API to get things done, see the [coding guide Several tools are available to help you in write code that conforms to this guide: -- The Moodle [Code checker](https://moodle.org/plugins/view.php?plugin=local_codechecker) (integrates with [eclipse/phpstorm](https://github.com/moodlehq/moodle-local_codechecker/blob/master/README.md#ide-integration)) +- The Moodle [Code checker](https://moodle.org/plugins/view.php?plugin=local_codechecker) (integrates with [eclipse/phpstorm](https://github.com/moodlehq/moodle-local_codechecker/blob/main/README.md#ide-integration)) - The Moodle [PHPdoc checker](https://moodle.org/plugins/local_moodlecheck) It is worth using both tools to check the code you are writing as they both perform slightly different checks. @@ -2024,7 +2024,7 @@ This is especially important if you know an issue still exists in that code that If you have a big task that is nearly done, apart a few TODOs, and you really want to mark the big task as finished, then you should file new tracker tasks for each TODO and change the TODOs comments to point at the new issue numbers. -There is a nice "to-do checker" reporting tool, restricted to admins and available via web @ [`lib/tests/other/todochecker.php`](https://github.com/moodle/moodle/blob/master/lib/tests/other/todochecker.php). +There is a nice "to-do checker" reporting tool, restricted to admins and available via web @ [`lib/tests/other/todochecker.php`](https://github.com/moodle/moodle/blob/main/lib/tests/other/todochecker.php). Finally, don't forget to add any MDL-12345 used by your TODOs (and @todos too, unless part of the [deprecation process](../deprecation/index.md), those are handled apart) to the "Review TODOs Epic": MDL-47779 (requires login to see the issues) @@ -2079,8 +2079,8 @@ Way before this coding-style guide was defined and agreed, a lot of code had bee In any case, in order to normalize the (progressive, non-critical) transition, a policy issue (MDL-43233) was created and agreed about. And these are the rules to apply to coding-style only changes: 1. Related coding-style changes (same lines, a variable within a method/function, adjacent comments, etc.) within a real issue are allowed. -1. Unrelated coding-style changes (other methods, blocks of code, comments, etc.) within a real issue are only accepted for master and in a separate commit. -1. Coding-style only issues are only accepted for master along the first 2 months of every cycle. +1. Unrelated coding-style changes (other methods, blocks of code, comments, etc.) within a real issue are only accepted for main and in a separate commit. +1. Coding-style only issues are only accepted for main along the first 2 months of every cycle. ## Git commits diff --git a/general/development/policies/deprecation/index.md b/general/development/policies/deprecation/index.md index f6242d30a5..0f55457806 100644 --- a/general/development/policies/deprecation/index.md +++ b/general/development/policies/deprecation/index.md @@ -18,7 +18,7 @@ In an open source project, the end use of the codebase varies. People may have c ## What is Moodle's deprecation policy? -- Deprecations should only be on master, not on stables (exceptions may be made for some external service integrations) +- Deprecations should only be on main, not on stables (exceptions may be made for some external service integrations) - Deprecations apply to all public APIs, classes, and files. - Removal of a function, class, or file may only be considered after a minimum of 4 major releases since the deprecation. Example: anything deprecated in 3.2 means that it will be removed in 3.6 - All deprecations should emit debugging notices where possible @@ -36,7 +36,7 @@ Both steps should always happen as earlier as possible in the 6-months period be ### Step 1. Immediate action -Deprecation affects only the current master version, in other words, the deprecation only becomes effective after the next [major release](../../../releases.md). +Deprecation affects only the current main version, in other words, the deprecation only becomes effective after the next [major release](../../../releases.md). - If the function is not a member of a class (in other words, it is an independent function), it should be moved, with its PHPDoc and all comments, to `lib/deprecatedlib.php`, which is included everywhere. If the function is a class member, it will need to be deprecated in its current location. - Deprecated behat step definitions should be moved to `lib/tests/behat/behat_deprecated.php`. Steps that are part of a component should be moved to `$COMPONENT_DIRECTORY/tests/behat/behat__deprecated.php` instead. Deprecated function should call to `behat_deprecated::deprecated_message()` proposing an alternative to the deprecated method. @@ -98,7 +98,7 @@ Longer deprecation periods can be considered for functions that are widely used. ### Step 2. Final deprecation -- If a function has been marked as deprecated for `3.[x]` (eg. 3.1) and set for removal at `3.[x + 4]` (eg. 3.5), soon after the release of `3.[x + 3].1` (eg. 3.4.1), the `3.[x + 4]` deprecation META will be processed. This means that the deprecated function will undergo final deprecation before `3.[x + 4]`, but only in the master version. This allows any potential regressions caused by the final deprecation of the function to be exposed as soon as possible. +- If a function has been marked as deprecated for `3.[x]` (eg. 3.1) and set for removal at `3.[x + 4]` (eg. 3.5), soon after the release of `3.[x + 3].1` (eg. 3.4.1), the `3.[x + 4]` deprecation META will be processed. This means that the deprecated function will undergo final deprecation before `3.[x + 4]`, but only in the main version. This allows any potential regressions caused by the final deprecation of the function to be exposed as soon as possible. - When a function undergoes final deprecation, all content of the function should be removed. In the skeleton that remains, an error statement should be included that indicates that the function cannot be used anymore. You can also direct developers to the new function(s) in this message. diff --git a/general/development/process.md b/general/development/process.md index 0dbac68343..d8be4267a7 100644 --- a/general/development/process.md +++ b/general/development/process.md @@ -157,7 +157,7 @@ During each cycle there are a periods and events that occur between and around s A period during which the Roadmap is explored, specs are written and prototypes are created. Regressions in the recent release are fixed as they arise. **End sync period**
-During the [on-sync period](./process/integration/index.md#on-sync-period), the recent release and master versions are kept synchronised. No new code is added during this period, which ensures regressions are fixed rapidly. This also allows for planning and provides relief for developers after a release. +During the [on-sync period](./process/integration/index.md#on-sync-period), the recent release and main versions are kept synchronised. No new code is added during this period, which ensures regressions are fixed rapidly. This also allows for planning and provides relief for developers after a release. **Personal projects**
Affecting full-time HQ developers only, this period allows for individual creations to be explored and provides a break from sprints. @@ -233,7 +233,7 @@ Every change must have an issue in the tracker. If you are fixing a bug, there i ### Decide which branches the fix is required on -Bugs should normally be fixed on all the supported stable branches that are affected. New features should just go into master, but sometimes minor enhancements are made on the most recent stable branch. +Bugs should normally be fixed on all the supported stable branches that are affected. New features should just go into main, but sometimes minor enhancements are made on the most recent stable branch. ### Develop your change using git diff --git a/general/development/process/integration/index.md b/general/development/process/integration/index.md index 92f8a395da..1955a1442f 100644 --- a/general/development/process/integration/index.md +++ b/general/development/process/integration/index.md @@ -30,7 +30,7 @@ Integration (non-technical but philosophical) principles (4-5 words determining 1. **safety**: if something does not look safe, stable, it won't land. Be conservative. 2. **security**: all security issues, if not breaking principle (1) will be integrated/backported to all security-supported versions. 3. **community**: Anything not useful for the community (or against it) won't be integrated/backported. We can measure the community as 10%HQ, 10%Partners, 10%Core developers, 20%Admins, 20%Teachers, 30%Students - not exact science, just one approximation, you know). Question yourself how the change will affect those groups and ensure positives are bigger always (only affected groups count). All community issues, if not breaking principles (1) and (2) will be integrated. -4. **typology**: bug fixes will be always integrated/backported to all the supported branches if none of the principles (1), (2) and (3) are violated. Also, partially-unsupported branches can receive some if they are important enough. Improvements and new features go, exclusively, to master only, that's the main reason for short release periods. We *MUST* not make exceptions to this. +4. **typology**: bug fixes will be always integrated/backported to all the supported branches if none of the principles (1), (2) and (3) are violated. Also, partially-unsupported branches can receive some if they are important enough. Improvements and new features go, exclusively, to main only, that's the main reason for short release periods. We *MUST* not make exceptions to this. 5. **priority**: issues will be "ordered down" by priority down (where priority is a [mix of various factors](https://tracker.moodle.org/issues/?filter=14000), dynamic). And will be integrated in that order. If something has to be delayed, better if it is low priority. Once again, nothing here can break any of the previous principles. 6. **tests**: unit tests and acceptance tests will backported as much as possible without breaking (1) and (2). New features required to implement tests will be backported if the API is 100% backwards compatible. @@ -66,7 +66,7 @@ comment. 2. at end of Wednesday, ensure testing is going to complete as expected. else take other actions (speak to test manager) 10. Performance - we have to look at maintaining optimum code here, as far as simple patches that can affect performance. (simple optimisations) -11. Scalability - if master only - we're looking far future, stable branches may not be lucky to get such improvements. +11. Scalability - if main only - we're looking far future, stable branches may not be lucky to get such improvements. 12. git authorship is correct vs committer + credits due are mentioned + email addresses 13. Documentation / PHP Doc / readability 14. [Tracker issue labels](../../tracker/labels.md) which might need adding. Particularly: @@ -75,7 +75,7 @@ optimisations) 3. `unit_test_required` / `acceptance_test_required` / `qa_test_required`: About the need to cover the issue with some test. 4. `affects_mobileapp` / `affects_workplace` / `affects_moodlecloud`: About issues that may affect other Moodle products and services 15. [Tracker issue versions](https://docs.moodle.org/dev/Tracker_issue_versions) review. Particularly: - 1. Fixed Version after integration - is the versions that the issue is patched for. (A rule here: ["or stables or master"](https://docs.moodle.org/dev/Tracker_issue_versions#Some_general_and_simple_rules)). + 1. Fixed Version after integration - is the versions that the issue is patched for. (A rule here: ["or stables or main"](https://docs.moodle.org/dev/Tracker_issue_versions#Some_general_and_simple_rules)). 2. Remove any `Must fix for X.Y` version once the issue is integrated. 16. Whenever any of the points above or any other detail require extra information or action to be done by the assignee, and the integrator considers that they can be fixed without needing to discard/reopen, the issue will be sent to `Waiting for feedback` with all the details to @@ -101,11 +101,11 @@ Note that under the strict schedule above, it is specially important **to be as ### During continuous integration/Freeze/QA period -During the continuous integration period (last 7 weeks before release) the integration team are continuously focused on producing regular builds of master to facilitate QA and fast fixes to issues identified. +During the continuous integration period (last 7 weeks before release) the integration team are continuously focused on producing regular builds of main to facilitate QA and fast fixes to issues identified. Throughout: -- Issues are picked on a one by one basis, prioritising [QA blockers](../testing/qa.md#resetting-tests) and master regressions (MUST FIX) issues. +- Issues are picked on a one by one basis, prioritising [QA blockers](../testing/qa.md#resetting-tests) and main regressions (MUST FIX) issues. - After freeze (usually 6 weeks before release) any non bug fix issues are given the `integration_held` label and are explicitly not picked for integration. Still, anybody is able to add a reasoned `unhold_requested` label to those issues in order to get them unblocked by the development managers. Note this does not guarantee the issue to land before release, but just gives it a chance to be integrated like any other issue. - Also, coming together with freeze, all the flow of issues to current integration is automatically controlled by the [Manage queues on continuous](https://ci.moodle.org/view/Tracker/job/TR%20-%20Manage%20queues%20on%20continuous/) job that keeps the current queue fed with issues, moves important ones, holds new features and other niceties. Issues are picked in strict integration order. - Our goal is to achieve 'release-ability' throughout, so we stop integrating to ensure a release happens @@ -114,13 +114,13 @@ So, basically, once under **the whole continuous integration period**, we do org - Continuous officially begins. Everybody is on integration. Until end of on-sync period. - Monday: Integration and [testing](../testing/integrated-issues.md#differences-in-test-process-during-continuous-integration-periods) happens. -- Tuesday: Integration happens until [12:00 (UTC+8)](http://time.unitarium.com/utc/4), afterwards we try to [achieve 100% 'Test Passed'](../testing/integrated-issues.md#differences-in-test-process-during-continuous-integration-periods) and stop integrating any untested changes until a master release is produced. -- Wednesday: [Assuming a master release has been rolled] Integration and testing continues +- Tuesday: Integration happens until [12:00 (UTC+8)](http://time.unitarium.com/utc/4), afterwards we try to [achieve 100% 'Test Passed'](../testing/integrated-issues.md#differences-in-test-process-during-continuous-integration-periods) and stop integrating any untested changes until a main release is produced. +- Wednesday: [Assuming a main release has been rolled] Integration and testing continues - Thursday: Integration and testing continues -- Friday: Integration happens until [12:00 (UTC+8)](http://time.unitarium.com/utc/4), afterwards we try to achieve 100% 'Test Passed' and stop integrating any untested changes until a master release is produced. Note that 24h before the cutoff it's possible to pick issues out of order towards queues reduction. +- Friday: Integration happens until [12:00 (UTC+8)](http://time.unitarium.com/utc/4), afterwards we try to achieve 100% 'Test Passed' and stop integrating any untested changes until a main release is produced. Note that 24h before the cutoff it's possible to pick issues out of order towards queues reduction. :::note -Along this period we always release as many stable weeklies, both supported (always) and security only (when there are changes), as master rolls (on-demand, beta, rc) happen (see [MDLSITE-3470](https://tracker.moodle.org/browse/MDLSITE-3470)). Note that those tags are not simply tags but they come with some important implications, aiming to stability, safety and clarity. Integrators will try to remain loyal to them, be warned: +Along this period we always release as many stable weeklies, both supported (always) and security only (when there are changes), as main rolls (on-demand, beta, rc) happen (see [MDLSITE-3470](https://tracker.moodle.org/browse/MDLSITE-3470)). Note that those tags are not simply tags but they come with some important implications, aiming to stability, safety and clarity. Integrators will try to remain loyal to them, be warned: ::: - **Once beta is released**, new features or improvements "unrelated" with the release will be really harder to be accepted. A +4 from developer managers (normally +3 is enough) will be needed to proceed with the issue. Integrators vote will be, always, -1. @@ -135,18 +135,18 @@ Definition: `related` said to be a followup of required/planned to release OR a Immediately after a major release and for a short period (right now, 2 weeks, matching 1st HQ sprint duration), the integration team is under the named on-sync period. -At all effects, it's a normal period (see above), and weeklies are produced for supported stable branches and also for master. But with one important rule/goal: +At all effects, it's a normal period (see above), and weeklies are produced for supported stable branches and also for main. But with one important rule/goal: -- We must keep the latest stable branch and master 100% on-sync, specifically about versions and upgrade steps. Some well-known exceptions to this are: *backup.class.php*, *config.php* (*$release*, *$branch*, *$maturity* and comments only, never *$version*!), *install/lang/xx files* (the new stable branch for install lang files is created 2w after the release). +- We must keep the latest stable branch and main 100% on-sync, specifically about versions and upgrade steps. Some well-known exceptions to this are: *backup.class.php*, *config.php* (*$release*, *$branch*, *$maturity* and comments only, never *$version*!), *install/lang/xx files* (the new stable branch for install lang files is created 2w after the release). -This simple, but important constraint, is there to facilitate the integration of impeding bugs, needing urgent resolution, and by keeping them the same, we guarantee that any stable or master fix will apply without problems to both branches. Of course, in order to achieve the rule, these must be also observed along the period: +This simple, but important constraint, is there to facilitate the integration of impeding bugs, needing urgent resolution, and by keeping them the same, we guarantee that any stable or main fix will apply without problems to both branches. Of course, in order to achieve the rule, these must be also observed along the period: -- We continuously perform diffs between the latest stable and master, controlling that we are on-sync. Any non-authorised difference is cleaned (rewritten). Whenever a latest stable branch is missing in the issue (it's optional over the period), we automatically cherry pick the changes straight from master. +- We continuously perform diffs between the latest stable and main, controlling that we are on-sync. Any non-authorised difference is cleaned (rewritten). Whenever a latest stable branch is missing in the issue (it's optional over the period), we automatically cherry pick the changes straight from main. - Both improvements and new features (and, in general, everything leading to divergence) are held until the on-sync period ends. Last, but not less important, a second goal for this on-sync period is: -- The **environmental requirements for next major version** [must be agreed and resolved so they can land to master](./release#2-weeks-after) early in the process, remaining defined and stable over the next, 6 months of, development cycle. +- The **environmental requirements for next major version** [must be agreed and resolved so they can land to main](./release#2-weeks-after) early in the process, remaining defined and stable over the next, 6 months of, development cycle. As part of the standard [Moodle release process](./release), at the beginning of the on-sync period, we "unhold" all bugs that were held during the last week before the release because they were unrelated to the release. At the end of the onsync period we "unhold" all new features that were submitted after the code freeze for the the release. ## Fixing issues identified during integration review/ testing diff --git a/general/development/process/peer-review/index.md b/general/development/process/peer-review/index.md index 4e8ecff2ad..d7ef88c06c 100644 --- a/general/development/process/peer-review/index.md +++ b/general/development/process/peer-review/index.md @@ -97,7 +97,7 @@ Ensure that: - New language strings are named correctly (all lower case, no camel-case, underscores are permissible in some cases); - Help strings are named and formatted as described in [Help strings](https://docs.moodle.org/dev/Help_strings); - Language strings are used instead of hard-coded strings for text output; -- Language strings have not been removed or renamed, had their meaning changed or had their parameters changed in stable branches (permitted only in master following [string deprecation policy](../../../projects/api/string-deprecation.md)); and +- Language strings have not been removed or renamed, had their meaning changed or had their parameters changed in stable branches (permitted only in main following [string deprecation policy](../../../projects/api/string-deprecation.md)); and - [AMOS commands](https://docs.moodle.org/dev/AMOS_commands) have been specified when moving or copying language strings. ### Databases diff --git a/general/development/process/security/penetration-testing.md b/general/development/process/security/penetration-testing.md index 9e3eedd23b..6ce482c19f 100644 --- a/general/development/process/security/penetration-testing.md +++ b/general/development/process/security/penetration-testing.md @@ -27,7 +27,7 @@ Moodle has a fine grained capabilities and roles system for providing access con However if a penetration test finds that actions can be taken which expose an XSS risk, **AND** that the test user has **NOT** been granted capabilities that grant them an explicit XSS risk, then there is a real issue and either the XSS risk should be closed, or it should be disclosed in the definition of that capability. -The most trivial example would be the ability to [edit `site:config`](https://github.com/moodle/moodle/blob/master/lib/db/access.php#L58-L60) which has the RISK_XSS: +The most trivial example would be the ability to [edit `site:config`](https://github.com/moodle/moodle/blob/main/lib/db/access.php#L58-L60) which has the RISK_XSS: ```php 'moodle/site:config' => [ diff --git a/general/development/process/testing/integrated-issues.md b/general/development/process/testing/integrated-issues.md index f70b25675d..9a8e67ca36 100644 --- a/general/development/process/testing/integrated-issues.md +++ b/general/development/process/testing/integrated-issues.md @@ -67,7 +67,7 @@ Testing instructions are clear, concise, complete, and accurate. Where possible ## Differences in test process during continuous integration periods During [continuous integration](../integration/index.md#during-continuous-integrationfreezeqa-period) the schedule is changed to allow faster iteration and for bug fixes to be applied more rapidly than the usual weekly cycle. The goal during this period is ... -goal during this period is to release a new version of master multiple times per week. We try to keep the process more flexible during this time in order that developers who have less pressing issues than others can take the load off those concentrating on big fixes. It works best if we work together to help each other out. +goal during this period is to release a new version of main multiple times per week. We try to keep the process more flexible during this time in order that developers who have less pressing issues than others can take the load off those concentrating on big fixes. It works best if we work together to help each other out. :::warning Priority is given to testing issues to ensure we can release regularly diff --git a/general/development/process/testing/qa.md b/general/development/process/testing/qa.md index c8f5bc453d..ab9266ffdc 100644 --- a/general/development/process/testing/qa.md +++ b/general/development/process/testing/qa.md @@ -23,7 +23,7 @@ Would you like to help with QA testing? If so, please make sure you have created - Only assign an issue to yourself which no one else is testing (Assignee = Unassigned). - Only assign one issue at a time unless you plan to test a number of related issues within the next 24 hours. In other words, don't assign several issues to yourself then do nothing for several days. ;-) - The label `test_server_required` indicates issues that can't be tested on the QA testing site. The label `credentials_required` indicates that credentials such as an OAuth 2 service client ID and secret are required. -2. Using either the [Moodle QA Testing Site](https://qa.moodledemo.net/) or your own test site running the latest Moodle 4.2dev (available from Git on the integration/master branch git://git.moodle.org/integration.git) with [debugging](https://docs.moodle.org/dev/debugging) set to developer, perform each of the steps listed in the test. +2. Using either the [Moodle QA Testing Site](https://qa.moodledemo.net/) or your own test site running the latest Moodle 4.2dev (available from Git on the integration/main branch git://git.moodle.org/integration.git) with [debugging](https://docs.moodle.org/dev/debugging) set to developer, perform each of the steps listed in the test. 3. Please *attach screenshots of the steps where you verify or check something*. 4. If it makes sense, please test using the currently supported themes, Boost and Classic. 5. Choose an appropriate workflow action: diff --git a/general/development/process/triage.md b/general/development/process/triage.md index 9e2d9ed21e..a257e4fa9e 100644 --- a/general/development/process/triage.md +++ b/general/development/process/triage.md @@ -54,7 +54,7 @@ When you confirm that the issue is indeed a bug or a reasonable improvement requ - **Priority**. Some reporters over-state an issue's priority. Some reporters don't know they can set a priority. Priority is used as one of the criteria when sorting issues in the backlog, so it should reflect the position of this issue comparing to the others. Usually **Improvements** have `minor` or `major` priority and **Bugs** can have any priority up to `blocker`. Priority levels have specific criteria. Please see [the Tracker guide](https://docs.moodle.org/dev/Tracker_Guide#When_editing_an_issue) - **Component/s**. Listing components correctly is important as they are the primary variable used for searching for issues. In addition the component leads will be added as watchers automatically when. Issues may have several components when needed - **Affects version**. This field should include one or more released **and supported** versions of Moodle that are affected by the issue, with the following exceptions: - - The issue is a bug in code that is present in the `master` branch only, in which case the next major version should be used. (The next major version should not be used in conjunction with previous released versions, this won't make sense later.) + - The issue is a bug in code that is present in the `main` branch only, in which case the next major version should be used. (The next major version should not be used in conjunction with previous released versions, this won't make sense later.) - The issue is a new feature and is unrelated to any existing code in Moodle, in which case the `Future dev` version should be used. - **Labels** - Remove functionality tags that some reporters add as labels, only [standard labels or partner-specific labels](../tracker/labels.md) are used in Moodle diff --git a/general/development/tools/behat/writing.md b/general/development/tools/behat/writing.md index 5f80e7ebb5..d36a321a82 100644 --- a/general/development/tools/behat/writing.md +++ b/general/development/tools/behat/writing.md @@ -302,7 +302,7 @@ There are two reasons why it is good to use these steps: It is possible to extend the `Given the following "entities" exist` step to support your plugin's data generators. This avoids having to write new whole new behat step definitions for your plugin, and allows you to re-use data generators between PHPUnit and Behat tests. -Full documentation of this process and all available options can be found in the [PHPDoc for behat_generator_base](https://github.com/moodle/moodle/blob/1d4fdb0d1c60448104bc9eac79b5123863c67cbd/lib/behat/classes/behat_generator_base.php#L33). A core example of this can be found in [/mod/quiz/tests/generator](https://github.com/moodle/moodle/tree/master/mod/quiz/tests/generator) and [quiz_reset.feature](https://github.com/moodle/moodle/blob/1d4fdb0d1c60448104bc9eac79b5123863c67cbd/mod/quiz/tests/behat/quiz_reset.feature#L51). What follows is a simple example. +Full documentation of this process and all available options can be found in the [PHPDoc for behat_generator_base](https://github.com/moodle/moodle/blob/1d4fdb0d1c60448104bc9eac79b5123863c67cbd/lib/behat/classes/behat_generator_base.php#L33). A core example of this can be found in [/mod/quiz/tests/generator](https://github.com/moodle/moodle/tree/main/mod/quiz/tests/generator) and [quiz_reset.feature](https://github.com/moodle/moodle/blob/1d4fdb0d1c60448104bc9eac79b5123863c67cbd/mod/quiz/tests/behat/quiz_reset.feature#L51). What follows is a simple example. To begin, you need a [generator](https://docs.moodle.org/dev/Writing_PHPUnit_tests#Generators) in `/*your*/*plugin*/tests/generator/lib.php`. If you are generating a type of entity called "thing", your generator will need a method called create_thing, which accepts an object: diff --git a/general/development/tools/cibot.md b/general/development/tools/cibot.md index 4d17a47458..3c7af27e24 100644 --- a/general/development/tools/cibot.md +++ b/general/development/tools/cibot.md @@ -35,9 +35,9 @@ If correcting this variable would affect other parts of the code not covered by ## Requesting CiBot checks an issue -At any time a developer can add the label `cime` to an issue to request it runs it checks against it. The bot [checks for issues with the cime label](https://github.com/moodlehq/moodle-local_ci/blob/master/tracker_automations/bulk_precheck_issues/criteria/developer_request/query.sh) every 20mins and runs the checks then remove the cime label. (Note that because it removes the label, it is normal to 'create' the label). +At any time a developer can add the label `cime` to an issue to request it runs it checks against it. The bot [checks for issues with the cime label](https://github.com/moodlehq/moodle-local_ci/blob/main/tracker_automations/bulk_precheck_issues/criteria/developer_request/query.sh) every 20mins and runs the checks then remove the cime label. (Note that because it removes the label, it is normal to 'create' the label). -Any issue [submitted for peer review](https://github.com/moodlehq/moodle-local_ci/blob/master/tracker_automations/bulk_precheck_issues/criteria/awaiting_peer_review/query.sh) or [integration review](https://github.com/moodlehq/moodle-local_ci/blob/master/tracker_automations/bulk_precheck_issues/criteria/awaiting_integration/query.sh) will be checked automatically as long as it does not already have the 'ci' label. +Any issue [submitted for peer review](https://github.com/moodlehq/moodle-local_ci/blob/main/tracker_automations/bulk_precheck_issues/criteria/awaiting_peer_review/query.sh) or [integration review](https://github.com/moodlehq/moodle-local_ci/blob/main/tracker_automations/bulk_precheck_issues/criteria/awaiting_integration/query.sh) will be checked automatically as long as it does not already have the 'ci' label. ## Are additional CiBot checks possible? diff --git a/general/development/tools/composer.md b/general/development/tools/composer.md index a69d3f02f4..6631d36063 100644 --- a/general/development/tools/composer.md +++ b/general/development/tools/composer.md @@ -31,7 +31,7 @@ php composer.phar install ## How to prepare and submit composer changes -There are a number of situations where we need to update the bundled [composer.json](https://github.com/moodle/moodle/blob/master/composer.json)] in core. When we upgrade, for a given branch, [the phpunit](https://tracker.moodle.org/browse/MDL-71036) or [the behat-extension](https://tracker.moodle.org/browse/MDL-70637) versions... we also have to update the [composer.lock](https://github.com/moodle/moodle/blob/master/composer.lock) file, in order to guarantee that all the tests will run in a stable, verified environment. +There are a number of situations where we need to update the bundled [composer.json](https://github.com/moodle/moodle/blob/main/composer.json)] in core. When we upgrade, for a given branch, [the phpunit](https://tracker.moodle.org/browse/MDL-71036) or [the behat-extension](https://tracker.moodle.org/browse/MDL-70637) versions... we also have to update the [composer.lock](https://github.com/moodle/moodle/blob/main/composer.lock) file, in order to guarantee that all the tests will run in a stable, verified environment. As far as there are a number of variables affecting how that lock file will be generated, here there are some standard steps to follow, in order to guarantee that any change to composer will be always applied in the same, standard and verified way. diff --git a/general/documentation/contributing.md b/general/documentation/contributing.md index 7feca0c986..c460adc7ee 100644 --- a/general/documentation/contributing.md +++ b/general/documentation/contributing.md @@ -258,7 +258,7 @@ The `` tag is primarily used for `docs` changes to describe the section of Some of this documentation related to a specific version of Moodle: - `general` - This section is not documented at all -- `docs` - Relates to the current Moodle development branch, known as `master` +- `docs` - Relates to the current Moodle development branch, known as `main` - `versioned_docs/version-X.Y` - Related to a specific major version of Moodle If you are documenting a feature which should be documented across older versions, we request that you backport it to the relevant stable versions. diff --git a/general/documentation/structure.md b/general/documentation/structure.md index 1b613af8ca..1783b891ec 100644 --- a/general/documentation/structure.md +++ b/general/documentation/structure.md @@ -44,7 +44,7 @@ If you are creating a page which does not fit into one of these categories, we s The versioned documentation has two locations you will need to look at: -- For the Moodle master branch, see the [docs](https://github.com/moodle/devdocs/tree/main/docs) folder +- For the Moodle main branch, see the [docs](https://github.com/moodle/devdocs/tree/main/docs) folder - For older versions of Moodle which are documented here, see the [versioned_docs](https://github.com/moodle/devdocs/tree/main/versioned_docs) folder :::note diff --git a/general/projects/api/amos.md b/general/projects/api/amos.md index b084584583..b4da3f58d6 100644 --- a/general/projects/api/amos.md +++ b/general/projects/api/amos.md @@ -196,7 +196,7 @@ There are no instructions `DEL` or `ADD`. AMOS automatically recognized new stri :::note -Strings can be removed on the master branch easily by removing them from the strings file. No AMOS command is needed. Just make sure the string is not use elsewhere and do not remove the string from stable branches. +Strings can be removed on the main branch easily by removing them from the strings file. No AMOS command is needed. Just make sure the string is not use elsewhere and do not remove the string from stable branches. ::: diff --git a/general/projects/api/string-deprecation.md b/general/projects/api/string-deprecation.md index 42ccdf2cf0..99cee671ac 100644 --- a/general/projects/api/string-deprecation.md +++ b/general/projects/api/string-deprecation.md @@ -58,7 +58,7 @@ When deprecating a core string from `lang/en/xxxx.php` the `fullcomponentname` s ::: -- Strings can be deprecated and removed on the `master` branch only. +- Strings can be deprecated and removed on the `main` branch only. - Locate or create a file `deprecated.txt` either in `lang/en/` or `componentfullpath/lang/en/` - Add a line `identifier,fullcomponentname` to the end of this file - Move the string inside the existing language file to the end of the file under the comment `// Deprecated since Moodle X.Y.` (this comment will help removing deprecated strings later). @@ -78,14 +78,14 @@ There are two possibilities. Either the code that uses the deprecated string mus Use the `git-blame` tool on the corresponding `lang/en/deprecated.txt` and find the commit/issue that deprecated the string. It should give you enough information to decide on the most appropriate action. -- If you think the string was deprecated by mistake, create a new issue in the tracker to remove it from the list (on all supported branches, not only on master). +- If you think the string was deprecated by mistake, create a new issue in the tracker to remove it from the list (on all supported branches, not only on main). - If the string was renamed or moved, you will probably want to fix the caller to use the new name/location of the string. - You may as well copy the string to your own plugin scope and make it context-specific. :::info Git blame -[git blame lang/en/deprecated.txt](https://github.com/moodle/moodle/blame/master/lang/en/deprecated.txt)
-[git blame mod/quiz/lang/en/deprecated.txt](https://github.com/moodle/moodle/blame/master/mod/quiz/lang/en/deprecated.txt) +[git blame lang/en/deprecated.txt](https://github.com/moodle/moodle/blame/main/lang/en/deprecated.txt)
+[git blame mod/quiz/lang/en/deprecated.txt](https://github.com/moodle/moodle/blame/main/mod/quiz/lang/en/deprecated.txt) ::: diff --git a/general/releases/2.2.md b/general/releases/2.2.md index 19d6053830..31aff37d38 100644 --- a/general/releases/2.2.md +++ b/general/releases/2.2.md @@ -43,7 +43,7 @@ All security issues that were fixed in 2.1.x and 2.0.x were also fixed in 2.2. #### Core API changes -- https://github.com/moodle/moodle/blob/master/lib/upgrade.txt +- https://github.com/moodle/moodle/blob/main/lib/upgrade.txt - [MDL-29474](https://tracker.moodle.org/browse/MDL-29474) - Plugins should declare (in [version.php](/docs/apis/commonfiles/version.php)) if they depend on other plugins - [MDL-28554](https://tracker.moodle.org/browse/MDL-28554) - Upgrade to YUI 3.4.0 and 2.9.0 - [MDL-26796](https://tracker.moodle.org/browse/MDL-26796) - We no longer accept arrays in required_param() and optional_param() diff --git a/versioned_docs/version-4.1/apis.md b/versioned_docs/version-4.1/apis.md index 9045fe5289..598b17052c 100644 --- a/versioned_docs/version-4.1/apis.md +++ b/versioned_docs/version-4.1/apis.md @@ -78,7 +78,7 @@ The [Backup API](./apis/subsystems/backup/index.md) defines exactly how to conve ### Cache API (cache) -The [The Moodle Universal Cache (MUC)](https://docs.moodle.org/dev/The_Moodle_Universal_Cache_(MUC)) is the structure for storing cache data within Moodle. [Cache API](https://docs.moodle.org/dev/Cache_API) explains some of what is needed to use a cache in your code. +The [The Moodle Universal Cache (MUC)](https://docs.moodle.org/dev/The_Moodle_Universal_Cache_(MUC)) is the structure for storing cache data within Moodle. [Cache API](/docs/apis/subsystems/muc/index.md) explains some of what is needed to use a cache in your code. ### Calendar API (calendar) @@ -135,7 +135,7 @@ The [Lock API](./apis/core/lock/index.md) lets you synchronise processing betwee ### Message API (message) -The [Message API](https://docs.moodle.org/dev/Message_API) lets you post messages to users. They decide how they want to receive them. +The [Message API](/docs/apis/core/message/index.md) lets you post messages to users. They decide how they want to receive them. ### Media API (media) @@ -173,7 +173,7 @@ The [Rating API](https://docs.moodle.org/dev/Rating_API) lets you create AJAX ra ### Report builder API (reportbuilder) -The [Report builder API](../../docs/apis/core/reportbuilder/index.md) allows you to create reports in your plugin, as well as providing custom reporting data which users can use to build their own reports. +The [Report builder API](/docs/apis/core/reportbuilder/index.md) allows you to create reports in your plugin, as well as providing custom reporting data which users can use to build their own reports. ### RSS API (rss) @@ -213,7 +213,7 @@ The [https://docs.moodle.org/dev/OpenBadges_User_Documentation Badges] user docu ### Custom fields API (customfield) -The [Custom fields API](../../docs/apis/core/customfields/index.md) allows you to configure and add custom fields for different entities +The [Custom fields API](/docs/apis/core/customfields/index.md) allows you to configure and add custom fields for different entities ## Activity module APIs diff --git a/versioned_docs/version-4.1/apis/_files/upgrade-txt.mdx b/versioned_docs/version-4.1/apis/_files/upgrade-txt.mdx index 5397e05ba0..a29d8cd37f 100644 --- a/versioned_docs/version-4.1/apis/_files/upgrade-txt.mdx +++ b/versioned_docs/version-4.1/apis/_files/upgrade-txt.mdx @@ -1,20 +1,20 @@ Each component and subsystem may make use of an `upgrade.txt` file in the top level folder. A section title is used to identify the Moodle version where the change was introduced, and significant changes for that version relating to that component or subsystem are noted. -For example, given an API change is applied for the upcoming Moodle version 4.1 which is still in the **master** branch (4.1dev), the version number on the `upgrade.txt`'s section title will be set to **4.1**. +For example, given an API change is applied for the upcoming Moodle version 4.1 which is still in the **main** branch (4.1dev), the version number on the `upgrade.txt`'s section title will be set to **4.1**. -```txt title="Example 1: Change applied to the master branch" +```txt title="Example 1: Change applied to the main branch" == 4.1 == An API change to empower educators! ``` #### Changes applied to multiple branches -When changes are integrated to multiple branches, for example a stable version and the master branch, then the relevant versions used to describe the change in the `upgrade.txt` file should be the next version to be released _for each branch_. The **master** branch should always use the next major version. +When changes are integrated to multiple branches, for example a stable version and the main branch, then the relevant versions used to describe the change in the `upgrade.txt` file should be the next version to be released _for each branch_. The **main** branch should always use the next major version. -For example, if a change is applied to the **MOODLE_400_STABLE** during the development of Moodle 4.0.2, and the **master** branch during the development of Moodle 4.1, then the relevant versions will be **4.0.2** and **4.1**, respectively. The section title for the **master** branch will be the same as the one in Example 1. The section title for the **MOODLE_400_STABLE** branch will indicate the next upcoming minor version (4.0.2 in this case): +For example, if a change is applied to the **MOODLE_400_STABLE** during the development of Moodle 4.0.2, and the **main** branch during the development of Moodle 4.1, then the relevant versions will be **4.0.2** and **4.1**, respectively. The section title for the **main** branch will be the same as the one in Example 1. The section title for the **MOODLE_400_STABLE** branch will indicate the next upcoming minor version (4.0.2 in this case): -```txt title="Example 2: Patch applied to master and MOODLE_400_STABLE" +```txt title="Example 2: Patch applied to main and MOODLE_400_STABLE" == 4.0.2 == An API change to empower educators! ``` @@ -23,7 +23,7 @@ An API change to empower educators! Multiple versions within the section title are **not** allowed. However, developers may note the Moodle versions that the change applies to within the upgrade note text itself. -```txt title="Example 3a: master (4.1dev)" +```txt title="Example 3a: main (4.1dev)" == 4.1 == An API change to empower educators! (This was fixed in 4.1 and 4.0.2) ``` @@ -43,9 +43,9 @@ An API change to empower educators! When Moodle is developing two major versions in parallel, for example Moodle 3.11.0, and Moodle 4.0.0, then the version in the earliest of the major version development branches will be used for both branches. -For example, given we are in a parallel development situation with **MOODLE_311_STABLE** (3.11dev) and **master** (4.0dev), with Moodle 3.11 as the next upcoming major Moodle version. If an API change is applied to **MOODLE_311_STABLE**, the version number on the section title will be **3.11** for both **master** and **MOODLE_400_STABLE** branches. +For example, given we are in a parallel development situation with **MOODLE_311_STABLE** (3.11dev) and **main** (4.0dev), with Moodle 3.11 as the next upcoming major Moodle version. If an API change is applied to **MOODLE_311_STABLE**, the version number on the section title will be **3.11** for both **main** and **MOODLE_400_STABLE** branches. -```txt title="Example 4a: master (4.0dev)" +```txt title="Example 4a: main (4.0dev)" == 3.11 == An API change to empower educators! ``` diff --git a/versioned_docs/version-4.1/apis/core/htmlwriter/index.md b/versioned_docs/version-4.1/apis/core/htmlwriter/index.md index 2a1188580f..4740676734 100644 --- a/versioned_docs/version-4.1/apis/core/htmlwriter/index.md +++ b/versioned_docs/version-4.1/apis/core/htmlwriter/index.md @@ -16,7 +16,7 @@ Please consider using [templates](../../../guides/templates/index.md) as an alte :::note -There is no documentation for most of this class. Please read [HTML Writer Class Reference](https://phpdoc.moodledev.io/master/d4/d78/classhtml__writer.html) for further information. +There is no documentation for most of this class. Please read [HTML Writer Class Reference](https://phpdoc.moodledev.io/main/d4/d78/classhtml__writer.html) for further information. ::: diff --git a/versioned_docs/version-4.1/apis/plugintypes/assign/feedback.md b/versioned_docs/version-4.1/apis/plugintypes/assign/feedback.md index 90935e9fea..ce7dad1e04 100644 --- a/versioned_docs/version-4.1/apis/plugintypes/assign/feedback.md +++ b/versioned_docs/version-4.1/apis/plugintypes/assign/feedback.md @@ -19,7 +19,7 @@ An assignment feedback plugin can do many things including providing feedback to :::tip -For a good reference implementation, see the [file](https://github.com/moodle/moodle/tree/master/mod/assign/feedback/file) feedback plugin included with core because it uses most of the features of feedback plugins. +For a good reference implementation, see the [file](https://github.com/moodle/moodle/tree/main/mod/assign/feedback/file) feedback plugin included with core because it uses most of the features of feedback plugins. ::: diff --git a/versioned_docs/version-4.1/apis/plugintypes/assign/submission.md b/versioned_docs/version-4.1/apis/plugintypes/assign/submission.md index 10ca853116..6f153d1c2d 100644 --- a/versioned_docs/version-4.1/apis/plugintypes/assign/submission.md +++ b/versioned_docs/version-4.1/apis/plugintypes/assign/submission.md @@ -19,7 +19,7 @@ An assignment submission plugin is used to display custom form fields to a stude :::tip -For a good reference implementation, see the [onlinetext](https://github.com/moodle/moodle/tree/master/mod/assign/submission/onlinetext) submission plugin included with core because it uses most of the features of submission plugins. +For a good reference implementation, see the [onlinetext](https://github.com/moodle/moodle/tree/main/mod/assign/submission/onlinetext) submission plugin included with core because it uses most of the features of submission plugins. ::: diff --git a/versioned_docs/version-4.1/apis/plugintypes/tiny/testing.md b/versioned_docs/version-4.1/apis/plugintypes/tiny/testing.md index ebea115999..b08ca16a41 100644 --- a/versioned_docs/version-4.1/apis/plugintypes/tiny/testing.md +++ b/versioned_docs/version-4.1/apis/plugintypes/tiny/testing.md @@ -29,7 +29,7 @@ By using these tags appropriately, Moodle will ensure that TinyMCE is set as the ### Useful steps -A number of useful Behat steps have been defined in [TinyMCE Behat context](https://github.com/moodle/moodle/blob/master/lib/editor/tiny/tests/behat/behat_editor_tiny.php). +A number of useful Behat steps have been defined in [TinyMCE Behat context](https://github.com/moodle/moodle/blob/main/lib/editor/tiny/tests/behat/behat_editor_tiny.php). :::caution Use generic steps where possible @@ -39,7 +39,7 @@ Typically, when interacting with an Editor, you should use the _generic_ step de #### Generic steps to interact with editors -Most of these steps are defined in the [Behat Forms context](https://github.com/moodle/moodle/blob/master/lib/tests/behat/behat_forms.php) and this documentation should not be treated as a complete list, rather an indication of approaches that you may consider taking. +Most of these steps are defined in the [Behat Forms context](https://github.com/moodle/moodle/blob/main/lib/tests/behat/behat_forms.php) and this documentation should not be treated as a complete list, rather an indication of approaches that you may consider taking. ##### Setting content of a field diff --git a/versioned_docs/version-4.1/apis/subsystems/admin/index.md b/versioned_docs/version-4.1/apis/subsystems/admin/index.md index e1c5bffa45..ca5e03e18c 100644 --- a/versioned_docs/version-4.1/apis/subsystems/admin/index.md +++ b/versioned_docs/version-4.1/apis/subsystems/admin/index.md @@ -117,7 +117,7 @@ Few things to highlight: ## Individual settings -Let us look at a simple example: [mod/lesson/settings.php](https://github.com/moodle/moodle/blob/master/mod/lesson/settings.php). This is included by admin/settings/plugins.php, which has already created $settings, which is an admin_settingpage that we can add to. The file contains lots of lines that look a bit like: +Let us look at a simple example: [mod/lesson/settings.php](https://github.com/moodle/moodle/blob/main/mod/lesson/settings.php). This is included by admin/settings/plugins.php, which has already created $settings, which is an admin_settingpage that we can add to. The file contains lots of lines that look a bit like: ```php $settings->add(new admin_setting_configtext('mod_lesson/mediawidth', get_string('mediawidth', 'lesson'), diff --git a/versioned_docs/version-4.1/apis/subsystems/analytics/index.md b/versioned_docs/version-4.1/apis/subsystems/analytics/index.md index 37408390a8..820f4bdf5f 100644 --- a/versioned_docs/version-4.1/apis/subsystems/analytics/index.md +++ b/versioned_docs/version-4.1/apis/subsystems/analytics/index.md @@ -362,7 +362,7 @@ public function processes_user_data(); /** * SQL JOIN from a sample to users table. * - * More info in [https://github.com/moodle/moodle/blob/master/analytics/classes/local/analyser/base.php core_analytics\local\analyser\base]::join_sample_user + * More info in [https://github.com/moodle/moodle/blob/main/analytics/classes/local/analyser/base.php core_analytics\local\analyser\base]::join_sample_user * * @param string $sampletablealias The alias of the table with a sampleid field that will join with this SQL string * @return string diff --git a/versioned_docs/version-4.1/apis/subsystems/check/index.md b/versioned_docs/version-4.1/apis/subsystems/check/index.md index b40c6cb3dc..a3de677e56 100644 --- a/versioned_docs/version-4.1/apis/subsystems/check/index.md +++ b/versioned_docs/version-4.1/apis/subsystems/check/index.md @@ -214,7 +214,7 @@ class foobar_result extends \core\check\result { For a real example see: -https://github.com/moodle/moodle/blob/master/lib/classes/check/access/riskxss_result.php +https://github.com/moodle/moodle/blob/main/lib/classes/check/access/riskxss_result.php ### Asynchronous checks diff --git a/versioned_docs/version-4.1/apis/subsystems/external/writing-a-service.md b/versioned_docs/version-4.1/apis/subsystems/external/writing-a-service.md index 74b13ce776..326b8001bd 100644 --- a/versioned_docs/version-4.1/apis/subsystems/external/writing-a-service.md +++ b/versioned_docs/version-4.1/apis/subsystems/external/writing-a-service.md @@ -54,7 +54,7 @@ If _any_ group creation fails, the function will throw an exception, and no grou ## Technical specification -- **the core function the external function will call**: `groups_create_group()` from [/group/lib.php](http://github.com/moodle/moodle/tree/master/moodle/group/lib.php). +- **the core function the external function will call**: `groups_create_group()` from [/group/lib.php](http://github.com/moodle/moodle/tree/main/moodle/group/lib.php). - **the parameter types**: a list of object. This object are groups, with `id`/`name`/`courseid`. - **the returned value types**: a list of objects (groups) with their id. - **the user capabilities to check**: `moodle/course:managegroups` diff --git a/versioned_docs/version-4.1/apis/subsystems/form/index.md b/versioned_docs/version-4.1/apis/subsystems/form/index.md index b47115a0e2..4b9b92bee7 100644 --- a/versioned_docs/version-4.1/apis/subsystems/form/index.md +++ b/versioned_docs/version-4.1/apis/subsystems/form/index.md @@ -207,8 +207,8 @@ $mform->addElement( For a real-life example, see: -- [Custom element definition](https://github.com/moodle/moodle/blob/master/admin/tool/lp/classes/course_competency_rule_form_element.php) -- [Custom element usage](https://github.com/moodle/moodle/blob/master/admin/tool/lp/lib.php#L157-L161) +- [Custom element definition](https://github.com/moodle/moodle/blob/main/admin/tool/lp/classes/course_competency_rule_form_element.php) +- [Custom element usage](https://github.com/moodle/moodle/blob/main/admin/tool/lp/lib.php#L157-L161) ## Commonly used functions diff --git a/versioned_docs/version-4.1/apis/subsystems/form/usage.md b/versioned_docs/version-4.1/apis/subsystems/form/usage.md index 2c4a0124b0..0895194c2d 100644 --- a/versioned_docs/version-4.1/apis/subsystems/form/usage.md +++ b/versioned_docs/version-4.1/apis/subsystems/form/usage.md @@ -16,8 +16,8 @@ Moodle will attempt to provide a more complete tutorial in this documentation wh Some good examples of usage of the Forms API can be found at the following locations: -- [Course edit form - definition](https://github.com/moodle/moodle/blob/master/course/edit_form.php) -- [Course edit form - usage](https://github.com/moodle/moodle/blob/master/course/edit.php) +- [Course edit form - definition](https://github.com/moodle/moodle/blob/main/course/edit_form.php) +- [Course edit form - usage](https://github.com/moodle/moodle/blob/main/course/edit.php) ::: diff --git a/versioned_docs/version-4.1/apis/subsystems/group/index.md b/versioned_docs/version-4.1/apis/subsystems/group/index.md index c57a50d64d..5ea67e28dc 100644 --- a/versioned_docs/version-4.1/apis/subsystems/group/index.md +++ b/versioned_docs/version-4.1/apis/subsystems/group/index.md @@ -52,7 +52,7 @@ This is explained in more detail on the [Groups access control](https://docs.moo ## File locations -The Groups API is currently defined in [lib/grouplib.php](https://github.com/moodle/moodle/blob/master/lib/grouplib.php). This contains global functions which have the `groups_` prefix, for example: `groups_get_group()`. +The Groups API is currently defined in [lib/grouplib.php](https://github.com/moodle/moodle/blob/main/lib/grouplib.php). This contains global functions which have the `groups_` prefix, for example: `groups_get_group()`. ## Examples diff --git a/versioned_docs/version-4.1/devupdate.md b/versioned_docs/version-4.1/devupdate.md index e6774ed495..090c29256e 100644 --- a/versioned_docs/version-4.1/devupdate.md +++ b/versioned_docs/version-4.1/devupdate.md @@ -146,7 +146,7 @@ With the changes in boost to incorporate the primary and secondary navigation, t ``` - It is recommended to transition towards the secondary/tertiary navigation hierarchy to reduce user cognitive load and with a logical separation of components - - Secondary navigation can be added to the templates by following the example https://github.com/moodle/moodle/blob/master/theme/boost/templates/columns2.mustache#L64-L68 This leverages the secondary navigation class to generate it's content. + - Secondary navigation can be added to the templates by following the example https://github.com/moodle/moodle/blob/main/theme/boost/templates/columns2.mustache#L64-L68 This leverages the secondary navigation class to generate it's content. - Flat navigation classes have been marked for deprecation. Themes that leverage the flat_navigation will need to make the following changes in their plugins in order to use it - Account for the additional changes [theme changes](#theme-changes) - Indicate that they do not implement secondary navigation via the page's `set_secondary_navigation` function. It is recommended to set this within the root layout file, for example, columns2 @@ -838,7 +838,7 @@ More information about this project can be found in the [Site admin presets](htt From Moodle 4.0, Internet Explorer is no longer supported. See [MDL-73915](https://tracker.moodle.org/browse/MDL-73915) and [MDLSITE-6109](https://tracker.moodle.org/browse/MDLSITE-6109) for further information on this change. -This change means that changes built on 4.0 onwards (including the master branch) will be different to older versions of Moodle. +This change means that changes built on 4.0 onwards (including the main branch) will be different to older versions of Moodle. For plugin developers supporting multiple versions of Moodle using a single plugin version, the compiled JavaScript files are backwards compatible and will _work_ on all supported versions, however if you run the `grunt` command on multiple versions you will see unbuilt changes. Running grunt on all versions of Moodle is not necessary and this check can be safely disabled for Moodle versions 3.9 - 4.0, as long as only at least you run `grunt` against at least one version of Moodle. diff --git a/versioned_docs/version-4.1/guides/upgrade/index.md b/versioned_docs/version-4.1/guides/upgrade/index.md index f9c1d0fc2a..ae11c792e9 100644 --- a/versioned_docs/version-4.1/guides/upgrade/index.md +++ b/versioned_docs/version-4.1/guides/upgrade/index.md @@ -166,11 +166,11 @@ In Moodle core, one of the standard simple rules is not to make any database cha :::warning Advanced -Suppose, in order to fix a bug, you need to make a database change in the Moodle 4.0 stable branch (and the master branch targetting Moodle 4.1). The root of the problem is that people may upgrade their Moodle in three different ways, which +Suppose, in order to fix a bug, you need to make a database change in the Moodle 4.0 stable branch (and the main branch targetting Moodle 4.1). The root of the problem is that people may upgrade their Moodle in three different ways, which - Upgrade from \<=4.0.2 to 4.0.3 - this executes the upgrade script on the 4.0 branch. -- Upgrade from \<=4.0.2 directly to >=4.1 - this executes the upgrade script on the master branch. -- Upgrade from 4.0.3 to >=4.1 - in this case, you must ensure that the upgrade on master is not executed. +- Upgrade from \<=4.0.2 directly to >=4.1 - this executes the upgrade script on the main branch. +- Upgrade from 4.0.3 to >=4.1 - in this case, you must ensure that the upgrade on main is not executed. The normal way to do this is ensure that your database upgrade is idempotent. That is, it does not matter if you do it twice. So for example, instead of doing diff --git a/versioned_docs/version-4.2/apis.md b/versioned_docs/version-4.2/apis.md index 9045fe5289..598b17052c 100644 --- a/versioned_docs/version-4.2/apis.md +++ b/versioned_docs/version-4.2/apis.md @@ -78,7 +78,7 @@ The [Backup API](./apis/subsystems/backup/index.md) defines exactly how to conve ### Cache API (cache) -The [The Moodle Universal Cache (MUC)](https://docs.moodle.org/dev/The_Moodle_Universal_Cache_(MUC)) is the structure for storing cache data within Moodle. [Cache API](https://docs.moodle.org/dev/Cache_API) explains some of what is needed to use a cache in your code. +The [The Moodle Universal Cache (MUC)](https://docs.moodle.org/dev/The_Moodle_Universal_Cache_(MUC)) is the structure for storing cache data within Moodle. [Cache API](/docs/apis/subsystems/muc/index.md) explains some of what is needed to use a cache in your code. ### Calendar API (calendar) @@ -135,7 +135,7 @@ The [Lock API](./apis/core/lock/index.md) lets you synchronise processing betwee ### Message API (message) -The [Message API](https://docs.moodle.org/dev/Message_API) lets you post messages to users. They decide how they want to receive them. +The [Message API](/docs/apis/core/message/index.md) lets you post messages to users. They decide how they want to receive them. ### Media API (media) @@ -173,7 +173,7 @@ The [Rating API](https://docs.moodle.org/dev/Rating_API) lets you create AJAX ra ### Report builder API (reportbuilder) -The [Report builder API](../../docs/apis/core/reportbuilder/index.md) allows you to create reports in your plugin, as well as providing custom reporting data which users can use to build their own reports. +The [Report builder API](/docs/apis/core/reportbuilder/index.md) allows you to create reports in your plugin, as well as providing custom reporting data which users can use to build their own reports. ### RSS API (rss) @@ -213,7 +213,7 @@ The [https://docs.moodle.org/dev/OpenBadges_User_Documentation Badges] user docu ### Custom fields API (customfield) -The [Custom fields API](../../docs/apis/core/customfields/index.md) allows you to configure and add custom fields for different entities +The [Custom fields API](/docs/apis/core/customfields/index.md) allows you to configure and add custom fields for different entities ## Activity module APIs diff --git a/versioned_docs/version-4.2/apis/_files/upgrade-txt.mdx b/versioned_docs/version-4.2/apis/_files/upgrade-txt.mdx index 5397e05ba0..a29d8cd37f 100644 --- a/versioned_docs/version-4.2/apis/_files/upgrade-txt.mdx +++ b/versioned_docs/version-4.2/apis/_files/upgrade-txt.mdx @@ -1,20 +1,20 @@ Each component and subsystem may make use of an `upgrade.txt` file in the top level folder. A section title is used to identify the Moodle version where the change was introduced, and significant changes for that version relating to that component or subsystem are noted. -For example, given an API change is applied for the upcoming Moodle version 4.1 which is still in the **master** branch (4.1dev), the version number on the `upgrade.txt`'s section title will be set to **4.1**. +For example, given an API change is applied for the upcoming Moodle version 4.1 which is still in the **main** branch (4.1dev), the version number on the `upgrade.txt`'s section title will be set to **4.1**. -```txt title="Example 1: Change applied to the master branch" +```txt title="Example 1: Change applied to the main branch" == 4.1 == An API change to empower educators! ``` #### Changes applied to multiple branches -When changes are integrated to multiple branches, for example a stable version and the master branch, then the relevant versions used to describe the change in the `upgrade.txt` file should be the next version to be released _for each branch_. The **master** branch should always use the next major version. +When changes are integrated to multiple branches, for example a stable version and the main branch, then the relevant versions used to describe the change in the `upgrade.txt` file should be the next version to be released _for each branch_. The **main** branch should always use the next major version. -For example, if a change is applied to the **MOODLE_400_STABLE** during the development of Moodle 4.0.2, and the **master** branch during the development of Moodle 4.1, then the relevant versions will be **4.0.2** and **4.1**, respectively. The section title for the **master** branch will be the same as the one in Example 1. The section title for the **MOODLE_400_STABLE** branch will indicate the next upcoming minor version (4.0.2 in this case): +For example, if a change is applied to the **MOODLE_400_STABLE** during the development of Moodle 4.0.2, and the **main** branch during the development of Moodle 4.1, then the relevant versions will be **4.0.2** and **4.1**, respectively. The section title for the **main** branch will be the same as the one in Example 1. The section title for the **MOODLE_400_STABLE** branch will indicate the next upcoming minor version (4.0.2 in this case): -```txt title="Example 2: Patch applied to master and MOODLE_400_STABLE" +```txt title="Example 2: Patch applied to main and MOODLE_400_STABLE" == 4.0.2 == An API change to empower educators! ``` @@ -23,7 +23,7 @@ An API change to empower educators! Multiple versions within the section title are **not** allowed. However, developers may note the Moodle versions that the change applies to within the upgrade note text itself. -```txt title="Example 3a: master (4.1dev)" +```txt title="Example 3a: main (4.1dev)" == 4.1 == An API change to empower educators! (This was fixed in 4.1 and 4.0.2) ``` @@ -43,9 +43,9 @@ An API change to empower educators! When Moodle is developing two major versions in parallel, for example Moodle 3.11.0, and Moodle 4.0.0, then the version in the earliest of the major version development branches will be used for both branches. -For example, given we are in a parallel development situation with **MOODLE_311_STABLE** (3.11dev) and **master** (4.0dev), with Moodle 3.11 as the next upcoming major Moodle version. If an API change is applied to **MOODLE_311_STABLE**, the version number on the section title will be **3.11** for both **master** and **MOODLE_400_STABLE** branches. +For example, given we are in a parallel development situation with **MOODLE_311_STABLE** (3.11dev) and **main** (4.0dev), with Moodle 3.11 as the next upcoming major Moodle version. If an API change is applied to **MOODLE_311_STABLE**, the version number on the section title will be **3.11** for both **main** and **MOODLE_400_STABLE** branches. -```txt title="Example 4a: master (4.0dev)" +```txt title="Example 4a: main (4.0dev)" == 3.11 == An API change to empower educators! ``` diff --git a/versioned_docs/version-4.2/apis/core/htmlwriter/index.md b/versioned_docs/version-4.2/apis/core/htmlwriter/index.md index 2a1188580f..4740676734 100644 --- a/versioned_docs/version-4.2/apis/core/htmlwriter/index.md +++ b/versioned_docs/version-4.2/apis/core/htmlwriter/index.md @@ -16,7 +16,7 @@ Please consider using [templates](../../../guides/templates/index.md) as an alte :::note -There is no documentation for most of this class. Please read [HTML Writer Class Reference](https://phpdoc.moodledev.io/master/d4/d78/classhtml__writer.html) for further information. +There is no documentation for most of this class. Please read [HTML Writer Class Reference](https://phpdoc.moodledev.io/main/d4/d78/classhtml__writer.html) for further information. ::: diff --git a/versioned_docs/version-4.2/apis/plugintypes/assign/feedback.md b/versioned_docs/version-4.2/apis/plugintypes/assign/feedback.md index 90935e9fea..ce7dad1e04 100644 --- a/versioned_docs/version-4.2/apis/plugintypes/assign/feedback.md +++ b/versioned_docs/version-4.2/apis/plugintypes/assign/feedback.md @@ -19,7 +19,7 @@ An assignment feedback plugin can do many things including providing feedback to :::tip -For a good reference implementation, see the [file](https://github.com/moodle/moodle/tree/master/mod/assign/feedback/file) feedback plugin included with core because it uses most of the features of feedback plugins. +For a good reference implementation, see the [file](https://github.com/moodle/moodle/tree/main/mod/assign/feedback/file) feedback plugin included with core because it uses most of the features of feedback plugins. ::: diff --git a/versioned_docs/version-4.2/apis/plugintypes/assign/submission.md b/versioned_docs/version-4.2/apis/plugintypes/assign/submission.md index 10ca853116..6f153d1c2d 100644 --- a/versioned_docs/version-4.2/apis/plugintypes/assign/submission.md +++ b/versioned_docs/version-4.2/apis/plugintypes/assign/submission.md @@ -19,7 +19,7 @@ An assignment submission plugin is used to display custom form fields to a stude :::tip -For a good reference implementation, see the [onlinetext](https://github.com/moodle/moodle/tree/master/mod/assign/submission/onlinetext) submission plugin included with core because it uses most of the features of submission plugins. +For a good reference implementation, see the [onlinetext](https://github.com/moodle/moodle/tree/main/mod/assign/submission/onlinetext) submission plugin included with core because it uses most of the features of submission plugins. ::: diff --git a/versioned_docs/version-4.2/apis/plugintypes/tiny/testing.md b/versioned_docs/version-4.2/apis/plugintypes/tiny/testing.md index ebea115999..b08ca16a41 100644 --- a/versioned_docs/version-4.2/apis/plugintypes/tiny/testing.md +++ b/versioned_docs/version-4.2/apis/plugintypes/tiny/testing.md @@ -29,7 +29,7 @@ By using these tags appropriately, Moodle will ensure that TinyMCE is set as the ### Useful steps -A number of useful Behat steps have been defined in [TinyMCE Behat context](https://github.com/moodle/moodle/blob/master/lib/editor/tiny/tests/behat/behat_editor_tiny.php). +A number of useful Behat steps have been defined in [TinyMCE Behat context](https://github.com/moodle/moodle/blob/main/lib/editor/tiny/tests/behat/behat_editor_tiny.php). :::caution Use generic steps where possible @@ -39,7 +39,7 @@ Typically, when interacting with an Editor, you should use the _generic_ step de #### Generic steps to interact with editors -Most of these steps are defined in the [Behat Forms context](https://github.com/moodle/moodle/blob/master/lib/tests/behat/behat_forms.php) and this documentation should not be treated as a complete list, rather an indication of approaches that you may consider taking. +Most of these steps are defined in the [Behat Forms context](https://github.com/moodle/moodle/blob/main/lib/tests/behat/behat_forms.php) and this documentation should not be treated as a complete list, rather an indication of approaches that you may consider taking. ##### Setting content of a field diff --git a/versioned_docs/version-4.2/apis/subsystems/admin/index.md b/versioned_docs/version-4.2/apis/subsystems/admin/index.md index e1c5bffa45..ca5e03e18c 100644 --- a/versioned_docs/version-4.2/apis/subsystems/admin/index.md +++ b/versioned_docs/version-4.2/apis/subsystems/admin/index.md @@ -117,7 +117,7 @@ Few things to highlight: ## Individual settings -Let us look at a simple example: [mod/lesson/settings.php](https://github.com/moodle/moodle/blob/master/mod/lesson/settings.php). This is included by admin/settings/plugins.php, which has already created $settings, which is an admin_settingpage that we can add to. The file contains lots of lines that look a bit like: +Let us look at a simple example: [mod/lesson/settings.php](https://github.com/moodle/moodle/blob/main/mod/lesson/settings.php). This is included by admin/settings/plugins.php, which has already created $settings, which is an admin_settingpage that we can add to. The file contains lots of lines that look a bit like: ```php $settings->add(new admin_setting_configtext('mod_lesson/mediawidth', get_string('mediawidth', 'lesson'), diff --git a/versioned_docs/version-4.2/apis/subsystems/analytics/index.md b/versioned_docs/version-4.2/apis/subsystems/analytics/index.md index 37408390a8..820f4bdf5f 100644 --- a/versioned_docs/version-4.2/apis/subsystems/analytics/index.md +++ b/versioned_docs/version-4.2/apis/subsystems/analytics/index.md @@ -362,7 +362,7 @@ public function processes_user_data(); /** * SQL JOIN from a sample to users table. * - * More info in [https://github.com/moodle/moodle/blob/master/analytics/classes/local/analyser/base.php core_analytics\local\analyser\base]::join_sample_user + * More info in [https://github.com/moodle/moodle/blob/main/analytics/classes/local/analyser/base.php core_analytics\local\analyser\base]::join_sample_user * * @param string $sampletablealias The alias of the table with a sampleid field that will join with this SQL string * @return string diff --git a/versioned_docs/version-4.2/apis/subsystems/check/index.md b/versioned_docs/version-4.2/apis/subsystems/check/index.md index 3b26541531..b71dbbfe30 100644 --- a/versioned_docs/version-4.2/apis/subsystems/check/index.md +++ b/versioned_docs/version-4.2/apis/subsystems/check/index.md @@ -215,7 +215,7 @@ class foobar_result extends \core\check\result { For a real example see: -https://github.com/moodle/moodle/blob/master/lib/classes/check/access/riskxss_result.php +https://github.com/moodle/moodle/blob/main/lib/classes/check/access/riskxss_result.php ### Asynchronous checks diff --git a/versioned_docs/version-4.2/apis/subsystems/external/writing-a-service.md b/versioned_docs/version-4.2/apis/subsystems/external/writing-a-service.md index ea5a5627ee..5e60330815 100644 --- a/versioned_docs/version-4.2/apis/subsystems/external/writing-a-service.md +++ b/versioned_docs/version-4.2/apis/subsystems/external/writing-a-service.md @@ -54,7 +54,7 @@ If _any_ group creation fails, the function will throw an exception, and no grou ## Technical specification -- **the core function the external function will call**: `groups_create_group()` from [/group/lib.php](http://github.com/moodle/moodle/tree/master/moodle/group/lib.php). +- **the core function the external function will call**: `groups_create_group()` from [/group/lib.php](http://github.com/moodle/moodle/tree/main/moodle/group/lib.php). - **the parameter types**: a list of object. This object are groups, with `id`/`name`/`courseid`. - **the returned value types**: a list of objects (groups) with their id. - **the user capabilities to check**: `moodle/course:managegroups` diff --git a/versioned_docs/version-4.2/apis/subsystems/form/index.md b/versioned_docs/version-4.2/apis/subsystems/form/index.md index b4121bfdf5..e28b754785 100644 --- a/versioned_docs/version-4.2/apis/subsystems/form/index.md +++ b/versioned_docs/version-4.2/apis/subsystems/form/index.md @@ -207,8 +207,8 @@ $mform->addElement( For a real-life example, see: -- [Custom element definition](https://github.com/moodle/moodle/blob/master/admin/tool/lp/classes/course_competency_rule_form_element.php) -- [Custom element usage](https://github.com/moodle/moodle/blob/master/admin/tool/lp/lib.php#L157-L161) +- [Custom element definition](https://github.com/moodle/moodle/blob/main/admin/tool/lp/classes/course_competency_rule_form_element.php) +- [Custom element usage](https://github.com/moodle/moodle/blob/main/admin/tool/lp/lib.php#L157-L161) ## Commonly used functions diff --git a/versioned_docs/version-4.2/apis/subsystems/form/usage/index.md b/versioned_docs/version-4.2/apis/subsystems/form/usage/index.md index 8d374eb38b..cb9d4fc80f 100644 --- a/versioned_docs/version-4.2/apis/subsystems/form/usage/index.md +++ b/versioned_docs/version-4.2/apis/subsystems/form/usage/index.md @@ -16,8 +16,8 @@ Moodle will attempt to provide a more complete tutorial in this documentation wh Some good examples of usage of the Forms API can be found at the following locations: -- [Course edit form - definition](https://github.com/moodle/moodle/blob/master/course/edit_form.php) -- [Course edit form - usage](https://github.com/moodle/moodle/blob/master/course/edit.php) +- [Course edit form - definition](https://github.com/moodle/moodle/blob/main/course/edit_form.php) +- [Course edit form - usage](https://github.com/moodle/moodle/blob/main/course/edit.php) ::: diff --git a/versioned_docs/version-4.2/apis/subsystems/group/index.md b/versioned_docs/version-4.2/apis/subsystems/group/index.md index 94ebe9f0c0..bf670c5d34 100644 --- a/versioned_docs/version-4.2/apis/subsystems/group/index.md +++ b/versioned_docs/version-4.2/apis/subsystems/group/index.md @@ -74,7 +74,7 @@ The core API functions in groupslib such as `groups_get_all_groups()` and `group ## File locations -The Groups API is currently defined in [lib/grouplib.php](https://github.com/moodle/moodle/blob/master/lib/grouplib.php). This contains global functions which have the `groups_` prefix, for example: `groups_get_group()`. +The Groups API is currently defined in [lib/grouplib.php](https://github.com/moodle/moodle/blob/main/lib/grouplib.php). This contains global functions which have the `groups_` prefix, for example: `groups_get_group()`. ## Examples diff --git a/versioned_docs/version-4.2/apis/subsystems/task/index.md b/versioned_docs/version-4.2/apis/subsystems/task/index.md index 9bb1325e2f..7d41abded8 100644 --- a/versioned_docs/version-4.2/apis/subsystems/task/index.md +++ b/versioned_docs/version-4.2/apis/subsystems/task/index.md @@ -65,11 +65,11 @@ If you catch an exception, then you become responsible for things that the task For example, it is important to log all the details of the error, so problems can be investigated and fixed. The helper function `mtrace_exception` makes this easier. Also, you need to consider: if something has gone wrong with part of the processing, but other parts succeeded, should the overall state of the task run be success or failure? It will depend on how the task works, but you may need to ensure that the task -ends by throwing an exception if any part failed. There is a an example of all this in the [`\quiz_statistics\task\recalculate`](https://github.com/moodle/moodle/blob/master/mod/quiz/report/statistics/classes/task/recalculate.php). +ends by throwing an exception if any part failed. There is a an example of all this in the [`\quiz_statistics\task\recalculate`](https://github.com/moodle/moodle/blob/main/mod/quiz/report/statistics/classes/task/recalculate.php). ### Caches -Historically many Moodle APIs have used static caches. Whilst many of these have been replaced by the [Moodle Universal Cache](https://docs.moodle.org/dev/Cache_API), which can be cleared between runs, it is not possible to guarantee that this is always the case. +Historically many Moodle APIs have used static caches. Whilst many of these have been replaced by the [Moodle Universal Cache](/docs/apis/subsystems/muc/index.md), which can be cleared between runs, it is not possible to guarantee that this is always the case. When working with long-running tasks, you may need to consider caching - this applies to both scheduled, and adhoc, tasks. This is particularly true for tasks related to enrolment. diff --git a/versioned_docs/version-4.2/devupdate.md b/versioned_docs/version-4.2/devupdate.md index 83b06a58c2..35b26235c4 100644 --- a/versioned_docs/version-4.2/devupdate.md +++ b/versioned_docs/version-4.2/devupdate.md @@ -103,7 +103,7 @@ Therefore, if you have made customisations to the core quiz code, you will have (reports or access rules) you may have a small amount of work to do. I will write a more coherent summary once the changes are complete, but -[mod/quiz/upgrade.txt](https://github.com/moodle/moodle/blob/master/mod/quiz/upgrade.txt) lists all the changes so far. +[mod/quiz/upgrade.txt](https://github.com/moodle/moodle/blob/main/mod/quiz/upgrade.txt) lists all the changes so far. ### Developer tip - handling changes to base class names, while supporting multiple Moodle versions diff --git a/versioned_docs/version-4.2/guides/git/index.md b/versioned_docs/version-4.2/guides/git/index.md index 1af1f4ce58..b596e41832 100644 --- a/versioned_docs/version-4.2/guides/git/index.md +++ b/versioned_docs/version-4.2/guides/git/index.md @@ -101,7 +101,7 @@ This command does several jobs for you: - Creates a new folder - Initialises a new local Git repository - Sets your GitHub repository as the remote repository called 'origin' -- Makes a local checkout of the branch 'master' +- Makes a local checkout of the branch 'main' :::tip [MDK](/general/development/tools/mdk) features many commands that aid in the creation and management of your Moodle branches. If you haven't checked it out already, see how MDK can streamline your Moodle development. @@ -109,7 +109,7 @@ This command does several jobs for you: ## Keeping your public repository up-to-date -Your fork at GitHub is not updated automatically. To keep it synced with the upstream Moodle repository, you have to fetch the recent changes from the official moodle.git repository. To avoid conflicts, it is strongly recommended that you never modify the standard Moodle branches. Never commit directly into `master` and `MOODLE_XXX_STABLE` branches, but instead create topic branches to work on. In Git terminology, the `master` branch and `MOODLE_XXX_STABLE` branches should always be fast-forwardable. +Your fork at GitHub is not updated automatically. To keep it synced with the upstream Moodle repository, you have to fetch the recent changes from the official moodle.git repository. To avoid conflicts, it is strongly recommended that you never modify the standard Moodle branches. Never commit directly into `main` and `MOODLE_XXX_STABLE` branches, but instead create topic branches to work on. In Git terminology, the `main` branch and `MOODLE_XXX_STABLE` branches should always be fast-forwardable. ![git-sync-github.png](./_index/git-sync-github.png) @@ -126,13 +126,13 @@ The following commands can be used to keep the your forked Moodle branches at yo ``` #!/bin/bash git fetch upstream -for BRANCH in MOODLE_{19..39}_STABLE MOODLE_{310..311}_STABLE MOODLE_{400..401}_STABLE master; do +for BRANCH in MOODLE_{19..39}_STABLE MOODLE_{310..311}_STABLE MOODLE_{400..401}_STABLE main; do git push origin refs/remotes/upstream/$BRANCH:refs/heads/$BRANCH done ``` :::caution -Never commit directly into `master` and `MOODLE_XXX_STABLE` branches +Never commit directly into `main` and `MOODLE_XXX_STABLE` branches ::: :::tip @@ -173,7 +173,7 @@ git push origin MOODLE_99_STABLE:MOODLE_99_STABLE The above code will create a new copy of the `MOODLE_99_STABLE` branch in your local repository. If you do not need to keep a local copy of the new branch (probably the case), you can remove it from your local repository as follows: ``` -git checkout master +git checkout main git branch -D MOODLE_99_STABLE ``` @@ -183,10 +183,10 @@ git branch -D MOODLE_99_STABLE As mentioned earlier, you never work on standard Moodle branches directly. Every time you are going to edit something, switch to a local branch. Fork the local branch off Moodle's standard branch that you think it should be eventually merged to. -For example, if you are working on a patch for **4.1**, fork the branch off `MOODLE_401_STABLE`. Patches for the next [major version](https://docs.moodle.org/dev/Moodle_versions) should be based on the `master` branch. +For example, if you are working on a patch for **4.1**, fork the branch off `MOODLE_401_STABLE`. Patches for the next [major version](https://docs.moodle.org/dev/Moodle_versions) should be based on the `main` branch. ``` -git checkout -b MDL-xxxxx-master_brief_name origin/master +git checkout -b MDL-xxxxx-main_brief_name origin/main ``` If you forget to specify the branch you want to fork from, the new branch will be based on the currently checked-out branch. It is recommended you always specify this. @@ -218,7 +218,7 @@ git log Your local branch changes may consist of several commits. Once you are happy with it, and you have checked it against Moodle's [Coding styles](/general/development/policies/codingstyle), publish your changes by pushing to your public repository. ``` -git push origin MDL-xxxxx-master_brief_name +git push origin MDL-xxxxx-main_brief_name ``` Now your branch is published and you can ask Moodle core developers to review it and eventually integrate it into Moodle's main repository. @@ -231,10 +231,10 @@ There are a couple of ways this can be achieved. #### Reset all changes and commit again -The following command will preserve your changes, but all commits on top of `master` branch will be gone and become **unstaged** and ready to be added and committed again. +The following command will preserve your changes, but all commits on top of `main` branch will be gone and become **unstaged** and ready to be added and committed again. ``` -git reset --mixed origin/master +git reset --mixed origin/main ``` #### Rebase your changes @@ -247,12 +247,12 @@ Rebase your branch using the following command: git rebase --interactive ``` -Whichever option you chose, you have "rewritten history". If you had already pushed your branch to your remote repository, you may encounter issues when trying to push the updated branch. If you try `git push MDL-xxxxx-master_brief_name` you will get an error message suggesting you to `force push`. +Whichever option you chose, you have "rewritten history". If you had already pushed your branch to your remote repository, you may encounter issues when trying to push the updated branch. If you try `git push MDL-xxxxx-main_brief_name` you will get an error message suggesting you to `force push`. To force push the changed commits use: ``` -git push -f origin MDL-xxxxx-master_brief_name +git push -f origin MDL-xxxxx-main_brief_name ``` If an error occurs because you are still using the git protocol (read only), use this command: @@ -273,16 +273,16 @@ After some time contributing to Moodle, you will have accumulated many branches, ``` git fetch upstream -git branch --merged upstream/master +git branch --merged upstream/main git branch --merged upstream/MOODLE_XXX_STABLE ``` #### Pruning local branches -The `git fetch upstream` command fetches the changes from your upstream repository (remember that `git fetch` does not modify your working directory, so it is safe to run it whenever). The `git branch --merged` commands displays all branches that are merged into the Moodle's upstream `master` branch and `MOODLE_XXX_STABLE` branch, respectively. To delete these local branches, use: +The `git fetch upstream` command fetches the changes from your upstream repository (remember that `git fetch` does not modify your working directory, so it is safe to run it whenever). The `git branch --merged` commands displays all branches that are merged into the Moodle's upstream `main` branch and `MOODLE_XXX_STABLE` branch, respectively. To delete these local branches, use: ``` -git branch -d MDL-xxxxx-master_accepted_branch +git branch -d MDL-xxxxx-main_accepted_branch ``` #### Pruning remote branches @@ -292,7 +292,7 @@ A similar approach can be used to check the branches published at your origin re ``` git fetch origin git fetch upstream -git branch -r --merged upstream/master +git branch -r --merged upstream/main git branch -r --merged upstream/MOODLE_XXX_STABLE ``` @@ -301,7 +301,7 @@ The `git fetch upstream` command makes sure that you have all your branches from To delete a branch on your origin repository, use: ``` -git push origin :MDL-xxxxx-master_branch_to_delete +git push origin :MDL-xxxxx-main_branch_to_delete ``` This syntax may look unfamiliar, however it is pretty logical. The general syntax of the `git push` command is: @@ -359,7 +359,7 @@ Once you have acquired the code and are ready to review it, reference Moodle's [ Rebasing is a process when you cut off the branch from its current start point and transplant it to another point. Let us assume the following history exists: ```mermaid -%%{init: { 'gitGraph': {'mainBranchName': 'master', 'mainBranchOrder': 2 }} }%% +%%{init: { 'gitGraph': {'mainBranchName': 'main', 'mainBranchOrder': 2 }} }%% gitGraph commit id: "D" commit id: "E" @@ -367,20 +367,20 @@ gitGraph commit id: "A" commit id: "B" commit id: "C" - checkout master + checkout main commit id: "F" commit id: "G" ``` -The result of the command `git rebase master topic` would transplant the `topic` branch on top of the `master` branch and look like this: +The result of the command `git rebase main topic` would transplant the `topic` branch on top of the `main` branch and look like this: ```mermaid -%%{init: { 'gitGraph': {'mainBranchName': 'master', 'mainBranchOrder': 2 }} }%% +%%{init: { 'gitGraph': {'mainBranchName': 'main', 'mainBranchOrder': 2 }} }%% gitGraph commit id: "D" commit id: "E" - checkout master + checkout main commit id: "F" commit id: "G" branch topic order: 1 @@ -393,10 +393,10 @@ gitGraph You may be asked to rebase your branch if the submitted branch was based on an outdated commit. Consider this example: -On Tuesday, we create a new topic branch, forked off the upstream `master` branch. On Wednesday, the upstream `master` branch is updated with all the changes from the last integration cycle. To make our branch easier to integrate, we rebase our branch against the newly updated `master` branch. +On Tuesday, we create a new topic branch, forked off the upstream `main` branch. On Wednesday, the upstream `main` branch is updated with all the changes from the last integration cycle. To make our branch easier to integrate, we rebase our branch against the newly updated `main` branch. ``` -git rebase master MDL-xxxxx-master_topic_branch +git rebase main MDL-xxxxx-main_topic_branch ``` Note that rebasing effectively rewrites the history of the branch. **Do not rebase the branch if there is a chance that somebody has already forked it and based their own branch on it.** For this reason, many Git tutorials discourage from rebasing any branch that has been published. @@ -419,7 +419,7 @@ git rebase --continue Most bugs are fixed on each stable branch (e.g. `MOODLE_400_STABLE`, `MOODLE_311_STABLE`). If you are working on an fix based on one of these branches, it is possible you will need to prepare a patch for other affected stable branches too. -In Moodle, we separately maintain the stable branches and the current development branch (master). We do not merge stable branches into the master one. Typically, the contributor prepares at least two branches: one with the fix for the affected stable branch(es), and one with the fix for the master branch. +In Moodle, we separately maintain the stable branches and the current development branch (main). We do not merge stable branches into the main one. Typically, the contributor prepares at least two branches: one with the fix for the affected stable branch(es), and one with the fix for the main branch. Let's assume you have a patch prepared, based on `MOODLE_400_STABLE`, called `MDL-xxxxx-400_topic`. It is possible to apply this patch to other stable branches. There are a few ways we could achieve this. @@ -428,18 +428,18 @@ Let's assume you have a patch prepared, based on `MOODLE_400_STABLE`, called `MD Let's assume we have two local Git repositories: 1. `~/public_html/moodle_400` containing a local installation of Moodle 4.0, and -2. `~/public_html/moodle_master` containing a local installation of the most recent development version of Moodle. +2. `~/public_html/moodle_main` containing a local installation of the most recent development version of Moodle. -They both use your public repository at github.com as the origin. You have a branch in `moodle_400` called `MDL-xxxxx-400_topic` that was forked off `MOODLE_400_STABLE`. It contains one commit. Now, you want to apply this commit to a new branch in `moodle_master` called `MDL-xxxxx-master_topic`. +They both use your public repository at github.com as the origin. You have a branch in `moodle_400` called `MDL-xxxxx-400_topic` that was forked off `MOODLE_400_STABLE`. It contains one commit. Now, you want to apply this commit to a new branch in `moodle_main` called `MDL-xxxxx-main_topic`. ``` -cd ~/public_html/moodle_master -git checkout -b MDL-xxxxx-master_topic origin/master +cd ~/public_html/moodle_main +git checkout -b MDL-xxxxx-main_topic origin/main git fetch ../moodle_400 MDL-xxxxx-400_topic git cherry-pick FETCH_HEAD ``` -1. The `git checkout -b MDL-xxxxx-master_topic origin/master` command creates new local branch, forked off `master`. +1. The `git checkout -b MDL-xxxxx-main_topic origin/main` command creates new local branch, forked off `main`. 2. The `git fetch ../moodle_400 MDL-xxxxx-400_topic` command fetches all data needed to apply the topic branch, and sets the pointer to the tip of that branch with `FETCH_HEAD` as a symbolic reference. 3. The `git cherry-pick FETCH_HEAD` command picks the tip of the branch (the top-most commit) and tries to apply it on the current branch. @@ -464,8 +464,8 @@ The `git format-patch -o .patches MOODLE_400_STABLE..MDL-xxxxx-400_topic` comman In this example, we will apply them to another repository. ``` -cd ~/public_html/moodle_master -git checkout -b MDL-xxxxx-master_topic origin/master +cd ~/public_html/moodle_main +git checkout -b MDL-xxxxx-main_topic origin/main git am -3 ../moodle_400/.patches/* ``` diff --git a/versioned_docs/version-4.2/guides/upgrade/index.md b/versioned_docs/version-4.2/guides/upgrade/index.md index f9c1d0fc2a..ae11c792e9 100644 --- a/versioned_docs/version-4.2/guides/upgrade/index.md +++ b/versioned_docs/version-4.2/guides/upgrade/index.md @@ -166,11 +166,11 @@ In Moodle core, one of the standard simple rules is not to make any database cha :::warning Advanced -Suppose, in order to fix a bug, you need to make a database change in the Moodle 4.0 stable branch (and the master branch targetting Moodle 4.1). The root of the problem is that people may upgrade their Moodle in three different ways, which +Suppose, in order to fix a bug, you need to make a database change in the Moodle 4.0 stable branch (and the main branch targetting Moodle 4.1). The root of the problem is that people may upgrade their Moodle in three different ways, which - Upgrade from \<=4.0.2 to 4.0.3 - this executes the upgrade script on the 4.0 branch. -- Upgrade from \<=4.0.2 directly to >=4.1 - this executes the upgrade script on the master branch. -- Upgrade from 4.0.3 to >=4.1 - in this case, you must ensure that the upgrade on master is not executed. +- Upgrade from \<=4.0.2 directly to >=4.1 - this executes the upgrade script on the main branch. +- Upgrade from 4.0.3 to >=4.1 - in this case, you must ensure that the upgrade on main is not executed. The normal way to do this is ensure that your database upgrade is idempotent. That is, it does not matter if you do it twice. So for example, instead of doing diff --git a/versioned_docs/version-4.3/apis.md b/versioned_docs/version-4.3/apis.md index 5f22ee85c6..7b6958b52a 100644 --- a/versioned_docs/version-4.3/apis.md +++ b/versioned_docs/version-4.3/apis.md @@ -78,7 +78,7 @@ The [Backup API](./apis/subsystems/backup/index.md) defines exactly how to conve ### Cache API (cache) -The [The Moodle Universal Cache (MUC)](https://docs.moodle.org/dev/The_Moodle_Universal_Cache_(MUC)) is the structure for storing cache data within Moodle. [Cache API](https://docs.moodle.org/dev/Cache_API) explains some of what is needed to use a cache in your code. +The [The Moodle Universal Cache (MUC)](https://docs.moodle.org/dev/The_Moodle_Universal_Cache_(MUC)) is the structure for storing cache data within Moodle. [Cache API](/docs/apis/subsystems/muc/index.md) explains some of what is needed to use a cache in your code. ### Calendar API (calendar) diff --git a/versioned_docs/version-4.3/apis/_files/upgrade-txt.mdx b/versioned_docs/version-4.3/apis/_files/upgrade-txt.mdx index 5397e05ba0..a29d8cd37f 100644 --- a/versioned_docs/version-4.3/apis/_files/upgrade-txt.mdx +++ b/versioned_docs/version-4.3/apis/_files/upgrade-txt.mdx @@ -1,20 +1,20 @@ Each component and subsystem may make use of an `upgrade.txt` file in the top level folder. A section title is used to identify the Moodle version where the change was introduced, and significant changes for that version relating to that component or subsystem are noted. -For example, given an API change is applied for the upcoming Moodle version 4.1 which is still in the **master** branch (4.1dev), the version number on the `upgrade.txt`'s section title will be set to **4.1**. +For example, given an API change is applied for the upcoming Moodle version 4.1 which is still in the **main** branch (4.1dev), the version number on the `upgrade.txt`'s section title will be set to **4.1**. -```txt title="Example 1: Change applied to the master branch" +```txt title="Example 1: Change applied to the main branch" == 4.1 == An API change to empower educators! ``` #### Changes applied to multiple branches -When changes are integrated to multiple branches, for example a stable version and the master branch, then the relevant versions used to describe the change in the `upgrade.txt` file should be the next version to be released _for each branch_. The **master** branch should always use the next major version. +When changes are integrated to multiple branches, for example a stable version and the main branch, then the relevant versions used to describe the change in the `upgrade.txt` file should be the next version to be released _for each branch_. The **main** branch should always use the next major version. -For example, if a change is applied to the **MOODLE_400_STABLE** during the development of Moodle 4.0.2, and the **master** branch during the development of Moodle 4.1, then the relevant versions will be **4.0.2** and **4.1**, respectively. The section title for the **master** branch will be the same as the one in Example 1. The section title for the **MOODLE_400_STABLE** branch will indicate the next upcoming minor version (4.0.2 in this case): +For example, if a change is applied to the **MOODLE_400_STABLE** during the development of Moodle 4.0.2, and the **main** branch during the development of Moodle 4.1, then the relevant versions will be **4.0.2** and **4.1**, respectively. The section title for the **main** branch will be the same as the one in Example 1. The section title for the **MOODLE_400_STABLE** branch will indicate the next upcoming minor version (4.0.2 in this case): -```txt title="Example 2: Patch applied to master and MOODLE_400_STABLE" +```txt title="Example 2: Patch applied to main and MOODLE_400_STABLE" == 4.0.2 == An API change to empower educators! ``` @@ -23,7 +23,7 @@ An API change to empower educators! Multiple versions within the section title are **not** allowed. However, developers may note the Moodle versions that the change applies to within the upgrade note text itself. -```txt title="Example 3a: master (4.1dev)" +```txt title="Example 3a: main (4.1dev)" == 4.1 == An API change to empower educators! (This was fixed in 4.1 and 4.0.2) ``` @@ -43,9 +43,9 @@ An API change to empower educators! When Moodle is developing two major versions in parallel, for example Moodle 3.11.0, and Moodle 4.0.0, then the version in the earliest of the major version development branches will be used for both branches. -For example, given we are in a parallel development situation with **MOODLE_311_STABLE** (3.11dev) and **master** (4.0dev), with Moodle 3.11 as the next upcoming major Moodle version. If an API change is applied to **MOODLE_311_STABLE**, the version number on the section title will be **3.11** for both **master** and **MOODLE_400_STABLE** branches. +For example, given we are in a parallel development situation with **MOODLE_311_STABLE** (3.11dev) and **main** (4.0dev), with Moodle 3.11 as the next upcoming major Moodle version. If an API change is applied to **MOODLE_311_STABLE**, the version number on the section title will be **3.11** for both **main** and **MOODLE_400_STABLE** branches. -```txt title="Example 4a: master (4.0dev)" +```txt title="Example 4a: main (4.0dev)" == 3.11 == An API change to empower educators! ``` diff --git a/versioned_docs/version-4.3/apis/core/customfields/index.md b/versioned_docs/version-4.3/apis/core/customfields/index.md index a9b7ac5cd5..faaac256b6 100644 --- a/versioned_docs/version-4.3/apis/core/customfields/index.md +++ b/versioned_docs/version-4.3/apis/core/customfields/index.md @@ -25,7 +25,7 @@ New plugin type `customfield` was also added as part of the Custom fields API. A ## How to use custom fields -Component/plugin that uses custom fields must define a **handler class** for each area and a **configuration page**. Handler class must be called `/customfield/_handler` and be placed in autoloaded location `/classes/customfield/_handler.php`. This class must extend **\core_customfield\handler** . Configuration page may be located anywhere. For course custom fields configuration the admin settings page is used [/course/customfield.php](https://github.com/moodle/moodle/blob/master/course/customfield.php). If the area uses `itemid` this page should take `itemid` as a parameter. +Component/plugin that uses custom fields must define a **handler class** for each area and a **configuration page**. Handler class must be called `/customfield/_handler` and be placed in autoloaded location `/classes/customfield/_handler.php`. This class must extend **\core_customfield\handler** . Configuration page may be located anywhere. For course custom fields configuration the admin settings page is used [/course/customfield.php](https://github.com/moodle/moodle/blob/main/course/customfield.php). If the area uses `itemid` this page should take `itemid` as a parameter. Handler has protected constructor, to get a handler call `create()` method. Some areas may choose to return a singleton here: diff --git a/versioned_docs/version-4.3/apis/core/htmlwriter/index.md b/versioned_docs/version-4.3/apis/core/htmlwriter/index.md index 2a1188580f..4740676734 100644 --- a/versioned_docs/version-4.3/apis/core/htmlwriter/index.md +++ b/versioned_docs/version-4.3/apis/core/htmlwriter/index.md @@ -16,7 +16,7 @@ Please consider using [templates](../../../guides/templates/index.md) as an alte :::note -There is no documentation for most of this class. Please read [HTML Writer Class Reference](https://phpdoc.moodledev.io/master/d4/d78/classhtml__writer.html) for further information. +There is no documentation for most of this class. Please read [HTML Writer Class Reference](https://phpdoc.moodledev.io/main/d4/d78/classhtml__writer.html) for further information. ::: diff --git a/versioned_docs/version-4.3/apis/core/reportbuilder/index.md b/versioned_docs/version-4.3/apis/core/reportbuilder/index.md index e7aa25b789..a9117b1795 100644 --- a/versioned_docs/version-4.3/apis/core/reportbuilder/index.md +++ b/versioned_docs/version-4.3/apis/core/reportbuilder/index.md @@ -32,7 +32,7 @@ Column instances define the data captured/displayed within a report column typic #### Creating columns -To create a new column, just create a new instance of [`reportbuilder/classes/local/report/column.php`](https://github.com/moodle/moodle/blob/master/reportbuilder/classes/local/report/column.php) class with: +To create a new column, just create a new instance of [`reportbuilder/classes/local/report/column.php`](https://github.com/moodle/moodle/blob/main/reportbuilder/classes/local/report/column.php) class with: ```php * string $name @@ -80,20 +80,20 @@ Filters & columns are entirely separate concepts in the report, and each can be #### Filter types -- **Text** ([reportbuilder/classes/local/filters/text.php](https://github.com/moodle/moodle/blob/master/reportbuilder/classes/local/filters/text.php)) -- **Date** ([reportbuilder/classes/local/filters/date.php](https://github.com/moodle/moodle/blob/master/reportbuilder/classes/local/filters/date.php)) -- **Number** ([reportbuilder/classes/local/filters/number.php](https://github.com/moodle/moodle/blob/master/reportbuilder/classes/local/filters/number.php)) -- **Boolean Select** ([reportbuilder/classes/local/filters/boolean_select.php](https://github.com/moodle/moodle/blob/master/reportbuilder/classes/local/filters/boolean_select.php)) -- **Select** ([reportbuilder/classes/local/filters/select.php](https://github.com/moodle/moodle/blob/master/reportbuilder/classes/local/filters/select.php)) -- **Course selector** ([reportbuilder/classes/local/filters/course_selector.php](https://github.com/moodle/moodle/blob/master/reportbuilder/classes/local/filters/course_selector.php)) -- **Duration** ([reportbuilder/classes/local/filters/duration.php](https://github.com/moodle/moodle/blob/master/reportbuilder/classes/local/filters/duration.php)) -- **Tags** ([reportbuilder/classes/local/filters/tags.php](https://github.com/moodle/moodle/blob/master/reportbuilder/classes/local/filters/tags.php)) -- **Autocomplete** ([reportbuilder/classes/local/filters/autocomplete.php](https://github.com/moodle/moodle/blob/master/reportbuilder/classes/local/filters/autocomplete.php)) -- **Category** ([reportbuilder/classes/local/filters/category.php](https://github.com/moodle/moodle/blob/master/reportbuilder/classes/local/filters/category.php)) +- **Text** ([reportbuilder/classes/local/filters/text.php](https://github.com/moodle/moodle/blob/main/reportbuilder/classes/local/filters/text.php)) +- **Date** ([reportbuilder/classes/local/filters/date.php](https://github.com/moodle/moodle/blob/main/reportbuilder/classes/local/filters/date.php)) +- **Number** ([reportbuilder/classes/local/filters/number.php](https://github.com/moodle/moodle/blob/main/reportbuilder/classes/local/filters/number.php)) +- **Boolean Select** ([reportbuilder/classes/local/filters/boolean_select.php](https://github.com/moodle/moodle/blob/main/reportbuilder/classes/local/filters/boolean_select.php)) +- **Select** ([reportbuilder/classes/local/filters/select.php](https://github.com/moodle/moodle/blob/main/reportbuilder/classes/local/filters/select.php)) +- **Course selector** ([reportbuilder/classes/local/filters/course_selector.php](https://github.com/moodle/moodle/blob/main/reportbuilder/classes/local/filters/course_selector.php)) +- **Duration** ([reportbuilder/classes/local/filters/duration.php](https://github.com/moodle/moodle/blob/main/reportbuilder/classes/local/filters/duration.php)) +- **Tags** ([reportbuilder/classes/local/filters/tags.php](https://github.com/moodle/moodle/blob/main/reportbuilder/classes/local/filters/tags.php)) +- **Autocomplete** ([reportbuilder/classes/local/filters/autocomplete.php](https://github.com/moodle/moodle/blob/main/reportbuilder/classes/local/filters/autocomplete.php)) +- **Category** ([reportbuilder/classes/local/filters/category.php](https://github.com/moodle/moodle/blob/main/reportbuilder/classes/local/filters/category.php)) #### Creating filters -To create a new filter, just create a new instance of **[reportbuilder/classes/local/report/filter.php](https://github.com/moodle/moodle/blob/master/reportbuilder/classes/local/report/filter.php)** class with: +To create a new filter, just create a new instance of **[reportbuilder/classes/local/report/filter.php](https://github.com/moodle/moodle/blob/main/reportbuilder/classes/local/report/filter.php)** class with: ```php * string $filterclass @@ -125,7 +125,7 @@ All report elements can be defined within the reports themselves - but entities #### Create an entity -To create an entity, the new entity class must extend **[reportbuilder/classes/local/entities/base.php](https://github.com/moodle/moodle/blob/master/reportbuilder/classes/local/entities/base.php)** class and must include these methods: +To create an entity, the new entity class must extend **[reportbuilder/classes/local/entities/base.php](https://github.com/moodle/moodle/blob/main/reportbuilder/classes/local/entities/base.php)** class and must include these methods: ```php get_default_table_aliases() @@ -149,8 +149,8 @@ This is where we **add** the entity columns and filters. Check out these two entities as an example to start building reports: -- **User entity**: [reportbuilder/classes/local/entities/user.php](https://github.com/moodle/moodle/blob/master/reportbuilder/classes/local/entities/user.php) -- **Course entity**: [reportbuilder/classes/local/entities/course.php](https://github.com/moodle/moodle/blob/master/reportbuilder/classes/local/entities/course.php) +- **User entity**: [reportbuilder/classes/local/entities/user.php](https://github.com/moodle/moodle/blob/main/reportbuilder/classes/local/entities/user.php) +- **Course entity**: [reportbuilder/classes/local/entities/course.php](https://github.com/moodle/moodle/blob/main/reportbuilder/classes/local/entities/course.php) ### Actions @@ -174,7 +174,7 @@ System reports are a consistent way of providing reporting data, with paging, fi #### Create a new system report using entities -To create a new system report just create a new class extending [reportbuilder/classes/system_report.php](https://github.com/moodle/moodle/blob/master/reportbuilder/classes/system_report.php). +To create a new system report just create a new class extending [reportbuilder/classes/system_report.php](https://github.com/moodle/moodle/blob/main/reportbuilder/classes/system_report.php). The first method that we need is ***initialise()*** : @@ -285,5 +285,5 @@ $this->set_initial_sort_column('task_log:starttime', SORT_DESC); Check out these two system reports as an example: -- **Task logs**: [`admin/classes/reportbuilder/local/systemreports/task_logs.php`](https://github.com/moodle/moodle/blob/master/admin/classes/reportbuilder/local/systemreports/task_logs.php) -- **Config changes**: [`report/configlog/classes/reportbuilder/local/systemreports/config_changes.php`](https://github.com/moodle/moodle/blob/master/report/configlog/classes/reportbuilder/local/systemreports/config_changes.php) +- **Task logs**: [`admin/classes/reportbuilder/local/systemreports/task_logs.php`](https://github.com/moodle/moodle/blob/main/admin/classes/reportbuilder/local/systemreports/task_logs.php) +- **Config changes**: [`report/configlog/classes/reportbuilder/local/systemreports/config_changes.php`](https://github.com/moodle/moodle/blob/main/report/configlog/classes/reportbuilder/local/systemreports/config_changes.php) diff --git a/versioned_docs/version-4.3/apis/plugintypes/assign/feedback.md b/versioned_docs/version-4.3/apis/plugintypes/assign/feedback.md index 61d9599d4f..7c2a5753fb 100644 --- a/versioned_docs/version-4.3/apis/plugintypes/assign/feedback.md +++ b/versioned_docs/version-4.3/apis/plugintypes/assign/feedback.md @@ -19,7 +19,7 @@ An assignment feedback plugin can do many things including providing feedback to :::tip -For a good reference implementation, see the [file](https://github.com/moodle/moodle/tree/master/mod/assign/feedback/file) feedback plugin included with core because it uses most of the features of feedback plugins. +For a good reference implementation, see the [file](https://github.com/moodle/moodle/tree/main/mod/assign/feedback/file) feedback plugin included with core because it uses most of the features of feedback plugins. ::: diff --git a/versioned_docs/version-4.3/apis/plugintypes/assign/submission.md b/versioned_docs/version-4.3/apis/plugintypes/assign/submission.md index 51a28456dd..076ca343a0 100644 --- a/versioned_docs/version-4.3/apis/plugintypes/assign/submission.md +++ b/versioned_docs/version-4.3/apis/plugintypes/assign/submission.md @@ -19,7 +19,7 @@ An assignment submission plugin is used to display custom form fields to a stude :::tip -For a good reference implementation, see the [onlinetext](https://github.com/moodle/moodle/tree/master/mod/assign/submission/onlinetext) submission plugin included with core because it uses most of the features of submission plugins. +For a good reference implementation, see the [onlinetext](https://github.com/moodle/moodle/tree/main/mod/assign/submission/onlinetext) submission plugin included with core because it uses most of the features of submission plugins. ::: diff --git a/versioned_docs/version-4.3/apis/plugintypes/communication/index.md b/versioned_docs/version-4.3/apis/plugintypes/communication/index.md index 208827e0e0..669eced758 100644 --- a/versioned_docs/version-4.3/apis/plugintypes/communication/index.md +++ b/versioned_docs/version-4.3/apis/plugintypes/communication/index.md @@ -133,6 +133,6 @@ All the necessary actions to remove members from a room should live here. The ar :::info -For a real plugin example, please look at the [Matrix plugin](https://github.com/moodle/moodle/tree/master/communication/provider/matrix). +For a real plugin example, please look at the [Matrix plugin](https://github.com/moodle/moodle/tree/main/communication/provider/matrix). ::: diff --git a/versioned_docs/version-4.3/apis/plugintypes/tiny/testing.md b/versioned_docs/version-4.3/apis/plugintypes/tiny/testing.md index ebea115999..b08ca16a41 100644 --- a/versioned_docs/version-4.3/apis/plugintypes/tiny/testing.md +++ b/versioned_docs/version-4.3/apis/plugintypes/tiny/testing.md @@ -29,7 +29,7 @@ By using these tags appropriately, Moodle will ensure that TinyMCE is set as the ### Useful steps -A number of useful Behat steps have been defined in [TinyMCE Behat context](https://github.com/moodle/moodle/blob/master/lib/editor/tiny/tests/behat/behat_editor_tiny.php). +A number of useful Behat steps have been defined in [TinyMCE Behat context](https://github.com/moodle/moodle/blob/main/lib/editor/tiny/tests/behat/behat_editor_tiny.php). :::caution Use generic steps where possible @@ -39,7 +39,7 @@ Typically, when interacting with an Editor, you should use the _generic_ step de #### Generic steps to interact with editors -Most of these steps are defined in the [Behat Forms context](https://github.com/moodle/moodle/blob/master/lib/tests/behat/behat_forms.php) and this documentation should not be treated as a complete list, rather an indication of approaches that you may consider taking. +Most of these steps are defined in the [Behat Forms context](https://github.com/moodle/moodle/blob/main/lib/tests/behat/behat_forms.php) and this documentation should not be treated as a complete list, rather an indication of approaches that you may consider taking. ##### Setting content of a field diff --git a/versioned_docs/version-4.3/apis/subsystems/admin/index.md b/versioned_docs/version-4.3/apis/subsystems/admin/index.md index e1c5bffa45..ca5e03e18c 100644 --- a/versioned_docs/version-4.3/apis/subsystems/admin/index.md +++ b/versioned_docs/version-4.3/apis/subsystems/admin/index.md @@ -117,7 +117,7 @@ Few things to highlight: ## Individual settings -Let us look at a simple example: [mod/lesson/settings.php](https://github.com/moodle/moodle/blob/master/mod/lesson/settings.php). This is included by admin/settings/plugins.php, which has already created $settings, which is an admin_settingpage that we can add to. The file contains lots of lines that look a bit like: +Let us look at a simple example: [mod/lesson/settings.php](https://github.com/moodle/moodle/blob/main/mod/lesson/settings.php). This is included by admin/settings/plugins.php, which has already created $settings, which is an admin_settingpage that we can add to. The file contains lots of lines that look a bit like: ```php $settings->add(new admin_setting_configtext('mod_lesson/mediawidth', get_string('mediawidth', 'lesson'), diff --git a/versioned_docs/version-4.3/apis/subsystems/analytics/index.md b/versioned_docs/version-4.3/apis/subsystems/analytics/index.md index 37408390a8..820f4bdf5f 100644 --- a/versioned_docs/version-4.3/apis/subsystems/analytics/index.md +++ b/versioned_docs/version-4.3/apis/subsystems/analytics/index.md @@ -362,7 +362,7 @@ public function processes_user_data(); /** * SQL JOIN from a sample to users table. * - * More info in [https://github.com/moodle/moodle/blob/master/analytics/classes/local/analyser/base.php core_analytics\local\analyser\base]::join_sample_user + * More info in [https://github.com/moodle/moodle/blob/main/analytics/classes/local/analyser/base.php core_analytics\local\analyser\base]::join_sample_user * * @param string $sampletablealias The alias of the table with a sampleid field that will join with this SQL string * @return string diff --git a/versioned_docs/version-4.3/apis/subsystems/check/index.md b/versioned_docs/version-4.3/apis/subsystems/check/index.md index 3b26541531..b71dbbfe30 100644 --- a/versioned_docs/version-4.3/apis/subsystems/check/index.md +++ b/versioned_docs/version-4.3/apis/subsystems/check/index.md @@ -215,7 +215,7 @@ class foobar_result extends \core\check\result { For a real example see: -https://github.com/moodle/moodle/blob/master/lib/classes/check/access/riskxss_result.php +https://github.com/moodle/moodle/blob/main/lib/classes/check/access/riskxss_result.php ### Asynchronous checks diff --git a/versioned_docs/version-4.3/apis/subsystems/external/writing-a-service.md b/versioned_docs/version-4.3/apis/subsystems/external/writing-a-service.md index f96e504070..51a2ba206d 100644 --- a/versioned_docs/version-4.3/apis/subsystems/external/writing-a-service.md +++ b/versioned_docs/version-4.3/apis/subsystems/external/writing-a-service.md @@ -54,7 +54,7 @@ If _any_ group creation fails, the function will throw an exception, and no grou ## Technical specification -- **the core function the external function will call**: `groups_create_group()` from [/group/lib.php](http://github.com/moodle/moodle/tree/master/moodle/group/lib.php). +- **the core function the external function will call**: `groups_create_group()` from [/group/lib.php](http://github.com/moodle/moodle/tree/main/moodle/group/lib.php). - **the parameter types**: a list of object. This object are groups, with `id`/`name`/`courseid`. - **the returned value types**: a list of objects (groups) with their id. - **the user capabilities to check**: `moodle/course:managegroups` diff --git a/versioned_docs/version-4.3/apis/subsystems/form/index.md b/versioned_docs/version-4.3/apis/subsystems/form/index.md index 4ea6cc2941..165942784d 100644 --- a/versioned_docs/version-4.3/apis/subsystems/form/index.md +++ b/versioned_docs/version-4.3/apis/subsystems/form/index.md @@ -207,8 +207,8 @@ $mform->addElement( For a real-life example, see: -- [Custom element definition](https://github.com/moodle/moodle/blob/master/admin/tool/lp/classes/course_competency_rule_form_element.php) -- [Custom element usage](https://github.com/moodle/moodle/blob/master/admin/tool/lp/lib.php#L157-L161) +- [Custom element definition](https://github.com/moodle/moodle/blob/main/admin/tool/lp/classes/course_competency_rule_form_element.php) +- [Custom element usage](https://github.com/moodle/moodle/blob/main/admin/tool/lp/lib.php#L157-L161) ## Commonly used functions diff --git a/versioned_docs/version-4.3/apis/subsystems/form/usage/index.md b/versioned_docs/version-4.3/apis/subsystems/form/usage/index.md index 8d374eb38b..cb9d4fc80f 100644 --- a/versioned_docs/version-4.3/apis/subsystems/form/usage/index.md +++ b/versioned_docs/version-4.3/apis/subsystems/form/usage/index.md @@ -16,8 +16,8 @@ Moodle will attempt to provide a more complete tutorial in this documentation wh Some good examples of usage of the Forms API can be found at the following locations: -- [Course edit form - definition](https://github.com/moodle/moodle/blob/master/course/edit_form.php) -- [Course edit form - usage](https://github.com/moodle/moodle/blob/master/course/edit.php) +- [Course edit form - definition](https://github.com/moodle/moodle/blob/main/course/edit_form.php) +- [Course edit form - usage](https://github.com/moodle/moodle/blob/main/course/edit.php) ::: diff --git a/versioned_docs/version-4.3/apis/subsystems/group/index.md b/versioned_docs/version-4.3/apis/subsystems/group/index.md index e4734da8aa..b8fa221caf 100644 --- a/versioned_docs/version-4.3/apis/subsystems/group/index.md +++ b/versioned_docs/version-4.3/apis/subsystems/group/index.md @@ -74,7 +74,7 @@ The core API functions in `groupslib` such as `groups_get_all_groups()` and `gro ## File locations -The Groups API is currently defined in [lib/grouplib.php](https://github.com/moodle/moodle/blob/master/lib/grouplib.php). This contains global functions which have the `groups_` prefix, for example: `groups_get_group()`. +The Groups API is currently defined in [lib/grouplib.php](https://github.com/moodle/moodle/blob/main/lib/grouplib.php). This contains global functions which have the `groups_` prefix, for example: `groups_get_group()`. ## Examples diff --git a/versioned_docs/version-4.3/apis/subsystems/output/inplace.md b/versioned_docs/version-4.3/apis/subsystems/output/inplace.md index ac07b780f4..11a4f4c131 100644 --- a/versioned_docs/version-4.3/apis/subsystems/output/inplace.md +++ b/versioned_docs/version-4.3/apis/subsystems/output/inplace.md @@ -140,7 +140,7 @@ class inplace_edit_text extends \core\output\inplace_editable { You may choose to set the UI for your inplace editable element to be a string value (default), toggle or dropdown. -Examples of dropdown setup (see also [example by overriding class](https://github.com/moodle/moodle/blob/master/tag/classes/output/tagareacollection.php)): +Examples of dropdown setup (see also [example by overriding class](https://github.com/moodle/moodle/blob/main/tag/classes/output/tagareacollection.php)): ```php $tagcollections = \core_tag_collection::get_collections_menu(true); @@ -163,7 +163,7 @@ $tmpl = new \core\output\inplace_editable( $tmpl->set_type_select($tagcollections); ``` -Example of toggle setup (see also [example by overriding class](https://github.com/moodle/moodle/blob/master/tag/classes/output/tagareaenabled.php)): +Example of toggle setup (see also [example by overriding class](https://github.com/moodle/moodle/blob/main/tag/classes/output/tagareaenabled.php)): ```php $tmpl = new \core\output\inplace_editable( diff --git a/versioned_docs/version-4.3/apis/subsystems/task/index.md b/versioned_docs/version-4.3/apis/subsystems/task/index.md index f3836b1ab3..a6bfd303c8 100644 --- a/versioned_docs/version-4.3/apis/subsystems/task/index.md +++ b/versioned_docs/version-4.3/apis/subsystems/task/index.md @@ -65,7 +65,7 @@ If you catch an exception, then you become responsible for things that the task For example, it is important to log all the details of the error, so problems can be investigated and fixed. The helper function `mtrace_exception` makes this easier. Also, you need to consider: if something has gone wrong with part of the processing, but other parts succeeded, should the overall state of the task run be success or failure? It will depend on how the task works, but you may need to ensure that the task -ends by throwing an exception if any part failed. There is a an example of all this in the [`\quiz_statistics\task\recalculate`](https://github.com/moodle/moodle/blob/master/mod/quiz/report/statistics/classes/task/recalculate.php). +ends by throwing an exception if any part failed. There is a an example of all this in the [`\quiz_statistics\task\recalculate`](https://github.com/moodle/moodle/blob/main/mod/quiz/report/statistics/classes/task/recalculate.php). ### Caches diff --git a/versioned_docs/version-4.3/guides/git/index.md b/versioned_docs/version-4.3/guides/git/index.md index 1845e44705..3cd4e97948 100644 --- a/versioned_docs/version-4.3/guides/git/index.md +++ b/versioned_docs/version-4.3/guides/git/index.md @@ -101,7 +101,7 @@ This command does several jobs for you: - Creates a new folder - Initialises a new local Git repository - Sets your GitHub repository as the remote repository called 'origin' -- Makes a local checkout of the branch 'master' +- Makes a local checkout of the branch 'main' :::tip [MDK](/general/development/tools/mdk) features many commands that aid in the creation and management of your Moodle branches. If you haven't checked it out already, see how MDK can streamline your Moodle development. @@ -109,7 +109,7 @@ This command does several jobs for you: ## Keeping your public repository up-to-date -Your fork at GitHub is not updated automatically. To keep it synced with the upstream Moodle repository, you have to fetch the recent changes from the official moodle.git repository. To avoid conflicts, it is strongly recommended that you never modify the standard Moodle branches. Never commit directly into `master` and `MOODLE_XXX_STABLE` branches, but instead create topic branches to work on. In Git terminology, the `master` branch and `MOODLE_XXX_STABLE` branches should always be fast-forwardable. +Your fork at GitHub is not updated automatically. To keep it synced with the upstream Moodle repository, you have to fetch the recent changes from the official moodle.git repository. To avoid conflicts, it is strongly recommended that you never modify the standard Moodle branches. Never commit directly into `main` and `MOODLE_XXX_STABLE` branches, but instead create topic branches to work on. In Git terminology, the `main` branch and `MOODLE_XXX_STABLE` branches should always be fast-forwardable. ![git-sync-github.png](./_index/git-sync-github.png) @@ -126,13 +126,13 @@ The following commands can be used to keep the your forked Moodle branches at yo ``` #!/bin/bash git fetch upstream -for BRANCH in MOODLE_{19..39}_STABLE MOODLE_{310..311}_STABLE MOODLE_{400..403}_STABLE master; do +for BRANCH in MOODLE_{19..39}_STABLE MOODLE_{310..311}_STABLE MOODLE_{400..403}_STABLE main; do git push origin refs/remotes/upstream/$BRANCH:refs/heads/$BRANCH done ``` :::caution -Never commit directly into `master` and `MOODLE_XXX_STABLE` branches +Never commit directly into `main` and `MOODLE_XXX_STABLE` branches ::: :::tip @@ -173,7 +173,7 @@ git push origin MOODLE_99_STABLE:MOODLE_99_STABLE The above code will create a new copy of the `MOODLE_99_STABLE` branch in your local repository. If you do not need to keep a local copy of the new branch (probably the case), you can remove it from your local repository as follows: ``` -git checkout master +git checkout main git branch -D MOODLE_99_STABLE ``` @@ -183,10 +183,10 @@ git branch -D MOODLE_99_STABLE As mentioned earlier, you never work on standard Moodle branches directly. Every time you are going to edit something, switch to a local branch. Fork the local branch off Moodle's standard branch that you think it should be eventually merged to. -For example, if you are working on a patch for **4.1**, fork the branch off `MOODLE_401_STABLE`. Patches for the next [major version](https://docs.moodle.org/dev/Moodle_versions) should be based on the `master` branch. +For example, if you are working on a patch for **4.1**, fork the branch off `MOODLE_401_STABLE`. Patches for the next [major version](https://docs.moodle.org/dev/Moodle_versions) should be based on the `main` branch. ``` -git checkout -b MDL-xxxxx-master_brief_name origin/master +git checkout -b MDL-xxxxx-main_brief_name origin/main ``` If you forget to specify the branch you want to fork from, the new branch will be based on the currently checked-out branch. It is recommended you always specify this. @@ -218,7 +218,7 @@ git log Your local branch changes may consist of several commits. Once you are happy with it, and you have checked it against Moodle's [Coding styles](/general/development/policies/codingstyle), publish your changes by pushing to your public repository. ``` -git push origin MDL-xxxxx-master_brief_name +git push origin MDL-xxxxx-main_brief_name ``` Now your branch is published and you can ask Moodle core developers to review it and eventually integrate it into Moodle's main repository. @@ -231,10 +231,10 @@ There are a couple of ways this can be achieved. #### Reset all changes and commit again -The following command will preserve your changes, but all commits on top of `master` branch will be gone and become **unstaged** and ready to be added and committed again. +The following command will preserve your changes, but all commits on top of `main` branch will be gone and become **unstaged** and ready to be added and committed again. ``` -git reset --mixed origin/master +git reset --mixed origin/main ``` #### Rebase your changes @@ -247,12 +247,12 @@ Rebase your branch using the following command: git rebase --interactive ``` -Whichever option you chose, you have "rewritten history". If you had already pushed your branch to your remote repository, you may encounter issues when trying to push the updated branch. If you try `git push MDL-xxxxx-master_brief_name` you will get an error message suggesting you to `force push`. +Whichever option you chose, you have "rewritten history". If you had already pushed your branch to your remote repository, you may encounter issues when trying to push the updated branch. If you try `git push MDL-xxxxx-main_brief_name` you will get an error message suggesting you to `force push`. To force push the changed commits use: ``` -git push -f origin MDL-xxxxx-master_brief_name +git push -f origin MDL-xxxxx-main_brief_name ``` If an error occurs because you are still using the git protocol (read only), use this command: @@ -273,16 +273,16 @@ After some time contributing to Moodle, you will have accumulated many branches, ``` git fetch upstream -git branch --merged upstream/master +git branch --merged upstream/main git branch --merged upstream/MOODLE_XXX_STABLE ``` #### Pruning local branches -The `git fetch upstream` command fetches the changes from your upstream repository (remember that `git fetch` does not modify your working directory, so it is safe to run it whenever). The `git branch --merged` commands displays all branches that are merged into the Moodle's upstream `master` branch and `MOODLE_XXX_STABLE` branch, respectively. To delete these local branches, use: +The `git fetch upstream` command fetches the changes from your upstream repository (remember that `git fetch` does not modify your working directory, so it is safe to run it whenever). The `git branch --merged` commands displays all branches that are merged into the Moodle's upstream `main` branch and `MOODLE_XXX_STABLE` branch, respectively. To delete these local branches, use: ``` -git branch -d MDL-xxxxx-master_accepted_branch +git branch -d MDL-xxxxx-main_accepted_branch ``` #### Pruning remote branches @@ -292,7 +292,7 @@ A similar approach can be used to check the branches published at your origin re ``` git fetch origin git fetch upstream -git branch -r --merged upstream/master +git branch -r --merged upstream/main git branch -r --merged upstream/MOODLE_XXX_STABLE ``` @@ -301,7 +301,7 @@ The `git fetch upstream` command makes sure that you have all your branches from To delete a branch on your origin repository, use: ``` -git push origin :MDL-xxxxx-master_branch_to_delete +git push origin :MDL-xxxxx-main_branch_to_delete ``` This syntax may look unfamiliar, however it is pretty logical. The general syntax of the `git push` command is: @@ -359,7 +359,7 @@ Once you have acquired the code and are ready to review it, reference Moodle's [ Rebasing is a process when you cut off the branch from its current start point and transplant it to another point. Let us assume the following history exists: ```mermaid -%%{init: { 'gitGraph': {'mainBranchName': 'master', 'mainBranchOrder': 2 }} }%% +%%{init: { 'gitGraph': {'mainBranchName': 'main', 'mainBranchOrder': 2 }} }%% gitGraph commit id: "D" commit id: "E" @@ -367,20 +367,20 @@ gitGraph commit id: "A" commit id: "B" commit id: "C" - checkout master + checkout main commit id: "F" commit id: "G" ``` -The result of the command `git rebase master topic` would transplant the `topic` branch on top of the `master` branch and look like this: +The result of the command `git rebase main topic` would transplant the `topic` branch on top of the `main` branch and look like this: ```mermaid -%%{init: { 'gitGraph': {'mainBranchName': 'master', 'mainBranchOrder': 2 }} }%% +%%{init: { 'gitGraph': {'mainBranchName': 'main', 'mainBranchOrder': 2 }} }%% gitGraph commit id: "D" commit id: "E" - checkout master + checkout main commit id: "F" commit id: "G" branch topic order: 1 @@ -393,10 +393,10 @@ gitGraph You may be asked to rebase your branch if the submitted branch was based on an outdated commit. Consider this example: -On Tuesday, we create a new topic branch, forked off the upstream `master` branch. On Wednesday, the upstream `master` branch is updated with all the changes from the last integration cycle. To make our branch easier to integrate, we rebase our branch against the newly updated `master` branch. +On Tuesday, we create a new topic branch, forked off the upstream `main` branch. On Wednesday, the upstream `main` branch is updated with all the changes from the last integration cycle. To make our branch easier to integrate, we rebase our branch against the newly updated `main` branch. ``` -git rebase master MDL-xxxxx-master_topic_branch +git rebase main MDL-xxxxx-main_topic_branch ``` Note that rebasing effectively rewrites the history of the branch. **Do not rebase the branch if there is a chance that somebody has already forked it and based their own branch on it.** For this reason, many Git tutorials discourage from rebasing any branch that has been published. @@ -419,7 +419,7 @@ git rebase --continue Most bugs are fixed on each stable branch (e.g. `MOODLE_400_STABLE`, `MOODLE_311_STABLE`). If you are working on an fix based on one of these branches, it is possible you will need to prepare a patch for other affected stable branches too. -In Moodle, we separately maintain the stable branches and the current development branch (master). We do not merge stable branches into the master one. Typically, the contributor prepares at least two branches: one with the fix for the affected stable branch(es), and one with the fix for the master branch. +In Moodle, we separately maintain the stable branches and the current development branch (main). We do not merge stable branches into the main one. Typically, the contributor prepares at least two branches: one with the fix for the affected stable branch(es), and one with the fix for the main branch. Let's assume you have a patch prepared, based on `MOODLE_400_STABLE`, called `MDL-xxxxx-400_topic`. It is possible to apply this patch to other stable branches. There are a few ways we could achieve this. @@ -428,18 +428,18 @@ Let's assume you have a patch prepared, based on `MOODLE_400_STABLE`, called `MD Let's assume we have two local Git repositories: 1. `~/public_html/moodle_400` containing a local installation of Moodle 4.0, and -2. `~/public_html/moodle_master` containing a local installation of the most recent development version of Moodle. +2. `~/public_html/moodle_main` containing a local installation of the most recent development version of Moodle. -They both use your public repository at github.com as the origin. You have a branch in `moodle_400` called `MDL-xxxxx-400_topic` that was forked off `MOODLE_400_STABLE`. It contains one commit. Now, you want to apply this commit to a new branch in `moodle_master` called `MDL-xxxxx-master_topic`. +They both use your public repository at github.com as the origin. You have a branch in `moodle_400` called `MDL-xxxxx-400_topic` that was forked off `MOODLE_400_STABLE`. It contains one commit. Now, you want to apply this commit to a new branch in `moodle_main` called `MDL-xxxxx-main_topic`. ``` -cd ~/public_html/moodle_master -git checkout -b MDL-xxxxx-master_topic origin/master +cd ~/public_html/moodle_main +git checkout -b MDL-xxxxx-main_topic origin/main git fetch ../moodle_400 MDL-xxxxx-400_topic git cherry-pick FETCH_HEAD ``` -1. The `git checkout -b MDL-xxxxx-master_topic origin/master` command creates new local branch, forked off `master`. +1. The `git checkout -b MDL-xxxxx-main_topic origin/main` command creates new local branch, forked off `main`. 2. The `git fetch ../moodle_400 MDL-xxxxx-400_topic` command fetches all data needed to apply the topic branch, and sets the pointer to the tip of that branch with `FETCH_HEAD` as a symbolic reference. 3. The `git cherry-pick FETCH_HEAD` command picks the tip of the branch (the top-most commit) and tries to apply it on the current branch. @@ -464,8 +464,8 @@ The `git format-patch -o .patches MOODLE_400_STABLE..MDL-xxxxx-400_topic` comman In this example, we will apply them to another repository. ``` -cd ~/public_html/moodle_master -git checkout -b MDL-xxxxx-master_topic origin/master +cd ~/public_html/moodle_main +git checkout -b MDL-xxxxx-main_topic origin/main git am -3 ../moodle_400/.patches/* ``` diff --git a/versioned_docs/version-4.3/guides/upgrade/index.md b/versioned_docs/version-4.3/guides/upgrade/index.md index 0c775f79ea..dc809aba03 100644 --- a/versioned_docs/version-4.3/guides/upgrade/index.md +++ b/versioned_docs/version-4.3/guides/upgrade/index.md @@ -166,11 +166,11 @@ In Moodle core, one of the standard simple rules is not to make any database cha :::warning Advanced -Suppose, in order to fix a bug, you need to make a database change in the Moodle 4.0 stable branch (and the master branch targetting Moodle 4.1). The root of the problem is that people may upgrade their Moodle in three different ways, which +Suppose, in order to fix a bug, you need to make a database change in the Moodle 4.0 stable branch (and the main branch targetting Moodle 4.1). The root of the problem is that people may upgrade their Moodle in three different ways, which - Upgrade from \<=4.0.2 to 4.0.3 - this executes the upgrade script on the 4.0 branch. -- Upgrade from \<=4.0.2 directly to >=4.1 - this executes the upgrade script on the master branch. -- Upgrade from 4.0.3 to >=4.1 - in this case, you must ensure that the upgrade on master is not executed. +- Upgrade from \<=4.0.2 directly to >=4.1 - this executes the upgrade script on the main branch. +- Upgrade from 4.0.3 to >=4.1 - in this case, you must ensure that the upgrade on main is not executed. The normal way to do this is ensure that your database upgrade is idempotent. That is, it does not matter if you do it twice. So for example, instead of doing