Bots often have the habit of trying a next page, even if there isn't one.
Thus, using CurrentPage < TotalPages, prevents from unwanted next-links being shown.
Fixes issue of templates not being found when a Page's main/Layout templates are split between the project and theme folders. Adds more expansive testing for template loading.
The error thrown by `parseStatic` when there's an unexpected token is now more meaningful as it states the type of token that was encountered as well as the class that it was found in.
Previously, generated cache results that returned 0, '', array() etc
were being ignored. This change narrows it down to just false.
Ideally we would use a EmptyCacheHit object to be very specific for
these cases, but perhaps this approach is a bit overkill.
Changed error from: Fatal error: Hmm - depth calc wrong, hit negatives in /var/www/tangoio.maori.nz/framework/core/manifest/ConfigStaticManifest.php on line 242
... to ....
Fatal error: Hmm - depth calc wrong, hit negatives, see: /var/www/mysite.maori.nz/mymodule/code/MyClass.php in /var/www/mysite.maori.nz/framework/core/manifest/ConfigStaticManifest.php on line 240
The first error is completely meaningless and impossible to debug...
The recent flush filter fix had a problem that you couldnt set a custom
BASE_PATH in _ss_environment because that file didnt get included until
after checking the confirmation token. This patch pulls the part of Core.php
that defines BASE_PATH into a seperate file that can be included earlier
in the startup sequence so that ParameterConfirmationToken can access it.
Core.php includes Constants.php with a require_once call, so for startup
scripts that dont pull in Constants.php themselves (like cli-script.php)
no change is needed.
When a method was not found on UnsavedRelationList I was getting the following error:
Object->__call(): the method 'nameOfMethod' does not exist on ''
(nameOfMethod has been replaced here since it was a method I added via an extension)
Change the in_array call to not do bad things with strict casting off
Add a deprecated message if you run with magic_quotes on
Change the requirement for magic_quotes to an error
Fixing the logic that searches for environment files so that warnings
due to open_basedir are suppressed and both the 'realdir' and the server
path are spidered for the environment file.
Cleanup of framework's use of @package and @subpackage labels and additional of labels for classes missing packages.
Moved all GridField related components to the one name.
Countless spelling fixes, grammar for other comments.
Link ClassName references in file headers.
Anyone who has run "sudo -u www-data ./framework/sake dev/build" knows that SilverStripe's temp
folder permissions can be very brittle. This patch resolves this by making the temp folder
user-specific.
To minimise directory pollution it first creates a chmod 777 parent folder with the same name
as the current folder. It then creates a subfolder of this with the same name as the current
user.
The positive impact of this change is that sake can be used without fear of messing up file
permissions. This means, among other things, that we can put a Composer post-update-cmd into
the installer to run dev/build. Progress!
The negative impact is that you will get two caches if you run sake as a different user. However,
that is much better than the current situation - which is a bunch of bugs - and if you're concerned
about that, you still have the option of running sake as www-data.
DO NOT MERGE: to be reviewed. Only i18n & Deprecation classes use
->getModules() as far as I can see. Given that the method still simply
returns an array of modulename => modulepath, I don't think it's really
an API change
This reverts commit 14b997eea3.
Its just not practical to use the Config API as it stands,
the add_extension() wrapper does more than just a Config->update().
Most use cases can be covered via YML, but any conditional
additions (e.g. in unit tests) can still benefit from the
add_extensions() shorthand.
Anyone who has run "sudo -u www-data ./framework/sake dev/build" knows that SilverStripe's temp
folder permissions can be very brittle. This patch resolves this by making the temp folder
user-specific.
To minimise directory pollution it first creates a chmod 777 parent folder with the same name
as the current folder. It then creates a subfolder of this with the same name as the current
user.
The positive impact of this change is that sake can be used without fear of messing up file
permissions. This means, among other things, that we can put a Composer post-update-cmd into
the installer to run dev/build. Progress!
The negative impact is that you will get two caches if you run sake as a different user. However,
that is much better than the current situation - which is a bunch of bugs - and if you're concerned
about that, you still have the option of running sake as www-data.
* Due to missing break, the T_STRING case would fall through to array.
* The values were being added to the wrong variable.
* Added missing support for missing null values.
The deprecations are supposed to denote the release where
the functionality will be removed, as opposed to the one where
its deprecated. Having 3.1 as a target for recent changes
in popular methods like Object::add_extension() causes
too many short-term hassles, there's no "grace period".
Extracted common code out to SS_HTMLValue and made abstract, then
put HTML 4 specific code in SS_HTML4Value. Its now possible to
replace HTMLValue with one designed for HTML 5 or XHTML
Requires a code change from new SS_HTMLValue to
Injector::inst()->create(HTMLValue)
The overhead of Zend_Cache in manifests is too high - we don't
need LRU or tags, just somewhere to dump a bunch of data that
persists
You can replace the class used by defining SS_MANIFESTCACHE
to be a class that implements the ManifestCache interface
(we can't use the Config system to set this, as it isn't
initialised yet).
It shouldnt be possible to get ConfigStaticManifest to parse
a user uploaded file, and if you could it shouldnt be possible
to form PHP that token_get_all could parse which would end
up executing any code.
However just in case it is, this changes the eval to assign to a
static, so the eval will give a syntax error if an attacker
manages to make $value look like `ls` or some other expression
