diff --git a/.circleci/config.yml b/.circleci/config.yml index 55571d3dba..949ced826a 100644 --- a/.circleci/config.yml +++ b/.circleci/config.yml @@ -78,4 +78,4 @@ workflows: filters: branches: only: - - master + - main diff --git a/.circleci/trigger-nightly-build.sh b/.circleci/trigger-nightly-build.sh index 3e2381cb4c..3e080c360e 100755 --- a/.circleci/trigger-nightly-build.sh +++ b/.circleci/trigger-nightly-build.sh @@ -1,9 +1,9 @@ #!/bin/bash -# Triggers a nightly build for the latest commit on master +# Triggers a nightly build for the latest commit on main # Use this for testing changes to the nightly release process # Call with the CIRCLE_API_USER_TOKEN set to your Personal API key # You can find this under User Settings on Circle CI curl -u ${CIRCLE_API_USER_TOKEN}: \ -d build_parameters[CIRCLE_JOB]=nightly-build \ - https://circleci.com/api/v1.1/project/github/wagtail/wagtail/tree/master + https://circleci.com/api/v1.1/project/github/wagtail/wagtail/tree/main diff --git a/README.md b/README.md index b963c38fae..f073a03278 100644 --- a/README.md +++ b/README.md @@ -1,12 +1,12 @@

- Wagtail + Wagtail

