mirror of
https://github.com/silverstripe/silverstripe-framework
synced 2024-06-28 23:49:26 +02:00
Merge remote-tracking branch 'origin/3.0' into 3.1
Conflicts: model/DataList.php
This commit is contained in:
Ingo Schommer
commit
79997477b3
|
|
@ -450,6 +450,12 @@ jQuery.noConflict();
|
|||
handleAjaxResponse: function(data, status, xhr) {
|
||||
var self = this, url, selectedTabs, guessFragment;
|
||||
|
||||
// Support a full reload
|
||||
if(xhr.getResponseHeader('X-Reload') && xhr.getResponseHeader('X-ControllerURL')) {
|
||||
document.location.href = xhr.getResponseHeader('X-ControllerURL');
|
||||
return;
|
||||
}
|
||||
|
||||
// Pseudo-redirects via X-ControllerURL might return empty data, in which
|
||||
// case we'll ignore the response
|
||||
if(!data) return;
|
||||
|
|
|
|||
|
|
@ -1281,6 +1281,7 @@ ErrorDocument 500 /assets/error-500.html
|
|||
$baseClause
|
||||
RewriteCond %{REQUEST_URI} ^(.*)$
|
||||
RewriteCond %{REQUEST_FILENAME} !-f
|
||||
RewriteCond %{REQUEST_URI} !\.php$
|
||||
RewriteRule .* $modulePath/main.php?url=%1&%{QUERY_STRING} [L]
|
||||
</IfModule>
|
||||
TEXT;
|
||||
|
|
|
|||
|
|
@ -72,7 +72,6 @@ Now that we have a contact form, we need some way of collecting the data submitt
|
|||
|
||||
$messageBody = "
|
||||
<p><strong>Name:</strong> {$data['Name']}</p>
|
||||
<p><strong>Website:</strong> {$data['Website']}</p>
|
||||
<p><strong>Message:</strong> {$data['Message']}</p>
|
||||
";
|
||||
$email->setBody($messageBody);
|
||||
|
|
|
|||
|
|
@ -44,18 +44,20 @@ Composer can create a new site for you, using the installer as a template. To d
|
|||
|
||||
composer create-project silverstripe/installer ./my/website/folder
|
||||
|
||||
`./my/website/folder` should be the root directory where your site will live. For example, on OS X, you might use a subdirectory of `~/Sites`.
|
||||
|
||||
`./my/website/folder` should be the root directory where your site will live.
|
||||
For example, on OS X, you might use a subdirectory of `~/Sites`.
|
||||
As long as your web server is up and running, this will get all the code that you need.
|
||||
|
||||
Now visit the site in your web browser, and the installation process will be completed.
|
||||
|
||||
#### Selecting a version
|
||||
|
||||
By default composer will download the latest stable version. You can also specify
|
||||
a version to download that version explicitly, i.e. this will download 3.0.3:
|
||||
|
||||
composer create-project silverstripe/installer ./my/website/folder 3.0.3
|
||||
|
||||
When `create-project` is used with a release version like above,
|
||||
it will try to get the code from archives instead of creating
|
||||
git repositories. If you're planning to contribute to SilverStripe,
|
||||
see [Using development versions](#using-development-versions).
|
||||
|
||||
## Adding modules to your project
|
||||
|
||||
|
|
@ -94,14 +96,35 @@ The `composer.lock` file helps with this. It references the specific commits th
|
|||
So, your deployment process, as it relates to Composer, should be as follows:
|
||||
|
||||
* Run `composer update` on your development version before you start whatever testing you have planned. Perform all the necessary testing.
|
||||
|
||||
* Check `composer.lock` into your repository.
|
||||
|
||||
* Deploy your project code base, using the deployment tool of your choice.
|
||||
* Run `composer install` on your production version.
|
||||
|
||||
* Run the following command on your production version.
|
||||
# Setting up an environment for contributing to SilverStripe {#contributing}
|
||||
|
||||
composer install
|
||||
So you want to contribute to SilverStripe? Fantastic! You can do this with composer too.
|
||||
You have to tell composer three things in order to be able to do this:
|
||||
|
||||
- Keep the full git repository information
|
||||
- Include dependancies marked as "developer" requirements
|
||||
- Use the development version, not the latest stable version
|
||||
|
||||
The first two steps are done as part of the initial create project using additional arguments. For instance:
|
||||
|
||||
composer create-project --keep-vcs --dev silverstripe/installer ./my/website/folder 3.0.x-dev
|
||||
|
||||
The process will take a bit longer, since all modules are checked out as full git repositories which you can work on.
|
||||
|
||||
The `--keep-vcs` flag will make sure you have access to the git history of the installer and the requirements
|
||||
|
||||
The `--dev` flag will add a couple modules which are useful for SilverStripe development:
|
||||
|
||||
* The `docsviewer` module will let you preview changes to the project documentation
|
||||
* The `buildtools` module which adds [phing](http://phing.info) tasks for creating SilverStripe releases
|
||||
|
||||
Note that you can also include those into an existing project by running `composer update --dev`.
|
||||
Please read the ["Contributing Code"](/misc/contributing/code) documentation to find out how to
|
||||
create forks and send pull requests.
|
||||
|
||||
# Advanced usage
|
||||
|
||||
|
|
@ -212,27 +235,3 @@ Both the version and the alias are specified as Composer versions, not branch na
|
|||
|
||||
This is not the only way to set things up in Composer. For more information on this topic, read the ["Aliases" chapter of the Composer documentation](http://getcomposer.org/doc/articles/aliases.md).
|
||||
|
||||
## Setting up an environment for contributing to SilverStripe
|
||||
|
||||
So you want to contribute to SilverStripe? Fantastic! You can do this with composer too.
|
||||
You have to tell composer three things in order to be able to do this:
|
||||
|
||||
- Keep the full git repository information
|
||||
- Include dependancies marked as "developer" requirements
|
||||
- Use the development version, not the latest stable version
|
||||
|
||||
The first two steps are done as part of the initial create project using additional arguments. For instance:
|
||||
|
||||
composer create-project --keep-vcs --dev silverstripe/installer ./my/website/folder 3.0.x-dev
|
||||
|
||||
The process will take a bit longer, since all modules are checked out as full git repositories which you can work on.
|
||||
|
||||
The `--keep-vcs` flag will make sure you have access to the git history of the installer and the requirements
|
||||
|
||||
The `--dev` flag will add a couple modules which are useful for SilverStripe development:
|
||||
|
||||
* The `compass` module will regenerate CSS if you update the SCSS files
|
||||
* The `docsviewer` module will let you preview changes to the project documentation
|
||||
* The `buildtools` module which adds [phing](http://phing.info) tasks for creating SilverStripe releases
|
||||
|
||||
Note that you can also include those into an existing project by running `composer update --dev`.
|
||||
|
|
@ -16,29 +16,32 @@ 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. Follow the [Installation for contributions](../../installation/from-source#option-2-installation-for-contributions) instructions, which explain how to fork the core modules and add the correct "upstream" remote.
|
||||
1. Follow the [Installation through Composer](../../installation/composer#contributing) instructions,
|
||||
which explain how to fork the core modules and add the correct "upstream" remote. In short:
|
||||
|
||||
1. [Branch for new issue and develop on issue branch](code#branch-for-new-issue-and-develop-on-issue-branch)
|
||||
composer create-project --keep-vcs --dev silverstripe/installer ./my/website/folder 3.0.x-dev
|
||||
|
||||
$ git branch ###-description
|
||||
$ git checkout ###-description
|
||||
2. [Branch for new issue and develop on issue branch](code#branch-for-new-issue-and-develop-on-issue-branch)
|
||||
|
||||
1. As time passes, the upstream repository accumulates new commits. Keep your working copy's master branch and issue branch up to date by periodically [rebasing your development branch on the latest upstream](code#rebase-your-development-branch-on-the-latest-upstream).
|
||||
git branch ###-description
|
||||
git checkout ###-description
|
||||
|
||||
# [make sure all your changes are committed as necessary in branch]
|
||||
$ git fetch upstream
|
||||
$ git rebase upstream/master
|
||||
3. As time passes, the upstream repository accumulates new commits. Keep your working copy's master branch and issue branch up to date by periodically [rebasing your development branch on the latest upstream](code#rebase-your-development-branch-on-the-latest-upstream).
|
||||
|
||||
1. When development is complete, [squash all commit related to a single issue into a single commit](code#squash-all-commits-related-to-a-single-issue-into-a-single-commit).
|
||||
# [make sure all your changes are committed as necessary in branch]
|
||||
git fetch upstream
|
||||
git rebase upstream/master
|
||||
|
||||
$ git fetch upstream
|
||||
$ git rebase -i upstream/master
|
||||
4. When development is complete, [squash all commit related to a single issue into a single commit](code#squash-all-commits-related-to-a-single-issue-into-a-single-commit).
|
||||
|
||||
1. Push release candidate branch to GitHub
|
||||
git fetch upstream
|
||||
git rebase -i upstream/master
|
||||
|
||||
$ git push origin ###-description
|
||||
5. Push release candidate branch to GitHub
|
||||
|
||||
1. Issue pull request on GitHub. Visit your forked respoistory on GitHub.com and click the "Create Pull Request" button nex tot the new branch.
|
||||
git push origin ###-description
|
||||
|
||||
6. Issue pull request on GitHub. Visit your forked respoistory on GitHub.com and click the "Create Pull Request" button nex tot the new branch.
|
||||
|
||||
The core team is then responsible for reviewing patches and deciding if they will make it into core. If
|
||||
there are any problems they will follow up with you, so please ensure they have a way to contact you!
|
||||
|
|
@ -61,7 +64,10 @@ If you're familiar with it, here's the short version of what you need to know. O
|
|||
|
||||
* **Squash your commits, so that each commit addresses a single issue.** After you rebase your work on top of the upstream master, you can squash multiple commits into one. Say, for instance, you've got three commits in related to Issue #100. Squash all three into one with the message "Issue #100 Description of the issue here." We won't accept pull requests for multiple commits related to a single issue; it's up to you to squash and clean your commit tree. (Remember, if you squash commits you've already pushed to GitHub, you won't be able to push that same branch again. Create a new local branch, squash, and push the new squashed branch.)
|
||||
|
||||
|
||||
* **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)).
|
||||
|
||||
### Editing files directly on GitHub.com
|
||||
|
||||
|
|
|
|||
|
|
@ -308,7 +308,7 @@ The following example runs an if statement, and a loop on *Children*, checking t
|
|||
</a>
|
||||
</li>
|
||||
<% end_loop %>
|
||||
<ul>
|
||||
</ul>
|
||||
<% end_if %>
|
||||
</li>
|
||||
<% end_loop %>
|
||||
|
|
|
|||
|
|
@ -229,8 +229,7 @@ class TreeDropdownField extends FormField {
|
|||
? (int)$request->latestparam('ID')
|
||||
: (int)$request->requestVar('ID');
|
||||
|
||||
$forceFullTree = $request->requestVar('forceFullTree')?$request->requestVar('forceFullTree'):false;
|
||||
if($ID && !$forceFullTree) {
|
||||
if($ID && !$request->requestVar('forceFullTree')) {
|
||||
$obj = DataObject::get_by_id($this->sourceObject, $ID);
|
||||
$isSubTree = true;
|
||||
if(!$obj) {
|
||||
|
|
|
|||
|
|
@ -376,15 +376,15 @@ class DataList extends ViewableData implements SS_List, SS_Filterable, SS_Sortab
|
|||
$whereArguments = func_get_arg(0);
|
||||
} elseif($numberFuncArgs == 2) {
|
||||
$whereArguments[func_get_arg(0)] = func_get_arg(1);
|
||||
} else {
|
||||
} else {
|
||||
throw new InvalidArgumentException('Incorrect number of arguments passed to exclude()');
|
||||
}
|
||||
|
||||
}
|
||||
|
||||
return $this->alterDataQuery(function($query, $list) use ($whereArguments) {
|
||||
$subquery = $query->disjunctiveGroup();
|
||||
|
||||
foreach($whereArguments as $field => $value) {
|
||||
$fieldArgs = explode(':', $field);
|
||||
$fieldArgs = explode(':',$field);
|
||||
$field = array_shift($fieldArgs);
|
||||
$filterType = array_shift($fieldArgs);
|
||||
$modifiers = $fieldArgs;
|
||||
|
|
@ -393,16 +393,16 @@ class DataList extends ViewableData implements SS_List, SS_Filterable, SS_Sortab
|
|||
$t = singleton($list->dataClass())->dbObject($field);
|
||||
if($filterType) {
|
||||
$className = "{$filterType}Filter";
|
||||
} else {
|
||||
} else {
|
||||
$className = 'ExactMatchFilter';
|
||||
}
|
||||
if(!class_exists($className)){
|
||||
$className = 'ExactMatchFilter';
|
||||
array_unshift($modifiers, $filterType);
|
||||
}
|
||||
}
|
||||
$t = new $className($field, $value, $modifiers);
|
||||
$t->apply($subquery);
|
||||
}
|
||||
}
|
||||
});
|
||||
}
|
||||
|
||||
|
|
@ -453,29 +453,29 @@ class DataList extends ViewableData implements SS_List, SS_Filterable, SS_Sortab
|
|||
}
|
||||
|
||||
/**
|
||||
* Translates the comparisator to the sql query
|
||||
* Translates a filter type to a SQL query.
|
||||
*
|
||||
* @param string $field - the fieldname in the db
|
||||
* @param string $comparisators - example StartsWith, relates to a filtercontext
|
||||
* @param string $filter - example StartsWith, relates to a filtercontext
|
||||
* @param array $modifiers - Modifiers to pass to the filter, ie not,nocase
|
||||
* @param string $value - the value that the filtercontext will use for matching
|
||||
* @todo Deprecated SearchContexts and pull their functionality into the core of the ORM
|
||||
*/
|
||||
private function applyFilterContext($field, $comparisators, $modifiers, $value) {
|
||||
if($comparisators) {
|
||||
$className = "{$comparisators}Filter";
|
||||
private function applyFilterContext($field, $filter, $modifiers, $value) {
|
||||
if($filter) {
|
||||
$className = "{$filter}Filter";
|
||||
} else {
|
||||
$className = 'ExactMatchFilter';
|
||||
}
|
||||
if(!class_exists($className)){
|
||||
if(!class_exists($className)) {
|
||||
$className = 'ExactMatchFilter';
|
||||
array_unshift($modifiers, $comparisators);
|
||||
array_unshift($modifiers, $filter);
|
||||
}
|
||||
$t = new $className($field, $value, $modifiers);
|
||||
|
||||
return $this->alterDataQuery(array($t, 'apply'));
|
||||
}
|
||||
|
||||
|
||||
/**
|
||||
* Return a copy of this list which does not contain any items with these charactaristics
|
||||
*
|
||||
|
|
@ -517,13 +517,13 @@ class DataList extends ViewableData implements SS_List, SS_Filterable, SS_Sortab
|
|||
$t = singleton($list->dataClass())->dbObject($field);
|
||||
if($filterType) {
|
||||
$className = "{$filterType}Filter";
|
||||
} else {
|
||||
} else {
|
||||
$className = 'ExactMatchFilter';
|
||||
}
|
||||
}
|
||||
if(!class_exists($className)){
|
||||
$className = 'ExactMatchFilter';
|
||||
array_unshift($modifiers, $filterType);
|
||||
}
|
||||
}
|
||||
$t = new $className($field, $value, $modifiers);
|
||||
$t->exclude($subquery);
|
||||
}
|
||||
|
|
@ -609,7 +609,7 @@ class DataList extends ViewableData implements SS_List, SS_Filterable, SS_Sortab
|
|||
|
||||
return $result;
|
||||
}
|
||||
|
||||
|
||||
/**
|
||||
* Walks the list using the specified callback
|
||||
*
|
||||
|
|
@ -979,7 +979,7 @@ class DataList extends ViewableData implements SS_List, SS_Filterable, SS_Sortab
|
|||
public function remove($item) {
|
||||
// By default, we remove an item from a DataList by deleting it.
|
||||
$this->removeByID($item->ID);
|
||||
}
|
||||
}
|
||||
|
||||
/**
|
||||
* Remove an item from this DataList by ID
|
||||
|
|
|
|||
Loading…
Reference in New Issue
Block a user