Avoid PHPUnit throwing "test didn't run any assertions"
notices in PHP. If nothing else, it keeps test output
looking less broken by default, making it more likely
that actual errors do get noticed.
This became a problem with fdcd7a2e where $custom_database_fields
were cached, but never reset. It lead to extensions not applying
correctly in SapphireTest->setUpOnce().
Previously changes to $requiredExtensions and $illegalExtensions
didn't cause a reset unless there was also other schema-altering
settings like $extensionsToRemove or $extraDataObjects
Settings.url no longer contains the URL, as a result navigating around
tabs in IE (browsers that do not support History API) becomes broken.
For example when the admin is opened on "Pages" section it is impossible to
navigate to specific page, or if the admin is opened on a tab, it's not
possible to navigate to another tab.
Since the tinymce upgrade from 3.5.6 to 3.5.7 it seems like data attributes are forbidden on tags.
This fix tells tinymce to allow data* properties on img tags
Quoted table / column names to make test cases work in postgres
BUG Fixed issue with SQLQuery::lastRow crashing on empty set. Added test cases for lastRow and firstRow.
Quoted table / column names to make test cases work in postgres
Merge branch '3.0-sqlquery-lastrow-fix' of github.com:tractorcow/sapphire into 3.0-sqlquery-lastrow-fix
- Moved some docs around to reflect this change
- Described how to symlink from vendor/bin/phpunit
- Added note about browser-runs not being recommended
- Added more examples on how to run through "sake",
to complement the existing descriptions for "phpunit"
Since the tinymce upgrade from 3.5.6 to 3.5.7 it seems like data attributes are forbidden on tags.
This fix tells tinymce to allow data* properties on img tags
Refactor the code to make it clear the distinction is made between a
plaintext token and a hashed version. Rename fields so it is more
obvious what is being written and what sent out to the user.
This reuses the salt and algorithm from the Member, which are kept
constant throughout the Member lifetime in a normal scenario. If they do
change, users will need to re-request so the hashes can be regenerated.
