From websitemaster at cogeco.net Sun May 1 16:35:30 2011 From: websitemaster at cogeco.net (Tom) Date: Sun, 1 May 2011 16:35:30 -0400 Subject: [geeklog-devel] Geeklog 1.8.0 b3/rc1 Message-ID: <000001cc083f$50412430$f0c36c90$@cogeco.net> When should we release our next version? I haven't seen too many bug reports coming in the last few days. It has only been a week since b2 was released so should we wait another week or should it be longer? Tom -----Original Message----- From: geeklog-devel-bounces at lists.geeklog.net [mailto:geeklog-devel-bounces at lists.geeklog.net] On Behalf Of Dirk Haun Sent: April-25-11 11:59 AM To: Geeklog Development Subject: Re: [geeklog-devel] OAuth and sessions (was: Geeklog 1.8.0) Tom wrote: > I doubt if I can spend much more time on this today. I hope to figure > out the problem tomorrow. No problem. Good to hear you have a handle on it. I'll go ahead and publish b2 later today and we can then roll the fix into b3/rc1. bye, Dirk _______________________________________________ geeklog-devel mailing list geeklog-devel at lists.geeklog.net http://eight.pairlist.net/mailman/listinfo/geeklog-devel From dirk at haun-online.de Sun May 1 16:53:36 2011 From: dirk at haun-online.de (Dirk Haun) Date: Sun, 1 May 2011 22:53:36 +0200 Subject: [geeklog-devel] Geeklog 1.8.0 b3/rc1 In-Reply-To: <000001cc083f$50412430$f0c36c90$@cogeco.net> References: <000001cc083f$50412430$f0c36c90$@cogeco.net> Message-ID: <58076F5D-7438-430A-8A12-9059ACE1BE7D@haun-online.de> Tom wrote: > When should we release our next version? I haven't seen too many bug reports > coming in the last few days. Soon, I'd say. I did actually start updating geeklog.net today, but only managed to apply the fixes for the OAuth/OpenID login issue. And I think the next version should be rc1. bye, Dirk From websitemaster at cogeco.net Wed May 4 08:29:59 2011 From: websitemaster at cogeco.net (Tom) Date: Wed, 4 May 2011 08:29:59 -0400 Subject: [geeklog-devel] OAuth and Google In-Reply-To: <1303742980.2307.16.camel@roccivic-pc> References: <025301cbfe97$1ebe35d0$5c3aa170$@cogeco.net> <529D3909-FF2F-44A5-93BF-551193FC5C61@haun-online.de> <00a401cc0350$25185380$6f48fa80$@cogeco.net> <69366196-D7D9-4FA7-B4BF-E0254D64E47A@haun-online.de> <1303742980.2307.16.camel@roccivic-pc> Message-ID: <017901cc0a56$fbad0ff0$f3072fd0$@cogeco.net> It would be nice but it looks like Google is experimenting with OAuth 2. The Pear libraries we used are based on the 1.0a specs. The OAuth 2.0 spec is still being ironed out I believe. Once everything gets finalized it would be great to offer a Google OAuth authentication option. Tom -----Original Message----- From: geeklog-devel-bounces at lists.geeklog.net [mailto:geeklog-devel-bounces at lists.geeklog.net] On Behalf Of Rouslan Placella Sent: April-25-11 10:50 AM To: Geeklog Development Subject: [geeklog-devel] OAuth and Google Looks like Google is also an OAuth provider: http://code.google.com/intl/en/apis/accounts/docs/OAuth2.html I wonder if we can support them, too. Rouslan _______________________________________________ geeklog-devel mailing list geeklog-devel at lists.geeklog.net http://eight.pairlist.net/mailman/listinfo/geeklog-devel From dirk at haun-online.de Sat May 7 18:21:54 2011 From: dirk at haun-online.de (Dirk Haun) Date: Sun, 8 May 2011 00:21:54 +0200 Subject: [geeklog-devel] Feature freeze In-Reply-To: <57C39EB5-B1D6-402F-A443-80056A25B04C@haun-online.de> References: <57C39EB5-B1D6-402F-A443-80056A25B04C@haun-online.de> Message-ID: > The nightly tarball is now created twice per day. Would have preferred an even higher frequency, but the script to create it isn't so great and puts a lot of load on the server for a few minutes. Have to review that - maybe let Jenkins do it. Success: The "nightly" tarball is now created every hour (assuming there were changes) via Jenkins. http://project.geeklog.net:8080/job/geeklog-nightly/ You can download the tarball from that page or from the (unchanged) old location: http://project.geeklog.net/nightly/geeklog-nightly.tar.gz bye, Dirk From dirk at haun-online.de Sun May 8 14:07:39 2011 From: dirk at haun-online.de (Dirk Haun) Date: Sun, 8 May 2011 20:07:39 +0200 Subject: [geeklog-devel] More automation (was: Feature freeze) In-Reply-To: References: <57C39EB5-B1D6-402F-A443-80056A25B04C@haun-online.de> Message-ID: <7C5262C3-AC61-448B-8252-2F7E5B4D2FD3@haun-online.de> > Success: The "nightly" tarball is now created every hour (assuming there were changes) via Jenkins. And to further automate things, the release tarball for 1.8.0rc1 was now also created automatically by a Jenkins job. http://project.geeklog.net:8080/job/geeklog-release/ The idea is to allow others to roll out a Geeklog release if necessary. The new Jenkins job checks for any new tags that start with "geeklog_". So simply tagging a version, e.g. hg tag -r 8272 geeklog_1_8_0rc1 triggers the creation of a tarball geeklog-1.8.0rc1.tar.gz, which then also ends up in a predefined directory on www.geeklog.net. The next step would be to add that file to the submission queue of the File Management plugin automatically so that it doesn't require any access to the file system on the server. Maybe in time for the official 1.8.0 release ... Okay, so there's some fine tuning left to be done. Part of the release tarball is the changed-files text file that lists the files that changed since the previous version. Figuring out what the "previous version" actually is would probably fail right now if we had to do, say, a 1.7.2sr1 tomorrow. It also assumes that the tarball for the previous version is available (which currently isn't). I'll work on those. Anyway, I hope the general idea is clear? Feedback welcome. bye, Dirk From websitemaster at cogeco.net Sun May 8 14:38:07 2011 From: websitemaster at cogeco.net (Tom) Date: Sun, 8 May 2011 14:38:07 -0400 Subject: [geeklog-devel] More automation (was: Feature freeze) In-Reply-To: <7C5262C3-AC61-448B-8252-2F7E5B4D2FD3@haun-online.de> References: <57C39EB5-B1D6-402F-A443-80056A25B04C@haun-online.de> <7C5262C3-AC61-448B-8252-2F7E5B4D2FD3@haun-online.de> Message-ID: <001701cc0daf$12f97d00$38ec7700$@cogeco.net> Thanks for this Dirk. After the release of 1.8.0 I was going to ask if you could write down the process of releasing a version of Geeklog. Everything from what one needs to consider before releasing a new version to the actual process and what should be done in the repository, etc... Looks like you are a step ahead of me :-) Tom -----Original Message----- From: geeklog-devel-bounces at lists.geeklog.net [mailto:geeklog-devel-bounces at lists.geeklog.net] On Behalf Of Dirk Haun Sent: May-08-11 2:08 PM To: Geeklog Development Subject: [geeklog-devel] More automation (was: Feature freeze) > Success: The "nightly" tarball is now created every hour (assuming there were changes) via Jenkins. And to further automate things, the release tarball for 1.8.0rc1 was now also created automatically by a Jenkins job. http://project.geeklog.net:8080/job/geeklog-release/ The idea is to allow others to roll out a Geeklog release if necessary. The new Jenkins job checks for any new tags that start with "geeklog_". So simply tagging a version, e.g. hg tag -r 8272 geeklog_1_8_0rc1 triggers the creation of a tarball geeklog-1.8.0rc1.tar.gz, which then also ends up in a predefined directory on www.geeklog.net. The next step would be to add that file to the submission queue of the File Management plugin automatically so that it doesn't require any access to the file system on the server. Maybe in time for the official 1.8.0 release ... Okay, so there's some fine tuning left to be done. Part of the release tarball is the changed-files text file that lists the files that changed since the previous version. Figuring out what the "previous version" actually is would probably fail right now if we had to do, say, a 1.7.2sr1 tomorrow. It also assumes that the tarball for the previous version is available (which currently isn't). I'll work on those. Anyway, I hope the general idea is clear? Feedback welcome. bye, Dirk _______________________________________________ geeklog-devel mailing list geeklog-devel at lists.geeklog.net http://eight.pairlist.net/mailman/listinfo/geeklog-devel From dirk at haun-online.de Sun May 8 14:54:03 2011 From: dirk at haun-online.de (Dirk Haun) Date: Sun, 8 May 2011 20:54:03 +0200 Subject: [geeklog-devel] More automation (was: Feature freeze) In-Reply-To: <001701cc0daf$12f97d00$38ec7700$@cogeco.net> References: <57C39EB5-B1D6-402F-A443-80056A25B04C@haun-online.de> <7C5262C3-AC61-448B-8252-2F7E5B4D2FD3@haun-online.de> <001701cc0daf$12f97d00$38ec7700$@cogeco.net> Message-ID: <2AEA13F7-C41C-46F2-94E4-2093B5875F6F@haun-online.de> Tom wrote: > After the release of 1.8.0 I was going to ask if you could write down the > process of releasing a version of Geeklog. Everything from what one needs to > consider before releasing a new version to the actual process and what > should be done in the repository, etc... There's http://wiki.geeklog.net/index.php/Geeklog_Release_Procedures > Looks like you are a step ahead of me :-) I'm doing stuff like that at work right now (also with Jenkins, but in a "slightly" more complex[1] setup). So it only makes sense to try and apply some of the things I learned[2] there to Geeklog. bye, Dirk [1] http://www.flickr.com/photos/dhaun/5640386266/ [2] http://www.slideshare.net/dhaun/continuous-integration-does-it-scale From dirk at haun-online.de Sat May 14 18:45:52 2011 From: dirk at haun-online.de (Dirk Haun) Date: Sun, 15 May 2011 00:45:52 +0200 Subject: [geeklog-devel] More automation (was: Feature freeze) In-Reply-To: <7C5262C3-AC61-448B-8252-2F7E5B4D2FD3@haun-online.de> References: <57C39EB5-B1D6-402F-A443-80056A25B04C@haun-online.de> <7C5262C3-AC61-448B-8252-2F7E5B4D2FD3@haun-online.de> Message-ID: > The next step would be to add that file to the submission queue of the File Management plugin automatically so that it doesn't require any access to the file system on the server. Maybe in time for the official 1.8.0 release ... This should work now. I've also fixed the problem with tagging older releases (or rather, adding new tags for older branches). I've only tested parts of everything, though, so I'm going to do some tests with fake tags to see if the whole process works as expected. Some info on the wiki: http://wiki.geeklog.net/index.php/Automatic_Tarball_Creation Are there any issues left with 1.8.0? Do we need an rc2 or should we go straight to the final release? bye, Dirk From rouslan at placella.com Sat May 14 18:55:12 2011 From: rouslan at placella.com (Rouslan Placella) Date: Sat, 14 May 2011 23:55:12 +0100 Subject: [geeklog-devel] More automation (was: Feature freeze) In-Reply-To: References: <57C39EB5-B1D6-402F-A443-80056A25B04C@haun-online.de> <7C5262C3-AC61-448B-8252-2F7E5B4D2FD3@haun-online.de> Message-ID: <1305413712.2202.10.camel@roccivic-pc> On Sun, 2011-05-15 at 00:45 +0200, Dirk Haun wrote: > Are there any issues left with 1.8.0? Do we need an rc2 or should we go straight to the final release? > > bye, Dirk I'm yet to reproduce the bug that was recently reported in PgSQL (I'll try to get onto it tomorrow). Other than that I don't see any showstoppers, so IMO we don't need an rc2. Rouslan From websitemaster at cogeco.net Sat May 14 20:13:33 2011 From: websitemaster at cogeco.net (Tom) Date: Sat, 14 May 2011 20:13:33 -0400 Subject: [geeklog-devel] More automation (was: Feature freeze) In-Reply-To: References: <57C39EB5-B1D6-402F-A443-80056A25B04C@haun-online.de> <7C5262C3-AC61-448B-8252-2F7E5B4D2FD3@haun-online.de> Message-ID: <016001cc1294$ed7fb090$c87f11b0$@cogeco.net> I would think a final release. -----Original Message----- From: geeklog-devel-bounces at lists.geeklog.net [mailto:geeklog-devel-bounces at lists.geeklog.net] On Behalf Of Dirk Haun Sent: May-14-11 6:46 PM To: Geeklog Development Subject: Re: [geeklog-devel] More automation (was: Feature freeze) > The next step would be to add that file to the submission queue of the File Management plugin automatically so that it doesn't require any access to the file system on the server. Maybe in time for the official 1.8.0 release ... This should work now. I've also fixed the problem with tagging older releases (or rather, adding new tags for older branches). I've only tested parts of everything, though, so I'm going to do some tests with fake tags to see if the whole process works as expected. Some info on the wiki: http://wiki.geeklog.net/index.php/Automatic_Tarball_Creation Are there any issues left with 1.8.0? Do we need an rc2 or should we go straight to the final release? bye, Dirk _______________________________________________ geeklog-devel mailing list geeklog-devel at lists.geeklog.net http://eight.pairlist.net/mailman/listinfo/geeklog-devel From komma at ivywe.co.jp Sat May 14 21:15:51 2011 From: komma at ivywe.co.jp (=?ISO-2022-JP?B?GyRCOiM2cEUvO1IbKEIgR2Vla2xvZyBJdnlXZQ==?=) Date: Sun, 15 May 2011 10:15:51 +0900 Subject: [geeklog-devel] More automation (was: Feature freeze) In-Reply-To: <1305413712.2202.10.camel@roccivic-pc> References: <57C39EB5-B1D6-402F-A443-80056A25B04C@haun-online.de> <7C5262C3-AC61-448B-8252-2F7E5B4D2FD3@haun-online.de> <1305413712.2202.10.camel@roccivic-pc> Message-ID: >> Are there any issues left with 1.8.0? Do we need an rc2 or should we go straight to the final release? >> >> bye, Dirk plugin update works well? I can't update any plugins. Ivy From dirk at haun-online.de Sun May 15 02:55:21 2011 From: dirk at haun-online.de (Dirk Haun) Date: Sun, 15 May 2011 08:55:21 +0200 Subject: [geeklog-devel] More automation (was: Feature freeze) In-Reply-To: References: <57C39EB5-B1D6-402F-A443-80056A25B04C@haun-online.de> <7C5262C3-AC61-448B-8252-2F7E5B4D2FD3@haun-online.de> <1305413712.2202.10.camel@roccivic-pc> Message-ID: <65C823BC-6238-4812-8D9C-4E5D7B2AA0F0@haun-online.de> ???? Geeklog IvyWe wrote: > plugin update works well? > I can't update any plugins. Works for me. Can you provide more details, please? What are you doing? What happens? bye, Dirk From dirk at haun-online.de Sun May 15 07:17:40 2011 From: dirk at haun-online.de (Dirk Haun) Date: Sun, 15 May 2011 13:17:40 +0200 Subject: [geeklog-devel] More automation (was: Feature freeze) In-Reply-To: References: <57C39EB5-B1D6-402F-A443-80056A25B04C@haun-online.de> <7C5262C3-AC61-448B-8252-2F7E5B4D2FD3@haun-online.de> Message-ID: > I'm going to do some tests with fake tags to see if the whole process works as expected. It didn't but I've fixed the remaining issues now. I've also tested that you can move tags (hg tag -f) in case you accidentally tagged the wrong revision. And removing a tag (like the fake geeklog_1_8_0rc2) also works as expected, i.e. it doesn't do anything :) So this part of the release process is ready now ... bye, Dirk From rouslan at placella.com Sun May 15 07:21:35 2011 From: rouslan at placella.com (Rouslan Placella) Date: Sun, 15 May 2011 12:21:35 +0100 Subject: [geeklog-devel] More automation (was: Feature freeze) In-Reply-To: <65C823BC-6238-4812-8D9C-4E5D7B2AA0F0@haun-online.de> References: <57C39EB5-B1D6-402F-A443-80056A25B04C@haun-online.de> <7C5262C3-AC61-448B-8252-2F7E5B4D2FD3@haun-online.de> <1305413712.2202.10.camel@roccivic-pc> <65C823BC-6238-4812-8D9C-4E5D7B2AA0F0@haun-online.de> Message-ID: <1305458495.2221.15.camel@roccivic-pc> I have issues with updating plugins as well. For example, with my "search word ranking" plugin, if you do the following: * install a plugin v1.0.0 * disable this plugin * upload version 1.1.0 * enable plugin back * "update" icon shows up * click on update icon * upgrade works perfect However, if you do this: * install plugin v1.0.0 * upload version 1.1.0 * autoupdate takes place * Geeklog reports that version 1.1.0 is installed, but it's not true. plugin_upgrade_foobar() was never called. So the files are up to date, but the database as well as the configuration settings are from version 1.0.0 In both of the above cases I'm talking about uploading a tarball through the form on admin/plugins.php, not FTP or anything like that. Files needed to reproduce (note: there are only 4 config settings in version 1.0.0 and 8 config settings in 1.1.0): http://www.placella.com/gl/searchrank_1.0.0_1.6.0.tar.gz http://www.placella.com/gl/searchrank_1.1.0hg_1.6.0.tar.gz I couldn't trace the problem to anywhere, so it might be in my code, though I doubt it... Rouslan On Sun, 2011-05-15 at 08:55 +0200, Dirk Haun wrote: > ???? Geeklog IvyWe wrote: > > > plugin update works well? > > I can't update any plugins. > > Works for me. > > Can you provide more details, please? What are you doing? What happens? > > bye, Dirk > > _______________________________________________ > geeklog-devel mailing list > geeklog-devel at lists.geeklog.net > http://eight.pairlist.net/mailman/listinfo/geeklog-devel From websitemaster at cogeco.net Sun May 15 10:55:32 2011 From: websitemaster at cogeco.net (Tom) Date: Sun, 15 May 2011 10:55:32 -0400 Subject: [geeklog-devel] More automation (was: Feature freeze) In-Reply-To: <1305458495.2221.15.camel@roccivic-pc> References: <57C39EB5-B1D6-402F-A443-80056A25B04C@haun-online.de> <7C5262C3-AC61-448B-8252-2F7E5B4D2FD3@haun-online.de> <1305413712.2202.10.camel@roccivic-pc> <65C823BC-6238-4812-8D9C-4E5D7B2AA0F0@haun-online.de> <1305458495.2221.15.camel@roccivic-pc> Message-ID: <018201cc1310$23be99c0$6b3bcd40$@cogeco.net> Hmm... my development server is having problems uncompressing files at the moment so I couldn't test the upload and auto upgrade procedure out right but I did a quick follow through with the code in Geeklog and your plugin and it looks like everything should work and the plugin upgrade should happen when PLG_upgrade gets called. (obviously it doesn't though) Ivy, is Rouslan's problem the same as yours? Tom -----Original Message----- From: geeklog-devel-bounces at lists.geeklog.net [mailto:geeklog-devel-bounces at lists.geeklog.net] On Behalf Of Rouslan Placella Sent: May-15-11 7:22 AM To: Geeklog Development Subject: Re: [geeklog-devel] More automation (was: Feature freeze) I have issues with updating plugins as well. For example, with my "search word ranking" plugin, if you do the following: * install a plugin v1.0.0 * disable this plugin * upload version 1.1.0 * enable plugin back * "update" icon shows up * click on update icon * upgrade works perfect However, if you do this: * install plugin v1.0.0 * upload version 1.1.0 * autoupdate takes place * Geeklog reports that version 1.1.0 is installed, but it's not true. plugin_upgrade_foobar() was never called. So the files are up to date, but the database as well as the configuration settings are from version 1.0.0 In both of the above cases I'm talking about uploading a tarball through the form on admin/plugins.php, not FTP or anything like that. Files needed to reproduce (note: there are only 4 config settings in version 1.0.0 and 8 config settings in 1.1.0): http://www.placella.com/gl/searchrank_1.0.0_1.6.0.tar.gz http://www.placella.com/gl/searchrank_1.1.0hg_1.6.0.tar.gz I couldn't trace the problem to anywhere, so it might be in my code, though I doubt it... Rouslan On Sun, 2011-05-15 at 08:55 +0200, Dirk Haun wrote: > ???? Geeklog IvyWe wrote: > > > plugin update works well? > > I can't update any plugins. > > Works for me. > > Can you provide more details, please? What are you doing? What happens? > > bye, Dirk > > _______________________________________________ > geeklog-devel mailing list > geeklog-devel at lists.geeklog.net > http://eight.pairlist.net/mailman/listinfo/geeklog-devel _______________________________________________ geeklog-devel mailing list geeklog-devel at lists.geeklog.net http://eight.pairlist.net/mailman/listinfo/geeklog-devel From komma at ivywe.co.jp Sun May 15 11:25:01 2011 From: komma at ivywe.co.jp (=?ISO-2022-JP?B?GyRCOiM2cEUvO1IbKEIgR2Vla2xvZyBJdnlXZQ==?=) Date: Mon, 16 May 2011 00:25:01 +0900 Subject: [geeklog-devel] More automation (was: Feature freeze) In-Reply-To: <018201cc1310$23be99c0$6b3bcd40$@cogeco.net> References: <57C39EB5-B1D6-402F-A443-80056A25B04C@haun-online.de> <7C5262C3-AC61-448B-8252-2F7E5B4D2FD3@haun-online.de> <1305413712.2202.10.camel@roccivic-pc> <65C823BC-6238-4812-8D9C-4E5D7B2AA0F0@haun-online.de> <1305458495.2221.15.camel@roccivic-pc> <018201cc1310$23be99c0$6b3bcd40$@cogeco.net> Message-ID: Tom, My Geeklog 1.8.0 test site, I can't update any plugins. Windows 7 - IE9 FF Chrome Mac - Safari Chrome By any browser, I can't update plugins. But Dirk can update plugins on my test site. 2011/5/15 Tom : > Hmm... my development server is having problems uncompressing files at the moment so I couldn't test the upload and auto upgrade procedure out right but I did a quick follow through with the code in Geeklog and your plugin and it looks like everything should work and the plugin upgrade should happen when PLG_upgrade gets called. (obviously it doesn't though) > > Ivy, is Rouslan's problem the same as yours? > > Tom > > -----Original Message----- > From: geeklog-devel-bounces at lists.geeklog.net [mailto:geeklog-devel-bounces at lists.geeklog.net] On Behalf Of Rouslan Placella > Sent: May-15-11 7:22 AM > To: Geeklog Development > Subject: Re: [geeklog-devel] More automation (was: Feature freeze) > > I have issues with updating plugins as well. For example, with my "search word ranking" plugin, if you do the following: > > * install a plugin v1.0.0 > * disable this plugin > * upload version 1.1.0 > * enable plugin back > * "update" icon shows up > * click on update icon > * upgrade works perfect > > However, if you do this: > > * install plugin v1.0.0 > * upload version 1.1.0 > * autoupdate takes place > * Geeklog reports that version 1.1.0 is installed, but it's not true. > plugin_upgrade_foobar() was never called. So the files are up to date, but the database as well as the configuration settings are from version > 1.0.0 > > In both of the above cases I'm talking about uploading a tarball through the form on admin/plugins.php, not FTP or anything like that. > > Files needed to reproduce (note: there are only 4 config settings in version 1.0.0 and 8 config settings in 1.1.0): > > http://www.placella.com/gl/searchrank_1.0.0_1.6.0.tar.gz > http://www.placella.com/gl/searchrank_1.1.0hg_1.6.0.tar.gz > > I couldn't trace the problem to anywhere, so it might be in my code, though I doubt it... > > Rouslan > > > On Sun, 2011-05-15 at 08:55 +0200, Dirk Haun wrote: >> ???? Geeklog IvyWe wrote: >> >> > plugin update works well? >> > I can't update any plugins. >> >> Works for me. >> >> Can you provide more details, please? What are you doing? What happens? >> >> bye, Dirk >> From rouslan at placella.com Sun May 15 11:33:11 2011 From: rouslan at placella.com (Rouslan Placella) Date: Sun, 15 May 2011 16:33:11 +0100 Subject: [geeklog-devel] More automation (was: Feature freeze) In-Reply-To: References: <57C39EB5-B1D6-402F-A443-80056A25B04C@haun-online.de> <7C5262C3-AC61-448B-8252-2F7E5B4D2FD3@haun-online.de> <1305413712.2202.10.camel@roccivic-pc> <65C823BC-6238-4812-8D9C-4E5D7B2AA0F0@haun-online.de> <1305458495.2221.15.camel@roccivic-pc> <018201cc1310$23be99c0$6b3bcd40$@cogeco.net> Message-ID: <1305473591.7028.19.camel@roccivic-pc> @Ivy: Does the upgrade work if you disable the plugin before uploading a new version? If yes, it's the same problem as I'm experiencing. Rouslan On Mon, 2011-05-16 at 00:25 +0900, ???? Geeklog IvyWe wrote: > Tom, > > My Geeklog 1.8.0 test site, I can't update any plugins. > > Windows 7 - IE9 FF Chrome > Mac - Safari Chrome > > By any browser, I can't update plugins. > > But Dirk can update plugins on my test site. > > > 2011/5/15 Tom : > > Hmm... my development server is having problems uncompressing files at the moment so I couldn't test the upload and auto upgrade procedure out right but I did a quick follow through with the code in Geeklog and your plugin and it looks like everything should work and the plugin upgrade should happen when PLG_upgrade gets called. (obviously it doesn't though) > > > > Ivy, is Rouslan's problem the same as yours? > > > > Tom > > > > -----Original Message----- > > From: geeklog-devel-bounces at lists.geeklog.net [mailto:geeklog-devel-bounces at lists.geeklog.net] On Behalf Of Rouslan Placella > > Sent: May-15-11 7:22 AM > > To: Geeklog Development > > Subject: Re: [geeklog-devel] More automation (was: Feature freeze) > > > > I have issues with updating plugins as well. For example, with my "search word ranking" plugin, if you do the following: > > > > * install a plugin v1.0.0 > > * disable this plugin > > * upload version 1.1.0 > > * enable plugin back > > * "update" icon shows up > > * click on update icon > > * upgrade works perfect > > > > However, if you do this: > > > > * install plugin v1.0.0 > > * upload version 1.1.0 > > * autoupdate takes place > > * Geeklog reports that version 1.1.0 is installed, but it's not true. > > plugin_upgrade_foobar() was never called. So the files are up to date, but the database as well as the configuration settings are from version > > 1.0.0 > > > > In both of the above cases I'm talking about uploading a tarball through the form on admin/plugins.php, not FTP or anything like that. > > > > Files needed to reproduce (note: there are only 4 config settings in version 1.0.0 and 8 config settings in 1.1.0): > > > > http://www.placella.com/gl/searchrank_1.0.0_1.6.0.tar.gz > > http://www.placella.com/gl/searchrank_1.1.0hg_1.6.0.tar.gz > > > > I couldn't trace the problem to anywhere, so it might be in my code, though I doubt it... > > > > Rouslan > > > > > > On Sun, 2011-05-15 at 08:55 +0200, Dirk Haun wrote: > >> ???? Geeklog IvyWe wrote: > >> > >> > plugin update works well? > >> > I can't update any plugins. > >> > >> Works for me. > >> > >> Can you provide more details, please? What are you doing? What happens? > >> > >> bye, Dirk > >> > _______________________________________________ > geeklog-devel mailing list > geeklog-devel at lists.geeklog.net > http://eight.pairlist.net/mailman/listinfo/geeklog-devel From komma at ivywe.co.jp Sun May 15 12:24:27 2011 From: komma at ivywe.co.jp (=?ISO-2022-JP?B?GyRCOiM2cEUvO1IbKEIgR2Vla2xvZyBJdnlXZQ==?=) Date: Mon, 16 May 2011 01:24:27 +0900 Subject: [geeklog-devel] More automation (was: Feature freeze) In-Reply-To: <1305473591.7028.19.camel@roccivic-pc> References: <57C39EB5-B1D6-402F-A443-80056A25B04C@haun-online.de> <7C5262C3-AC61-448B-8252-2F7E5B4D2FD3@haun-online.de> <1305413712.2202.10.camel@roccivic-pc> <65C823BC-6238-4812-8D9C-4E5D7B2AA0F0@haun-online.de> <1305458495.2221.15.camel@roccivic-pc> <018201cc1310$23be99c0$6b3bcd40$@cogeco.net> <1305473591.7028.19.camel@roccivic-pc> Message-ID: Rouslan, > @Ivy: Does the upgrade work if you disable the plugin before uploading a > new version? If yes, it's the same problem as I'm experiencing. No, both failed. Ivy 2011/5/16 Rouslan Placella : > @Ivy: Does the upgrade work if you disable the plugin before uploading a > new version? If yes, it's the same problem as I'm experiencing. > > Rouslan > > On Mon, 2011-05-16 at 00:25 +0900, ???? Geeklog IvyWe wrote: >> Tom, >> >> My Geeklog 1.8.0 test site, I can't update any plugins. >> >> Windows 7 - IE9 FF Chrome >> Mac - Safari Chrome >> >> By any browser, I can't update plugins. >> >> But Dirk can update plugins on my test site. >> >> >> 2011/5/15 Tom : >> > Hmm... my development server is having problems uncompressing files at the moment so I couldn't test the upload and auto upgrade procedure out right but I did a quick follow through with the code in Geeklog and your plugin and it looks like everything should work and the plugin upgrade should happen when PLG_upgrade gets called. (obviously it doesn't though) >> > >> > Ivy, is Rouslan's problem the same as yours? >> > >> > Tom >> > >> > -----Original Message----- >> > From: geeklog-devel-bounces at lists.geeklog.net [mailto:geeklog-devel-bounces at lists.geeklog.net] On Behalf Of Rouslan Placella >> > Sent: May-15-11 7:22 AM >> > To: Geeklog Development >> > Subject: Re: [geeklog-devel] More automation (was: Feature freeze) >> > >> > I have issues with updating plugins as well. For example, with my "search word ranking" plugin, if you do the following: >> > >> > * install a plugin v1.0.0 >> > * disable this plugin >> > * upload version 1.1.0 >> > * enable plugin back >> > * "update" icon shows up >> > * click on update icon >> > * upgrade works perfect >> > >> > However, if you do this: >> > >> > * install plugin v1.0.0 >> > * upload version 1.1.0 >> > * autoupdate takes place >> > * Geeklog reports that version 1.1.0 is installed, but it's not true. >> > plugin_upgrade_foobar() was never called. So the files are up to date, but the database as well as the configuration settings are from version >> > 1.0.0 >> > >> > In both of the above cases I'm talking about uploading a tarball through the form on admin/plugins.php, not FTP or anything like that. >> > >> > Files needed to reproduce (note: there are only 4 config settings in version 1.0.0 and 8 config settings in 1.1.0): >> > >> > http://www.placella.com/gl/searchrank_1.0.0_1.6.0.tar.gz >> > http://www.placella.com/gl/searchrank_1.1.0hg_1.6.0.tar.gz >> > >> > I couldn't trace the problem to anywhere, so it might be in my code, though I doubt it... >> > >> > Rouslan >> > >> > >> > On Sun, 2011-05-15 at 08:55 +0200, Dirk Haun wrote: >> >> ???? Geeklog IvyWe wrote: >> >> >> >> > plugin update works well? >> >> > I can't update any plugins. >> >> >> >> Works for me. >> >> >> >> Can you provide more details, please? What are you doing? What happens? >> >> >> >> bye, Dirk >> >> From dirk at haun-online.de Sun May 15 16:08:32 2011 From: dirk at haun-online.de (Dirk Haun) Date: Sun, 15 May 2011 22:08:32 +0200 Subject: [geeklog-devel] Updating the changelog In-Reply-To: <20110317110040.196035aozmc4wcmc@webmail.df.eu> References: <50D131BF-0582-4822-905A-5A27BEECF17E@haun-online.de> <000601cbe41a$fcf0e740$f6d2b5c0$@cogeco.net> <003C2E2F-06A4-403F-9341-0DBEC73E9890@haun-online.de> <20110317110040.196035aozmc4wcmc@webmail.df.eu> Message-ID: <4B60D018-2ACE-4EB2-AE8F-969B898EBE67@haun-online.de> > What we do at work is to generate the changelog from our bugtracker (JIRA - haven't checked what Mantis offers in terms of APIs). Mantis has a SOAP API. Fortunately, there are wsdl2php converters, so it's not too painful. I've managed to extract something that vaguely resembles our changelog entries, e.g. --- snip --- - Staticpage Plugin Function plugin_getiteminfo_staticpages does not always return correct data (Bugs #1342) [Laugh] - Calendar Week view date range may not display correctly (Bugs #1340) [Laugh] - Font size of Calendar is so small. (Feature Requests #1329) [Laugh] - "Mail users" lose all filled in values upon error (Patches #1270) [Roccivic] - Speed up template class (Patches #1302) [Laugh] - Oauth accounts get logged out after 2 minutes of inactivity (Bugs #1334) [Laugh] --- snip --- So looks like this would be doable. We just need to take a little bit more care about the subject and don't be afraid to update or rewrite it. As I said before: > But even there we had to add a field "summary for the changelog" and have a person performing the task of an editor to ensure that what ends up in the changelog is presentable to our customers ... > > But if we were to automate extraction of the changelog from the bugtracker, it would we easy to do just that. I.e. run the process, check contents, edit description where necessary, re-run process. bye, Dirk From rouslan at placella.com Sun May 15 16:38:11 2011 From: rouslan at placella.com (Rouslan Placella) Date: Sun, 15 May 2011 21:38:11 +0100 Subject: [geeklog-devel] Updating the changelog In-Reply-To: <4B60D018-2ACE-4EB2-AE8F-969B898EBE67@haun-online.de> References: <50D131BF-0582-4822-905A-5A27BEECF17E@haun-online.de> <000601cbe41a$fcf0e740$f6d2b5c0$@cogeco.net> <003C2E2F-06A4-403F-9341-0DBEC73E9890@haun-online.de> <20110317110040.196035aozmc4wcmc@webmail.df.eu> <4B60D018-2ACE-4EB2-AE8F-969B898EBE67@haun-online.de> Message-ID: <1305491891.7028.137.camel@roccivic-pc> Normally I don't edit the changelog in my patches. So, yeah, extracting the info from the bugtracker looks pretty appealing to me. Rouslan On Sun, 2011-05-15 at 22:08 +0200, Dirk Haun wrote: > > What we do at work is to generate the changelog from our bugtracker (JIRA - haven't checked what Mantis offers in terms of APIs). > > Mantis has a SOAP API. Fortunately, there are wsdl2php converters, so it's not too painful. I've managed to extract something that vaguely resembles our changelog entries, e.g. > > --- snip --- > - Staticpage Plugin Function plugin_getiteminfo_staticpages does not always return correct data (Bugs #1342) [Laugh] > - Calendar Week view date range may not display correctly (Bugs #1340) [Laugh] > - Font size of Calendar is so small. (Feature Requests #1329) [Laugh] > - "Mail users" lose all filled in values upon error (Patches #1270) [Roccivic] > - Speed up template class (Patches #1302) [Laugh] > - Oauth accounts get logged out after 2 minutes of inactivity (Bugs #1334) [Laugh] > --- snip --- > > So looks like this would be doable. We just need to take a little bit more care about the subject and don't be afraid to update or rewrite it. As I said before: > > > But even there we had to add a field "summary for the changelog" and have a person performing the task of an editor to ensure that what ends up in the changelog is presentable to our customers ... > > > > But if we were to automate extraction of the changelog from the bugtracker, it would we easy to do just that. I.e. run the process, check contents, edit description where necessary, re-run process. > > bye, Dirk > > _______________________________________________ > geeklog-devel mailing list > geeklog-devel at lists.geeklog.net > http://eight.pairlist.net/mailman/listinfo/geeklog-devel From vfuria at gmail.com Sun May 15 19:57:01 2011 From: vfuria at gmail.com (Vincent Furia) Date: Sun, 15 May 2011 17:57:01 -0600 Subject: [geeklog-devel] Updating the changelog In-Reply-To: <1305491891.7028.137.camel@roccivic-pc> References: <50D131BF-0582-4822-905A-5A27BEECF17E@haun-online.de> <000601cbe41a$fcf0e740$f6d2b5c0$@cogeco.net> <003C2E2F-06A4-403F-9341-0DBEC73E9890@haun-online.de> <20110317110040.196035aozmc4wcmc@webmail.df.eu> <4B60D018-2ACE-4EB2-AE8F-969B898EBE67@haun-online.de> <1305491891.7028.137.camel@roccivic-pc> Message-ID: That's great Dirk! One less thing to remember to do. -Vinny On Sun, May 15, 2011 at 14:38, Rouslan Placella wrote: > Normally I don't edit the changelog in my patches. So, yeah, extracting > the info from the bugtracker looks pretty appealing to me. > > Rouslan > > On Sun, 2011-05-15 at 22:08 +0200, Dirk Haun wrote: > > > What we do at work is to generate the changelog from our bugtracker > (JIRA - haven't checked what Mantis offers in terms of APIs). > > > > Mantis has a SOAP API. Fortunately, there are wsdl2php converters, so > it's not too painful. I've managed to extract something that vaguely > resembles our changelog entries, e.g. > > > > --- snip --- > > - Staticpage Plugin Function plugin_getiteminfo_staticpages does not > always return correct data (Bugs #1342) [Laugh] > > - Calendar Week view date range may not display correctly (Bugs #1340) > [Laugh] > > - Font size of Calendar is so small. (Feature Requests #1329) [Laugh] > > - "Mail users" lose all filled in values upon error (Patches #1270) > [Roccivic] > > - Speed up template class (Patches #1302) [Laugh] > > - Oauth accounts get logged out after 2 minutes of inactivity (Bugs > #1334) [Laugh] > > --- snip --- > > > > So looks like this would be doable. We just need to take a little bit > more care about the subject and don't be afraid to update or rewrite it. As > I said before: > > > > > But even there we had to add a field "summary for the changelog" and > have a person performing the task of an editor to ensure that what ends up > in the changelog is presentable to our customers ... > > > > > > But if we were to automate extraction of the changelog from the > bugtracker, it would we easy to do just that. I.e. run the process, check > contents, edit description where necessary, re-run process. > > > > bye, Dirk > > > > _______________________________________________ > > geeklog-devel mailing list > > geeklog-devel at lists.geeklog.net > > http://eight.pairlist.net/mailman/listinfo/geeklog-devel > > > _______________________________________________ > geeklog-devel mailing list > geeklog-devel at lists.geeklog.net > http://eight.pairlist.net/mailman/listinfo/geeklog-devel > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From komma at ivywe.co.jp Mon May 16 09:04:24 2011 From: komma at ivywe.co.jp (=?ISO-2022-JP?B?GyRCOiM2cEUvO1IbKEIgR2Vla2xvZyBJdnlXZQ==?=) Date: Mon, 16 May 2011 22:04:24 +0900 Subject: [geeklog-devel] More automation (was: Feature freeze) In-Reply-To: <1305413712.2202.10.camel@roccivic-pc> References: <57C39EB5-B1D6-402F-A443-80056A25B04C@haun-online.de> <7C5262C3-AC61-448B-8252-2F7E5B4D2FD3@haun-online.de> <1305413712.2202.10.camel@roccivic-pc> Message-ID: Rouslan, Can you update plugin by using submit icon? onclick="submit() is Okay? submit(plugin id)? But Dirl can update plugin by using the submit icon. I don't know why. Ivy 2011/5/15 Rouslan Placella : > On Sun, 2011-05-15 at 00:45 +0200, Dirk Haun wrote: >> Are there any issues left with 1.8.0? Do we need an rc2 or should we go straight to the final release? >> >> bye, Dirk > > I'm yet to reproduce the bug that was recently reported in PgSQL (I'll > try to get onto it tomorrow). Other than that I don't see any > showstoppers, so IMO we don't need an rc2. > > Rouslan > > _______________________________________________ > geeklog-devel mailing list > geeklog-devel at lists.geeklog.net > http://eight.pairlist.net/mailman/listinfo/geeklog-devel > From dirk at haun-online.de Tue May 17 05:59:59 2011 From: dirk at haun-online.de (Dirk Haun) Date: Tue, 17 May 2011 11:59:59 +0200 Subject: [geeklog-devel] Plugin Update issue vs. 1.8.0 release Message-ID: <20110517115959.34934y96ndxl7mkg@webmail.df.eu> So, what's the current state of that plugin update issue? This seems to be the only thing holding back the 1.8.0 release. For starters, there doesn't seem to be a bugtracker entry for this. Can someone please open one and collect the available information there? Most of the info seems to have been posted here under wrong/irrelevant subjects, so it's hard to find. And who's got time to work on this? bye, Dirk From komma at ivywe.co.jp Tue May 17 07:19:24 2011 From: komma at ivywe.co.jp (=?ISO-2022-JP?B?GyRCOiM2cEUvO1IbKEIgR2Vla2xvZyBJdnlXZQ==?=) Date: Tue, 17 May 2011 20:19:24 +0900 Subject: [geeklog-devel] Plugin Update issue vs. 1.8.0 release In-Reply-To: <20110517115959.34934y96ndxl7mkg@webmail.df.eu> References: <20110517115959.34934y96ndxl7mkg@webmail.df.eu> Message-ID: Dirk, I registed. http://project.geeklog.net/tracking/view.php?id=1344 -- Ivy http://www.geeklog.jp http://www.ivywe.co.jp 2011/5/17 Dirk Haun : > So, what's the current state of that plugin update issue? This seems to be > the only thing holding back the 1.8.0 release. > > For starters, there doesn't seem to be a bugtracker entry for this. Can > someone please open one and collect the available information there? Most of > the info seems to have been posted here under wrong/irrelevant subjects, so > it's hard to find. > > And who's got time to work on this? > > bye, Dirk > > From rouslan at placella.com Tue May 17 08:23:22 2011 From: rouslan at placella.com (Rouslan Placella) Date: Tue, 17 May 2011 13:23:22 +0100 Subject: [geeklog-devel] Plugin Update issue vs. 1.8.0 release In-Reply-To: <20110517115959.34934y96ndxl7mkg@webmail.df.eu> References: <20110517115959.34934y96ndxl7mkg@webmail.df.eu> Message-ID: <1305635002.2232.1.camel@roccivic-pc> On Tue, 2011-05-17 at 11:59 +0200, Dirk Haun wrote: > So, what's the current state of that plugin update issue? This seems > to be the only thing holding back the 1.8.0 release. > > For starters, there doesn't seem to be a bugtracker entry for this. > Can someone please open one and collect the available information > there? Most of the info seems to have been posted here under > wrong/irrelevant subjects, so it's hard to find. I filed my problem with plugin upgrade in the tracker. Rouslan From dirk at haun-online.de Wed May 18 16:56:09 2011 From: dirk at haun-online.de (Dirk Haun) Date: Wed, 18 May 2011 22:56:09 +0200 Subject: [geeklog-devel] Updating the changelog In-Reply-To: <4B60D018-2ACE-4EB2-AE8F-969B898EBE67@haun-online.de> References: <50D131BF-0582-4822-905A-5A27BEECF17E@haun-online.de> <000601cbe41a$fcf0e740$f6d2b5c0$@cogeco.net> <003C2E2F-06A4-403F-9341-0DBEC73E9890@haun-online.de> <20110317110040.196035aozmc4wcmc@webmail.df.eu> <4B60D018-2ACE-4EB2-AE8F-969B898EBE67@haun-online.de> Message-ID: <30898443-39DB-4DFA-8191-49CD96CFD5EA@haun-online.de> > Mantis has a SOAP API. Fortunately, there are wsdl2php converters, so it's not too painful. I've managed to extract something that vaguely resembles our changelog entries, e.g. I ran into one problem here: Attributing patches. For example (an actual generated entry): - Update bigdump.php (patch #0001143) [Dirk] That patch, however, came from Rouslan, my name is only there since I applied the patch (before Rouslan had commit access) and handled the issue. I've asked on the Mantis mailing list and it seems the information who submitted a patch is not available via SOAP. And even then it wouldn't be clear, since we have issue with more than one patch attached, not all of which are working. I guess we could work around that issue with specially formatted commit messages, but that's awkward and requires discipline ... bye, Dirk From websitemaster at cogeco.net Wed May 18 20:50:45 2011 From: websitemaster at cogeco.net (Tom) Date: Wed, 18 May 2011 20:50:45 -0400 Subject: [geeklog-devel] Updating the changelog In-Reply-To: <30898443-39DB-4DFA-8191-49CD96CFD5EA@haun-online.de> References: <50D131BF-0582-4822-905A-5A27BEECF17E@haun-online.de> <000601cbe41a$fcf0e740$f6d2b5c0$@cogeco.net> <003C2E2F-06A4-403F-9341-0DBEC73E9890@haun-online.de> <20110317110040.196035aozmc4wcmc@webmail.df.eu> <4B60D018-2ACE-4EB2-AE8F-969B898EBE67@haun-online.de> <30898443-39DB-4DFA-8191-49CD96CFD5EA@haun-online.de> Message-ID: <019f01cc15be$c9b3b8f0$5d1b2ad0$@cogeco.net> If it makes creating the change log easier then I am probably for it. Tom -----Original Message----- From: geeklog-devel-bounces at lists.geeklog.net [mailto:geeklog-devel-bounces at lists.geeklog.net] On Behalf Of Dirk Haun Sent: May-18-11 4:56 PM To: Geeklog Development Subject: Re: [geeklog-devel] Updating the changelog > Mantis has a SOAP API. Fortunately, there are wsdl2php converters, so it's not too painful. I've managed to extract something that vaguely resembles our changelog entries, e.g. I ran into one problem here: Attributing patches. For example (an actual generated entry): - Update bigdump.php (patch #0001143) [Dirk] That patch, however, came from Rouslan, my name is only there since I applied the patch (before Rouslan had commit access) and handled the issue. I've asked on the Mantis mailing list and it seems the information who submitted a patch is not available via SOAP. And even then it wouldn't be clear, since we have issue with more than one patch attached, not all of which are working. I guess we could work around that issue with specially formatted commit messages, but that's awkward and requires discipline ... bye, Dirk _______________________________________________ geeklog-devel mailing list geeklog-devel at lists.geeklog.net http://eight.pairlist.net/mailman/listinfo/geeklog-devel From dirk at haun-online.de Sat May 21 14:04:31 2011 From: dirk at haun-online.de (Dirk Haun) Date: Sat, 21 May 2011 20:04:31 +0200 Subject: [geeklog-devel] Plugin upgrade failure (was: More automation) In-Reply-To: <1305458495.2221.15.camel@roccivic-pc> References: <57C39EB5-B1D6-402F-A443-80056A25B04C@haun-online.de> <7C5262C3-AC61-448B-8252-2F7E5B4D2FD3@haun-online.de> <1305413712.2202.10.camel@roccivic-pc> <65C823BC-6238-4812-8D9C-4E5D7B2AA0F0@haun-online.de> <1305458495.2221.15.camel@roccivic-pc> Message-ID: Rouslan Placella wrote: > * install plugin v1.0.0 > * upload version 1.1.0 > * autoupdate takes place > * Geeklog reports that version 1.1.0 is installed, but it's not true. > plugin_upgrade_foobar() was never called. So the files are up to date, > but the database as well as the configuration settings are from version > 1.0.0 Nice fine. Looks like this case never worked correctly in the first place. The problem was that while we replaced the plugin's functions.inc, we were still calling the upgrade function from the old copy, which was still in memory at this point. I've fixed this by splitting the upgrade in two parts now: When all the files have been replaced and we've confirmed that we do need to call PLG_upgrade, it does a COM_refresh on itself now to force a (re)load of the (new) functions.inc. One implementation detail that I'm not happy with: This refresh happens without a security token, since COM_refresh doesn't cause a referrer to be set. I've tried to be extra thorough with the sanity checks but wouldn't mind another pair of eyes to have a look: http://project.geeklog.net/cgi-bin/hgwebdir.cgi/geeklog/rev/ce9647bd2310 bye, Dirk From rouslan at placella.com Sat May 21 15:11:58 2011 From: rouslan at placella.com (Rouslan Placella) Date: Sat, 21 May 2011 20:11:58 +0100 Subject: [geeklog-devel] Plugin upgrade failure (was: More automation) In-Reply-To: References: <57C39EB5-B1D6-402F-A443-80056A25B04C@haun-online.de> <7C5262C3-AC61-448B-8252-2F7E5B4D2FD3@haun-online.de> <1305413712.2202.10.camel@roccivic-pc> <65C823BC-6238-4812-8D9C-4E5D7B2AA0F0@haun-online.de> <1305458495.2221.15.camel@roccivic-pc> Message-ID: <1306005118.12117.4.camel@roccivic-pc> I didn't try your fix yet, but from what I can see in plugins.php, there is no output sent to the browser when you call COM_refresh($url). So it should be possible to use: header("Location: $url"); Will that send a referrer? Rouslan On Sat, 2011-05-21 at 20:04 +0200, Dirk Haun wrote: > Rouslan Placella wrote: > > > * install plugin v1.0.0 > > * upload version 1.1.0 > > * autoupdate takes place > > * Geeklog reports that version 1.1.0 is installed, but it's not true. > > plugin_upgrade_foobar() was never called. So the files are up to date, > > but the database as well as the configuration settings are from version > > 1.0.0 > > Nice fine. Looks like this case never worked correctly in the first place. > > The problem was that while we replaced the plugin's functions.inc, we were still calling the upgrade function from the old copy, which was still in memory at this point. > > I've fixed this by splitting the upgrade in two parts now: When all the files have been replaced and we've confirmed that we do need to call PLG_upgrade, it does a COM_refresh on itself now to force a (re)load of the (new) functions.inc. > > One implementation detail that I'm not happy with: This refresh happens without a security token, since COM_refresh doesn't cause a referrer to be set. I've tried to be extra thorough with the sanity checks but wouldn't mind another pair of eyes to have a look: > > http://project.geeklog.net/cgi-bin/hgwebdir.cgi/geeklog/rev/ce9647bd2310 > > bye, Dirk > > _______________________________________________ > geeklog-devel mailing list > geeklog-devel at lists.geeklog.net > http://eight.pairlist.net/mailman/listinfo/geeklog-devel From dirk at haun-online.de Sat May 21 16:19:55 2011 From: dirk at haun-online.de (Dirk Haun) Date: Sat, 21 May 2011 22:19:55 +0200 Subject: [geeklog-devel] Plugin upgrade failure (was: More automation) In-Reply-To: <1306005118.12117.4.camel@roccivic-pc> References: <57C39EB5-B1D6-402F-A443-80056A25B04C@haun-online.de> <7C5262C3-AC61-448B-8252-2F7E5B4D2FD3@haun-online.de> <1305413712.2202.10.camel@roccivic-pc> <65C823BC-6238-4812-8D9C-4E5D7B2AA0F0@haun-online.de> <1305458495.2221.15.camel@roccivic-pc> <1306005118.12117.4.camel@roccivic-pc> Message-ID: <018E7AA9-ACFE-42AC-93AB-6691FD82AEDA@haun-online.de> Rouslan Placella wrote: > I didn't try your fix yet, but from what I can see in plugins.php, there > is no output sent to the browser when you call COM_refresh($url). So it > should be possible to use: > > header("Location: $url"); > > Will that send a referrer? For a moment, I thought I had missed something obvious ... It's not so easy, unfortunately. The referrer is just another HTTP header. But we can't create it, the browser has to do it: COM_refresh() creates an HTML snippet that does a meta refresh to the new URL. This HTML snippet is sent to the browser as the result of clicking the "Upload" button. The browser then sends another HTTP GET request (to the URL from the meta refresh) back to Geeklog (which then triggers the second part of the plugin upgrade). The referrer would have to be sent with that GET request, i.e. the browser would have to create it. The only way we could make this work would be by throwing some JavaScript into the mix. But I don't really want the plugin upload to _require_ JavaScript. That's the tradeoff here, I guess. bye, Dirk From jmucchiello at yahoo.com Sat May 21 16:54:24 2011 From: jmucchiello at yahoo.com (Joe Mucchiello) Date: Sat, 21 May 2011 13:54:24 -0700 (PDT) Subject: [geeklog-devel] Plugin upgrade failure (was: More automation) Message-ID: <850087.63155.qm@web161404.mail.bf1.yahoo.com> > The problem was that while we replaced the plugin's functions.inc, we were >still > calling the upgrade function from the old copy, which was still in memory at >this > point. This has always bothered me. Why is plugin_upgrade_foo in functions.inc? It should be in the autoinstall.php file that only gets loaded by the installer code. There are lots of ways this could be done in the future to avoid the COM_refresh. Not that any of those methods are useful days before 1.8 goes live. Maybe the location of functions within the plugins can be targeted for 1.9 (also needed for my comments a few months ago about reducing Geeklog's memory footprint). From rouslan at placella.com Sat May 21 17:10:20 2011 From: rouslan at placella.com (Rouslan Placella) Date: Sat, 21 May 2011 22:10:20 +0100 Subject: [geeklog-devel] Plugin upgrade failure (was: More automation) In-Reply-To: <018E7AA9-ACFE-42AC-93AB-6691FD82AEDA@haun-online.de> References: <57C39EB5-B1D6-402F-A443-80056A25B04C@haun-online.de> <7C5262C3-AC61-448B-8252-2F7E5B4D2FD3@haun-online.de> <1305413712.2202.10.camel@roccivic-pc> <65C823BC-6238-4812-8D9C-4E5D7B2AA0F0@haun-online.de> <1305458495.2221.15.camel@roccivic-pc> <1306005118.12117.4.camel@roccivic-pc> <018E7AA9-ACFE-42AC-93AB-6691FD82AEDA@haun-online.de> Message-ID: <1306012220.2112.6.camel@roccivic-pc> On Sat, 2011-05-21 at 22:19 +0200, Dirk Haun wrote: > Rouslan Placella wrote: > > > I didn't try your fix yet, but from what I can see in plugins.php, there > > is no output sent to the browser when you call COM_refresh($url). So it > > should be possible to use: > > > > header("Location: $url"); > > > > Will that send a referrer? > > For a moment, I thought I had missed something obvious ... It's not so easy, unfortunately. > > The referrer is just another HTTP header. But we can't create it, the browser has to do it: > > COM_refresh() creates an HTML snippet that does a meta refresh to the new URL. This HTML snippet is sent to the browser as the result of clicking the "Upload" button. The browser then sends another HTTP GET request (to the URL from the meta refresh) back to Geeklog (which then triggers the second part of the plugin upgrade). The referrer would have to be sent with that GET request, i.e. the browser would have to create it. > > The only way we could make this work would be by throwing some JavaScript into the mix. But I don't really want the plugin upload to _require_ JavaScript. That's the tradeoff here, I guess. > > bye, Dirk Perhaps I'm missing something, but the 'header("Location: $url");' call does send a referer. It's the referer that it itself received, it merely copies it over. And since we go from plugins.php to plugins.php and once more to plugins.php, I'm guessing it could be good enough. Try the example in the attached tarball by clicking the link on page1.php Could this work or am I just embarrassing myself further on the list? Rouslan -------------- next part -------------- A non-text attachment was scrubbed... Name: referer_test.tar.gz Type: application/x-compressed-tar Size: 307 bytes Desc: not available URL: From dirk at haun-online.de Sat May 21 18:02:11 2011 From: dirk at haun-online.de (Dirk Haun) Date: Sun, 22 May 2011 00:02:11 +0200 Subject: [geeklog-devel] Plugin upgrade failure (was: More automation) In-Reply-To: <1306012220.2112.6.camel@roccivic-pc> References: <57C39EB5-B1D6-402F-A443-80056A25B04C@haun-online.de> <7C5262C3-AC61-448B-8252-2F7E5B4D2FD3@haun-online.de> <1305413712.2202.10.camel@roccivic-pc> <65C823BC-6238-4812-8D9C-4E5D7B2AA0F0@haun-online.de> <1305458495.2221.15.camel@roccivic-pc> <1306005118.12117.4.camel@roccivic-pc> <018E7AA9-ACFE-42AC-93AB-6691FD82AEDA@haun-online.de> <1306012220.2112.6.camel@roccivic-pc> Message-ID: Rouslan Placella wrote: > Perhaps I'm missing something, but the 'header("Location: $url");' call > does send a referer. It's the referer that it itself received, it merely > copies it over. I hadn't considered this, I have to admit. Unfortunately it doesn't help us, since it's the wrong URL ... With the Location header (as with the meta refresh) we specify the URL we want the browser to go to. So that's the .../plugins.php?mode=continue_upgrade... URL. But when the CSRF token is generated, it uses the then-current URL and that's .../plugins.php, without any further parameters. So the two URLs (the one in the token and the one in the referrer) don't match. HTTP can be messy sometimes :P > Could this work or am I just embarrassing myself further on the list? No worries, I obviously hadn't thought this through entirely myself. Thanks for being insistent :) bye, Dirk From rouslan at placella.com Sat May 21 20:53:27 2011 From: rouslan at placella.com (Rouslan Placella) Date: Sun, 22 May 2011 01:53:27 +0100 Subject: [geeklog-devel] Plugin upgrade failure (was: More automation) In-Reply-To: References: <57C39EB5-B1D6-402F-A443-80056A25B04C@haun-online.de> <7C5262C3-AC61-448B-8252-2F7E5B4D2FD3@haun-online.de> <1305413712.2202.10.camel@roccivic-pc> <65C823BC-6238-4812-8D9C-4E5D7B2AA0F0@haun-online.de> <1305458495.2221.15.camel@roccivic-pc> <1306005118.12117.4.camel@roccivic-pc> <018E7AA9-ACFE-42AC-93AB-6691FD82AEDA@haun-online.de> <1306012220.2112.6.camel@roccivic-pc> Message-ID: <1306025607.2281.2.camel@roccivic-pc> On Sun, 2011-05-22 at 00:02 +0200, Dirk Haun wrote: > Rouslan Placella wrote: > > > Perhaps I'm missing something, but the 'header("Location: $url");' call > > does send a referer. It's the referer that it itself received, it merely > > copies it over. > > I hadn't considered this, I have to admit. Unfortunately it doesn't help us, since it's the wrong URL ... > > With the Location header (as with the meta refresh) we specify the URL we want the browser to go to. So that's the .../plugins.php?mode=continue_upgrade... URL. But when the CSRF token is generated, it uses the then-current URL and that's .../plugins.php, without any further parameters. So the two URLs (the one in the token and the one in the referrer) don't match. > > HTTP can be messy sometimes :P The token mismatch isn't actually where you think it is. I got it to work, see attached patch. However we lose a message, though I'm not sure what it is or how important... Rouslan -------------- next part -------------- A non-text attachment was scrubbed... Name: patch.diff.gz Type: application/x-gzip Size: 625 bytes Desc: not available URL: From dirk at haun-online.de Sun May 22 04:26:53 2011 From: dirk at haun-online.de (Dirk Haun) Date: Sun, 22 May 2011 10:26:53 +0200 Subject: [geeklog-devel] Plugin upgrade failure (was: More automation) In-Reply-To: <1306025607.2281.2.camel@roccivic-pc> References: <57C39EB5-B1D6-402F-A443-80056A25B04C@haun-online.de> <7C5262C3-AC61-448B-8252-2F7E5B4D2FD3@haun-online.de> <1305413712.2202.10.camel@roccivic-pc> <65C823BC-6238-4812-8D9C-4E5D7B2AA0F0@haun-online.de> <1305458495.2221.15.camel@roccivic-pc> <1306005118.12117.4.camel@roccivic-pc> <018E7AA9-ACFE-42AC-93AB-6691FD82AEDA@haun-online.de> <1306012220.2112.6.camel@roccivic-pc> <1306025607.2281.2.camel@roccivic-pc> Message-ID: Rouslan Placella wrote: > The token mismatch isn't actually where you think it is. Yep, you're right. > However we lose a message, though I'm not sure > what it is or how important... First of all, we both seem to test the same situation, i.e. upload the 1.0.0 version of the plugin and then immediately upload the 1.1.0 version. The successful initial install will result in message 44 being displayed, i.e. the current URL ends in ?msg=44 when we upload the 1.1.0 version. The problem then is this: Sun May 22 10:01:07 2011 - created token b0a28de3bfe5f32eeb1b503446755aa1 for URL http://example.com/admin/plugins.php Sun May 22 10:01:07 2011 - mode=continue_upgrade, Referrer: http://example.com/admin/plugins.php?msg=44 Sun May 22 10:01:07 2011 - checking token b0a28de3bfe5f32eeb1b503446755aa1 Sun May 22 10:01:07 2011 - > referrer didn't match, expected http://example.com/admin/plugins.php but got http://example.com/admin/plugins.php?msg=44 SEC_createToken uses COM_getCurrentURL to get the current URL. But the reconstructed URL is missing the ?msg=44 bit, probably because we're in the middle of a POST request at this point. Ugh. I don't really want to fiddle with COM_getCurrentURL at this point. Suggestion: We leave things as they are (i.e. no token check for this upgrade scenario) for 1.8.0 and try to fix COM_getCurrentURL for 1.8.1. I think the upgrade is reasonably safe as it is - it's vulnerable to CSRF but with the sanity checks in place, I don't see how you could do any damage here. Comments, other opionions, other solutions? bye, Dirk From rouslan at placella.com Sun May 22 07:39:45 2011 From: rouslan at placella.com (Rouslan Placella) Date: Sun, 22 May 2011 12:39:45 +0100 Subject: [geeklog-devel] Plugin upgrade failure (was: More automation) In-Reply-To: References: <57C39EB5-B1D6-402F-A443-80056A25B04C@haun-online.de> <7C5262C3-AC61-448B-8252-2F7E5B4D2FD3@haun-online.de> <1305413712.2202.10.camel@roccivic-pc> <65C823BC-6238-4812-8D9C-4E5D7B2AA0F0@haun-online.de> <1305458495.2221.15.camel@roccivic-pc> <1306005118.12117.4.camel@roccivic-pc> <018E7AA9-ACFE-42AC-93AB-6691FD82AEDA@haun-online.de> <1306012220.2112.6.camel@roccivic-pc> <1306025607.2281.2.camel@roccivic-pc> Message-ID: <1306064385.1964.5.camel@roccivic-pc> On Sun, 2011-05-22 at 10:26 +0200, Dirk Haun wrote: > Suggestion: We leave things as they are (i.e. no token check for this upgrade scenario) for 1.8.0 Agreed. By the way, the rest of the continue_upgrade code looks good to me. Rouslan From jmucchiello at yahoo.com Sun May 22 09:20:44 2011 From: jmucchiello at yahoo.com (Joe Mucchiello) Date: Sun, 22 May 2011 06:20:44 -0700 (PDT) Subject: [geeklog-devel] Plugin upgrade failure (was: More automation) Message-ID: <605425.28459.qm@web161404.mail.bf1.yahoo.com> > SEC_createToken uses COM_getCurrentURL to get the current URL. But the >reconstructed > URL is missing the ?msg=44 bit, probably because we're in the >middle of a POST > request at this point. > > Ugh. I don't really want to fiddle >with COM_getCurrentURL at this point. I'm not following this discussion completely but could you add a parameter to SEC_createToken allowing you to override the URL. Call COM_getCurrentURL from the install/upgrade code and strip off everything after the ? to create the correct URL before calling SEC_createToken. From rouslan at placella.com Sun May 22 10:13:42 2011 From: rouslan at placella.com (Rouslan Placella) Date: Sun, 22 May 2011 15:13:42 +0100 Subject: [geeklog-devel] Plugin upgrade failure (was: More automation) In-Reply-To: <850087.63155.qm@web161404.mail.bf1.yahoo.com> References: <850087.63155.qm@web161404.mail.bf1.yahoo.com> Message-ID: <1306073622.1964.9.camel@roccivic-pc> On Sat, 2011-05-21 at 13:54 -0700, Joe Mucchiello wrote: > > The problem was that while we replaced the plugin's functions.inc, we were > >still > > calling the upgrade function from the old copy, which was still in memory at > >this > > point. > > This has always bothered me. Why is plugin_upgrade_foo in functions.inc? It > should > be in the autoinstall.php file that only gets loaded by the installer code. > There > are lots of ways this could be done in the future to avoid the COM_refresh. Not > that any of those methods are useful days before 1.8 goes live. Maybe the > location > of functions within the plugins can be targeted for 1.9 (also needed for my > comments > a few months ago about reducing Geeklog's memory footprint). While certainly a good idea for the memory issue, I'd say that this won't help for the problem with the plugin upgrade that we are having. Since 1.8.0, Geeklog loads the autoinstall.php of each plugin when the admin visits ./public_html/admin/plugins.php. This is necessary to extract the information about plugin dependencies. Rouslan From cordiste at free.fr Sun May 22 13:37:00 2011 From: cordiste at free.fr (cordiste) Date: Sun, 22 May 2011 19:37:00 +0200 Subject: [geeklog-devel] Plugin upgrade failure (was: More automation) In-Reply-To: References: <57C39EB5-B1D6-402F-A443-80056A25B04C@haun-online.de> <7C5262C3-AC61-448B-8252-2F7E5B4D2FD3@haun-online.de> <1305413712.2202.10.camel@roccivic-pc> <65C823BC-6238-4812-8D9C-4E5D7B2AA0F0@haun-online.de> <1305458495.2221.15.camel@roccivic-pc> Message-ID: This seems to be related to bug #1165 [1] Why not automatically disable plugin when the admin hit the upload button, then enable the plugin and lets the admin hit the upgrade button ? Ben [1] http://project.geeklog.net/tracking/view.php?id=1165 2011/5/21 Dirk Haun : > Rouslan Placella wrote: > >> * install plugin v1.0.0 >> * upload version 1.1.0 >> * autoupdate takes place >> * Geeklog reports that version 1.1.0 is installed, but it's not true. >> plugin_upgrade_foobar() was never called. So the files are up to date, >> but the database as well as the configuration settings are from version >> 1.0.0 > > Nice fine. Looks like this case never worked correctly in the first place. > > The problem was that while we replaced the plugin's functions.inc, we were still calling the upgrade function from the old copy, which was still in memory at this point. > > I've fixed this by splitting the upgrade in two parts now: When all the files have been replaced and we've confirmed that we do need to call PLG_upgrade, it does a COM_refresh on itself now to force a (re)load of the (new) functions.inc. > > One implementation detail that I'm not happy with: This refresh happens without a security token, since COM_refresh doesn't cause a referrer to be set. I've tried to be extra thorough with the sanity checks but wouldn't mind another pair of eyes to have a look: > > http://project.geeklog.net/cgi-bin/hgwebdir.cgi/geeklog/rev/ce9647bd2310 > > bye, Dirk > > _______________________________________________ > geeklog-devel mailing list > geeklog-devel at lists.geeklog.net > http://eight.pairlist.net/mailman/listinfo/geeklog-devel > > From cordiste at free.fr Sun May 22 13:43:06 2011 From: cordiste at free.fr (cordiste) Date: Sun, 22 May 2011 19:43:06 +0200 Subject: [geeklog-devel] Plugin upgrade failure (was: More automation) In-Reply-To: References: <57C39EB5-B1D6-402F-A443-80056A25B04C@haun-online.de> <7C5262C3-AC61-448B-8252-2F7E5B4D2FD3@haun-online.de> <1305413712.2202.10.camel@roccivic-pc> <65C823BC-6238-4812-8D9C-4E5D7B2AA0F0@haun-online.de> <1305458495.2221.15.camel@roccivic-pc> Message-ID: Oups I discover that bug #1345 [1] was fixed yesterday. Ben [1] http://project.geeklog.net/tracking/view.php?id=1345 2011/5/22 cordiste : > This seems to be related to bug #1165 [1] > > Why not automatically disable plugin when the admin hit the upload > button, then enable the plugin and lets the admin hit the upgrade > button ? > > Ben > > [1] http://project.geeklog.net/tracking/view.php?id=1165 > > 2011/5/21 Dirk Haun : >> Rouslan Placella wrote: >> >>> * install plugin v1.0.0 >>> * upload version 1.1.0 >>> * autoupdate takes place >>> * Geeklog reports that version 1.1.0 is installed, but it's not true. >>> plugin_upgrade_foobar() was never called. So the files are up to date, >>> but the database as well as the configuration settings are from version >>> 1.0.0 >> >> Nice fine. Looks like this case never worked correctly in the first place. >> >> The problem was that while we replaced the plugin's functions.inc, we were still calling the upgrade function from the old copy, which was still in memory at this point. >> >> I've fixed this by splitting the upgrade in two parts now: When all the files have been replaced and we've confirmed that we do need to call PLG_upgrade, it does a COM_refresh on itself now to force a (re)load of the (new) functions.inc. >> >> One implementation detail that I'm not happy with: This refresh happens without a security token, since COM_refresh doesn't cause a referrer to be set. I've tried to be extra thorough with the sanity checks but wouldn't mind another pair of eyes to have a look: >> >> http://project.geeklog.net/cgi-bin/hgwebdir.cgi/geeklog/rev/ce9647bd2310 >> >> bye, Dirk >> >> _______________________________________________ >> geeklog-devel mailing list >> geeklog-devel at lists.geeklog.net >> http://eight.pairlist.net/mailman/listinfo/geeklog-devel >> >> > From dirk at haun-online.de Sun May 22 14:27:29 2011 From: dirk at haun-online.de (Dirk Haun) Date: Sun, 22 May 2011 20:27:29 +0200 Subject: [geeklog-devel] Plugin upgrade failure (was: More automation) In-Reply-To: References: <57C39EB5-B1D6-402F-A443-80056A25B04C@haun-online.de> <7C5262C3-AC61-448B-8252-2F7E5B4D2FD3@haun-online.de> <1305413712.2202.10.camel@roccivic-pc> <65C823BC-6238-4812-8D9C-4E5D7B2AA0F0@haun-online.de> <1305458495.2221.15.camel@roccivic-pc> Message-ID: cordiste wrote: > This seems to be related to bug #1165 [1] It is the same bug, actually. So kudos for finding it first and even proposing the same solution. Too bad it slipped through the cracks :-/ > Why not automatically disable plugin when the admin hit the upload > button, then enable the plugin and lets the admin hit the upgrade > button ? The plugin is actually disabled during the upload of the new version, but then re-enabled for the automatic upgrade. I think if we can make this work automatically, then we should do it, to make plugin updates as simple as possible. Plugin installation and updates seem to be a common cause of confusion and problems among our users - I'd like to address that. The upgrade process works now, we're only missing an extra bit of security, which we'll address in a future Geeklog version. bye, Dirk From cordiste at free.fr Sun May 22 15:16:39 2011 From: cordiste at free.fr (cordiste) Date: Sun, 22 May 2011 21:16:39 +0200 Subject: [geeklog-devel] Core upgrade autoinstall new plugins Message-ID: Will the core upgrade to 1.8.0+ will still autoinstall new plugins? Could that be an option? See bug report #1224 [1] Ben [1] http://project.geeklog.net/tracking/view.php?id=1224 From dirk at haun-online.de Sun May 22 15:45:56 2011 From: dirk at haun-online.de (Dirk Haun) Date: Sun, 22 May 2011 21:45:56 +0200 Subject: [geeklog-devel] Core upgrade autoinstall new plugins In-Reply-To: References: Message-ID: <3A12AFEF-7FEC-40A2-A14E-26591DA771F0@haun-online.de> cordiste wrote: > Will the core upgrade to 1.8.0+ will still autoinstall new plugins? > Could that be an option? See bug report #1224 [1] So you've uninstalled a plugin, have the files still around, and when the next Geeklog update is installed, it re-installs that plugin? Hmm, I can see that this would be unexpected. I'm just wondering if an option in the install script would be the best way to avoid this, though. Maybe uninstalling a plugin should really remove the files as well? Or leave an "uninstalled" entry in the database. bye, Dirk From cordiste at free.fr Mon May 23 01:55:54 2011 From: cordiste at free.fr (cordiste) Date: Mon, 23 May 2011 07:55:54 +0200 Subject: [geeklog-devel] Core upgrade autoinstall new plugins In-Reply-To: <3A12AFEF-7FEC-40A2-A14E-26591DA771F0@haun-online.de> References: <3A12AFEF-7FEC-40A2-A14E-26591DA771F0@haun-online.de> Message-ID: As I'm using the Multi plugin [1]. Some plugins are disabled and other are not depending to the site needs. >> Maybe uninstalling a plugin should really remove the files as well? So this would be a very bad solution in this particular case :) A checkbox in the upgrade script would be a better option and leave an "uninstalled" entry another one. Ben [1] http://geeklog.fr/wiki/plugins:multi 2011/5/22 Dirk Haun : > cordiste wrote: > >> Will the core upgrade to 1.8.0+ will still autoinstall new plugins? >> Could that be an option? See bug report #1224 [1] > > So you've uninstalled a plugin, have the files still around, and when the next Geeklog update is installed, it re-installs that plugin? > > Hmm, I can see that this would be unexpected. I'm just wondering if an option in the install script would be the best way to avoid this, though. Maybe uninstalling a plugin should really remove the files as well? Or leave an "uninstalled" entry in the database. > > bye, Dirk > > _______________________________________________ > geeklog-devel mailing list > geeklog-devel at lists.geeklog.net > http://eight.pairlist.net/mailman/listinfo/geeklog-devel > > From websitemaster at cogeco.net Mon May 23 08:35:28 2011 From: websitemaster at cogeco.net (Tom) Date: Mon, 23 May 2011 08:35:28 -0400 Subject: [geeklog-devel] Core upgrade autoinstall new plugins In-Reply-To: <3A12AFEF-7FEC-40A2-A14E-26591DA771F0@haun-online.de> References: <3A12AFEF-7FEC-40A2-A14E-26591DA771F0@haun-online.de> Message-ID: <002201cc1945$e5a42740$b0ec75c0$@cogeco.net> >> Maybe uninstalling a plugin should really remove the files as well? Only if there is a config option to disable it or maybe a checkbox on the plugin admin page would suffice. >> Or leave an "uninstalled" entry in the database. I would rather see a list of plugins that will be installed when the Geeklog install script is run. The admin can then uncheck any he does not want installed. Tom -----Original Message----- From: geeklog-devel-bounces at lists.geeklog.net [mailto:geeklog-devel-bounces at lists.geeklog.net] On Behalf Of Dirk Haun Sent: May-22-11 3:46 PM To: Geeklog Development Subject: Re: [geeklog-devel] Core upgrade autoinstall new plugins cordiste wrote: > Will the core upgrade to 1.8.0+ will still autoinstall new plugins? > Could that be an option? See bug report #1224 [1] So you've uninstalled a plugin, have the files still around, and when the next Geeklog update is installed, it re-installs that plugin? Hmm, I can see that this would be unexpected. I'm just wondering if an option in the install script would be the best way to avoid this, though. Maybe uninstalling a plugin should really remove the files as well? Or leave an "uninstalled" entry in the database. bye, Dirk _______________________________________________ geeklog-devel mailing list geeklog-devel at lists.geeklog.net http://eight.pairlist.net/mailman/listinfo/geeklog-devel From dirk at haun-online.de Mon May 23 13:48:47 2011 From: dirk at haun-online.de (Dirk Haun) Date: Mon, 23 May 2011 19:48:47 +0200 Subject: [geeklog-devel] Core upgrade autoinstall new plugins In-Reply-To: <002201cc1945$e5a42740$b0ec75c0$@cogeco.net> References: <3A12AFEF-7FEC-40A2-A14E-26591DA771F0@haun-online.de> <002201cc1945$e5a42740$b0ec75c0$@cogeco.net> Message-ID: Tom wrote: >>> Or leave an "uninstalled" entry in the database. > > I would rather see a list of plugins that will be installed when the Geeklog > install script is run. The admin can then uncheck any he does not want > installed. This is already possible for a fresh install, btw. On the second page of the install script, there's an option "Install and configure additional plugins" which does just that. The paths through the install script can be tricky, but it should be possible to re-use this for the upgrade process as well (which was Ben's original issue) if required. I'm just trying to get an idea if all these options are really typical use cases. The install and upgrade should be as simple as possible, IMO, and if something isn't used a lot, it may be better put somewhere else. bye, Dirk From websitemaster at cogeco.net Wed May 25 15:01:30 2011 From: websitemaster at cogeco.net (Tom) Date: Wed, 25 May 2011 15:01:30 -0400 Subject: [geeklog-devel] Core upgrade autoinstall new plugins In-Reply-To: References: <3A12AFEF-7FEC-40A2-A14E-26591DA771F0@haun-online.de> <002201cc1945$e5a42740$b0ec75c0$@cogeco.net> Message-ID: <002d01cc1b0e$28737890$795a69b0$@cogeco.net> >> This is already possible for a fresh install, btw. On the second page of the install script, there's an option "Install and configure additional plugins" which does just that. I thought that was for core plugins only, I am glad it checks for any plugin. What is the status for the next release since the upgrade stuff has been solved? Do you think we can release 1.8.0 this weekend or next? Tom -----Original Message----- From: geeklog-devel-bounces at lists.geeklog.net [mailto:geeklog-devel-bounces at lists.geeklog.net] On Behalf Of Dirk Haun Sent: May-23-11 1:49 PM To: Geeklog Development Subject: Re: [geeklog-devel] Core upgrade autoinstall new plugins Tom wrote: >>> Or leave an "uninstalled" entry in the database. > > I would rather see a list of plugins that will be installed when the > Geeklog install script is run. The admin can then uncheck any he does > not want installed. This is already possible for a fresh install, btw. On the second page of the install script, there's an option "Install and configure additional plugins" which does just that. The paths through the install script can be tricky, but it should be possible to re-use this for the upgrade process as well (which was Ben's original issue) if required. I'm just trying to get an idea if all these options are really typical use cases. The install and upgrade should be as simple as possible, IMO, and if something isn't used a lot, it may be better put somewhere else. bye, Dirk _______________________________________________ geeklog-devel mailing list geeklog-devel at lists.geeklog.net http://eight.pairlist.net/mailman/listinfo/geeklog-devel From dirk at haun-online.de Wed May 25 15:30:55 2011 From: dirk at haun-online.de (Dirk Haun) Date: Wed, 25 May 2011 21:30:55 +0200 Subject: [geeklog-devel] Core upgrade autoinstall new plugins In-Reply-To: <002d01cc1b0e$28737890$795a69b0$@cogeco.net> References: <3A12AFEF-7FEC-40A2-A14E-26591DA771F0@haun-online.de> <002201cc1945$e5a42740$b0ec75c0$@cogeco.net> <002d01cc1b0e$28737890$795a69b0$@cogeco.net> Message-ID: <8C5A88B6-6E93-4CCA-AC44-173BEAA4892F@haun-online.de> Tom wrote: > What is the status for the next release since the upgrade stuff has been > solved? Do you think we can release 1.8.0 this weekend or next? The changelog needs a final update and somebody has to write the release announcement. geeklog.net is already up to date. So we're ready to go and it all comes down to finding some time (and inspiration) to actually do it. bye, Dirk From websitemaster at cogeco.net Thu May 26 09:26:20 2011 From: websitemaster at cogeco.net (Tom) Date: Thu, 26 May 2011 09:26:20 -0400 Subject: [geeklog-devel] Core upgrade autoinstall new plugins In-Reply-To: <8C5A88B6-6E93-4CCA-AC44-173BEAA4892F@haun-online.de> References: <3A12AFEF-7FEC-40A2-A14E-26591DA771F0@haun-online.de> <002201cc1945$e5a42740$b0ec75c0$@cogeco.net> <002d01cc1b0e$28737890$795a69b0$@cogeco.net> <8C5A88B6-6E93-4CCA-AC44-173BEAA4892F@haun-online.de> Message-ID: <007401cc1ba8$800070f0$800152d0$@cogeco.net> I am pretty busy at the moment but I should be able to write up the release this weekend. Tom -----Original Message----- From: geeklog-devel-bounces at lists.geeklog.net [mailto:geeklog-devel-bounces at lists.geeklog.net] On Behalf Of Dirk Haun Sent: May-25-11 3:31 PM To: Geeklog Development Subject: Re: [geeklog-devel] Core upgrade autoinstall new plugins Tom wrote: > What is the status for the next release since the upgrade stuff has > been solved? Do you think we can release 1.8.0 this weekend or next? The changelog needs a final update and somebody has to write the release announcement. geeklog.net is already up to date. So we're ready to go and it all comes down to finding some time (and inspiration) to actually do it. bye, Dirk _______________________________________________ geeklog-devel mailing list geeklog-devel at lists.geeklog.net http://eight.pairlist.net/mailman/listinfo/geeklog-devel From dirk at haun-online.de Sat May 28 08:03:43 2011 From: dirk at haun-online.de (Dirk Haun) Date: Sat, 28 May 2011 14:03:43 +0200 Subject: [geeklog-devel] Upgrade bug in 1.8.0 Message-ID: Trying to reproduce someone's upgrade problems, I found an unrelated upgrade problem in 1.8.0: When you're upgrading from a pre-1.5.0 version, the plugin upgrades (e.g. for the Calendar) fail when trying to initialize the Configuration: Fatal error: 1054: Unknown column 'tab' in 'field list' in /geeklog/system/databases/mysql.class.php on line 260 Call Stack # Time Memory Function Location 1 0.0115 591372 {main}( ) ../migrate.php:0 2 0.1030 1373756 INST_doDatabaseUpgrades( ) ../migrate.php:784 3 3.6755 2265908 upgrade_CalendarPlugin( ) ../lib-upgrade.php:408 4 3.6771 2303464 plugin_initconfig_calendar( ) ../mysql_1.4.1_to_1.5.0.php:482 5 3.6774 2305140 config->add( ) ../install_defaults.php:147 6 3.6776 2306568 config->_DB_escapedQuery( ) ../config.class.php:523 7 3.6776 2306568 DB_query( ) ../config.class.php:1752 8 3.6776 2306624 database->dbQuery( ) ../lib-database.php:208 9 3.6782 2306788 trigger_error ( ) ../mysql.class.php:260 The problem is with the "tab" column, which is new in 1.8.0. At the point of the failure, the database is at 1.5.0, i.e. it does have a conf_values table but without the "tab" column. Yet plugin_initconfig_calendar calls the Configuration's add() function with a valid value for $tab, so we try to write it to the db. Oops. I haven't had a good idea yet how to get around this. Anyone? bye, Dirk From websitemaster at cogeco.net Sat May 28 09:58:02 2011 From: websitemaster at cogeco.net (Tom) Date: Sat, 28 May 2011 09:58:02 -0400 Subject: [geeklog-devel] Upgrade bug in 1.8.0 In-Reply-To: References: Message-ID: <015301cc1d3f$42bb0640$c83112c0$@cogeco.net> The latest version of the Calendar plugin (and all the other core plugins) requires Geeklog 1.8.0 to run. The Geeklog database needs to be at 1.8.0 (just like the Geeklog code is) to run the 1.1.1 to 1.1.2 Calendar upgrade. (I haven't looked at the code yet) Doesn't migrate check the min Geeklog version required for the Calendar plugin in the autoinstall.php? Looking at plugin_compatible_with_this_version_calendar do we need to add if (!function_exists('COM_ versionCompare')) { // This function was introduced in Geeklog 1.8.0 return false; } So that the calendar upgrade is not run until the Geeklog DB is at version 1.8.0? Tom -----Original Message----- From: geeklog-devel-bounces at lists.geeklog.net [mailto:geeklog-devel-bounces at lists.geeklog.net] On Behalf Of Dirk Haun Sent: May-28-11 8:04 AM To: Geeklog Development Subject: [geeklog-devel] Upgrade bug in 1.8.0 Trying to reproduce someone's upgrade problems, I found an unrelated upgrade problem in 1.8.0: When you're upgrading from a pre-1.5.0 version, the plugin upgrades (e.g. for the Calendar) fail when trying to initialize the Configuration: Fatal error: 1054: Unknown column 'tab' in 'field list' in /geeklog/system/databases/mysql.class.php on line 260 Call Stack # Time Memory Function Location 1 0.0115 591372 {main}( ) ../migrate.php:0 2 0.1030 1373756 INST_doDatabaseUpgrades( ) ../migrate.php:784 3 3.6755 2265908 upgrade_CalendarPlugin( ) ../lib-upgrade.php:408 4 3.6771 2303464 plugin_initconfig_calendar( ) ../mysql_1.4.1_to_1.5.0.php:482 5 3.6774 2305140 config->add( ) ../install_defaults.php:147 6 3.6776 2306568 config->_DB_escapedQuery( ) ../config.class.php:523 7 3.6776 2306568 DB_query( ) ../config.class.php:1752 8 3.6776 2306624 database->dbQuery( ) ../lib-database.php:208 9 3.6782 2306788 trigger_error ( ) ../mysql.class.php:260 The problem is with the "tab" column, which is new in 1.8.0. At the point of the failure, the database is at 1.5.0, i.e. it does have a conf_values table but without the "tab" column. Yet plugin_initconfig_calendar calls the Configuration's add() function with a valid value for $tab, so we try to write it to the db. Oops. I haven't had a good idea yet how to get around this. Anyone? bye, Dirk _______________________________________________ geeklog-devel mailing list geeklog-devel at lists.geeklog.net http://eight.pairlist.net/mailman/listinfo/geeklog-devel From dirk at haun-online.de Sat May 28 11:51:24 2011 From: dirk at haun-online.de (Dirk Haun) Date: Sat, 28 May 2011 17:51:24 +0200 Subject: [geeklog-devel] Upgrade bug in 1.8.0 In-Reply-To: <015301cc1d3f$42bb0640$c83112c0$@cogeco.net> References: <015301cc1d3f$42bb0640$c83112c0$@cogeco.net> Message-ID: Tom wrote: > (I haven't looked at the code yet) Doesn't migrate check the min Geeklog > version required for the Calendar plugin in the autoinstall.php? There's a hard-coded upgrade_CalendarPlugin() call in lib-upgrade.php for the upgrade from 1.4.1 to 1.5.0 which triggers this. I guess if we decouple the upgrade process for the core plugins at that point and let it run at the end of the upgrade / migrate process - just like for non-core plugins - it should work. That requires extensive testing, though, since I'm not sure what else may lurk between 1.5.0 and 1.8.0 regarding plugin upgrades ... bye, Dirk P.S. Anyone else having DNS problems with geeklog.net (all subdomains) today? From websitemaster at cogeco.net Sat May 28 12:01:58 2011 From: websitemaster at cogeco.net (Tom) Date: Sat, 28 May 2011 12:01:58 -0400 Subject: [geeklog-devel] Upgrade bug in 1.8.0 In-Reply-To: References: <015301cc1d3f$42bb0640$c83112c0$@cogeco.net> Message-ID: <015d01cc1d50$93188a70$b9499f50$@cogeco.net> Nope, I have been on Geeklog.net and the bug tracker a few times throughout today without any problems. >> I guess if we decouple the upgrade process for the core plugins at that point and let it run at the end of the upgrade / migrate process - just like for non-core plugins - it should work. Sounds like the best solution to me (since that is also how the Plugin admin form works). The only other solution I thought of and quickly discarded was keeping track of the Geeklog versions that each plugin upgrade supports. Well, back to working on the forum plugin... Tom -----Original Message----- From: geeklog-devel-bounces at lists.geeklog.net [mailto:geeklog-devel-bounces at lists.geeklog.net] On Behalf Of Dirk Haun Sent: May-28-11 11:51 AM To: Geeklog Development Subject: Re: [geeklog-devel] Upgrade bug in 1.8.0 Tom wrote: > (I haven't looked at the code yet) Doesn't migrate check the min > Geeklog version required for the Calendar plugin in the autoinstall.php? There's a hard-coded upgrade_CalendarPlugin() call in lib-upgrade.php for the upgrade from 1.4.1 to 1.5.0 which triggers this. I guess if we decouple the upgrade process for the core plugins at that point and let it run at the end of the upgrade / migrate process - just like for non-core plugins - it should work. >though, since I'm not sure what else may lurk between 1.5.0 and 1.8.0 regarding plugin upgrades ... bye, Dirk P.S. Anyone else having DNS problems with geeklog.net (all subdomains) today? _______________________________________________ geeklog-devel mailing list geeklog-devel at lists.geeklog.net http://eight.pairlist.net/mailman/listinfo/geeklog-devel From dirk at haun-online.de Sun May 29 04:31:55 2011 From: dirk at haun-online.de (Dirk Haun) Date: Sun, 29 May 2011 10:31:55 +0200 Subject: [geeklog-devel] Upgrade bug in 1.8.0 In-Reply-To: References: <015301cc1d3f$42bb0640$c83112c0$@cogeco.net> Message-ID: > I guess if we decouple the upgrade process for the core plugins at that point and let it run at the end of the upgrade / migrate process - just like for non-core plugins - it should work. Speaking of migration: Why do we call PLG_migrate before PLG_upgrade? That doesn't seem to make sense. Ugh, this is getting nasty - so many "last minute" changes. I think we need an rc2. bye, Dirk From dirk at haun-online.de Sun May 29 04:35:03 2011 From: dirk at haun-online.de (Dirk Haun) Date: Sun, 29 May 2011 10:35:03 +0200 Subject: [geeklog-devel] Upgrade bug in 1.8.0 In-Reply-To: References: <015301cc1d3f$42bb0640$c83112c0$@cogeco.net> Message-ID: (replying to myself again) > Speaking of migration: Why do we call PLG_migrate before PLG_upgrade? That doesn't seem to make sense. Well, at least it's documented, so I guess it has to stay that way: http://wiki.geeklog.net/index.php/PLG_migrate bye, Dirk From rouslan at placella.com Sun May 29 08:49:41 2011 From: rouslan at placella.com (Rouslan Placella) Date: Sun, 29 May 2011 13:49:41 +0100 Subject: [geeklog-devel] Upgrade bug in 1.8.0 In-Reply-To: References: <015301cc1d3f$42bb0640$c83112c0$@cogeco.net> Message-ID: <1306673381.2218.7.camel@roccivic-pc> I think that it does make sense. Looks like you could be running the upgrade off a broken plugin, if you run the upgrade before the migrate. Rouslan On Sun, 2011-05-29 at 10:35 +0200, Dirk Haun wrote: > (replying to myself again) > > > Speaking of migration: Why do we call PLG_migrate before PLG_upgrade? That doesn't seem to make sense. > > Well, at least it's documented, so I guess it has to stay that way: http://wiki.geeklog.net/index.php/PLG_migrate > > bye, Dirk > > _______________________________________________ > geeklog-devel mailing list > geeklog-devel at lists.geeklog.net > http://eight.pairlist.net/mailman/listinfo/geeklog-devel From dirk at haun-online.de Sun May 29 10:02:01 2011 From: dirk at haun-online.de (Dirk Haun) Date: Sun, 29 May 2011 16:02:01 +0200 Subject: [geeklog-devel] Upgrade bug in 1.8.0 In-Reply-To: <1306673381.2218.7.camel@roccivic-pc> References: <015301cc1d3f$42bb0640$c83112c0$@cogeco.net> <1306673381.2218.7.camel@roccivic-pc> Message-ID: Rouslan Placella wrote: > I think that it does make sense. Looks like you could be running the > upgrade off a broken plugin, if you run the upgrade before the migrate. Yeah, there must be a reason why we did it this way around - I just can't remember it. With the changes I'm currently making, the Polls plugin tried to migrate a table that didn't exist. That's what triggered my suspicion that it was the wrong way around. bye, Dirk From websitemaster at cogeco.net Sun May 29 10:16:48 2011 From: websitemaster at cogeco.net (Tom) Date: Sun, 29 May 2011 10:16:48 -0400 Subject: [geeklog-devel] Upgrade bug in 1.8.0 In-Reply-To: References: <015301cc1d3f$42bb0640$c83112c0$@cogeco.net> Message-ID: <018d01cc1e0b$0ca6bff0$25f43fd0$@cogeco.net> >> Ugh, this is getting nasty - so many "last minute" changes. I think we need an rc2. I hate to do it especially with something that shouldn't effect most people but from the amount of code changes you indicate it will probably be for the best. -----Original Message----- From: geeklog-devel-bounces at lists.geeklog.net [mailto:geeklog-devel-bounces at lists.geeklog.net] On Behalf Of Dirk Haun Sent: May-29-11 4:32 AM To: Geeklog Development Subject: Re: [geeklog-devel] Upgrade bug in 1.8.0 > I guess if we decouple the upgrade process for the core plugins at that point and let it run at the end of the upgrade / migrate process - just like for non-core plugins - it should work. Speaking of migration: Why do we call PLG_migrate before PLG_upgrade? That doesn't seem to make sense. Ugh, this is getting nasty - so many "last minute" changes. I think we need an rc2. bye, Dirk _______________________________________________ geeklog-devel mailing list geeklog-devel at lists.geeklog.net http://eight.pairlist.net/mailman/listinfo/geeklog-devel From dirk at haun-online.de Sun May 29 14:24:59 2011 From: dirk at haun-online.de (Dirk Haun) Date: Sun, 29 May 2011 20:24:59 +0200 Subject: [geeklog-devel] Upgrade bug in 1.8.0 In-Reply-To: <018d01cc1e0b$0ca6bff0$25f43fd0$@cogeco.net> References: <015301cc1d3f$42bb0640$c83112c0$@cogeco.net> <018d01cc1e0b$0ca6bff0$25f43fd0$@cogeco.net> Message-ID: <095D644C-A833-49D4-8C8D-CB0315FAE6AC@haun-online.de> Tom wrote: > I hate to do it especially with something that shouldn't effect most people > but from the amount of code changes you indicate it will probably be for the > best. Okay, I think I did it. And yes, it required quite a few code changes: added 4 changesets with 30 changes to 21 files 21 files updated, 0 files merged, 2 files removed, 0 files unresolved I'm going to test the upgrade some more with every backup file I can find. Can someone please test it with MS SQL? Thanks. bye, Dirk From websitemaster at cogeco.net Sun May 29 14:29:42 2011 From: websitemaster at cogeco.net (Tom) Date: Sun, 29 May 2011 14:29:42 -0400 Subject: [geeklog-devel] Upgrade bug in 1.8.0 In-Reply-To: <095D644C-A833-49D4-8C8D-CB0315FAE6AC@haun-online.de> References: <015301cc1d3f$42bb0640$c83112c0$@cogeco.net> <018d01cc1e0b$0ca6bff0$25f43fd0$@cogeco.net> <095D644C-A833-49D4-8C8D-CB0315FAE6AC@haun-online.de> Message-ID: <019301cc1e2e$60801f40$21805dc0$@cogeco.net> I do not have MS SQL but I will test the MySQL upgrade/migrate with a few older DB backups I have. Tom -----Original Message----- From: geeklog-devel-bounces at lists.geeklog.net [mailto:geeklog-devel-bounces at lists.geeklog.net] On Behalf Of Dirk Haun Sent: May-29-11 2:25 PM To: Geeklog Development Subject: Re: [geeklog-devel] Upgrade bug in 1.8.0 Tom wrote: > I hate to do it especially with something that shouldn't effect most > people but from the amount of code changes you indicate it will > probably be for the best. Okay, I think I did it. And yes, it required quite a few code changes: added 4 changesets with 30 changes to 21 files 21 files updated, 0 files merged, 2 files removed, 0 files unresolved I'm going to test the upgrade some more with every backup file I can find. Can someone please test it with MS SQL? Thanks. bye, Dirk _______________________________________________ geeklog-devel mailing list geeklog-devel at lists.geeklog.net http://eight.pairlist.net/mailman/listinfo/geeklog-devel From dirk at haun-online.de Mon May 30 14:32:40 2011 From: dirk at haun-online.de (Dirk Haun) Date: Mon, 30 May 2011 20:32:40 +0200 Subject: [geeklog-devel] [geeklog-cvs] geeklog: Fixed entries that should not be translated or changed In-Reply-To: References: Message-ID: <88499B15-F340-4E1A-9BC9-C1FB51D23BD9@haun-online.de> > description: > Fixed entries that should not be translated or changed I ran into similar entries in the German language files yesterday. Since I suspected that other translators may have made the same mistake, I've now added some unit tests that check $_CONF_VALIDATE 'inList' entries that are non-numerical against the entries from $LANG_configselects for Core and the plugins for all language files. So if something doesn't match up there, the tests will fail. This only added 8 tests to our small unit test suite, but it does over 4000 checks. http://project.geeklog.net:8080/job/test-framework/lastCompletedBuild/testReport/ Our unit test setup currently only works for code that does not require a database. Still, that allows you to check things like the above. So I'd like to encourage everyone to try and think of a way to write a unit test for your next change you make to Geeklog. bye, Dirk