summaryrefslogtreecommitdiff
path: root/modules/info/helpers/info_installer.php
AgeCommit message (Collapse)Author
2013-06-12change "size" to "dimensions" and display unit "px"jamaa
2013-06-12fix upgrade functionjamaa
allow for sequential upgrades
2013-06-12fix whitespacejamaa
2013-06-12add the image size (in pixels) to the info modulejamaa
adds a new variable "show_size", so had to increment the version number to 3
2013-01-31Drop the requirement to have the install() function set the moduleBharat Mediratta
version. It's redundant. Fixes #1985.
2013-01-21Update copyright to 2013. Fixes #1953.Bharat Mediratta
2012-02-27Update copyright to 2012. #1822Bharat Mediratta
2011-01-21Update copyright to 2011.Bharat Mediratta
2011-01-05Added info module show metadata options and set all to true. Admins may turn ↵Chad Kieffer
off display of items from the Advanced Settings list.
2009-09-05Change the module installer so that you don't need to provide your ownBharat Mediratta
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.
2009-06-23Refactor the install/upgrade code to be more flexible.Bharat Mediratta
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.
2009-05-26Restructure the module lifecycle.Bharat Mediratta
Install: <module>_installer::install() is called, any necessary tables are created. Activate: <module>_installer::activate() is called. Module controllers are routable, helpers are accessible, etc. The module is in use. Deactivate: <module>_installer::deactivate() is called. Module code is not accessible or routable. Module is *not* in use, but its tables are still around. Uninstall: <module>_installer::uninstall() is called. Module is completely removed from the database. Admin > Modules will install and activate modules, but will only deactivate (will NOT uninstall modules).
2009-05-13Gee it's May already. Update copyright to 2009.Bharat Mediratta
2009-01-14Make sure that helper functions are all static. Add newBharat Mediratta
File_Structure_Test to make sure we don't regress. According to the PHP docs, the "public" keyword is implied on static functions, so remove it. Also, require private static functions to start with an _. http://php.net/manual/en/language.oop5.visibility.php
2008-11-27Centralize logging around installing/uninstalling modules.Bharat Mediratta
2008-11-22Convert gmaps, info, and tag modules to the new block moduleTim Almdal