Merge branch 'codeigniter4:develop' into 4.6-servicesreload

Author: pyromanci

admin/userguide/.github/scripts/deploy

@@ -2,7 +2,8 @@
 
 # Deploys the User Guide to the production
 # website. Triggered by updates to the GitHub
-# repo's master branch.
+# codeigniter4/userguide repo's master branch.
+# See https://github.com/codeigniter4/userguide/blob/master/.github/workflows/deploy.yml
 
 REPO=/opt/userguide
 SITE=/home/public_html/userguides/userguide4
@@ -11,5 +12,7 @@ cd "$REPO"
 git switch master
 git pull
 
-rm -rf "$SITE"
-cp -R "$REPO/docs" "$SITE"
+cp -R "$REPO/docs" "$SITE.new"
+mv "$SITE" "$SITE.old"
+mv "$SITE.new" "$SITE"
+rm -rf "$SITE.old"

contributing/pull_request.md

@@ -200,10 +200,13 @@ working on your contribution.
 
 ### Branching
 
-All bug fixes should be sent to the __"develop"__ branch, this is where the next
-bug fix version will be developed.
+- All bug fix PRs should be sent to the __"develop"__ branch, this is where the
+  next bug fix version will be developed.
+- PRs with any enhancement should be sent to next minor version branch, e.g. __"4.6"__
 
