- Added manifest logic docs
- More obvious pointers to flushing
- Removed Director page since it duplicated a lot of information already presenting in routing,
which in itself is already duplicated between routing.md and controllers.md.
- Merged Director execution rundown into main exec pipeline docs
- Moved YAML security note from main installation docs to "secure coding", making it sless obvious
Detect and parse HTTP_AUTHORIZATION for basic authentication running PHP in CGI mode
Add comments about using CGI mode with Apache and Basic Auth in /docs/en/topics/environment-management.md
Added notes to docs/en/changelogs/3.1.9.md
* Fix a few missing packages in `apt-get install` command
* Add command to start HHVM automatically on boot
* Remove unnecessary `sendfile on` (already in /etc/nginx/nginx.conf)
Removed parent::onAfterPublish(); because Page parents does not implement it. The old code generate this error:
Error at framework/core/Object.php line 761: Uncaught Exception: Object->__call(): the method 'onafterpublish' does not exist on 'MyPage' (http://ssdev-master.zk/admin/pages/edit/EditForm)
I've decoupled `Cookie` from the actual act of setting and getting
cookies. Currently there are a few limitations to how Cookie works that
this change mitigates:
0. `Cookie` currently changes the super global `$_COOKIE` when setting
to make the state of an application a bit more managable, but this is
bad because we shouldn't be modifying super globals
0. One can't actually change the `$cookie_class` once the
`Cookie::$inst` has been instantiated
0. One can't test cookies as there is no class that holds the state of
the cookies (it's just held in the super global which is reset as part
of `Director::test()`
0. One can't tell the origin of a cookie (eg: did the application set it
and it needs to be sent, or did we receive it from the browser?)
0. `time()` was used, so testing was made difficult
0. There was no way to get all the cookies at once (without accessing
the super global)
Todos are on the phpdoc and I'd like to write some tests for the backend
as well as update the docs (if there are any) around cookies.
DOCS Adding `Cookie` docs
Explains basic usage of `Cookie` as well as how the `Cookie_Backend`
controls the setting and getting of cookies and manages state of sent vs
received cookies
Fixing `Cookie` usage
`Cookie` is being used inconsistently with the API throughout framework.
Either by not using `force_expiry` to expire cookies or setting them to
null and then expiring them (which is redundant).
NEW `Director::test()` takes `Cookie_Backend` rather than `array` for `$cookies` param
This pattern improves over the current usage of singleton by allowing type inference.
This also better supports refactor, code usage detection, and auto-completion of classes.
API Mailer bounce email can now be configured
API Mailer no longer calls Convert::xml2raw on all email subjects
API Deprecate dead Mailer code and refactored duplicate or mis-documented code.
Updated Composer command to reference latest stable version as advised
Removed testing installation via Browser step
Added a note about the PHPUnit 3.7 requirement for running tests via the Browser
Step by step Composer installation instructions, including a composer.json example.
In addition:
- Removed self-page reference to an introduction
- Removed reference to PEAR installation instructions due to end of life
- Removed reference to Ruby as doesn't add value
- Shortened testing via Web Browser section (as covered in Composer installation instructions)
These should be avoided because they undermine the process of
peer review and merging in github, we should strive to have
zero open pull requests, as opposed to treating it as a stage
for work in progress. Intermediary code review can happen in github forks instead.
Also remove some checklist items which were based on the Trac bugtracker,
e.g. its not longer possible to assign yourself to issues because
of github's limited permission abilities.
Provides an interface for classes to implement their own flush()
functionality. This function gets called early in a request on
all implementations of Flushable when flush=1|all is requested in the
URL.
This fix came out of an issue where Requirements combined files were not
being cleaned up after dev/build?flush=1, due to the fact that flush
would only occur when you called it while on a page that used those
combined files, but not in any other contexts. This will now call flush
on any implementors of Flushable regardless of the context of where
flush was called.
getTempParentFolder() in framewor/core/TempPath.php checks for silverstripe-cache directory in webroot first, failing that it falls back on the sys_get_temp_dir() folder.
also, getTempFolder() is no longer in framework/core/Core.php since #b075fa29c59f970bea31bbe8be1bd6560a8778b6, it is now located in framework/core/TempPath.php
There's no way to make things like [api:DataObject->beforeUpdateCMSFields()] work, is there?
I removed those kind of api tags (the links yielded a 404 page), and corrected a few other link-rendering issues.
BUG Fix incompatibility in Member_GroupList
Fix regressions in merges from 3.1
BUG Fix Security failing on test classes
BUG Fix postgresql compatibility
Clarify sql encoding of table names
Database abstraction broken up into controller, connector, query builder, and schema manager, each independently configurable via YAML / Injector
Creation of new DBQueryGenerator for database specific generation of SQL
Support for parameterised queries, move of code base to use these over escaped conditions
Refactor of SQLQuery into separate query classes for each of INSERT UPDATE DELETE and SELECT
Support for PDO
Installation process upgraded to use new ORM
SS_DatabaseException created to handle database errors, maintaining details of raw sql and parameter details for user code designed interested in that data.
Renamed DB static methods to conform correctly to naming conventions (e.g. DB::getConn -> DB::get_conn)
3.2 upgrade docs
Performance Optimisation and simplification of code to use more concise API
API Ability for database adapters to register extensions to ConfigureFromEnv.php
Changed Fragment links to Anchor links, however it's is slighty confusing what the right name for the thing is.
According to w3.org: "Some URIs refer to a location within a resource. This kind of URI ends with "#" followed by an anchor identifier (called the fragment identifier)." - http://www.w3.org/TR/html401/intro/intro.html#fragment-uri
After doing some research in the most common used name for the #some-link identifier I came to the conclusion that most of the time (about 70% on StackOverflow/BlogArticles/Interwebz) Anchor-link was the term used to describe the identifier. Imho, Anchor is the prefered term for the identifier.
Is it acceptable to change fragment to anchor, since it seems more used?
