From a128941d66a5b1e7c8e25dec0d51594319babd04 Mon Sep 17 00:00:00 2001 From: 3Dgoo Date: Fri, 16 Jun 2017 06:38:53 +0930 Subject: [PATCH 1/2] Documentation link fixes Removing defunct silverstripe-labs github link. Fixing up some broken links. Making links https if they can be https. --- docs/en/05_Contributing/01_Code.md | 28 ++++++++++++++-------------- 1 file changed, 14 insertions(+), 14 deletions(-) diff --git a/docs/en/05_Contributing/01_Code.md b/docs/en/05_Contributing/01_Code.md index 7b6f3aed2..647201de1 100644 --- a/docs/en/05_Contributing/01_Code.md +++ b/docs/en/05_Contributing/01_Code.md @@ -6,10 +6,10 @@ summary: Fix bugs and add new features to help make SilverStripe better. SilverStripe will never be finished, and we need your help to keep making it better. If you're a developer a great way to get involved is to contribute patches to our modules and core codebase, fixing bugs or adding features. The SilverStripe core modules (`framework` and `cms`), as well as some of the more popular modules are in -git version control. SilverStripe hosts its modules on [github.com/silverstripe](http://github.com/silverstripe) and [github.com/silverstripe-labs](http://github.com/silverstripe-labs). After [installing git](http://help.github.com/git-installation-redirect) and creating a [free github.com account](https://github.com/signup/free), you can "fork" a module, -which creates a copy that you can commit to (see github's [guide to "forking"](http://help.github.com/forking/)). +git version control. SilverStripe hosts its modules on [github.com/silverstripe](https://github.com/silverstripe/). After [installing git](https://help.github.com/articles/set-up-git/) and creating a [free github.com account](https://github.com/join/), you can "fork" a module, +which creates a copy that you can commit to (see github's [guide to "forking"](https://help.github.com/articles/fork-a-repo/)). -For other modules, our [add-ons site](http://addons.silverstripe.org/add-ons) lists the repository locations, typically using the version control system like "git". +For other modules, our [add-ons site](https://addons.silverstripe.org/add-ons/) lists the repository locations, typically using the version control system like "git".
Note: By supplying code to the SilverStripe core team in patches, tickets and pull requests, you agree to assign copyright of that code to SilverStripe Limited, on the condition that SilverStripe Limited releases that code under the BSD license. @@ -142,12 +142,12 @@ The current GitHub labels are grouped into 5 sections: ### Workflow Diagram -[![Workflow diagram](http://www.silverstripe.org/assets/doc-silverstripe-org/collaboration-on-github.png)](http://www.silverstripe.org/assets/doc-silverstripe-org/collaboration-on-github.png) +[![Workflow diagram](https://www.silverstripe.org/assets/doc-silverstripe-org/collaboration-on-github.png)](https://www.silverstripe.org/assets/doc-silverstripe-org/collaboration-on-github.png) ### Quickfire Do's and Don't's -If you aren't familiar with git and GitHub, try reading the ["GitHub bootcamp documentation"](http://help.github.com/). -We also found the [free online git book](http://git-scm.com/book/) and the [git crash course](http://gitref.org/) useful. +If you aren't familiar with git and GitHub, try reading the ["GitHub bootcamp documentation"](https://help.github.com/). +We also found the [free online git book](https://git-scm.com/book/en/v2) and the [git crash course](https://services.github.com/) useful. If you're familiar with it, here's the short version of what you need to know. Once you fork and download the code: * **Don't develop on the master branch.** Always create a development branch specific to "the issue" you're working on (on our [GitHub repository's issues](https://github.com/silverstripe/silverstripe-framework/issues)). Name it by issue number and description. For example, if you're working on Issue #100, a `DataObject::get_one()` bugfix, your development branch should be called 100-dataobject-get-one. If you decide to work on another issue mid-stream, create a new branch for that issue--don't work on both in one branch. @@ -173,15 +173,15 @@ After you have edited the file, GitHub will offer to create a pull request for y * When working on existing tickets, provide status updates through ticket comments * Check your patches against the "master" branch, as well as the latest release branch * Write [unit tests](../developer_guides/testing/unit_testing) -* Write [Behat integration tests](https://github.com/silverstripe-labs/silverstripe-behat-extension) for any interface changes +* Write [Behat integration tests](https://github.com/silverstripe/silverstripe-behat-extension) for any interface changes * Describe specifics on how to test the effects of the patch * It's better to submit multiple patches with separate bits of functionality than a big patch containing lots of changes * Only submit a pull request for work you expect to be ready to merge. Work in progress is best discussed in an issue, or on your own repository fork. -* Document your code inline through [PHPDoc](http://en.wikipedia.org/wiki/PHPDoc) syntax. See our -[API documentation](http://api.silverstripe.org/3.1/) for good examples. -* Check and update documentation on [docs.silverstripe.org](http://docs.silverstripe.org). Check for any references to functionality deprecated or extended through your patch. Documentation changes should be included in the patch. +* Document your code inline through [PHPDoc](https://en.wikipedia.org/wiki/PHPDoc) syntax. See our +[API documentation](https://api.silverstripe.org/3.5/) for good examples. +* Check and update documentation on [docs.silverstripe.org](https://docs.silverstripe.org). Check for any references to functionality deprecated or extended through your patch. Documentation changes should be included in the patch. * When introducing something "noteworthy" (new feature, API change), [update the release changelog](/changelogs) for the next release this commit will be included in. -* If you get stuck, please post to the [forum](http://silverstripe.org/forum) or for deeper core problems, to the [core mailinglist](https://groups.google.com/forum/#!forum/silverstripe-dev) +* If you get stuck, please post to the [forum](https://www.silverstripe.org/community/forums) or for deeper core problems, to the [core mailinglist](https://groups.google.com/forum/#!forum/silverstripe-dev) * When working with the CMS, please read the ["CMS Architecture Guide"](/developer_guides/customising_the_admin_interface/cms_architecture) first ## Commit Messages @@ -191,7 +191,7 @@ Most importantly: Keep the first line short, and add more detail below. This ensures commits are easy to browse, and look nice on github.com (more info about [proper git commit messages](http://tbaggery.com/2008/04/19/a-note-about-git-commit-messages.html)). -As we automatically generate [changelogs](http://localhost/SpiritLevel/SS/doc.silverstripe.org/en/changelogs/) from them, we need a way to categorize and filter. +As we automatically generate [changelogs](https://docs.silverstripe.org/en/changelogs/) from them, we need a way to categorize and filter. Please prefix **noteworthy** commit messages with one of the following tags: * `NEW` New feature or major enhancement (both for users and developers) @@ -206,7 +206,7 @@ Same goes for version control plumbing like merges, file renames or reverts. Further guidelines: * Each commit should form a logical unit - if you fix two unrelated bugs, commit each one separately -* If you are fixing a issue from our bugtracker ([cms](http://github.com/silverstripe/silverstripe-framework) and [framework](http://github.com/silverstripe/silverstripe-framework)), please append `(fixes #)` +* If you are fixing a issue from our bugtracker ([cms](https://github.com/silverstripe/silverstripe-framework) and [framework](https://github.com/silverstripe/silverstripe-framework)), please append `(fixes #)` * When fixing issues across repos (e.g. a commit to `framework` fixes an issue raised in the `cms` bugtracker), use `(fixes silverstripe/silverstripe-cms#)` ([details](https://github.com/blog/1439-closing-issues-across-repositories)) * If your change is related to another commit, reference it with its abbreviated commit hash. @@ -344,7 +344,7 @@ It's as if you had just started your branch. One immediate advantage you get is So when you're ready to send the new plugin upstream, you do one last rebase, test, and then merge (which is really no merge at all) and send out your pull request. Then in most cases, we have a simple fast-forward on our end (or at worst a very small rebase or merge) and over time that adds up to a simpler tree. -More info on the ["Rebasing" chapter on git-scm.com](http://git-scm.com/book/ch3-6.html) and the [git rebase man page](http://www.kernel.org/pub/software/scm/git/docs/git-rebase.html). +More info on the ["Rebasing" chapter on git-scm.com](http://git-scm.com/book/ch3-6.html) and the [git rebase man page](https://www.kernel.org/pub/software/scm/git/docs/git-rebase.html). ## License From 1e887c06315fd80678604f6061c40a941d1e566d Mon Sep 17 00:00:00 2001 From: 3Dgoo Date: Mon, 19 Jun 2017 07:09:41 +0930 Subject: [PATCH 2/2] Future proofing api link --- docs/en/05_Contributing/01_Code.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/en/05_Contributing/01_Code.md b/docs/en/05_Contributing/01_Code.md index 647201de1..ed39c8e24 100644 --- a/docs/en/05_Contributing/01_Code.md +++ b/docs/en/05_Contributing/01_Code.md @@ -178,7 +178,7 @@ After you have edited the file, GitHub will offer to create a pull request for y * It's better to submit multiple patches with separate bits of functionality than a big patch containing lots of changes * Only submit a pull request for work you expect to be ready to merge. Work in progress is best discussed in an issue, or on your own repository fork. * Document your code inline through [PHPDoc](https://en.wikipedia.org/wiki/PHPDoc) syntax. See our -[API documentation](https://api.silverstripe.org/3.5/) for good examples. +[API documentation](https://api.silverstripe.org/) for good examples. * Check and update documentation on [docs.silverstripe.org](https://docs.silverstripe.org). Check for any references to functionality deprecated or extended through your patch. Documentation changes should be included in the patch. * When introducing something "noteworthy" (new feature, API change), [update the release changelog](/changelogs) for the next release this commit will be included in. * If you get stuck, please post to the [forum](https://www.silverstripe.org/community/forums) or for deeper core problems, to the [core mailinglist](https://groups.google.com/forum/#!forum/silverstripe-dev)