I think the version numbering fight re: whole number vs decimal has been fought, and the core devs are sticking to their guns on this one. I agree that there needs to be consistency re: module.info, codex, forums, etc...otherwise, it's all worthless.
--
For Gallery 3 modules and themes, visit GalleryModules.com.
For PHPNuke, phpBB2, and phpBB3 integration help, visit NukedGallery.net.
brentil
Joined: 2007-04-11
Posts: 124
Posted: Mon, 2011-08-01 17:34
Yeah, it's why I started jumping version numbers for this module by whole numbers no matter how small an update. That way across all version locations it just resolves the same.
The whole versioning thing got out of control in Gallery 2. The final release was version 2.3.1, and the core module was 1.3.0.1. We were trying to ram a lot of context into a structured form and then we'd come across a case that would require more structure than we had and we'd have to do something ridiculous to make it work. Essentially on the versioning front, we really just need to know two things:
1) What version do I have?
2) Do I have the latest version?
For G3 I went with a single number for each module, which answers both questions. But there's an additional lurking situation where you have to patch an older release (like if there's a security patch and we want to update old versions while releasing a new version). So that means that we need the option to say "You're on version 2, and the latest is version 10, but here's version 2.1 with a patch." So while we prefer integers, it didn't make sense to lock it down to integers. In this case I went with what was easy, which was to just say "stick what you want here" but be consistent for the core modules.
IMO, the whole numbers thing works just fine. I have no problem with having the gallery module be at version 49. But I'm happy to entertain any ideas you guys have about improving the situation.
---
Problems? Check gallery3/var/logs file a bug/feature ticket | upgrade to the latest code! | hacking G3? join us on IRC!
brentil
Joined: 2007-04-11
Posts: 124
Posted: Mon, 2011-08-01 19:09
In terms of the Gallery core, gallery core modules, and gallery contrib modules it works perfectly fine since it's easy for us to get to the module.info files to validate version numbers. Where it breaks down for us is module developers who don't put their code into the gallery contrib and instead place their versions into either the Gallery forum as attached zip files or host them on their own websites.
dmolavi is pulling the version data from the Codex to put into his system at GalleryModules.com so he can check that information to see if there's been an update (which still relies on that data being updated by a developer). That's when we run into the issue of their decimal based version not being comparable to the data stored in the modules.info file installed into a Gallery.
Maybe if the module.info version # was added to the Codex page? Then dmolavi could pull that data and when I check his data the locally stored module.info version will match up with the one he's storing. That seems the least intrusive method in terms of altering Gallery itself.
If they're putting the code up, we can always unpack the zip file, extract the module.info and read it. So I assume that the main problem is that developers don't update the Codex page? We've talked about having a hosting setup so that you can submit a module .zip file and have it Do the Right Thing. That would probably help here, but it's a lot of work-- policing the codex file might be easier.
The Codex page contains a link to the forum post which has an attached zip file, so theoretically it'd be possible to grab the zip file from the forum post, extract it and verify the version number in the codex.. Dari, how hard would that be to do?
Grabbing the file from codex, if the link ends in .zip, and doing the extraction is trivial.
The trick comes into play when it's a link to a forum, or some other CMS that may require some sort of validation (CAPTCHA, etc).
Since I'm already "hosting" the modules from -contrib, in theory, I could do the same for Codex-based modules that don't get uploaded to git. It's trivial to create an upload form that can call code to do the backend processing.
--
For Gallery 3 modules and themes, visit GalleryModules.com.
For PHPNuke, phpBB2, and phpBB3 integration help, visit NukedGallery.net.
floridave
Joined: 2003-12-22
Posts: 27300
Posted: Tue, 2011-08-02 13:07
Serge and I are migrating the modules we have developed to just the codex. I guess I can go through some that are linked to forum posts and move them to the codex. Would that help?
I'm sure that will take some time and then the developer will undoubtedly not update the codex if a new version comes out. The issue comes down to enforcement and we all know developers are stubborn and might not like this extra hoop to go through. Some don't even update the codex even if I create a page for them.
@floridave- It definitely wouldn't hurt, but like you said, the onus is on the developer to maintain it on Codex, which most don't.
I wonder if bharat can make a default template for new posts to this forum stating that if you are a developer with a new (or updated) module, that you should upload it to Codex instead of posting it here.
I'm not averse to hosting the files on GalleryModules directly, but again, it's up to the dev to keep it up to date.
--
For Gallery 3 modules and themes, visit GalleryModules.com.
For PHPNuke, phpBB2, and phpBB3 integration help, visit NukedGallery.net.
chamb1
Joined: 2004-12-27
Posts: 32
Posted: Sat, 2011-08-06 00:17
I recently switch servers (from godaddy to pair.com [go ahead and congratulate me, you folks were right]...but one problem that cropped up is that moduleupdates now reports, "Outbound Status: Offline - GitHub Status: Offline - Execution Time: 1 s" when trying to check for updates.....any ideas on what permission I am missing?
Thanks!
brentil
Joined: 2007-04-11
Posts: 124
Posted: Sun, 2011-08-07 16:26
That's why I created those 2 fields was to detect this type of issue. It typically means your host does not allow outbound http/https calls. You need to find out if your host has a process for allowing this at all, to specific URLs/IPs, etc.
Please note that our PHP configuration disallows the loading of URLs via include(), require(), file(), and similar routines. For example:
<?php include("http://www.example.com/script.php"); ?>
If you wish to take advantage of this feature, you can turn it on for your account by adding the following configuration line to your .htaccess file: php_flag allow_url_fopen on
I haven't used or looked at that module, but I'm betting that's the issue.
____________________________________________
Like Gallery? Like the support? Donate now!
hummmm, sounded like a nice, quick fix, but after adding:
php_flag allow_url_fopen on
to my .htaccess file, nothing changed....
anyone else have other ideas? (i suppose I can just email pair's support....)
nivekiam
Joined: 2002-12-10
Posts: 16504
Posted: Mon, 2011-08-08 01:56
I'd first check phpinfo to verify that the change did take effect: FAQ: How do I create a phpinfo page?
____________________________________________
Like Gallery? Like the support? Donate now!
chamb1
Joined: 2004-12-27
Posts: 32
Posted: Tue, 2011-08-09 00:54
Indeed, in the phpinfo, it is set to "off" for both local and master values. I even tried putting " allow_url_fopen = On " into the local php.ini file. Wonder if I am supposed to be making these edits not in the local .htaccess or php.ini files, but somewhere higher up in the web server?
chamb1
Joined: 2004-12-27
Posts: 32
Posted: Tue, 2011-08-09 02:29
brief update: emailed pair.com support regarding the problem - 30 minutes later, it is solved. they even took care of it. the solution was to put the php.ini file in the fcgi-bin directory allowing fopen....all good now!
again, thanks for the pair.com rec! totally worth it!
I get an "Internal Server Error" after ~1 minute if i click Settings > Module Updates. The v8 is the first Version I installed on Galler3. Any Hint? var/log shows
I get an "Internal Server Error" after ~1 minute if i click Settings > Module Updates. The v8 is the first Version I installed on Galler3. Any Hint? var/log shows
I don't believe that error actually relates to my module. Go look at page 2 of this thread that relates to turning on debug to see the correct error going on. Specifically my post from Fri, 2011-07-29 16:23. If the error is a timeout error then you will need to work with your ISP to increase your execution time. It could possibly be a out of memory issue too.
I had tried to allow more RAM for PHP, but this doesn't worked too
brentil
Joined: 2007-04-11
Posts: 124
Posted: Thu, 2011-09-29 15:16
Have either of you enabled the debug mode to see what the exact error message is? It's typically a timeout issue due to not having enough time to do outbound calls. Increasing the RAM allowed will not speed up the time it takes to connect over the internet to all the resources needed. You have to increase the PHP timeout value for your scripts.
Just installed Module updates, ti seems to work (no visual bugs) but I can't have any modules listed the core and community lines are empty, although a lot of those modules have been downloaded from the core or module page.
On the top of the check button I get this message :
From your information listed above "Outbound Status: Offline - GitHub Status: Offline" this indicates your host is not allowing outbound connections. If you read through the last page and this page there is discussion on how to go about enabling this requirement.
Brentil,
I have pushed an update to this module to utilize the ini file that I generate. It is much less taxing on the GalleryModules server, and the ini file is updated no later than 15 minutes after a commit is pushed to the main gallery3-contrib repository.
Because of this, I would like to propose that the check the module does to the git repo for the contrib modules be eliminated from the code, which would reduce the execution time substantially for people with lots of modules to check.
(BTW, my previous issue in this post is OBE and resolved. Bonehead move on my part)
--
For Gallery 3 modules and themes, visit GalleryModules.com.
For PHPNuke, phpBB2, and phpBB3 integration help, visit NukedGallery.net.
brentil
Joined: 2007-04-11
Posts: 124
Posted: Tue, 2012-04-17 19:10
In giving your code a try I've run into some other issue related to the Gallery core I believe. I just upgraded to 3.0.3 before upgraded to your MU v10 code. It appears it's trying to find the database_info module in the gm_core_array even though it's a non-core module. Because of that it's then throwing an unknown index because it doesn't exist.
You may also want to look to store the ini files inside of the var/modules/moduleupdates folder as I believe that's the correct location for module file storage.
Thanks, I'll have to take a look at this when I get a few free minutes. I have noticed that my non-core module count has skyrocketed, so i'll have to check the logic to see what has changed.
--
For Gallery 3 modules and themes, visit GalleryModules.com.
For PHPNuke, phpBB2, and phpBB3 integration help, visit NukedGallery.net.
I think I see the problem, I have an outdated reference to an old ini file. I'll push the update. If you want to make the change manually, open controllers/admin_moduleupdates.php and find: fwrite($fp2,file_get_contents("http://www.gallerymodules.com/sandbox/core.ini"));
and change it to: fwrite($fp2,file_get_contents("http://www.gallerymodules.com/core.ini"));
--
For Gallery 3 modules and themes, visit GalleryModules.com.
For PHPNuke, phpBB2, and phpBB3 integration help, visit NukedGallery.net.
brentil
Joined: 2007-04-11
Posts: 124
Posted: Thu, 2012-04-19 13:32
It still errors in the same place. It's doing it when making the Core call;
Quote:
list ($core_version, $core_server) = $this->get_remote_module_version($this_module_name, "CORE");
Which does not have the database_info in it so it errors when looking for it. Since it was already found in the GM list it's not going to exist in the other so you need to either not look for it or ignore it. The problem is this block as there is no detection for modules that do not exist in a list. The same happens once you make it past the Core checking and GM checking fails on not being in the Core list.
I'm working on a fix for this now and should have it up shortly.
You also need to be careful with unlink, if the files doesn't exist when you try to unlick it throws an exception. So you'll want to put some validation around it.
I'm going to have a hissy fit, the gallery::VERSION information comes back DIFFERENTLY again now! Now gallery::VERSION = 3.0.3 where before it was gallery::VERSION = 3.0.2 (NAME). So the code now ignores all GCC modules when run under 3.0.3... Luckily with your new system it doesn't matter so we'll just rip it out.
Ok, I've attached the updated code file here. I don't have GIT setup on my new PC so it'll be easier if you merge and upload with your recent changes. This fixes the unlink issue, the version # changes issue, and items not in the correct lists issue.
Later today I'll update the first page of this thread and the codex. Might want to bump the version # to 11 too.
Thanks, I'll merge this in tonight (probably around 9PM Eastern). If you get to it before then, let me know.
--
For Gallery 3 modules and themes, visit GalleryModules.com.
For PHPNuke, phpBB2, and phpBB3 integration help, visit NukedGallery.net.
dmolavi
Joined: 2002-12-05
Posts: 573
Posted: Sun, 2012-04-22 03:07
Merged and submitted pull request.
This doesn't break anything on < 3.0.3 installs, does it?
--
For Gallery 3 modules and themes, visit GalleryModules.com.
For PHPNuke, phpBB2, and phpBB3 integration help, visit NukedGallery.net.
brentil
Joined: 2007-04-11
Posts: 124
Posted: Sun, 2012-04-22 04:39
I tried to take into account the naming schemes for version numbers in 3.0.0/3.0.1/3.0.2 with the changes I made. We may have to revisit it when 3.1.x hits though. If we find people run into issues I'll setup a copy of a previous version and work through it.
There's a v12? Did I do an update and not realize it?
--
For Gallery 3 modules and themes, visit GalleryModules.com.
For PHPNuke, phpBB2, and phpBB3 integration help, visit NukedGallery.net.
brentil
Joined: 2007-04-11
Posts: 124
Posted: Wed, 2012-12-19 20:17
It appears DanielMuller has decided to join us in our quest for updates. Comparing his changes now from our last checked in version so I can write updated release notes and update the codex.
Posts: 573
I think the version numbering fight re: whole number vs decimal has been fought, and the core devs are sticking to their guns on this one. I agree that there needs to be consistency re: module.info, codex, forums, etc...otherwise, it's all worthless.
--
For Gallery 3 modules and themes, visit GalleryModules.com.
For PHPNuke, phpBB2, and phpBB3 integration help, visit NukedGallery.net.
Posts: 124
Yeah, it's why I started jumping version numbers for this module by whole numbers no matter how small an update. That way across all version locations it just resolves the same.
-Brentil
ModuleUpdates module for Gallery 3
Posts: 7994
The whole versioning thing got out of control in Gallery 2. The final release was version 2.3.1, and the core module was 1.3.0.1. We were trying to ram a lot of context into a structured form and then we'd come across a case that would require more structure than we had and we'd have to do something ridiculous to make it work. Essentially on the versioning front, we really just need to know two things:
1) What version do I have?
2) Do I have the latest version?
For G3 I went with a single number for each module, which answers both questions. But there's an additional lurking situation where you have to patch an older release (like if there's a security patch and we want to update old versions while releasing a new version). So that means that we need the option to say "You're on version 2, and the latest is version 10, but here's version 2.1 with a patch." So while we prefer integers, it didn't make sense to lock it down to integers. In this case I went with what was easy, which was to just say "stick what you want here" but be consistent for the core modules.
IMO, the whole numbers thing works just fine. I have no problem with having the gallery module be at version 49. But I'm happy to entertain any ideas you guys have about improving the situation.
---
Problems? Check gallery3/var/logs
file a bug/feature ticket | upgrade to the latest code! | hacking G3? join us on IRC!
Posts: 124
In terms of the Gallery core, gallery core modules, and gallery contrib modules it works perfectly fine since it's easy for us to get to the module.info files to validate version numbers. Where it breaks down for us is module developers who don't put their code into the gallery contrib and instead place their versions into either the Gallery forum as attached zip files or host them on their own websites.
dmolavi is pulling the version data from the Codex to put into his system at GalleryModules.com so he can check that information to see if there's been an update (which still relies on that data being updated by a developer). That's when we run into the issue of their decimal based version not being comparable to the data stored in the modules.info file installed into a Gallery.
Maybe if the module.info version # was added to the Codex page? Then dmolavi could pull that data and when I check his data the locally stored module.info version will match up with the one he's storing. That seems the least intrusive method in terms of altering Gallery itself.
-Brentil
ModuleUpdates module for Gallery 3
Posts: 7994
If they're putting the code up, we can always unpack the zip file, extract the module.info and read it. So I assume that the main problem is that developers don't update the Codex page? We've talked about having a hosting setup so that you can submit a module .zip file and have it Do the Right Thing. That would probably help here, but it's a lot of work-- policing the codex file might be easier.
The Codex page contains a link to the forum post which has an attached zip file, so theoretically it'd be possible to grab the zip file from the forum post, extract it and verify the version number in the codex.. Dari, how hard would that be to do?
---
Problems? Check gallery3/var/logs
file a bug/feature ticket | upgrade to the latest code! | hacking G3? join us on IRC!
Posts: 573
Grabbing the file from codex, if the link ends in .zip, and doing the extraction is trivial.
The trick comes into play when it's a link to a forum, or some other CMS that may require some sort of validation (CAPTCHA, etc).
Since I'm already "hosting" the modules from -contrib, in theory, I could do the same for Codex-based modules that don't get uploaded to git. It's trivial to create an upload form that can call code to do the backend processing.
--
For Gallery 3 modules and themes, visit GalleryModules.com.
For PHPNuke, phpBB2, and phpBB3 integration help, visit NukedGallery.net.
Posts: 27300
Serge and I are migrating the modules we have developed to just the codex. I guess I can go through some that are linked to forum posts and move them to the codex. Would that help?
I'm sure that will take some time and then the developer will undoubtedly not update the codex if a new version comes out. The issue comes down to enforcement and we all know developers are stubborn and might not like this extra hoop to go through. Some don't even update the codex even if I create a page for them.
Dave
_____________________________________________
Blog & G2 || floridave - Gallery Team
Posts: 573
@floridave- It definitely wouldn't hurt, but like you said, the onus is on the developer to maintain it on Codex, which most don't.
I wonder if bharat can make a default template for new posts to this forum stating that if you are a developer with a new (or updated) module, that you should upload it to Codex instead of posting it here.
I'm not averse to hosting the files on GalleryModules directly, but again, it's up to the dev to keep it up to date.
--
For Gallery 3 modules and themes, visit GalleryModules.com.
For PHPNuke, phpBB2, and phpBB3 integration help, visit NukedGallery.net.
Posts: 32
I recently switch servers (from godaddy to pair.com [go ahead and congratulate me, you folks were right]...but one problem that cropped up is that moduleupdates now reports, "Outbound Status: Offline - GitHub Status: Offline - Execution Time: 1 s" when trying to check for updates.....any ideas on what permission I am missing?
Thanks!
Posts: 124
That's why I created those 2 fields was to detect this type of issue. It typically means your host does not allow outbound http/https calls. You need to find out if your host has a process for allowing this at all, to specific URLs/IPs, etc.
-Brentil
ModuleUpdates module for Gallery 3
Posts: 16504
Pair disables allow_url_fopen by default, that's probably the issue:
http://www.pair.com/support/knowledge_base/authoring_development/using_php.html
I haven't used or looked at that module, but I'm betting that's the issue.
____________________________________________
Like Gallery? Like the support? Donate now!
Posts: 124
My module does use file() so that would do it.
-Brentil
ModuleUpdates module for Gallery 3
Posts: 32
hummmm, sounded like a nice, quick fix, but after adding:
php_flag allow_url_fopen on
to my .htaccess file, nothing changed....
anyone else have other ideas? (i suppose I can just email pair's support....)
Posts: 16504
I'd first check phpinfo to verify that the change did take effect:
FAQ: How do I create a phpinfo page?
____________________________________________
Like Gallery? Like the support? Donate now!
Posts: 32
Indeed, in the phpinfo, it is set to "off" for both local and master values. I even tried putting " allow_url_fopen = On " into the local php.ini file. Wonder if I am supposed to be making these edits not in the local .htaccess or php.ini files, but somewhere higher up in the web server?
Posts: 32
brief update: emailed pair.com support regarding the problem - 30 minutes later, it is solved. they even took care of it. the solution was to put the php.ini file in the fcgi-bin directory allowing fopen....all good now!
again, thanks for the pair.com rec! totally worth it!
Posts: 27300
Cool!
Dave
_____________________________________________
Blog & G2 || floridave - Gallery Team
Posts: 124
Great news! I'll add a section to the codex for my module about checking for this if the items fail.
-Brentil
ModuleUpdates module for Gallery 3
Posts: 21
I get an "Internal Server Error" after ~1 minute if i click Settings > Module Updates. The v8 is the first Version I installed on Galler3. Any Hint? var/log shows
2011-08-22 01:57:29 +02:00 --- error: ReflectionException [ -1 ]: Class _Controller does not exist <myhome>/modules/gallery/helpers/gallery.php [ 34 ] #0 <myhome>/modules/gallery/helpers/gallery.php(34): ReflectionClass->__construct('_Controller') #1 <myhome>/system/core/Event.php(208): gallery_Core::maintenance_mode(NULL) #2 <myhome>/system/libraries/Router.php(160): Event_Core::run(Array, Array) #3 <myhome>/system/core/Event.php(208): Router_Core::setup('system.post_rou...') #4 <myhome>/application/Bootstrap.php(61): Event_Core::run(NULL) #5 <myhome>/index.php(102): require('<myhome>...') #6 {main}Posts: 124
I don't believe that error actually relates to my module. Go look at page 2 of this thread that relates to turning on debug to see the correct error going on. Specifically my post from Fri, 2011-07-29 16:23. If the error is a timeout error then you will need to work with your ISP to increase your execution time. It could possibly be a out of memory issue too.
-Brentil
ModuleUpdates module for Gallery 3
Posts: 428
Installed Module Updates, but when I attempt to go to Settings > Module Updates, I am also greeted with a 500 Internal Server Error
SoosKriszta
Csillamvilag.com
Bodypainting, Facepainting, Glitter, Henna
HennaLap.com
Posts: 21
I had tried to allow more RAM for PHP, but this doesn't worked too
Posts: 124
Have either of you enabled the debug mode to see what the exact error message is? It's typically a timeout issue due to not having enough time to do outbound calls. Increasing the RAM allowed will not speed up the time it takes to connect over the internet to all the resources needed. You have to increase the PHP timeout value for your scripts.
-Brentil
ModuleUpdates module for Gallery 3
Posts: 253
Hello
Just installed Module updates, ti seems to work (no visual bugs) but I can't have any modules listed the core and community lines are empty, although a lot of those modules have been downloaded from the core or module page.
On the top of the check button I get this message :
Outbound Status: Offline - GitHub Status: Offline - Execution Time: 1 s
I have the 3.1 installed from the gallerymodules page
Is this module working for 3.2 ?
Thank you in advance for any answer
------
Gallery 3 URL = http://www.coquille.org/gallery3/
Gallery version = 3.0.2 (Coollanta)
Operating system: Linux 2.6.18-194.32.1.el5
Apache: Apache/2.2.3 (Red Hat)
PHP: 5.2.6
MySQL: 5.0.77
Server load: 0.33 0.48 0.49
Graphics toolkit: gd
Posts: 124
From your information listed above "Outbound Status: Offline - GitHub Status: Offline" this indicates your host is not allowing outbound connections. If you read through the last page and this page there is discussion on how to go about enabling this requirement.
-Brentil
ModuleUpdates module for Gallery 3
Posts: 573
Brentil,
I have pushed an update to this module to utilize the ini file that I generate. It is much less taxing on the GalleryModules server, and the ini file is updated no later than 15 minutes after a commit is pushed to the main gallery3-contrib repository.
Because of this, I would like to propose that the check the module does to the git repo for the contrib modules be eliminated from the code, which would reduce the execution time substantially for people with lots of modules to check.
(BTW, my previous issue in this post is OBE and resolved. Bonehead move on my part)
--
For Gallery 3 modules and themes, visit GalleryModules.com.
For PHPNuke, phpBB2, and phpBB3 integration help, visit NukedGallery.net.
Posts: 124
In giving your code a try I've run into some other issue related to the Gallery core I believe. I just upgraded to 3.0.3 before upgraded to your MU v10 code. It appears it's trying to find the database_info module in the gm_core_array even though it's a non-core module. Because of that it's then throwing an unknown index because it doesn't exist.
-Brentil
ModuleUpdates module for Gallery 3
Posts: 124
You may also want to look to store the ini files inside of the var/modules/moduleupdates folder as I believe that's the correct location for module file storage.
-Brentil
ModuleUpdates module for Gallery 3
Posts: 573
Thanks, I'll have to take a look at this when I get a few free minutes. I have noticed that my non-core module count has skyrocketed, so i'll have to check the logic to see what has changed.
--
For Gallery 3 modules and themes, visit GalleryModules.com.
For PHPNuke, phpBB2, and phpBB3 integration help, visit NukedGallery.net.
Posts: 573
I see database_info in http://www.gallerymodules.com/gallerymodules.ini , so I'm not sure why it's erroring out on you, but...
I think I see the problem, I have an outdated reference to an old ini file. I'll push the update. If you want to make the change manually, open controllers/admin_moduleupdates.php and find:
fwrite($fp2,file_get_contents("http://www.gallerymodules.com/sandbox/core.ini"));and change it to:
fwrite($fp2,file_get_contents("http://www.gallerymodules.com/core.ini"));--
For Gallery 3 modules and themes, visit GalleryModules.com.
For PHPNuke, phpBB2, and phpBB3 integration help, visit NukedGallery.net.
Posts: 124
It still errors in the same place. It's doing it when making the Core call;
Which does not have the database_info in it so it errors when looking for it. Since it was already found in the GM list it's not going to exist in the other so you need to either not look for it or ignore it. The problem is this block as there is no detection for modules that do not exist in a list. The same happens once you make it past the Core checking and GM checking fails on not being in the Core list.
I'm working on a fix for this now and should have it up shortly.
You also need to be careful with unlink, if the files doesn't exist when you try to unlick it throws an exception. So you'll want to put some validation around it.
-Brentil
ModuleUpdates module for Gallery 3
Posts: 124
I'm going to have a hissy fit, the gallery::VERSION information comes back DIFFERENTLY again now! Now gallery::VERSION = 3.0.3 where before it was gallery::VERSION = 3.0.2 (NAME). So the code now ignores all GCC modules when run under 3.0.3... Luckily with your new system it doesn't matter so we'll just rip it out.
Ok, I've attached the updated code file here. I don't have GIT setup on my new PC so it'll be easier if you merge and upload with your recent changes. This fixes the unlink issue, the version # changes issue, and items not in the correct lists issue.
Later today I'll update the first page of this thread and the codex. Might want to bump the version # to 11 too.
-Brentil
ModuleUpdates module for Gallery 3
Posts: 573
Thanks, I'll merge this in tonight (probably around 9PM Eastern). If you get to it before then, let me know.
--
For Gallery 3 modules and themes, visit GalleryModules.com.
For PHPNuke, phpBB2, and phpBB3 integration help, visit NukedGallery.net.
Posts: 573
Merged and submitted pull request.
This doesn't break anything on < 3.0.3 installs, does it?
--
For Gallery 3 modules and themes, visit GalleryModules.com.
For PHPNuke, phpBB2, and phpBB3 integration help, visit NukedGallery.net.
Posts: 124
I tried to take into account the naming schemes for version numbers in 3.0.0/3.0.1/3.0.2 with the changes I made. We may have to revisit it when 3.1.x hits though. If we find people run into issues I'll setup a copy of a previous version and work through it.
-Brentil
ModuleUpdates module for Gallery 3
Posts: 124
I've upgraded my Gallery to 3.0.4 and the latest v11 ModuleUpdates appears to be working as expected.
-Brentil
ModuleUpdates module for Gallery 3
Posts: 124
dmolavi, what's new in v12?
-Brentil
ModuleUpdates module for Gallery 3
Posts: 573
There's a v12? Did I do an update and not realize it?
--
For Gallery 3 modules and themes, visit GalleryModules.com.
For PHPNuke, phpBB2, and phpBB3 integration help, visit NukedGallery.net.
Posts: 124
It appears DanielMuller has decided to join us in our quest for updates. Comparing his changes now from our last checked in version so I can write updated release notes and update the codex.
https://github.com/DanielMuller
-Brentil
ModuleUpdates module for Gallery 3
Posts: 124
-Brentil
ModuleUpdates module for Gallery 3
Posts: 124
I have tested ModuleUpdates 12 against Gallery 3.0.5 and everything works as expected.
-Brentil
ModuleUpdates module for Gallery 3