Wagtail is an open source content management system built on Django, with a strong community and commercial support. It's focused on user experience, and offers precise control for designers and developers. -![Wagtail screenshot](https://cdn.jsdelivr.net/gh/wagtail/wagtail@master/.github/wagtail-screenshot-with-browser.png) +![Wagtail screenshot](https://cdn.jsdelivr.net/gh/wagtail/wagtail@main/.github/wagtail-screenshot-with-browser.png) ### Features @@ -88,7 +88,7 @@ Feature releases of Wagtail are released every three months. Selected releases a #### Nightly releases -To try out the latest features before a release, we also create builds from master every night. You can find instructions on how to install the latest nightly release at https://releases.wagtail.io/nightly/index.html +To try out the latest features before a release, we also create builds from `main` every night. You can find instructions on how to install the latest nightly release at https://releases.wagtail.io/nightly/index.html ### Contributing @@ -99,23 +99,23 @@ You might like to start by reviewing the [contributing guidelines](https://docs. We also welcome translations for Wagtail's interface. Translation work should be submitted through [Transifex](https://www.transifex.com/projects/p/wagtail/). ### License -[BSD](https://github.com/wagtail/wagtail/blob/master/LICENSE) +[BSD](https://github.com/wagtail/wagtail/blob/main/LICENSE) ### Thanks We thank the following organisations for their services used in Wagtail's development: -[![Browserstack](https://cdn.jsdelivr.net/gh/wagtail/wagtail@master/.github/browserstack-logo.svg)](https://www.browserstack.com/)
+[![Browserstack](https://cdn.jsdelivr.net/gh/wagtail/wagtail@main/.github/browserstack-logo.svg)](https://www.browserstack.com/)
[BrowserStack](https://www.browserstack.com/) provides the project with free access to their live web-based browser testing tool, and automated Selenium cloud testing. -[![squash.io](https://cdn.jsdelivr.net/gh/wagtail/wagtail@master/.github/squash-logo.svg)](https://www.squash.io/)
+[![squash.io](https://cdn.jsdelivr.net/gh/wagtail/wagtail@main/.github/squash-logo.svg)](https://www.squash.io/)
[Squash](https://www.squash.io/) provides the project with free test environments for reviewing pull requests. [![Build Status](https://github.com/wagtail/wagtail/workflows/Wagtail%20CI/badge.svg)](https://github.com/wagtail/wagtail/actions) [![License](https://img.shields.io/badge/license-BSD-blue.svg)](https://opensource.org/licenses/BSD-3-Clause) [![Version](https://img.shields.io/pypi/v/wagtail.svg)](https://pypi.python.org/pypi/wagtail/) -[![Coverage](https://codecov.io/github/wagtail/wagtail/coverage.svg?branch=master)](https://codecov.io/github/wagtail/wagtail?branch=master) +[![Coverage](https://codecov.io/github/wagtail/wagtail/coverage.svg?branch=main)](https://codecov.io/github/wagtail/wagtail?branch=main) [![Total alerts](https://img.shields.io/lgtm/alerts/g/wagtail/wagtail.svg?logo=lgtm&logoWidth=18)](https://lgtm.com/projects/g/wagtail/wagtail/alerts/) [![Language grade: Python](https://img.shields.io/lgtm/grade/python/g/wagtail/wagtail.svg?logo=lgtm&logoWidth=18)](https://lgtm.com/projects/g/wagtail/wagtail/context:python) [![Language grade: JavaScript](https://img.shields.io/lgtm/grade/javascript/g/wagtail/wagtail.svg?logo=lgtm&logoWidth=18)](https://lgtm.com/projects/g/wagtail/wagtail/context:javascript) diff --git a/client/scss/tools/_functions.breakpoints.scss b/client/scss/tools/_functions.breakpoints.scss index c53b99898c..42a8f16bd1 100644 --- a/client/scss/tools/_functions.breakpoints.scss +++ b/client/scss/tools/_functions.breakpoints.scss @@ -2,7 +2,7 @@ // // Copyright 2011-2018 The Bootstrap Authors // Copyright 2011-2018 Twitter, Inc. -// Licensed under MIT (https://github.com/twbs/bootstrap/blob/master/LICENSE) +// Licensed under MIT (https://github.com/twbs/bootstrap/blob/main/LICENSE) // Name of the next breakpoint, or null for the last breakpoint. // diff --git a/client/scss/tools/_mixins.breakpoints.scss b/client/scss/tools/_mixins.breakpoints.scss index 28bd6fac88..faaa82feaa 100644 --- a/client/scss/tools/_mixins.breakpoints.scss +++ b/client/scss/tools/_mixins.breakpoints.scss @@ -2,7 +2,7 @@ // // Copyright 2011-2018 The Bootstrap Authors // Copyright 2011-2018 Twitter, Inc. -// Licensed under MIT (https://github.com/twbs/bootstrap/blob/master/LICENSE) +// Licensed under MIT (https://github.com/twbs/bootstrap/blob/main/LICENSE) // Media of at least the minimum breakpoint width. No query for the smallest breakpoint. diff --git a/docs/README.md b/docs/README.md index 88ab0a5e88..7d507f0f64 100644 --- a/docs/README.md +++ b/docs/README.md @@ -1,6 +1,6 @@ # Wagtail docs -These are Sphinx docs, automatically built at https://docs.wagtail.io when the master branch is committed to Github. To build them locally, install Wagtail's development requirements (in the root Wagtail directory): +These are Sphinx docs, automatically built at https://docs.wagtail.io when the `main` branch is committed to Github. To build them locally, install Wagtail's development requirements (in the root Wagtail directory): pip install -e .[testing,docs] diff --git a/docs/advanced_topics/embeds.rst b/docs/advanced_topics/embeds.rst index a315a9cc56..c531c57fbb 100644 --- a/docs/advanced_topics/embeds.rst +++ b/docs/advanced_topics/embeds.rst @@ -117,7 +117,7 @@ provider using the oEmbed protocol. Wagtail has a built-in list of providers which are all enabled by default. You can find that provider list at the following link: -https://github.com/wagtail/wagtail/blob/master/wagtail/embeds/oembed_providers.py +https://github.com/wagtail/wagtail/blob/main/wagtail/embeds/oembed_providers.py .. _customising_embed_providers: diff --git a/docs/conf.py b/docs/conf.py index 6187df665d..3f972154b6 100644 --- a/docs/conf.py +++ b/docs/conf.py @@ -304,7 +304,7 @@ def setup(app): app.add_css_file('css/custom.css') app.add_js_file('js/banner.js') - github_doc_root = 'https://github.com/wagtail/wagtail/tree/master/docs/' + github_doc_root = 'https://github.com/wagtail/wagtail/tree/main/docs/' app.add_config_value('recommonmark_config', { 'url_resolver': lambda url: github_doc_root + url, diff --git a/docs/contributing/committing.rst b/docs/contributing/committing.rst index d2f60459b0..9af8c40b47 100644 --- a/docs/contributing/committing.rst +++ b/docs/contributing/committing.rst @@ -16,7 +16,7 @@ Pull requests should not be merged from Github, apart from small documentation f which can be merged with the 'Squash and merge' option. Instead, the code should be checked out by a committer locally, the changes examined and rebased, the ``CHANGELOG.txt`` and release notes updated, -and finally the code should be pushed to the master branch. +and finally the code should be pushed to the ``main`` branch. This process is covered in more detail below. Check out the code locally @@ -33,10 +33,10 @@ A simple way to do this is by adding the following ``git`` alias to your ``~/.gi Now you can check out pull request number ``xxxx`` by running ``git pr xxxx``. -Rebase on to master -=================== +Rebase on to ``main`` +===================== -Now that you have the code, you should rebase the commits on to the ``master`` branch. +Now that you have the code, you should rebase the commits on to the ``main`` branch. Rebasing is preferred over merging, as merge commits make the commit history harder to read for small changes. @@ -54,13 +54,13 @@ depending on which will be more readable in the commit history. $ # Get the latest commits from Wagtail $ git fetch upstream - $ git checkout master - $ git merge --ff-only upstream/master - $ # Rebase this pull request on to master + $ git checkout main + $ git merge --ff-only upstream/main + $ # Rebase this pull request on to main $ git checkout pr/xxxx - $ git rebase master - $ # Update master to this commit - $ git checkout master + $ git rebase main + $ # Update main to this commit + $ git checkout main $ git merge --ff-only pr/xxxx Update ``CHANGELOG.txt`` and release notes @@ -117,18 +117,18 @@ The commit message should say ``Release notes for #xxxx``: $ git add CHANGELOG.txt docs/releases/x.x.x.rst CONTRIBUTORS.rst $ git commit -m 'Release notes for #xxxx' -Push to master -============== +Push to ``main`` +================ -The changes are ready to be pushed to ``master`` now. +The changes are ready to be pushed to ``main`` now. .. code-block:: console $ # Check that everything looks OK - $ git log upstream/master..master --oneline - $ git push --dry-run upstream master + $ git log upstream/main..main --oneline + $ git push --dry-run upstream main $ # Push the commits! - $ git push upstream master + $ git push upstream main $ git branch -d pr/xxxx When you have made a mistake diff --git a/docs/contributing/release_process.rst b/docs/contributing/release_process.rst index a55c596bf8..f6dd861106 100644 --- a/docs/contributing/release_process.rst +++ b/docs/contributing/release_process.rst @@ -89,10 +89,10 @@ Supported versions At any moment in time, Wagtail's developer team will support a set of releases to varying levels. -* The current development master will get new features and bug fixes +* The current development ``main`` will get new features and bug fixes requiring non-trivial refactoring. -* Patches applied to the master branch must also be applied to the last feature +* Patches applied to the ``main`` branch must also be applied to the last feature release branch, to be released in the next patch release of that feature series, when they fix critical problems: @@ -110,7 +110,7 @@ varying levels. release for bugs that would have prevented a release in the first place (release blockers). -* Security fixes and data loss bugs will be applied to the current master, the +* Security fixes and data loss bugs will be applied to the current ``main``, the last feature release branch, and any other supported long-term support release branches. @@ -123,16 +123,16 @@ varying levels. As a concrete example, consider a moment in time halfway between the release of Wagtail 1.6 and 1.7. At this point in time: -* Features will be added to ``master``, to be released as Wagtail 1.7. +* Features will be added to ``main``, to be released as Wagtail 1.7. * Critical bug fixes will be applied to the ``stable/1.6.x`` branch, and released as 1.6.1, 1.6.2, etc. * Security fixes and bug fixes for data loss issues will be applied to - ``master`` and to the ``stable/1.6.x`` and ``stable/1.4.x`` (LTS) branches. + ``main`` and to the ``stable/1.6.x`` and ``stable/1.4.x`` (LTS) branches. They will trigger the release of ``1.6.1``, ``1.4.8``, etc. -* Documentation fixes will be applied to master, and, if easily backported, to +* Documentation fixes will be applied to ``main``, and, if easily backported, to the latest stable branch, ``1.6.x``. Supported versions of Django @@ -187,7 +187,7 @@ get everything on it done. At the end of phase two, any unfinished features will be postponed until the next release. -At this point, the ``stable/A.B.x`` branch will be forked from ``master``. +At this point, the ``stable/A.B.x`` branch will be forked from ``main``. Phase three: bugfixes ~~~~~~~~~~~~~~~~~~~~~ @@ -208,7 +208,7 @@ candidate - this ensures that translators have the full period between the relea candidate and the final release to bring translations up to date. Translations will be re-imported immediately before the final release. -In parallel to this phase, ``master`` can receive new features, to be released +In parallel to this phase, ``main`` can receive new features, to be released in the ``A.B+1`` cycle. Bug-fix releases @@ -218,7 +218,7 @@ After a feature release (e.g. A.B), the previous release will go into bugfix mode. The branch for the previous feature release (e.g. ``stable/A.B-1.x``) will -include bugfixes. Critical bugs fixed on master must *also* be fixed on the +include bugfixes. Critical bugs fixed on ``main`` must *also* be fixed on the bugfix branch; this means that commits need to cleanly separate bug fixes from -feature additions. The developer who commits a fix to master will be +feature additions. The developer who commits a fix to ``main`` will be responsible for also applying the fix to the current bugfix branch. diff --git a/docs/contributing/security.md b/docs/contributing/security.md index 7d2d7a2c47..5ac6141a7e 100644 --- a/docs/contributing/security.md +++ b/docs/contributing/security.md @@ -20,7 +20,7 @@ Django security issues should be reported directly to the Django Project, follow At any given time, the Wagtail team provides official security support for several versions of Wagtail: -- The master development branch, hosted on GitHub, which will become the next release of Wagtail, receives security support. +- The ``main`` development branch, hosted on GitHub, which will become the next release of Wagtail, receives security support. - The two most recent Wagtail release series receive security support. For example, during the development cycle leading to the release of Wagtail 2.6, support will be provided for Wagtail 2.5 and Wagtail 2.4. Upon the release of Wagtail 2.6, Wagtail 2.4's security support will end. diff --git a/docs/editor_manual/new_pages/inserting_videos.rst b/docs/editor_manual/new_pages/inserting_videos.rst index 299aefc990..a96192ef50 100644 --- a/docs/editor_manual/new_pages/inserting_videos.rst +++ b/docs/editor_manual/new_pages/inserting_videos.rst @@ -14,5 +14,5 @@ It is possible to embed media into the body text of a web page by clicking the * * A placeholder of the media will be inserted into the text area. -The embed button can be used to import media from a number of supported providers, you can see the `full list of supported providers in Wagtail’s source code `_. +The embed button can be used to import media from a number of supported providers, you can see the `full list of supported providers in Wagtail’s source code `_. diff --git a/docs/reference/settings.rst b/docs/reference/settings.rst index 73f4066110..ccd3e1effa 100644 --- a/docs/reference/settings.rst +++ b/docs/reference/settings.rst @@ -31,9 +31,9 @@ When ``WAGTAIL_APPEND_SLASH`` is ``False``, requests to Wagtail pages will be se .. note:: - If you use the ``False`` setting, keep in mind that serving your pages both with and without slashes may affect search engines' ability to index your site. See `this Google Webmaster Blog post`_ for more details. + If you use the ``False`` setting, keep in mind that serving your pages both with and without slashes may affect search engines' ability to index your site. See `this Google Search Central Blog post`_ for more details. -.. _this Google Webmaster Blog post: https://webmasters.googleblog.com/2010/04/to-slash-or-not-to-slash.html +.. _this Google Search Central Blog post: https://developers.google.com/search/blog/2010/04/to-slash-or-not-to-slash Search ====== diff --git a/docs/releases/0.7.rst b/docs/releases/0.7.rst index 29e9347c08..d150a4afb2 100644 --- a/docs/releases/0.7.rst +++ b/docs/releases/0.7.rst @@ -100,5 +100,5 @@ Update to ``focal_point_key`` field on custom Rendition models The ``focal_point_key`` field on wagtailimages.Rendition has been changed to ``null=False``, to fix an issue with duplicate renditions being created. If you have defined a custom Rendition model in your project (by extending the ``wagtailimages.AbstractRendition`` class), you will need to apply a migration to make the corresponding change on your custom model. Unfortunately neither South nor Django 1.7's migration system are able to generate this automatically - you will need to customise the migration produced by ``./manage.py schemamigration`` / ``./manage.py makemigrations``, using the wagtailimages migration as a guide: -- https://github.com/wagtail/wagtail/blob/master/wagtail/wagtailimages/south_migrations/0004_auto__chg_field_rendition_focal_point_key.py (for South / Django 1.6) -- https://github.com/wagtail/wagtail/blob/master/wagtail/wagtailimages/migrations/0004_make_focal_point_key_not_nullable.py (for Django 1.7) + - https://github.com/wagtail/wagtail/blob/stable/0.7.x/wagtail/wagtailimages/south_migrations/0004_auto__chg_field_rendition_focal_point_key.py (for South / Django 1.6) + - https://github.com/wagtail/wagtail/blob/stable/0.7.x/wagtail/wagtailimages/migrations/0004_make_focal_point_key_not_nullable.py (for Django 1.7) diff --git a/wagtail/admin/static_src/wagtailadmin/js/vendor/bootstrap-transition.js b/wagtail/admin/static_src/wagtailadmin/js/vendor/bootstrap-transition.js index 36141c4fc3..fb38686f1d 100644 --- a/wagtail/admin/static_src/wagtailadmin/js/vendor/bootstrap-transition.js +++ b/wagtail/admin/static_src/wagtailadmin/js/vendor/bootstrap-transition.js @@ -3,7 +3,7 @@ * http://getbootstrap.com/javascript/#transitions * ======================================================================== * Copyright 2011-2014 Twitter, Inc. - * Licensed under MIT (https://github.com/twbs/bootstrap/blob/master/LICENSE) + * Licensed under MIT (https://github.com/twbs/bootstrap/blob/main/LICENSE) * ======================================================================== */