- added module::deactivate_missing_modules()
- revised module::deactivate() to change log message if the module is missing
- added call to new function in module::get_obsolete_modules_message()
- added call to new function when loading admin/maintenance menu
- fixed all instances of this in core code
- deleted previous Zend Guard Loader workaround in MY_Kohana.php
- updated Bootstrap.php to reflect deleted MY_Kohana.php
- added module::get_obsolete_modules_message function
- put message on admin/dashboard
- put message on admin/modules
- put message on upgrader
- updated unit test golden file xss_data
name=_cache row. If that overflows, it will cause us to be unable to
load variables, and we can't recover from that.
Instead, use the Cache table. Bump the gallery module to v40. Fixes
ticket #1405.
module ordering, which is currently being done in the moduleorder
contrib module.
By default, the weight will be the same as the id of the row which
means that new modules will get added at the end of the list. This is
covered in the upgrade case as well.
The one gotcha is that we need to make sure that we don't try to sort
by the weight column if the gallery module version is < 32, which is
something we haven't done before.
mostly issues around uninitialized variables, calling non-static
functions in a static context, calling Session functions directly
instead of on its singleton, passing non-variables by reference, and
subclasses not using the same interface as the parent class.
which is called prior to installation. The method allows the module to provide
an error message or warnings if the module can not be installed or activated
without issues. The admin module controller also will fire a pre_deactivate
event, which allows modules to indicate issues that may arise be deactivating the
specified module.
These messages are displayed in a dialog box prior to installation in order to
allow the gallery administrator to determine the appropriate action before proceeding.
Lays the foundation for implementing a fix for ticket #937
for lookup. So instead of doing:
ORM::factory("foo", array("some_key" => "some_value"))
you have to do:
ORM::factory("foo"->where("some_key", "=" "some_value")->find()
modules, and have an admin subdirectory that is treated like a Kohana
module (as distinct from a Gallery module).
The main advantage of creating the separate admin subdirectory is that
we will not load an admin theme and a site theme at the same time.
We'll only load a few specialized bits of the site theme while the
admin theme is active.
Concrete examples. A site theme named "xxx":
- will receive events at themes/xxx/helpers/xxx_event.php
- will have working controllers at themes/xxx/controllers/xxx.php
If theme xxx has an admin subdir, then in admin mode it:
- will receive events at themes/xxx/admin/helpers/xxx_event.php
- will have working controllers at themes/xxx/admin/controllers/xxx.php
are being deactivated. Change the module activation/deactivation to call (activate|deactivate)_blocks instead of just the sidebar blocks. This insures
that when a module is deactivated any admin dashboard blocks are removed as well the site sideboard blocks. Fix for ticket #876.
