The functionality is easy to replicate in custom controllers,
and is too rarely used to be placed in core.
This also removes the `Member::is_repeat_member()` getter
and the `PastMember`/`IsRepeatMember` template globals.
See https://groups.google.com/forum/#!topic/silverstripe-dev/b8K3wU64TXg
Added tests to RequiredFields and fixed bugs that were found
Now you:
1. Can't add the same field name many times
2. Can use append RequiredFields correctly without fear of duplicates
I've also added a Deprecation warning to $useLabels as it's not used
*anywhere* in framework
Header parsing now takes into account situations like a proxy or
redirections. Works around the curl issue.
Also fixes the issue when a redirected request would cause a double
amount of headers coming out of the parser - it would merrily process
anything that's in key:value format even if it was two distinct headers.
When using Controller::join_links to join two links with identical query
params, both query params would be used in the result, ending up with
links that look like `../edit/show/14?locale=en_NZ&locale=mi_NZ`
This patch eliminates duplicate query params, so only the last one
for any key is present in the output.
If more than two $from were added through SQLQuery->addFrom(),
the getOrderedJoins() comparison kicks in. It assumes all $from
parts are in array notation, which isn't always the case.
For legacy reasons, and because we don't have full API support,
you can still add literal joins through addFrom('INNER JOIN ...').
On PHP 5.3, the ordering comparison still works because it
allows array access in strings, with string rather than numeric indexes.
Thankfully that's no longer supported in PHP 5.4.
- Added content formatting behat feature file Updated Given statement for Insert link behat feature file
- Added Behat test feature file for alignment buttons Updated formatting buttons feature file to include strikethrough formatting
DataQuery::initialiseQuery() will add a default sort to a query,
and when calling up an aggregate it will make a query like this
which doesn't make sense:
SELECT MAX("LastEdited") FROM "Member" ORDER BY "ID"
In this case there is no need to add the ORDER BY, and it will
break databases like MSSQL in cases such as
GenericTemplateGlobalProvider
which provides a default List() function for adding aggregates
into SSViewer template cacheblocks.
If we add a limit, however, then it does make sense:
SELECT MAX("LastEdited") FROM "Member" ORDER BY "ID" LIMIT 10
This fixes SQLQuery::aggregate() to NOT add an ORDER BY to an
aggregate call if there is no limit.
Due to the recent change of translations to transifex, some
locales changed their names, which prompted a fix to
i18n::get_available_translations() (see 00ffe7294).
This caused a regression where short locales are determined
from the YAML file names (e.g. "en"), but weren't matched up
with fully qualified locales from get_available_translations() (e.g. "en_US").
Since this list is used in the admin/myprofile dropdown for the Member.Locale value,
it didn't match up with any entries and defaulted to the first one ("Africaans").
Note that the behaviour of admin/myprofile is still a bit weird:
It defaults the locale on new members to the one set for the current administrator.
So if a site defaults to en_US in _config.php, but the admin happens to view
his backend in de_DE, all members he creates default to de_DE as well.
Thanks to @tractorcow for contributing and peer reviewing!
If multiple image manipulations are performend the resulting cached image is stored in assets/_resampled because the cached version of the image has no ParentID, which cacheFilename needs to set the correct path.
- Based on new (last) translation download from getlocalization.com
- Removed untranslated strings. Getlocalization started including those at some point
which is highly annoying, unnecessary and breaks the new transfix system,
since it'll mark all of the english strings as actual translations
- Avoid dots in entities. It confuses the Transifex YML parser
- Removed some locales unknown to Transifex which didn't have any translations anyway
- Removed "lolcat" locale, uses custom notation (en@lolcal)
which SilverStripe's i18n system can't handle
(needs mapping from SS naming to Zend naming)
- Renamed "Te Reo/Maori" locale from "mi_NZ" to "mi" (Transifex/CLDR notation)
- Namespaced all entities used in templates (deprecated usage)
- Converted dots to underscores where template filenames are used for namespaces,
since Transifex YML parsing handles them as separate YML keys otherwise
- Removed whitespace in entity names, SilverStripe i18n can't handle it
- Only allow selection of locales registered through i18n::$all_locales to avoid
issues with unknown locales in Zend's CLDR database
Allow DataList::limit() to take a null value to remove the limit.
Added tests for limit(). Note the one failure, currently the ORM doesn't support unlimited values with an offset.
The function "first" on ArrayList uses the PHP function "reset", which
returns false if there aren't any elements in the array. Two functions
inside ArrayList use this function, "canFilterBy" and "byID". I've
changed these functions to catch the possibility of a false return from
first().
Session tracks the user agent in the session, to add some detection of
stolen session IDs. However this was causing a session to always be
created, even if this request didnt store any data in the session.
urlRewriter will expect a callable as a second parameter,
but will work with the current api and simply raise a deprecation error.
HTTP::absoluteURLs now correctly rewrites urls into absolute urls. Resolves introduced in c56a80d6ce
HTTP::absoluteURLs now handles additional cases where urls were not translated.
Test cases for HTTP::absoluteURLs added for both css and attribute links.
Cleaned up replacement expression and improved documentation.
Commit 964b3f2 fixed an issue where dbObject was returning casting helpers for
fields that were not actually DB objects, but had something in $casting config.
However, because dbObject was no longer calling DataObject->castingHelper, this
exposed a bug that the underlying function db($fieldName) was not returning
field specs for the base fields that are created by SS automatically on all
DataObjects (i.e. Created, LastEdited, etc).
This commit fixes the underlying issue that DataObject->db($fieldName) should
return the field specs for *all* DB fields like its documentation says it will,
including those base fields that are automatically created and do not appear in
$db.
