From vfuria at gmail.com Fri Sep 2 02:16:57 2011 From: vfuria at gmail.com (Vincent Furia) Date: Fri, 2 Sep 2011 00:16:57 -0600 Subject: [geeklog-devel] Bug Confirmation Message-ID: Can someone confirm the following bug in 1.8.0: 1. Go to the user admin screen. 2. Select a user to edit 3. Modify one field (not the password fields, leave those blank) such as "email address" 4. Click "save" 5. Check if the "passwd" field in the database for that user is now empty. If so, I found a bug (and didn't somehow create it). Let me know and I'll throw it in the bug tracker. I can probably fix it myself since I'm working in that code now. Thanks, Vinny -------------- next part -------------- An HTML attachment was scrubbed... URL: From dirk at haun-online.de Sun Sep 4 15:57:12 2011 From: dirk at haun-online.de (Dirk Haun) Date: Sun, 4 Sep 2011 21:57:12 +0200 Subject: [geeklog-devel] 1.8.1 In-Reply-To: <312E4896-7DC1-4197-A1CB-0806E1151F0D@haun-online.de> References: <20110624133138.9164384jmqc7tuas@webmail.df.eu> <1308916307.1804.8.camel@roccivic-pc> <025901cc3267$570753a0$0515fae0$@cogeco.net> <20110624164720.9052387slu8vhl0k@webmail.df.eu> <312E4896-7DC1-4197-A1CB-0806E1151F0D@haun-online.de> Message-ID: > I'd shoot for a 1.8.1rc1 next weekend then. FYI: I ran into a few quirks with the release process. This was the first attempt to do the automated release for a version on a branch and it didn't quite work as expected. There is now a 1.8.1rc1 tarball up on geeklog.net[1] but I haven't had a chance to check it, upgrade the site, or write a release announcement. I'll try to squeeze that in tomorrow, but it may as well take until Tuesday ? bye, Dirk [1] unofficial(!) tarball: http://www.geeklog.net/nightly/geeklog-1.8.1rc1.tar.gz From websitemaster at cogeco.net Sun Sep 4 18:25:00 2011 From: websitemaster at cogeco.net (Tom) Date: Sun, 4 Sep 2011 18:25:00 -0400 Subject: [geeklog-devel] Bug Confirmation In-Reply-To: References: Message-ID: <006601cc6b51$7cfa8e60$76efab20$@cogeco.net> Sorry I have been away for the most of last week so I couldn't check on this. I was able to reproduce this error following your instructions on a Geeklog 1.8.0 site. Tom From: geeklog-devel-bounces at lists.geeklog.net [mailto:geeklog-devel-bounces at lists.geeklog.net] On Behalf Of Vincent Furia Sent: September-02-11 2:17 AM To: Geeklog Subject: [geeklog-devel] Bug Confirmation Can someone confirm the following bug in 1.8.0: 1. Go to the user admin screen. 2. Select a user to edit 3. Modify one field (not the password fields, leave those blank) such as "email address" 4. Click "save" 5. Check if the "passwd" field in the database for that user is now empty. If so, I found a bug (and didn't somehow create it). Let me know and I'll throw it in the bug tracker. I can probably fix it myself since I'm working in that code now. Thanks, Vinny -------------- next part -------------- An HTML attachment was scrubbed... URL: From cordiste at free.fr Mon Sep 5 09:29:15 2011 From: cordiste at free.fr (cordiste) Date: Mon, 5 Sep 2011 15:29:15 +0200 Subject: [geeklog-devel] 1.8.1 In-Reply-To: References: <20110624133138.9164384jmqc7tuas@webmail.df.eu> <1308916307.1804.8.camel@roccivic-pc> <025901cc3267$570753a0$0515fae0$@cogeco.net> <20110624164720.9052387slu8vhl0k@webmail.df.eu> <312E4896-7DC1-4197-A1CB-0806E1151F0D@haun-online.de> Message-ID: Is there any theme or language changes in Geeklog 1.8.1? Ben 2011/9/4 Dirk Haun > > > I'd shoot for a 1.8.1rc1 next weekend then. > > FYI: I ran into a few quirks with the release process. This was the first attempt to do the automated release for a version on a branch and it didn't quite work as expected. > > There is now a 1.8.1rc1 tarball up on geeklog.net[1] but I haven't had a chance to check it, upgrade the site, or write a release announcement. I'll try to squeeze that in tomorrow, but it may as well take until Tuesday ? > > bye, Dirk > > [1] unofficial(!) tarball: http://www.geeklog.net/nightly/geeklog-1.8.1rc1.tar.gz > > _______________________________________________ > geeklog-devel mailing list > geeklog-devel at lists.geeklog.net > http://eight.pairlist.net/mailman/listinfo/geeklog-devel > From vfuria at gmail.com Mon Sep 5 17:54:13 2011 From: vfuria at gmail.com (Vincent Furia) Date: Mon, 5 Sep 2011 15:54:13 -0600 Subject: [geeklog-devel] Bug Confirmation In-Reply-To: <006601cc6b51$7cfa8e60$76efab20$@cogeco.net> References: <006601cc6b51$7cfa8e60$76efab20$@cogeco.net> Message-ID: Thanks Tony, I'll submit the bug report fix the bug. I probably won't get in for 1.8.1. -Vinny On Sun, Sep 4, 2011 at 16:25, Tom wrote: > Sorry I have been away for the most of last week so I couldn?t check on > this.**** > > ** ** > > I was able to reproduce this error following your instructions on a Geeklog > 1.8.0 site.**** > > ** ** > > Tom**** > > ** ** > > *From:* geeklog-devel-bounces at lists.geeklog.net [mailto: > geeklog-devel-bounces at lists.geeklog.net] *On Behalf Of *Vincent Furia > *Sent:* September-02-11 2:17 AM > *To:* Geeklog > *Subject:* [geeklog-devel] Bug Confirmation**** > > ** ** > > Can someone confirm the following bug in 1.8.0:**** > > 1. Go to the user admin screen. **** > 2. Select a user to edit**** > 3. Modify one field (not the password fields, leave those blank) such > as "email address"**** > 4. Click "save"**** > 5. Check if the "passwd" field in the database for that user is now > empty.**** > > If so, I found a bug (and didn't somehow create it). Let me know and I'll > throw it in the bug tracker. I can probably fix it myself since I'm working > in that code now.**** > > ** ** > > Thanks,**** > > Vinny**** > > _______________________________________________ > 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 websitemaster at cogeco.net Mon Sep 5 18:03:09 2011 From: websitemaster at cogeco.net (Tom) Date: Mon, 5 Sep 2011 18:03:09 -0400 Subject: [geeklog-devel] 1.8.1 In-Reply-To: References: <20110624133138.9164384jmqc7tuas@webmail.df.eu> <1308916307.1804.8.camel@roccivic-pc> <025901cc3267$570753a0$0515fae0$@cogeco.net> <20110624164720.9052387slu8vhl0k@webmail.df.eu> <312E4896-7DC1-4197-A1CB-0806E1151F0D@haun-online.de> Message-ID: <009801cc6c17$98ee1850$caca48f0$@cogeco.net> There may be if I update jQuery UI (it would be just the css files). So is everyone okay if I go ahead and update jQuery and jQuery UI to the latest versions for Geeklog 1.8.1? Tom -----Original Message----- From: geeklog-devel-bounces at lists.geeklog.net [mailto:geeklog-devel-bounces at lists.geeklog.net] On Behalf Of cordiste Sent: September-05-11 9:29 AM To: Geeklog Development Subject: Re: [geeklog-devel] 1.8.1 Is there any theme or language changes in Geeklog 1.8.1? Ben 2011/9/4 Dirk Haun > > > I'd shoot for a 1.8.1rc1 next weekend then. > > FYI: I ran into a few quirks with the release process. This was the first attempt to do the automated release for a version on a branch and it didn't quite work as expected. > > There is now a 1.8.1rc1 tarball up on geeklog.net[1] but I haven't had a chance to check it, upgrade the site, or write a release announcement. I'll try to squeeze that in tomorrow, but it may as well take until Tuesday . > > bye, Dirk > > [1] unofficial(!) tarball: http://www.geeklog.net/nightly/geeklog-1.8.1rc1.tar.gz > > _______________________________________________ > 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 websitemaster at cogeco.net Mon Sep 5 18:03:51 2011 From: websitemaster at cogeco.net (Tom) Date: Mon, 5 Sep 2011 18:03:51 -0400 Subject: [geeklog-devel] Bug Confirmation In-Reply-To: References: <006601cc6b51$7cfa8e60$76efab20$@cogeco.net> Message-ID: <009901cc6c17$b24c6360$16e52a20$@cogeco.net> I missed your email. I just added the bug report http://project.geeklog.net/tracking/view.php?id=1385 Tom From: geeklog-devel-bounces at lists.geeklog.net [mailto:geeklog-devel-bounces at lists.geeklog.net] On Behalf Of Vincent Furia Sent: September-05-11 5:54 PM To: Geeklog Development Subject: Re: [geeklog-devel] Bug Confirmation Thanks Tony, I'll submit the bug report fix the bug. I probably won't get in for 1.8.1. -Vinny On Sun, Sep 4, 2011 at 16:25, Tom wrote: Sorry I have been away for the most of last week so I couldn't check on this. I was able to reproduce this error following your instructions on a Geeklog 1.8.0 site. Tom From: geeklog-devel-bounces at lists.geeklog.net [mailto:geeklog-devel-bounces at lists.geeklog.net] On Behalf Of Vincent Furia Sent: September-02-11 2:17 AM To: Geeklog Subject: [geeklog-devel] Bug Confirmation Can someone confirm the following bug in 1.8.0: 1. Go to the user admin screen. 2. Select a user to edit 3. Modify one field (not the password fields, leave those blank) such as "email address" 4. Click "save" 5. Check if the "passwd" field in the database for that user is now empty. If so, I found a bug (and didn't somehow create it). Let me know and I'll throw it in the bug tracker. I can probably fix it myself since I'm working in that code now. Thanks, Vinny _______________________________________________ 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 vfuria at gmail.com Mon Sep 5 18:07:27 2011 From: vfuria at gmail.com (Vincent Furia) Date: Mon, 5 Sep 2011 16:07:27 -0600 Subject: [geeklog-devel] Bug Confirmation In-Reply-To: <009901cc6c17$b24c6360$16e52a20$@cogeco.net> References: <006601cc6b51$7cfa8e60$76efab20$@cogeco.net> <009901cc6c17$b24c6360$16e52a20$@cogeco.net> Message-ID: No problem, I just assigned the bug you made to myself. On Mon, Sep 5, 2011 at 16:03, Tom wrote: > I missed your email. I just added the bug report > http://project.geeklog.net/tracking/view.php?id=1385**** > > ** ** > > Tom**** > > ** ** > > *From:* geeklog-devel-bounces at lists.geeklog.net [mailto: > geeklog-devel-bounces at lists.geeklog.net] *On Behalf Of *Vincent Furia > *Sent:* September-05-11 5:54 PM > *To:* Geeklog Development > *Subject:* Re: [geeklog-devel] Bug Confirmation**** > > ** ** > > Thanks Tony, I'll submit the bug report fix the bug. I probably won't get > in for 1.8.1.**** > > ** ** > > -Vinny**** > > On Sun, Sep 4, 2011 at 16:25, Tom wrote:**** > > Sorry I have been away for the most of last week so I couldn?t check on > this.**** > > **** > > I was able to reproduce this error following your instructions on a Geeklog > 1.8.0 site.**** > > **** > > Tom**** > > **** > > *From:* geeklog-devel-bounces at lists.geeklog.net [mailto: > geeklog-devel-bounces at lists.geeklog.net] *On Behalf Of *Vincent Furia > *Sent:* September-02-11 2:17 AM > *To:* Geeklog > *Subject:* [geeklog-devel] Bug Confirmation**** > > **** > > Can someone confirm the following bug in 1.8.0:**** > > 1. Go to the user admin screen. **** > 2. Select a user to edit**** > 3. Modify one field (not the password fields, leave those blank) such > as "email address"**** > 4. Click "save"**** > 5. Check if the "passwd" field in the database for that user is now > empty.**** > > If so, I found a bug (and didn't somehow create it). Let me know and I'll > throw it in the bug tracker. I can probably fix it myself since I'm working > in that code now.**** > > **** > > Thanks,**** > > Vinny**** > > > _______________________________________________ > 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 dirk at haun-online.de Tue Sep 6 01:57:58 2011 From: dirk at haun-online.de (Dirk Haun) Date: Tue, 6 Sep 2011 07:57:58 +0200 Subject: [geeklog-devel] 1.8.1 In-Reply-To: <009801cc6c17$98ee1850$caca48f0$@cogeco.net> References: <20110624133138.9164384jmqc7tuas@webmail.df.eu> <1308916307.1804.8.camel@roccivic-pc> <025901cc3267$570753a0$0515fae0$@cogeco.net> <20110624164720.9052387slu8vhl0k@webmail.df.eu> <312E4896-7DC1-4197-A1CB-0806E1151F0D@haun-online.de> <009801cc6c17$98ee1850$caca48f0$@cogeco.net> Message-ID: <7554C68E-0B1D-4636-BE78-5B7AF4A8781B@haun-online.de> Tom wrote: > So is everyone okay if I go ahead and update jQuery and jQuery UI to the > latest versions for Geeklog 1.8.1? I'd rather keep 1.8.1 a "painless" update - so no theme, language file, or db changes, please, if possible. bye, Dirk From dirk at haun-online.de Tue Sep 6 01:56:30 2011 From: dirk at haun-online.de (Dirk Haun) Date: Tue, 6 Sep 2011 07:56:30 +0200 Subject: [geeklog-devel] Bug Confirmation In-Reply-To: <009901cc6c17$b24c6360$16e52a20$@cogeco.net> References: <006601cc6b51$7cfa8e60$76efab20$@cogeco.net> <009901cc6c17$b24c6360$16e52a20$@cogeco.net> Message-ID: Tom wrote: > I missed your email. I just added the bug report http://project.geeklog.net/tracking/view.php?id=1385 Did anyone check that with 1.8.1? I made some changes in the user editor to make it keep information you entered even when an error occured (e.g. you forgot to fill out a required field). Not sure if it's related, but maybe I accidentally fixed it already (probably not). bye, Dirk From websitemaster at cogeco.net Tue Sep 6 10:10:35 2011 From: websitemaster at cogeco.net (Tom) Date: Tue, 6 Sep 2011 10:10:35 -0400 Subject: [geeklog-devel] 1.8.1 In-Reply-To: <7554C68E-0B1D-4636-BE78-5B7AF4A8781B@haun-online.de> References: <20110624133138.9164384jmqc7tuas@webmail.df.eu> <1308916307.1804.8.camel@roccivic-pc> <025901cc3267$570753a0$0515fae0$@cogeco.net> <20110624164720.9052387slu8vhl0k@webmail.df.eu> <312E4896-7DC1-4197-A1CB-0806E1151F0D@haun-online.de> <009801cc6c17$98ee1850$caca48f0$@cogeco.net> <7554C68E-0B1D-4636-BE78-5B7AF4A8781B@haun-online.de> Message-ID: <00e001cc6c9e$bf687bb0$3e397310$@cogeco.net> Okay then I will update just jQuery and make sure it all works fine with the older version of jQuery UI. I will also double check the user admin bug for 1.8.1. 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: September-06-11 1:58 AM To: Geeklog Development Subject: Re: [geeklog-devel] 1.8.1 Tom wrote: > So is everyone okay if I go ahead and update jQuery and jQuery UI to > the latest versions for Geeklog 1.8.1? I'd rather keep 1.8.1 a "painless" update - so no theme, language file, or db changes, please, if possible. 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 Tue Sep 6 13:44:18 2011 From: dirk at haun-online.de (Dirk Haun) Date: Tue, 6 Sep 2011 19:44:18 +0200 Subject: [geeklog-devel] 1.8.1 In-Reply-To: <00e001cc6c9e$bf687bb0$3e397310$@cogeco.net> References: <20110624133138.9164384jmqc7tuas@webmail.df.eu> <1308916307.1804.8.camel@roccivic-pc> <025901cc3267$570753a0$0515fae0$@cogeco.net> <20110624164720.9052387slu8vhl0k@webmail.df.eu> <312E4896-7DC1-4197-A1CB-0806E1151F0D@haun-online.de> <009801cc6c17$98ee1850$caca48f0$@cogeco.net> <7554C68E-0B1D-4636-BE78-5B7AF4A8781B@haun-online.de> <00e001cc6c9e$bf687bb0$3e397310$@cogeco.net> Message-ID: <74018DD2-E2D2-4B87-B0C2-18EC213AD460@haun-online.de> Okay, sounds like we have a few things to sort out first. So let's delay the 1.8.1rc1 release to sort this all out. In the meantime, I'll install the Mantis security update that just came out. bye, Dirk From websitemaster at cogeco.net Thu Sep 8 21:27:55 2011 From: websitemaster at cogeco.net (Tom) Date: Thu, 8 Sep 2011 21:27:55 -0400 Subject: [geeklog-devel] Geeklog Topics and Blocks In-Reply-To: <017101cc612d$431a9560$c94fc020$@cogeco.net> References: <00a601cc6041$5a33b2a0$0e9b17e0$@cogeco.net> <011301cc60cf$648b76a0$2da263e0$@cogeco.net> <017101cc612d$431a9560$c94fc020$@cogeco.net> Message-ID: <019101cc6e8f$b3503aa0$19f0afe0$@cogeco.net> 1. COM_showBlocks will have to be modified to handle a topic array as well as a single topic. Most calling functions to COM_showBlocks functions will also need to be modified to handle multiple topics. Hey Vinny, Why are you saying here that most calling functions to COM_showBlocks needs to handle multiple topics? The user will still be only viewing one topic at a time so only one topic will still need to be passed into the function. I will just have to update the function to take into account the new topic_assiginments table and the fact that blocks can appear in 1 or more topics. Tom From: geeklog-devel-bounces at lists.geeklog.net [mailto:geeklog-devel-bounces at lists.geeklog.net] On Behalf Of Tom Sent: August-22-11 8:41 PM To: 'Geeklog Development' Subject: Re: [geeklog-devel] Geeklog Topics and Blocks You covered most of my points but I hadn't thought of 5, 6 and 9. 5. I would probably leave this as a feed for articles only and not other types since clicking on a topic itself would still only display articles. 6. Handling of featured topic articles. I guess the first question would be is should an article be allowed to be featured for only one topic or many topics. If it is many then either we will need a new table or I will have to add a column to topic_assignments Tom From: geeklog-devel-bounces at lists.geeklog.net [mailto:geeklog-devel-bounces at lists.geeklog.net] On Behalf Of Vincent Furia Sent: August-22-11 5:06 PM To: Geeklog Development Subject: Re: [geeklog-devel] Geeklog Topics and Blocks First the easy part. Defining the tables: 1. Remove 'tid' from the story table. 2. Create a new table "topic_assignments". It should have columns "type" varchar(30), "sid" varchar(40), and "tid" varchar(20). It's primary key should be on "tid" and with a INDEX on "type" and "sid" (this key could also just be on sid). 3. The topics table is sufficient as is, though that depends on the full set of features you want to change. The underlying code changes get complicated. Here is what I recall looking at originally, though I'm sure there is more that will have to be modified to incorporate the changes. Since you're implementation allows a single article (or other item) to be belong to multiple topics, you're changes are going to be more extensive than what I had looked at. At a minimum you're going to want to look at lib-common.php, article.php, and lib-security.php. 1. COM_siteHeader may need some mods to recognize when you are looking at plugin/block/etc that is associated with a specific topic. Also, COM_siteFooter. 2. COM_showBlocks will have to be modified to handle a topic array as well as a single topic. Most calling functions to COM_showBlocks functions will also need to be modified to handle multiple topics. 3. COM_topicArray will have to understand the new underlying database structure. 4. SEC_hasTopicAccess probably doesn't need to change, but keep an eye on it. 5. COM_rdfUpToDateCheck will need to be expanded to handle topic feed updates for non-article types. 6. COM_featuredCheck assumes tid will be in the article table. You'll also have to figure out how you want to handle featured article flag on stories with multiple topics, this could get really confusing if not taken into account at the start. 7. COM_adminMenu will need to handle topic assignments. Again, it assumes tid in the article table. 8. Everywhere COM_getTopicSQL is called will need to be rethought (and the function itself will probably go away). That code currently generates an "IN" clause against the tid in the article table. All queries that use it will have to do a double join to the topics table and topic_assignments table. I imagine this is where A LOT of the work for this project will be invested. 9. COM_emailUserTopics will need some mods since you don't want the informational email to repeat articles. Also, you might want to add a plugin API for plugin items be included in topic emails. 10. Obviously a new interface will be required to submit/administer articles with multiple topics. Some generic functions here will make it easy to add topic support to other plugins. 11. Webservices may be impacted, though I haven't looked at that code at all to even make an educated guess as to how much (or even if they would be impacted). 12. I think story.class.php will require extensive modifications, though it didn't exist when I first looked into modifying topics. I'm sure my notes on article.php are useless for the same reason... That should get you started. It's a pretty big undertaking. You might want to reconsider implementing subtopics, with all the work needed already the extra cost wouldn't be great (though I do understand your desire to limit the scope at least a little bit). It's a shame we didn't do GSOC this year, this probably would have made a great project for a summer intern... -Vinny On Mon, Aug 22, 2011 at 07:28, Tom wrote: >Any change that modified the database would require quite a bit of work (as my suggestion in the first paragraph would). If you end up going with any of these ideas, I had >thought out quite a bit more detail if you want it. Sure. J From: geeklog-devel-bounces at lists.geeklog.net [mailto:geeklog-devel-bounces at lists.geeklog.net] On Behalf Of Vincent Furia Sent: August-21-11 7:20 PM To: Geeklog Development Subject: Re: [geeklog-devel] Geeklog Topics and Blocks I had done some thinking on this several years ago. The most flexible design I came up with is using "tag" style backend. Instead of having tid's associated with stories, there would be topic_assignments (or some better named...) table allowing a many-to-many relationship between stories (or blocks, or plugins, etc) and topics. I went so far as to also consider how to handle sub-topics. Easy way: you could define topic relationships by having a topic separator (e.g. "-" or "/") in the topic name. Hard way: create a hierarchal data structure in the database (parent child relationship, or tree representation similar to how comments are not handled). The latter design would allow more flexibility, though the former would be significantly less work to implement. Any change that modified the database would require quite a bit of work (as my suggestion in the first paragraph would). If you end up going with any of these ideas, I had thought out quite a bit more detail if you want it. -Vinny On Sun, Aug 21, 2011 at 14:31, Tom wrote: I have started to do a bit of research/work on my feature request about allowing topics to be associated with other objects like staticpages, etc. http://project.geeklog.net/tracking/view.php?id=1155 I was also thinking about (I haven't decided to tackle it yet): - Allowing blocks to be assigned to one or more topics and not just one or all. - Allowing stories (and other objects) to be assigned to one or more topics. Does anyone have any thoughts or opinions... Tom _______________________________________________ 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 vfuria at gmail.com Fri Sep 9 03:56:45 2011 From: vfuria at gmail.com (Vincent Furia) Date: Fri, 9 Sep 2011 01:56:45 -0600 Subject: [geeklog-devel] Geeklog Topics and Blocks In-Reply-To: <019101cc6e8f$b3503aa0$19f0afe0$@cogeco.net> References: <00a601cc6041$5a33b2a0$0e9b17e0$@cogeco.net> <011301cc60cf$648b76a0$2da263e0$@cogeco.net> <017101cc612d$431a9560$c94fc020$@cogeco.net> <019101cc6e8f$b3503aa0$19f0afe0$@cogeco.net> Message-ID: I believe the use case I was thinking of is when viewing a single story/article that is a member of several topics. On Thu, Sep 8, 2011 at 19:27, Tom wrote: > > 1. COM_showBlocks will have to be modified to handle a topic array as > well as a single topic. Most calling functions to COM_showBlocks functions > will also need to be modified to handle multiple topics.**** > > Hey Vinny,**** > > ** ** > > Why are you saying here that most calling functions to COM_showBlocks needs > to handle multiple topics? The user will still be only viewing one topic at > a time so only one topic will still need to be passed into the function. I > will just have to update the function to take into account the new > topic_assiginments table and the fact that blocks can appear in 1 or more > topics.**** > > ** ** > > Tom**** > > ** ** > > ** ** > > *From:* geeklog-devel-bounces at lists.geeklog.net [mailto: > geeklog-devel-bounces at lists.geeklog.net] *On Behalf Of *Tom > *Sent:* August-22-11 8:41 PM > > *To:* 'Geeklog Development' > *Subject:* Re: [geeklog-devel] Geeklog Topics and Blocks**** > > ** ** > > You covered most of my points but I hadn?t thought of 5, 6 and 9.**** > > ** ** > > 5. I would probably leave this as a feed for articles only and not other > types since clicking on a topic itself would still only display articles. > **** > > 6. Handling of featured topic articles? I guess the first question would be > is should an article be allowed to be featured for only one topic or many > topics. If it is many then either we will need a new table or I will have to > add a column to topic_assignments**** > > ** ** > > Tom**** > > ** ** > > *From:* geeklog-devel-bounces at lists.geeklog.net > [mailto:geeklog-devel-bounces at lists.geeklog.net] *On Behalf Of *Vincent > Furia > *Sent:* August-22-11 5:06 PM > *To:* Geeklog Development > *Subject:* Re: [geeklog-devel] Geeklog Topics and Blocks**** > > ** ** > > First the easy part. Defining the tables:**** > > 1. Remove 'tid' from the story table.**** > 2. Create a new table "topic_assignments". It should have columns > "type" varchar(30), "sid" varchar(40), and "tid" varchar(20). It's primary > key should be on "tid" and with a INDEX on "type" and "sid" (this key could > also just be on sid).**** > 3. The topics table is sufficient as is, though that depends on the > full set of features you want to change.**** > > The underlying code changes get complicated. Here is what I recall looking > at originally, though I'm sure there is more that will have to be modified > to incorporate the changes. Since you're implementation allows a single > article (or other item) to be belong to multiple topics, you're changes are > going to be more extensive than what I had looked at. At a minimum you're > going to want to look at lib-common.php, article.php, and lib-security.php. > **** > > 1. COM_siteHeader may need some mods to recognize when you are looking > at plugin/block/etc that is associated with a specific topic. Also, > COM_siteFooter.**** > 2. COM_showBlocks will have to be modified to handle a topic array as > well as a single topic. Most calling functions to COM_showBlocks functions > will also need to be modified to handle multiple topics.**** > 3. COM_topicArray will have to understand the new underlying database > structure.**** > 4. SEC_hasTopicAccess probably doesn't need to change, but keep an eye > on it.**** > 5. COM_rdfUpToDateCheck will need to be expanded to handle topic feed > updates for non-article types.**** > 6. COM_featuredCheck assumes tid will be in the article table. You'll > also have to figure out how you want to handle featured article flag on > stories with multiple topics, this could get really confusing if not taken > into account at the start.**** > 7. COM_adminMenu will need to handle topic assignments. Again, it > assumes tid in the article table.**** > 8. Everywhere COM_getTopicSQL is called will need to be rethought (and > the function itself will probably go away). That code currently generates an > "IN" clause against the tid in the article table. All queries that use it > will have to do a double join to the topics table and topic_assignments > table. I imagine this is where A LOT of the work for this project will be > invested.**** > 9. COM_emailUserTopics will need some mods since you don't want the > informational email to repeat articles. Also, you might want to add a plugin > API for plugin items be included in topic emails.**** > 10. Obviously a new interface will be required to submit/administer > articles with multiple topics. Some generic functions here will make it easy > to add topic support to other plugins.**** > 11. Webservices may be impacted, though I haven't looked at that code > at all to even make an educated guess as to how much (or even if they would > be impacted).**** > 12. I think story.class.php will require extensive modifications, > though it didn't exist when I first looked into modifying topics. I'm sure > my notes on article.php are useless for the same reason...**** > > That should get you started. It's a pretty big undertaking. You might want > to reconsider implementing subtopics, with all the work needed already the > extra cost wouldn't be great (though I do understand your desire to limit > the scope at least a little bit). > > It's a shame we didn't do GSOC this year, this probably would have made a > great project for a summer intern... > > -Vinny**** > > On Mon, Aug 22, 2011 at 07:28, Tom wrote:**** > > >Any change that modified the database would require quite a bit of work > (as my suggestion in the first paragraph would). If you end up going with > any of these ideas, I had >thought out quite a bit more detail if you want > it.**** > > **** > > Sure. J**** > > **** > > **** > > *From:* geeklog-devel-bounces at lists.geeklog.net [mailto: > geeklog-devel-bounces at lists.geeklog.net] *On Behalf Of *Vincent Furia > *Sent:* August-21-11 7:20 PM > *To:* Geeklog Development > *Subject:* Re: [geeklog-devel] Geeklog Topics and Blocks**** > > **** > > I had done some thinking on this several years ago. The most flexible > design I came up with is using "tag" style backend. Instead of having tid's > associated with stories, there would be topic_assignments (or some better > named...) table allowing a many-to-many relationship between stories (or > blocks, or plugins, etc) and topics.**** > > **** > > I went so far as to also consider how to handle sub-topics. Easy way: you > could define topic relationships by having a topic separator (e.g. "-" or > "/") in the topic name. Hard way: create a hierarchal data structure in the > database (parent child relationship, or tree representation similar to how > comments are not handled). The latter design would allow more flexibility, > though the former would be significantly less work to implement.**** > > **** > > Any change that modified the database would require quite a bit of work (as > my suggestion in the first paragraph would). If you end up going with any of > these ideas, I had thought out quite a bit more detail if you want it.**** > > **** > > -Vinny**** > > **** > > On Sun, Aug 21, 2011 at 14:31, Tom wrote:**** > > I have started to do a bit of research/work on my feature request about > allowing topics to be associated with other objects like staticpages, etc. > > http://project.geeklog.net/tracking/view.php?id=1155 > > I was also thinking about (I haven't decided to tackle it yet): > > - Allowing blocks to be assigned to one or more topics and not just one or > all. > - Allowing stories (and other objects) to be assigned to one or more > topics. > > Does anyone have any thoughts or opinions... > > Tom > > _______________________________________________ > 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**** > > ** ** > > _______________________________________________ > 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 websitemaster at cogeco.net Fri Sep 9 09:21:47 2011 From: websitemaster at cogeco.net (Tom) Date: Fri, 9 Sep 2011 09:21:47 -0400 Subject: [geeklog-devel] Geeklog Topics and Blocks In-Reply-To: References: <00a601cc6041$5a33b2a0$0e9b17e0$@cogeco.net> <011301cc60cf$648b76a0$2da263e0$@cogeco.net> <017101cc612d$431a9560$c94fc020$@cogeco.net> <019101cc6e8f$b3503aa0$19f0afe0$@cogeco.net> Message-ID: <01d801cc6ef3$6cf16750$46d435f0$@cogeco.net> Right, I see what you mean. For me I see the user being able to only view one topic at a time, therefore if a story belong to multiple topics it would have multiple views (depending on which topic the user is currently in). I guess doing it this way though would require a story to have a default topic. This topic would be used if the story was the first page the user visited when going to the website. Doing it this way also makes more sense for when I hope to eventually allow topics to have their own themes. Does this sound good to everyone? Tom From: geeklog-devel-bounces at lists.geeklog.net [mailto:geeklog-devel-bounces at lists.geeklog.net] On Behalf Of Vincent Furia Sent: September-09-11 3:57 AM To: Geeklog Development Subject: Re: [geeklog-devel] Geeklog Topics and Blocks I believe the use case I was thinking of is when viewing a single story/article that is a member of several topics. On Thu, Sep 8, 2011 at 19:27, Tom wrote: 1. COM_showBlocks will have to be modified to handle a topic array as well as a single topic. Most calling functions to COM_showBlocks functions will also need to be modified to handle multiple topics. Hey Vinny, Why are you saying here that most calling functions to COM_showBlocks needs to handle multiple topics? The user will still be only viewing one topic at a time so only one topic will still need to be passed into the function. I will just have to update the function to take into account the new topic_assiginments table and the fact that blocks can appear in 1 or more topics. Tom From: geeklog-devel-bounces at lists.geeklog.net [mailto:geeklog-devel-bounces at lists.geeklog.net] On Behalf Of Tom Sent: August-22-11 8:41 PM To: 'Geeklog Development' Subject: Re: [geeklog-devel] Geeklog Topics and Blocks You covered most of my points but I hadn't thought of 5, 6 and 9. 5. I would probably leave this as a feed for articles only and not other types since clicking on a topic itself would still only display articles. 6. Handling of featured topic articles. I guess the first question would be is should an article be allowed to be featured for only one topic or many topics. If it is many then either we will need a new table or I will have to add a column to topic_assignments Tom From: geeklog-devel-bounces at lists.geeklog.net [mailto:geeklog-devel-bounces at lists.geeklog.net] On Behalf Of Vincent Furia Sent: August-22-11 5:06 PM To: Geeklog Development Subject: Re: [geeklog-devel] Geeklog Topics and Blocks First the easy part. Defining the tables: 1. Remove 'tid' from the story table. 2. Create a new table "topic_assignments". It should have columns "type" varchar(30), "sid" varchar(40), and "tid" varchar(20). It's primary key should be on "tid" and with a INDEX on "type" and "sid" (this key could also just be on sid). 3. The topics table is sufficient as is, though that depends on the full set of features you want to change. The underlying code changes get complicated. Here is what I recall looking at originally, though I'm sure there is more that will have to be modified to incorporate the changes. Since you're implementation allows a single article (or other item) to be belong to multiple topics, you're changes are going to be more extensive than what I had looked at. At a minimum you're going to want to look at lib-common.php, article.php, and lib-security.php. 1. COM_siteHeader may need some mods to recognize when you are looking at plugin/block/etc that is associated with a specific topic. Also, COM_siteFooter. 2. COM_showBlocks will have to be modified to handle a topic array as well as a single topic. Most calling functions to COM_showBlocks functions will also need to be modified to handle multiple topics. 3. COM_topicArray will have to understand the new underlying database structure. 4. SEC_hasTopicAccess probably doesn't need to change, but keep an eye on it. 5. COM_rdfUpToDateCheck will need to be expanded to handle topic feed updates for non-article types. 6. COM_featuredCheck assumes tid will be in the article table. You'll also have to figure out how you want to handle featured article flag on stories with multiple topics, this could get really confusing if not taken into account at the start. 7. COM_adminMenu will need to handle topic assignments. Again, it assumes tid in the article table. 8. Everywhere COM_getTopicSQL is called will need to be rethought (and the function itself will probably go away). That code currently generates an "IN" clause against the tid in the article table. All queries that use it will have to do a double join to the topics table and topic_assignments table. I imagine this is where A LOT of the work for this project will be invested. 9. COM_emailUserTopics will need some mods since you don't want the informational email to repeat articles. Also, you might want to add a plugin API for plugin items be included in topic emails. 10. Obviously a new interface will be required to submit/administer articles with multiple topics. Some generic functions here will make it easy to add topic support to other plugins. 11. Webservices may be impacted, though I haven't looked at that code at all to even make an educated guess as to how much (or even if they would be impacted). 12. I think story.class.php will require extensive modifications, though it didn't exist when I first looked into modifying topics. I'm sure my notes on article.php are useless for the same reason... That should get you started. It's a pretty big undertaking. You might want to reconsider implementing subtopics, with all the work needed already the extra cost wouldn't be great (though I do understand your desire to limit the scope at least a little bit). It's a shame we didn't do GSOC this year, this probably would have made a great project for a summer intern... -Vinny On Mon, Aug 22, 2011 at 07:28, Tom wrote: >Any change that modified the database would require quite a bit of work (as my suggestion in the first paragraph would). If you end up going with any of these ideas, I had >thought out quite a bit more detail if you want it. Sure. J From: geeklog-devel-bounces at lists.geeklog.net [mailto:geeklog-devel-bounces at lists.geeklog.net] On Behalf Of Vincent Furia Sent: August-21-11 7:20 PM To: Geeklog Development Subject: Re: [geeklog-devel] Geeklog Topics and Blocks I had done some thinking on this several years ago. The most flexible design I came up with is using "tag" style backend. Instead of having tid's associated with stories, there would be topic_assignments (or some better named...) table allowing a many-to-many relationship between stories (or blocks, or plugins, etc) and topics. I went so far as to also consider how to handle sub-topics. Easy way: you could define topic relationships by having a topic separator (e.g. "-" or "/") in the topic name. Hard way: create a hierarchal data structure in the database (parent child relationship, or tree representation similar to how comments are not handled). The latter design would allow more flexibility, though the former would be significantly less work to implement. Any change that modified the database would require quite a bit of work (as my suggestion in the first paragraph would). If you end up going with any of these ideas, I had thought out quite a bit more detail if you want it. -Vinny On Sun, Aug 21, 2011 at 14:31, Tom wrote: I have started to do a bit of research/work on my feature request about allowing topics to be associated with other objects like staticpages, etc. http://project.geeklog.net/tracking/view.php?id=1155 I was also thinking about (I haven't decided to tackle it yet): - Allowing blocks to be assigned to one or more topics and not just one or all. - Allowing stories (and other objects) to be assigned to one or more topics. Does anyone have any thoughts or opinions... Tom _______________________________________________ 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 _______________________________________________ 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 websitemaster at cogeco.net Sat Sep 10 08:24:40 2011 From: websitemaster at cogeco.net (Tom) Date: Sat, 10 Sep 2011 08:24:40 -0400 Subject: [geeklog-devel] Geeklog Topics and Blocks In-Reply-To: <01d801cc6ef3$6cf16750$46d435f0$@cogeco.net> References: <00a601cc6041$5a33b2a0$0e9b17e0$@cogeco.net> <011301cc60cf$648b76a0$2da263e0$@cogeco.net> <017101cc612d$431a9560$c94fc020$@cogeco.net> <019101cc6e8f$b3503aa0$19f0afe0$@cogeco.net> <01d801cc6ef3$6cf16750$46d435f0$@cogeco.net> Message-ID: <024401cc6fb4$9ce93f70$d6bbbe50$@cogeco.net> Currently for a block it sticks "all" or "homeonly" in the tid if the block is to display for all topics or for a homepage only. (There actually is a small bug here since you can create topics with the same ids) For the new topic assignments table, what would be considered "better" practice. Coding it similar to above and restricting the use of topic ids or adding an extra column or two to the table? Tom From: geeklog-devel-bounces at lists.geeklog.net [mailto:geeklog-devel-bounces at lists.geeklog.net] On Behalf Of Tom Sent: September-09-11 9:22 AM To: 'Geeklog Development' Subject: Re: [geeklog-devel] Geeklog Topics and Blocks Right, I see what you mean. For me I see the user being able to only view one topic at a time, therefore if a story belong to multiple topics it would have multiple views (depending on which topic the user is currently in). I guess doing it this way though would require a story to have a default topic. This topic would be used if the story was the first page the user visited when going to the website. Doing it this way also makes more sense for when I hope to eventually allow topics to have their own themes. Does this sound good to everyone? Tom From: geeklog-devel-bounces at lists.geeklog.net [mailto:geeklog-devel-bounces at lists.geeklog.net] On Behalf Of Vincent Furia Sent: September-09-11 3:57 AM To: Geeklog Development Subject: Re: [geeklog-devel] Geeklog Topics and Blocks I believe the use case I was thinking of is when viewing a single story/article that is a member of several topics. On Thu, Sep 8, 2011 at 19:27, Tom wrote: 1. COM_showBlocks will have to be modified to handle a topic array as well as a single topic. Most calling functions to COM_showBlocks functions will also need to be modified to handle multiple topics. Hey Vinny, Why are you saying here that most calling functions to COM_showBlocks needs to handle multiple topics? The user will still be only viewing one topic at a time so only one topic will still need to be passed into the function. I will just have to update the function to take into account the new topic_assiginments table and the fact that blocks can appear in 1 or more topics. Tom From: geeklog-devel-bounces at lists.geeklog.net [mailto:geeklog-devel-bounces at lists.geeklog.net] On Behalf Of Tom Sent: August-22-11 8:41 PM To: 'Geeklog Development' Subject: Re: [geeklog-devel] Geeklog Topics and Blocks You covered most of my points but I hadn't thought of 5, 6 and 9. 5. I would probably leave this as a feed for articles only and not other types since clicking on a topic itself would still only display articles. 6. Handling of featured topic articles. I guess the first question would be is should an article be allowed to be featured for only one topic or many topics. If it is many then either we will need a new table or I will have to add a column to topic_assignments Tom From: geeklog-devel-bounces at lists.geeklog.net [mailto:geeklog-devel-bounces at lists.geeklog.net] On Behalf Of Vincent Furia Sent: August-22-11 5:06 PM To: Geeklog Development Subject: Re: [geeklog-devel] Geeklog Topics and Blocks First the easy part. Defining the tables: 1. Remove 'tid' from the story table. 2. Create a new table "topic_assignments". It should have columns "type" varchar(30), "sid" varchar(40), and "tid" varchar(20). It's primary key should be on "tid" and with a INDEX on "type" and "sid" (this key could also just be on sid). 3. The topics table is sufficient as is, though that depends on the full set of features you want to change. The underlying code changes get complicated. Here is what I recall looking at originally, though I'm sure there is more that will have to be modified to incorporate the changes. Since you're implementation allows a single article (or other item) to be belong to multiple topics, you're changes are going to be more extensive than what I had looked at. At a minimum you're going to want to look at lib-common.php, article.php, and lib-security.php. 1. COM_siteHeader may need some mods to recognize when you are looking at plugin/block/etc that is associated with a specific topic. Also, COM_siteFooter. 2. COM_showBlocks will have to be modified to handle a topic array as well as a single topic. Most calling functions to COM_showBlocks functions will also need to be modified to handle multiple topics. 3. COM_topicArray will have to understand the new underlying database structure. 4. SEC_hasTopicAccess probably doesn't need to change, but keep an eye on it. 5. COM_rdfUpToDateCheck will need to be expanded to handle topic feed updates for non-article types. 6. COM_featuredCheck assumes tid will be in the article table. You'll also have to figure out how you want to handle featured article flag on stories with multiple topics, this could get really confusing if not taken into account at the start. 7. COM_adminMenu will need to handle topic assignments. Again, it assumes tid in the article table. 8. Everywhere COM_getTopicSQL is called will need to be rethought (and the function itself will probably go away). That code currently generates an "IN" clause against the tid in the article table. All queries that use it will have to do a double join to the topics table and topic_assignments table. I imagine this is where A LOT of the work for this project will be invested. 9. COM_emailUserTopics will need some mods since you don't want the informational email to repeat articles. Also, you might want to add a plugin API for plugin items be included in topic emails. 10. Obviously a new interface will be required to submit/administer articles with multiple topics. Some generic functions here will make it easy to add topic support to other plugins. 11. Webservices may be impacted, though I haven't looked at that code at all to even make an educated guess as to how much (or even if they would be impacted). 12. I think story.class.php will require extensive modifications, though it didn't exist when I first looked into modifying topics. I'm sure my notes on article.php are useless for the same reason... That should get you started. It's a pretty big undertaking. You might want to reconsider implementing subtopics, with all the work needed already the extra cost wouldn't be great (though I do understand your desire to limit the scope at least a little bit). It's a shame we didn't do GSOC this year, this probably would have made a great project for a summer intern... -Vinny On Mon, Aug 22, 2011 at 07:28, Tom wrote: >Any change that modified the database would require quite a bit of work (as my suggestion in the first paragraph would). If you end up going with any of these ideas, I had >thought out quite a bit more detail if you want it. Sure. J From: geeklog-devel-bounces at lists.geeklog.net [mailto:geeklog-devel-bounces at lists.geeklog.net] On Behalf Of Vincent Furia Sent: August-21-11 7:20 PM To: Geeklog Development Subject: Re: [geeklog-devel] Geeklog Topics and Blocks I had done some thinking on this several years ago. The most flexible design I came up with is using "tag" style backend. Instead of having tid's associated with stories, there would be topic_assignments (or some better named...) table allowing a many-to-many relationship between stories (or blocks, or plugins, etc) and topics. I went so far as to also consider how to handle sub-topics. Easy way: you could define topic relationships by having a topic separator (e.g. "-" or "/") in the topic name. Hard way: create a hierarchal data structure in the database (parent child relationship, or tree representation similar to how comments are not handled). The latter design would allow more flexibility, though the former would be significantly less work to implement. Any change that modified the database would require quite a bit of work (as my suggestion in the first paragraph would). If you end up going with any of these ideas, I had thought out quite a bit more detail if you want it. -Vinny On Sun, Aug 21, 2011 at 14:31, Tom wrote: I have started to do a bit of research/work on my feature request about allowing topics to be associated with other objects like staticpages, etc. http://project.geeklog.net/tracking/view.php?id=1155 I was also thinking about (I haven't decided to tackle it yet): - Allowing blocks to be assigned to one or more topics and not just one or all. - Allowing stories (and other objects) to be assigned to one or more topics. Does anyone have any thoughts or opinions... Tom _______________________________________________ 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 _______________________________________________ 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 websitemaster at cogeco.net Mon Sep 12 09:29:06 2011 From: websitemaster at cogeco.net (Tom) Date: Mon, 12 Sep 2011 09:29:06 -0400 Subject: [geeklog-devel] Geeklog Topics and Blocks In-Reply-To: <024401cc6fb4$9ce93f70$d6bbbe50$@cogeco.net> References: <00a601cc6041$5a33b2a0$0e9b17e0$@cogeco.net> <011301cc60cf$648b76a0$2da263e0$@cogeco.net> <017101cc612d$431a9560$c94fc020$@cogeco.net> <019101cc6e8f$b3503aa0$19f0afe0$@cogeco.net> <01d801cc6ef3$6cf16750$46d435f0$@cogeco.net> <024401cc6fb4$9ce93f70$d6bbbe50$@cogeco.net> Message-ID: <02cf01cc714f$f1d82090$d58861b0$@cogeco.net> After thinking on it a bit here is how I see the gl_topic_assignments table: CREATE TABLE `gl_topic_assignments` ( `tid` varchar(20) NOT NULL, `type` varchar(30) NOT NULL, `id` varchar(40) NOT NULL, `value` varchar(255) NULL, PRIMARY KEY (`tid`,`type`,`id`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8; I have dropped the feature column (for articles) in favour of a multi-use column called value. This way articles can use the column to signify a featured story and blocks can use it to signify all or homepage only (this would leave the tid field blank). Plus it could be used by other plugins if needed. I am also wondering if I should up the char count of the id. Right now it sits at 40 which is good for the core plugins and articles but may be too small for other plugins. At some point I would like to see some of the ids in Geeklog (like for stories) pushed to at least the length of titles but I do not plan to do this at the moment. What size should the id be? 40, 100, 122, 255? Tom From: geeklog-devel-bounces at lists.geeklog.net [mailto:geeklog-devel-bounces at lists.geeklog.net] On Behalf Of Tom Sent: September-10-11 8:25 AM To: 'Geeklog Development' Subject: Re: [geeklog-devel] Geeklog Topics and Blocks Currently for a block it sticks "all" or "homeonly" in the tid if the block is to display for all topics or for a homepage only. (There actually is a small bug here since you can create topics with the same ids) For the new topic assignments table, what would be considered "better" practice. Coding it similar to above and restricting the use of topic ids or adding an extra column or two to the table? Tom From: geeklog-devel-bounces at lists.geeklog.net [mailto:geeklog-devel-bounces at lists.geeklog.net] On Behalf Of Tom Sent: September-09-11 9:22 AM To: 'Geeklog Development' Subject: Re: [geeklog-devel] Geeklog Topics and Blocks Right, I see what you mean. For me I see the user being able to only view one topic at a time, therefore if a story belong to multiple topics it would have multiple views (depending on which topic the user is currently in). I guess doing it this way though would require a story to have a default topic. This topic would be used if the story was the first page the user visited when going to the website. Doing it this way also makes more sense for when I hope to eventually allow topics to have their own themes. Does this sound good to everyone? Tom From: geeklog-devel-bounces at lists.geeklog.net [mailto:geeklog-devel-bounces at lists.geeklog.net] On Behalf Of Vincent Furia Sent: September-09-11 3:57 AM To: Geeklog Development Subject: Re: [geeklog-devel] Geeklog Topics and Blocks I believe the use case I was thinking of is when viewing a single story/article that is a member of several topics. On Thu, Sep 8, 2011 at 19:27, Tom wrote: 1. COM_showBlocks will have to be modified to handle a topic array as well as a single topic. Most calling functions to COM_showBlocks functions will also need to be modified to handle multiple topics. Hey Vinny, Why are you saying here that most calling functions to COM_showBlocks needs to handle multiple topics? The user will still be only viewing one topic at a time so only one topic will still need to be passed into the function. I will just have to update the function to take into account the new topic_assiginments table and the fact that blocks can appear in 1 or more topics. Tom From: geeklog-devel-bounces at lists.geeklog.net [mailto:geeklog-devel-bounces at lists.geeklog.net] On Behalf Of Tom Sent: August-22-11 8:41 PM To: 'Geeklog Development' Subject: Re: [geeklog-devel] Geeklog Topics and Blocks You covered most of my points but I hadn't thought of 5, 6 and 9. 5. I would probably leave this as a feed for articles only and not other types since clicking on a topic itself would still only display articles. 6. Handling of featured topic articles. I guess the first question would be is should an article be allowed to be featured for only one topic or many topics. If it is many then either we will need a new table or I will have to add a column to topic_assignments Tom From: geeklog-devel-bounces at lists.geeklog.net [mailto:geeklog-devel-bounces at lists.geeklog.net] On Behalf Of Vincent Furia Sent: August-22-11 5:06 PM To: Geeklog Development Subject: Re: [geeklog-devel] Geeklog Topics and Blocks First the easy part. Defining the tables: 1. Remove 'tid' from the story table. 2. Create a new table "topic_assignments". It should have columns "type" varchar(30), "sid" varchar(40), and "tid" varchar(20). It's primary key should be on "tid" and with a INDEX on "type" and "sid" (this key could also just be on sid). 3. The topics table is sufficient as is, though that depends on the full set of features you want to change. The underlying code changes get complicated. Here is what I recall looking at originally, though I'm sure there is more that will have to be modified to incorporate the changes. Since you're implementation allows a single article (or other item) to be belong to multiple topics, you're changes are going to be more extensive than what I had looked at. At a minimum you're going to want to look at lib-common.php, article.php, and lib-security.php. 1. COM_siteHeader may need some mods to recognize when you are looking at plugin/block/etc that is associated with a specific topic. Also, COM_siteFooter. 2. COM_showBlocks will have to be modified to handle a topic array as well as a single topic. Most calling functions to COM_showBlocks functions will also need to be modified to handle multiple topics. 3. COM_topicArray will have to understand the new underlying database structure. 4. SEC_hasTopicAccess probably doesn't need to change, but keep an eye on it. 5. COM_rdfUpToDateCheck will need to be expanded to handle topic feed updates for non-article types. 6. COM_featuredCheck assumes tid will be in the article table. You'll also have to figure out how you want to handle featured article flag on stories with multiple topics, this could get really confusing if not taken into account at the start. 7. COM_adminMenu will need to handle topic assignments. Again, it assumes tid in the article table. 8. Everywhere COM_getTopicSQL is called will need to be rethought (and the function itself will probably go away). That code currently generates an "IN" clause against the tid in the article table. All queries that use it will have to do a double join to the topics table and topic_assignments table. I imagine this is where A LOT of the work for this project will be invested. 9. COM_emailUserTopics will need some mods since you don't want the informational email to repeat articles. Also, you might want to add a plugin API for plugin items be included in topic emails. 10. Obviously a new interface will be required to submit/administer articles with multiple topics. Some generic functions here will make it easy to add topic support to other plugins. 11. Webservices may be impacted, though I haven't looked at that code at all to even make an educated guess as to how much (or even if they would be impacted). 12. I think story.class.php will require extensive modifications, though it didn't exist when I first looked into modifying topics. I'm sure my notes on article.php are useless for the same reason... That should get you started. It's a pretty big undertaking. You might want to reconsider implementing subtopics, with all the work needed already the extra cost wouldn't be great (though I do understand your desire to limit the scope at least a little bit). It's a shame we didn't do GSOC this year, this probably would have made a great project for a summer intern... -Vinny On Mon, Aug 22, 2011 at 07:28, Tom wrote: >Any change that modified the database would require quite a bit of work (as my suggestion in the first paragraph would). If you end up going with any of these ideas, I had >thought out quite a bit more detail if you want it. Sure. J From: geeklog-devel-bounces at lists.geeklog.net [mailto:geeklog-devel-bounces at lists.geeklog.net] On Behalf Of Vincent Furia Sent: August-21-11 7:20 PM To: Geeklog Development Subject: Re: [geeklog-devel] Geeklog Topics and Blocks I had done some thinking on this several years ago. The most flexible design I came up with is using "tag" style backend. Instead of having tid's associated with stories, there would be topic_assignments (or some better named...) table allowing a many-to-many relationship between stories (or blocks, or plugins, etc) and topics. I went so far as to also consider how to handle sub-topics. Easy way: you could define topic relationships by having a topic separator (e.g. "-" or "/") in the topic name. Hard way: create a hierarchal data structure in the database (parent child relationship, or tree representation similar to how comments are not handled). The latter design would allow more flexibility, though the former would be significantly less work to implement. Any change that modified the database would require quite a bit of work (as my suggestion in the first paragraph would). If you end up going with any of these ideas, I had thought out quite a bit more detail if you want it. -Vinny On Sun, Aug 21, 2011 at 14:31, Tom wrote: I have started to do a bit of research/work on my feature request about allowing topics to be associated with other objects like staticpages, etc. http://project.geeklog.net/tracking/view.php?id=1155 I was also thinking about (I haven't decided to tackle it yet): - Allowing blocks to be assigned to one or more topics and not just one or all. - Allowing stories (and other objects) to be assigned to one or more topics. Does anyone have any thoughts or opinions... Tom _______________________________________________ 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 _______________________________________________ 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 jmucchiello at yahoo.com Mon Sep 12 18:19:01 2011 From: jmucchiello at yahoo.com (Joe Mucchiello) Date: Mon, 12 Sep 2011 15:19:01 -0700 (PDT) Subject: [geeklog-devel] Geeklog Topics and Blocks Message-ID: <1315865941.51012.YahooMailNeo@web161424.mail.bf1.yahoo.com> > I have dropped the feature column (for articles) in favour of a multi-use > column called value. This way articles can use the column to signify a > featured story and blocks can use it to signify all or homepage only (this > would leave the tid field blank). Plus it could be used by other plugins > if needed. Value is a weak solution. While I realize that type mitigates "fights" over what goes into value (the owner of type decides what goes in value), filtering on value is going to be a pain if you need to store more than one logical "field" in value. No, I don't have a better solution. But I just wanted to point out the pitfalls of the opaque "value" field. -------------- next part -------------- An HTML attachment was scrubbed... URL: From websitemaster at cogeco.net Tue Sep 13 12:33:35 2011 From: websitemaster at cogeco.net (Tom) Date: Tue, 13 Sep 2011 12:33:35 -0400 Subject: [geeklog-devel] Geeklog Topics and Blocks In-Reply-To: <1315865941.51012.YahooMailNeo@web161424.mail.bf1.yahoo.com> References: <1315865941.51012.YahooMailNeo@web161424.mail.bf1.yahoo.com> Message-ID: <03e701cc7232$e27a5120$a76ef360$@cogeco.net> Yeah I know it is not an ideal solution (that's why I started the conversation) but I believe it is better than adding single use columns on a table that will only be used by certain types. Unless someone else can point to a better solution I think I will stick with it. Tom From: geeklog-devel-bounces at lists.geeklog.net [mailto:geeklog-devel-bounces at lists.geeklog.net] On Behalf Of Joe Mucchiello Sent: September-12-11 6:19 PM To: geeklog-devel at lists.geeklog.net Subject: Re: [geeklog-devel] Geeklog Topics and Blocks > I have dropped the feature column (for articles) in favour of a multi-use > column called value. This way articles can use the column to signify a > featured story and blocks can use it to signify all or homepage only (this > would leave the tid field blank). Plus it could be used by other plugins > if needed. Value is a weak sol ution. While I realize that type mitigates "fights" over what goes into value (the owner of type decides what goes in value), filtering on value is going to be a pain if you need to store more than one logical "field" in value. No, I don't have a better solution. But I just wanted to point out the pitfalls of the opaque "value" field. -------------- next part -------------- An HTML attachment was scrubbed... URL: From vfuria at gmail.com Wed Sep 14 03:14:43 2011 From: vfuria at gmail.com (Vincent Furia) Date: Wed, 14 Sep 2011 01:14:43 -0600 Subject: [geeklog-devel] Geeklog Topics and Blocks In-Reply-To: <03e701cc7232$e27a5120$a76ef360$@cogeco.net> References: <1315865941.51012.YahooMailNeo@web161424.mail.bf1.yahoo.com> <03e701cc7232$e27a5120$a76ef360$@cogeco.net> Message-ID: What about a separate table to track what you want to store in value? Or add a column to the topic table, at least for featured stories (I never understood why this was in the story table and not the topic table). You could also have special values for tid to represent all topics or homepage only (I'd suggest numerics, but you could use NULL). Since you're likely going to be using this table for joins, I'd suggest keeping it as simply as possible (e.g. removing the "value" column completely and moving the information you'd keep in there elsewhere). -Vinny On Tue, Sep 13, 2011 at 10:33, Tom wrote: > Yeah I know it is not an ideal solution (that?s why I started the > conversation) but I believe it is better than adding single use columns on a > table that will only be used by certain types. Unless someone else can point > to a better solution I think I will stick with it.**** > > ** ** > > Tom**** > > ** ** > > *From:* geeklog-devel-bounces at lists.geeklog.net [mailto: > geeklog-devel-bounces at lists.geeklog.net] *On Behalf Of *Joe Mucchiello > *Sent:* September-12-11 6:19 PM > *To:* geeklog-devel at lists.geeklog.net > > *Subject:* Re: [geeklog-devel] Geeklog Topics and Blocks**** > > ** ** > > > I have dropped the feature column (for articles) in favour of a multi-use > > > column called value. This way articles can use the column to signify a > > featured story and blocks can use it to signify all or homepage only > (this > > would leave the tid field blank). Plus it could be used by other plugins > > if needed.**** > > ** ** > > Value is a weak sol ution. While I realize that type mitigates "fights" > over what goes into value (the owner of type decides what goes in value), > filtering on value is going to be a pain if you need to store more than one > logical "field" in value. No, I don't have a better solution. But I just > wanted to point out the pitfalls of the opaque "value" field.**** > > _______________________________________________ > 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 websitemaster at cogeco.net Wed Sep 14 11:43:31 2011 From: websitemaster at cogeco.net (Tom) Date: Wed, 14 Sep 2011 11:43:31 -0400 Subject: [geeklog-devel] Geeklog Topics and Blocks In-Reply-To: References: <1315865941.51012.YahooMailNeo@web161424.mail.bf1.yahoo.com> <03e701cc7232$e27a5120$a76ef360$@cogeco.net> Message-ID: <006c01cc72f5$0dfb51b0$29f1f510$@cogeco.net> >> Or add a column to the topic table, at least for featured stories . You could also have special values for tid to represent all topics or homepage only That was what I was originally going to do. Have a featured column used by articles and the column tid would contain either the topic id or "all" or "homeonly" (currently how blocks work). When a user creates a topic I will just have to add a few topic ids that are not allowed. CREATE TABLE `gl_topic_assignments` ( `tid` varchar(20) NOT NULL, `type` varchar(30) NOT NULL, `id` varchar(40) NOT NULL, `featured` tinyint(1) NOT NULL DEFAULT 0, PRIMARY KEY (`tid`,`type`,`id`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8; Tom From: geeklog-devel-bounces at lists.geeklog.net [mailto:geeklog-devel-bounces at lists.geeklog.net] On Behalf Of Vincent Furia Sent: September-14-11 3:15 AM To: Geeklog Development Subject: Re: [geeklog-devel] Geeklog Topics and Blocks What about a separate table to track what you want to store in value? Or add a column to the topic table, at least for featured stories (I never understood why this was in the story table and not the topic table). You could also have special values for tid to represent all topics or homepage only (I'd suggest numerics, but you could use NULL). Since you're likely going to be using this table for joins, I'd suggest keeping it as simply as possible (e.g. removing the "value" column completely and moving the information you'd keep in there elsewhere). -Vinny On Tue, Sep 13, 2011 at 10:33, Tom wrote: Yeah I know it is not an ideal solution (that's why I started the conversation) but I believe it is better than adding single use columns on a table that will only be used by certain types. Unless someone else can point to a better solution I think I will stick with it. Tom From: geeklog-devel-bounces at lists.geeklog.net [mailto:geeklog-devel-bounces at lists.geeklog.net] On Behalf Of Joe Mucchiello Sent: September-12-11 6:19 PM To: geeklog-devel at lists.geeklog.net Subject: Re: [geeklog-devel] Geeklog Topics and Blocks > I have dropped the feature column (for articles) in favour of a multi-use > column called value. This way articles can use the column to signify a > featured story and blocks can use it to signify all or homepage only (this > would leave the tid field blank). Plus it could be used by other plugins > if needed. Value is a weak sol ution. While I realize that type mitigates "fights" over what goes into value (the owner of type decides what goes in value), filtering on value is going to be a pain if you need to store more than one logical "field" in value. No, I don't have a better solution. But I just wanted to point out the pitfalls of the opaque "value" field. _______________________________________________ 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 vfuria at gmail.com Wed Sep 14 13:16:37 2011 From: vfuria at gmail.com (Vincent Furia) Date: Wed, 14 Sep 2011 11:16:37 -0600 Subject: [geeklog-devel] Geeklog Topics and Blocks In-Reply-To: <006c01cc72f5$0dfb51b0$29f1f510$@cogeco.net> References: <1315865941.51012.YahooMailNeo@web161424.mail.bf1.yahoo.com> <03e701cc7232$e27a5120$a76ef360$@cogeco.net> <006c01cc72f5$0dfb51b0$29f1f510$@cogeco.net> Message-ID: Tom, I think you misunderstood, what I meant was: CREATE TABLE `gl_topic_assignments` (**** `tid` varchar(20) NOT NULL,**** `type` varchar(30) NOT NULL,**** `id` varchar(40) NOT NULL, PRIMARY KEY (`tid`,`type`,`id`)**** ) ENGINE=InnoDB DEFAULT CHARSET=utf8; CREATE TABLE {$_TABLES['topics']} ( tid varchar(20) NOT NULL default '', topic varchar(48) default NULL, imageurl varchar(255) default NULL, meta_description TEXT NULL, meta_keywords TEXT NULL, sortnum smallint(3) default NULL, limitnews tinyint(3) default NULL, * featured varchar(40) default NULL,* is_default tinyint(1) unsigned NOT NULL DEFAULT '0', archive_flag tinyint(1) unsigned NOT NULL DEFAULT '0', owner_id mediumint(8) unsigned NOT NULL default '1', group_id mediumint(8) unsigned NOT NULL default '1', perm_owner tinyint(1) unsigned NOT NULL default '3', perm_group tinyint(1) unsigned NOT NULL default '3', perm_members tinyint(1) unsigned NOT NULL default '2', perm_anon tinyint(1) unsigned NOT NULL default '2', PRIMARY KEY (tid) ) ENGINE=MyISAM We only allow one featured article per topic, so why not keep it in the topic? We have to grab data from the topic table anyway when displaying the topic page. The homepage can be a special case (of which there are any number of ways to handle). -Vinny On Wed, Sep 14, 2011 at 09:43, Tom wrote: > >> Or add a column to the topic table, at least for featured stories ? You > could also have special values for tid to represent all topics or homepage > only**** > > ** ** > > That was what I was originally going to do. Have a featured column used by > articles and the column tid would contain either the topic id or ?all? or > ?homeonly? (currently how blocks work). When a user creates a topic I will > just have to add a few topic ids that are not allowed.**** > > ** ** > > CREATE TABLE `gl_topic_assignments` (**** > > `tid` varchar(20) NOT NULL,**** > > `type` varchar(30) NOT NULL,**** > > `id` varchar(40) NOT NULL,**** > > `featured` tinyint(1) NOT NULL DEFAULT 0,**** > > PRIMARY KEY (`tid`,`type`,`id`)**** > > ) ENGINE=InnoDB DEFAULT CHARSET=utf8;**** > > ** ** > > Tom**** > > ** ** > > *From:* geeklog-devel-bounces at lists.geeklog.net [mailto: > geeklog-devel-bounces at lists.geeklog.net] *On Behalf Of *Vincent Furia > *Sent:* September-14-11 3:15 AM > *To:* Geeklog Development > > *Subject:* Re: [geeklog-devel] Geeklog Topics and Blocks**** > > ** ** > > What about a separate table to track what you want to store in value? Or > add a column to the topic table, at least for featured stories (I never > understood why this was in the story table and not the topic table). You > could also have special values for tid to represent all topics or homepage > only (I'd suggest numerics, but you could use NULL).**** > > ** ** > > Since you're likely going to be using this table for joins, I'd suggest > keeping it as simply as possible (e.g. removing the "value" column > completely and moving the information you'd keep in there elsewhere).**** > > ** ** > > -Vinny**** > > On Tue, Sep 13, 2011 at 10:33, Tom wrote:**** > > Yeah I know it is not an ideal solution (that?s why I started the > conversation) but I believe it is better than adding single use columns on a > table that will only be used by certain types. Unless someone else can point > to a better solution I think I will stick with it.**** > > **** > > Tom**** > > **** > > *From:* geeklog-devel-bounces at lists.geeklog.net [mailto: > geeklog-devel-bounces at lists.geeklog.net] *On Behalf Of *Joe Mucchiello > *Sent:* September-12-11 6:19 PM > *To:* geeklog-devel at lists.geeklog.net**** > > > *Subject:* Re: [geeklog-devel] Geeklog Topics and Blocks**** > > **** > > > I have dropped the feature column (for articles) in favour of a multi-use > **** > > > > column called value. This way articles can use the column to signify a > > featured story and blocks can use it to signify all or homepage only > (this > > would leave the tid field blank). Plus it could be used by other plugins > > if needed.**** > > **** > > Value is a weak sol ution. While I realize that type mitigates "fights" > over what goes into value (the owner of type decides what goes in value), > filtering on value is going to be a pain if you need to store more than one > logical "field" in value. No, I don't have a better solution. But I just > wanted to point out the pitfalls of the opaque "value" field.**** > > > _______________________________________________ > 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 websitemaster at cogeco.net Wed Sep 14 14:52:03 2011 From: websitemaster at cogeco.net (Tom) Date: Wed, 14 Sep 2011 14:52:03 -0400 Subject: [geeklog-devel] Geeklog Topics and Blocks In-Reply-To: References: <1315865941.51012.YahooMailNeo@web161424.mail.bf1.yahoo.com> <03e701cc7232$e27a5120$a76ef360$@cogeco.net> <006c01cc72f5$0dfb51b0$29f1f510$@cogeco.net> Message-ID: <00a701cc730f$64d90670$2e8b1350$@cogeco.net> Opps . my mistake. From: geeklog-devel-bounces at lists.geeklog.net [mailto:geeklog-devel-bounces at lists.geeklog.net] On Behalf Of Vincent Furia Sent: September-14-11 1:17 PM To: Geeklog Development Subject: Re: [geeklog-devel] Geeklog Topics and Blocks Tom, I think you misunderstood, what I meant was: CREATE TABLE `gl_topic_assignments` ( `tid` varchar(20) NOT NULL, `type` varchar(30) NOT NULL, `id` varchar(40) NOT NULL, PRIMARY KEY (`tid`,`type`,`id`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8; CREATE TABLE {$_TABLES['topics']} ( tid varchar(20) NOT NULL default '', topic varchar(48) default NULL, imageurl varchar(255) default NULL, meta_description TEXT NULL, meta_keywords TEXT NULL, sortnum smallint(3) default NULL, limitnews tinyint(3) default NULL, featured varchar(40) default NULL, is_default tinyint(1) unsigned NOT NULL DEFAULT '0', archive_flag tinyint(1) unsigned NOT NULL DEFAULT '0', owner_id mediumint(8) unsigned NOT NULL default '1', group_id mediumint(8) unsigned NOT NULL default '1', perm_owner tinyint(1) unsigned NOT NULL default '3', perm_group tinyint(1) unsigned NOT NULL default '3', perm_members tinyint(1) unsigned NOT NULL default '2', perm_anon tinyint(1) unsigned NOT NULL default '2', PRIMARY KEY (tid) ) ENGINE=MyISAM We only allow one featured article per topic, so why not keep it in the topic? We have to grab data from the topic table anyway when displaying the topic page. The homepage can be a special case (of which there are any number of ways to handle). -Vinny On Wed, Sep 14, 2011 at 09:43, Tom wrote: >> Or add a column to the topic table, at least for featured stories . You could also have special values for tid to represent all topics or homepage only That was what I was originally going to do. Have a featured column used by articles and the column tid would contain either the topic id or "all" or "homeonly" (currently how blocks work). When a user creates a topic I will just have to add a few topic ids that are not allowed. CREATE TABLE `gl_topic_assignments` ( `tid` varchar(20) NOT NULL, `type` varchar(30) NOT NULL, `id` varchar(40) NOT NULL, `featured` tinyint(1) NOT NULL DEFAULT 0, PRIMARY KEY (`tid`,`type`,`id`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8; Tom From: geeklog-devel-bounces at lists.geeklog.net [mailto:geeklog-devel-bounces at lists.geeklog.net] On Behalf Of Vincent Furia Sent: September-14-11 3:15 AM To: Geeklog Development Subject: Re: [geeklog-devel] Geeklog Topics and Blocks What about a separate table to track what you want to store in value? Or add a column to the topic table, at least for featured stories (I never understood why this was in the story table and not the topic table). You could also have special values for tid to represent all topics or homepage only (I'd suggest numerics, but you could use NULL). Since you're likely going to be using this table for joins, I'd suggest keeping it as simply as possible (e.g. removing the "value" column completely and moving the information you'd keep in there elsewhere). -Vinny On Tue, Sep 13, 2011 at 10:33, Tom wrote: Yeah I know it is not an ideal solution (that's why I started the conversation) but I believe it is better than adding single use columns on a table that will only be used by certain types. Unless someone else can point to a better solution I think I will stick with it. Tom From: geeklog-devel-bounces at lists.geeklog.net [mailto:geeklog-devel-bounces at lists.geeklog.net] On Behalf Of Joe Mucchiello Sent: September-12-11 6:19 PM To: geeklog-devel at lists.geeklog.net Subject: Re: [geeklog-devel] Geeklog Topics and Blocks > I have dropped the feature column (for articles) in favour of a multi-use > column called value. This way articles can use the column to signify a > featured story and blocks can use it to signify all or homepage only (this > would leave the tid field blank). Plus it could be used by other plugins > if needed. Value is a weak sol ution. While I realize that type mitigates "fights" over what goes into value (the owner of type decides what goes in value), filtering on value is going to be a pain if you need to store more than one logical "field" in value. No, I don't have a better solution. But I just wanted to point out the pitfalls of the opaque "value" field. _______________________________________________ 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 dirk at haun-online.de Wed Sep 14 15:45:43 2011 From: dirk at haun-online.de (Dirk Haun) Date: Wed, 14 Sep 2011 21:45:43 +0200 Subject: [geeklog-devel] IKS Semantic UX Contest Message-ID: <3947AA1E-CD4C-4C93-AB48-44DFF3F4663B@haun-online.de> Anyone from the Geeklog community up for a challenge? or http://goo.gl/pXVte if the long URL doesn't work for you. --- snip --- Interactive Knowledge Stack (IKS), the open source project to speed the implementation and broaden the reach of the semantic web, is offering a total of up to ?110,000 in a competition to develop new semantically-enriched, user-centric applications. --- snip --- They're actually looking for a proposal first (deadline: October 14), then comes acceptance and then comes implementation. We don't have any "official" IKS support in Geeklog but I can donate my early prototype of a plugin if anyone's interested. Also see http://www.geeklog.net/article.php/iks-workshop-amsterdam for some background. bye, Dirk From cordiste at free.fr Thu Sep 15 09:51:21 2011 From: cordiste at free.fr (cordiste) Date: Thu, 15 Sep 2011 15:51:21 +0200 Subject: [geeklog-devel] USER_addGroup VS SEC_addUserToGroup Message-ID: I noticed two different functions for almost the same action. USER_addGroup : Add user to group if user does not belong to specified group (lib-user.php) SEC_addUserToGroup: Add user to a group (lib-security.php) Ben From vfuria at gmail.com Thu Sep 15 11:11:55 2011 From: vfuria at gmail.com (Vincent Furia) Date: Thu, 15 Sep 2011 09:11:55 -0600 Subject: [geeklog-devel] USER_addGroup VS SEC_addUserToGroup In-Reply-To: References: Message-ID: Sounds like something to add to the bugtracker ... On Thu, Sep 15, 2011 at 07:51, cordiste wrote: > I noticed two different functions for almost the same action. > > USER_addGroup : Add user to group if user does not belong to specified > group (lib-user.php) > SEC_addUserToGroup: Add user to a group (lib-security.php) > > Ben > _______________________________________________ > 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 jmucchiello at yahoo.com Thu Sep 15 11:34:42 2011 From: jmucchiello at yahoo.com (Joe Mucchiello) Date: Thu, 15 Sep 2011 08:34:42 -0700 (PDT) Subject: [geeklog-devel] USER_addGroup VS SEC_addUserToGroup Message-ID: <1316100882.55034.YahooMailNeo@web161421.mail.bf1.yahoo.com> > I noticed two different functions for almost the same action. > > USER_addGroup : Add user to group if user does not belong to specified > group (lib-user.php) > SEC_addUserToGroup: Add user to a group (lib-security.php) > > Ben Perfectly "logical" or at least explainable. The one in lib-user came first. Then someone decided to add a missing function to lib-security (if you read the comment, Trinity added it because it seemed like a good idea), not knowing about the one in lib-user because lib-user is only loaded by the user/profile pages, not by lib-common. Harder to explain is the fact that copy in lib-security is used only once in the system (one would think the plugin autoinstall code must need such functionality) and worse is the copy in lib-user is not used anywhere at all. Finally, the version in lib-security has no sanity checks, allowing duplicate grp_id, uid pairs to be put into the database. And for some reason the lib-user version doesn't allow anonymous users into groups. There are lots of things like this in Geeklog, Ben. -------------- next part -------------- An HTML attachment was scrubbed... URL: From websitemaster at cogeco.net Sun Sep 18 10:04:24 2011 From: websitemaster at cogeco.net (Tom) Date: Sun, 18 Sep 2011 10:04:24 -0400 Subject: [geeklog-devel] Geeklog.net Redesign Message-ID: <01bb01cc760b$df07a600$9d16f200$@cogeco.net> While I have delayed (for a little while) starting the redesign process of how Geeklog.net is structured and the information is presented I would just like to remind everyone that if you come up with a few redesign ideas, you are more than welcome to add it to the Geeklog.net Redesign wiki page: http://wiki.geeklog.net/index.php/Geeklog.net_Redesign Tom -------------- next part -------------- An HTML attachment was scrubbed... URL: From websitemaster at cogeco.net Mon Sep 19 14:50:56 2011 From: websitemaster at cogeco.net (Tom) Date: Mon, 19 Sep 2011 14:50:56 -0400 Subject: [geeklog-devel] Geeklog Blocks Message-ID: <009501cc76fd$10a760f0$31f622d0$@cogeco.net> When creating/editing a block, the block name says it must have no spaces and must be unique. There are no checks when saving for this nor is there a unique index (just a regular one) on the block name field. From what I recall the block name is used just for specifying a specific template to use. I could see different blocks using the same template so IMO this message needs to state no spaces only and nothing about being unique (unless I am missing something here). Is this right? Tom -------------- next part -------------- An HTML attachment was scrubbed... URL: From websitemaster at cogeco.net Wed Sep 21 10:51:37 2011 From: websitemaster at cogeco.net (Tom) Date: Wed, 21 Sep 2011 10:51:37 -0400 Subject: [geeklog-devel] Installing Geeklog affects plugins that install blocks Message-ID: <003701cc786d$f6a468c0$e3ed3a40$@cogeco.net> I have finished pretty much allowing blocks to appear for one or more topics. I have decided to do the topics update in stages as I am unsure if I could get it all done by 1.9.0 potential release date (especially when problems crop up) so I will be committing this part to core soon. Upgrading the database from 1.8.1 to 1.9.0 s is not a problem but the install can be. Currently when a plugin wants to add a block it just goes ahead and accesses the block table directly. Well as of 1.9.0 the block table has changed since it doesn't need the tid column (for topics) any more. This breaks installing plugins that add blocks like polls and the forum. While I can go ahead and fix the polls plugin, 3rd party plugins are another matter. What should we do here? Also to fix this problem in the future (this doesn't help with the issue above) I propose adding some functions to the plugins library that will handle adding, deleting and updating (enabling, disabling, etc.) blocks. (I am not sure does the upgrade process have access to lib-plugins if a plugin needs to add a block?) Plugins also do not really have a way to identify their own blocks. Here are a few line samples I saw in the polls plugin: DB_query ("UPDATE {$_TABLES['blocks']} SET is_enabled = $is_enabled WHERE (type = 'phpblock') AND (phpblockfn = 'phpblock_polls')"); // uninstall procedure 'php_blocks' => array('phpblock_polls'), $title = DB_getItem($_TABLES['blocks'], 'title', "name='poll_block'"); Should we attempt to tidy this up and what would the best way be? Finally, the forum also does a little bit of extra block magic when it makes the forum block first, // Retrieve the list of blocks to show on the left side and make the forum menu the first block function forum_GetUserBlocks($blocks = array('forum_menu')) { global $_TABLES, $_USER; $retval = ''; $sql = "SELECT name,owner_id,group_id,perm_owner,perm_group,perm_members,perm_anon FROM {$_TABLES['blocks']} WHERE onleft = 1 AND is_enabled = 1"; ... While this update does not affect this, future table changes could since it accessing the blocks table directly to gather information. I think for now I will leave this but we should consider it when discussing the above problems. Tom -------------- next part -------------- An HTML attachment was scrubbed... URL: From ironmax at spacequad.com Thu Sep 22 12:35:26 2011 From: ironmax at spacequad.com (Michael Brusletten) Date: Thu, 22 Sep 2011 12:35:26 -0400 Subject: [geeklog-devel] New addition to the demo site - zbblock References: Message-ID: <000901cc7945$a22d8be0$fe00a8c0@node1> To All: I have added ZBBLOCK to the Geeklog Demo Site because I thought it was time to finally stop the onslaught of really bad behavior that should not be let into the site in the first place. What this script does is the following: This php security script is designed to detect certain behaviors detrimental to websites, or known bad addresses attempting to access your site. It then will send the bad robot (usually) or hacker an authentic 403 FORBIDDEN page with a description of what the problem was. If the attacker persists, then they will be served up a permanently reccurring 503 OVERLOAD message with a 24 hour timeout. If you are looking for a script to help with protection of a Counter-Strike Gaming server, this is not the zBlock program you are looking for. You can find them at http://zblock.mgamez.eu/ , however, many of the same sites could also benefit from what this site has to offer. The name is purely coincidental (I have been using the moniker Zaphod Breeblebrox for 25 years), and their version number is V. 4.4 a post-release. While ZB Block (double Bs and a space) is still in beta development. What ZB Block is Excellent at: a.. Saves money by reducing hacker bandwith usage! (by 2,500% on this site's index page alone!) b.. Strengthing your site against defacement. c.. Preventing PHP script exploitation. d.. Ending Remote File Include (RFI) exploits. e.. Protecting against directory traversal attacks. f.. Stopping MySQL database injection and tampering. g.. Removing access from known bad addresses and domain names. h.. Blocking access from top level domains, like .cn (China) and .kp (North Korea). What ZB Block is Good at: a.. Avoiding website scraping/content theft. b.. Deterring bad user agents. c.. Halting referrer spam. d.. Impeding some Cross Site Scripting (XSS) attacks. What ZB Block will not do: a.. Protect non-PHP pages. b.. Stop access to non-exploitable resource files like .gif, .jpg, or .swf . ZB Block is also fast, not only does ZB Block check for over 100,000,000 bad IPs/Hostnames and many thousands of bots, but standard execution times are around 1/10th of a second on an aged PIII 930, which is unnoticable to the web surfer. This anti-exploit / anti-'sploit / anti-hacking / anti-injection script should find many uses around the web as it's good at detecting, and stopping exploitation probes from many of the worst known skript kiddie tools. Why ZB Block is BETTER than .htaccess methods... 1.. Under certiain tasks, it is FASTER than htaccess due to only polling the server for data once per execution. An example of this is domain blocking. 2.. It will run on webservers that do not support the full gamut of .htaccess commands (And there are quite a few). 3.. It allows for intelligent detection of problem clients without previous knowledge of their address. 4.. It can sniff query strings to find attack sequences from all IPs, while allowing legitimate requests to go through. 5.. Through proper signature use, it can automatically remove some blocks that have met a condition. (such as registration of domain) 6.. It can ban whole whole ranges of IPs written in classic decimal quadot notation. You can put your own custom ones in the signatures like 193.189.126.5 through 193.189.127.252 . (.htaccess gets a big FAIL! on dealing with IPs as it uses tricky to maintain CIDR ranges that only work in a most signifigant bit (MSB) method, sometimes requiring multiple entries for oddball ranges. 'Did I really include all the IPs? Did I accidentally go to far?') 7.. Some hosts don't like custom 403s, so they don't allow you to use your own .htaccess driven 403. ZB Block doesn't care if the .htaccess is emplaced. 8.. It logs banned accesses for later review in plain, easy to read english, with a description as to why said session was blocked. 9.. It's simple and easy to use, and requires no authorization beyond the ability to upload files to your php equipped web-server. 10.. Most importantly, it slows down evil robot machines to a crawl (sometimes) and helps alleviate (we hope) your fellow hosts/webmasters from some of the unwanted traffic! 11.. For more information, see http://www.spambotsecurity.com/zbblock.php To download the script, goto their site http://www.spambotsecurity.com/zbblock.php and check it out. I have added a message to the 404 Error page that will be shown to those that have issues to copy and paste the message they get in a forum post on the geeklog site for help. However, it is my belief that there will be little to no problems with normal operations other that a dramatic decrease in spammer/hacker traffic. Michael -------------- next part -------------- An HTML attachment was scrubbed... URL: From websitemaster at cogeco.net Thu Sep 22 14:09:44 2011 From: websitemaster at cogeco.net (Tom) Date: Thu, 22 Sep 2011 14:09:44 -0400 Subject: [geeklog-devel] New addition to the demo site - zbblock In-Reply-To: <000901cc7945$a22d8be0$fe00a8c0@node1> References: <000901cc7945$a22d8be0$fe00a8c0@node1> Message-ID: <00e301cc7952$ce5492b0$6afdb810$@cogeco.net> Hey Michael, I just noticed on the demo site that the "Welcome to Geeklog" story contains links to the old forum plugins website. Could you update it to http://code.google.com/p/geeklog/ when you get a chance? The Captcha plugin also has been taken over by Ben of Geeklog.fr In regards to your email, I haven't heard of ZB Block before, I will have to read up on it. Thanks Tom From: geeklog-devel-bounces at lists.geeklog.net [mailto:geeklog-devel-bounces at lists.geeklog.net] On Behalf Of Michael Brusletten Sent: September-22-11 12:35 PM To: geeklog-devel at lists.geeklog.net Subject: [geeklog-devel] New addition to the demo site - zbblock To All: I have added ZBBLOCK to the Geeklog Demo Site because I thought it was time to finally stop the onslaught of really bad behavior that should not be let into the site in the first place. What this script does is the following: This php security script is designed to detect certain behaviors detrimental to websites, or known bad addresses attempting to access your site. It then will send the bad robot (usually) or hacker an authentic 403 FORBIDDEN page with a description of what the problem was. If the attacker persists, then they will be served up a permanently reccurring 503 OVERLOAD message with a 24 hour timeout. If you are looking for a script to help with protection of a Counter-Strike Gaming server, this is not the zBlock program you are looking for. You can find them at http://zblock.mgamez.eu/ , however, many of the same sites could also benefit from what this site has to offer. The name is purely coincidental (I have been using the moniker Zaphod Breeblebrox for 25 years), and their version number is V. 4.4 a post-release. While ZB Block (double Bs and a space) is still in beta development. What ZB Block is Excellent at: * Saves money by reducing hacker bandwith usage! (by 2,500% on this site's index page alone!) * Strengthing your site against defacement. * Preventing PHP script exploitation. * Ending Remote File Include (RFI) exploits. * Protecting against directory traversal attacks. * Stopping MySQL database injection and tampering. * Removing access from known bad addresses and domain names. * Blocking access from top level domains, like .cn (China) and .kp (North Korea). What ZB Block is Good at: * Avoiding website scraping/content theft. * Deterring bad user agents. * Halting referrer spam. * Impeding some Cross Site Scripting (XSS) attacks. What ZB Block will not do: * Protect non-PHP pages. * Stop access to non-exploitable resource files like .gif, .jpg, or .swf . ZB Block is also fast, not only does ZB Block check for over 100,000,000 bad IPs/Hostnames and many thousands of bots, but standard execution times are around 1/10th of a second on an aged PIII 930, which is unnoticable to the web surfer. This anti-exploit / anti-'sploit / anti-hacking / anti-injection script should find many uses around the web as it's good at detecting, and stopping exploitation probes from many of the worst known skript kiddie tools. Why ZB Block is BETTER than .htaccess methods... 1. Under certiain tasks, it is FASTER than htaccess due to only polling the server for data once per execution. An example of this is domain blocking. 2. It will run on webservers that do not support the full gamut of .htaccess commands (And there are quite a few). 3. It allows for intelligent detection of problem clients without previous knowledge of their address. 4. It can sniff query strings to find attack sequences from all IPs, while allowing legitimate requests to go through. 5. Through proper signature use, it can automatically remove some blocks that have met a condition. (such as registration of domain) 6. It can ban whole whole ranges of IPs written in classic decimal quadot notation. You can put your own custom ones in the signatures like 193.189.126.5 through 193.189.127.252 . (.htaccess gets a big FAIL! on dealing with IPs as it uses tricky to maintain CIDR ranges that only work in a most signifigant bit (MSB) method, sometimes requiring multiple entries for oddball ranges. 'Did I really include all the IPs? Did I accidentally go to far?') 7. Some hosts don't like custom 403s, so they don't allow you to use your own .htaccess driven 403. ZB Block doesn't care if the .htaccess is emplaced. 8. It logs banned accesses for later review in plain, easy to read english, with a description as to why said session was blocked. 9. It's simple and easy to use, and requires no authorization beyond the ability to upload files to your php equipped web-server. 10. Most importantly, it slows down evil robot machines to a crawl (sometimes) and helps alleviate (we hope) your fellow hosts/webmasters from some of the unwanted traffic! 11. For more information, see http://www.spambotsecurity.com/zbblock.php To download the script, goto their site http://www.spambotsecurity.com/zbblock.php and check it out. I have added a message to the 404 Error page that will be shown to those that have issues to copy and paste the message they get in a forum post on the geeklog site for help. However, it is my belief that there will be little to no problems with normal operations other that a dramatic decrease in spammer/hacker traffic. Michael -------------- next part -------------- An HTML attachment was scrubbed... URL: From dirk at haun-online.de Thu Sep 22 14:58:30 2011 From: dirk at haun-online.de (Dirk Haun) Date: Thu, 22 Sep 2011 20:58:30 +0200 Subject: [geeklog-devel] Installing Geeklog affects plugins that install blocks In-Reply-To: <003701cc786d$f6a468c0$e3ed3a40$@cogeco.net> References: <003701cc786d$f6a468c0$e3ed3a40$@cogeco.net> Message-ID: Tom wrote: > Currently when a plugin wants to add a block it just goes ahead and accesses the block table directly. Well as of 1.9.0 the block table has changed since it doesn?t need the tid column (for topics) any more. This breaks installing plugins that add blocks like polls and the forum. > > While I can go ahead and fix the polls plugin, 3rd party plugins are another matter. What should we do here? I don't really have a good idea for that case. I guess we could leave the tid in and call it "deprecated" or unused, but that's a bit messy. The other alternative is to accept breakage and tell the plugin authors to update their plugins. > Also to fix this problem in the future (this doesn?t help with the issue above) I propose adding some functions to the plugins library that will handle adding, deleting and updating (enabling, disabling, etc.) blocks. Do we need plugin API functions or would it be enough to add an entry in the structure that plugin_autoinstall_xxx returns? Do you need to be able to add a block at runtime? > Should we attempt to tidy this up and what would the best way be? It would be nice if Geeklog could take care of removing the blocks when a plugin is uninstalled. We would need a way to know which block belongs to which plugin. A naming convention could be one solution (while we're breaking compatibility anyway) or an additional entry in the blocks table. bye, Dirk From websitemaster at cogeco.net Thu Sep 22 20:50:00 2011 From: websitemaster at cogeco.net (Tom) Date: Thu, 22 Sep 2011 20:50:00 -0400 Subject: [geeklog-devel] Installing Geeklog affects plugins that install blocks In-Reply-To: References: <003701cc786d$f6a468c0$e3ed3a40$@cogeco.net> Message-ID: <010701cc798a$b9723860$2c56a920$@cogeco.net> >> I don't really have a good idea for that case. I guess we could leave the tid in and call it "deprecated" or unused, but that's a bit messy. The other alternative is to accept breakage and >> tell the plugin authors to update their plugins. Those where my thoughts as well. I think it would be best to break the plugins. I will give plugin authors as much notice as possible once the api and table structure is defined. >> Do we need plugin API functions or would it be enough to add an entry in the structure that plugin_autoinstall_xxx returns? It would be safer if we do so just in case of changes to the table in the future and then we most likely will not have to break the plugin. We already have plugin_getBlocks_xxx which allows plugins to specify a block to appear on a side and for a certain topic. I guess the main problem with it is you cannot specify an order. Maybe we can just expand this api in some way? I am going to have to create some plugin api for topics anyways so I will see what I come up with for blocks and get back to everyone. (unless anyone has any other ideas) >> Do you need to be able to add a block at runtime? Probably not, I guess it depends if plugins delete blocks not in use or just disables them. >> A naming convention could be one solution (while we're breaking compatibility anyway) or an additional entry in the blocks table. Are you thinking of the naming convention for the Block Name? In regards to my other email should the block name be unique or not? 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: September-22-11 2:59 PM To: Geeklog Development Subject: Re: [geeklog-devel] Installing Geeklog affects plugins that install blocks Tom wrote: > Currently when a plugin wants to add a block it just goes ahead and accesses the block table directly. Well as of 1.9.0 the block table has changed since it doesn't need the tid column (for topics) any more. This breaks installing plugins that add blocks like polls and the forum. > > While I can go ahead and fix the polls plugin, 3rd party plugins are another matter. What should we do here? I don't really have a good idea for that case. I guess we could leave the tid in and call it "deprecated" or unused, but that's a bit messy. The other alternative is to accept breakage and tell the plugin authors to update their plugins. > Also to fix this problem in the future (this doesn't help with the issue above) I propose adding some functions to the plugins library that will handle adding, deleting and updating (enabling, disabling, etc.) blocks. Do we need plugin API functions or would it be enough to add an entry in the structure that plugin_autoinstall_xxx returns? Do you need to be able to add a block at runtime? > Should we attempt to tidy this up and what would the best way be? It would be nice if Geeklog could take care of removing the blocks when a plugin is uninstalled. We would need a way to know which block belongs to which plugin. A naming convention could be one solution (while we're breaking compatibility anyway) or an additional entry in the blocks table. 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 Thu Sep 22 21:27:19 2011 From: websitemaster at cogeco.net (Tom) Date: Thu, 22 Sep 2011 21:27:19 -0400 Subject: [geeklog-devel] Installing Geeklog affects plugins that install blocks In-Reply-To: <010701cc798a$b9723860$2c56a920$@cogeco.net> References: <003701cc786d$f6a468c0$e3ed3a40$@cogeco.net> <010701cc798a$b9723860$2c56a920$@cogeco.net> Message-ID: <010c01cc798f$efbb3750$cf31a5f0$@cogeco.net> To answer one of my own questions after looking at PLG_getBlocks more and the wiki (http://wiki.geeklog.net/index.php/Dynamic_Blocks) as well the search rank plugin I think for most cases plugins can use plugin_getBlocks_xxx because you can specify the order as well. This means plugins shouldn't really be playing with the blocks table. (unless I am missing something here) I will update the polls plugin to use a dynamic block. Looking at the forum plugin it's phpblock_forum_newposts block could work as a dynamic but the forum menu block will still have problems since it needs to display only when the forum is displayed. This information doesn't get passed to the api and I am not really sure at the moment the best way to do this (ideas???) Ben ... Your Paypal plugin uses blocks I believe, if they are not currently dynamic would you have any problems converting them to dynamic or have I overlooked something? Tom -----Original Message----- From: geeklog-devel-bounces at lists.geeklog.net [mailto:geeklog-devel-bounces at lists.geeklog.net] On Behalf Of Tom Sent: September-22-11 8:50 PM To: 'Geeklog Development' Subject: Re: [geeklog-devel] Installing Geeklog affects plugins that install blocks >> I don't really have a good idea for that case. I guess we could leave >> the tid in and call it "deprecated" or unused, but that's a bit messy. The other alternative is to accept breakage and >> tell the plugin authors to update their plugins. Those where my thoughts as well. I think it would be best to break the plugins. I will give plugin authors as much notice as possible once the api and table structure is defined. >> Do we need plugin API functions or would it be enough to add an entry >> in the structure that plugin_autoinstall_xxx returns? It would be safer if we do so just in case of changes to the table in the future and then we most likely will not have to break the plugin. We already have plugin_getBlocks_xxx which allows plugins to specify a block to appear on a side and for a certain topic. I guess the main problem with it is you cannot specify an order. Maybe we can just expand this api in some way? I am going to have to create some plugin api for topics anyways so I will see what I come up with for blocks and get back to everyone. (unless anyone has any other ideas) >> Do you need to be able to add a block at runtime? Probably not, I guess it depends if plugins delete blocks not in use or just disables them. >> A naming convention could be one solution (while we're breaking compatibility anyway) or an additional entry in the blocks table. Are you thinking of the naming convention for the Block Name? In regards to my other email should the block name be unique or not? 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: September-22-11 2:59 PM To: Geeklog Development Subject: Re: [geeklog-devel] Installing Geeklog affects plugins that install blocks Tom wrote: > Currently when a plugin wants to add a block it just goes ahead and accesses the block table directly. Well as of 1.9.0 the block table has changed since it doesn't need the tid column (for topics) any more. This breaks installing plugins that add blocks like polls and the forum. > > While I can go ahead and fix the polls plugin, 3rd party plugins are another matter. What should we do here? I don't really have a good idea for that case. I guess we could leave the tid in and call it "deprecated" or unused, but that's a bit messy. The other alternative is to accept breakage and tell the plugin authors to update their plugins. > Also to fix this problem in the future (this doesn't help with the > issue above) I propose adding some functions to the plugins library that will handle adding, deleting and updating (enabling, disabling, etc.) blocks. Do we need plugin API functions or would it be enough to add an entry in the structure that plugin_autoinstall_xxx returns? Do you need to be able to add a block at runtime? > Should we attempt to tidy this up and what would the best way be? It would be nice if Geeklog could take care of removing the blocks when a plugin is uninstalled. We would need a way to know which block belongs to which plugin. A naming convention could be one solution (while we're breaking compatibility anyway) or an additional entry in the blocks table. 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 ironmax at spacequad.com Thu Sep 22 22:15:28 2011 From: ironmax at spacequad.com (Michael Brusletten) Date: Thu, 22 Sep 2011 22:15:28 -0400 Subject: [geeklog-devel] New addition to the demo site - zbblock References: Message-ID: <000801cc7996$a9d781b0$fe00a8c0@node1> Tom, All should be fixed in regards to what you mentioned below now. I did notice one user make a post about the ZBBLOCK that they could not enter the site from their home computer, but had no problem from other systems outside their home. Unfortunately, I cannot help this user unless they are willing to provide the requested information to help me track down why they were blocked. It could be something so simple, that I could make an adjustment to my script. Perhaps I could turn on direct email to a special email account I could setup, so that they could click and I get this information with a message from them. Here are just a few log entries I've pasted here, so you can see examples of what it blocks. The first entry is the test url to verify it works. #: 1 @: Thu, 22 Sep 2011 08:27:39 -0400 Running: 0.4.9_Final Host: node1.spacequad.com IP: 192.168.0.254 Score: 1 Violation count: 0 Why blocked: QUERY Test Trigger to test function. Query: test=xtestx Referer: User Agent: Mozilla/5.0 (Windows NT 5.0; rv:5.0.1) Gecko/20100101 Firefox/5.0.1 Reconstructed URL: http:// demo.geeklog.net /index.php?test=xtestx #: 2 @: Thu, 22 Sep 2011 08:30:13 -0400 Running: 0.4.9_Final Host: ec2-50-16-26-215.compute-1.amazonaws.com IP: 50.16.26.215 Score: 1 Violation count: 1 Why blocked: Amazon Web Services. Not an ISP. Used by hackers, Keyword spamming SEO bots, and other unsavories. Checked for bypass - Query: Referer: User Agent: Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 5.1; Trident/4.0; GTB6.4) Reconstructed URL: http:// demo.geeklog.net /index.php #: 3 @: Thu, 22 Sep 2011 08:33:56 -0400 Running: 0.4.9_Final Host: alexandria84.etcserver.com IP: 174.123.137.18 Score: 1 Violation count: 1 Why blocked: Scrapebot, SEO scum. Query: method=newtopic&forum=1 Referer: http://demo.geeklog.net/ User Agent: Mozilla/4.0 (vBSEO; http://www.vbseo.com) Reconstructed URL: http:// demo.geeklog.net /forum/createtopic.php?method=newtopic&forum=1 #: 4 @: Thu, 22 Sep 2011 08:44:57 -0400 Running: 0.4.9_Final Host: sentriless-lantern.volia.net IP: 93.72.18.22 Score: 3 Violation count: 1 INSTA-BANNED Why blocked: Robot Probe. INSTA-BAN. Bot UA. RBN. You have been instantly banned due to extremely hazardous behavior! Query: method=newtopic&forum=1 Referer: http://demo.geeklog.net/forum/createtopic.php?method=newtopic&forum=1 User Agent: Mozilla/0.91 Beta (Windows) Reconstructed URL: http:// demo.geeklog.net /forum/createtopic.php?method=newtopic&forum=1 #: 5 @: Thu, 22 Sep 2011 08:54:03 -0400 Running: 0.4.9_Final Host: chols252.krypt.com IP: 98.126.47.234 Score: 2 Violation count: 1 Why blocked: RFI attack/SQL injection (some browser plugins like Linkification for Firefox may cause this). Execution Attempt. Query: method=newtopic&forum=1+Result:+captcha+recognized;+choosen+values+in+select +field+-+%22blah%22;+success+-+posted+to+first+encountered+partition+%22inde x.php?forum=1%22;+BB-code+not+working; Referer: http://www.discountonline-uggboots.com] User Agent: Mozilla/4.76 [en] (Windows NT 5.0; U) Reconstructed URL: http:// demo.geeklog.net /forum/createtopic.php?method=newtopic&forum=1+Result:+captcha+recognized;+c hoosen+values+in+select+field+-+%22blah%22;+success+-+posted+to+first+encoun tered+partition+%22index.php?forum=1%22;+BB-code+not+working; #: 6 @: Thu, 22 Sep 2011 08:54:12 -0400 Running: 0.4.9_Final Host: chols252.krypt.com IP: 98.126.47.234 Score: 2 Violation count: 2 Why blocked: RFI attack/SQL injection (some browser plugins like Linkification for Firefox may cause this). Execution Attempt. Query: method=newtopic&forum=1+Result:+captcha+recognized;+choosen+values+in+select +field+-+%22blah%22;+success+-+posted+to+first+encountered+partition+%22inde x.php?forum=1%22;+BB-code+not+working; Referer: http://demo.geeklog.net/forum/createtopic.php?method=newtopic&forum=1+result:+captcha+recognized;+choosen+values+in+select+field+-+%22blah%22;+success+-+posted+to+first+encountered+partition+%22index.php?forum=1%22;+bb-code+not+working; User Agent: Mozilla/4.76 [en] (Windows NT 5.0; U) Reconstructed URL: http:// demo.geeklog.net /forum/createtopic.php?method=newtopic&forum=1+Result:+captcha+recognized;+c hoosen+values+in+select+field+-+%22blah%22;+success+-+posted+to+first+encoun tered+partition+%22index.php?forum=1%22;+BB-code+not+working; #: 7 @: Thu, 22 Sep 2011 09:02:23 -0400 Running: 0.4.9_Final Host: 70-40-95-178.pool.ukrtel.net IP: 178.95.40.70 Score: 1 Violation count: 1 Why blocked: ukrtel, forum spambots. Query: method=newtopic&forum=1 Referer: http://demo.geeklog.net/forum/createtopic.php?method=newtopic&forum=1 User Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; MRA 4.6 (build 01425)) Reconstructed URL: http:// demo.geeklog.net /forum/createtopic.php?method=newtopic&forum=1 #: 8 @: Thu, 22 Sep 2011 09:02:31 -0400 Running: 0.4.9_Final Host: 70-40-95-178.pool.ukrtel.net IP: 178.95.40.70 Score: 1 Violation count: 2 Why blocked: ukrtel, forum spambots. Query: Referer: http://demo.geeklog.net/forum/createtopic.php?method=newtopic&forum=1 User Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; MRA 4.6 (build 01425)) Reconstructed URL: http:// demo.geeklog.net /index.php Hopefully with some tweaking, I can forgo the perminant ban after the 3 strike rule and just provide the user with the actual error page everytime, instead a few words that they've been banned. Michael > ------------------------------ > > Message: 2 > Date: Thu, 22 Sep 2011 14:09:44 -0400 > From: "Tom" > Subject: Re: [geeklog-devel] New addition to the demo site - zbblock > To: "'Geeklog Development'" > Message-ID: <00e301cc7952$ce5492b0$6afdb810$@cogeco.net> > Content-Type: text/plain; charset="us-ascii" > > Hey Michael, > > > > I just noticed on the demo site that the "Welcome to Geeklog" story > contains links to the old forum plugins website. Could you update it to > http://code.google.com/p/geeklog/ when you get a chance? > > > > The Captcha plugin also has been taken over by Ben of Geeklog.fr > > > > In regards to your email, I haven't heard of ZB Block before, I will have to > read up on it. > > > > Thanks > > > > Tom > > > > From: geeklog-devel-bounces at lists.geeklog.net > [mailto:geeklog-devel-bounces at lists.geeklog.net] On Behalf Of Michael > Brusletten > Sent: September-22-11 12:35 PM > To: geeklog-devel at lists.geeklog.net > Subject: [geeklog-devel] New addition to the demo site - zbblock > > > > To All: > > > > I have added ZBBLOCK to the > Geeklog Demo Site because I thought it was time to finally stop the > onslaught of really bad behavior that should not be let into the site in the > first place. What this script does is the following: > > > > This php security script is designed to detect certain behaviors detrimental > to websites, or known bad addresses attempting to access your site. It then > will send the bad robot (usually) or hacker an authentic 403 FORBIDDEN page > with a description of what the problem was. If the attacker persists, then > they will be served up a permanently reccurring 503 OVERLOAD message with a > 24 hour timeout. > > If you are looking for a script to help with protection of a Counter-Strike > Gaming server, this is not the zBlock program you are looking for. You can > find them at http://zblock.mgamez.eu/ , however, > many of the same sites could also benefit from what this site has to offer. > The name is purely coincidental (I have been using the moniker Zaphod > Breeblebrox for 25 years), and their version number is V. 4.4 a > post-release. While ZB Block (double Bs and a space) is still in beta > development. > > > What ZB Block is Excellent at: > > > * Saves money by reducing hacker bandwith usage! (by 2,500% on this > site's index page alone!) > * Strengthing your site against defacement. > * Preventing PHP script exploitation. > * Ending Remote File Include (RFI) exploits. > * Protecting against directory traversal attacks. > * Stopping MySQL database injection and tampering. > * Removing access from known bad addresses and domain names. > * Blocking access from top level domains, like .cn (China) and .kp > (North Korea). > > > What ZB Block is Good at: > > > * Avoiding website scraping/content theft. > * Deterring bad user agents. > * Halting referrer spam. > * Impeding some Cross Site Scripting (XSS) attacks. > > > What ZB Block will not do: > > > * Protect non-PHP pages. > * Stop access to non-exploitable resource files like .gif, .jpg, or > .swf . > > ZB Block is also fast, not only does ZB Block check for over 100,000,000 bad > IPs/Hostnames and many thousands of bots, but standard execution times are > around 1/10th of a second on an aged PIII 930, which is unnoticable to the > web surfer. This anti-exploit / anti-'sploit / anti-hacking / anti-injection > script should find many uses around the web as it's good at detecting, and > stopping exploitation probes from many of the worst known skript kiddie > tools. > > > > > Why ZB Block is BETTER than .htaccess methods... > > > 1. Under certiain tasks, it is FASTER than htaccess due to only polling > the server for data once per execution. An example of this is domain > blocking. > 2. It will run on webservers that do not support the full gamut of > .htaccess commands (And there are quite a few). > 3. It allows for intelligent detection of problem clients without > previous knowledge of their address. > 4. It can sniff query strings to find attack sequences from all IPs, > while allowing legitimate requests to go through. > 5. Through proper signature use, it can automatically remove some > blocks that have met a condition. (such as registration of domain) > 6. It can ban whole whole ranges of IPs written in classic decimal > quadot notation. You can put your own custom ones in the signatures like > 193.189.126.5 through 193.189.127.252 . (.htaccess gets a big FAIL! on > dealing with IPs as it uses tricky to maintain CIDR ranges that only work in > a most signifigant bit (MSB) method, sometimes requiring multiple entries > for oddball ranges. 'Did I really include all the IPs? Did I accidentally go > to far?') > 7. Some hosts don't like custom 403s, so they don't allow you to use > your own .htaccess driven 403. ZB Block doesn't care if the .htaccess is > emplaced. > 8. It logs banned accesses for later review in plain, easy to read > english, with a description as to why said session was blocked. > 9. It's simple and easy to use, and requires no authorization beyond > the ability to upload files to your php equipped web-server. > 10. Most importantly, it slows down evil robot machines to a crawl > (sometimes) and helps alleviate (we hope) your fellow hosts/webmasters from > some of the unwanted traffic! > 11. For more information, see http://www.spambotsecurity.com/zbblock.php > > To download the script, goto their site > http://www.spambotsecurity.com/zbblock.php and check it out. > > > > I have added a message to the 404 Error page that will be shown to those > that have issues to copy and paste the message they get in a forum post on > the geeklog site for help. However, it is my belief that there will be > little to no problems with normal operations other that a dramatic decrease > in spammer/hacker traffic. > > > > Michael > > From rouslan at placella.com Fri Sep 23 06:44:39 2011 From: rouslan at placella.com (Rouslan Placella) Date: Fri, 23 Sep 2011 11:44:39 +0100 Subject: [geeklog-devel] Installing Geeklog affects plugins that install blocks In-Reply-To: <010c01cc798f$efbb3750$cf31a5f0$@cogeco.net> References: <003701cc786d$f6a468c0$e3ed3a40$@cogeco.net> <010701cc798a$b9723860$2c56a920$@cogeco.net> <010c01cc798f$efbb3750$cf31a5f0$@cogeco.net> Message-ID: <1316774679.1965.0.camel@roccivic-pc> On Thu, 2011-09-22 at 21:27 -0400, Tom wrote: > To answer one of my own questions after looking at PLG_getBlocks more and > the wiki (http://wiki.geeklog.net/index.php/Dynamic_Blocks) as well the > search rank plugin I think for most cases plugins can use > plugin_getBlocks_xxx because you can specify the order as well. This means > plugins shouldn't really be playing with the blocks table. (unless I am > missing something here) The problem with dynamic blocks is that there is zero support for "group" privileges... > I will update the polls plugin to use a dynamic block. Looking at the forum > plugin it's phpblock_forum_newposts block could work as a dynamic but the > forum menu block will still have problems since it needs to display only > when the forum is displayed. This information doesn't get passed to the api > and I am not really sure at the moment the best way to do this (ideas???) > > Ben ... Your Paypal plugin uses blocks I believe, if they are not currently > dynamic would you have any problems converting them to dynamic or have I > overlooked something? > > Tom > > > > -----Original Message----- > From: geeklog-devel-bounces at lists.geeklog.net > [mailto:geeklog-devel-bounces at lists.geeklog.net] On Behalf Of Tom > Sent: September-22-11 8:50 PM > To: 'Geeklog Development' > Subject: Re: [geeklog-devel] Installing Geeklog affects plugins that install > blocks > > >> I don't really have a good idea for that case. I guess we could leave > >> the > tid in and call it "deprecated" or unused, but that's a bit messy. The other > alternative is to accept breakage and >> tell the plugin authors to update > their plugins. > > Those where my thoughts as well. I think it would be best to break the > plugins. I will give plugin authors as much notice as possible once the api > and table structure is defined. > > >> Do we need plugin API functions or would it be enough to add an entry > >> in > the structure that plugin_autoinstall_xxx returns? > > It would be safer if we do so just in case of changes to the table in the > future and then we most likely will not have to break the plugin. We > already have plugin_getBlocks_xxx which allows plugins to specify a block to > appear on a side and for a certain topic. I guess the main problem with it > is you cannot specify an order. Maybe we can just expand this api in some > way? > > I am going to have to create some plugin api for topics anyways so I will > see what I come up with for blocks and get back to everyone. (unless anyone > has any other ideas) > > >> Do you need to be able to add a block at runtime? > > Probably not, I guess it depends if plugins delete blocks not in use or just > disables them. > > >> A naming convention could be one solution (while we're breaking > compatibility anyway) or an additional entry in the blocks table. > > Are you thinking of the naming convention for the Block Name? In regards to > my other email should the block name be unique or not? > > 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: September-22-11 2:59 PM > To: Geeklog Development > Subject: Re: [geeklog-devel] Installing Geeklog affects plugins that install > blocks > > Tom wrote: > > > Currently when a plugin wants to add a block it just goes ahead and > accesses the block table directly. Well as of 1.9.0 the block table has > changed since it doesn't need the tid column (for topics) any more. This > breaks installing plugins that add blocks like polls and the forum. > > > > While I can go ahead and fix the polls plugin, 3rd party plugins are > another matter. What should we do here? > > I don't really have a good idea for that case. I guess we could leave the > tid in and call it "deprecated" or unused, but that's a bit messy. The other > alternative is to accept breakage and tell the plugin authors to update > their plugins. > > > > Also to fix this problem in the future (this doesn't help with the > > issue > above) I propose adding some functions to the plugins library that will > handle adding, deleting and updating (enabling, disabling, etc.) blocks. > > Do we need plugin API functions or would it be enough to add an entry in the > structure that plugin_autoinstall_xxx returns? Do you need to be able to add > a block at runtime? > > > > Should we attempt to tidy this up and what would the best way be? > > It would be nice if Geeklog could take care of removing the blocks when a > plugin is uninstalled. We would need a way to know which block belongs to > which plugin. A naming convention could be one solution (while we're > breaking compatibility anyway) or an additional entry in the blocks table. > > 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 > > _______________________________________________ > geeklog-devel mailing list > geeklog-devel at lists.geeklog.net > http://eight.pairlist.net/mailman/listinfo/geeklog-devel From websitemaster at cogeco.net Fri Sep 23 10:17:18 2011 From: websitemaster at cogeco.net (Tom) Date: Fri, 23 Sep 2011 10:17:18 -0400 Subject: [geeklog-devel] Installing Geeklog affects plugins that install blocks In-Reply-To: <1316774679.1965.0.camel@roccivic-pc> References: <003701cc786d$f6a468c0$e3ed3a40$@cogeco.net> <010701cc798a$b9723860$2c56a920$@cogeco.net> <010c01cc798f$efbb3750$cf31a5f0$@cogeco.net> <1316774679.1965.0.camel@roccivic-pc> Message-ID: <013b01cc79fb$805b6fd0$81124f70$@cogeco.net> >> The problem with dynamic blocks is that there is zero support for "group" privileges... I hadn't thought of that... This could be assigned in the Configuration could it not like you did for the other options in the search rank plugin and then checked when the plugin_getBlocks_xxx is run? (a group dropdown would have to be created for the configuration though). The plugin would also have to deal with group deletes on that configuration option and change it to some sort of default. On a related note I guess we should also do something similar with topics so we can assign a dynamic block in the configuration to a topic as well. I guess the only thing I do not like about all this is that this makes managing blocks a little more difficult since it is not all done via the Geeklog Block Manager. I just did a test with the polls plugin and notice that it does not handle group deletes at all (it should use plugin_group_changed_xxx). I deleted the Polls Admin and lost access to the polls admin forms (but not the configuration for some reason). Plus when I look at the database I still see the polls block and a poll still assigned to the old Polls Admin id (19). I just did another test and assigned a story to a group I just created. I then deleted the group but I still see the story in the db assigned to that group. Stories does not handle it either and I am willing to bet the other core plugins do not as well. I guess the first question is should we allow Plugin Admin groups to be deleted? I do not really want to add another group type (I guess they could be considered a core group) but I think that it is okay as long as everything gets reassigned properly. I guess in situations like this the polls plugin should have reassigned all of its objects that are assigned to the deleted group to first the Polls Admin Group (if it exists) and then the root group if it does not. Thoughts? 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: September-23-11 6:45 AM To: geeklog-devel at lists.geeklog.net Subject: Re: [geeklog-devel] Installing Geeklog affects plugins that install blocks On Thu, 2011-09-22 at 21:27 -0400, Tom wrote: > To answer one of my own questions after looking at PLG_getBlocks more > and the wiki (http://wiki.geeklog.net/index.php/Dynamic_Blocks) as > well the search rank plugin I think for most cases plugins can use > plugin_getBlocks_xxx because you can specify the order as well. This > means plugins shouldn't really be playing with the blocks table. > (unless I am missing something here) The problem with dynamic blocks is that there is zero support for "group" privileges... > I will update the polls plugin to use a dynamic block. Looking at the > forum plugin it's phpblock_forum_newposts block could work as a > dynamic but the forum menu block will still have problems since it > needs to display only when the forum is displayed. This information > doesn't get passed to the api and I am not really sure at the moment > the best way to do this (ideas???) > > Ben ... Your Paypal plugin uses blocks I believe, if they are not > currently dynamic would you have any problems converting them to > dynamic or have I overlooked something? > > Tom > > > > -----Original Message----- > From: geeklog-devel-bounces at lists.geeklog.net > [mailto:geeklog-devel-bounces at lists.geeklog.net] On Behalf Of Tom > Sent: September-22-11 8:50 PM > To: 'Geeklog Development' > Subject: Re: [geeklog-devel] Installing Geeklog affects plugins that > install blocks > > >> I don't really have a good idea for that case. I guess we could > >> leave the > tid in and call it "deprecated" or unused, but that's a bit messy. The > other alternative is to accept breakage and >> tell the plugin authors > to update their plugins. > > Those where my thoughts as well. I think it would be best to break the > plugins. I will give plugin authors as much notice as possible once > the api and table structure is defined. > > >> Do we need plugin API functions or would it be enough to add an > >> entry in > the structure that plugin_autoinstall_xxx returns? > > It would be safer if we do so just in case of changes to the table in > the future and then we most likely will not have to break the plugin. > We already have plugin_getBlocks_xxx which allows plugins to specify a > block to appear on a side and for a certain topic. I guess the main > problem with it is you cannot specify an order. Maybe we can just > expand this api in some way? > > I am going to have to create some plugin api for topics anyways so I > will see what I come up with for blocks and get back to everyone. > (unless anyone has any other ideas) > > >> Do you need to be able to add a block at runtime? > > Probably not, I guess it depends if plugins delete blocks not in use > or just disables them. > > >> A naming convention could be one solution (while we're breaking > compatibility anyway) or an additional entry in the blocks table. > > Are you thinking of the naming convention for the Block Name? In > regards to my other email should the block name be unique or not? > > 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: September-22-11 2:59 PM > To: Geeklog Development > Subject: Re: [geeklog-devel] Installing Geeklog affects plugins that > install blocks > > Tom wrote: > > > Currently when a plugin wants to add a block it just goes ahead and > accesses the block table directly. Well as of 1.9.0 the block table > has changed since it doesn't need the tid column (for topics) any > more. This breaks installing plugins that add blocks like polls and the forum. > > > > While I can go ahead and fix the polls plugin, 3rd party plugins are > another matter. What should we do here? > > I don't really have a good idea for that case. I guess we could leave > the tid in and call it "deprecated" or unused, but that's a bit messy. > The other alternative is to accept breakage and tell the plugin > authors to update their plugins. > > > > Also to fix this problem in the future (this doesn't help with the > > issue > above) I propose adding some functions to the plugins library that > will handle adding, deleting and updating (enabling, disabling, etc.) blocks. > > Do we need plugin API functions or would it be enough to add an entry > in the structure that plugin_autoinstall_xxx returns? Do you need to > be able to add a block at runtime? > > > > Should we attempt to tidy this up and what would the best way be? > > It would be nice if Geeklog could take care of removing the blocks > when a plugin is uninstalled. We would need a way to know which block > belongs to which plugin. A naming convention could be one solution > (while we're breaking compatibility anyway) or an additional entry in the blocks table. > > 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 > > _______________________________________________ > 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 dirk at haun-online.de Sat Sep 24 02:53:42 2011 From: dirk at haun-online.de (Dirk Haun) Date: Sat, 24 Sep 2011 08:53:42 +0200 Subject: [geeklog-devel] 1.8.1 In-Reply-To: <74018DD2-E2D2-4B87-B0C2-18EC213AD460@haun-online.de> References: <20110624133138.9164384jmqc7tuas@webmail.df.eu> <1308916307.1804.8.camel@roccivic-pc> <025901cc3267$570753a0$0515fae0$@cogeco.net> <20110624164720.9052387slu8vhl0k@webmail.df.eu> <312E4896-7DC1-4197-A1CB-0806E1151F0D@haun-online.de> <009801cc6c17$98ee1850$caca48f0$@cogeco.net> <7554C68E-0B1D-4636-BE78-5B7AF4A8781B@haun-online.de> <00e001cc6c9e$bf687bb0$3e397310$@cogeco.net> <74018DD2-E2D2-4B87-B0C2-18EC213AD460@haun-online.de> Message-ID: <7E72692B-6360-4DB3-B171-9F7162EAFF48@haun-online.de> Almost forgot about 1.8.1 ;-) I haven't heard of any problems, so I guess we're good to go? bye, Dirk From komma at ivywe.co.jp Sat Sep 24 03:32:59 2011 From: komma at ivywe.co.jp (=?ISO-2022-JP?B?GyRCOiM2cEUvO1IbKEIgR2Vla2xvZyBJdnlXZQ==?=) Date: Sat, 24 Sep 2011 16:32:59 +0900 Subject: [geeklog-devel] 1.8.1 In-Reply-To: <7E72692B-6360-4DB3-B171-9F7162EAFF48@haun-online.de> References: <20110624133138.9164384jmqc7tuas@webmail.df.eu> <1308916307.1804.8.camel@roccivic-pc> <025901cc3267$570753a0$0515fae0$@cogeco.net> <20110624164720.9052387slu8vhl0k@webmail.df.eu> <312E4896-7DC1-4197-A1CB-0806E1151F0D@haun-online.de> <009801cc6c17$98ee1850$caca48f0$@cogeco.net> <7554C68E-0B1D-4636-BE78-5B7AF4A8781B@haun-online.de> <00e001cc6c9e$bf687bb0$3e397310$@cogeco.net> <74018DD2-E2D2-4B87-B0C2-18EC213AD460@haun-online.de> <7E72692B-6360-4DB3-B171-9F7162EAFF48@haun-online.de> Message-ID: Dirk, calendar plugin configuration http://demo.geeklog.net/admin/configuration.php I ca't delete Event Types by using X button. demo site and onother some site, error occurred. but some site(1.8.0) are Okay. 2011/9/24 Dirk Haun : > Almost forgot about 1.8.1 ;-) > > I haven't heard of any problems, so I guess we're good to go? > > bye, Dirk -- Ivy From dirk at haun-online.de Sat Sep 24 04:38:53 2011 From: dirk at haun-online.de (Dirk Haun) Date: Sat, 24 Sep 2011 10:38:53 +0200 Subject: [geeklog-devel] 1.8.1 In-Reply-To: References: <20110624133138.9164384jmqc7tuas@webmail.df.eu> <1308916307.1804.8.camel@roccivic-pc> <025901cc3267$570753a0$0515fae0$@cogeco.net> <20110624164720.9052387slu8vhl0k@webmail.df.eu> <312E4896-7DC1-4197-A1CB-0806E1151F0D@haun-online.de> <009801cc6c17$98ee1850$caca48f0$@cogeco.net> <7554C68E-0B1D-4636-BE78-5B7AF4A8781B@haun-online.de> <00e001cc6c9e$bf687bb0$3e397310$@cogeco.net> <74018DD2-E2D2-4B87-B0C2-18EC213AD460@haun-online.de> <7E72692B-6360-4DB3-B171-9F7162EAFF48@haun-online.de> Message-ID: ???? Geeklog IvyWe wrote: > calendar plugin configuration > http://demo.geeklog.net/admin/configuration.php > I ca't delete Event Types by using X button. > > demo site and onother some site, error occurred. > but some site(1.8.0) are Okay. Works for me. On the demo site as well as on a local fresh install of 1.8.1. Anyone else seeing this? bye, Dirk From komma at ivywe.co.jp Sat Sep 24 07:18:09 2011 From: komma at ivywe.co.jp (=?ISO-2022-JP?B?GyRCOiM2cEUvO1IbKEIgR2Vla2xvZyBJdnlXZQ==?=) Date: Sat, 24 Sep 2011 20:18:09 +0900 Subject: [geeklog-devel] 1.8.1 In-Reply-To: References: <20110624133138.9164384jmqc7tuas@webmail.df.eu> <1308916307.1804.8.camel@roccivic-pc> <025901cc3267$570753a0$0515fae0$@cogeco.net> <20110624164720.9052387slu8vhl0k@webmail.df.eu> <312E4896-7DC1-4197-A1CB-0806E1151F0D@haun-online.de> <009801cc6c17$98ee1850$caca48f0$@cogeco.net> <7554C68E-0B1D-4636-BE78-5B7AF4A8781B@haun-online.de> <00e001cc6c9e$bf687bb0$3e397310$@cogeco.net> <74018DD2-E2D2-4B87-B0C2-18EC213AD460@haun-online.de> <7E72692B-6360-4DB3-B171-9F7162EAFF48@haun-online.de> Message-ID: Dirk, >> calendar plugin configuration >> http://demo.geeklog.net/admin/configuration.php >> I ca't delete Event Types by using X button. >> >> demo site and onother some site, error occurred. >> but some site(1.8.0) are Okay. > > Works for me. On the demo site as well as on a local fresh install of 1.8.1. > > Anyone else seeing this? It works well on IE9 and FF. I tested on Google Chrome, So it may be Chrome's bug. Thanks. bye, Ivy From websitemaster at cogeco.net Sat Sep 24 08:44:25 2011 From: websitemaster at cogeco.net (Tom) Date: Sat, 24 Sep 2011 08:44:25 -0400 Subject: [geeklog-devel] 1.8.1 In-Reply-To: References: <20110624133138.9164384jmqc7tuas@webmail.df.eu> <1308916307.1804.8.camel@roccivic-pc> <025901cc3267$570753a0$0515fae0$@cogeco.net> <20110624164720.9052387slu8vhl0k@webmail.df.eu> <312E4896-7DC1-4197-A1CB-0806E1151F0D@haun-online.de> <009801cc6c17$98ee1850$caca48f0$@cogeco.net> <7554C68E-0B1D-4636-BE78-5B7AF4A8781B@haun-online.de> <00e001cc6c9e$bf687bb0$3e397310$@cogeco.net> <74018DD2-E2D2-4B87-B0C2-18EC213AD460@haun-online.de> <7E72692B-6360-4DB3-B171-9F7162EAFF48@haun-online.de> Message-ID: <019701cc7ab7$b13339f0$1399add0$@cogeco.net> I can delete items using the x but for some reason when you hit the save button it doesn't actually delete the element. This seems to happen on other lists as well like the censor list. 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: September-24-11 4:39 AM To: Geeklog Development Subject: Re: [geeklog-devel] 1.8.1 ???? Geeklog IvyWe wrote: > calendar plugin configuration > http://demo.geeklog.net/admin/configuration.php > I ca't delete Event Types by using X button. > > demo site and onother some site, error occurred. > but some site(1.8.0) are Okay. Works for me. On the demo site as well as on a local fresh install of 1.8.1. Anyone else seeing this? 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 Sep 24 09:17:04 2011 From: komma at ivywe.co.jp (=?ISO-2022-JP?B?GyRCOiM2cEUvO1IbKEIgR2Vla2xvZyBJdnlXZQ==?=) Date: Sat, 24 Sep 2011 22:17:04 +0900 Subject: [geeklog-devel] 1.8.1 In-Reply-To: <019701cc7ab7$b13339f0$1399add0$@cogeco.net> References: <20110624133138.9164384jmqc7tuas@webmail.df.eu> <1308916307.1804.8.camel@roccivic-pc> <025901cc3267$570753a0$0515fae0$@cogeco.net> <20110624164720.9052387slu8vhl0k@webmail.df.eu> <312E4896-7DC1-4197-A1CB-0806E1151F0D@haun-online.de> <009801cc6c17$98ee1850$caca48f0$@cogeco.net> <7554C68E-0B1D-4636-BE78-5B7AF4A8781B@haun-online.de> <00e001cc6c9e$bf687bb0$3e397310$@cogeco.net> <74018DD2-E2D2-4B87-B0C2-18EC213AD460@haun-online.de> <7E72692B-6360-4DB3-B171-9F7162EAFF48@haun-online.de> <019701cc7ab7$b13339f0$1399add0$@cogeco.net> Message-ID: Tom, Dengen (Japanese) upload code for calendar configuration problem by Geeklog Japanese group on facebook. config.class.php line 1323: /* if array such as mail settings */ $_changed = false; foreach ( $change_array[$param_name] as $_param_name => $_param_value ) { to: /* if array such as mail settings */ $_changed = false; if (count($this->config_array[$group][$param_name]) != count($change_array[$param_name])) { $_changed = true; } foreach ( $change_array[$param_name] as $_param_name => $_param_value ) { bye, Ivy 2011/9/24 Tom : > I can delete items using the x but for some reason when you hit the save button it doesn't actually delete the element. This seems to happen on other lists as well like the censor list. > > 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: September-24-11 4:39 AM > To: Geeklog Development > Subject: Re: [geeklog-devel] 1.8.1 > > ???? Geeklog IvyWe wrote: > >> calendar plugin configuration >> http://demo.geeklog.net/admin/configuration.php >> I ca't delete Event Types by using X button. >> >> demo site and onother some site, error occurred. >> but some site(1.8.0) are Okay. > > Works for me. On the demo site as well as on a local fresh install of 1.8.1. > > Anyone else seeing this? > > 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 Sat Sep 24 10:33:23 2011 From: websitemaster at cogeco.net (Tom) Date: Sat, 24 Sep 2011 10:33:23 -0400 Subject: [geeklog-devel] 1.8.1 In-Reply-To: <7E72692B-6360-4DB3-B171-9F7162EAFF48@haun-online.de> References: <20110624133138.9164384jmqc7tuas@webmail.df.eu> <1308916307.1804.8.camel@roccivic-pc> <025901cc3267$570753a0$0515fae0$@cogeco.net> <20110624164720.9052387slu8vhl0k@webmail.df.eu> <312E4896-7DC1-4197-A1CB-0806E1151F0D@haun-online.de> <009801cc6c17$98ee1850$caca48f0$@cogeco.net> <7554C68E-0B1D-4636-BE78-5B7AF4A8781B@haun-online.de> <00e001cc6c9e$bf687bb0$3e397310$@cogeco.net> <74018DD2-E2D2-4B87-B0C2-18EC213AD460@haun-online.de> <7E72692B-6360-4DB3-B171-9F7162EAFF48@haun-online.de> Message-ID: <01a401cc7ac6$e9e3b770$bdab2650$@cogeco.net> Hey Dirk, You probably noticed but I have added 2 censor bug reports (one with a fix) and then a bug report for Ivy's along with her fix. Can you add the fixes to the repository for 1.8.1? 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: September-24-11 2:54 AM To: Geeklog Development Subject: Re: [geeklog-devel] 1.8.1 Almost forgot about 1.8.1 ;-) I haven't heard of any problems, so I guess we're good to go? bye, Dirk _______________________________________________ geeklog-devel mailing list geeklog-devel at lists.geeklog.net http://eight.pairlist.net/mailman/listinfo/geeklog-devel From ironmax at spacequad.com Sat Sep 24 17:20:18 2011 From: ironmax at spacequad.com (Michael Brusletten) Date: Sat, 24 Sep 2011 17:20:18 -0400 Subject: [geeklog-devel] geeklog-devel Digest, Vol 58, Issue 21 References: Message-ID: <000f01cc7aff$c2763e40$fe00a8c0@node1> > Message: 6 > Date: Sat, 24 Sep 2011 08:44:25 -0400 > From: "Tom" > Subject: Re: [geeklog-devel] 1.8.1 > To: "'Geeklog Development'" > Message-ID: <019701cc7ab7$b13339f0$1399add0$@cogeco.net> > Content-Type: text/plain; charset="utf-8" > > I can delete items using the x but for some reason when you hit the save button it doesn't actually delete the element. This seems to happen on other lists as well like the censor list. > > 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: September-24-11 4:39 AM > To: Geeklog Development > Subject: Re: [geeklog-devel] 1.8.1 > > ???? Geeklog IvyWe wrote: > > > calendar plugin configuration > > http://demo.geeklog.net/admin/configuration.php > > I ca't delete Event Types by using X button. > > > > demo site and onother some site, error occurred. > > but some site(1.8.0) are Okay. > > Works for me. On the demo site as well as on a local fresh install of 1.8.1. > > Anyone else seeing this? > > bye, Dirk > If your using Firefox, then yea your gonna have some issues saving stuff on the demo site. Atleast I've run into that problem with Firefox. Opera and IE seem to work fine in all areas on the site. Haven't tried Chrome. Michael From dirk at haun-online.de Sun Sep 25 16:49:07 2011 From: dirk at haun-online.de (Dirk Haun) Date: Sun, 25 Sep 2011 22:49:07 +0200 Subject: [geeklog-devel] [geeklog-cvs] geeklog: blank out OAuth consumer secrets when displaying the ro... In-Reply-To: References: Message-ID: > changeset 8425:0c05e3b0e0d5 > url: http://project.geeklog.net/cgi-bin/hgwebdir.cgi/geeklog/rev/0c05e3b0e0d5 > user: Dirk Haun > date: Sun Sep 25 22:24:26 2011 +0200 > description: > blank out OAuth consumer secrets when displaying the rootdebug error screen to a non-Root user Should we also blank out the OAuth consumer keys? How secret are those? bye, Dirk From websitemaster at cogeco.net Sun Sep 25 20:04:09 2011 From: websitemaster at cogeco.net (Tom) Date: Sun, 25 Sep 2011 20:04:09 -0400 Subject: [geeklog-devel] [geeklog-cvs] geeklog: blank out OAuth consumer secrets when displaying the ro... In-Reply-To: References: Message-ID: <024701cc7bdf$d0d64ad0$7282e070$@cogeco.net> We might as well just to be on the safe side since it is used as part of the identification process. http://oauth.net/core/1.0/ Consumer Key: A value used by the Consumer to identify itself to the Service Provider. Consumer Secret: A secret used by the Consumer to establish ownership of the Consumer Key. 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: September-25-11 4:49 PM To: geeklog-devel at lists.geeklog.net Subject: Re: [geeklog-devel] [geeklog-cvs] geeklog: blank out OAuth consumer secrets when displaying the ro... > changeset 8425:0c05e3b0e0d5 > url: http://project.geeklog.net/cgi-bin/hgwebdir.cgi/geeklog/rev/0c05e3b0e0d5 > user: Dirk Haun > date: Sun Sep 25 22:24:26 2011 +0200 > description: > blank out OAuth consumer secrets when displaying the rootdebug error screen to a non-Root user Should we also blank out the OAuth consumer keys? How secret are those? 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 Sep 26 11:04:15 2011 From: websitemaster at cogeco.net (Tom) Date: Mon, 26 Sep 2011 11:04:15 -0400 Subject: [geeklog-devel] Geeklog Block and Topic Updates Message-ID: <005401cc7c5d$8e8c3da0$aba4b8e0$@cogeco.net> Okay so just so I can keep track of things. My next commit will include: - Specifying Blocks for one or more topic (introduces the topic assignments table) (plus remove unique notice from black name since no check is done) - Restricted the use of a few topic names (ie all, homeonly) - Stories, Blocks, Topics and polls, calendar plugins will be updated to take into account if group has been deleted. Group Ids of objects will fall back to the plugins own admin group and if that is not found it will fall back to the Root group. - Calendar, Polls plugin blocks will be updated to be dynamic with full security. To modify these blocks new configuration options will have to be added that can be changed in the Geeklog Configuration (dynamic blocks do not show up in the Block Manager). * Currently working on I am also introducing 2 new files lib-block and lib-topic. Right now they just contain a few constants and plugin related functions for dealing with deleted groups. I expect to add more functions to these when I start dealing with multiple topics for staticpages and stories. Future commits will include: - Updating rest of core plugins with group delete fix. - Having core become more topic aware - Allowing staticpages to specify one or more topics - Allowing stories to specify one or more topics Tom From websitemaster at cogeco.net Fri Sep 30 14:03:22 2011 From: websitemaster at cogeco.net (Tom) Date: Fri, 30 Sep 2011 14:03:22 -0400 Subject: [geeklog-devel] Geeklog Topics - This is how they will work Message-ID: <021301cc7f9b$3e602ad0$bb208070$@cogeco.net> Okay so I have started to think more about multiple topics and child topics. I am writing this to organize my thoughts and to make sure we are all on the same page and agree with the direction I am taking (I am trying to make things as flexible as possible while still using the current framework). This will affect Topics (duh!), Blocks, Articles and Staticpages. For these changes Geeklog will have to keep track better what topic the user is in or was just in. Currently we have a global variable $topic that gets set in COM_siteHeader. It is set by seeing if there is a topic variable in the url or if a story id is in the url. Since stories will be able to have multiple topics and plugins (that support this) will have the option to be assigned to one or more topics this will not work. Adding the topic variable to the url string every time is not the answer either. I am not really familiar with how Geeklog sessions work . could we add a topic column to the session table (or somehow create a session variable) that we can grab and set instead? I will be adding fields (see below) to the topic edit form. At some point this form should be redesigned and visibly show the topic structure (jQuery Tree control maybe) but this is not something I am planning to tackle at the moment. Geeklog currently has 3 views: All Topics, Home Page and Topic. This will not change. This means we are still only passing around one topic id in the code though required functions will still have to gather all the child topic ids if needed. When a topic is viewed, it can inherit items from child topics. One of these inherited items are blocks. Let's say this is our topic tree: A -> B -> E -> C -> F -> G -> D -> H If we are viewing Topic A then all the blocks assigned to All Topics as well as any of the child topics (B - H) will be displayed just as long as the blocks are marked as inherited and the child topics are marked as inherited. If the block is marked as not inherited then it is only viewed from within that topic. If a topic is marked as not inherited then it cannot be inherited by a parent topic but it still can inherit from its own child topics. If duplicate blocks are inherited (i.e. Block 12 is assigned to both Topic C and E) then only one will be displayed. When viewing topics, stories being displayed will follow the same logic as blocks. The only exception is that a story will also have a default topic. This will be used when viewing a story directly, and only if the last topic viewed by the user is not known. For plugins, previously their only real option when it came to what blocks are displayed was the All Topic option. For the Staticpages plugin I plan to add the ability to specify if the page belongs to one or more topics. This way when viewed directly a staticpage will show only the blocks of that topic. Like stories though a staticpage will also require a default topic. The other thing topics can affect in the plugin is search and the menu. I would modify plugin_getmenuitems_staticpages to return only pages in the menu that relate to the topic and child topics. Likewise when using the advance search, the topic dropdown will be used if specified. The only other change at the moment I will make is to update the Topics block. The block will have to take into account hidden topics as well as distinguish child topics by indenting them. This is what I have come up with so far. Hopefully I have thought of most things but please feel free to comment! Here are the table changes: New Topic Fields Parent Id - Blank id = root Inherit - True/False = Inherit information from child topics (if topics and topic assignments are set to inherit) Hidden - Topic is not viewable but it can be inherited. Inherit must be true if Hidden is True - Not valid for root topics Featured Article - Used by articles New Topic Assignments Fields Inherit - True/False = Allow individual objects to be inherited or not Default - True/False = If a story or plugin item is viewed and has multiple topics then this will be considered the default Tom -------------- next part -------------- An HTML attachment was scrubbed... URL: From jmucchiello at yahoo.com Fri Sep 30 21:21:10 2011 From: jmucchiello at yahoo.com (Joe Mucchiello) Date: Fri, 30 Sep 2011 18:21:10 -0700 (PDT) Subject: [geeklog-devel] Geeklog Topics - This is how they will work Message-ID: <1317432070.35743.YahooMailNeo@web161404.mail.bf1.yahoo.com> When I last looked at this, the problem was the session code. I don't think it has changed much since then. There is no reliable way to find out what session is the "current" session because lib-session does not expose such a variable. And there are a few edge cases in the code that makes it a bit of a hassle to try exposing the session with a healthy restructuring of the session code. IIRC, going from not logged in to logged in is one of those edge cases.