ModuleUpdates
http://codex.gallery2.org/Gallery3:Modules:moduleupdates
INSTALLATION
A link to the latest version can be found at the top of this post. Once downloaded upload the moduleupdates folder to your Gallery3 installation. Once uploaded log in with your administrator account and proceed to the Modules section. Check the box next to Module Updates and click Update at the bottom of the page. Once installed under Settings will be a new Module Updates page.
USAGE
Module Updates shows ALL modules on your system and not just the ones that are installed and active.
Going to the Module Updates page within the Settings area of your Gallery3 administration console will display the update information. This module will compare all of your installed modules against the Gallery3 Core, Gallery3 Community Contributions GitHub, and GalleryModules.com collection. It will then display to you the version you have residing in your Gallery3 installation against the versions found in the GitHub repositories. Results are color coded for easy identification and tagged to explain where they were found.
SUPPORTED VERSIONS
KNOWN ISSUES
- Modules that do not reside in the Gallery3 GitHub or GalleryModules will NOT be compared by this module. (Hint Hint: get your module added ;)
CHANGE LOG
- Version 1
- v1.0 Initial Release
- v1.1
- Removed rWatcher checking
- Added indicator for which location the update was found in
- Cleaned up code to conform to Gallery coding standards
- Added additional documentation to code
- v1.2 - 2010.06.23
- Fixed a bug where it was showing G3CC after a DNE
- Added the installed module version information
- Added alert for when a newer module is on the system but an older version is installed
- Added alert for when an installed module is newer than the one on the system
- Added version information on the Settings page to permit incremental update verification
- Version 2
- v2.0 - 2010.08.27
- Fixed: comply with translated/t("string") standards
- Added: New caching system. ModuleUpdates now caches the last results so that it does not check every time the page is run. The cache expires every 30 days, when the user selects the option to Check Modules for Updates, or the cache is empty.
- Added: Color coding for more cases when versions are out of sync (Orange = Your file version is newer than the installed version & Pink = Your installed version is newer than file version).
- Added: Each module now links to it's location in the Gallery Codex so if your version is out of date you can go get the official version. This also allows for manual verification of DNE modules that are not in the GitHub.
- Added: GitHub status check along with status check to access the internet outbound from your Gallery installation.
- Version 4
- v4.0 - 2010.11.23
- Fixed: version information during upgrade fixed with v3
- Fixed: comply with with new gallery 3 GitHub naming conventions
- Validated: built against v3.0 final
- Added: dynamically checks the correct GitHub based on the version currently installed (3.0 versus 3.1)
- Version 5
- v5.0 - 2011.01.04
- Fixed: Corrected an installation bug relating to zombie version numbers
- Added: Support for all 3.x versions by using dynamic version checking
- Added: Redesigned information to display version information from all sources
- Added: Links directly to the version's location
- Added: Support for checking GalleryModules.com module collection
- Version 7
- v7.0 - 2011.01.29
- Fixed: Several bugs relating to the new Community Contributed Modules section
- Version 8
- v8 - 2011.06.23
- Fixed: Bugs relating to the new Community Contributed Modules section & GCC stored modules
- Added: Modules information for the new Gallery 3.0.2 Modules tab
- Added: SPEED! The module checking process is now 60% faster than before thanks to logic updates in the data gathering process. The decrease in update checking time will be more noticeable as more modules are added.
- Version 11
- v11 - 2012.04.22
- Added: SPEED! Thanks to dmolavi, ModuleUpdates now downloads a ini of modules from GalleryModules and checks versions locally now. Module validation runs much faster now.
- Added: The new system now looks at reported version numbers and if those do not exist it falls back to codex version numbers. This allows a much broader range of modules to be checked than before. You should still add your modules to the Git though. ;)
- Fixed: ModuleUpdates works correctly with Gallery 3.0.3 using the new v11 code.
- Version 12
- v12 - 2012.11.17
- Fixed: Code cleanup thanks to DanielMuller
- Fixed: The module correctly uses the TMPPATH instead of VARPATH thanks to DanielMuller
Posted: Sun, 2010-06-20 18:17
Posts: 124
Image of v8 is attached below.
Posts: 124
I've uploaded a new copy to my GitHub for approval to the Contrib section.
v1.2 - 2010.06.23
Posts: 7994
Oh man this is awesome. I love it! A couple of suggestions:
1) If you choose, you could replace the existing "Modules" entry in the Admin menu with your own with this code in your
event handler:
$menu->get("modules")->url = url::site("admin/moduleupdates");2) You might consider using the Cache API to store data in the database for performance. Look at modules/gallery/controllers/combined.php for an example of getting/putting cache data.
---
Problems? Check gallery3/var/logs
bugs/feature req's | upgrade to the latest code | use git
Posts: 124
Oh sweet, the Cache API stuff will be great. I'll focus on that for a v2 release. That way I can just add an option to check for updates instead of pulling data each time.
I'm not sure if I want to get on the level of replacing the entire modules page but I have contemplated adding my code to the modules page itself. Once I get the cache stuff worked out I will start looking into doing that.
Posts: 337
Issue:
The module names & descriptions don't get passed to the translation function t("string").
Suggestion:
As I said in other thread, it would be great if this module could be extended to be able to upgrade Gallery it-self. Maybe Bharat has some ideas of how that could be done (?).
Thanks
!
Posts: 124
I'll have to look into the t("string") thing, I'm not exactly sure how that all works yet. Are there any good examples of what I should do for that?
Posts: 337
To make any string translatable via Gallery translation system, it must be passed to the translation function so it is being replaced by the translation of the selected language if exists. Take a look at the original module administration view page:
http://github.com/gallery/gallery3/blob/master/modules/gallery/views/admin_modules.html.php
t("Gallery Modules") t("Installed") t("Name") t("Version") t("Description") ... etcPosts: 124
Ok, gotcha. How do I know what words support being translated, or can I just t("") entire sentences and then it auto translates words in it?
::EDIT::
Nevermind, I'm already passing everything else through t() just not those two things... I'll get that fixed for the next update.
Posts: 124
Does the Cache system just store my variable + value in temp db location that I can call to see if it exists or not?
Posts: 337
Even if the string has no translation yet, it will be added to the translatable strings database so anyone can translate it to his language via Gallery 3 translation interface.
Posts: 7994
Yep. It's pretty easy. Check out http://docs.kohanaphp.com/libraries/cache for docs.
---
Problems? Check gallery3/var/logs
bugs/feature req's | upgrade to the latest code | use git
Posts: 124
Ok, I've implemented a working cache system so now it only triggers once every 30 days or when a user manually runs it. However does the cache system natively provide SQL injection protection like from mysql_real_escape_string() or do I need to implement something myself? I tried using mysql_real_escape_string() but it fails I'm guessing because I don't have an active connection on my pages themselves.
Posts: 7994
Hm. Can you explain a bit more about the SQL injection? I suspect that the cache system is resilient to SQL injection but if you can give me an example I can verify it.
---
Problems? Check gallery3/var/logs
bugs/feature req's | upgrade to the latest code | use git
Posts: 124
The MySQL page has some good info on it.
http://www.php.net/manual/en/security.database.sql-injection.php
In respect to my module and SQL Injection attacks, if someone specifically crafted a module description with an attack string in the name or description when I store it into the cache it could trigger. Also if someone manually manipulated that data from the local system the next time it's read back in it could also be vulnerable. The mysql_real_escape_string command protects from this by safely escaping SQL characters that are not usually caught by html escaping.
Posts: 7994
I'm very familiar with SQL injection
I was more interested in a specific example.
Under the covers we're using the ORM library to do the Cache updates in the database so you should be fully protected from SQL injection. I'm glad you're looking out for these issues, though!
---
Problems? Check gallery3/var/logs
bugs/feature req's | upgrade to the latest code | use git
Posts: 124
hehehe sorry, I misunderstood what you meant. :D
Posts: 2466
Is this module alive? I have downloaded the version but it does not show git state
Posts: 124
Yup it sure is, I've been working on v2 in my spare time.
What exactly is going wrong? How is the output of what you are seeing differing from what I have in the image above?
Posts: 2466
there
Posts: 124
It shows DNE if it is not located in the GIT (which Akismet & Comments are in the GIT for sure) or if it cannot make an outbound call to the GIT server. Does your server permit outbound HTTP calls? If not that would block it.
Posts: 2466
I could not imagine why not, what would not permit it? .htaccess?
what url used?
Posts: 124
If your host blocks outbound calls via their firewall. This still allows return data from inbound HTTP but not outbound calls originating from the code.
The URLs being called are;
http://github.com/gallery/gallery3/raw/master/modules/ + module_name + /module.info
http://github.com/gallery/gallery3-contrib/raw/master/modules/ + module_name + /module.info
Posts: 124
I'm almost done with v2, I'll add in a communication test at the top of the page to see if the system has the ability to make outbound calls to the GIT servers and the web in general.
Posts: 124
woo-hoo, version 2.0 is now up in my GitHub for evaluation to add to the main GitHub! I've added a new screenshot in the 2nd post above.
Posts: 7994
Pulled! Great work, brentil!
---
Problems? Check gallery3/var/logs
bugs/feature req's | upgrade to the latest code | use git
Posts: 573
Please update your module to reflect the new git repo structure:
Open modules/moduleupdates/controllers/admin_moduleupdates.php. Find:
//Check the Gallery3 Community Contributions GitHub if ($file == null) { try { $file = fopen ("http://github.com/gallery/gallery3-contrib/raw/master/modules/".$module_name."/module.info", "r");replace the "$file = fopen..." line with:
$file = fopen ("http://github.com/gallery/gallery3-contrib/raw/master/3.0/modules/".$module_name."/module.info", "r");--
For Gallery 3 modules and themes, visit GalleryModules.com.
For PHPNuke, phpBB2, and phpBB3 integration help, visit NukedGallery.net.
Posts: 124
Thanks for the information. I had to rebuild my machine so as soon as I get my dev tools back installed I'll get the update in place.
Posts: 67
I can't seem to enable this module anymore, says there was an error installing it. It was running fine then I disabled it... now it won't enable again...
Any thoughts or is there something I can look at?
Posts: 124
Hmmm I've done a lot of install/uninstall tests. The maintenance tab might have some more info if there's an error.
Also I haven't installed and tested against the official 3.0 release yet either since I have to figure out how to re-sync my GitHub against the main account.
Posts: 67
I don't see anything in the maintenance tab regarding any errors... or that an attempt was made to active a module. I only see a log on a success for activate/deactivate...
Posts: 124
Cause the issue to happen and then go into your folder structure /gallery/var/logs and download the log for the day you made the error happen. That should hopefully contain error data you can post here.
Posts: 67
2010-11-15 07:21:53 -08:00 --- error: exception 'Exception' with message '@todo MODULE_FAILED_TO_UPGRADE' in /var/g3/modules/gallery/helpers/module.php:243
Stack trace:
#0 /var/g3/modules/gallery/controllers/admin_modules.php(89): module_Core::upgrade('moduleupdates')
#1 /var/g3/modules/gallery/controllers/admin_modules.php(51): Admin_Modules_Controller->_do_save()
#2 [internal function]: Admin_Modules_Controller->confirm()
#3 /var/g3/modules/gallery/controllers/admin.php(62): call_user_func_array(Array, Array)
#4 [internal function]: Admin_Controller->__call('modules', Array)
#5 /var/g3/system/core/Kohana.php(331): ReflectionMethod->invokeArgs(Object(Admin_Controller), Array)
#6 [internal function]: Kohana_Core::instance(NULL)
#7 /var/g3/system/core/Event.php(208): call_user_func_array(Array, Array)
#8 /var/g3/application/Bootstrap.php(67): Event_Core::run('system.execute')
#9 /var/g3/index.php(97): require('/var/g3/applic...')
#10 {main}
Posts: 241
I was going to try this out but I already know it will fail because allow_url_fopen is set to Off at my host. Any thoughts about adding an alternative Curl connection method if fopen fails? I could probably install it and create my own connection routine using Curl or Fsockopen which is what I use to grab website and RSS feeds from other sites.
Hmmmm...
Thanks,
Mark H.
Using Gallery 3.0+(git) - gallery.markheadrick.com
Posts: 20
I'm having the same issue with moduleupdates (same log) as "crackers". I was able to activate before, but when I tried to disable and enable again - got this error: An error occurred while installing the Module Updates module
Posts: 124
This might be an issue with the final version of Gallery 3 since I developed against the RC versions. I need to upgrade my Gallery still and once I do I'll begin fixing these issues.
Posts: 124
Hmmm, I just upgraded to v3.0 final release and uninstalled and reinstalled the module and I'm not having any issues. The quick solution will be to manually delete the database entries inserted by the application and try again. I'd suggest deleting the files from the system and uploading a new copy as well from the official page.
DELETE FROM modules WHERE name='moduleupdates'
DELETE FROM caches WHERE tags LIKE '%ModuleUpdates%'
If your tables have unique names you will have to modify them.
I just performed these steps on my install and then proceeded to successfully install it afterwards.
Posts: 67
That worked I s'pose. But now ModuleUpdates (downloaded from gallery3modules.com) says it isn't updated, and fails to update. Says I have version 2 installed and wants version 3. But AFAIK, I downloaded 3:
server:/var/gallery3/modules/moduleupdates# cat module.info
name = "Module Updates"
description = "Compares your installed module version against the ones stored in the GitHub."
version = 3
ah well...
Posts: 124
Looks like when someone updated my code to handle the new correct git structure they didn't update the part of the code that injects the version number into the modules table. So it's version 3 now from the updates but the system thinks it's 2. I'll work on getting a fresh git copy and updating the update.
The errors also probably come from this newer version someone else worked on, since I'm still working on my last copy I made.
Posts: 124
Where oh where can I get the current version from in the system??? The modules.info file and modules table both have the 41 version number and doing gallery::VERSION gives me "3.0 (Santa Fe)." All I want is the version number like it corresponds to the value in the git hub (3.0 or 3.1) so I can have my program dynamically lookup the location based on what version your running instead of needing to upgrade the module every time.
Posts: 124
Ok, I made a little hack for now to get the data I want from gallery::VERSION for now. Version 4.0 of ModuleUpdates is now in my git waiting to be pulled.
[*]Fixed: version information during upgrade fixed with v3
[*]Fixed: comply with with new gallery 3 GitHub naming conventions
[*]Validated: built against v3.0 final
[*]Added: dynamically checks the correct GitHub based on the version currently installed (3.0 versus 3.1)
Posts: 7994
I pulled your changes. But I noticed that Alex Schomburg (alexschomb here in the forums) made some changes on top of yours and I'm having difficulty merging those because there are conflicts. Can you guys put your heads together and get your forks clean so that I can merge in all the goodness? That'd be great, thanks!
---
Problems? Check gallery3/var/logs
bugs/feature req's | upgrade to the latest code | use git
Posts: 124
Yup, sure will.
Posts: 19
Oh, I didn't even know there is a place like this. Thanks to bharat for redirecting me to this topic.
In the past month I did commit some changes to your update without asking you, sorry for that, I hope you don't mind. bharat mentioned there is a conflict error that might result in our both versions. Actually I don't know how to directly solve that problem. Actually I just changed your script a little bit to work with the new GalleryModules.com interface done by dmolavi. But for getting this done I kept it real simple and removed all your GitHub checks as GalleryModules.com does this itself. I also asked dmolavi to check for the modules of the main repo (gallery3, not gallery3-contrib) so we can get some results for these modules too. He agreed to implement it, but I don't think it's ready yet.
As I can see you, brentil, did some commit some changes to the script lately. My suggestion would be pulling your changes to the script and removing my commits that refer to your script. This should solve the conflicts. After that we can integrate the check for GalleryModules.com again if you agree to this. The big question is whether you want your script to work either in the way it did before (checking itself against the git repos), the way I implemented it (checking itself against GalleryModules.com) or a combination of both solutions that let's the user choose (a little bit harder to implement).
With best regards,
Alex.
Posts: 124
What I was thinking of doing was one of 2 things.
1 - Check the Git & GM and show both values with an indication as to which ones have versions different than what you have with links to both
2 - Give the user the choice of what place to check and then give them that information
I'll look at both and see which one will be the most robust to implement.
Posts: 124
Version 5 is now in my GitHub for both 3.0 and 3.1. This merges Alex's code with mine along with some extras.
Posts: 19
Great job. Thank you very much!
The check against GalleryModules.com and gallery3.git seems to work correctly. But in the column for gallery3-contrib are no version entries shown at all.
Two little suggestions on the side:
First, it would be good to change to subtitle from "Compares your installed module version against the ones stored in the GitHub." to "Compares your installed module version against the ones stored in remote locations."
Second, the column titles don't fit to the titles in the description. For myself it's clear that "Core" means gallery3.git, but that might not be clear to other users.
Posts: 124
I'll add the verbiage clarifications in the next version.
Hmm, mine is showing updates for the Contrib versions. I'll pull from the git and test that just to make sure I didn't miss uploading something.
Posts: 573
You need to update your download links in Codex and at the top of this post, they point to the gallery3/gallery3-contrib repo, which doesn't have version 5 yet, or submit a pull request so it gets pulled into the main repo.
--
For Gallery 3 modules and themes, visit GalleryModules.com.
For PHPNuke, phpBB2, and phpBB3 integration help, visit NukedGallery.net.
Posts: 124
I saw the pull request info but I don't know how to do it. Is there git documentation that will show me how to do that?
Posts: 573
Just click the pull request button on your repo page. it will send a request to the g3 admins to pull into the main repo.
But, before you do that, i noticed that you don't check the 3.1 repo on GalleryModules.com properly. The correct version URLs are as follows:
Gallery 3.0.x:
Version check - http://www.gallerymodules.com/m/<module_name> (http://www.gallerymodules.com/m/moduleupdates)
Download link - http://www.gallerymodules.com/update/<module_name> (http://www.gallerymodules.com/update/moduleupdates)
Gallery 3.1.x:
Version check - http://www.gallerymodules.com/31m/<module_name> (http://www.gallerymodules.com/31m/moduleupdates)
Download link - http://www.gallerymodules.com/update31/<module_name> (http://www.gallerymodules.com/update31/moduleupdates)
--
For Gallery 3 modules and themes, visit GalleryModules.com.
For PHPNuke, phpBB2, and phpBB3 integration help, visit NukedGallery.net.