-PRs with any enhancement should be sent to next minor version branch, e.g. __"4.6"__
+> [!NOTE]
+> If you sent your PR to the wrong branch, see
+> [Contribution Workflow](./workflow.md#if-you-sent-to-the-wrong-branch).
 
 The __"master"__ branch will always contain the latest stable version and is kept
 clean so a "hotfix" (e.g. an emergency security patch) can be applied to the
@@ -235,6 +238,10 @@ This is *not* just a "signed-off-by" commit, but instead, a digitally signed one
 
 See [Contribution signing](./signing.md) for details.
 
+> [!NOTE]
+> If you forgot GPG-signing your commits, see
+> [Contribution Workflow](./workflow.md#gpg-signing-old-commits).
+
 ### Static Analysis on PHP code
 
 We cannot, at all times, guarantee that all PHP code submitted on pull requests

contributing/workflow.md

@@ -18,7 +18,7 @@ values for when you try these:
 
 - All bug fix PRs should be sent to the __"develop"__ branch, this is where the
   next bug fix version will be developed.
-- PRs with any enhancement should be sent to next minor version branch, e.g. __"4.5"__
+- PRs with any enhancement should be sent to next minor version branch, e.g. __"4.6"__
 
 The "master" branch will always contain the latest stable
 version and is kept clean so a "hotfix" (e.g: an emergency security
@@ -114,7 +114,7 @@ is optional, and implies a sort of namespacing if used.
 
 - All bug fix PRs should be sent to the __"develop"__ branch, this is where the
   next bug fix version will be developed.
-- PRs with any enhancement should be sent to next minor version branch, e.g. __"4.5"__
+- PRs with any enhancement should be sent to next minor version branch, e.g. __"4.6"__
 
 For instance, if you send a PR to __"develop"__ branch, make sure you are in the
 *develop* branch, and create a new bugfix branch, based on *develop*, for a new
@@ -126,11 +126,11 @@ feature you are creating:
 ```
 
 If you send a PR with an enhancement, make sure you are in the *next minor version*
-branch, and create a new feature branch, based on, e.g., __"4.5"__, for a new
+branch, and create a new feature branch, based on, e.g., __"4.6"__, for a new
 feature you are creating:
 
 ```console
-> git switch 4.5
+> git switch 4.6
 > git switch -c new/mind-reader
 ```
 
@@ -283,7 +283,7 @@ switching to the branch you wish to contribute, and then clicking on
 "New pull request".
 
 Make sure the pull request is for the shared __"develop"__ or next minor version
-branch, e.g. __"4.5"__, or it may be rejected.
+branch, e.g. __"4.6"__, or it may be rejected.
 
 Make sure that the PR title is helpful for the maintainers and other
 developers. Add any comments appropriate, for instance asking for
@@ -324,7 +324,7 @@ And if your PRs have the breaking changes, label the following label:
 If you are asked for changes in the review, commit the fix in your branch and
 push it to GitHub again.
 
-If the __"develop"__ or next minor version branch, e.g. __"4.5"__, progresses
+If the __"develop"__ or next minor version branch, e.g. __"4.6"__, progresses
 and conflicts arise that prevent merging, or if you are asked to *rebase*,
 do the following:
 
@@ -364,7 +364,7 @@ And finally push your local branch to your GitHub repository:
 
 If you have sent a PR to the wrong branch, you need to create a new PR branch.
 
-When you have the PR branch `feat-abc` and you should have sent the PR to __"4.5"__,
+When you have the PR branch `feat-abc` and you should have sent the PR to __"4.6"__,
 but you created the PR branch from `develop` and sent a PR.
 
 Copy the IDs of any commits you made that you want to keep:
@@ -373,13 +373,13 @@ Copy the IDs of any commits you made that you want to keep:
 > git log
 ```
 
-Update your __"4.5"__ branch:
+Update your __"4.6"__ branch:
 
 ```console
 > git fetch upstream
-> git switch 4.5
-> git merge upstream/4.5
-> git push origin 4.5
+> git switch 4.6
+> git merge upstream/4.6
+> git push origin 4.6
 ```
 
 (Optional) Create a new branch as a backup, just in case:
@@ -388,10 +388,10 @@ Update your __"4.5"__ branch:
 > git branch feat-abc.bk feat-abc
 ```
 
-Rebase your PR branch from `develop` onto __"4.5"__:
+Rebase your PR branch from `develop` onto __"4.6"__:
 
 ```console
-> git rebase --onto 4.5 develop feat-abc
+> git rebase --onto 4.6 develop feat-abc
 ```
 
 Force push.
@@ -400,7 +400,7 @@ Force push.
 > git push --force-with-lease origin feat-abc
 ```
 
-On the GitHub PR page, change the base branch to the correct branch __"4.5"__.
+On the GitHub PR page, change the base branch to the correct branch __"4.6"__.
 
 ## Cleanup
 

user_guide_src/source/libraries/uri.rst

@@ -39,8 +39,8 @@ Since v4.4.0, if you don't pass a URL, it returns the current URI:
 The Current URI
 ---------------
 
-Many times, all you really want is an object representing the current URL of this request.
-You can use the :php:func:`current_url()` function available in the :doc:`../helpers/url_helper`:
+When you need an object representing the current URL of the request,
+you can use the :php:func:`current_url()` function available in the :doc:`../helpers/url_helper`:
 
 .. literalinclude:: uri/004.php
     :lines: 2-
@@ -141,12 +141,12 @@ When using the ``setPort()`` method, the port will be checked that it is within
 Path
 ----
 
-The path are all of the segments within the site itself. As expected, the ``getPath()`` and ``setPath()`` methods
+The path is all of the segments within the site itself. As expected, the ``getPath()`` and ``setPath()`` methods
 can be used to manipulate it:
 
 .. literalinclude:: uri/016.php
 
-.. note:: When setting the path this way, or any other way the class allows, it is sanitized to encode any dangerous
+.. note:: When setting the path it is sanitized to encode any dangerous
     characters, and remove dot segments for safety.
 
 .. note:: Since v4.4.0, the ``SiteURI::getRoutePath()`` method,
@@ -166,7 +166,7 @@ be set as a string currently.
 
 .. literalinclude:: uri/017.php
 
-The ``setQuery()`` method overwrite any existing query variables.
+The ``setQuery()`` method overwrites existing query variables.
 
 .. note:: Query values cannot contain fragments. An InvalidArgumentException will be thrown if it does.
 
@@ -177,7 +177,7 @@ You can set query values using an array:
 
 .. literalinclude:: uri/018.php
 
-The ``setQueryArray()`` method overwrite any existing query variables.
+The ``setQueryArray()`` method overwrites existing query variables.
 
 Adding Query Value
 ^^^^^^^^^^^^^^^^^^
@@ -196,11 +196,12 @@ You can filter the query values returned by passing an options array to the ``ge
 
 .. literalinclude:: uri/020.php
 
-This only changes the values returned during this one call. If you need to modify the URI's query values more permanently,
+This only changes the values returned during this one call.
 
 Changing Query Values
 ^^^^^^^^^^^^^^^^^^^^^
 
+If you need to modify the URI's query values more permanently,
 you can use the ``stripQuery()`` and ``keepQuery()`` methods to change the actual object's query variable collection:
 
 .. literalinclude:: uri/021.php