mirror of
https://github.com/silverstripe/silverstripe-framework
synced 2024-10-22 14:05:37 +02:00
DOCS: correct broken links
- Correct internal links between documentation pages - Delete defunct links to documentation removed during documentation reorganization - Restore testing glossary - Verify by crawling site locally
This commit is contained in:
Fred Condo
parent
2298bed4e9
commit
82ed86f6cd
@ -4,7 +4,7 @@ SilverStripe CMS needs to be installed on a web server. Content authors and webs
|
||||
to access a web-based GUI to do their day-to-day work. Website designers and developers require access to the files on
|
||||
the server to update templates, website logic, and perform upgrades or maintenance.
|
||||
|
||||
Our web-based [PHP installer](/installation) can check if you meet the requirements listed below.
|
||||
Our web-based [PHP installer](installation/) can check if you meet the requirements listed below.
|
||||
|
||||
## Web server software requirements
|
||||
|
||||
|
||||
@ -2,7 +2,7 @@
|
||||
|
||||
SilverStripe should be able to be installed on any Linux, Unix or *nix like OS as long as the correct server software is installed and configured (referred to a *nix in this document from herein). It is common that web hosting that you may use for your production SilverStripe application will be *nix based, here you may also want to use *nix locally to ensure how you develop locally mimics closely your production environment.
|
||||
|
||||
Is important to ensure you check the [Server Requirements](/Getting_Started/Installation/Server_Requirements) list before acquiring and installing SilverStripe on your *nix server (locally or otherwise).
|
||||
Is important to ensure you check the [Server Requirements](/getting_started/server_requirements) list before acquiring and installing SilverStripe on your *nix server (locally or otherwise).
|
||||
|
||||
At a high level you will need a:
|
||||
* Web server e.g. Apache, Nginx
|
||||
@ -12,7 +12,7 @@ At a high level you will need a:
|
||||
##*nix installation guides on the web
|
||||
There are a number of good step by step guides covering server setups and installing of SilverStripe on the various flavours of *nix systems.
|
||||
|
||||
Note: Many of the following guides simply download SilverStripe as a zipped file. We recommend the use of [Composer](/Getting_Started/Composer/) once you get to the point of installing SilverStripe (though the choice is up to you). Always ensure you get the latest version if you are starting a new project.
|
||||
Note: Many of the following guides simply download SilverStripe as a zipped file. We recommend the use of [Composer](/getting_started/composer/) once you get to the point of installing SilverStripe (though the choice is up to you). Always ensure you get the latest version if you are starting a new project.
|
||||
|
||||
###Known (but not exhaustive) list
|
||||
* [How To Install Silverstripe on Your VPS](https://www.digitalocean.com/community/tutorials/how-to-install-silverstripe-on-your-vps)
|
||||
|
||||
@ -5,7 +5,7 @@ done through [WampServer](http://www.wampserver.com/en/). This can be useful if
|
||||
want a Microsoft Windows machine with a very similar environment.
|
||||
|
||||
Note: Installing on Microsoft's IIS webserver through Microsoft WebPI is likely to be easier, see
|
||||
[installation-on-windows-pi](windows-pi).
|
||||
[Windows with Web Platform Installer](other_installation_options/windows_platform_installer).
|
||||
|
||||
## Install WAMP
|
||||
|
||||
|
||||
@ -73,11 +73,11 @@ every page on the site, if that's easier.
|
||||
|
||||
Please make sure all code inside `*.php` files is wrapped in classes. Due to the way `[api:ManifestBuilder]`
|
||||
includes all files with this extension, any **procedural code will be executed on every call**. The most common error here
|
||||
is putting a test.php/phpinfo.php file in the document root. See [datamodel](/topics/datamodel) and [controllers](/topics/controller)
|
||||
is putting a test.php/phpinfo.php file in the document root. See [datamodel](/developer_guides/data_model_and_orm) and [controllers](/developer_guides/controllers)
|
||||
for ways how to structure your code.
|
||||
|
||||
Also, please check that you have PHP enabled on the webserver, and you're running PHP 5.1 or later.
|
||||
The web-based [SilverStripe installer](/installation) can help you with this.
|
||||
The web-based [SilverStripe installer](/getting_started/installation) can help you with this.
|
||||
|
||||
## I've got file permission problems during installation
|
||||
|
||||
|
||||
@ -107,4 +107,4 @@ e.g. `/etc/nginx/sites-enabled/mysite`:
|
||||
include /etc/nginx/silverstripe.conf;
|
||||
}
|
||||
|
||||
For more information on nginx configuration, please see the [nginx installation](nginx) page.
|
||||
For more information on nginx configuration, please see the [nginx installation](configure_nginx) page.
|
||||
|
||||
@ -3,12 +3,12 @@
|
||||
These instructions show you how to install SilverStripe on any web server.
|
||||
The best way to install from the source code is to use [Composer](../composer).
|
||||
Check out our operating system specific guides for [Linux](linux_unix),
|
||||
[Windows Server](windows-pi) and [Mac OSX](mac-osx).
|
||||
[Windows Server](windows) and [Mac OSX](mac_osx).
|
||||
|
||||
## Installation Steps
|
||||
|
||||
* [Download](http://silverstripe.org/download) the installer package
|
||||
* Make sure the webserver has MySQL and PHP support. See [Server Requirements](server-requirements) for more information.
|
||||
* Make sure the webserver has MySQL and PHP support. See [Server Requirements](../server_requirements) for more information.
|
||||
* Unpack the installer somewhere into your web-root. Usually the www folder or similar. Most downloads from SilverStripe
|
||||
are compressed tarballs. To extract these files you can either do them natively (Unix) or with 7-Zip (Windows)
|
||||
* Visit your sites domain or IP address in your web browser.
|
||||
@ -18,7 +18,7 @@ name' and the default login details. Follow the questions and select the *instal
|
||||
|
||||
## Issues?
|
||||
|
||||
If the above steps don't work for any reason have a read of the [Common Problems](common-problems) section.
|
||||
If the above steps don't work for any reason have a read of the [Common Problems](common_problems) section.
|
||||
|
||||
<div class="notice" markdown="1">
|
||||
SilverStripe ships with default rewriting rules specific to your web server. Apart from
|
||||
|
||||
@ -3,7 +3,7 @@
|
||||
Composer is a package management tool for PHP that lets you install and upgrade SilverStripe and its modules. Although installing Composer is one extra step, it will give you much more flexibility than just downloading the file from silverstripe.org. This is our recommended way of downloading SilverStripe and managing your code.
|
||||
|
||||
For more information about Composer, visit [its website](http://getcomposer.org/).
|
||||
We also have separate instructions for [installing modules with Composer](/topics/modules).
|
||||
We also have separate instructions for [installing modules with Composer](/developer_guides/extending/modules).
|
||||
|
||||
# Basic usage
|
||||
|
||||
@ -36,7 +36,7 @@ If you already have composer installed you can update it by running:
|
||||
Composer updates regularly, so you should run this command fairly often. These instructions assume you are running the latest version.
|
||||
|
||||
## Installing Composer on Windows WAMP
|
||||
For those that use WAMP as a development environment, [detailed information is available on installing using Composer.](/installation/windows-wamp#install-wamp)
|
||||
For those that use WAMP as a development environment, [detailed information is available on installing using Composer.](/getting_started/installation/windows)
|
||||
|
||||
## Create a new site
|
||||
|
||||
@ -139,7 +139,7 @@ and remove the `@stable` markers from the `silverstripe/cms` and `silverstripe/f
|
||||
Another `composer update --dev` call will now fetch from the development branch instead.
|
||||
Note that you can also convert an existing composer project with these steps.
|
||||
|
||||
Please read the ["Contributing Code"](/misc/contributing/code) documentation to find out how to
|
||||
Please read the ["Contributing Code"](/contributing/code) documentation to find out how to
|
||||
create forks and send pull requests.
|
||||
|
||||
# Advanced usage
|
||||
@ -290,9 +290,9 @@ which triggers their installation into the correct path.
|
||||
|
||||
### How do I convert an existing project to Composer?
|
||||
|
||||
The easiest way is to follow the [upgrading](/installation/upgrading) instructions
|
||||
and switch to a newer release. Alternatively, copy the `composer.json` file from
|
||||
a newer release, and adjust the version settings in the "require" section to your needs.
|
||||
Copy the `composer.json` file from a newer release, and adjust the
|
||||
version settings in the "require" section to your needs. Then refer to
|
||||
the [upgrading documentation](/upgrading).
|
||||
You'll also need to update your webserver configuration
|
||||
from there (`.htaccess` or `web.config` files), in order to prevent
|
||||
web access to the composer-generated files.
|
||||
|
||||
@ -117,7 +117,7 @@ Example: `mysite/code/MyClass.php`
|
||||
|
||||
To help with namespacing common class names (like Database) it is recommended to use a prefix convention `SS_ClassName` but the filename will remain `ClassName.php`.
|
||||
|
||||
See [directory-structure](/topics/directory-structure) for more information.
|
||||
See [directory structure](directory_structure) for more information.
|
||||
|
||||
## Coding Style
|
||||
|
||||
@ -450,5 +450,4 @@ which are licensed under BSD (see [license](http://framework.zend.com/license)).
|
||||
|
||||
## Related
|
||||
|
||||
* [Topics: CSS](/topics/css)
|
||||
* [Reference: CMS Architecture](/reference/cms-archirecture)
|
||||
* [Reference: CMS Architecture](/developer_guides/customising_the_admin_interface/cms_architecture)
|
||||
|
||||
@ -178,7 +178,7 @@ would create a new tab called "New Tab", and a single "Author" textfield inside.
|
||||
</div>
|
||||
|
||||
We have added two fields: A simple `[api:TextField]` and a `[api:DateField]`.
|
||||
There are many more fields available in the default installation, listed in ["form field types"](/developer_guides/forms/fields/common_subclasses).
|
||||
There are many more fields available in the default installation, listed in ["form field types"](/developer_guides/forms/field_types/common_subclasses).
|
||||
|
||||
:::php
|
||||
return $fields;
|
||||
|
||||
@ -9,7 +9,7 @@ This tutorial is deprecated, and has been replaced by Lessons 7, 8, 9, and 10 in
|
||||
|
||||
## Overview
|
||||
|
||||
This tutorial explores the relationship and management of [DataObjects](/developer_guides/model/dataobject). It builds on the [second tutorial](/tutorials/extending_a_basic_site) where we learnt how to define
|
||||
This tutorial explores the relationship and management of [DataObjects](api:DataObject). It builds on the [second tutorial](/tutorials/extending_a_basic_site) where we learnt how to define
|
||||
additional fields on our models, and attach images to them.
|
||||
|
||||
## What are we working towards?
|
||||
@ -65,8 +65,9 @@ Let's create the `Student` and `Project` objects.
|
||||
The relationships are defined through the `$has_one`
|
||||
and `$has_many` properties on the objects.
|
||||
The array keys declares the name of the relationship,
|
||||
the array values contain the class name (see the ["database structure"](/developer_guides/model/database_structure)
|
||||
and ["datamodel"](/developer_guides/model/data_model_and_orm) topics for more information).
|
||||
the array values contain the class name
|
||||
(see the ["datamodel"](/developer_guides/model/data_model_and_orm)
|
||||
topic for more information).
|
||||
|
||||
As you can see, only the `Project` model extends `Page`,
|
||||
while `Student` is a plain `DataObject` subclass.
|
||||
|
||||
@ -13,7 +13,7 @@ information.
|
||||
All data tables in SilverStripe are defined as subclasses of [api:DataObject]. The [api:DataObject] class represents a
|
||||
single row in a database table, following the ["Active Record"](http://en.wikipedia.org/wiki/Active_record_pattern)
|
||||
design pattern. Database Columns are is defined as [Data Types](data_types_and_casting) in the static `$db` variable
|
||||
along with any [relationships](../relations) defined as `$has_one`, `$has_many`, `$many_many` properties on the class.
|
||||
along with any [relationships](relations) defined as `$has_one`, `$has_many`, `$many_many` properties on the class.
|
||||
|
||||
Let's look at a simple example:
|
||||
|
||||
@ -222,7 +222,7 @@ Notice that we can step into the loop safely without having to check if `$player
|
||||
// do something here
|
||||
}
|
||||
|
||||
See the [Lists](../lists) documentation for more information on dealing with [api:SS_List] instances.
|
||||
See the [Lists](lists) documentation for more information on dealing with [api:SS_List] instances.
|
||||
|
||||
## Returning a single DataObject
|
||||
|
||||
@ -512,7 +512,7 @@ whenever a new object is created.
|
||||
|
||||
<div class="notice" markdown='1'>
|
||||
Note: Alternatively you can set defaults directly in the database-schema (rather than the object-model). See
|
||||
[Data Types and Casting](data-types) for details.
|
||||
[Data Types and Casting](data_types_and_casting) for details.
|
||||
</div>
|
||||
|
||||
## Subclasses
|
||||
|
||||
@ -54,7 +54,7 @@ Example: Disallow creation of new players if the currently logged-in player is n
|
||||
|
||||
Triggered before executing *delete()* on an existing object.
|
||||
|
||||
Example: Checking for a specific [permission](/reference/permission) to delete this type of object. It checks if a
|
||||
Example: Checking for a specific [permission](permissions) to delete this type of object. It checks if a
|
||||
member is logged in who belongs to a group containing the permission "PLAYER_DELETE".
|
||||
|
||||
:::php
|
||||
|
||||
@ -103,7 +103,7 @@ Creates a map based on the first two columns of the query result.
|
||||
|
||||
## Related Documentation
|
||||
|
||||
* [Introduction to the Data Model and ORM](../data_model_and_orm)
|
||||
* [Introduction to the Data Model and ORM](data_model_and_orm)
|
||||
|
||||
## API Documentation
|
||||
|
||||
|
||||
@ -2,7 +2,7 @@
|
||||
|
||||
The [api:SS_List] class is designed to return a flat list of records.
|
||||
These lists can get quite long, and hard to present on a single list.
|
||||
[Pagination](/howto/pagination) is one way to solve this problem,
|
||||
[Pagination](/templates/how_tos/pagination) is one way to solve this problem,
|
||||
by splitting up the list into multiple pages.
|
||||
|
||||
In this howto, we present an alternative to pagination:
|
||||
@ -144,4 +144,5 @@ The final step is the render this into the template using the [api:GroupedList->
|
||||
|
||||
## Related
|
||||
|
||||
* [Howto: "Pagination"](/howto/pagination)
|
||||
* [Howto: "Pagination"](/templates/how_tos/pagination)
|
||||
|
||||
@ -393,7 +393,7 @@ A page will normally contain some content and potentially a form of some kind. F
|
||||
SilverStripe log-in form. If you are on such a page, the `$Form` variable will contain the HTML content of the form.
|
||||
Placing it just below `$Content` is a good default.
|
||||
|
||||
You can add your own forms by implementing new form instances (see the [Forms tutorial](../tutorials/forms)).
|
||||
You can add your own forms by implementing new form instances (see the [Forms tutorial](/tutorials/forms)).
|
||||
|
||||
|
||||
## Related
|
||||
|
||||
@ -22,7 +22,7 @@ Requiring assets from the template is restricted compared to the PHP API.
|
||||
|
||||
## PHP Requirements API
|
||||
|
||||
It is common practice to include most Requirements either in the *init()*-method of your [controller](../controller), or
|
||||
It is common practice to include most Requirements either in the *init()*-method of your [controller](../controllers/), or
|
||||
as close to rendering as possible (e.g. in `[api:FormField]`.
|
||||
|
||||
:::php
|
||||
|
||||
@ -31,4 +31,4 @@ top level menu with a nested second level using the `Menu` loop and a `Children`
|
||||
## Related
|
||||
|
||||
* [Template Syntax](../syntax)
|
||||
* [Common Variables](../command_variables)
|
||||
* [Common Variables](../common_variables)
|
||||
@ -145,7 +145,7 @@ Controller actions can use `renderWith` to override this template selection proc
|
||||
`htmlaction`. `MyCustomTemplate.ss` would be used rather than `TeamsController`.
|
||||
|
||||
For more information about templates, inheritance and how to rendering into views, See the
|
||||
[Templates and Views](templates) documentation.
|
||||
[Templates and Views](../templates) documentation.
|
||||
|
||||
## Link
|
||||
|
||||
|
||||
@ -1,6 +1,6 @@
|
||||
# How to add a custom action to a GridField row
|
||||
|
||||
In a [GridField](/reference/grid-field) instance each table row can have a
|
||||
In a [GridField](../field_types/gridfield) instance each table row can have a
|
||||
number of actions located the end of the row such as edit or delete actions.
|
||||
Each action is represented as a instance of a specific class
|
||||
(e.g [api:GridFieldEditButton]) which has been added to the `GridFieldConfig`
|
||||
@ -79,7 +79,7 @@ below:
|
||||
|
||||
While we're working on the code, to add this new action to the `GridField`, add
|
||||
a new instance of the class to the [api:GridFieldConfig] object. The `GridField`
|
||||
[Reference](/reference/grid-field) documentation has more information about
|
||||
[Reference](../field_types/gridfield) documentation has more information about
|
||||
manipulating the `GridFieldConfig` instance if required.
|
||||
|
||||
:::php
|
||||
@ -142,6 +142,6 @@ message to the user interface indicating a successful message.
|
||||
|
||||
## Related
|
||||
|
||||
* [GridField Reference](/reference/grid-field)
|
||||
* [ModelAdmin: A UI driven by GridField](/reference/modeladmin)
|
||||
* [Tutorial 5: Dataobject Relationship Management](/tutorials/5-dataobject-relationship-management)
|
||||
* [GridField Reference](/developer_guides/forms/field_types/gridfield)
|
||||
* [ModelAdmin: A UI driven by GridField](/developer_guides/customising_the_admin_interface/modeladmin)
|
||||
* [Tutorial 5: Dataobject Relationship Management](/tutorials/dataobject_relationship_management)
|
||||
|
||||
@ -5,7 +5,7 @@ title: How to Publish a SilverStripe module
|
||||
If you wish to submit your module to our public directory, you take responsibility for a certain level of code quality,
|
||||
adherence to conventions, writing documentation, and releasing updates.
|
||||
|
||||
SilverStripe uses [Composer](../../getting_started/composer/) to manage module releases and dependencies between
|
||||
SilverStripe uses [Composer](../../../getting_started/composer/) to manage module releases and dependencies between
|
||||
modules. If you plan on releasing your module to the public, ensure that you provide a `composer.json` file in the root
|
||||
of your module containing the meta-data about your module.
|
||||
|
||||
|
||||
@ -309,7 +309,7 @@ equal the class names they manage.
|
||||
|
||||
## Related Documentation
|
||||
|
||||
* [How to use a FixtureFactory](how_to/fixturefactories/)
|
||||
* [How to use a FixtureFactory](how_tos/fixturefactories/)
|
||||
|
||||
## API Documentation
|
||||
|
||||
|
||||
@ -0,0 +1,29 @@
|
||||
title: Testing Glossary
|
||||
|
||||
<dl>
|
||||
<dt>Assertion<dd>A predicate statement that must be true when a test runs.
|
||||
|
||||
<dt>Behat<dd>A behaviour-driven testing library used with SilverStripe as a higher-level alternative to the `FunctionalTest` API, see <http://behat.org>.
|
||||
|
||||
<dt>Test Case<dd>The atomic class type in most unit test frameworks. New unit tests are created by inheriting from the base test case.
|
||||
|
||||
<dt>Test Suite<dd>Also known as a 'test group', a composite of test cases, used to collect individual unit tests into packages, allowing all tests to be run at once.
|
||||
|
||||
<dt>Fixture<dd>Usually refers to the runtime context of a unit test - the environment and data prerequisites that must be in place in order to run the test and expect a particular outcome. Most unit test frameworks provide methods that can be used to create fixtures for the duration of a test - `setUp` - and clean them up after the test is done - `tearDown`.
|
||||
|
||||
<dt>Refactoring<dd>A behavior preserving transformation of code. If you change the code, while keeping the actual functionality the same, it is refactoring. If you change the behavior or add new functionality it's not.
|
||||
|
||||
<dt>Smell<dd>A code smell is a symptom of a problem. Usually refers to code that is structured in a way that will lead to problems with maintenance or understanding.
|
||||
|
||||
<dt>Spike<dd>A limited and throwaway sketch of code or experiment to get a feel for how long it will take to implement a certain feature, or a possible direction for how that feature might work.
|
||||
|
||||
<dt>Test Double<dd>Also known as a 'Substitute'. A general term for a dummy object that replaces a real object with the same interface. Substituting objects is useful when a real object is difficult or impossible to incorporate into a unit test.
|
||||
|
||||
**Fake Object**: A substitute object that simply replaces a real object with the same interface, and returns a pre-determined (usually fixed) value from each method.
|
||||
|
||||
<dt>Mock Object<dd>A substitute object that mimics the same behavior as a real object (some people think of mocks as "crash test dummy" objects). Mocks differ from other kinds of substitute objects in that they must understand the context of each call to them, setting expectations of which, and what order, methods will be invoked and what parameters will be passed.
|
||||
|
||||
<dt>Test-Driven Development (TDD)<dd>A style of programming where tests for a new feature are constructed before any code is written. Code to implement the feature is then written with the aim of making the tests pass. Testing is used to understand the problem space and discover suitable APIs for performing specific actions.
|
||||
|
||||
<dt>Behavior Driven Development (BDD)<dd>An extension of the test-driven programming style, where tests are used primarily for describing the specification of how code should perform. In practice, there's little or no technical difference - it all comes down to language. In BDD, the usual terminology is changed to reflect this change of focus, so _Specification_ is used in place of _Test Case_, and _should_ is used in place of _expect_ and _assert_.
|
||||
</dl>
|
||||
@ -12,18 +12,15 @@ SilverStripe uses [PHPUnit](http://www.phpunit.de) for unit tests, and the frame
|
||||
process of creating and managing tests.
|
||||
|
||||
If you're more familiar with unit testing, but want a refresher of some of the concepts and terminology, you can browse
|
||||
the [Testing Glossary](glossary). To get started now, follow the installation instructions below, and check
|
||||
[Troubleshooting](testing-guide-troubleshooting) in case you run into any problems.
|
||||
the [Testing Glossary](testing_glossary). To get started now, follow the installation instructions below.
|
||||
|
||||
If you are familiar with PHP coding but new to unit testing then check out Mark's presentation [Getting to Grips with SilverStripe Testing](http://www.slideshare.net/maetl/getting-to-grips-with-silverstripe-testing).
|
||||
|
||||
[Why Unit Test?](why-should-i-test) will give you reasons why you should be testing your code.
|
||||
|
||||
You should also read over [the PHPUnit manual](http://www.phpunit.de/manual/current/en/). It provides a lot of
|
||||
fundamental concepts that we build on in this documentation.
|
||||
|
||||
Unit tests are not included in the normal SilverStripe downloads so you need to install them through git repositories
|
||||
([installation instructions](/installation/composer)).
|
||||
([installation instructions](/getting_started/composer)).
|
||||
|
||||
## Install with Composer
|
||||
|
||||
@ -108,7 +105,7 @@ All command-line arguments are documented on
|
||||
|
||||
### Via the "sake" Wrapper on Command Line
|
||||
|
||||
The [sake](/topics/commandline) executable that comes with SilverStripe can trigger a customized
|
||||
The [sake](/developer_guides/cli/) executable that comes with SilverStripe can trigger a customized
|
||||
`[api:TestRunner]` class that handles the PHPUnit configuration and output formatting.
|
||||
While the custom test runner a handy tool, its also more limited than using `phpunit` directly,
|
||||
particularly around formatting test output.
|
||||
|
||||
@ -24,7 +24,7 @@ Append the option and corresponding value to your URL in your browser's address
|
||||
|
||||
| URL Variable | | Values | | Description |
|
||||
| ------------ | | ------ | | ----------- |
|
||||
| isDev | | 1 | | Put the site into [development mode](/topics/debugging), enabling debugging messages to the browser on a live server. For security, you'll be asked to log in with an administrator log-in. Will persist for the current browser session. |
|
||||
| isDev | | 1 | | Put the site into [development mode](../), enabling debugging messages to the browser on a live server. For security, you'll be asked to log in with an administrator log-in. Will persist for the current browser session. |
|
||||
| isTest | | 1 | | See above. |
|
||||
| debug | | 1 | | Show a collection of debugging information about the director / controller operation |
|
||||
| debug_request | | 1 | | Show all steps of the request from initial `[api:HTTPRequest]` to `[api:Controller]` to Template Rendering |
|
||||
|
||||
@ -3,7 +3,7 @@ summary: Learn how to identify errors in your application and best practice for
|
||||
# Debugging
|
||||
|
||||
SilverStripe can be a large and complex framework to debug, but there are ways to make debugging less painful. In this
|
||||
guide we show the basics on defining the correct [Environment Type](environment_type) for your application and other
|
||||
guide we show the basics on defining the correct [Environment Type](environment_types) for your application and other
|
||||
built-in helpers for dealing with application errors.
|
||||
|
||||
[CHILDREN]
|
||||
|
||||
@ -17,7 +17,7 @@ Flushing the various manifests is performed through a GET
|
||||
parameter (`flush=1`). Since this action requires more server resources than normal requests,
|
||||
executing the action is limited to the following cases when performed via a web request:
|
||||
|
||||
* The [environment](/topics/environment-management) is in "dev mode"
|
||||
* The [environment](../getting_started/environment_management) is in "dev mode"
|
||||
* A user is logged in with ADMIN permissions
|
||||
* An error occurs during startup
|
||||
|
||||
|
||||
@ -7,7 +7,7 @@ See our "[Release Process](/misc/release-process#security-releases) on how to re
|
||||
|
||||
## SQL Injection
|
||||
|
||||
The [coding-conventions](/misc/coding-conventions) help guard against SQL injection attacks but still require developer
|
||||
The [coding-conventions](/getting_started/coding_conventions) help guard against SQL injection attacks but still require developer
|
||||
diligence: ensure that any variable you insert into a filter / sort / join clause has been escaped.
|
||||
|
||||
See [http://shiflett.org/articles/sql-injection](http://shiflett.org/articles/sql-injection).
|
||||
@ -49,7 +49,7 @@ result in *double escaping* and alters the actually saved data (e.g. by adding s
|
||||
### Manual escaping
|
||||
|
||||
As a rule of thumb, whenever you're creating raw queries (or just chunks of SQL), you need to take care of escaping
|
||||
yourself. See [coding-conventions](/misc/coding-conventions) and [datamodel](/topics/datamodel) for ways to cast and convert
|
||||
yourself. See [coding-conventions](/getting_started/coding_conventions) and [datamodel](/topics/datamodel) for ways to cast and convert
|
||||
your data.
|
||||
|
||||
* `SQLQuery`
|
||||
|
||||
@ -169,7 +169,7 @@ If you want to bypass error handling, define `checkErrors` in the constructor fo
|
||||
|
||||
## How to's
|
||||
|
||||
* [Embed an RSS Feed](how_to/embed_rss)
|
||||
* [Embed an RSS Feed](how_tos/embed_rss)
|
||||
|
||||
## API Documentation
|
||||
|
||||
|
||||
@ -11,7 +11,7 @@ The default output of a [api:SearchContext] is either a [api:SQLQuery] object fo
|
||||
[api:DataObject] instance.
|
||||
|
||||
<div class="notice" markdown="1">
|
||||
[api:SearchContext] is mainly used by [ModelAdmin](../customising_the_cms/modeladmin).
|
||||
[api:SearchContext] is mainly used by [ModelAdmin](../customising_the_admin_interface/modeladmin).
|
||||
</div>
|
||||
|
||||
## Usage
|
||||
|
||||
@ -80,7 +80,7 @@ not PHP's built-in [date()](http://nz.php.net/manual/en/function.date.php).
|
||||
### Language Names
|
||||
|
||||
SilverStripe comes with a built-in list of common languages, listed by locale and region.
|
||||
They can be accessed via the `i18n.common_languages` and `i18n.common_locales` [config setting](/topics/configuration).
|
||||
They can be accessed via the `i18n.common_languages` and `i18n.common_locales` [config setting](/developer_guides/configuration).
|
||||
|
||||
In order to add a value, add the following to your `config.yml`:
|
||||
|
||||
@ -125,7 +125,7 @@ Date- and time related form fields support i18n ([api:DateField], [api:TimeField
|
||||
$field->setConfig('dateformat', 'dd. MMMM YYYY'); // sets typical 'de_DE' date format, shows as "23. Juni 1982"
|
||||
|
||||
Defaults can be applied globally for all field instances through the `DateField.default_config`
|
||||
and `TimeField.default_config` [configuration arrays](/topics/configuration).
|
||||
and `TimeField.default_config` [configuration arrays](/developer_guides/configuration).
|
||||
If no 'locale' default is set on the field, [api:i18n::get_locale()] will be used.
|
||||
|
||||
**Important:** Form fields in the CMS are automatically configured according to the profile settings for the logged-in user (`Member->Locale`, `Member->DateFormat` and `Member->TimeFormat`). This means that in most cases,
|
||||
@ -408,7 +408,7 @@ The `ss.i18n` object contain a couple functions to help and replace dynamic vari
|
||||
|
||||
## Links
|
||||
|
||||
* [Help to translate](/misc/contribute/translation) - Instructions for online collaboration to translate core
|
||||
* [Help to translate](/misc/translation-process) - Instructions for adding translation to your own modules
|
||||
* [Help to translate](../../contributing/translations) - Instructions for online collaboration to translate core
|
||||
* [Help to translate](../../contributing/translation_process) - Instructions for adding translation to your own modules
|
||||
* [http://www.i18nguy.com/](http://www.i18nguy.com/)
|
||||
* [balbus.tk i18n notes](http://www.balbus.tk/internationalize)
|
||||
|
||||
@ -13,7 +13,7 @@ All files, images and folders in the 'assets' directory are stored in the databa
|
||||
| `Title` | The optional, human-readable title of the file for display only (doesn't apply to folders). |
|
||||
| `Filename` | The path to the file/folder, relative to the webroot. For example 'assets/images/my-image.jpg', or 'assets/images/' for a folder. |
|
||||
| `Content` | Typically unused, but handy for a textual representation of files. For example for fulltext indexing of PDF documents. |
|
||||
| `ShowInSearch` | Whether the file should be shown in search results, defaults to '1'. See ["Tutorial 4 - Site Search"](/tutorials/4-site-search) for enabling search. |
|
||||
| `ShowInSearch` | Whether the file should be shown in search results, defaults to '1'. See ["Tutorial 4 - Site Search"](/tutorials/site_search) for enabling search. |
|
||||
| `ParentID` | The ID of the parent Folder that this File/Folder is in. A ParentID of '0' indicates that the File/Folder is in the 'assets' directory. |
|
||||
| `OwnerID` | The ID of the Member that 'owns' the File/Folder (not related to filesystem permissions). |
|
||||
|
||||
@ -37,4 +37,4 @@ You may also notice the 'Sync files' button (highlighted below). This button all
|
||||
|
||||
## Upload
|
||||
|
||||
Files can be managed through a `FileField` or an `UploadField`. The `[api:FileField]` class provides a simple HTML input with a type of "file", whereas an `[api:UploadField]` provides a much more feature-rich field (including AJAX-based uploads, previews, relationship management and file data management). See [`Reference - UploadField`](/reference/uploadfield) for more information about how to use the `UploadField` class.
|
||||
Files can be managed through a `FileField` or an `UploadField`. The `[api:FileField]` class provides a simple HTML input with a type of "file", whereas an `[api:UploadField]` provides a much more feature-rich field (including AJAX-based uploads, previews, relationship management and file data management). See [`Reference - UploadField`](/developer_guides/forms/field_types/uploadfield) for more information about how to use the `UploadField` class.
|
||||
@ -10,7 +10,7 @@ It uses the framework's knowledge about the model to provide sensible defaults,
|
||||
of lines of code, while still providing a solid base for customization.
|
||||
|
||||
<div class="info" markdown="1">
|
||||
The interface is mainly powered by the [api:GridField] class ([documentation](../forms/fields/gridfield)), which can
|
||||
The interface is mainly powered by the [api:GridField] class ([documentation](../forms/field_types/gridfield)), which can
|
||||
also be used in other areas of your application.
|
||||
</div>
|
||||
|
||||
@ -146,7 +146,7 @@ class (see [SearchContext](../search/searchcontext) docs for details).
|
||||
|
||||
## Displaying Results
|
||||
|
||||
The results are shown in a tabular listing, powered by the [GridField](../forms/fields/gridfield), more specifically
|
||||
The results are shown in a tabular listing, powered by the [GridField](../forms/field_types/gridfield), more specifically
|
||||
the [api:GridFieldDataColumns] component. This component looks for a [api:DataObject::$summary_fields] static on your
|
||||
model class, where you can add or remove columns. To change the title, use [api:DataObject::$field_labels].
|
||||
|
||||
@ -320,9 +320,9 @@ To customize the exported columns, create a new method called `getExportFields`
|
||||
|
||||
## Related Documentation
|
||||
|
||||
* [GridField](../forms/fields/gridfield)
|
||||
* [GridField](../forms/field_types/gridfield)
|
||||
* [Permissions](../security/permissions)
|
||||
* [SeachContext](../search/seachcontext)
|
||||
* [SearchContext](../search/searchcontext)
|
||||
|
||||
## API Documentation
|
||||
|
||||
|
||||
@ -66,7 +66,7 @@ Layout manager will automatically apply algorithms to the children of `.cms-cont
|
||||
For detailed discussion on available algorithms refer to
|
||||
[jLayout algorithms](https://github.com/bramstein/jlayout#layout-algorithms).
|
||||
|
||||
Our [Howto: Extend the CMS Interface](../howto/extend-cms-interface) has a practical example on how to add a bottom
|
||||
Our [Howto: Extend the CMS Interface](how_tos/extend_cms_interface) has a practical example on how to add a bottom
|
||||
panel to the CMS UI.
|
||||
|
||||
### Methods
|
||||
@ -115,6 +115,6 @@ The parameters are as follows:
|
||||
|
||||
## Related
|
||||
|
||||
* [Reference: CMS Architecture](../reference/cms-architecture)
|
||||
* [Reference: Preview](../reference/preview)
|
||||
* [Howto: Extend the CMS Interface](../howto/extend-cms-interface)
|
||||
* [Reference: CMS Architecture](cms_architecture)
|
||||
* [Reference: Preview](preview)
|
||||
* [Howto: Extend the CMS Interface](how_tos/extend_cms_interface)
|
||||
|
||||
@ -69,7 +69,7 @@ Note how the configuration happens in different entwine namespaces
|
||||
}(jQuery));
|
||||
|
||||
Load the file in the CMS via setting adding 'mysite/javascript/MyLeftAndMain.Preview.js'
|
||||
to the `LeftAndMain.extra_requirements_javascript` [configuration value](/topics/configuration)
|
||||
to the `LeftAndMain.extra_requirements_javascript` [configuration value](../configuration)
|
||||
|
||||
:::yml
|
||||
LeftAndMain:
|
||||
@ -79,7 +79,7 @@ to the `LeftAndMain.extra_requirements_javascript` [configuration value](/topics
|
||||
In order to find out which configuration values are available, the source code
|
||||
is your best reference at the moment - have a look in `framework/admin/javascript/LeftAndMain.Preview.js`.
|
||||
To understand how layouts are handled in the CMS UI, have a look at the
|
||||
[CMS Architecture](/reference/cms-architecture) guide.
|
||||
[CMS Architecture](cms_architecture) guide.
|
||||
|
||||
## Enabling preview
|
||||
|
||||
@ -146,7 +146,7 @@ You can find out current size by calling:
|
||||
## Preview modes
|
||||
|
||||
Preview modes map to the modes supported by the _threeColumnCompressor_ layout
|
||||
algorithm, see [layout reference](../reference/layout) for more details. You
|
||||
algorithm, see [layout reference](cms_layout) for more details. You
|
||||
can change modes by calling:
|
||||
|
||||
```js
|
||||
@ -184,4 +184,4 @@ previewable content is loaded.
|
||||
|
||||
## Related
|
||||
|
||||
* [Reference: Layout](../reference/layout)
|
||||
* [Reference: Layout](cms_layout)
|
||||
|
||||
@ -13,7 +13,7 @@ feel familiar to you. This is just a quick run down to get you started
|
||||
with some special conventions.
|
||||
|
||||
For a more practical-oriented approach to CMS customizations, refer to the
|
||||
[Howto: Extend the CMS Interface](../howto/extend-cms-interface) which builds
|
||||
[Howto: Extend the CMS Interface](../how_tos/extend_cms_interface) which builds
|
||||
|
||||
|
||||
## Markup and Style Conventions
|
||||
@ -47,7 +47,7 @@ As there's a whole lot of CSS driving the CMS, we have certain best practives ar
|
||||
* Use jQuery UI's built-in styles where possible, e.g. `ui-widget` for a generic container, or `ui-state-highlight`
|
||||
to highlight a specific component. See the [jQuery UI Theming API](http://jqueryui.com/docs/Theming/API) for a full list.
|
||||
|
||||
See our [system requirements](../installation/server-requirements) for a list of supported browsers.
|
||||
See our [system requirements](/getting_started/server_requirements) for a list of supported browsers.
|
||||
|
||||
## Templates and Controllers
|
||||
|
||||
@ -89,7 +89,7 @@ The various panels and UI components within them are loosely coupled to the layo
|
||||
attribute. The layout is triggered on the top element and cascades into children, with a `redraw` method defined on
|
||||
each panel and UI component that needs to update itself as a result of layouting.
|
||||
|
||||
Refer to [Layout reference](../reference/layout) for further information.
|
||||
Refer to [Layout reference](cms_layout) for further information.
|
||||
|
||||
## Forms
|
||||
|
||||
@ -148,7 +148,7 @@ correctly configured form.
|
||||
[jQuery.entwine](https://github.com/hafriedlander/jquery.entwine) is a thirdparty library
|
||||
which allows us to attach behaviour to DOM elements in a flexible and structured mannger.
|
||||
It replaces the `behaviour.js` library used in previous versions of the CMS interface.
|
||||
See [Topics: JavaScript](../topics/javascript) for more information on how to use it.
|
||||
See [JavaScript Development](javascript_development) for more information on how to use it.
|
||||
In the CMS interface, all entwine rules should be placed in the "ss" entwine namespace.
|
||||
If you want to call methods defined within these rules outside of entwine logic,
|
||||
you have to use this namespace, e.g. `$('.cms-menu').entwine('ss').collapse()`.
|
||||
@ -433,7 +433,7 @@ The CMS tree for viewing hierarchical structures (mostly pages) is powered
|
||||
by the [jstree](http://jstree.com) library. It is configured through
|
||||
`framework/admin/javascript/LeftAndMain.Tree.js`, as well as some
|
||||
HTML5 metadata generated on its container (see the `data-hints` attribute).
|
||||
For more information, see the [Howto: Customize the CMS tree](../howto/customize-cms-tree).
|
||||
For more information, see the [Howto: Customize the CMS tree](../how_tos/customize_cms_tree).
|
||||
|
||||
Note that a similar tree logic is also used for the
|
||||
form fields to select one or more entries from those hierarchies
|
||||
@ -538,8 +538,8 @@ through the `PjaxResponseNegotiator` class (see above).
|
||||
|
||||
## Related
|
||||
|
||||
* [Howto: Extend the CMS Interface](../howto/extend-cms-interface)
|
||||
* [Howto: Customize the CMS tree](../howto/customize-cms-tree)
|
||||
* [Reference: ModelAdmin](../reference/modeladmin)
|
||||
* [Reference: Layout](../reference/layout)
|
||||
* [Topics: Rich Text Editing](../topics/rich-text-editing)
|
||||
* [Howto: Extend the CMS Interface](how_tos/extend_cms_interface)
|
||||
* [Howto: Customize the CMS tree](how_tos/customize_cms_tree)
|
||||
* [ModelAdmin API](api:ModelAdmin)
|
||||
* [Reference: Layout](cms_layout)
|
||||
* [Rich Text Editing](/developer_guides/forms/field_types/htmleditorfield)
|
||||
|
||||
@ -14,7 +14,7 @@ This how-to will walk you through creation of a "Clean-up" button with two appea
|
||||
* active: "Clean-up now" green constructive button if the actions can be performed
|
||||
* netural: "Cleaned" default button if the action does not need to be done
|
||||
|
||||
The controller code that goes with this example is listed in [Extend CMS Interface](../reference/extend-cms-interface).
|
||||
The controller code that goes with this example is listed in [Extend CMS Interface](extend_cms_interface).
|
||||
|
||||
## Backend support ##
|
||||
|
||||
|
||||
@ -27,4 +27,4 @@ more complex fields like `GridField`, `UploadField`
|
||||
or `DropdownField` with the chosen.js behaviour applied.
|
||||
|
||||
Note: For more advanced help text we recommend using
|
||||
[Custom form field templates](/topics/forms#custom-form-field-templates);
|
||||
[Custom form field templates](../form_templates);
|
||||
|
||||
@ -7,10 +7,10 @@ SilverStripe will automatically create a new `[api:CMSMenuItem]` for it
|
||||
|
||||
The most popular extension of LeftAndMain is a `[api:ModelAdmin]` class, so
|
||||
for a more detailed introduction to creating new `ModelAdmin` interfaces, read
|
||||
the [ModelAdmin reference](../reference/modeladmin).
|
||||
the [ModelAdmin reference](../modeladmin).
|
||||
|
||||
In this document we'll take the `ProductAdmin` class used in the
|
||||
[ModelAdmin reference](../reference/modeladmin#setup) and so how we can change
|
||||
[ModelAdmin reference](../modeladmin#setup) and so how we can change
|
||||
the menu behaviour by using the `$menu_title` and `$menu_icon` statics to
|
||||
provide a custom title and icon.
|
||||
|
||||
@ -43,7 +43,7 @@ In order to localize the menu title in different languages, use the
|
||||
the i18n text collection.
|
||||
|
||||
For more information on language and translations, please refer to the
|
||||
[i18n](../reference/ii8n) docs.
|
||||
[i18n](../../ii8n) docs.
|
||||
|
||||
## Adding an external link to the menu
|
||||
|
||||
@ -85,7 +85,7 @@ button configuration.
|
||||
|
||||
To have the link appear, make sure you add the extension to the `LeftAndMain`
|
||||
class. For more information about configuring extensions see the
|
||||
[DataExtension reference](../reference/dataextension).
|
||||
[extensions reference](../extending/extensions).
|
||||
|
||||
:::php
|
||||
LeftAndMain::add_extension('CustomLeftAndMain')
|
||||
@ -93,4 +93,4 @@ class. For more information about configuring extensions see the
|
||||
|
||||
## Related
|
||||
|
||||
* [How to extend the CMS interface](extend-cms-interface)
|
||||
* [How to extend the CMS interface](extend_cms_interface)
|
||||
|
||||
@ -62,7 +62,7 @@ or across page types with common characteristics.
|
||||
}
|
||||
}
|
||||
|
||||
Now you just need to enable the extension in your [configuration file](/topics/configuration).
|
||||
Now you just need to enable the extension in your [configuration file](../../configuration).
|
||||
|
||||
// mysite/_config/config.yml
|
||||
LeftAndMain:
|
||||
|
||||
@ -55,7 +55,7 @@ with the CMS interface. Paste the following content into a new file called
|
||||
.bookmarked-link.first {margin-top: 1em;}
|
||||
|
||||
Load the new CSS file into the CMS, by setting the `LeftAndMain.extra_requirements_css`
|
||||
[configuration value](/topics/configuration).
|
||||
[configuration value](../../configuration).
|
||||
|
||||
:::yml
|
||||
LeftAndMain:
|
||||
@ -85,7 +85,7 @@ and insert the following code.
|
||||
}
|
||||
}
|
||||
|
||||
Enable the extension in your [configuration file](/topics/configuration)
|
||||
Enable the extension in your [configuration file](../../configuration)
|
||||
|
||||
:::yml
|
||||
SiteTree:
|
||||
@ -114,7 +114,7 @@ Add the following code to a new file `mysite/code/BookmarkedLeftAndMainExtension
|
||||
}
|
||||
}
|
||||
|
||||
Enable the extension in your [configuration file](/topics/configuration)
|
||||
Enable the extension in your [configuration file](../../configuration)
|
||||
|
||||
:::yml
|
||||
LeftAndMain:
|
||||
@ -191,11 +191,11 @@ Empty tabs will be automatically removed from the `FieldList` to prevent clutter
|
||||
</div>
|
||||
|
||||
New actions will need associated controller handlers to work. You can use a
|
||||
`LeftAndMainExtension` to provide one. Refer to [Controller documentation](../topics/controller)
|
||||
`LeftAndMainExtension` to provide one. Refer to [Controller documentation](../../controllers)
|
||||
for instructions on setting up handlers.
|
||||
|
||||
To make the actions more user-friendly you can also use alternating buttons as
|
||||
detailed in the [CMS Alternating Button](../reference/cms-alternating-button)
|
||||
detailed in the [CMS Alternating Button](cms_alternating_button)
|
||||
how-to.
|
||||
|
||||
## Summary
|
||||
@ -207,7 +207,7 @@ blocks and concepts for more complex extensions as well.
|
||||
|
||||
## Related
|
||||
|
||||
* [Reference: CMS Architecture](../reference/cms-architecture)
|
||||
* [Reference: Layout](../reference/layout)
|
||||
* [Topics: Rich Text Editing](../topics/rich-text-editing)
|
||||
* [CMS Alternating Button](../howto/cms-alternating-button)
|
||||
* [Reference: CMS Architecture](../cms_architecture)
|
||||
* [Reference: Layout](../cms_layout)
|
||||
* [Rich Text Editing](/developer_guides/forms/field_types/htmleditorfield)
|
||||
* [CMS Alternating Button](cms_alternating_button)
|
||||
|
||||
@ -64,14 +64,14 @@ a `tests/` folder, unless tests are executed.
|
||||
|
||||
The `[api:SS_TemplateManifest]` class builds a manifest of all templates present in a directory,
|
||||
in both modules and themes. Templates in `tests/` folders are automatically excluded.
|
||||
The chapter on [template inheritance](../templates/template-inheritance) provides more details
|
||||
The chapter on [template inheritance](../templates/template_inheritance) provides more details
|
||||
on its operation.
|
||||
|
||||
## Config Manifest
|
||||
|
||||
The `[api:SS_ConfigManifest]` loads builds a manifest of configuration items,
|
||||
for both PHP and YAML. It also takes care of ordering and merging configuration fragments.
|
||||
The chapter on [configuration](/topics/configuration) has more details.
|
||||
The chapter on [configuration](../configuration) has more details.
|
||||
|
||||
## Flushing
|
||||
|
||||
|
||||
@ -103,14 +103,14 @@ before handing control off to SilverStripe's own `main.php`.
|
||||
|
||||
## Routing and Request Handling
|
||||
|
||||
The `main.php` script relies on `[api:Director]` to work out which [controller](../controllers) should handle this request. It parses the URL, matching it to one of a number of patterns,
|
||||
The `main.php` script relies on `[api:Director]` to work out which [controller](../controllers/) should handle this request. It parses the URL, matching it to one of a number of patterns,
|
||||
and determines the controller, action and any argument to be used ([Routing](../controllers/routing)).
|
||||
|
||||
* Creates a `[api:SS_HTTPRequest]` object containing all request and environment information
|
||||
* The [session](../cookies_and_sessions/sessions) holds an abstraction of PHP session
|
||||
* Instantiates a [controller](../Controllers) object
|
||||
* Instantiates a [controller](../controllers/) object
|
||||
* The `[api:Injector]` is first referenced, and asks the registered
|
||||
[RequestFilter](../controller/request_filters)
|
||||
[RequestFilter](../controllers/requestfilters)
|
||||
to pre-process the request object (see below)
|
||||
* The `Controller` executes the actual business logic and populates an `[api:SS_HTTPResponse]`
|
||||
* The `Controller` can optionally hand off control to further nested controllers
|
||||
@ -125,7 +125,7 @@ The framework provides the ability to hook into the request both before and
|
||||
after it is handled to allow binding custom logic. This can be used
|
||||
to transform or filter request data, instanciate helpers, execute global logic,
|
||||
or even short-circuit execution (e.g. to enforce custom authentication schemes).
|
||||
The ["Request Filters" documentation](../controller/request_filters) shows you how.
|
||||
The ["Request Filters" documentation](../controllers/requestfilters) shows you how.
|
||||
|
||||
## Flushing Manifests
|
||||
|
||||
|
||||
@ -6,7 +6,7 @@ The SilverStripe core modules (`framework` and `cms`), as well as some of the mo
|
||||
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/)).
|
||||
|
||||
For other modules, our [module list on silverstripe.org](http://silverstripe.org/modules) lists the repository locations, typically using a version control system like "git" or "[subversion](subversion)".
|
||||
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".
|
||||
|
||||
<div class="hint" markdown="1">
|
||||
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.
|
||||
@ -16,7 +16,7 @@ We ask for this so that the ownership in the license is clear and unambiguous, a
|
||||
|
||||
## Step-by-step: From forking to sending the pull request
|
||||
|
||||
1. Install the project through composer. The process is described in detail in "[Installation through Composer](../../installation/composer#contributing)".
|
||||
1. Install the project through composer. The process is described in detail in "[Installation through Composer](../getting_started/composer#contributing)".
|
||||
|
||||
composer create-project --keep-vcs --dev silverstripe/installer ./my/website/folder 3.1.x-dev
|
||||
|
||||
@ -71,7 +71,7 @@ If you aren't familiar with git and GitHub, try reading the ["GitHub bootcamp do
|
||||
We also found the [free online git book](http://git-scm.com/book/) and the [git crash course](http://gitref.org/) 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 (mostly on our [bugtracker](/misc/contributing/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.
|
||||
* **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.
|
||||
|
||||
* **Do not merge the upstream master** with your development branch; *rebase* your branch on top of the upstream master.
|
||||
|
||||
@ -82,7 +82,7 @@ If you're familiar with it, here's the short version of what you need to know. O
|
||||
* **Choose the correct branch**: Assume the current release is 3.0.3, and 3.1.0 is in beta state.
|
||||
Most pull requests should go against the `3.1.x-dev` *pre-release branch*, only critical bugfixes
|
||||
against the `3.0.x-dev` *release branch*. If you're changing an API or introducing a major feature,
|
||||
the pull request should go against `master` (read more about our [release process](/misc/release-process)). Branches are periodically merged "upwards" (3.0 into 3.1, 3.1 into master).
|
||||
the pull request should go against `master` (read more about our [release process](release_process)). Branches are periodically merged "upwards" (3.0 into 3.1, 3.1 into master).
|
||||
|
||||
### Editing files directly on GitHub.com
|
||||
|
||||
@ -92,11 +92,11 @@ After you have edited the file, GitHub will offer to create a pull request for y
|
||||
|
||||
## Check List
|
||||
|
||||
* Adhere to our [coding conventions](/misc/coding-conventions)
|
||||
* Adhere to our [coding conventions](/getting_started/coding_conventions)
|
||||
* If your patch is extensive, discuss it first on the [silverstripe-dev google group](https://groups.google.com/group/silverstripe-dev) (ideally before doing any serious coding)
|
||||
* 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](/topics/testing)
|
||||
* Write [unit tests](../developer_guides/testing/unit_testing)
|
||||
* Write [Behat integration tests](https://github.com/silverstripe-labs/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
|
||||
@ -106,7 +106,7 @@ changes
|
||||
[API documentation](http://api.silverstripe.org/3.1/) for good examples.
|
||||
* Check and update documentation on [doc.silverstripe.org](http://doc.silverstripe.org). Check for any references to functionality deprecated or extended through your patch. Documentation changes should be included in the patch.
|
||||
* 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)
|
||||
* When working with the CMS, please read the ["CMS Architecture Guide"](/reference/cms-architecture) first
|
||||
* When working with the CMS, please read the ["CMS Architecture Guide"](cms_architecture) first
|
||||
|
||||
## Commit Messages
|
||||
|
||||
|
||||
@ -9,7 +9,7 @@ only have time for a partial translation or quick review work - our system accom
|
||||
same language.
|
||||
|
||||
The content for UI elements (button labels, field titles) and instruction texts shown in the CMS and elsewhere is
|
||||
stored in the PHP code for a module (see [i18n](/topics/i18n)). All content can be extracted as a "language file", and
|
||||
stored in the PHP code for a module (see [i18n](../developer_guides/i18n)). All content can be extracted as a "language file", and
|
||||
uploaded to an online translation editor interface. SilverStripe is already translated in over 60 languages, and we're
|
||||
relying on native speakers to keep these up to date, and of course add new languages.
|
||||
|
||||
@ -83,13 +83,13 @@ dropdown which automatically includes all found translations (based on the files
|
||||
### I've found a piece of untranslatable text
|
||||
|
||||
It is entirely possible that we missed certain strings in preparing Silverstripe for translation-support. If you're
|
||||
technically minded, please read [i18n](/topics/i18n) on how to make it translatable. Otherwise just post your findings
|
||||
technically minded, please read [i18n](../developer_guides/i18n) on how to make it translatable. Otherwise just post your findings
|
||||
to the forum.
|
||||
|
||||
### How do I add my own module?
|
||||
|
||||
Once you've built a translation-enabled module, you can run the "textcollector" on your local installation for this
|
||||
specific module (see [i18n](/topics/i18n)). This should find all calls to `_t()` in php and template files, and generate
|
||||
specific module (see [i18n](../developer_guides/i18n)). This should find all calls to `_t()` in php and template files, and generate
|
||||
a new lang file with the default locale (path: <mymodule>/lang/en.yml). Upload this file to the online translation
|
||||
tool, and wait for your translators to do their magic!
|
||||
|
||||
@ -128,7 +128,7 @@ This was a custom-built online translation tool serving us well for a couple of
|
||||
were migrated. Unfortunately, the ownership of individual translations couldn't be migrated.
|
||||
|
||||
As the new tool doesn't support the PHP format used in SilverStripe 2.x, this means that we no longer have a working
|
||||
translation tool for PHP files. Please edit the PHP files directly and [send us pull requests](/misc/contributing).
|
||||
translation tool for PHP files. Please edit the PHP files directly and [send us pull requests](/contributing).
|
||||
|
||||
This also applies for any modules staying compatible with SilverStripe 2.x.
|
||||
|
||||
@ -140,7 +140,7 @@ board if you have specific comments on a translation.
|
||||
|
||||
## Related
|
||||
|
||||
* [i18n](/developer_guids/i18n): Developer-level documentation of Silverstripe's i18n capabilities
|
||||
* [translation-process](translation-process): Information about managing translations for the core team and/or module maintainers.
|
||||
* [i18n](/developer_guides/i18n): Developer-level documentation of Silverstripe's i18n capabilities
|
||||
* [Translation Process](translation_process): Information about managing translations for the core team and/or module maintainers.
|
||||
* [translatable](https://github.com/silverstripe/silverstripe-translatable): DataObject-interface powering the website-content translations
|
||||
* ["Translatable ModelAdmin" module](http://silverstripe.org/translatablemodeladmin-module/): An extension which allows translations of DataObjects inside ModelAdmin
|
||||
|
||||
@ -4,14 +4,14 @@ summary: Implement SilverStripe's internationalization system in your own module
|
||||
# Implementing Internationalization
|
||||
|
||||
To find out about how to assist with translating SilverStripe from a users point of view, see the
|
||||
[Contributing Translations page](translation).
|
||||
[Contributing Translations page](/contributing/translations).
|
||||
|
||||
## Set up your own module for localization
|
||||
|
||||
### Collecting translatable text
|
||||
|
||||
As a first step, you can automatically collect all translatable text in your module through the `i18nTextCollector`
|
||||
task. See [i18n](/topics/i18n#collecting-text) for more details.
|
||||
task. See [i18n](../developer_guides/i18n#collecting-text) for more details.
|
||||
|
||||
### Import master files
|
||||
|
||||
@ -127,7 +127,7 @@ files back into the JS files SilverStripe can actually read. This requires an in
|
||||
|
||||
# Related
|
||||
|
||||
* [i18n](/topics/i18n): Developer-level documentation of Silverstripe's i18n capabilities
|
||||
* [contributing/translation](contributing/translation): Information for translators looking to contribute translations of the SilverStripe UI.
|
||||
* [i18n](/developer_guides/i18n/): Developer-level documentation of Silverstripe's i18n capabilities
|
||||
* [Contributing Translations](/contributing/translations): Information for translators looking to contribute translations of the SilverStripe UI.
|
||||
* [translatable](https://github.com/silverstripe/silverstripe-translatable): DataObject-interface powering the website-content translations
|
||||
* ["Translatable ModelAdmin" module](http://silverstripe.org/translatablemodeladmin-module/): An extension which allows translations of DataObjects inside ModelAdmin
|
||||
@ -24,7 +24,7 @@ With great power comes great responsibility, so we have agreed on certain expect
|
||||
* Treat issues according to our [issue guidelines](issues_and_bugs)
|
||||
* Don't commit directly to core, raise pull requests instead (except trivial fixes)
|
||||
* Only merge code you have tested and fully understand. If in doubt, ask for a second opinion.
|
||||
* Ensure contributions have appropriate [test coverage](/topics/testing), are documented, and pass our [coding conventions](/getting_started/coding-conventions)
|
||||
* Ensure contributions have appropriate [test coverage](../developer_guides/testing), are documented, and pass our [coding conventions](/getting_started/coding_conventions)
|
||||
* Keep the codebase "releasable" at all times (check our [release process](release_process))
|
||||
* API changes and non-trivial features should not be merged into release branches.
|
||||
* API changes on master should not be merged until they have the buy-in of at least two core committers (or better, through the [core mailing list](https://groups.google.com/forum/#!forum/silverstripe-dev))
|
||||
|
||||
Loading…
Reference in New Issue
Block a user