From geeklog at langfamily.ca Sun Jan 2 13:52:14 2005 From: geeklog at langfamily.ca (Blaine Lang) Date: Sun, 2 Jan 2005 13:52:14 -0500 Subject: [geeklog-devel] Filtering in GL2 References: <41BE16BC.2080407@tonybibbs.com> <028701c4e167$d574cfe0$650a10ac@XPBL2> <41BE33F6.3000304@tonybibbs.com> <02c401c4e186$d0e0fed0$650a10ac@XPBL2> <41C74F76.3050309@tonybibbs.com> Message-ID: <000b01c4f0fc$2cc465f0$650a10ac@XPBL2> I wanted to send out an update on this and what I am thinking right now. I've been looking at other projects and how we do the current filtering and sanitizing of variables and have the following summary of requirements. This is a generic list and some functions are now handled by the GL2 DB Extraction layer but I am thinking we develop this new class and introduce it in GL 1.3.X as well. We have several requirements 1: Sanitize and filter incoming data variables and remove any potentially hostile data - Javascript, SQL Injections - sanitize numeric id's 2: Filter data that is not allowed - Javascript, HTML tags not allowed - Censor 3: Prepare data for SQL inserts - Create clickable links - Validate Email and URL links - Handle quotes (addslashes if necessary) - SPAM Filter 4: Prepare data for display - Convert HTML entities, Newlines to
tags, BBcode like [code] and [quote], autotags - stripslashes - Create crawler friendly links 5: Prepare data for edit - Convert HTML that was added for [code] back to BBcode tag for easier editing - remove extra
tags but not within [code] tags A lot of what we need is already in the KSES class and our other COM functions. The KSES Class can be extended to create the missing functions and then document the best practices. Please review and let me know if you agree with this approach. ----- Original Message ----- From: "Tony Bibbs" To: Sent: Monday, December 20, 2004 5:17 PM Subject: Re: [geeklog-devel] Filtering in GL2 Blaine, Any ETA on when you might get a draft of the class put together? If it will be a while, let me know and I can take a stab at it. --Tony Blaine Lang wrote: > >In addition, there is much more code inside the app that is adding or >stripping. >These have been added over time to address common needs but a major task to >replace and consolidate the core GL 1.3 codebase. > >Still, it would be good to create a new OO based class and start to use it >and slowing migrate scripts. >The 1.3.x platform and plugins could be used to test such a new common >class. > >I'd like to get more input but would be willing to take the lead on >developing this. > > > _______________________________________________ geeklog-devel mailing list geeklog-devel at lists.geeklog.net http://lists.geeklog.net/listinfo/geeklog-devel From geeklog at langfamily.ca Sun Jan 2 22:06:09 2005 From: geeklog at langfamily.ca (Blaine Lang) Date: Sun, 2 Jan 2005 22:06:09 -0500 Subject: [geeklog-devel] Filtering in GL2 References: <41BE16BC.2080407@tonybibbs.com> <028701c4e167$d574cfe0$650a10ac@XPBL2> <41BE33F6.3000304@tonybibbs.com> <02c401c4e186$d0e0fed0$650a10ac@XPBL2> <41C74F76.3050309@tonybibbs.com> <000b01c4f0fc$2cc465f0$650a10ac@XPBL2> Message-ID: <000801c4f141$2cbbf420$650a10ac@XPBL2> Update: I have just submitted to the 1.3.x CVS my initial version of this new class for review. I've done some initial testing but not all functions and it's working and shows the direction of this work-in-process. I think the function names and such can still be cleaned up and I don't have all the functions created yet. Let me know if you have any comments once it's approved for your review. Blaine ----- Original Message ----- From: "Blaine Lang" To: Sent: Sunday, January 02, 2005 1:52 PM Subject: Re: [geeklog-devel] Filtering in GL2 I wanted to send out an update on this and what I am thinking right now. I've been looking at other projects and how we do the current filtering and sanitizing of variables and have the following summary of requirements. This is a generic list and some functions are now handled by the GL2 DB Extraction layer but I am thinking we develop this new class and introduce it in GL 1.3.X as well. We have several requirements 1: Sanitize and filter incoming data variables and remove any potentially hostile data - Javascript, SQL Injections - sanitize numeric id's 2: Filter data that is not allowed - Javascript, HTML tags not allowed - Censor 3: Prepare data for SQL inserts - Create clickable links - Validate Email and URL links - Handle quotes (addslashes if necessary) - SPAM Filter 4: Prepare data for display - Convert HTML entities, Newlines to
tags, BBcode like [code] and [quote], autotags - stripslashes - Create crawler friendly links 5: Prepare data for edit - Convert HTML that was added for [code] back to BBcode tag for easier editing - remove extra
tags but not within [code] tags A lot of what we need is already in the KSES class and our other COM functions. The KSES Class can be extended to create the missing functions and then document the best practices. Please review and let me know if you agree with this approach. ----- Original Message ----- From: "Tony Bibbs" To: Sent: Monday, December 20, 2004 5:17 PM Subject: Re: [geeklog-devel] Filtering in GL2 Blaine, Any ETA on when you might get a draft of the class put together? If it will be a while, let me know and I can take a stab at it. --Tony Blaine Lang wrote: > >In addition, there is much more code inside the app that is adding or >stripping. >These have been added over time to address common needs but a major task to >replace and consolidate the core GL 1.3 codebase. > >Still, it would be good to create a new OO based class and start to use it >and slowing migrate scripts. >The 1.3.x platform and plugins could be used to test such a new common >class. > >I'd like to get more input but would be willing to take the lead on >developing this. > > > _______________________________________________ geeklog-devel mailing list geeklog-devel at lists.geeklog.net http://lists.geeklog.net/listinfo/geeklog-devel _______________________________________________ geeklog-devel mailing list geeklog-devel at lists.geeklog.net http://lists.geeklog.net/listinfo/geeklog-devel From tony at tonybibbs.com Tue Jan 4 14:45:06 2005 From: tony at tonybibbs.com (Tony Bibbs) Date: Tue, 04 Jan 2005 13:45:06 -0600 Subject: [geeklog-devel] Filtering in GL2 In-Reply-To: <000801c4f141$2cbbf420$650a10ac@XPBL2> References: <41BE16BC.2080407@tonybibbs.com> <028701c4e167$d574cfe0$650a10ac@XPBL2> <41BE33F6.3000304@tonybibbs.com> <02c401c4e186$d0e0fed0$650a10ac@XPBL2> <41C74F76.3050309@tonybibbs.com> <000b01c4f0fc$2cc465f0$650a10ac@XPBL2> <000801c4f141$2cbbf420$650a10ac@XPBL2> Message-ID: <41DAF242.2020701@tonybibbs.com> Blaine, looks good. I have already ported kses to PHP5 and started the PHP5 port of your class. So far my only comment is that you should remove the use of global variables and, instead, send them as options into your constructor: class sanitize { function sanitize($options) { $this->censorMode = $options['censorMode']; ... } } That way the class isn't GL specific (i.e. to need to use "global $_CONF"). --Tony Blaine Lang wrote: >Update: I have just submitted to the 1.3.x CVS my initial version of this >new class for review. >I've done some initial testing but not all functions and it's working and >shows the direction of this work-in-process. > >I think the function names and such can still be cleaned up and I don't >have all the functions created yet. > >Let me know if you have any comments once it's approved for your review. > >Blaine >----- Original Message ----- >From: "Blaine Lang" >To: >Sent: Sunday, January 02, 2005 1:52 PM >Subject: Re: [geeklog-devel] Filtering in GL2 > > >I wanted to send out an update on this and what I am thinking right now. >I've been looking at other projects and how we do the current filtering and >sanitizing of variables and have the following summary of requirements. > >This is a generic list and some functions are now handled by the GL2 DB >Extraction layer but I am thinking we develop this new class and introduce >it in GL 1.3.X as well. > >We have several requirements >1: Sanitize and filter incoming data variables and remove any potentially >hostile data > - Javascript, SQL Injections > - sanitize numeric id's >2: Filter data that is not allowed > - Javascript, HTML tags not allowed > - Censor >3: Prepare data for SQL inserts > - Create clickable links > - Validate Email and URL links > - Handle quotes (addslashes if necessary) > - SPAM Filter >4: Prepare data for display > - Convert HTML entities, Newlines to
tags, BBcode like [code] and >[quote], autotags > - stripslashes > - Create crawler friendly links >5: Prepare data for edit > - Convert HTML that was added for [code] back to BBcode tag for easier >editing > - remove extra
tags but not within [code] tags > >A lot of what we need is already in the KSES class and our other COM >functions. >The KSES Class can be extended to create the missing functions and then >document the best practices. > >Please review and let me know if you agree with this approach. > >----- Original Message ----- >From: "Tony Bibbs" >To: >Sent: Monday, December 20, 2004 5:17 PM >Subject: Re: [geeklog-devel] Filtering in GL2 > > >Blaine, > >Any ETA on when you might get a draft of the class put together? If it >will be a while, let me know and I can take a stab at it. > >--Tony > >Blaine Lang wrote: > > > >>In addition, there is much more code inside the app that is adding or >>stripping. >>These have been added over time to address common needs but a major task to >>replace and consolidate the core GL 1.3 codebase. >> >>Still, it would be good to create a new OO based class and start to use it >>and slowing migrate scripts. >>The 1.3.x platform and plugins could be used to test such a new common >>class. >> >>I'd like to get more input but would be willing to take the lead on >>developing this. >> >> >> >> >> > >_______________________________________________ >geeklog-devel mailing list >geeklog-devel at lists.geeklog.net >http://lists.geeklog.net/listinfo/geeklog-devel > >_______________________________________________ >geeklog-devel mailing list >geeklog-devel at lists.geeklog.net >http://lists.geeklog.net/listinfo/geeklog-devel > >_______________________________________________ >geeklog-devel mailing list >geeklog-devel at lists.geeklog.net >http://lists.geeklog.net/listinfo/geeklog-devel > > From tony at tonybibbs.com Wed Jan 5 12:04:37 2005 From: tony at tonybibbs.com (Tony Bibbs) Date: Wed, 05 Jan 2005 11:04:37 -0600 Subject: [geeklog-devel] GL2 and site relationships Message-ID: <41DC1E25.6090804@tonybibbs.com> One thing missing from the current GL2 data model is the ability to run multiple sites under one database. These sites may, or may not, have a relationship of some sort. This definitely needs to be added. I wanted to quickly describe this and how I am proposing to solve this. Organizations, particularly businesses, would want to use a CMS like GL2 allowing each entity in their table of organization to have their own site. These relationships can be in three different modes: 1) Independent. They share the same database but have no relationship between them. As such they effectively act as their own independent GL2 site 2) Peer-to-Peer. You may have two GL2 sites with different but related content. This model would allow one site to magically 'submit' items that can be included on the other site given that site administrator wants it. 3) Affinities. This covers the scenario I eluded to where you have a number of GL2 sites that are related to one another. There will always be a top level 'master' who can create affinities under them who can control their own content but are subjected to content changes the 'master' feels is appropriate to them. My first question is do we still want to support this sort of functionality? Doing so would complicate overall administration but we could probably hide that complexity if, at installation, we knew the admin didn't care to run more than one GL2 site in the single database. --Tony From slord at marelina.com Wed Jan 5 13:06:36 2005 From: slord at marelina.com (Simon Lord) Date: Wed, 5 Jan 2005 13:06:36 -0500 Subject: [geeklog-devel] GL2 and site relationships In-Reply-To: <41DC1E25.6090804@tonybibbs.com> References: <41DC1E25.6090804@tonybibbs.com> Message-ID: <8A2CE6D0-5F44-11D9-AD7C-003065C030F2@marelina.com> My current solution to this is to assign each dept as a GROUP. That way each dept only sees stories/links etc meant for them. It's not perfect, but it would be if a new *kind* of group object were created to categorize content into a meta-group. This would allow us to assign the *meta-group* tag to users who would automatically only be able to read and post to their meta-group. Some depts, such as the Documentation dept, would need to have permissions to search more than just within their own meta-group in order to gain access to information to author proper documentation. So a means to allow a user/or group access to more than one meta-group would be cool. Is that complex? I think it would work swimingly across sites as well seeing as how users are tagged with a specific meta-group depending on where they sign in/sign up and thus only see data pertaining to that meta-group. On Jan 5, 2005, at 12:04 PM, Tony Bibbs wrote: > One thing missing from the current GL2 data model is the ability to > run multiple sites under one database. These sites may, or may not, > have a relationship of some sort. This definitely needs to be added. > I wanted to quickly describe this and how I am proposing to solve > this. > > Organizations, particularly businesses, would want to use a CMS like > GL2 allowing each entity in their table of organization to have their > own site. These relationships can be in three different modes: > > 1) Independent. They share the same database but have no relationship > between them. As such they effectively act as their own independent > GL2 site > > 2) Peer-to-Peer. You may have two GL2 sites with different but > related content. This model would allow one site to magically > 'submit' items that can be included on the other site given that site > administrator wants it. > > 3) Affinities. This covers the scenario I eluded to where you have a > number of GL2 sites that are related to one another. There will > always be a top level 'master' who can create affinities under them > who can control their own content but are subjected to content changes > the 'master' feels is appropriate to them. > > My first question is do we still want to support this sort of > functionality? Doing so would complicate overall administration but > we could probably hide that complexity if, at installation, we knew > the admin didn't care to run more than one GL2 site in the single > database. > > --Tony > _______________________________________________ > geeklog-devel mailing list > geeklog-devel at lists.geeklog.net > http://lists.geeklog.net/listinfo/geeklog-devel > > Sincerely, Simon From vfuria at gmail.com Wed Jan 5 13:10:22 2005 From: vfuria at gmail.com (Vincent Furia) Date: Wed, 5 Jan 2005 13:10:22 -0500 Subject: [geeklog-devel] GL2 and site relationships In-Reply-To: <8A2CE6D0-5F44-11D9-AD7C-003065C030F2@marelina.com> References: <41DC1E25.6090804@tonybibbs.com> <8A2CE6D0-5F44-11D9-AD7C-003065C030F2@marelina.com> Message-ID: <8319e2d605010510103e006f8@mail.gmail.com> Simon, If I understand what your asking, I think between groups and the ACLs under GL2 you'll get this functionality for free (as long we keep in mind people may want to do things this way when we're writing the rest of the code). -Vinny On Wed, 5 Jan 2005 13:06:36 -0500, Simon Lord wrote: > My current solution to this is to assign each dept as a GROUP. That > way each dept only sees stories/links etc meant for them. It's not > perfect, but it would be if a new *kind* of group object were created > to categorize content into a meta-group. This would allow us to assign > the *meta-group* tag to users who would automatically only be able to > read and post to their meta-group. > > Some depts, such as the Documentation dept, would need to have > permissions to search more than just within their own meta-group in > order to gain access to information to author proper documentation. So > a means to allow a user/or group access to more than one meta-group > would be cool. > > Is that complex? I think it would work swimingly across sites as well > seeing as how users are tagged with a specific meta-group depending on > where they sign in/sign up and thus only see data pertaining to that > meta-group. > > > On Jan 5, 2005, at 12:04 PM, Tony Bibbs wrote: > > > One thing missing from the current GL2 data model is the ability to > > run multiple sites under one database. These sites may, or may not, > > have a relationship of some sort. This definitely needs to be added. > > I wanted to quickly describe this and how I am proposing to solve > > this. > > > > Organizations, particularly businesses, would want to use a CMS like > > GL2 allowing each entity in their table of organization to have their > > own site. These relationships can be in three different modes: > > > > 1) Independent. They share the same database but have no relationship > > between them. As such they effectively act as their own independent > > GL2 site > > > > 2) Peer-to-Peer. You may have two GL2 sites with different but > > related content. This model would allow one site to magically > > 'submit' items that can be included on the other site given that site > > administrator wants it. > > > > 3) Affinities. This covers the scenario I eluded to where you have a > > number of GL2 sites that are related to one another. There will > > always be a top level 'master' who can create affinities under them > > who can control their own content but are subjected to content changes > > the 'master' feels is appropriate to them. > > > > My first question is do we still want to support this sort of > > functionality? Doing so would complicate overall administration but > > we could probably hide that complexity if, at installation, we knew > > the admin didn't care to run more than one GL2 site in the single > > database. > > > > --Tony > > _______________________________________________ > > geeklog-devel mailing list > > geeklog-devel at lists.geeklog.net > > http://lists.geeklog.net/listinfo/geeklog-devel > > > > > Sincerely, > Simon > > _______________________________________________ > geeklog-devel mailing list > geeklog-devel at lists.geeklog.net > http://lists.geeklog.net/listinfo/geeklog-devel > From slord at marelina.com Wed Jan 5 13:18:23 2005 From: slord at marelina.com (Simon Lord) Date: Wed, 5 Jan 2005 13:18:23 -0500 Subject: [geeklog-devel] GL2 and site relationships In-Reply-To: <8319e2d605010510103e006f8@mail.gmail.com> References: <41DC1E25.6090804@tonybibbs.com> <8A2CE6D0-5F44-11D9-AD7C-003065C030F2@marelina.com> <8319e2d605010510103e006f8@mail.gmail.com> Message-ID: <2F7F7C21-5F46-11D9-AD7C-003065C030F2@marelina.com> Ok, so what's the underlying question Tony is asking if we can simulate separate depts under GL2? If we can assign a theme to a meta-group then in theory these meta-groups would look like independent sites. No? On Jan 5, 2005, at 1:10 PM, Vincent Furia wrote: > Simon, > > If I understand what your asking, I think between groups and the ACLs > under GL2 you'll get this functionality for free (as long we keep in > mind people may want to do things this way when we're writing the rest > of the code). > > -Vinny > > > On Wed, 5 Jan 2005 13:06:36 -0500, Simon Lord > wrote: >> My current solution to this is to assign each dept as a GROUP. That >> way each dept only sees stories/links etc meant for them. It's not >> perfect, but it would be if a new *kind* of group object were created >> to categorize content into a meta-group. This would allow us to >> assign >> the *meta-group* tag to users who would automatically only be able to >> read and post to their meta-group. >> >> Some depts, such as the Documentation dept, would need to have >> permissions to search more than just within their own meta-group in >> order to gain access to information to author proper documentation. >> So >> a means to allow a user/or group access to more than one meta-group >> would be cool. >> >> Is that complex? I think it would work swimingly across sites as well >> seeing as how users are tagged with a specific meta-group depending on >> where they sign in/sign up and thus only see data pertaining to that >> meta-group. >> >> >> On Jan 5, 2005, at 12:04 PM, Tony Bibbs wrote: >> >>> One thing missing from the current GL2 data model is the ability to >>> run multiple sites under one database. These sites may, or may not, >>> have a relationship of some sort. This definitely needs to be added. >>> I wanted to quickly describe this and how I am proposing to solve >>> this. >>> >>> Organizations, particularly businesses, would want to use a CMS like >>> GL2 allowing each entity in their table of organization to have their >>> own site. These relationships can be in three different modes: >>> >>> 1) Independent. They share the same database but have no >>> relationship >>> between them. As such they effectively act as their own independent >>> GL2 site >>> >>> 2) Peer-to-Peer. You may have two GL2 sites with different but >>> related content. This model would allow one site to magically >>> 'submit' items that can be included on the other site given that site >>> administrator wants it. >>> >>> 3) Affinities. This covers the scenario I eluded to where you have a >>> number of GL2 sites that are related to one another. There will >>> always be a top level 'master' who can create affinities under them >>> who can control their own content but are subjected to content >>> changes >>> the 'master' feels is appropriate to them. >>> >>> My first question is do we still want to support this sort of >>> functionality? Doing so would complicate overall administration but >>> we could probably hide that complexity if, at installation, we knew >>> the admin didn't care to run more than one GL2 site in the single >>> database. >>> >>> --Tony >>> _______________________________________________ >>> geeklog-devel mailing list >>> geeklog-devel at lists.geeklog.net >>> http://lists.geeklog.net/listinfo/geeklog-devel >>> >>> >> Sincerely, >> Simon >> >> _______________________________________________ >> geeklog-devel mailing list >> geeklog-devel at lists.geeklog.net >> http://lists.geeklog.net/listinfo/geeklog-devel >> > _______________________________________________ > geeklog-devel mailing list > geeklog-devel at lists.geeklog.net > http://lists.geeklog.net/listinfo/geeklog-devel > > Sincerely, Simon From tony at tonybibbs.com Wed Jan 5 13:54:13 2005 From: tony at tonybibbs.com (Tony Bibbs) Date: Wed, 05 Jan 2005 12:54:13 -0600 Subject: [geeklog-devel] GL2 and site relationships In-Reply-To: <2F7F7C21-5F46-11D9-AD7C-003065C030F2@marelina.com> References: <41DC1E25.6090804@tonybibbs.com> <8A2CE6D0-5F44-11D9-AD7C-003065C030F2@marelina.com> <8319e2d605010510103e006f8@mail.gmail.com> <2F7F7C21-5F46-11D9-AD7C-003065C030F2@marelina.com> Message-ID: <41DC37D5.4080200@tonybibbs.com> Let me try explaining this another way. The first relationship would be independent. In 1.3.x there is no way to do this. If you want two unrelated sites running under the same database...forget about it. In this the sites are truly separate with their own users, their own groups, own content. The second relationship, peer-to-peer, might be a suite of on line publications. For example purposes, they might all be computing publications with one specializing in Programming and the other in, say, Networking and Security. Each would have their own sets of groups, permissions, etc. However the admins can pick and choose what content they are willing to share with their affiliate sites. Thus the Programming site could 'listen' to the LDAP topic on the networking and security site so that when, for example, a story submission on LDAP was made the Programming site would get it as well. The last, and more complicated is the affinity relationship. This imposes a hierarchy where the parent site admin can control content downstream. So, for example, take a large company like Honeywell. Honeywell's HQ would have their own site. Each regional division would have their own Gl2 site under the Honeywell umbrella. The look and feel can even be drastically different by the content comes two sources, the HQ site and any content generated at the regional level. Not the greatest example but does that make more sense? --Tony Simon Lord wrote: > Ok, so what's the underlying question Tony is asking if we can > simulate separate depts under GL2? > > If we can assign a theme to a meta-group then in theory these > meta-groups would look like independent sites. No? > > > On Jan 5, 2005, at 1:10 PM, Vincent Furia wrote: > >> Simon, >> >> If I understand what your asking, I think between groups and the ACLs >> under GL2 you'll get this functionality for free (as long we keep in >> mind people may want to do things this way when we're writing the rest >> of the code). >> >> -Vinny >> >> >> On Wed, 5 Jan 2005 13:06:36 -0500, Simon Lord >> wrote: >> >>> My current solution to this is to assign each dept as a GROUP. That >>> way each dept only sees stories/links etc meant for them. It's not >>> perfect, but it would be if a new *kind* of group object were created >>> to categorize content into a meta-group. This would allow us to assign >>> the *meta-group* tag to users who would automatically only be able to >>> read and post to their meta-group. >>> >>> Some depts, such as the Documentation dept, would need to have >>> permissions to search more than just within their own meta-group in >>> order to gain access to information to author proper documentation. So >>> a means to allow a user/or group access to more than one meta-group >>> would be cool. >>> >>> Is that complex? I think it would work swimingly across sites as well >>> seeing as how users are tagged with a specific meta-group depending on >>> where they sign in/sign up and thus only see data pertaining to that >>> meta-group. >>> >>> >>> On Jan 5, 2005, at 12:04 PM, Tony Bibbs wrote: >>> >>>> One thing missing from the current GL2 data model is the ability to >>>> run multiple sites under one database. These sites may, or may not, >>>> have a relationship of some sort. This definitely needs to be added. >>>> I wanted to quickly describe this and how I am proposing to solve >>>> this. >>>> >>>> Organizations, particularly businesses, would want to use a CMS like >>>> GL2 allowing each entity in their table of organization to have their >>>> own site. These relationships can be in three different modes: >>>> >>>> 1) Independent. They share the same database but have no relationship >>>> between them. As such they effectively act as their own independent >>>> GL2 site >>>> >>>> 2) Peer-to-Peer. You may have two GL2 sites with different but >>>> related content. This model would allow one site to magically >>>> 'submit' items that can be included on the other site given that site >>>> administrator wants it. >>>> >>>> 3) Affinities. This covers the scenario I eluded to where you have a >>>> number of GL2 sites that are related to one another. There will >>>> always be a top level 'master' who can create affinities under them >>>> who can control their own content but are subjected to content changes >>>> the 'master' feels is appropriate to them. >>>> >>>> My first question is do we still want to support this sort of >>>> functionality? Doing so would complicate overall administration but >>>> we could probably hide that complexity if, at installation, we knew >>>> the admin didn't care to run more than one GL2 site in the single >>>> database. >>>> >>>> --Tony >>>> _______________________________________________ >>>> geeklog-devel mailing list >>>> geeklog-devel at lists.geeklog.net >>>> http://lists.geeklog.net/listinfo/geeklog-devel >>>> >>>> >>> Sincerely, >>> Simon >>> >>> _______________________________________________ >>> geeklog-devel mailing list >>> geeklog-devel at lists.geeklog.net >>> http://lists.geeklog.net/listinfo/geeklog-devel >>> >> _______________________________________________ >> geeklog-devel mailing list >> geeklog-devel at lists.geeklog.net >> http://lists.geeklog.net/listinfo/geeklog-devel >> >> > Sincerely, > Simon > > _______________________________________________ > geeklog-devel mailing list > geeklog-devel at lists.geeklog.net > http://lists.geeklog.net/listinfo/geeklog-devel From vfuria at gmail.com Wed Jan 5 14:10:34 2005 From: vfuria at gmail.com (Vincent Furia) Date: Wed, 5 Jan 2005 14:10:34 -0500 Subject: [geeklog-devel] GL2 and site relationships In-Reply-To: <41DC37D5.4080200@tonybibbs.com> References: <41DC1E25.6090804@tonybibbs.com> <8A2CE6D0-5F44-11D9-AD7C-003065C030F2@marelina.com> <8319e2d605010510103e006f8@mail.gmail.com> <2F7F7C21-5F46-11D9-AD7C-003065C030F2@marelina.com> <41DC37D5.4080200@tonybibbs.com> Message-ID: <8319e2d60501051110301bcb86@mail.gmail.com> On Wed, 05 Jan 2005 12:54:13 -0600, Tony Bibbs wrote: > Let me try explaining this another way. > > The first relationship would be independent. In 1.3.x there is no way > to do this. If you want two unrelated sites running under the same > database...forget about it. In this the sites are truly separate with > their own users, their own groups, own content. > I thought this could be done in 1.3.x by changing the table prefix? Are you talking independent sites sharing the same tables? I don't think that would be a good idea. I know one requested thing not currently supported in 1.3.x is to use a single GL installation to run multiple sites with independent databases (different physical databases or different table prefixes). I can see how this would make an admins life much easier when upgrading GL or installing plugins (which could be installed on all the sites, but enabled per site)... > The second relationship, peer-to-peer, might be a suite of on line > publications. For example purposes, they might all be computing > publications with one specializing in Programming and the other in, say, > Networking and Security. Each would have their own sets of groups, > permissions, etc. However the admins can pick and choose what content > they are willing to share with their affiliate sites. Thus the > Programming site could 'listen' to the LDAP topic on the networking and > security site so that when, for example, a story submission on LDAP was > made the Programming site would get it as well. > I think this could be best accomplished by a Web Application plugin that would allow "items" to be cross submitted to several sites. Such a system wouldn't even depend on the sites being on the same server. While implementing this may be a little difficult, as there are many complexities involved, I think implementing this later rather than sooner would be OK. Such a plugin could eventually give the ability to submit items (and do other tasks?) through interfaces besides the web. > The last, and more complicated is the affinity relationship. This > imposes a hierarchy where the parent site admin can control content > downstream. So, for example, take a large company like Honeywell. > Honeywell's HQ would have their own site. Each regional division would > have their own Gl2 site under the Honeywell umbrella. The look and feel > can even be drastically different by the content comes two sources, the > HQ site and any content generated at the regional level. > If we can implement giving different groups different default themes (and even different themes available based upon group/userid [ACLs?]), then I think this can be implemented like Simon described as a single site with items being assigned to whichever groups are applicable. Admins could be given permissions to post/edit on a per category basis. -Vinny From dirk at haun-online.de Wed Jan 5 14:22:56 2005 From: dirk at haun-online.de (Dirk Haun) Date: Wed, 5 Jan 2005 20:22:56 +0100 Subject: [geeklog-devel] GL2 and site relationships In-Reply-To: <8319e2d60501051110301bcb86@mail.gmail.com> References: <8319e2d60501051110301bcb86@mail.gmail.com> Message-ID: <20050105192256.22201@smtp.haun-online.de> Vinny wrote: >I know one requested thing not currently supported in 1.3.x is to use >a single GL installation to run multiple sites with independent >databases There's a hack for this in the FAQ, but it's not officially supported, yes. >Are you talking independent sites sharing the same tables? I don't >think that would be a good idea. A few people wanted to share their user base across several sites, so that users only had to register with one site, but get access to several sites at once. This should also work in 1.3.x, in theory, if you change lib-database.php such that all user-related tables exist only once (e.g. without a prefix, while the other tables keep their prefix). There's a forum thread on gl.net somewhere where I suggested to try this to someone who was willing to experiment. Haven't had a definitive answer, though. Anyway, what I was trying to say is that there seems to be demand for both approaches. bye, Dirk -- http://www.haun-online.de/ http://www.tinyweb.de/ From tony at tonybibbs.com Wed Jan 5 14:50:15 2005 From: tony at tonybibbs.com (Tony Bibbs) Date: Wed, 05 Jan 2005 13:50:15 -0600 Subject: [geeklog-devel] GL2 and site relationships In-Reply-To: <8319e2d60501051110301bcb86@mail.gmail.com> References: <41DC1E25.6090804@tonybibbs.com> <8A2CE6D0-5F44-11D9-AD7C-003065C030F2@marelina.com> <8319e2d605010510103e006f8@mail.gmail.com> <2F7F7C21-5F46-11D9-AD7C-003065C030F2@marelina.com> <41DC37D5.4080200@tonybibbs.com> <8319e2d60501051110301bcb86@mail.gmail.com> Message-ID: <41DC44F7.2010602@tonybibbs.com> Vincent Furia wrote: >On Wed, 05 Jan 2005 12:54:13 -0600, Tony Bibbs wrote: > > >>Let me try explaining this another way. >> >>The first relationship would be independent. In 1.3.x there is no way >>to do this. If you want two unrelated sites running under the same >>database...forget about it. In this the sites are truly separate with >>their own users, their own groups, own content. >> >> >> >I thought this could be done in 1.3.x by changing the table prefix? >Are you talking independent sites sharing the same tables? > Correct. >I don't >think that would be a good idea. > > Depends on the scenario. Take, for example, a company wanting to do cobranded stuff...where basically two sites share basic features but are wrapped in their own look and feels. The Insurance Industry would be a good example of this. I'm not advocating this, I'm simply saying it was something that I have noted as being a requirement and if we still want to support this notion it would need to happen sooner than later given the impact it would have on the data model. > >I know one requested thing not currently supported in 1.3.x is to use >a single GL installation to run multiple sites with independent >databases (different physical databases or different table prefixes). >I can see how this would make an admins life much easier when >upgrading GL or installing plugins (which could be installed on all >the sites, but enabled per site)... > > I agree with you on this. Definitely worth it. >I think this could be best accomplished by a Web Application plugin >that would allow "items" to be cross submitted to several sites. Such >a system wouldn't even depend on the sites being on the same server. >While implementing this may be a little difficult, as there are many >complexities involved, I think implementing this later rather than >sooner would be OK. Such a plugin could eventually give the ability >to submit items (and do other tasks?) through interfaces besides the >web. > > Blah, maybe we just web service this stuff that way we don't care --Tony From tony at tonybibbs.com Wed Jan 5 14:55:14 2005 From: tony at tonybibbs.com (Tony Bibbs) Date: Wed, 05 Jan 2005 13:55:14 -0600 Subject: [geeklog-devel] GL2 and site relationships In-Reply-To: <20050105192256.22201@smtp.haun-online.de> References: <8319e2d60501051110301bcb86@mail.gmail.com> <20050105192256.22201@smtp.haun-online.de> Message-ID: <41DC4622.6080902@tonybibbs.com> In gl2 we can handle the ability to share user bases across sites by simply implementing an account manager to do this. As you might guess, the entire log in process is isolated so that it can be easily extended/modified to suit the needs of a particular site. You could do a simple webservice call to have one GL site remotely authenticate to another GL site or use the same method for doing it local (though it would be unneeded HTTP overhead). --Tony >A few people wanted to share their user base across several sites, so >that users only had to register with one site, but get access to several >sites at once. > >This should also work in 1.3.x, in theory, if you change lib-database.php >such that all user-related tables exist only once (e.g. without a prefix, >while the other tables keep their prefix). > >There's a forum thread on gl.net somewhere where I suggested to try this >to someone who was willing to experiment. Haven't had a definitive >answer, though. > >Anyway, what I was trying to say is that there seems to be demand for >both approaches. > >bye, Dirk > > > > From tony at tonybibbs.com Wed Jan 5 23:14:39 2005 From: tony at tonybibbs.com (Tony Bibbs) Date: Wed, 05 Jan 2005 22:14:39 -0600 Subject: [geeklog-devel] colo server getting upgraded Message-ID: <41DCBB2F.40100@tonybibbs.com> I'm in the middle of upgrading to apache2 on my colo server. I'm also taking this time to patch a few out-of-date packages. CVS should still work minus the web viewer. project.geeklog.net will be down, though. I'll update when it comes back up. --Tony From tony at tonybibbs.com Thu Jan 6 00:56:51 2005 From: tony at tonybibbs.com (Tony Bibbs) Date: Wed, 05 Jan 2005 23:56:51 -0600 Subject: [geeklog-devel] colo server getting upgraded In-Reply-To: <41DCBB2F.40100@tonybibbs.com> References: <41DCBB2F.40100@tonybibbs.com> Message-ID: <41DCD323.5090808@tonybibbs.com> Upgrade is done. I have other patches to do but they shouldn't effect anything noticeable. We are now running apache2, php4.3.10 and upgrades to both postgres and mysql were made but their exact versions escape me (and I'm too tired/lazy to look now). --Tony Tony Bibbs wrote: > I'm in the middle of upgrading to apache2 on my colo server. I'm also > taking this time to patch a few out-of-date packages. CVS should > still work minus the web viewer. project.geeklog.net will be down, > though. I'll update when it comes back up. > > --Tony > _______________________________________________ > geeklog-devel mailing list > geeklog-devel at lists.geeklog.net > http://lists.geeklog.net/listinfo/geeklog-devel From tony at tonybibbs.com Fri Jan 7 14:55:45 2005 From: tony at tonybibbs.com (Tony Bibbs) Date: Fri, 07 Jan 2005 13:55:45 -0600 Subject: [geeklog-devel] Adsense Message-ID: <41DEE941.6020903@tonybibbs.com> Google's Adsense crew called me today. Apparantly they would like us to use Adsense on gl.net. I had a problem using them because they had essentially banned me. The guy I talked to undid that mess and I can now use it again (though I'm not sure I want to on ia.org). Anyway, I guess this means we could do it on gl.net if we wanted. I'm not opposed to the idea but don't have a strong desire either. Would it be worth trying it to see what we get? Maybe it will pay for the first annual Geeklog Conference in Hawaii (after 10 years)? --Tony From vfuria at gmail.com Fri Jan 7 15:24:56 2005 From: vfuria at gmail.com (Vincent Furia) Date: Fri, 7 Jan 2005 15:24:56 -0500 Subject: [geeklog-devel] Adsense In-Reply-To: <41DEE941.6020903@tonybibbs.com> References: <41DEE941.6020903@tonybibbs.com> Message-ID: <8319e2d605010712247b1db000@mail.gmail.com> Maybe run a poll a on gl.net asking what people think? Depending on what results we see I certainly don't see a problem with it, but I would hate to alienate a large number of users of something that I don't feel any of us feel very strongly about... Of course if someone does feel strongly one way or the other I'll go with along. :) -Vinny On Fri, 07 Jan 2005 13:55:45 -0600, Tony Bibbs wrote: > Google's Adsense crew called me today. Apparantly they would like us to > use Adsense on gl.net. I had a problem using them because they had > essentially banned me. The guy I talked to undid that mess and I can > now use it again (though I'm not sure I want to on ia.org). > > Anyway, I guess this means we could do it on gl.net if we wanted. I'm > not opposed to the idea but don't have a strong desire either. Would it > be worth trying it to see what we get? Maybe it will pay for the first > annual Geeklog Conference in Hawaii (after 10 years)? > > --Tony > _______________________________________________ > geeklog-devel mailing list > geeklog-devel at lists.geeklog.net > http://lists.geeklog.net/listinfo/geeklog-devel > From dirk at haun-online.de Fri Jan 7 17:31:08 2005 From: dirk at haun-online.de (Dirk Haun) Date: Fri, 7 Jan 2005 23:31:08 +0100 Subject: [geeklog-devel] Adsense In-Reply-To: <41DEE941.6020903@tonybibbs.com> References: <41DEE941.6020903@tonybibbs.com> Message-ID: <20050107223109.9040@smtp.haun-online.de> Tony, >I'm not opposed to the idea but don't have a strong desire either. Same here. With the webserver being sponsored, we don't have any real running costs to cover, so there's no real need to do it. The question is also where we place them. On the front page? In the forums only? Maybe Vinny is right and we should run a poll first. >Would it be worth trying it to see what we get? I have no idea what to expect in terms of revenues. IF (big if) we do it, we should also limit it to, say, 4-8 weeks first and see what comes out of it. bye, Dirk -- http://www.haun-online.de/ http://geeklog.info/ From tomw at pigstye.net Fri Jan 7 20:22:24 2005 From: tomw at pigstye.net (Tom Willett) Date: Fri, 07 Jan 2005 20:22:24 -0500 Subject: [geeklog-devel] Adsense In-Reply-To: <20050107223109.9040@smtp.haun-online.de> References: <41DEE941.6020903@tonybibbs.com> <20050107223109.9040@smtp.haun-online.de> Message-ID: <41DF35D0.8050507@pigstye.net> Dirk Haun wrote: >Tony, > > > >>I'm not opposed to the idea but don't have a strong desire either. >> >> > >Same here. With the webserver being sponsored, we don't have any real >running costs to cover, so there's no real need to do it. > >The question is also where we place them. On the front page? In the >forums only? > >Maybe Vinny is right and we should run a poll first. > > > > >>Would it be worth trying it to see what we get? >> >> > >I have no idea what to expect in terms of revenues. IF (big if) we do it, >we should also limit it to, say, 4-8 weeks first and see what comes out of it. > >bye, Dirk > > > > FYI It took a good 6 months for adsense to tailor the adds to my websites for them to begin to make any money. Now they are paying the bandwidth costs only. Tom -- Tom Willett tomw at pigstye.net -------------- next part -------------- An HTML attachment was scrubbed... URL: From dirk at haun-online.de Sat Jan 8 09:02:55 2005 From: dirk at haun-online.de (Dirk Haun) Date: Sat, 8 Jan 2005 15:02:55 +0100 Subject: [geeklog-devel] Adsense In-Reply-To: <41DF35D0.8050507@pigstye.net> References: <41DF35D0.8050507@pigstye.net> Message-ID: <20050108140255.13302@smtp.haun-online.de> Tom wrote: >FYI It took a good 6 months for adsense to tailor the adds to my >websites for them to begin to make any money. Now they are paying the >bandwidth costs only. The more I think about it, the less I like the idea. Is anyone actually in favour of it? bye, Dirk -- http://www.haun-online.de/ http://www.tinyweb.de/ From dirk at haun-online.de Sat Jan 8 15:24:19 2005 From: dirk at haun-online.de (Dirk Haun) Date: Sat, 8 Jan 2005 21:24:19 +0100 Subject: [geeklog-devel] Re: [geeklog-cvs] geeklog-1.3/public_html directory.php,NONE,1.1 In-Reply-To: <20050108200923.27BBC3E98@iowaoutdoors.org> References: <20050108200923.27BBC3E98@iowaoutdoors.org> Message-ID: <20050108202419.21054@smtp.haun-online.de> >Added Files: > directory.php >Log Message: >A date-based listing of all the stories on a site. >To do: >- Move text strings to the language files >- Move configuration option to config.php >- (maybe) use templates ... Forgot to add: - Hook it up with the rest of Geeklog, i.e. add links to it somewhere. This is a script I originally wrote for a client and which can go into the core with their permission. In its current form, it's self contained, so you can simply download it and throw it into your public_html directory. Currently, it only lists stories. Blaine wanted to see it being extendable so that plugins could add content, too. I'm a bit reluctant, though, and fear that it would make it too complex / complicated. Comments? bye, Dirk -- http://www.haun-online.de/ http://www.handful-of-sparks.de/ From tony at tonybibbs.com Mon Jan 10 16:36:24 2005 From: tony at tonybibbs.com (Tony Bibbs) Date: Mon, 10 Jan 2005 15:36:24 -0600 Subject: [geeklog-devel] ban by IP in forum no worky Message-ID: <41E2F558.6070001@tonybibbs.com> Trying to get more details on this but this seems to be the case. I have been harrassed the past 10 days by a bozo and banning the IP doesn't work in the forum. Ideally I would just disable the account but that feature isn't supported. More to come... --Tony From dirk at haun-online.de Fri Jan 14 16:25:07 2005 From: dirk at haun-online.de (Dirk Haun) Date: Fri, 14 Jan 2005 22:25:07 +0100 Subject: [geeklog-devel] "Hidden Porn"?! Message-ID: <20050114212508.23523@smtp.haun-online.de> I saw this in the logfiles for geeklog.net and thought "wtf?" [13/Jan/2005:08:29:55 -0500] "GET /hidden-porn/beach/sandy.gif..... HTTP/ 1.1" 404 11320 But then I saw that it came (via Google) from http://lists.geeklog.net/pipermail/geeklog-devtalk/2003-March/000129.html Thanks, Simon :P bye, Dirk -- http://www.haun-online.de/ http://www.haun.info/ From dirk at haun-online.de Sun Jan 16 14:31:27 2005 From: dirk at haun-online.de (Dirk Haun) Date: Sun, 16 Jan 2005 20:31:27 +0100 Subject: [geeklog-devel] Trackback support in CVS Message-ID: <20050116193127.10692@smtp.haun-online.de> Okay, the first major new feature (at least as far as code changes are concerned) for Geeklog 1.3.12 is now in CVS: It's now possible to send and receive trackback comments with Geeklog. If you have no idea what trackback is, here's a nice summary: Since this is probably not a feature that you want to use on a serious / business-oriented site, it can be switched off easily: $_CONF['trackback_enabled'] = false; Trackback is only supported for articles and I don't see a need to implement it for any other of the built-in things like links or events. There is, however, a plugin interface so plugins can easily make use of it (and Geeklog does almost all of the work). This has only been tested with the MT standalone trackback script as well as with Geeklog itself. I'd be interested in any real-life experience with other weblogs. It will probably also need some tweaks to improve usability. Comments and suggestions welcome ... Btw, with the exception of a small piece of code that actually sends the trackback comment, this have been written from scratch. There are existing libraries for trackback comments, but most of the needed code was Geeklog-specific anyway. And it was much more fun this way :-) bye, Dirk -- http://www.haun-online.de/ http://www.handful-of-sparks.de/ From vfuria at gmail.com Sun Jan 16 23:44:49 2005 From: vfuria at gmail.com (Vincent Furia) Date: Sun, 16 Jan 2005 23:44:49 -0500 Subject: [geeklog-devel] GL2 DataAccess Class Message-ID: <8319e2d60501162044335efb64@mail.gmail.com> Tony, Just looking through the DAO to understand everything it is doing better. I noticed that the "find" method (and the other methods) reloads the named queries from the xml file on every call. We should look for a way to work around this (i.e. somehow cache the DOMXPath object) so as not to suffer huge penalties for parsing the XML file on every DB call. -Vinny From tony at tonybibbs.com Mon Jan 17 09:32:53 2005 From: tony at tonybibbs.com (Tony Bibbs) Date: Mon, 17 Jan 2005 08:32:53 -0600 Subject: [geeklog-devel] GL2 DataAccess Class In-Reply-To: <8319e2d60501162044335efb64@mail.gmail.com> References: <8319e2d60501162044335efb64@mail.gmail.com> Message-ID: <41EBCC95.7080203@tonybibbs.com> You mean cache it to memory or to a file. I'd love to cache it to memory but, afaik, it would require php's shared memory which isn't enabled by default. I s'pose if the xml parsing itself if that bad, would could cache a php-friendly data structure to a file. I'm open to this. I just learned how to profile PHP applications this past week so finding poor performing code shouldn't be a problem. --Tony Vincent Furia wrote: >Tony, > >Just looking through the DAO to understand everything it is doing >better. I noticed that the "find" method (and the other methods) >reloads the named queries from the xml file on every call. We should >look for a way to work around this (i.e. somehow cache the DOMXPath >object) so as not to suffer huge penalties for parsing the XML file on >every DB call. > >-Vinny >_______________________________________________ >geeklog-devel mailing list >geeklog-devel at lists.geeklog.net >http://lists.geeklog.net/listinfo/geeklog-devel > > From vfuria at gmail.com Mon Jan 17 09:39:04 2005 From: vfuria at gmail.com (Vincent Furia) Date: Mon, 17 Jan 2005 09:39:04 -0500 Subject: [geeklog-devel] GL2 DataAccess Class In-Reply-To: <41EBCC95.7080203@tonybibbs.com> References: <8319e2d60501162044335efb64@mail.gmail.com> <41EBCC95.7080203@tonybibbs.com> Message-ID: <8319e2d605011706391e0c02d7@mail.gmail.com> Tony, Caching between page calls would be great. But even having a static variable or something similar to persist between calls to the "find" method would be a good start (and probably sufficient for most sites). -Vinny On Mon, 17 Jan 2005 08:32:53 -0600, Tony Bibbs wrote: > You mean cache it to memory or to a file. I'd love to cache it to > memory but, afaik, it would require php's shared memory which isn't > enabled by default. > > I s'pose if the xml parsing itself if that bad, would could cache a > php-friendly data structure to a file. > > I'm open to this. I just learned how to profile PHP applications this > past week so finding poor performing code shouldn't be a problem. > > --Tony > > Vincent Furia wrote: > > >Tony, > > > >Just looking through the DAO to understand everything it is doing > >better. I noticed that the "find" method (and the other methods) > >reloads the named queries from the xml file on every call. We should > >look for a way to work around this (i.e. somehow cache the DOMXPath > >object) so as not to suffer huge penalties for parsing the XML file on > >every DB call. > > > >-Vinny > >_______________________________________________ > >geeklog-devel mailing list > >geeklog-devel at lists.geeklog.net > >http://lists.geeklog.net/listinfo/geeklog-devel > > > > > > _______________________________________________ > geeklog-devel mailing list > geeklog-devel at lists.geeklog.net > http://lists.geeklog.net/listinfo/geeklog-devel > From vfuria at gmail.com Mon Jan 17 10:07:14 2005 From: vfuria at gmail.com (Vincent Furia) Date: Mon, 17 Jan 2005 10:07:14 -0500 Subject: [geeklog-devel] GL2 DataAccess Class In-Reply-To: <8319e2d605011706391e0c02d7@mail.gmail.com> References: <8319e2d60501162044335efb64@mail.gmail.com> <41EBCC95.7080203@tonybibbs.com> <8319e2d605011706391e0c02d7@mail.gmail.com> Message-ID: <8319e2d6050117070717a15298@mail.gmail.com> Tony, Another issue with the DAO class is that it seems catered to providing support only for SELECT's. It won't work for doing INSERT's, UPDATE's, or DELETE's (etc...). -Vinny On Mon, 17 Jan 2005 09:39:04 -0500, Vincent Furia wrote: > Tony, > > Caching between page calls would be great. But even having a static > variable or something similar to persist between calls to the "find" > method would be a good start (and probably sufficient for most sites). > > -Vinny > > > On Mon, 17 Jan 2005 08:32:53 -0600, Tony Bibbs wrote: > > You mean cache it to memory or to a file. I'd love to cache it to > > memory but, afaik, it would require php's shared memory which isn't > > enabled by default. > > > > I s'pose if the xml parsing itself if that bad, would could cache a > > php-friendly data structure to a file. > > > > I'm open to this. I just learned how to profile PHP applications this > > past week so finding poor performing code shouldn't be a problem. > > > > --Tony > > > > Vincent Furia wrote: > > > > >Tony, > > > > > >Just looking through the DAO to understand everything it is doing > > >better. I noticed that the "find" method (and the other methods) > > >reloads the named queries from the xml file on every call. We should > > >look for a way to work around this (i.e. somehow cache the DOMXPath > > >object) so as not to suffer huge penalties for parsing the XML file on > > >every DB call. > > > > > >-Vinny > > >_______________________________________________ > > >geeklog-devel mailing list > > >geeklog-devel at lists.geeklog.net > > >http://lists.geeklog.net/listinfo/geeklog-devel > > > > > > > > > > _______________________________________________ > > geeklog-devel mailing list > > geeklog-devel at lists.geeklog.net > > http://lists.geeklog.net/listinfo/geeklog-devel > > > From tony at tonybibbs.com Mon Jan 17 12:41:21 2005 From: tony at tonybibbs.com (Tony Bibbs) Date: Mon, 17 Jan 2005 11:41:21 -0600 Subject: [geeklog-devel] GL2 DataAccess Class In-Reply-To: <8319e2d6050117070717a15298@mail.gmail.com> References: <8319e2d60501162044335efb64@mail.gmail.com> <41EBCC95.7080203@tonybibbs.com> <8319e2d605011706391e0c02d7@mail.gmail.com> <8319e2d6050117070717a15298@mail.gmail.com> Message-ID: <41EBF8C1.8070503@tonybibbs.com> You sure? It's an easy fix to get around that...but seems the updates/deletes should work. --Tony Vincent Furia wrote: >Tony, > >Another issue with the DAO class is that it seems catered to providing >support only for SELECT's. It won't work for doing INSERT's, >UPDATE's, or DELETE's (etc...). > >-Vinny > > >On Mon, 17 Jan 2005 09:39:04 -0500, Vincent Furia wrote: > > >>Tony, >> >>Caching between page calls would be great. But even having a static >>variable or something similar to persist between calls to the "find" >>method would be a good start (and probably sufficient for most sites). >> >>-Vinny >> >> >>On Mon, 17 Jan 2005 08:32:53 -0600, Tony Bibbs wrote: >> >> >>>You mean cache it to memory or to a file. I'd love to cache it to >>>memory but, afaik, it would require php's shared memory which isn't >>>enabled by default. >>> >>>I s'pose if the xml parsing itself if that bad, would could cache a >>>php-friendly data structure to a file. >>> >>>I'm open to this. I just learned how to profile PHP applications this >>>past week so finding poor performing code shouldn't be a problem. >>> >>>--Tony >>> >>>Vincent Furia wrote: >>> >>> >>> >>>>Tony, >>>> >>>>Just looking through the DAO to understand everything it is doing >>>>better. I noticed that the "find" method (and the other methods) >>>>reloads the named queries from the xml file on every call. We should >>>>look for a way to work around this (i.e. somehow cache the DOMXPath >>>>object) so as not to suffer huge penalties for parsing the XML file on >>>>every DB call. >>>> >>>>-Vinny >>>>_______________________________________________ >>>>geeklog-devel mailing list >>>>geeklog-devel at lists.geeklog.net >>>>http://lists.geeklog.net/listinfo/geeklog-devel >>>> >>>> >>>> >>>> >>>_______________________________________________ >>>geeklog-devel mailing list >>>geeklog-devel at lists.geeklog.net >>>http://lists.geeklog.net/listinfo/geeklog-devel >>> >>> >>> >_______________________________________________ >geeklog-devel mailing list >geeklog-devel at lists.geeklog.net >http://lists.geeklog.net/listinfo/geeklog-devel > > From vfuria at gmail.com Mon Jan 17 13:38:20 2005 From: vfuria at gmail.com (Vincent Furia) Date: Mon, 17 Jan 2005 13:38:20 -0500 Subject: [geeklog-devel] GL2 DataAccess Class In-Reply-To: <41EBF8C1.8070503@tonybibbs.com> References: <8319e2d60501162044335efb64@mail.gmail.com> <41EBCC95.7080203@tonybibbs.com> <8319e2d605011706391e0c02d7@mail.gmail.com> <8319e2d6050117070717a15298@mail.gmail.com> <41EBF8C1.8070503@tonybibbs.com> Message-ID: <8319e2d605011710386432525e@mail.gmail.com> I guess I should have been more specific... There is no way to use criteria to do UPDATEs or DELETEs (criteria with INSERTs doesn't make much sense). It is not clear if what behavior specifying the SQL for UDPATEs, DELETEs and INSERTs will be. From reading the code it looks like the SQL will be executed, I'm just not sure if the program will stop with an error afterwards or throw an exception or just return an empty result set. I haven't tested the DAO code under these conditions, but it looks like something that needs be corrected. -Vinny On Mon, 17 Jan 2005 11:41:21 -0600, Tony Bibbs wrote: > You sure? It's an easy fix to get around that...but seems the > updates/deletes should work. > > --Tony > > Vincent Furia wrote: > > >Tony, > > > >Another issue with the DAO class is that it seems catered to providing > >support only for SELECT's. It won't work for doing INSERT's, > >UPDATE's, or DELETE's (etc...). > > > >-Vinny > > > > > >On Mon, 17 Jan 2005 09:39:04 -0500, Vincent Furia wrote: > > > > > >>Tony, > >> > >>Caching between page calls would be great. But even having a static > >>variable or something similar to persist between calls to the "find" > >>method would be a good start (and probably sufficient for most sites). > >> > >>-Vinny > >> > >> > >>On Mon, 17 Jan 2005 08:32:53 -0600, Tony Bibbs wrote: > >> > >> > >>>You mean cache it to memory or to a file. I'd love to cache it to > >>>memory but, afaik, it would require php's shared memory which isn't > >>>enabled by default. > >>> > >>>I s'pose if the xml parsing itself if that bad, would could cache a > >>>php-friendly data structure to a file. > >>> > >>>I'm open to this. I just learned how to profile PHP applications this > >>>past week so finding poor performing code shouldn't be a problem. > >>> > >>>--Tony > >>> > >>>Vincent Furia wrote: > >>> > >>> > >>> > >>>>Tony, > >>>> > >>>>Just looking through the DAO to understand everything it is doing > >>>>better. I noticed that the "find" method (and the other methods) > >>>>reloads the named queries from the xml file on every call. We should > >>>>look for a way to work around this (i.e. somehow cache the DOMXPath > >>>>object) so as not to suffer huge penalties for parsing the XML file on > >>>>every DB call. > >>>> > >>>>-Vinny > >>>>_______________________________________________ > >>>>geeklog-devel mailing list > >>>>geeklog-devel at lists.geeklog.net > >>>>http://lists.geeklog.net/listinfo/geeklog-devel > >>>> > >>>> > >>>> > >>>> > >>>_______________________________________________ > >>>geeklog-devel mailing list > >>>geeklog-devel at lists.geeklog.net > >>>http://lists.geeklog.net/listinfo/geeklog-devel > >>> > >>> > >>> > >_______________________________________________ > >geeklog-devel mailing list > >geeklog-devel at lists.geeklog.net > >http://lists.geeklog.net/listinfo/geeklog-devel > > > > > > _______________________________________________ > geeklog-devel mailing list > geeklog-devel at lists.geeklog.net > http://lists.geeklog.net/listinfo/geeklog-devel > From dirk at haun-online.de Mon Jan 17 15:18:50 2005 From: dirk at haun-online.de (Dirk Haun) Date: Mon, 17 Jan 2005 21:18:50 +0100 Subject: [geeklog-devel] About the forum spammer Message-ID: <20050117201850.24082@smtp.haun-online.de> Found this: http://wordpress.org/support/topic.php?id=20956 It's about a known case of comment spamming in weblogs. The author noticed that all the domains used in the comment spams resolve to the same IP address, 161.58.59.8 And look what we just got (thanks Tom, thanks SpamX plugin!): | Please check some helpful info about internet poker dirk at terra:dirk> ping fidelityfunding.net PING fidelityfunding.net (161.58.59.8): 56 data bytes The nice thing is that he's also setting up bogus "account terminated" pages (try the above URL). Anyway, the IP address might be another filter criterion, instead of having to update the blacklist all the time. Anyone wanting to write a SpamX module for this? MT Blacklist is lagging behind, btw. The last few spam posts were only caught because they contained "texas holdem" - whatever that is, but it appears in all those posts. bye, Dirk -- http://www.haun-online.de/ http://www.macosx-faq.de/ From vfuria at gmail.com Mon Jan 17 16:36:39 2005 From: vfuria at gmail.com (Vincent Furia) Date: Mon, 17 Jan 2005 16:36:39 -0500 Subject: [geeklog-devel] About the forum spammer In-Reply-To: <20050117201850.24082@smtp.haun-online.de> References: <20050117201850.24082@smtp.haun-online.de> Message-ID: <8319e2d60501171336411142a4@mail.gmail.com> Texas Hold'em is type of Poker. The world poker championship in Vegas plays Texas Hold'em. A lot of gambling sites push it, a lot of those are sketchy, hence the need to block the text. -Vinny On Mon, 17 Jan 2005 21:18:50 +0100, Dirk Haun wrote: > Found this: > > http://wordpress.org/support/topic.php?id=20956 > > It's about a known case of comment spamming in weblogs. The author > noticed that all the domains used in the comment spams resolve to the > same IP address, 161.58.59.8 > > And look what we just got (thanks Tom, thanks SpamX plugin!): > > | Please check some helpful info about internet poker > > dirk at terra:dirk> ping fidelityfunding.net > PING fidelityfunding.net (161.58.59.8): 56 data bytes > > The nice thing is that he's also setting up bogus "account terminated" > pages (try the above URL). > > Anyway, the IP address might be another filter criterion, instead of > having to update the blacklist all the time. Anyone wanting to write a > SpamX module for this? > > MT Blacklist is lagging behind, btw. The last few spam posts were only > caught because they contained "texas holdem" - whatever that is, but it > appears in all those posts. > > bye, Dirk > > -- > http://www.haun-online.de/ > http://www.macosx-faq.de/ > > _______________________________________________ > geeklog-devel mailing list > geeklog-devel at lists.geeklog.net > http://lists.geeklog.net/listinfo/geeklog-devel > From slord at marelina.com Wed Jan 19 00:14:18 2005 From: slord at marelina.com (Simon Lord) Date: Wed, 19 Jan 2005 00:14:18 -0500 Subject: [geeklog-devel] Google ranking and blogs... Message-ID: http://arstechnica.com/news.ars/post/20050118-4536.html Sincerely, Simon From tomw at pigstye.net Wed Jan 19 10:10:18 2005 From: tomw at pigstye.net (Tom Willett) Date: Wed, 19 Jan 2005 10:10:18 -0500 Subject: [geeklog-devel] About the forum spammer In-Reply-To: <20050117201850.24082@smtp.haun-online.de> References: <20050117201850.24082@smtp.haun-online.de> Message-ID: <41EE785A.1060906@pigstye.net> On 1/17/2005 3:18 PM, Dirk Haun wrote: >Found this: > > http://wordpress.org/support/topic.php?id=20956 > >It's about a known case of comment spamming in weblogs. The author >noticed that all the domains used in the comment spams resolve to the >same IP address, 161.58.59.8 > >And look what we just got (thanks Tom, thanks SpamX plugin!): > >| Please check some helpful info about internet poker > >dirk at terra:dirk> ping fidelityfunding.net >PING fidelityfunding.net (161.58.59.8): 56 data bytes > >The nice thing is that he's also setting up bogus "account terminated" >pages (try the above URL). > >Anyway, the IP address might be another filter criterion, instead of >having to update the blacklist all the time. Anyone wanting to write a >SpamX module for this? > >MT Blacklist is lagging behind, btw. The last few spam posts were only >caught because they contained "texas holdem" - whatever that is, but it >appears in all those posts. > >bye, Dirk > > > > Here you go. -- Tom Willett tomw at pigstye.net -------------- next part -------------- A non-text attachment was scrubbed... Name: Spamx.IP.tar.gz Type: application/x-gzip Size: 1482 bytes Desc: not available URL: From dirk at haun-online.de Wed Jan 19 15:11:42 2005 From: dirk at haun-online.de (Dirk Haun) Date: Wed, 19 Jan 2005 21:11:42 +0100 Subject: [geeklog-devel] Google ranking and blogs... In-Reply-To: References: Message-ID: <20050119201142.7497@smtp.haun-online.de> >http://arstechnica.com/news.ars/post/20050118-4536.html There's a forum thread about this here: http://www.geeklog.net/forum/viewtopic.php?showtopic=46405 bye, Dirk -- http://www.haun-online.de/ http://www.macosx-faq.de/ From dirk at haun-online.de Wed Jan 19 16:02:40 2005 From: dirk at haun-online.de (Dirk Haun) Date: Wed, 19 Jan 2005 22:02:40 +0100 Subject: [geeklog-devel] About the forum spammer In-Reply-To: <41EE785A.1060906@pigstye.net> References: <41EE785A.1060906@pigstye.net> Message-ID: <20050119210240.23699@smtp.haun-online.de> >Here you go. Thanks, Tom :-) But I guess line 44 in IP.Examine.class.php: if ($val = $_SERVER['REMOTE_ADDR'])) { should really read if ($val == $_SERVER['REMOTE_ADDR']) { i.e. add one '=', remove one ')'. Also, this seems to block by IP address. What I meant was that all the domains in the spam post resolve to a certain IP address. The spam post itself is sent from one of the hijacked PCs under the spammer's control, so blocking by their IP address won't help much in this case. It's still useful for other cases, so I'll probably be adding it to CVS anyway. bye, Dirk -- http://www.haun-online.de/ http://www.macosx-faq.de/ From dirk at haun-online.de Wed Jan 19 16:52:02 2005 From: dirk at haun-online.de (Dirk Haun) Date: Wed, 19 Jan 2005 22:52:02 +0100 Subject: [geeklog-devel] Deleting comments Message-ID: <20050119215202.10376@smtp.haun-online.de> Since Geeklog 1.3.10, deleting comments isn't done with a simple DB_delete call any more - the relation with other comments on the same "comment tree" has to be fixed as well. Geeklog does that for comments on stories and polls, but not for comments in plugins (most prominent example: File Management plugin, but there are others). So I guess what we need is a function that deletes a comment properly and give plugins a way to access it. Just the other day, I was actually thinking about moving all the comment- related functions from lib-common.php[1] into their own lib-comment.php file. If we add a COM_deleteComment function to that, plugins could simply include that file and delete comments properly. The other option would be to change the PLG_handlePluginComment(..., 'delete') call yet again and only make it indicate if it's okay to delete the comment, but let Geeklog do the actual deletion. Vinny? Blaine? bye, Dirk [1] which amount for almost 10% of the code in lib-common.php, btw -- http://www.haun-online.de/ http://www.tinyweb.de/ From geeklog at langfamily.ca Wed Jan 19 17:09:44 2005 From: geeklog at langfamily.ca (Blaine Lang) Date: Wed, 19 Jan 2005 17:09:44 -0500 Subject: [geeklog-devel] About the forum spammer References: <41EE785A.1060906@pigstye.net> <20050119210240.23699@smtp.haun-online.de> Message-ID: <02c501c4fe73$951e6db0$650a10ac@XPBL2> Yeh - Thanks Tom :) Another nice addition. So ... are you up for another extension to query the IP's if there are multiple links in the post? Or maybe we just reject posts with more then a set number of links :) Blaine ----- Original Message ----- From: "Dirk Haun" To: Sent: Wednesday, January 19, 2005 4:02 PM Subject: Re: [geeklog-devel] About the forum spammer >Here you go. Thanks, Tom :-) But I guess line 44 in IP.Examine.class.php: if ($val = $_SERVER['REMOTE_ADDR'])) { should really read if ($val == $_SERVER['REMOTE_ADDR']) { i.e. add one '=', remove one ')'. Also, this seems to block by IP address. What I meant was that all the domains in the spam post resolve to a certain IP address. The spam post itself is sent from one of the hijacked PCs under the spammer's control, so blocking by their IP address won't help much in this case. It's still useful for other cases, so I'll probably be adding it to CVS anyway. bye, Dirk -- http://www.haun-online.de/ http://www.macosx-faq.de/ _______________________________________________ geeklog-devel mailing list geeklog-devel at lists.geeklog.net http://lists.geeklog.net/listinfo/geeklog-devel From geeklog at langfamily.ca Wed Jan 19 17:11:19 2005 From: geeklog at langfamily.ca (Blaine Lang) Date: Wed, 19 Jan 2005 17:11:19 -0500 Subject: [geeklog-devel] Deleting comments References: <20050119215202.10376@smtp.haun-online.de> Message-ID: <02ca01c4fe73$cdb4d150$650a10ac@XPBL2> Hi Dirk, I like any idea to reduce the size of lib-common and was not aware the comment functions already are some 500 lines of code. I don't have an issue with the Plugin Api changing if thats a better option. Blaine ----- Original Message ----- From: "Dirk Haun" To: Sent: Wednesday, January 19, 2005 4:52 PM Subject: [geeklog-devel] Deleting comments Since Geeklog 1.3.10, deleting comments isn't done with a simple DB_delete call any more - the relation with other comments on the same "comment tree" has to be fixed as well. Geeklog does that for comments on stories and polls, but not for comments in plugins (most prominent example: File Management plugin, but there are others). So I guess what we need is a function that deletes a comment properly and give plugins a way to access it. Just the other day, I was actually thinking about moving all the comment- related functions from lib-common.php[1] into their own lib-comment.php file. If we add a COM_deleteComment function to that, plugins could simply include that file and delete comments properly. The other option would be to change the PLG_handlePluginComment(..., 'delete') call yet again and only make it indicate if it's okay to delete the comment, but let Geeklog do the actual deletion. Vinny? Blaine? bye, Dirk [1] which amount for almost 10% of the code in lib-common.php, btw -- http://www.haun-online.de/ http://www.tinyweb.de/ _______________________________________________ geeklog-devel mailing list geeklog-devel at lists.geeklog.net http://lists.geeklog.net/listinfo/geeklog-devel From tony at tonybibbs.com Wed Jan 19 17:17:41 2005 From: tony at tonybibbs.com (Tony Bibbs) Date: Wed, 19 Jan 2005 16:17:41 -0600 Subject: [geeklog-devel] Deleting comments In-Reply-To: <20050119215202.10376@smtp.haun-online.de> References: <20050119215202.10376@smtp.haun-online.de> Message-ID: <41EEDC85.4030809@tonybibbs.com> Dirk Haun wrote: >Just the other day, I was actually thinking about moving all the comment- >related functions from lib-common.php[1] into their own lib-comment.php >file. If we add a COM_deleteComment function to that, plugins could >simply include that file and delete comments properly. > > If you mean lib-comment.php that would actually be CMT_deleteComment, right? I'm guessing you mean not to confuse it with lib-common.php functions. I'm all for this. I think you could also justify HTML-related stuff like COM_startHeader, COM_startBlock, etc. In fact, it might be a good exercise to review the code in lib-common.php and determinte what categories of functions you can come up with and decide how to layout the libraries. Only issue with this sort of stuff is it will clearly break compatiblity. I say you would leave the stubbed out functions in lib-common.php, call the new library equivalent (i.e. COM_deleteComment would call CMT_deleteComment) and then log a warning to error.log that the function is deprecated and will be removed in a future version. Thinking out loud, --Tony From vfuria at gmail.com Wed Jan 19 20:56:08 2005 From: vfuria at gmail.com (Vincent Furia) Date: Wed, 19 Jan 2005 20:56:08 -0500 Subject: [geeklog-devel] Deleting comments In-Reply-To: <41EEDC85.4030809@tonybibbs.com> References: <20050119215202.10376@smtp.haun-online.de> <41EEDC85.4030809@tonybibbs.com> Message-ID: <8319e2d6050119175652674cca@mail.gmail.com> Also the functions in comment.php could probably be moved into the "lib-comment.php" file as well. If you'd like, I can take a first stab at this this coming weekend (with the weather here I should have time to get some work done). Though if you'd prefer to do it I won't get hurt feelings. Hopefully Tony won't mind me working on something besides Geeklog-2. ;) If you want to get really adventurous, I could go crazy and implement comments in a more OO fashion. -Vinny P.S. For those interested, I just checked in the first part of comments for GL2. See http://cvs.geeklog.net/co.php/Geeklog-2/system/Propel/Geeklog-2/Gl2Comment.php. Just ignore the FIXMEs. :) On Wed, 19 Jan 2005 16:17:41 -0600, Tony Bibbs wrote: > Dirk Haun wrote: > > >Just the other day, I was actually thinking about moving all the comment- > >related functions from lib-common.php[1] into their own lib-comment.php > >file. If we add a COM_deleteComment function to that, plugins could > >simply include that file and delete comments properly. > > > > > If you mean lib-comment.php that would actually be CMT_deleteComment, > right? I'm guessing you mean not to confuse it with lib-common.php > functions. I'm all for this. I think you could also justify HTML-related > stuff like COM_startHeader, COM_startBlock, etc. In fact, it might be a > good exercise to review the code in lib-common.php and determinte what > categories of functions you can come up with and decide how to layout > the libraries. > > Only issue with this sort of stuff is it will clearly break > compatiblity. I say you would leave the stubbed out functions in > lib-common.php, call the new library equivalent (i.e. COM_deleteComment > would call CMT_deleteComment) and then log a warning to error.log that > the function is deprecated and will be removed in a future version. > > Thinking out loud, > > --Tony > _______________________________________________ > geeklog-devel mailing list > geeklog-devel at lists.geeklog.net > http://lists.geeklog.net/listinfo/geeklog-devel > From dirk at haun-online.de Thu Jan 20 02:00:55 2005 From: dirk at haun-online.de (Dirk Haun) Date: Thu, 20 Jan 2005 08:00:55 +0100 Subject: [geeklog-devel] Deleting comments In-Reply-To: <41EEDC85.4030809@tonybibbs.com> References: <41EEDC85.4030809@tonybibbs.com> Message-ID: <20050120070055.6205@smtp.haun-online.de> Tony, >Only issue with this sort of stuff is it will clearly break >compatiblity. I say you would leave the stubbed out functions in >lib-common.php, call the new library equivalent (i.e. COM_deleteComment >would call CMT_deleteComment) and then log a warning to error.log that >the function is deprecated and will be removed in a future version. That would still require lib-common.php to include the lib-comment.php then. Since comments are only used by a few components (and plugins) I was actually thinking about getting rid of that code entirely so that those components that actually need it would have to include this. if (!function_exists ('COM_comment')) { require_once ($_CONF['path_system'] . 'lib-comment.php'); } Yeah, it would break compatibility. But then again, there are more flaws in the plugin API regarding comments (I'll post something about them later) and this would be a good opportunity to fix them all at once. Vinny, I'm not opposed to having a comment.class.php instead of the lib- comment.php if you think that makes sense. bye, Dirk -- http://www.haun-online.de/ http://mypod.de/ From tomw at pigstye.net Thu Jan 20 13:10:38 2005 From: tomw at pigstye.net (Tom Willett) Date: Thu, 20 Jan 2005 13:10:38 -0500 Subject: [geeklog-devel] About the forum spammer In-Reply-To: <02c501c4fe73$951e6db0$650a10ac@XPBL2> References: <41EE785A.1060906@pigstye.net> <20050119210240.23699@smtp.haun-online.de> <02c501c4fe73$951e6db0$650a10ac@XPBL2> Message-ID: <41EFF41E.1000406@pigstye.net> On 1/19/2005 5:09 PM, Blaine Lang wrote: >Yeh - Thanks Tom :) >Another nice addition. > >So ... are you up for another extension to query the IP's if there are >multiple links in the post? > >Or maybe we just reject posts with more then a set number of links :) > >Blaine > >----- Original Message ----- >From: "Dirk Haun" >To: >Sent: Wednesday, January 19, 2005 4:02 PM >Subject: Re: [geeklog-devel] About the forum spammer > > > > >>Here you go. >> >> > >Thanks, Tom :-) > >But I guess line 44 in IP.Examine.class.php: > > if ($val = $_SERVER['REMOTE_ADDR'])) { > >should really read > > if ($val == $_SERVER['REMOTE_ADDR']) { > >i.e. add one '=', remove one ')'. > > >Also, this seems to block by IP address. What I meant was that all the >domains in the spam post resolve to a certain IP address. The spam post >itself is sent from one of the hijacked PCs under the spammer's control, >so blocking by their IP address won't help much in this case. > >It's still useful for other cases, so I'll probably be adding it to CVS >anyway. > >bye, Dirk > > > > Ok here is one that will check the IP of the urls and reject based on the IP I had brush up on regex for this one. -- Tom Willett tomw at pigstye.net -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: Spamx.IPofURL.tar.gz Type: application/x-gzip Size: 1637 bytes Desc: not available URL: From tony at tonybibbs.com Thu Jan 20 14:03:06 2005 From: tony at tonybibbs.com (Tony Bibbs) Date: Thu, 20 Jan 2005 13:03:06 -0600 Subject: [geeklog-devel] Deleting comments In-Reply-To: <20050120070055.6205@smtp.haun-online.de> References: <41EEDC85.4030809@tonybibbs.com> <20050120070055.6205@smtp.haun-online.de> Message-ID: <41F0006A.7010403@tonybibbs.com> Dirk, actually, in the stubbed out functions I would put the require_once: function COM_deleteComment() { require_once '/path/to/lib-comment.php'; CMT_deleteComment(); } Gets around the issue of including code that probably won't be used and it provides the backwards compatibility. Note that making this elegant isn't a big deal as that the whole notion of deprecating the COM_*Comment functions is that those functions will eventually go bye-bye. Also, worth noting is that you shouldn't call require_once after you do a function_exists. The overhead to check for the function is made up automatically by simply calling require_once. --Tony Dirk Haun wrote: >Tony, > > > >>Only issue with this sort of stuff is it will clearly break >>compatiblity. I say you would leave the stubbed out functions in >>lib-common.php, call the new library equivalent (i.e. COM_deleteComment >>would call CMT_deleteComment) and then log a warning to error.log that >>the function is deprecated and will be removed in a future version. >> >> > >That would still require lib-common.php to include the lib-comment.php >then. Since comments are only used by a few components (and plugins) I >was actually thinking about getting rid of that code entirely so that >those components that actually need it would have to include this. > >if (!function_exists ('COM_comment')) { > require_once ($_CONF['path_system'] . 'lib-comment.php'); >} > >Yeah, it would break compatibility. But then again, there are more flaws >in the plugin API regarding comments (I'll post something about them >later) and this would be a good opportunity to fix them all at once. > >Vinny, I'm not opposed to having a comment.class.php instead of the lib- >comment.php if you think that makes sense. > >bye, Dirk > > > > From dirk at haun-online.de Fri Jan 21 02:00:45 2005 From: dirk at haun-online.de (Dirk Haun) Date: Fri, 21 Jan 2005 08:00:45 +0100 Subject: [geeklog-devel] Deleting comments In-Reply-To: <41F0006A.7010403@tonybibbs.com> References: <41F0006A.7010403@tonybibbs.com> Message-ID: <20050121070045.9473@smtp.haun-online.de> Tony, >Dirk, actually, in the stubbed out functions I would put the require_once: > >function COM_deleteComment() >{ > require_once '/path/to/lib-comment.php'; > CMT_deleteComment(); >} > >Gets around the issue of including code that probably won't be used and >it provides the backwards compatibility. Makes perfect sense, thanks. bye, Dirk -- http://www.haun-online.de/ http://www.haun.info/ From dirk at haun-online.de Fri Jan 21 12:51:52 2005 From: dirk at haun-online.de (Dirk Haun) Date: Fri, 21 Jan 2005 18:51:52 +0100 Subject: [geeklog-devel] Minimum requirements: MySQL Message-ID: <20050121175152.19032@smtp.haun-online.de> For the next Geeklog release, I'm going to raise the minimum requirements _slightly_ again. This time, it's the MySQL version: The new minimum requirement will be 3.23.2. Currently, we don't specifiy a minimum version and have even incorporated changes to support 3.22 in the past. As of MySQL 3.23.2 it's possible to have an index on a field that's DEFAULT NULL. We take that into account in the inital install, but not in upgrades and it's a real hassle to handle that in upgrades. I think this is reasonable. MySQL AB have stopped supporting 3.22 long ago, and anyone running on something older than 3.23.45 (or thereabouts) is vulnerable to various security issues anyway. Not to mention that the current version recommended for production use is 4.1.9. I'm also going to change the install script such that it aborts the install when it encounters PHP versions older than 4.1.0 or MySQL versions older than 3.23.2. Parallel to that, my goal for Geeklog 1.3.12 is to get rid of the old "long" PHP HTTP arrays ($HTTP_GET_VARS, etc.) and only use the "short" ones ($_GET). This will help people running PHP 5, where the old-style arrays are disabled by default. Since some plugins and add-ons may require the "long" arrays, I'm going to add a warning to the install script for that case (as suggested by bug report #360). Does anyone see a problem with any of this? bye, Dirk -- http://www.geeklog.net/ http://geeklog.info/ From tony at tonybibbs.com Fri Jan 21 14:17:07 2005 From: tony at tonybibbs.com (Tony Bibbs) Date: Fri, 21 Jan 2005 13:17:07 -0600 Subject: [geeklog-devel] Minimum requirements: MySQL In-Reply-To: <20050121175152.19032@smtp.haun-online.de> References: <20050121175152.19032@smtp.haun-online.de> Message-ID: <41F15533.1020006@tonybibbs.com> Not at all. Makes perfect sense. --Tony Dirk Haun wrote: >For the next Geeklog release, I'm going to raise the minimum requirements >_slightly_ again. > >This time, it's the MySQL version: The new minimum requirement will be >3.23.2. Currently, we don't specifiy a minimum version and have even >incorporated changes to support 3.22 in the past. > >As of MySQL 3.23.2 it's possible to have an index on a field that's >DEFAULT NULL. We take that into account in the inital install, but not in >upgrades and it's a real hassle to handle that in upgrades. > >I think this is reasonable. MySQL AB have stopped supporting 3.22 long >ago, and anyone running on something older than 3.23.45 (or thereabouts) >is vulnerable to various security issues anyway. Not to mention that the >current version recommended for production use is 4.1.9. > >I'm also going to change the install script such that it aborts the >install when it encounters PHP versions older than 4.1.0 or MySQL >versions older than 3.23.2. > >Parallel to that, my goal for Geeklog 1.3.12 is to get rid of the old >"long" PHP HTTP arrays ($HTTP_GET_VARS, etc.) and only use the "short" >ones ($_GET). This will help people running PHP 5, where the old-style >arrays are disabled by default. > >Since some plugins and add-ons may require the "long" arrays, I'm going >to add a warning to the install script for that case (as suggested by bug >report #360). > >Does anyone see a problem with any of this? > >bye, Dirk > > > > From vfuria at gmail.com Fri Jan 21 18:34:27 2005 From: vfuria at gmail.com (Vincent Furia) Date: Fri, 21 Jan 2005 18:34:27 -0500 Subject: [geeklog-devel] Deleting comments In-Reply-To: <20050121070045.9473@smtp.haun-online.de> References: <41F0006A.7010403@tonybibbs.com> <20050121070045.9473@smtp.haun-online.de> Message-ID: <8319e2d60501211534c725830@mail.gmail.com> The only comment function that I see in lib-common.php that is used outside the other comment functions is COM_userComments. I'll leave a depreciated version of that function in lib-common.php, but the other comment functions I'm just going to move out. By the way, I'm placing all the COM_ comment functions and the functions in comment.php into lib-comment.php. Right now that looks like about 1200 or so lines of code. All that is checked in. Next step is to look at redoing the comment API (especially for deletes). The tough part of that will be keeping it backwards compatible. -Vinny On Fri, 21 Jan 2005 08:00:45 +0100, Dirk Haun wrote: > Tony, > > >Dirk, actually, in the stubbed out functions I would put the require_once: > > > >function COM_deleteComment() > >{ > > require_once '/path/to/lib-comment.php'; > > CMT_deleteComment(); > >} > > > >Gets around the issue of including code that probably won't be used and > >it provides the backwards compatibility. > > Makes perfect sense, thanks. > > bye, Dirk > > -- > http://www.haun-online.de/ > http://www.haun.info/ > > _______________________________________________ > geeklog-devel mailing list > geeklog-devel at lists.geeklog.net > http://lists.geeklog.net/listinfo/geeklog-devel > From dirk at haun-online.de Sat Jan 22 05:00:58 2005 From: dirk at haun-online.de (Dirk Haun) Date: Sat, 22 Jan 2005 11:00:58 +0100 Subject: [geeklog-devel] Deleting comments In-Reply-To: <8319e2d60501211534c725830@mail.gmail.com> References: <8319e2d60501211534c725830@mail.gmail.com> Message-ID: <20050122100058.4815@smtp.haun-online.de> Vincent Furia wrote: >Next step is to look at redoing the comment API (especially for >deletes). For the trackback comments, I've introduced a function that only checks with the plugin if it would be okay for the current user to delete a comment on an object under the plugin's control. The actual delete is then done by Geeklog. /** * Ask plugins to handle a trackback comment operation. * * Operations: * 'accept' - does the plugin accept a trackback comment for its entry $id, * returns: true or false * 'delete' - does the user have permission to delete comments on entry $id, * returns: true or false * 'info' - plugin is asked to provide information on entry $id, * returns: array (url, title, excerpt) * * @param string $type plugin type * @param string $id ID of an entry under the plugin's control * @param string $operation operation to perform * @return mixed depends on the operation (see above) * */ function PLG_handleTrackbackComment ($type, $id, $operation) Since this isn't used anywhere yet, we could easily change it to keep it in sync with the plugin API for "normal" comments. >The tough part of that will be keeping it backwards compatible. Since the current delete is actually messing up the comments, I'd say we should break it on purpose ... bye, Dirk -- http://www.haun-online.de/ http://mypod.de/ From dirk at haun-online.de Sat Jan 22 08:48:30 2005 From: dirk at haun-online.de (Dirk Haun) Date: Sat, 22 Jan 2005 14:48:30 +0100 Subject: [geeklog-devel] Table locking Message-ID: <20050122134831.16890@smtp.haun-online.de> It seems some of our users are still having problems getting their hosting service to allow them to lock tables (needed to post comments as of Geeklog 1.3.10). The excuses from the hosting services I've heard so far are ... less than convincing, to put it politely. Can our resident database experts try and shed some light on it in this thread, please? http://www.geeklog.net/forum/viewtopic.php?showtopic=45428 bye, Dirk -- http://www.haun-online.de/ http://mypod.de/ From vfuria at gmail.com Sat Jan 22 09:55:54 2005 From: vfuria at gmail.com (Vincent Furia) Date: Sat, 22 Jan 2005 09:55:54 -0500 Subject: [geeklog-devel] Table locking In-Reply-To: <20050122134831.16890@smtp.haun-online.de> References: <20050122134831.16890@smtp.haun-online.de> Message-ID: <8319e2d60501220655500663dd@mail.gmail.com> Just posted the following to the thread. -Vinny ---------- Assuming your hosting service is making up a lame excuse not to give you LOCK TABLES privileges there are a couple things you can do: 0. Tell your host that you want "LOCK TABLE" priveleges or you'll take your business else where, all the excuses I've seen on this thread seem very lame. Smile 1. Remove all the "LOCK TABLE" "UNLOCK TABLE" SQL calls from comment.php. This should be okay if you have a low traffice site, but opens up the possiblity of corruption if two or more users try to save or delete comments at the same time. 2. Upgrade to InnoDB tables. There is a script in the admin directory to do this. Then change every instance of "LOCK TABLE XXX" to "START TRANSACTION" and every instance of "UNLOCK TABLE XXX" to "COMMIT". The only downside to this is that it is untested and will only work with InnoDB tables. If anyone tries this let me know how it works. I appologize to everyone for the problems that the LOCK statements are causing. They were implemented to improve comment display performance (which was misserable). Good Luck, Vinny P.S. Dirk, do you want to this to the FAQ? On Sat, 22 Jan 2005 14:48:30 +0100, Dirk Haun wrote: > It seems some of our users are still having problems getting their > hosting service to allow them to lock tables (needed to post comments as > of Geeklog 1.3.10). > > The excuses from the hosting services I've heard so far are ... less than > convincing, to put it politely. > > Can our resident database experts try and shed some light on it in this > thread, please? > > http://www.geeklog.net/forum/viewtopic.php?showtopic=45428 > > bye, Dirk > > -- > http://www.haun-online.de/ > http://mypod.de/ > > _______________________________________________ > geeklog-devel mailing list > geeklog-devel at lists.geeklog.net > http://lists.geeklog.net/listinfo/geeklog-devel > From dirk at haun-online.de Sat Jan 22 16:23:05 2005 From: dirk at haun-online.de (Dirk Haun) Date: Sat, 22 Jan 2005 22:23:05 +0100 Subject: [geeklog-devel] DB_delete vs. DB_query("DELETE FROM ...") Message-ID: <20050122212305.17899@smtp.haun-online.de> Just an observation: I've noticed that we're using DB_query("DELETE FROM...") a lot when we actually have a separate function for that: DB_delete | dirk at terra:geeklog-1.3> grep -r 'DB_q.*DELETE FROM' . | wc -l | 47 bye, Dirk -- http://www.haun-online.de/ http://geeklog.info/ From vfuria at gmail.com Sat Jan 22 21:22:49 2005 From: vfuria at gmail.com (Vincent Furia) Date: Sat, 22 Jan 2005 21:22:49 -0500 Subject: [geeklog-devel] Deleting comments In-Reply-To: <20050122100058.4815@smtp.haun-online.de> References: <8319e2d60501211534c725830@mail.gmail.com> <20050122100058.4815@smtp.haun-online.de> Message-ID: <8319e2d60501221822155fb96a@mail.gmail.com> With Dirk's blessing to break the comment plugin API. Here is my idea thus far: CMT_deleteComment and CMT_saveComment will be limited to exactly that functionality. They will act no different for articles or polls as they would for any other variable. They will return 0 for success or >0 for failure (and log the failure to the errorLog). I plan on doing something similar for CMT_commentForm. So there will now be plugin functions for saving and deleting comments which should simply call these functions when they are ready (and determine that the correct permissions hold, etc). I'll continue with this approach if it sounds good to everyone. I'd especially like some feedback from anyone currently using the plugin comment functionality. -Vinny On Sat, 22 Jan 2005 11:00:58 +0100, Dirk Haun wrote: > Vincent Furia wrote: > > >Next step is to look at redoing the comment API (especially for > >deletes). > > For the trackback comments, I've introduced a function that only checks > with the plugin if it would be okay for the current user to delete a > comment on an object under the plugin's control. The actual delete is > then done by Geeklog. > > /** > * Ask plugins to handle a trackback comment operation. > * > * Operations: > * 'accept' - does the plugin accept a trackback comment for its entry $id, > * returns: true or false > * 'delete' - does the user have permission to delete comments on entry $id, > * returns: true or false > * 'info' - plugin is asked to provide information on entry $id, > * returns: array (url, title, excerpt) > * > * @param string $type plugin type > * @param string $id ID of an entry under the plugin's control > * @param string $operation operation to perform > * @return mixed depends on the operation (see above) > * > */ > function PLG_handleTrackbackComment ($type, $id, $operation) > > Since this isn't used anywhere yet, we could easily change it to keep it > in sync with the plugin API for "normal" comments. > > > >The tough part of that will be keeping it backwards compatible. > > Since the current delete is actually messing up the comments, I'd say we > should break it on purpose ... > > bye, Dirk > > -- > http://www.haun-online.de/ > http://mypod.de/ > > _______________________________________________ > geeklog-devel mailing list > geeklog-devel at lists.geeklog.net > http://lists.geeklog.net/listinfo/geeklog-devel > From vfuria at gmail.com Sun Jan 23 15:57:25 2005 From: vfuria at gmail.com (Vincent Furia) Date: Sun, 23 Jan 2005 15:57:25 -0500 Subject: [geeklog-devel] GL2 PHPDoc Message-ID: <8319e2d60501231257679669f8@mail.gmail.com> For shits and giggles I ran PHPDoc on Geeklog-2. It actually turned out decently nice (with most of the default values left alone). Check it out at: http://vinny.furiafamily.com/gl2doc/ -Vinny From tony at tonybibbs.com Mon Jan 24 09:37:15 2005 From: tony at tonybibbs.com (Tony Bibbs) Date: Mon, 24 Jan 2005 08:37:15 -0600 Subject: [geeklog-devel] GL2 PHPDoc In-Reply-To: <8319e2d60501231257679669f8@mail.gmail.com> References: <8319e2d60501231257679669f8@mail.gmail.com> Message-ID: <41F5081B.5080306@tonybibbs.com> Sweet, thanks. --Tony Vincent Furia wrote: >For shits and giggles I ran PHPDoc on Geeklog-2. It actually turned >out decently nice (with most of the default values left alone). Check >it out at: > >http://vinny.furiafamily.com/gl2doc/ > >-Vinny >_______________________________________________ >geeklog-devel mailing list >geeklog-devel at lists.geeklog.net >http://lists.geeklog.net/listinfo/geeklog-devel > > From tony at tonybibbs.com Mon Jan 24 09:47:07 2005 From: tony at tonybibbs.com (Tony Bibbs) Date: Mon, 24 Jan 2005 08:47:07 -0600 Subject: [geeklog-devel] GL2 Update Message-ID: <41F50A6B.4030907@tonybibbs.com> The last week or so has been slow for me because of my wife and I finally getting our house sold. Bad news is now we have to find a new one (before April 7th). I'll be trying to pick away at a few things here this week, particularly HTTP_Session2. Vinny, brought up the idea of having a separate GL2 mailing list. Seems to make sense only if we want to keep the 2.x stuff separate from the 1.3.x stuff. I'll probably go ahead and create geeklog2-devel later this week if I don't hear anything. In the meantime, Kevin Vidomski is going to start the links plugin. We figured that would be a good one since it is relatively trivial. If you have a wishlist for features in the gl2 links plugin now is the time to ask. Kevin, once we start getting feature requests we'll review them quickly so that we can weed out the good requests from the bad. --Tony From vfuria at gmail.com Mon Jan 24 10:46:16 2005 From: vfuria at gmail.com (Vincent Furia) Date: Mon, 24 Jan 2005 10:46:16 -0500 Subject: [geeklog-devel] article.php plugin comment code Message-ID: <8319e2d605012407467518bcf@mail.gmail.com> Anyone know why this: // First see if we have a plugin that may be trying to use the Geeklog comment engine $type = COM_applyFilter ($_REQUEST['type']); if (!empty ($type) && PLG_supportsComments ($type)) { // Yes, this is a plugin wanting to be commented on...do it $display .= PLG_callCommentForm($type,$story,$mode,$order,$reply); echo $display; exit(); } is in article.php? Is it used? -VInny From dirk at haun-online.de Mon Jan 24 13:47:23 2005 From: dirk at haun-online.de (Dirk Haun) Date: Mon, 24 Jan 2005 19:47:23 +0100 Subject: [geeklog-devel] article.php plugin comment code In-Reply-To: <8319e2d605012407467518bcf@mail.gmail.com> References: <8319e2d605012407467518bcf@mail.gmail.com> Message-ID: <20050124184723.23050@smtp.haun-online.de> Vinny, >Anyone know why this: [...] >is in article.php? Is it used? Heh, I've been scratching my head over this one just the other day when I was implementing the trackback comments. I have no idea why it is there. Maybe at one point, there was a redirect from the comments page through article.php? I don't think it's used any more. Same goes for the lines following the code you quoted which count the number of poll questions, for whatever reason ... Feel free to throw these lines out. bye, Dirk -- http://www.haun-online.de/ http://mypod.de/ From dirk at haun-online.de Mon Jan 24 13:50:06 2005 From: dirk at haun-online.de (Dirk Haun) Date: Mon, 24 Jan 2005 19:50:06 +0100 Subject: [geeklog-devel] GL2 Update In-Reply-To: <41F50A6B.4030907@tonybibbs.com> References: <41F50A6B.4030907@tonybibbs.com> Message-ID: <20050124185006.27948@smtp.haun-online.de> Tony, >I'll probably go ahead and create geeklog2-devel later >this week if I don't hear anything. Probably makes sense to have it public (as opposed to semi-closed like this list), so that people interested in GL2 development can join easily. >In the meantime, Kevin Vidomski is going to start the links plugin. We >figured that would be a good one since it is relatively trivial. Don't be too sure of that ;-) There are sooo many things that the links plugin should be able to do. Off the top of my head: - sub categories - notify submitter when link has been accepted / rejected - disable (hide) links, e.g. to review them or wait for the site to come back up - "report link to admin" option - use / don't use click counter (portal.php) - a global option should do - rating (- proper ownership, although that is a 1.3 problem) Also check out the existing feature requests for 1.3. bye, Dirk -- http://www.haun-online.de/ http://mypod.de/ From tony at tonybibbs.com Mon Jan 24 14:20:35 2005 From: tony at tonybibbs.com (Tony Bibbs) Date: Mon, 24 Jan 2005 13:20:35 -0600 Subject: [geeklog-devel] GL2 Update In-Reply-To: <20050124185006.27948@smtp.haun-online.de> References: <41F50A6B.4030907@tonybibbs.com> <20050124185006.27948@smtp.haun-online.de> Message-ID: <41F54A83.2030409@tonybibbs.com> Dirk Haun wrote: >Don't be too sure of that ;-) > Well, when compared to, say, the article plugin ;-) >There are sooo many things that the links >plugin should be able to do. Off the top of my head: > >- sub categories > > Check, handled by item generalization >- notify submitter when link has been accepted / rejected > > This should actually be a kernel level thing (i.e. have centralized code that handle notifications when items are approved, disapproved >- disable (hide) links, e.g. to review them or wait for the site to come >back up > > Makes sense. >- "report link to admin" option > > This for broken links, I assume? >- use / don't use click counter (portal.php) - a global option should do > > Yeah, good idea. >- rating > > This will either be done by the kernel or a plugin. I think we left it at a plugin would handle raitings but I can't remember (vinny)? >(- proper ownership, although that is a 1.3 problem) > > Check, handled by item generalization >Also check out the existing feature requests for 1.3. > > Will do. --Tony From dirk at haun-online.de Mon Jan 24 14:25:18 2005 From: dirk at haun-online.de (Dirk Haun) Date: Mon, 24 Jan 2005 20:25:18 +0100 Subject: [geeklog-devel] GL2 Update In-Reply-To: <41F54A83.2030409@tonybibbs.com> References: <41F54A83.2030409@tonybibbs.com> Message-ID: <20050124192519.18763@smtp.haun-online.de> Tony Bibbs wrote: >>- "report link to admin" option >> >This for broken links, I assume? Yeah, or "has turned into a p0rn site" ... bye, Dirk -- http://www.haun-online.de/ http://mypod.de/ From vidomski at lightbender.ca Mon Jan 24 14:40:42 2005 From: vidomski at lightbender.ca (Kevin Vidomski) Date: Mon, 24 Jan 2005 13:40:42 -0600 Subject: [geeklog-devel] GL2 Update In-Reply-To: <20050124185006.27948@smtp.haun-online.de> References: <41F50A6B.4030907@tonybibbs.com> <20050124185006.27948@smtp.haun-online.de> Message-ID: <200501241340.43010.vidomski@lightbender.ca> On January 24, 2005 12:50 pm, Dirk Haun wrote: > Don't be too sure of that ;-) There are sooo many things that the links > plugin should be able to do. Off the top of my head: > > - sub categories > - notify submitter when link has been accepted / rejected > - disable (hide) links, e.g. to review them or wait for the site to come > back up > - "report link to admin" option > - use / don't use click counter (portal.php) - a global option should do > - rating > (- proper ownership, although that is a 1.3 problem) > > Also check out the existing feature requests for 1.3. I'll keep that stuff in mind while working on it. > > bye, Dirk From vfuria at gmail.com Mon Jan 24 23:13:04 2005 From: vfuria at gmail.com (Vincent Furia) Date: Mon, 24 Jan 2005 23:13:04 -0500 Subject: [geeklog-devel] article.php plugin comment code In-Reply-To: <20050124184723.23050@smtp.haun-online.de> References: <8319e2d605012407467518bcf@mail.gmail.com> <20050124184723.23050@smtp.haun-online.de> Message-ID: <8319e2d605012420137e60f209@mail.gmail.com> Found out while all that junk comment code was at the begging of article.php. It was because of how the comment bar works. I refactored the comment bar and removed all that garbage from article.php. Hopefully I didn't break anything. :) The comment engine is going to need lots of testing again before the next release. I've now thoroughly broken...errr...fixed the comment API for plugins, plugins that use it are going to have to be reworked. I'll fix the documentation for that before the next release. -Vinny On Mon, 24 Jan 2005 19:47:23 +0100, Dirk Haun wrote: > Vinny, > > >Anyone know why this: > [...] > >is in article.php? Is it used? > > Heh, I've been scratching my head over this one just the other day when I > was implementing the trackback comments. > > I have no idea why it is there. Maybe at one point, there was a redirect > from the comments page through article.php? I don't think it's used any more. > > Same goes for the lines following the code you quoted which count the > number of poll questions, for whatever reason ... > > Feel free to throw these lines out. > > bye, Dirk > > -- > http://www.haun-online.de/ > http://mypod.de/ > > _______________________________________________ > geeklog-devel mailing list > geeklog-devel at lists.geeklog.net > http://lists.geeklog.net/listinfo/geeklog-devel > From dirk at haun-online.de Tue Jan 25 15:11:52 2005 From: dirk at haun-online.de (Dirk Haun) Date: Tue, 25 Jan 2005 21:11:52 +0100 Subject: [geeklog-devel] GL2 link? Message-ID: <20050125201153.17691@smtp.haun-online.de> What's a good link to point people to information about GL2? I've restructured the Resources block on geeklog.net a bit and noticed that the "Geeklog 2" link there points to the project page, which doesn't have a lot to say about GL2. Maybe someone wants to write a static page that can serve as a portal page to the various GL2 resources? Speaking of which: At one point, we had a GL2 vision document (linked to from ) but it's long gone. Search engines and human readers are still looking for it, though, so I've configured the server to send a "410 Gone". Does someone still have that document? bye, Dirk -- http://www.haun-online.de/ http://www.macosx-faq.de/ From robg at macosxhints.com Wed Jan 26 10:44:50 2005 From: robg at macosxhints.com (Rob Griffiths) Date: Wed, 26 Jan 2005 07:44:50 -0800 Subject: [geeklog-devel] Allowable HTML and 'style' Message-ID: <376413180ac40990e686b861607c9cb4@macosxhints.com> On my current (GL 1.3.7+) site, I use this
command to make a nice outlined box:
This works great, and I want to do the same in 1.3.9 (or .10 or .11), when I finally upgrade. My dev server is running 1.3.9, so I tried adding the following to config.php, in the Admin HTML section: 'div' => array('class' => 1, 'id' => 1, 'style' => 1), This sorta works, except the above
is munched from what I enter into this:
Why is it erasing 'border:', but leaving everything else? thanks; -rob. From dirk at haun-online.de Wed Jan 26 13:58:26 2005 From: dirk at haun-online.de (Dirk Haun) Date: Wed, 26 Jan 2005 19:58:26 +0100 Subject: [geeklog-devel] Allowable HTML and 'style' In-Reply-To: <376413180ac40990e686b861607c9cb4@macosxhints.com> References: <376413180ac40990e686b861607c9cb4@macosxhints.com> Message-ID: <20050126185826.26227@smtp.haun-online.de> Rob, >Why is it erasing 'border:', but leaving everything else? That's a known bug /misbehaving feature in the kses filter: It thinks it's a protocol and since it's not one of those that are allowed, it removes it. You can, apparently, play tricks with javascript: in CSS and it's trying to protect you from that ... Workaround: Put your definitions in a class and use that. bye, Dirk -- http://www.haun-online.de/ http://www.tinyweb.de/ From dirk at haun-online.de Wed Jan 26 14:23:02 2005 From: dirk at haun-online.de (Dirk Haun) Date: Wed, 26 Jan 2005 20:23:02 +0100 Subject: [geeklog-devel] SpamX documentation Message-ID: <20050126192303.14076@smtp.haun-online.de> I did some house cleaning on the SpamX documentation. There was a second spamx.html in the plugin's directory, in addition to the one in docs. I somehow synced the two and then only kept the one in docs. I've also updated the Developer.txt file in the plugin's directory. Tom, could you have a look at those two files (in CVS), please, to see if they're up to date now? And, to answer that question from lib-comment.php: // FIXME: is 'plugin=spamx' needed here? echo COM_refresh($_CONF['site_url'] . '/index.php? msg='.$result.'&plugin=spamx'); Yes, Vinny, that parameter is needed ;-) That's something Blaine introduced in 1.3.10 (I think) so that plugins can display their own messages. Btw, I've also added Tom's two IP-based filtering modules to CVS. bye, Dirk -- http://www.haun-online.de/ http://www.handful-of-sparks.de/ From vfuria at gmail.com Wed Jan 26 14:37:15 2005 From: vfuria at gmail.com (Vincent Furia) Date: Wed, 26 Jan 2005 14:37:15 -0500 Subject: [geeklog-devel] SpamX documentation In-Reply-To: <20050126192303.14076@smtp.haun-online.de> References: <20050126192303.14076@smtp.haun-online.de> Message-ID: <8319e2d605012611377dfc39f4@mail.gmail.com> On Wed, 26 Jan 2005 20:23:02 +0100, Dirk Haun wrote: > > And, to answer that question from lib-comment.php: > > // FIXME: is 'plugin=spamx' needed here? > echo COM_refresh($_CONF['site_url'] . '/index.php? > msg='.$result.'&plugin=spamx'); > > Yes, Vinny, that parameter is needed ;-) That's something Blaine > introduced in 1.3.10 (I think) so that plugins can display their own messages. But what happens if another plugin uses the PLG_checkforSpam API to remove a post? With spamx hardcoded in the refresh link, the error message may be problematic... Perhaps having the plugin API return a HTML string (i.e. a redirect) instead of having Geeklog decide where to refresh to would be a better solution? Actually there is another problem with the entire block of code: // Let plugins have a chance to check for SPAM $result = PLG_checkforSpam($comment, $_CONF['spamx']); // <-- SPAMX // Now check the result and redirect to index.php if spam action was taken if ($result > 0) { // notice no return value here to prevent spam based denail of service attack // FIXME: is 'plugin=spamx' needed here? echo COM_refresh($_CONF['site_url'] . '/index.php?msg='.$result.'&plugin=spamx'); // <-- SPAMX exit; } Notice the two references to spamx (the refresh and $_CONF['spamx']), another plugin would have a lot of trouble using this. I think we should generalize this so other plugin could (conceivably) use it. -Vinny From dirk at haun-online.de Wed Jan 26 14:55:48 2005 From: dirk at haun-online.de (Dirk Haun) Date: Wed, 26 Jan 2005 20:55:48 +0100 Subject: [geeklog-devel] SpamX documentation In-Reply-To: <8319e2d605012611377dfc39f4@mail.gmail.com> References: <8319e2d605012611377dfc39f4@mail.gmail.com> Message-ID: <20050126195548.24738@smtp.haun-online.de> Vinny, >Notice the two references to spamx (the refresh and $_CONF['spamx']), >another plugin would have a lot of trouble using this. You mean another plugin that would like to filter spam? >I think we >should generalize this so other plugin could (conceivably) use it. The problem here is that you may have one plugin calling another. I know Blaine and Tom struggled with this for a while and this is what they came up with. If you have a better solution, let's hear it ... bye, Dirk -- http://www.haun-online.de/ http://geeklog.info/ From tomw at pigstye.net Wed Jan 26 15:25:23 2005 From: tomw at pigstye.net (Tom Willett) Date: Wed, 26 Jan 2005 15:25:23 -0500 Subject: [geeklog-devel] SpamX documentation In-Reply-To: <20050126192303.14076@smtp.haun-online.de> References: <20050126192303.14076@smtp.haun-online.de> Message-ID: <41F7FCB3.6070802@pigstye.net> On 1/26/2005 2:23 PM, Dirk Haun wrote: >I did some house cleaning on the SpamX documentation. There was a second >spamx.html in the plugin's directory, in addition to the one in docs. I >somehow synced the two and then only kept the one in docs. I've also >updated the Developer.txt file in the plugin's directory. > >Tom, could you have a look at those two files (in CVS), please, to see if >they're up to date now? > >And, to answer that question from lib-comment.php: > > // FIXME: is 'plugin=spamx' needed here? > echo COM_refresh($_CONF['site_url'] . '/index.php? >msg='.$result.'&plugin=spamx'); > >Yes, Vinny, that parameter is needed ;-) That's something Blaine >introduced in 1.3.10 (I think) so that plugins can display their own messages. > >Btw, I've also added Tom's two IP-based filtering modules to CVS. > >bye, Dirk > > > > You caught me at a good time. Here is an updated spamx.html. -- Tom Willett tomw at pigstye.net -------------- next part -------------- An HTML attachment was scrubbed... URL: From dirk at haun-online.de Wed Jan 26 16:15:56 2005 From: dirk at haun-online.de (Dirk Haun) Date: Wed, 26 Jan 2005 22:15:56 +0100 Subject: [geeklog-devel] SpamX documentation In-Reply-To: <41F7FCB3.6070802@pigstye.net> References: <41F7FCB3.6070802@pigstye.net> Message-ID: <20050126211556.5583@smtp.haun-online.de> Tom Willett wrote: >Here is an updated spamx.html. ... and it's in CVS now. Thanks, Tom :-) bye, Dirk -- http://www.haun-online.de/ http://www.haun.info/ From tony at tonybibbs.com Wed Jan 26 22:24:59 2005 From: tony at tonybibbs.com (Tony Bibbs) Date: Wed, 26 Jan 2005 21:24:59 -0600 Subject: [geeklog-devel] HTTP_Session2 Message-ID: <41F85F0B.8070508@tonybibbs.com> Thanks to help from Justin, I have some alpha code done of HTTP_Session2. Right now it only supports Creole and, to be nice, I have to get the other containers working (PEAR::DB, PEAR::MDB, etc). Anyway, as soon as that is done, I'll be making code changes to Geeklog-2 to start using it. I wouldn't suppose anybody would have the hardware and ability to run load balance Geeklog-2 on two or more web servers, would they? --Tony From tony at tonybibbs.com Thu Jan 27 11:04:38 2005 From: tony at tonybibbs.com (Tony Bibbs) Date: Thu, 27 Jan 2005 10:04:38 -0600 Subject: [geeklog-devel] KSES and PHP5 Message-ID: <41F91116.50403@tonybibbs.com> This is just an FYI. I'll be ripping out the current class and replacing it with this. The current one is CVS was my attempt to port it but I'm sure they are doing a better job of maintaining and testing it so no need in assuming that responsibilty. --Tony -------- Original Message -------- Subject: {Filename?} Re: Kses for PHP5? Date: Thu, 27 Jan 2005 10:04:16 -0600 (CST) From: Chaos.org Webmaster Reply-To: webfella at chaos.org To: Tony Bibbs Warning: This message has had one or more attachments removed Warning: (php5.class.kses.php). Warning: Please read the "yoursite-Attachment-Warning.txt" attachment(s) for more information. | Sorry for the delay. Work keeps getting in myway ;-) No problem. BTDT. | I'll be giving your PHP5 version a whirl here pretty quick. | I'll fire any bugs/feedback, etc to you soon. Ulf and I are still working on a few things in the process of backcoding some of the E_STRICT changes I made, along with me waiting for his 0.3 improvements/modifications. So there's no official package to download. However, I'm sending the PHP5 class version as an attachment. Nothing's been broken in terms of funtionality, but a couple of methods have been deprecated. Also, the name of the class has changed from kses to kses5 since I'll be maintaining the PHP4 version (kses4) as well for the forseeable future. If you're familiar with PhpDocumentor (http://www.phpdoc.org/), you can create the docs, and see for yourself, or you can read the comments in the source code. Hopefully, the next release will have a stronger set of documentation. Any feedback appreciated, Richard -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: yoursite-Attachment-Warning.txt URL: From vfuria at gmail.com Thu Jan 27 11:18:31 2005 From: vfuria at gmail.com (Vincent Furia) Date: Thu, 27 Jan 2005 11:18:31 -0500 Subject: [geeklog-devel] PLG_commentPreSave Message-ID: <8319e2d605012708186e8a3a86@mail.gmail.com> Trying to understand the entire comment system a bit better as I refactor all this code... What is the difference between PLG_commentPreSave and PLG_checkForSpam? Are both really needed? Is PLG_commentPreSave even used (or planned to be used) in any plugins. Can people see a need for it not filled by PLG_checkForSpam? Thanks, Vinny P.S. I'm almost done, just need to take care of this issue and then work on plugin documentation. From tony at tonybibbs.com Thu Jan 27 11:22:50 2005 From: tony at tonybibbs.com (Tony Bibbs) Date: Thu, 27 Jan 2005 10:22:50 -0600 Subject: [geeklog-devel] PLG_commentPreSave In-Reply-To: <8319e2d605012708186e8a3a86@mail.gmail.com> References: <8319e2d605012708186e8a3a86@mail.gmail.com> Message-ID: <41F9155A.8030007@tonybibbs.com> Only point I have is on semantics. I know it's only wording so take this feedback for what it is worth. Seems PLG_commentPreSave make more sense in how it might be used in a broader sense. PLG_checkForSpam, IMHO, is too specific. I can see how people might dream up a need to do some processing before a comment is saved that may be completely unrelated to spam. --Tony Vincent Furia wrote: >Trying to understand the entire comment system a bit better as I >refactor all this code... > >What is the difference between PLG_commentPreSave and >PLG_checkForSpam? Are both really needed? Is PLG_commentPreSave even >used (or planned to be used) in any plugins. Can people see a need >for it not filled by PLG_checkForSpam? > >Thanks, >Vinny > >P.S. I'm almost done, just need to take care of this issue and then >work on plugin documentation. >_______________________________________________ >geeklog-devel mailing list >geeklog-devel at lists.geeklog.net >http://lists.geeklog.net/listinfo/geeklog-devel > > From geeklog at langfamily.ca Thu Jan 27 12:00:27 2005 From: geeklog at langfamily.ca (Blaine Lang) Date: Thu, 27 Jan 2005 12:00:27 -0500 Subject: [geeklog-devel] PLG_commentPreSave References: <8319e2d605012708186e8a3a86@mail.gmail.com> <41F9155A.8030007@tonybibbs.com> Message-ID: <023501c50491$b3a79300$650a10ac@XPBL2> Vincent Furia wrote: >What is the difference between PLG_commentPreSave and >PLG_checkForSpam? Are both really needed? Dirk, Tom and I talked about this when implementing the new SPAMX API's and decided that it was best to still have a Non-Spamx API to allow other plugins to add any other comment related filtering or handling that may be required. Blaine ----- Original Message ----- From: "Tony Bibbs" To: Sent: Thursday, January 27, 2005 11:22 AM Subject: Re: [geeklog-devel] PLG_commentPreSave Only point I have is on semantics. I know it's only wording so take this feedback for what it is worth. Seems PLG_commentPreSave make more sense in how it might be used in a broader sense. PLG_checkForSpam, IMHO, is too specific. I can see how people might dream up a need to do some processing before a comment is saved that may be completely unrelated to spam. --Tony Vincent Furia wrote: >Trying to understand the entire comment system a bit better as I >refactor all this code... > >What is the difference between PLG_commentPreSave and >PLG_checkForSpam? Are both really needed? Is PLG_commentPreSave even >used (or planned to be used) in any plugins. Can people see a need >for it not filled by PLG_checkForSpam? > >Thanks, >Vinny > >P.S. I'm almost done, just need to take care of this issue and then >work on plugin documentation. >_______________________________________________ >geeklog-devel mailing list >geeklog-devel at lists.geeklog.net >http://lists.geeklog.net/listinfo/geeklog-devel > > _______________________________________________ geeklog-devel mailing list geeklog-devel at lists.geeklog.net http://lists.geeklog.net/listinfo/geeklog-devel From geeklog at langfamily.ca Thu Jan 27 12:03:39 2005 From: geeklog at langfamily.ca (Blaine Lang) Date: Thu, 27 Jan 2005 12:03:39 -0500 Subject: [geeklog-devel] HTTP_Session2 References: <41F85F0B.8070508@tonybibbs.com> Message-ID: <024101c50492$25f72f60$650a10ac@XPBL2> Tony, We had added SESSION support for GL 1.3.10 and then had to pull it out due to issues that were appearing from testers. I wonder if your new version once you have support for non-creole containers will allow us to revisit the 1.3.X use of SESSIONS again. Blaine ----- Original Message ----- From: "Tony Bibbs" To: Sent: Wednesday, January 26, 2005 10:24 PM Subject: [geeklog-devel] HTTP_Session2 Thanks to help from Justin, I have some alpha code done of HTTP_Session2. Right now it only supports Creole and, to be nice, I have to get the other containers working (PEAR::DB, PEAR::MDB, etc). Anyway, as soon as that is done, I'll be making code changes to Geeklog-2 to start using it. I wouldn't suppose anybody would have the hardware and ability to run load balance Geeklog-2 on two or more web servers, would they? --Tony _______________________________________________ geeklog-devel mailing list geeklog-devel at lists.geeklog.net http://lists.geeklog.net/listinfo/geeklog-devel From tony at tonybibbs.com Thu Jan 27 12:07:25 2005 From: tony at tonybibbs.com (Tony Bibbs) Date: Thu, 27 Jan 2005 11:07:25 -0600 Subject: [geeklog-devel] HTTP_Session2 In-Reply-To: <024101c50492$25f72f60$650a10ac@XPBL2> References: <41F85F0B.8070508@tonybibbs.com> <024101c50492$25f72f60$650a10ac@XPBL2> Message-ID: <41F91FCD.7020704@tonybibbs.com> Being I'm the 'main' maintainer of HTTP_Session2 we have the ability to tweak, fix, improve anything. Do you remember the specific issues? This would be the time to revisit that. --Tony Blaine Lang wrote: >Tony, > >We had added SESSION support for GL 1.3.10 and then had to pull it out due >to issues that were appearing from testers. >I wonder if your new version once you have support for non-creole containers >will allow us to revisit the 1.3.X use of SESSIONS again. > >Blaine >----- Original Message ----- >From: "Tony Bibbs" >To: >Sent: Wednesday, January 26, 2005 10:24 PM >Subject: [geeklog-devel] HTTP_Session2 > > >Thanks to help from Justin, I have some alpha code done of >HTTP_Session2. Right now it only supports Creole and, to be nice, I >have to get the other containers working (PEAR::DB, PEAR::MDB, etc). > >Anyway, as soon as that is done, I'll be making code changes to >Geeklog-2 to start using it. > >I wouldn't suppose anybody would have the hardware and ability to run >load balance Geeklog-2 on two or more web servers, would they? > >--Tony >_______________________________________________ >geeklog-devel mailing list >geeklog-devel at lists.geeklog.net >http://lists.geeklog.net/listinfo/geeklog-devel > >_______________________________________________ >geeklog-devel mailing list >geeklog-devel at lists.geeklog.net >http://lists.geeklog.net/listinfo/geeklog-devel > > From vfuria at gmail.com Thu Jan 27 12:26:52 2005 From: vfuria at gmail.com (Vincent Furia) Date: Thu, 27 Jan 2005 12:26:52 -0500 Subject: [geeklog-devel] PLG_commentPreSave In-Reply-To: <023501c50491$b3a79300$650a10ac@XPBL2> References: <8319e2d605012708186e8a3a86@mail.gmail.com> <41F9155A.8030007@tonybibbs.com> <023501c50491$b3a79300$650a10ac@XPBL2> Message-ID: <8319e2d6050127092631f88608@mail.gmail.com> On Thu, 27 Jan 2005 12:00:27 -0500, Blaine Lang wrote: > > Dirk, Tom and I talked about this when implementing the new SPAMX API's and > decided that it was best to still have a Non-Spamx API to allow other > plugins to add any other comment related filtering or handling that may be > required. > I'm still confused as to why different APIs are needed since they appear to do the same thing. They are even called one after the other. I think one plugin call would be enough, something like: PLG_commentPreSave(title, comment, ...) and have it return HTML to output if there is an error (this can include a COM_refresh) otherwise just return 0. If I can work it into the plugin API to pass the comment and title by reference, plugins could modify those and still return a "success" status. Thoughts? -Vinny From tony at tonybibbs.com Thu Jan 27 13:22:48 2005 From: tony at tonybibbs.com (Tony Bibbs) Date: Thu, 27 Jan 2005 12:22:48 -0600 Subject: [geeklog-devel] PLG_commentPreSave In-Reply-To: <8319e2d6050127092631f88608@mail.gmail.com> References: <8319e2d605012708186e8a3a86@mail.gmail.com> <41F9155A.8030007@tonybibbs.com> <023501c50491$b3a79300$650a10ac@XPBL2> <8319e2d6050127092631f88608@mail.gmail.com> Message-ID: <41F93178.6000206@tonybibbs.com> Right, Vinny's question is why couldn't the spamx plugin just have used PLG_commentPreSave then? --Tony Vincent Furia wrote: >On Thu, 27 Jan 2005 12:00:27 -0500, Blaine Lang wrote: > > >>Dirk, Tom and I talked about this when implementing the new SPAMX API's and >>decided that it was best to still have a Non-Spamx API to allow other >>plugins to add any other comment related filtering or handling that may be >>required. >> >> >> >I'm still confused as to why different APIs are needed since they >appear to do the same thing. They are even called one after the >other. > >I think one plugin call would be enough, something like: > >PLG_commentPreSave(title, comment, ...) and have it return HTML to >output if there is an error (this can include a COM_refresh) otherwise >just return 0. If I can work it into the plugin API to pass the >comment and title by reference, plugins could modify those and still >return a "success" status. > >Thoughts? > >-Vinny >_______________________________________________ >geeklog-devel mailing list >geeklog-devel at lists.geeklog.net >http://lists.geeklog.net/listinfo/geeklog-devel > > From geeklog at langfamily.ca Thu Jan 27 14:07:06 2005 From: geeklog at langfamily.ca (Blaine Lang) Date: Thu, 27 Jan 2005 14:07:06 -0500 Subject: [geeklog-devel] PLG_commentPreSave References: <8319e2d605012708186e8a3a86@mail.gmail.com> <41F9155A.8030007@tonybibbs.com> <023501c50491$b3a79300$650a10ac@XPBL2> <8319e2d6050127092631f88608@mail.gmail.com> <41F93178.6000206@tonybibbs.com> Message-ID: <08d301c504a3$64b1ee50$650a10ac@XPBL2> Uh ok - went back through my emails and it was last Sept/Oct that I worked on this. Here was the email I sent to Dirk that raised this very question when I was adding the spamx API's. Have a read and see if this made sense. ----- I'm wondering if there is a reason to preserve the new API that Tony added to support the SPAMX feature in comments. Tony wrote a API that is very generic and can be used for other purposes. It's passed a lot of PARMS which would be useful by a Plugin if it needed to do something with that coment. function PLG_commentPreSave($uid, $title, $comment, $sid, $pid, $type, $postmode) The SPAMX API now only needs 2 parms ($text and $action) Tom's first idea was to change the PLG_commentPreSave API and I'm wondering if we should keep it. This API is only called from comment.php - since that is the only un-moderated way to add content to stories. But if we really want a generic hook then it should be for new stories as well as comments I think. I don't quite have the application in mind of how this would be used other then for parsing bbcode tags or wiki language. In both those cases, I think only the textual content would need to be passed as well. So I'm not sure what to do with the PLG_commentPreSave API. I'm thinking of adding a new PLG_checkforSpam($content,$action) API and that would be called from comment.php. The PLG_checkforSpam is a wrapper to call the plugin_checkforSpam_spamx() The other idea is to add the call to plugin_checkforSpam_spamx in the PLG_commentPreSave() so that it will be called plus what ever plugin related functions that may be available. Sorry to make this sound more complex - it's the current API and what to do with it that make me stop and ask. Blaine ------ ----- Original Message ----- From: "Tony Bibbs" To: Sent: Thursday, January 27, 2005 1:22 PM Subject: Re: [geeklog-devel] PLG_commentPreSave Right, Vinny's question is why couldn't the spamx plugin just have used PLG_commentPreSave then? --Tony Vincent Furia wrote: >On Thu, 27 Jan 2005 12:00:27 -0500, Blaine Lang >wrote: > > >>Dirk, Tom and I talked about this when implementing the new SPAMX API's >>and >>decided that it was best to still have a Non-Spamx API to allow other >>plugins to add any other comment related filtering or handling that may be >>required. >> >> >> >I'm still confused as to why different APIs are needed since they >appear to do the same thing. They are even called one after the >other. > >I think one plugin call would be enough, something like: > >PLG_commentPreSave(title, comment, ...) and have it return HTML to >output if there is an error (this can include a COM_refresh) otherwise >just return 0. If I can work it into the plugin API to pass the >comment and title by reference, plugins could modify those and still >return a "success" status. > >Thoughts? > >-Vinny >_______________________________________________ >geeklog-devel mailing list >geeklog-devel at lists.geeklog.net >http://lists.geeklog.net/listinfo/geeklog-devel > > _______________________________________________ geeklog-devel mailing list geeklog-devel at lists.geeklog.net http://lists.geeklog.net/listinfo/geeklog-devel From tony at tonybibbs.com Thu Jan 27 14:28:17 2005 From: tony at tonybibbs.com (Tony Bibbs) Date: Thu, 27 Jan 2005 13:28:17 -0600 Subject: [geeklog-devel] PLG_commentPreSave In-Reply-To: <08d301c504a3$64b1ee50$650a10ac@XPBL2> References: <8319e2d605012708186e8a3a86@mail.gmail.com> <41F9155A.8030007@tonybibbs.com> <023501c50491$b3a79300$650a10ac@XPBL2> <8319e2d6050127092631f88608@mail.gmail.com> <41F93178.6000206@tonybibbs.com> <08d301c504a3$64b1ee50$650a10ac@XPBL2> Message-ID: <41F940D1.1070101@tonybibbs.com> Hrm, k I see. So the question for me is do we really need the SPAMx function in the API at all. What's wrong with exposing the checkSpam in lib-common.php (or some other library)? Seems like this method (check for spam) isn't an API specific thing, it is a feature that we would like to expose to other plugins. Thus, I say it would be up to the plugin author to explicitly check for spam from within their own appropriate methods. Am I missing anything? --Tony Blaine Lang wrote: >Uh ok - went back through my emails and it was last Sept/Oct that I worked >on this. >Here was the email I sent to Dirk that raised this very question when I was >adding the spamx API's. > >Have a read and see if this made sense. > >----- >I'm wondering if there is a reason to preserve the new API that Tony added >to support the SPAMX feature in comments. Tony wrote a API that is very >generic and can be used for other purposes. It's passed a lot of PARMS which >would be useful by a Plugin if it needed to do something with that coment. > >function PLG_commentPreSave($uid, $title, $comment, $sid, $pid, $type, >$postmode) > >The SPAMX API now only needs 2 parms ($text and $action) > >Tom's first idea was to change the PLG_commentPreSave API and I'm wondering >if we should keep it. This API is only called from comment.php - since that >is the only un-moderated way to add content to stories. But if we really >want a generic hook then it should be for new stories as well as comments I >think. I don't quite have the application in mind of how this would be used >other then for parsing bbcode tags or wiki language. In both those cases, I >think only the textual content would need to be passed as well. > >So I'm not sure what to do with the PLG_commentPreSave API. > >I'm thinking of adding a new PLG_checkforSpam($content,$action) API and that >would be called from comment.php. The PLG_checkforSpam is a wrapper to call >the plugin_checkforSpam_spamx() > >The other idea is to add the call to plugin_checkforSpam_spamx in the >PLG_commentPreSave() so that it will be called plus what ever plugin related >functions that may be available. > >Sorry to make this sound more complex - it's the current API and what to do >with it that make me stop and ask. > >Blaine >------ > >----- Original Message ----- >From: "Tony Bibbs" >To: >Sent: Thursday, January 27, 2005 1:22 PM >Subject: Re: [geeklog-devel] PLG_commentPreSave > > >Right, Vinny's question is why couldn't the spamx plugin just have used >PLG_commentPreSave then? > >--Tony > >Vincent Furia wrote: > > > >>On Thu, 27 Jan 2005 12:00:27 -0500, Blaine Lang >>wrote: >> >> >> >> >>>Dirk, Tom and I talked about this when implementing the new SPAMX API's >>>and >>>decided that it was best to still have a Non-Spamx API to allow other >>>plugins to add any other comment related filtering or handling that may be >>>required. >>> >>> >>> >>> >>> >>I'm still confused as to why different APIs are needed since they >>appear to do the same thing. They are even called one after the >>other. >> >>I think one plugin call would be enough, something like: >> >>PLG_commentPreSave(title, comment, ...) and have it return HTML to >>output if there is an error (this can include a COM_refresh) otherwise >>just return 0. If I can work it into the plugin API to pass the >>comment and title by reference, plugins could modify those and still >>return a "success" status. >> >>Thoughts? >> >>-Vinny >>_______________________________________________ >>geeklog-devel mailing list >>geeklog-devel at lists.geeklog.net >>http://lists.geeklog.net/listinfo/geeklog-devel >> >> >> >> > >_______________________________________________ >geeklog-devel mailing list >geeklog-devel at lists.geeklog.net >http://lists.geeklog.net/listinfo/geeklog-devel > >_______________________________________________ >geeklog-devel mailing list >geeklog-devel at lists.geeklog.net >http://lists.geeklog.net/listinfo/geeklog-devel > > From tony at tonybibbs.com Thu Jan 27 14:31:56 2005 From: tony at tonybibbs.com (Tony Bibbs) Date: Thu, 27 Jan 2005 13:31:56 -0600 Subject: [geeklog-devel] PLG_commentPreSave In-Reply-To: <41F940D1.1070101@tonybibbs.com> References: <8319e2d605012708186e8a3a86@mail.gmail.com> <41F9155A.8030007@tonybibbs.com> <023501c50491$b3a79300$650a10ac@XPBL2> <8319e2d6050127092631f88608@mail.gmail.com> <41F93178.6000206@tonybibbs.com> <08d301c504a3$64b1ee50$650a10ac@XPBL2> <41F940D1.1070101@tonybibbs.com> Message-ID: <41F941AC.1020004@tonybibbs.com> This also brings up the issue of plugin dependencies. We have this in mind for GL2 on how to have some plugins either require or optionally use features from other plugins. That's essentially what we want. After I thought about the message below I sent I realized we can't assume the spamx plugin is installed (even if it is a plugin). Seems like an elegant fix might not be possible with the current paradigm. --Tony Tony Bibbs wrote: > Hrm, k I see. So the question for me is do we really need the SPAMx > function in the API at all. What's wrong with exposing the checkSpam > in lib-common.php (or some other library)? Seems like this method > (check for spam) isn't an API specific thing, it is a feature that we > would like to expose to other plugins. > > Thus, I say it would be up to the plugin author to explicitly check > for spam from within their own appropriate methods. Am I missing > anything? > > --Tony > > Blaine Lang wrote: > >> Uh ok - went back through my emails and it was last Sept/Oct that I >> worked on this. >> Here was the email I sent to Dirk that raised this very question when >> I was adding the spamx API's. >> >> Have a read and see if this made sense. >> >> ----- >> I'm wondering if there is a reason to preserve the new API that Tony >> added to support the SPAMX feature in comments. Tony wrote a API that >> is very generic and can be used for other purposes. It's passed a lot >> of PARMS which would be useful by a Plugin if it needed to do >> something with that coment. >> >> function PLG_commentPreSave($uid, $title, $comment, $sid, $pid, >> $type, $postmode) >> >> The SPAMX API now only needs 2 parms ($text and $action) >> >> Tom's first idea was to change the PLG_commentPreSave API and I'm >> wondering if we should keep it. This API is only called from >> comment.php - since that is the only un-moderated way to add content >> to stories. But if we really want a generic hook then it should be >> for new stories as well as comments I think. I don't quite have the >> application in mind of how this would be used other then for parsing >> bbcode tags or wiki language. In both those cases, I think only the >> textual content would need to be passed as well. >> >> So I'm not sure what to do with the PLG_commentPreSave API. >> >> I'm thinking of adding a new PLG_checkforSpam($content,$action) API >> and that would be called from comment.php. The PLG_checkforSpam is a >> wrapper to call the plugin_checkforSpam_spamx() >> >> The other idea is to add the call to plugin_checkforSpam_spamx in the >> PLG_commentPreSave() so that it will be called plus what ever plugin >> related functions that may be available. >> >> Sorry to make this sound more complex - it's the current API and what >> to do with it that make me stop and ask. >> >> Blaine >> ------ >> >> ----- Original Message ----- From: "Tony Bibbs" >> To: >> Sent: Thursday, January 27, 2005 1:22 PM >> Subject: Re: [geeklog-devel] PLG_commentPreSave >> >> >> Right, Vinny's question is why couldn't the spamx plugin just have used >> PLG_commentPreSave then? >> >> --Tony >> >> Vincent Furia wrote: >> >> >> >>> On Thu, 27 Jan 2005 12:00:27 -0500, Blaine Lang >>> wrote: >>> >>> >>> >>> >>>> Dirk, Tom and I talked about this when implementing the new SPAMX >>>> API's and >>>> decided that it was best to still have a Non-Spamx API to allow other >>>> plugins to add any other comment related filtering or handling that >>>> may be >>>> required. >>>> >>>> >>>> >>>> >>> >>> I'm still confused as to why different APIs are needed since they >>> appear to do the same thing. They are even called one after the >>> other. >>> >>> I think one plugin call would be enough, something like: >>> >>> PLG_commentPreSave(title, comment, ...) and have it return HTML to >>> output if there is an error (this can include a COM_refresh) otherwise >>> just return 0. If I can work it into the plugin API to pass the >>> comment and title by reference, plugins could modify those and still >>> return a "success" status. >>> >>> Thoughts? >>> >>> -Vinny >>> _______________________________________________ >>> geeklog-devel mailing list >>> geeklog-devel at lists.geeklog.net >>> http://lists.geeklog.net/listinfo/geeklog-devel >>> >>> >>> >> >> >> _______________________________________________ >> geeklog-devel mailing list >> geeklog-devel at lists.geeklog.net >> http://lists.geeklog.net/listinfo/geeklog-devel >> >> _______________________________________________ >> geeklog-devel mailing list >> geeklog-devel at lists.geeklog.net >> http://lists.geeklog.net/listinfo/geeklog-devel >> >> > > _______________________________________________ > geeklog-devel mailing list > geeklog-devel at lists.geeklog.net > http://lists.geeklog.net/listinfo/geeklog-devel From geeklog at langfamily.ca Thu Jan 27 14:49:10 2005 From: geeklog at langfamily.ca (Blaine Lang) Date: Thu, 27 Jan 2005 14:49:10 -0500 Subject: [geeklog-devel] PLG_commentPreSave References: <8319e2d605012708186e8a3a86@mail.gmail.com> <41F9155A.8030007@tonybibbs.com> <023501c50491$b3a79300$650a10ac@XPBL2> <8319e2d6050127092631f88608@mail.gmail.com> <41F93178.6000206@tonybibbs.com> <08d301c504a3$64b1ee50$650a10ac@XPBL2> <41F940D1.1070101@tonybibbs.com> Message-ID: <08f901c504a9$453f2f00$650a10ac@XPBL2> Well I think it is an API feature we want and thus why I created a wrapper for it. The API can and will also call any other plugins that have a spam related function - 'plugin_checkforSpam_' . $pi_name; If the spamx plugin is not installed then the wrapper returns the data unchanged and no issues. We felt this was the best way and left the options open later for other spam filtering plugins to be used. Blaine ----- Original Message ----- From: "Tony Bibbs" To: Sent: Thursday, January 27, 2005 2:28 PM Subject: Re: [geeklog-devel] PLG_commentPreSave Hrm, k I see. So the question for me is do we really need the SPAMx function in the API at all. What's wrong with exposing the checkSpam in lib-common.php (or some other library)? Seems like this method (check for spam) isn't an API specific thing, it is a feature that we would like to expose to other plugins. Thus, I say it would be up to the plugin author to explicitly check for spam from within their own appropriate methods. Am I missing anything? --Tony Blaine Lang wrote: >Uh ok - went back through my emails and it was last Sept/Oct that I worked >on this. >Here was the email I sent to Dirk that raised this very question when I was >adding the spamx API's. > >Have a read and see if this made sense. > >----- >I'm wondering if there is a reason to preserve the new API that Tony added >to support the SPAMX feature in comments. Tony wrote a API that is very >generic and can be used for other purposes. It's passed a lot of PARMS >which >would be useful by a Plugin if it needed to do something with that coment. > >function PLG_commentPreSave($uid, $title, $comment, $sid, $pid, $type, >$postmode) > >The SPAMX API now only needs 2 parms ($text and $action) > >Tom's first idea was to change the PLG_commentPreSave API and I'm wondering >if we should keep it. This API is only called from comment.php - since that >is the only un-moderated way to add content to stories. But if we really >want a generic hook then it should be for new stories as well as comments I >think. I don't quite have the application in mind of how this would be used >other then for parsing bbcode tags or wiki language. In both those cases, I >think only the textual content would need to be passed as well. > >So I'm not sure what to do with the PLG_commentPreSave API. > >I'm thinking of adding a new PLG_checkforSpam($content,$action) API and >that >would be called from comment.php. The PLG_checkforSpam is a wrapper to call >the plugin_checkforSpam_spamx() > >The other idea is to add the call to plugin_checkforSpam_spamx in the >PLG_commentPreSave() so that it will be called plus what ever plugin >related >functions that may be available. > >Sorry to make this sound more complex - it's the current API and what to do >with it that make me stop and ask. > >Blaine >------ > >----- Original Message ----- >From: "Tony Bibbs" >To: >Sent: Thursday, January 27, 2005 1:22 PM >Subject: Re: [geeklog-devel] PLG_commentPreSave > > >Right, Vinny's question is why couldn't the spamx plugin just have used >PLG_commentPreSave then? > >--Tony > >Vincent Furia wrote: > > > >>On Thu, 27 Jan 2005 12:00:27 -0500, Blaine Lang >>wrote: >> >> >> >> >>>Dirk, Tom and I talked about this when implementing the new SPAMX API's >>>and >>>decided that it was best to still have a Non-Spamx API to allow other >>>plugins to add any other comment related filtering or handling that may >>>be >>>required. >>> >>> >>> >>> >>> >>I'm still confused as to why different APIs are needed since they >>appear to do the same thing. They are even called one after the >>other. >> >>I think one plugin call would be enough, something like: >> >>PLG_commentPreSave(title, comment, ...) and have it return HTML to >>output if there is an error (this can include a COM_refresh) otherwise >>just return 0. If I can work it into the plugin API to pass the >>comment and title by reference, plugins could modify those and still >>return a "success" status. >> >>Thoughts? >> >>-Vinny >>_______________________________________________ >>geeklog-devel mailing list >>geeklog-devel at lists.geeklog.net >>http://lists.geeklog.net/listinfo/geeklog-devel >> >> >> >> > >_______________________________________________ >geeklog-devel mailing list >geeklog-devel at lists.geeklog.net >http://lists.geeklog.net/listinfo/geeklog-devel > >_______________________________________________ >geeklog-devel mailing list >geeklog-devel at lists.geeklog.net >http://lists.geeklog.net/listinfo/geeklog-devel > > _______________________________________________ geeklog-devel mailing list geeklog-devel at lists.geeklog.net http://lists.geeklog.net/listinfo/geeklog-devel From tony at tonybibbs.com Thu Jan 27 15:05:47 2005 From: tony at tonybibbs.com (Tony Bibbs) Date: Thu, 27 Jan 2005 14:05:47 -0600 Subject: [geeklog-devel] PLG_commentPreSave In-Reply-To: <08f901c504a9$453f2f00$650a10ac@XPBL2> References: <8319e2d605012708186e8a3a86@mail.gmail.com> <41F9155A.8030007@tonybibbs.com> <023501c50491$b3a79300$650a10ac@XPBL2> <8319e2d6050127092631f88608@mail.gmail.com> <41F93178.6000206@tonybibbs.com> <08d301c504a3$64b1ee50$650a10ac@XPBL2> <41F940D1.1070101@tonybibbs.com> <08f901c504a9$453f2f00$650a10ac@XPBL2> Message-ID: <41F9499B.2000707@tonybibbs.com> That's the argument I guess. I don't want to minimize the importance of spam filtering but doing it this way essentially implies the use of spamx. The plugins don't do the check for spam themselves the delegate that and since it isn't the plugin doing the work I don't quite think that would fit in an API. In otherwords, if the plugin doesn't implement the spam check, it's really not an interface. OO purism aside, I think what we have works and that it'd probably not make much sense to go in and change things at this point in time. --Tony Blaine Lang wrote: >Well I think it is an API feature we want and thus why I created a wrapper >for it. >The API can and will also call any other plugins that have a spam related >function - 'plugin_checkforSpam_' . $pi_name; > >If the spamx plugin is not installed then the wrapper returns the data >unchanged and no issues. > >We felt this was the best way and left the options open later for other spam >filtering plugins to be used. > >Blaine >----- Original Message ----- >From: "Tony Bibbs" >To: >Sent: Thursday, January 27, 2005 2:28 PM >Subject: Re: [geeklog-devel] PLG_commentPreSave > > >Hrm, k I see. So the question for me is do we really need the SPAMx >function in the API at all. What's wrong with exposing the checkSpam in >lib-common.php (or some other library)? Seems like this method (check >for spam) isn't an API specific thing, it is a feature that we would >like to expose to other plugins. > >Thus, I say it would be up to the plugin author to explicitly check for >spam from within their own appropriate methods. Am I missing anything? > >--Tony > >Blaine Lang wrote: > > > >>Uh ok - went back through my emails and it was last Sept/Oct that I worked >>on this. >>Here was the email I sent to Dirk that raised this very question when I was >>adding the spamx API's. >> >>Have a read and see if this made sense. >> >>----- >>I'm wondering if there is a reason to preserve the new API that Tony added >>to support the SPAMX feature in comments. Tony wrote a API that is very >>generic and can be used for other purposes. It's passed a lot of PARMS >>which >>would be useful by a Plugin if it needed to do something with that coment. >> >>function PLG_commentPreSave($uid, $title, $comment, $sid, $pid, $type, >>$postmode) >> >>The SPAMX API now only needs 2 parms ($text and $action) >> >>Tom's first idea was to change the PLG_commentPreSave API and I'm wondering >>if we should keep it. This API is only called from comment.php - since that >>is the only un-moderated way to add content to stories. But if we really >>want a generic hook then it should be for new stories as well as comments I >>think. I don't quite have the application in mind of how this would be used >>other then for parsing bbcode tags or wiki language. In both those cases, I >>think only the textual content would need to be passed as well. >> >>So I'm not sure what to do with the PLG_commentPreSave API. >> >>I'm thinking of adding a new PLG_checkforSpam($content,$action) API and >>that >>would be called from comment.php. The PLG_checkforSpam is a wrapper to call >>the plugin_checkforSpam_spamx() >> >>The other idea is to add the call to plugin_checkforSpam_spamx in the >>PLG_commentPreSave() so that it will be called plus what ever plugin >>related >>functions that may be available. >> >>Sorry to make this sound more complex - it's the current API and what to do >>with it that make me stop and ask. >> >>Blaine >>------ >> >>----- Original Message ----- >>From: "Tony Bibbs" >>To: >>Sent: Thursday, January 27, 2005 1:22 PM >>Subject: Re: [geeklog-devel] PLG_commentPreSave >> >> >>Right, Vinny's question is why couldn't the spamx plugin just have used >>PLG_commentPreSave then? >> >>--Tony >> >>Vincent Furia wrote: >> >> >> >> >> >>>On Thu, 27 Jan 2005 12:00:27 -0500, Blaine Lang >>>wrote: >>> >>> >>> >>> >>> >>> >>>>Dirk, Tom and I talked about this when implementing the new SPAMX API's >>>>and >>>>decided that it was best to still have a Non-Spamx API to allow other >>>>plugins to add any other comment related filtering or handling that may >>>>be >>>>required. >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>I'm still confused as to why different APIs are needed since they >>>appear to do the same thing. They are even called one after the >>>other. >>> >>>I think one plugin call would be enough, something like: >>> >>>PLG_commentPreSave(title, comment, ...) and have it return HTML to >>>output if there is an error (this can include a COM_refresh) otherwise >>>just return 0. If I can work it into the plugin API to pass the >>>comment and title by reference, plugins could modify those and still >>>return a "success" status. >>> >>>Thoughts? >>> >>>-Vinny >>>_______________________________________________ >>>geeklog-devel mailing list >>>geeklog-devel at lists.geeklog.net >>>http://lists.geeklog.net/listinfo/geeklog-devel >>> >>> >>> >>> >>> >>> >>_______________________________________________ >>geeklog-devel mailing list >>geeklog-devel at lists.geeklog.net >>http://lists.geeklog.net/listinfo/geeklog-devel >> >>_______________________________________________ >>geeklog-devel mailing list >>geeklog-devel at lists.geeklog.net >>http://lists.geeklog.net/listinfo/geeklog-devel >> >> >> >> > >_______________________________________________ >geeklog-devel mailing list >geeklog-devel at lists.geeklog.net >http://lists.geeklog.net/listinfo/geeklog-devel > >_______________________________________________ >geeklog-devel mailing list >geeklog-devel at lists.geeklog.net >http://lists.geeklog.net/listinfo/geeklog-devel > > From tony at tonybibbs.com Thu Jan 27 15:30:26 2005 From: tony at tonybibbs.com (Tony Bibbs) Date: Thu, 27 Jan 2005 14:30:26 -0600 Subject: [geeklog-devel] kses PHP5 (actual attachment) Message-ID: <41F94F62.4060604@tonybibbs.com> Sorry, my last email didn't include the attachment properly -------- Original Message -------- Subject: Re: [Fwd: {Filename?} Re: Kses for PHP5?] Date: Thu, 27 Jan 2005 14:30:20 -0600 (CST) From: Chaos.org Webmaster Reply-To: webfella at chaos.org To: Tony Bibbs On Thu, 27 Jan 2005, Tony Bibbs wrote: | The updated php script got filtered out. Please try and resend or get | me a URL where I can pull it down. Oops. Let's try this again then. Richard -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: kses.php5 URL: From tony at tonybibbs.com Thu Jan 27 22:01:39 2005 From: tony at tonybibbs.com (Tony Bibbs) Date: Thu, 27 Jan 2005 21:01:39 -0600 Subject: [geeklog-devel] GL2 DataAccess Class In-Reply-To: <8319e2d605011710386432525e@mail.gmail.com> References: <8319e2d60501162044335efb64@mail.gmail.com> <41EBCC95.7080203@tonybibbs.com> <8319e2d605011706391e0c02d7@mail.gmail.com> <8319e2d6050117070717a15298@mail.gmail.com> <41EBF8C1.8070503@tonybibbs.com> <8319e2d605011710386432525e@mail.gmail.com> Message-ID: <41F9AB13.3030605@tonybibbs.com> Vinny, finally getting back to addressing some issues. You are right here. However, 95% of the inserts, updates and deletes should come through the use of the domain objects themselves, right? For the remaining 5%, I think they should just use raw SQL in the named query file. So to be clear you'd use the PropelDAO::save to do the inserts and updates and the PropelDAO::delete to delete an object. Correct me if I am missing something. --Tony Vincent Furia wrote: >I guess I should have been more specific... > >There is no way to use criteria to do UPDATEs or DELETEs (criteria >with INSERTs doesn't make much sense). > >It is not clear if what behavior specifying the SQL for UDPATEs, >DELETEs and INSERTs will be. From reading the code it looks like the >SQL will be executed, I'm just not sure if the program will stop with >an error afterwards or throw an exception or just return an empty >result set. > >I haven't tested the DAO code under these conditions, but it looks >like something that needs be corrected. > >-Vinny > > >On Mon, 17 Jan 2005 11:41:21 -0600, Tony Bibbs wrote: > > >>You sure? It's an easy fix to get around that...but seems the >>updates/deletes should work. >> >>--Tony >> >>Vincent Furia wrote: >> >> >> >>>Tony, >>> >>>Another issue with the DAO class is that it seems catered to providing >>>support only for SELECT's. It won't work for doing INSERT's, >>>UPDATE's, or DELETE's (etc...). >>> >>>-Vinny >>> >>> >>>On Mon, 17 Jan 2005 09:39:04 -0500, Vincent Furia wrote: >>> >>> >>> >>> >>>>Tony, >>>> >>>>Caching between page calls would be great. But even having a static >>>>variable or something similar to persist between calls to the "find" >>>>method would be a good start (and probably sufficient for most sites). >>>> >>>>-Vinny >>>> >>>> >>>>On Mon, 17 Jan 2005 08:32:53 -0600, Tony Bibbs wrote: >>>> >>>> >>>> >>>> >>>>>You mean cache it to memory or to a file. I'd love to cache it to >>>>>memory but, afaik, it would require php's shared memory which isn't >>>>>enabled by default. >>>>> >>>>>I s'pose if the xml parsing itself if that bad, would could cache a >>>>>php-friendly data structure to a file. >>>>> >>>>>I'm open to this. I just learned how to profile PHP applications this >>>>>past week so finding poor performing code shouldn't be a problem. >>>>> >>>>>--Tony >>>>> >>>>>Vincent Furia wrote: >>>>> >>>>> >>>>> >>>>> >>>>> >>>>>>Tony, >>>>>> >>>>>>Just looking through the DAO to understand everything it is doing >>>>>>better. I noticed that the "find" method (and the other methods) >>>>>>reloads the named queries from the xml file on every call. We should >>>>>>look for a way to work around this (i.e. somehow cache the DOMXPath >>>>>>object) so as not to suffer huge penalties for parsing the XML file on >>>>>>every DB call. >>>>>> >>>>>>-Vinny >>>>>>_______________________________________________ >>>>>>geeklog-devel mailing list >>>>>>geeklog-devel at lists.geeklog.net >>>>>>http://lists.geeklog.net/listinfo/geeklog-devel >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>_______________________________________________ >>>>>geeklog-devel mailing list >>>>>geeklog-devel at lists.geeklog.net >>>>>http://lists.geeklog.net/listinfo/geeklog-devel >>>>> >>>>> >>>>> >>>>> >>>>> >>>_______________________________________________ >>>geeklog-devel mailing list >>>geeklog-devel at lists.geeklog.net >>>http://lists.geeklog.net/listinfo/geeklog-devel >>> >>> >>> >>> >>_______________________________________________ >>geeklog-devel mailing list >>geeklog-devel at lists.geeklog.net >>http://lists.geeklog.net/listinfo/geeklog-devel >> >> >> >_______________________________________________ >geeklog-devel mailing list >geeklog-devel at lists.geeklog.net >http://lists.geeklog.net/listinfo/geeklog-devel > > From tony at tonybibbs.com Thu Jan 27 22:10:29 2005 From: tony at tonybibbs.com (Tony Bibbs) Date: Thu, 27 Jan 2005 21:10:29 -0600 Subject: [geeklog-devel] Re: Autoincrement on Items In-Reply-To: <8319e2d605012020456dcdeb72@mail.gmail.com> References: <8319e2d605012020456dcdeb72@mail.gmail.com> Message-ID: <41F9AD25.9000208@tonybibbs.com> So you're saying to keep the 'security by obscurity' we get by using the sid's? Sounds good, only gripe is what do you do if you are running Geeklog-2 under more than one webserver? This is a great question though. Do you depend a bit on obscurity or depend on your code to do the appropriate security checking. If we want to stick with some obscurity, is there something beside timestamps we could do it with? FYI, I moved this to the -devel list --Tony Vincent Furia wrote: >Tony, > >Just was thinking about one concern about allowing visibility >to/access by the auto increment column of the item table. Currently >in Geeklog with the pseudo random story ids or manually set ids there >is no chance of a person knowing that another item exists that they >might have access to. > >But if you can see item ids in Gl2 (auto incrementing), and they can >see story 5 and link 7 they know that there must be (or have been at >some point) an item 6. > >Just something to keep in mind. Especially if we Gl2 to have the same >reputation as 1.x. > >-Vinny > > From tony at tonybibbs.com Thu Jan 27 22:28:07 2005 From: tony at tonybibbs.com (Tony Bibbs) Date: Thu, 27 Jan 2005 21:28:07 -0600 Subject: [geeklog-devel] Links to-do Message-ID: <41F9B147.90408@tonybibbs.com> Here are some things the links plugin needs to do (in no particular order). The first thing are things addressed across plugins and should be addressed in the framework of the 'item' concept. The second list are things specific to the link plugin. - allow security defaults to be set for plugins - email notification when items get accepted, denied, etc - Disable items - Rating of items (possibly a seperate plugin) - Ability to report a broken or inappropriate link - links give ownership to the submiter. Should work just like stories in 1.3.x - Nested categories (handled by current data model) - Count click-thru's. Should be configurable to turn this off - Automatic checking that links work (optional cron script or something) More anybody? Trying to get this all articulate for Kevin. It's worth noting that I did go through the 1.3.x feature list to generate some of this. I need to double check it that I didn't miss something. --Tony From vfuria at gmail.com Fri Jan 28 11:32:11 2005 From: vfuria at gmail.com (Vincent Furia) Date: Fri, 28 Jan 2005 11:32:11 -0500 Subject: [geeklog-devel] Links to-do In-Reply-To: <41F9B147.90408@tonybibbs.com> References: <41F9B147.90408@tonybibbs.com> Message-ID: <8319e2d605012808329e57373@mail.gmail.com> An addition for "accross all plugins": - submission moderation > - links give ownership to the submiter. Should work just like stories > in 1.3.x I think authorship should always go to the submitter, default "ownership" in the sense of the ability to control the item (edit, delete, change permissions) should be configurable in some way (and probably should not default to the submitter). -Vinny On Thu, 27 Jan 2005 21:28:07 -0600, Tony Bibbs wrote: > Here are some things the links plugin needs to do (in no particular > order). The first thing are things addressed across plugins and should > be addressed in the framework of the 'item' concept. The second list > are things specific to the link plugin. > > - allow security defaults to be set for plugins > - email notification when items get accepted, denied, etc > - Disable items > - Rating of items (possibly a seperate plugin) > > - Ability to report a broken or inappropriate link > - links give ownership to the submiter. Should work just like stories > in 1.3.x > - Nested categories (handled by current data model) > - Count click-thru's. Should be configurable to turn this off > - Automatic checking that links work (optional cron script or something) > > More anybody? Trying to get this all articulate for Kevin. It's worth > noting that I did go through the 1.3.x feature list to generate some of > this. I need to double check it that I didn't miss something. > > --Tony > > _______________________________________________ > geeklog-devel mailing list > geeklog-devel at lists.geeklog.net > http://lists.geeklog.net/listinfo/geeklog-devel > From vfuria at gmail.com Fri Jan 28 14:22:24 2005 From: vfuria at gmail.com (Vincent Furia) Date: Fri, 28 Jan 2005 14:22:24 -0500 Subject: [geeklog-devel] Deleting comments In-Reply-To: <8319e2d60501221822155fb96a@mail.gmail.com> References: <8319e2d60501211534c725830@mail.gmail.com> <20050122100058.4815@smtp.haun-online.de> <8319e2d60501221822155fb96a@mail.gmail.com> Message-ID: <8319e2d6050128112273f701c6@mail.gmail.com> Well, I think I'm done. Attached is the new documentation for Plugin Comment Engine. Note the missing code examples. I was hoping to work with Blaine, Tom, or one of the other plugin developers that use comments to get the examples done (and to make sure that the new API is reasonable). Note that comment.php passes on requests to delete and save comments to the plugin which then must call CMT_deleteComment or CMT_saveComment respectively. That way plugins can do any pre-save/delete checks and post-save/delete processing that they want. Besides the major changes to the comment API, I have also refactored the code in comment.php and consolidated comment related code in system/lib-comment.php. A code review would be welcome, but at the least some strenuous testing is required. Here is a list of files that I ended up touching: public_html/comment.php public_html/article.php public_html/layout/professional/comment/commentbar.thtml public_html/layout/professional/comment/thread.thtml public_html/lib-common.php system/lib-comment.php system/lib-plugins.php I'll repeat. Please test this out a bit. I've done a lot of testing, but the changes are pretty significant. Thanks, Vinny On Sat, 22 Jan 2005 21:22:49 -0500, Vincent Furia wrote: > With Dirk's blessing to break the comment plugin API. Here is my idea thus far: > > CMT_deleteComment and CMT_saveComment will be limited to exactly that > functionality. They will act no different for articles or polls as > they would for any other variable. They will return 0 for success or > >0 for failure (and log the failure to the errorLog). I plan on doing > something similar for CMT_commentForm. > > So there will now be plugin functions for saving and deleting comments > which should simply call these functions when they are ready (and > determine that the correct permissions hold, etc). > > I'll continue with this approach if it sounds good to everyone. I'd > especially like some feedback from anyone currently using the plugin > comment functionality. > > -Vinny > -------------- next part -------------- An HTML attachment was scrubbed... URL: From dirk at haun-online.de Fri Jan 28 14:46:07 2005 From: dirk at haun-online.de (Dirk Haun) Date: Fri, 28 Jan 2005 20:46:07 +0100 Subject: [geeklog-devel] Deleting comments In-Reply-To: <8319e2d6050128112273f701c6@mail.gmail.com> References: <8319e2d6050128112273f701c6@mail.gmail.com> Message-ID: <20050128194607.17387@smtp.haun-online.de> Vinny, I'd like to suggest an additional change that shouldn't interfere with what you did. I think in PLG_commentPreSave (and the plugin's implementation of that function), $comment should be passed by reference. That way, plugins could alter the text of the comment, e.g. to replace smilies or whatever comes to mind. Thoughts? >A code review would be welcome, but at the >least some strenuous testing is required. geeklog.info is running on the latest CVS code. The site isn't too busy, but that will provide some testing. I'll also have a look at the code. bye, Dirk -- http://www.haun-online.de/ http://www.tinyweb.de/ From vfuria at gmail.com Fri Jan 28 15:03:22 2005 From: vfuria at gmail.com (Vincent Furia) Date: Fri, 28 Jan 2005 15:03:22 -0500 Subject: [geeklog-devel] Deleting comments In-Reply-To: <20050128194607.17387@smtp.haun-online.de> References: <8319e2d6050128112273f701c6@mail.gmail.com> <20050128194607.17387@smtp.haun-online.de> Message-ID: <8319e2d6050128120360240d77@mail.gmail.com> I like the idea. And it seems like it wouldn't be too difficult to implement. I think only title, comment, and postmode should be passed by reference though. -Vinny On Fri, 28 Jan 2005 20:46:07 +0100, Dirk Haun wrote: > Vinny, > > I'd like to suggest an additional change that shouldn't interfere with > what you did. I think in PLG_commentPreSave (and the plugin's > implementation of that function), $comment should be passed by reference. > > That way, plugins could alter the text of the comment, e.g. to replace > smilies or whatever comes to mind. > > Thoughts? > > > >A code review would be welcome, but at the > >least some strenuous testing is required. > > geeklog.info is running on the latest CVS code. The site isn't too busy, > but that will provide some testing. I'll also have a look at the code. > > bye, Dirk > > -- > http://www.haun-online.de/ > http://www.tinyweb.de/ > > _______________________________________________ > geeklog-devel mailing list > geeklog-devel at lists.geeklog.net > http://lists.geeklog.net/listinfo/geeklog-devel > From dirk at haun-online.de Fri Jan 28 15:48:35 2005 From: dirk at haun-online.de (Dirk Haun) Date: Fri, 28 Jan 2005 21:48:35 +0100 Subject: [geeklog-devel] Deleting comments In-Reply-To: <8319e2d6050128120360240d77@mail.gmail.com> References: <8319e2d6050128120360240d77@mail.gmail.com> Message-ID: <20050128204835.2089@smtp.haun-online.de> Vincent Furia wrote: >I think only title, comment, and postmode should be passed >by reference though. Makes perfect sense (to me at least ;-) bye, Dirk -- http://www.haun-online.de/ http://www.macosx-faq.de/ From tony at tonybibbs.com Fri Jan 28 17:04:37 2005 From: tony at tonybibbs.com (Tony Bibbs) Date: Fri, 28 Jan 2005 16:04:37 -0600 Subject: [Fwd: Re: [geeklog-devel] GL2 DataAccess Class] Message-ID: <41FAB6F5.6060304@tonybibbs.com> Forgot to include the list. --Tony -------- Original Message -------- Subject: Re: [geeklog-devel] GL2 DataAccess Class Date: Fri, 28 Jan 2005 15:46:53 -0600 From: Tony Bibbs To: vmf at abtech.org References: <8319e2d60501162044335efb64 at mail.gmail.com> <41EBCC95.7080203 at tonybibbs.com> <8319e2d605011706391e0c02d7 at mail.gmail.com> <8319e2d6050117070717a15298 at mail.gmail.com> <41EBF8C1.8070503 at tonybibbs.com> <8319e2d605011710386432525e at mail.gmail.com> <41F9AB13.3030605 at tonybibbs.com> <8319e2d605012808432fb2eaeb at mail.gmail.com> Vincent Furia wrote: >Tony, > >I'm just sending this to you because I'm not sure if this debate >belongs on the list. Feel free to move it there if you'd like. > > I'll leave it there. I think it is a good debate so that we have a log of consciously deciding these things. >It is still undefined what return value should be expected when an >UPDATE or INSERT is done. Normally the DAO returns an array of >classes, that doesn't make sense for UPDATEs or INSERTs. > > Updates deletes and inserts would all throw SQLExceptions. So you would to do a TRY clause around them, and all database calls for that matter. In otherwords, no return means all went well. >I'm starting to get more and more concerned with speed issues for GL2. > Between Creole being generally slow compared to other DBAPIs (by >itself, not that big of a deal) and Propel loading/includes being very >time intensive I'm worried adding additional layers are going to slow >things down. > >All these things combine to make me want to reconsider using the DAO. >We also need to get to the point where we can decide if the Propel >speed issues are going to be a problem. > > Stripping the DAO doesn't save you anything. The Creole/Propel issues would still exist. I'm not skirting the issues with the performance. I fully expect that I/we will have to do true profiling at some point with this. The real question I think you are asking is just how much overhead is the DAO and how does that compare to the benefits. >Also, noting that the February deadline you imposed on yourself is >looming, I'm curious if you feel work has progressed enough to keep to >going (I feel that we're making good progress). > > Yeah, I was just thinking about this the other day. I definitely think things have progressed and that we have a ton of code to show for it. My only worry is things stagnating again. I'm doing to do my best to prevent this but getting continuing help from you and Kevin will be just as important of a factor. >As I said before, I'm don't feel strongly enough about the DAO to >force the issue. But I think it warrants reconsideration. > > Maybe we should take the link plugin, implement it fully and do some serious performance analysis on it before deciding on the DAO. That way we have only implemented time into one fairly minor plugin and I think it has enough complexity to give us an idea on performance? I'm leary of ditching the DAO as it has proven useful in all my apps here at work. Here we recently went from using raw JDBC to using Hibernate by simply implementing the new DAO layer and it saved us a bunch of time. Granted that was Java but without going the DAO layer, going to Hibernate wouldn't have even have been possible. --Tony From vfuria at gmail.com Fri Jan 28 18:15:16 2005 From: vfuria at gmail.com (Vincent Furia) Date: Fri, 28 Jan 2005 18:15:16 -0500 Subject: [geeklog-devel] Deleting comments In-Reply-To: <20050128204835.2089@smtp.haun-online.de> References: <8319e2d6050128120360240d77@mail.gmail.com> <20050128204835.2089@smtp.haun-online.de> Message-ID: <8319e2d605012815152694fabf@mail.gmail.com> Hows that for a feature improvement, only had to add 3 characters. (Discussed fix checked in). -Vinny On Fri, 28 Jan 2005 21:48:35 +0100, Dirk Haun wrote: > Vincent Furia wrote: > > >I think only title, comment, and postmode should be passed > >by reference though. > > Makes perfect sense (to me at least ;-) > > bye, Dirk > > -- > http://www.haun-online.de/ > http://www.macosx-faq.de/ > > _______________________________________________ > geeklog-devel mailing list > geeklog-devel at lists.geeklog.net > http://lists.geeklog.net/listinfo/geeklog-devel > From dirk at haun-online.de Fri Jan 28 18:27:26 2005 From: dirk at haun-online.de (Dirk Haun) Date: Sat, 29 Jan 2005 00:27:26 +0100 Subject: [geeklog-devel] Deleting comments In-Reply-To: <8319e2d605012815152694fabf@mail.gmail.com> References: <8319e2d605012815152694fabf@mail.gmail.com> Message-ID: <20050128232726.7871@smtp.haun-online.de> Vincent Furia wrote: >Hows that for a feature improvement, only had to add 3 characters. >(Discussed fix checked in). Not bad. Quite a bit of overhead for those 3 characters, though ;-) bye, Dirk -- http://www.haun-online.de/ http://www.macosx-faq.de/ From vfuria at gmail.com Sat Jan 29 11:03:23 2005 From: vfuria at gmail.com (Vincent Furia) Date: Sat, 29 Jan 2005 11:03:23 -0500 Subject: [geeklog-devel] GL2 link? In-Reply-To: <20050125201153.17691@smtp.haun-online.de> References: <20050125201153.17691@smtp.haun-online.de> Message-ID: <8319e2d605012908035ab8da63@mail.gmail.com> How about linking to http://wiki.geeklog.net/wiki/index.php/Geeklog_2x_Documentation. I think that has the most information about GL2 short of the mailing lists. -Vinny On Tue, 25 Jan 2005 21:11:52 +0100, Dirk Haun wrote: > What's a good link to point people to information about GL2? I've > restructured the Resources block on geeklog.net a bit and noticed that > the "Geeklog 2" link there points to the project page, which doesn't have > a lot to say about GL2. > > Maybe someone wants to write a static page that can serve as a portal > page to the various GL2 resources? > > Speaking of which: At one point, we had a GL2 vision document (linked to > from ) but it's > long gone. Search engines and human readers are still looking for it, > though, so I've configured the server to send a "410 Gone". Does someone > still have that document? > > bye, Dirk > > -- > http://www.haun-online.de/ > http://www.macosx-faq.de/ > > _______________________________________________ > geeklog-devel mailing list > geeklog-devel at lists.geeklog.net > http://lists.geeklog.net/listinfo/geeklog-devel > From dirk at haun-online.de Sat Jan 29 11:18:32 2005 From: dirk at haun-online.de (Dirk Haun) Date: Sat, 29 Jan 2005 17:18:32 +0100 Subject: [geeklog-devel] GL2 link? In-Reply-To: <8319e2d605012908035ab8da63@mail.gmail.com> References: <8319e2d605012908035ab8da63@mail.gmail.com> Message-ID: <20050129161832.31755@smtp.haun-online.de> Vincent Furia wrote: >How about linking to >http://wiki.geeklog.net/wiki/index.php/Geeklog_2x_Documentation Good idea - completely forgot about the Wiki. bye, Dirk -- http://www.haun-online.de/ http://geeklog.info/ From vfuria at gmail.com Sun Jan 30 18:51:37 2005 From: vfuria at gmail.com (Vincent Furia) Date: Sun, 30 Jan 2005 18:51:37 -0500 Subject: [geeklog-devel] Dynamic Comments... Message-ID: <8319e2d60501301551495082d9@mail.gmail.com> Just a prototype right now: http://vfuria.dyndns.org:8080/article.php?story=geeklog-1.3.10rc2&mode=dynamic What do people think (try clicking on the blue arrows). -Vinny From dirk at haun-online.de Mon Jan 31 15:00:10 2005 From: dirk at haun-online.de (Dirk Haun) Date: Mon, 31 Jan 2005 21:00:10 +0100 Subject: [geeklog-devel] Dynamic Comments... In-Reply-To: <8319e2d60501301551495082d9@mail.gmail.com> References: <8319e2d60501301551495082d9@mail.gmail.com> Message-ID: <20050131200010.25528@smtp.haun-online.de> Vinny, >What do people think (try clicking on the blue arrows). Nice. When can we expect it in CVS? ;-) bye, Dirk -- http://www.haun-online.de/ http://www.haun.info/ From vfuria at gmail.com Mon Jan 31 15:12:18 2005 From: vfuria at gmail.com (Vincent Furia) Date: Mon, 31 Jan 2005 15:12:18 -0500 Subject: [geeklog-devel] Dynamic Comments... In-Reply-To: <20050131200010.25528@smtp.haun-online.de> References: <8319e2d60501301551495082d9@mail.gmail.com> <20050131200010.25528@smtp.haun-online.de> Message-ID: <8319e2d6050131121241e8e4a@mail.gmail.com> I'm working on getting it past the prototype stage. While it (just) works now, I need to do some modifications to make it integrate cleanly and to not be embarrassed by my code. Hopefully I'll have it checked into CVS in the next couple days. Now, some possible downsides: 1. Each time a person clicks to expand (or collapse) a comment it is a http request to the server, which means loading lib-common.php, etc. While the page load for just the comment is relatively fast, server load could be problem for a really popular server (especially, say, during a slashdotting). 2. The images I'm using I grabbed from http://kuro5hin.org. I need to check their licensing to make sure I don't piss anyone off. 3. Of course, as with all good things, theme updates are required. -Vinny From dirk at haun-online.de Mon Jan 31 15:20:00 2005 From: dirk at haun-online.de (Dirk Haun) Date: Mon, 31 Jan 2005 21:20:00 +0100 Subject: [geeklog-devel] Dynamic Comments... In-Reply-To: <8319e2d6050131121241e8e4a@mail.gmail.com> References: <8319e2d6050131121241e8e4a@mail.gmail.com> Message-ID: <20050131202000.25407@smtp.haun-online.de> Vinny, >While the page load for just the comment is relatively fast, server >load could be problem for a really popular server (especially, say, >during a slashdotting). I was about to ask about the server load :-) Any chance this could be made configurable? Comment-heavy sites like groklaw could then switch it off. >2. The images I'm using I grabbed from http://kuro5hin.org. I need to >check their licensing to make sure I don't piss anyone off. They don't quite fit in with the Professional theme anyway, IMHO. They look a bit too heavy to me. I'm sure Simon can come up with something royalty-free ;-) bye, Dirk -- http://www.haun-online.de/ http://www.haun.info/ From vfuria at gmail.com Mon Jan 31 15:31:15 2005 From: vfuria at gmail.com (Vincent Furia) Date: Mon, 31 Jan 2005 15:31:15 -0500 Subject: [geeklog-devel] Dynamic Comments... In-Reply-To: <20050131202000.25407@smtp.haun-online.de> References: <8319e2d6050131121241e8e4a@mail.gmail.com> <20050131202000.25407@smtp.haun-online.de> Message-ID: <8319e2d605013112316b058ebd@mail.gmail.com> On Mon, 31 Jan 2005 21:20:00 +0100, Dirk Haun wrote: > I was about to ask about the server load :-) > > Any chance this could be made configurable? Comment-heavy sites like > groklaw could then switch it off. > I'm sure its possible, I'm not sure it it will be easy or pretty though. The comment modes are kept in the database now, so switching "off" dynamic comments would at least require an admin to modify the database and probably a $_CONF variable that would ignore requests for single comments (outside the geeklog header/footer framework) and ignore requests for comments to be displayed dynamically. > > They don't quite fit in with the Professional theme anyway, IMHO. They > look a bit too heavy to me. > > I'm sure Simon can come up with something royalty-free ;-) > Simon: think you can whip something up? -Vinny From niels at creatype.nl Mon Jan 31 15:44:03 2005 From: niels at creatype.nl (Niels Leenheer) Date: Mon, 31 Jan 2005 21:44:03 +0100 Subject: [geeklog-devel] Dynamic Comments... In-Reply-To: <8319e2d6050131121241e8e4a@mail.gmail.com> References: <8319e2d60501301551495082d9@mail.gmail.com> <20050131200010.25528@smtp.haun-online.de> <8319e2d6050131121241e8e4a@mail.gmail.com> Message-ID: <41FE9893.5080500@creatype.nl> Vincent Furia wrote: >I'm working on getting it past the prototype stage. While it (just) >works now, I need to do some modifications to make it integrate >cleanly and to not be embarrassed by my code. Hopefully I'll have it >checked into CVS in the next couple days. > > Vincent, great idea! However, I can see a couple of problems with the code you are currently using. First of all, you are using a single XMLHttpRequest object without protecting it from being called more than once. As a result it is possible to interrupt an ongoing request. Try clicking on quickly on multiple triangles after each other, without waiting for one to finish loading. Only the request clicked on last will be honoured, the other ones will be 'loading' indefinately. The solution to this problem would be to use an array and push each request in it. Then use a timer to frequently look at this array, shift one request of the bottom and execute it. Repeat until the array is empty... Secondly, there is a bug in the XMLHttpRequest implementation of Opera, which basically requeres and extra check inside the onreadystatechange function, otherwise it will be called multiple times after each other, but only the first time with the proper responseText. var inprogress = false; function loadFragmentInToElement(fragment_url, element_id) { var element = document.getElementById(element_id); element.innerHTML = 'Loading...Loading ...'; xmlhttp.open("GET", fragment_url); xmlhttp.onreadystatechange = function() { if (inprogress == true && xmlhttp.readyState == 4 && xmlhttp.status == 200) { inprogress = false; element.innerHTML = xmlhttp.responseText; } } xmlhttp.send(null); inprogress = true; } Niels -- www.rakaz.nl From justin.carlson at gmail.com Mon Jan 31 17:54:58 2005 From: justin.carlson at gmail.com (Justin Carlson) Date: Mon, 31 Jan 2005 16:54:58 -0600 Subject: [geeklog-devel] Dynamic Comments... In-Reply-To: <41FE9893.5080500@creatype.nl> References: <8319e2d60501301551495082d9@mail.gmail.com> <20050131200010.25528@smtp.haun-online.de> <8319e2d6050131121241e8e4a@mail.gmail.com> <41FE9893.5080500@creatype.nl> Message-ID: <3d1a3f4e05013114547ff6b29b@mail.gmail.com> It looks like it works well. I do not see myself using it, and definitely request it to be optional. On Mon, 31 Jan 2005 21:44:03 +0100, Niels Leenheer wrote: > Vincent Furia wrote: > > >I'm working on getting it past the prototype stage. While it (just) > >works now, I need to do some modifications to make it integrate > >cleanly and to not be embarrassed by my code. Hopefully I'll have it > >checked into CVS in the next couple days. > > > > > Vincent, great idea! > > However, I can see a couple of problems with the code you are currently > using. > > First of all, you are using a single XMLHttpRequest object without > protecting > it from being called more than once. As a result it is possible to > interrupt an > ongoing request. Try clicking on quickly on multiple triangles after > each other, > without waiting for one to finish loading. Only the request clicked on > last will > be honoured, the other ones will be 'loading' indefinately. > > The solution to this problem would be to use an array and push each > request in it. Then use a timer to frequently look at this array, shift > one request of the bottom and execute it. Repeat until the array is > empty... > > Secondly, there is a bug in the XMLHttpRequest implementation of Opera, > which basically requeres and extra check inside the onreadystatechange > function, otherwise it will be called multiple times after each other, > but only the first time with the proper responseText. > > var inprogress = false; > > function loadFragmentInToElement(fragment_url, element_id) { > var element = document.getElementById(element_id); > element.innerHTML = ' alt="Loading..."/>Loading ...'; > xmlhttp.open("GET", fragment_url); > xmlhttp.onreadystatechange = function() { > if (inprogress == true && xmlhttp.readyState == 4 && > xmlhttp.status == 200) { > inprogress = false; > element.innerHTML = xmlhttp.responseText; > } > } > xmlhttp.send(null); > inprogress = true; > } > > Niels > -- > www.rakaz.nl > _______________________________________________ > geeklog-devel mailing list > geeklog-devel at lists.geeklog.net > http://lists.geeklog.net/listinfo/geeklog-devel >