| Age | Commit message (Collapse) | Author |
|---|
|
Fixes ticket #1353.
|
|
informative message to help the user know that she needs to get a
newer copy of the module. Fixes ticket #1189.
|
|
|
|
gallery/_cache row and it already exists. Fixes ticket #1338.
|
|
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.
|
|
which deactivates modules on upgrade. No idea why we did that, but it
breaks upgrading because it deactivates any module that's been
upgraded.
|
|
|
|
|
|
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.
|
|
|
|
installers to can_activate to reflect that it is doing more than just checking the environment.
|
|
|
|
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()
|
|
|
|
|
|
|
|
Conflicts:
modules/gallery/helpers/theme.php
modules/gallery/libraries/Admin_View.php
modules/gallery/libraries/Theme_View.php
|
|
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
|
|
Convert all open_paren() calls to and_open() or or_open() as appropriate.
|
|
|
|
- Kohana::log() -> Kohana_Log::add()
- Kohana::config_XXX -> Kohana_Config::instance()->XXX
- Implement View::set_global in MY_View
- Updated Cache_Database_Driver to latest APIs
- ORM::$loaded -> ORM::loaded()
- Updated item::viewable() to use K2.4 parenthesization
|
|
module_name:block_id. This allows easier lookup of blocks to remove when modules
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.
|
|
shouldn't be managed by the default module administration screen. This module will always be locked on that screen.
|
|
current identity provider modules. Call module::deactive to truly deactivate the module.
|
|
changing providers.
|
|
remove_rule.
|
|
Conflicts:
lib/gallery.common.css
themes/admin_wind/views/admin.html.php
themes/night_wind/views/sidebar.html.php
themes/wind/views/sidebar.html.php
|
|
modules. In addition add a method "info" to return the module information contained in the module.info file
|
|
Identity constructor to look in module::get_var(gallery, identity_provider) for the current identity driver.
In addition, don't just arbitrarily lock the use module. Only lock gallery and the module that is referenced by "user_driver_module" variable.
|
|
the module or theme. This checks for the existence of an application/modules or application/themes first."
This reverts commit e1e1461a77caf5bff457927f098366497de6ffff.
|
|
module or theme. This checks for the existence of an application/modules or application/themes first.
|
|
and deactivate the sidebar blocks when the module is deactivated.
|
|
|
|
arguments... context menu events have 4 arguments.
|
|
gallery_event::$function first
* Refactor gallery.php to move site_menu, admin_menu, and context_menu to gallery_event.php
* Change Theme_View and Admin_view to call module::event("site_menu|admin_menu|context_menu"...)
|
|
install() function if all you're going to do is to set the version of
the module from module.info into the database. This means that for some
simple modules, you don't need an install.php file at all.
|
|
the "context" menu.
This new context menu is generated using the typical event processing
system, like our other menus. The specialized quick CSS and JS is now
gone, replaced by our generic menu handling code. It's all rolled
together currently using the thumb_menu UI for easy packaging. All
the CSS and JS is updated.
NOTE: the non-dialog links (rotate, album_cover) have a broken UI
because they return JSON which the quick.js code handled specially,
but we don't handle properly now. I need to fix this.
|
|
truncate incoming_translations after this
update to get rid of bad messages in your DB.
|
|
|
|
Add xxx_installer::upgrade($version) method so that upgrade stanzas
are separate from install stanzas. In the old code, to do an upgrade
meant that you had to re-evolve everything from the initial install
because we'd step through each version's changes. But what we really
want is for the initial install to start off in the perfect initial
state, and the upgrades to do the work behind the scenes. So now the
install() function gets things set up properly the first time, and the
upgrade() function does any work to catch you up to the latest code.
See gallery_installer.php for a good example.
|
|
|
|
|
|
|
|
install/activate/deactivate/uninstall events.
|
|
the module list (to match its location in the cascading filesystem)
|
|
that all other modules can override the core code.
|
|
|
|
gallery module. This type of mass update is prone to some small bugs.
|
|
Kohana makes this type of transition fairly straightforward in that
all controllers/helpers/etc are still located in the cascading
filesystem without any extra effort, except that I've temporarily
added a hack to force modules/gallery into the module path.
Rename what's left of "core" to be "application" so that it conforms
more closely to the Kohana standard (basically, just
application/config/config.php which is the minimal thing that you need
in the application directory)
There's still considerable work left to be done here.
|
