You can subscribe to this list here.
2002 |
Jan
|
Feb
|
Mar
(103) |
Apr
(37) |
May
(45) |
Jun
(49) |
Jul
(55) |
Aug
(11) |
Sep
(47) |
Oct
(55) |
Nov
(47) |
Dec
(8) |
---|---|---|---|---|---|---|---|---|---|---|---|---|
2003 |
Jan
(43) |
Feb
(85) |
Mar
(121) |
Apr
(37) |
May
(33) |
Jun
(33) |
Jul
(14) |
Aug
(34) |
Sep
(58) |
Oct
(68) |
Nov
(31) |
Dec
(9) |
2004 |
Jan
(13) |
Feb
(57) |
Mar
(37) |
Apr
(26) |
May
(57) |
Jun
(14) |
Jul
(8) |
Aug
(12) |
Sep
(32) |
Oct
(10) |
Nov
(7) |
Dec
(12) |
2005 |
Jan
(8) |
Feb
(25) |
Mar
(50) |
Apr
(20) |
May
(32) |
Jun
(20) |
Jul
(83) |
Aug
(25) |
Sep
(17) |
Oct
(14) |
Nov
(32) |
Dec
(27) |
2006 |
Jan
(24) |
Feb
(15) |
Mar
(46) |
Apr
(5) |
May
(6) |
Jun
(9) |
Jul
(12) |
Aug
(5) |
Sep
(7) |
Oct
(7) |
Nov
(4) |
Dec
(5) |
2007 |
Jan
(4) |
Feb
(1) |
Mar
(7) |
Apr
(3) |
May
(4) |
Jun
|
Jul
|
Aug
(2) |
Sep
(2) |
Oct
|
Nov
(22) |
Dec
(19) |
2008 |
Jan
(94) |
Feb
(19) |
Mar
(32) |
Apr
(46) |
May
(20) |
Jun
(10) |
Jul
(11) |
Aug
(20) |
Sep
(16) |
Oct
(12) |
Nov
(13) |
Dec
|
2009 |
Jan
|
Feb
(9) |
Mar
(37) |
Apr
(65) |
May
(15) |
Jun
|
Jul
(24) |
Aug
(1) |
Sep
(8) |
Oct
(4) |
Nov
(21) |
Dec
(5) |
2010 |
Jan
(35) |
Feb
(6) |
Mar
(8) |
Apr
|
May
(4) |
Jun
(3) |
Jul
(4) |
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
2011 |
Jan
|
Feb
(4) |
Mar
|
Apr
|
May
(1) |
Jun
(1) |
Jul
(1) |
Aug
|
Sep
(1) |
Oct
|
Nov
|
Dec
|
From: Matthew G. <mat...@gm...> - 2008-04-21 15:25:39
|
Most frameworks provide some sort of: Database abstraction Data validation UI abstraction(proper templating, etc..) Authentication(or at least support the idea of a single entry point) Unit Tests On Mon, 2008-04-21 at 11:01 -0400, Bishop Bettini wrote: > Quoting Matthew Gregg <mat...@gm...>: > > > Joel may be correct with projects the size of mozilla, but I'm not so > > sure with something as small as ESP. Especially since I would hope a > > great deal of what is currently custom in the code-base would be > > provided out of the box in most modern frameworks. > > To an outsider (me), phpESP looks pretty big, though that is probably > a mirage: I have had no problem digging into it, nor have I > encountered any feelings of "how deep does this rabbit hole go?" I > also don't know how many people/organizations use phpESP, so I'm not > sure what kind of upgrade resistance the community would offer. > > When you say "framework," what do you mean? When I hear "a great deal > of what is currently custom ... would be provided .. in [a] modern > framework", that makes me think that phpESP wouldn't add much value > over the framework. > > > > As for as a space for collaboration. I can enable the wiki on the > > Sourceforge site or drop an instance of Trac on our hosting service. > > > > IRC is available here: irc://irc.freenode.net/phpesp/ > > Or if you would rather have a Jabber/XMPP conference room I can have > > that available in a few seconds. > > I would think we'd want a wiki (or static repository of some kind), to > keep the documentation around for a longer period than afforded by > communication groups. > > bishop > > > > On Sun, 2008-04-20 at 19:38 -0400, Bishop Bettini wrote: > >> While I agree the code is horrendous in many places, I caution against > >> a wholesale rewrite, for the reasons Joel gives here: > >> http://www.joelonsoftware.com/articles/fog0000000069.html > >> > >> But, if that is the tack taken for v3, we should define the > >> requirements, write the functional specification, identify re-use and > >> re-factor candidates, decide on the platform tools, draw the road map, > >> and declare milestones. In other words, do it right and try not to > >> make the same mistakes. > >> > >> On that note, is there a wiki or some other collaboration space where > >> this information (requirements, specifications, etc) can be maintained? > >> > >> bishop > >> > >> Quoting Franky Van Liedekerke <lie...@te...>: > >> > >> > On Sat, 19 Apr 2008 20:21:28 -0400 > >> > Matthew Gregg <mat...@gm...> wrote: > >> > > >> >> So many things need to be redone in the current code base: > >> >> * Permission system > >> >> * User management > >> >> * The admin UI <-biggie > >> >> * Survey results export > >> >> * Survey question storage export/interchange > >> >> * etc... > >> >> and it's already in a pretty ugly state, that I have had "flip the > >> >> switch and start over" in my head for a long time. I have worked > >> >> privately on a few proof of concepts for this, but never pushed to > >> >> have something usable. Current code could be put into maintenance > >> >> mode and new dev only on this "branch". > >> > > >> > well, I agree here: the current code is ugly and I sometimes thought > >> > about beginning from scratch again also. So I'm in favour of starting > >> > over also. > >> > > >> > Franky > >> > > >> > ------------------------------------------------------------------------- > >> > This SF.net email is sponsored by the 2008 JavaOne(SM) Conference > >> > Don't miss this year's exciting event. There's still time to save $100. > >> > Use priority code J8TL2D2. > >> > > >> http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone > >> > _______________________________________________ > >> > phpESP-devel mailing list > >> > php...@li... > >> > https://lists.sourceforge.net/lists/listinfo/phpesp-devel > >> > > >> > >> > >> > > -- > > Matthew Gregg <mat...@gm...> > > > > > > ------------------------------------------------------------------------- > > This SF.net email is sponsored by the 2008 JavaOne(SM) Conference > > Don't miss this year's exciting event. There's still time to save $100. > > Use priority code J8TL2D2. > > http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone > > _______________________________________________ > > phpESP-devel mailing list > > php...@li... > > https://lists.sourceforge.net/lists/listinfo/phpesp-devel > > > > > |
From: Bishop B. <ph...@id...> - 2008-04-21 15:02:01
|
Quoting Matthew Gregg <mat...@gm...>: > Joel may be correct with projects the size of mozilla, but I'm not so > sure with something as small as ESP. Especially since I would hope a > great deal of what is currently custom in the code-base would be > provided out of the box in most modern frameworks. To an outsider (me), phpESP looks pretty big, though that is probably a mirage: I have had no problem digging into it, nor have I encountered any feelings of "how deep does this rabbit hole go?" I also don't know how many people/organizations use phpESP, so I'm not sure what kind of upgrade resistance the community would offer. When you say "framework," what do you mean? When I hear "a great deal of what is currently custom ... would be provided .. in [a] modern framework", that makes me think that phpESP wouldn't add much value over the framework. > As for as a space for collaboration. I can enable the wiki on the > Sourceforge site or drop an instance of Trac on our hosting service. > > IRC is available here: irc://irc.freenode.net/phpesp/ > Or if you would rather have a Jabber/XMPP conference room I can have > that available in a few seconds. I would think we'd want a wiki (or static repository of some kind), to keep the documentation around for a longer period than afforded by communication groups. bishop > On Sun, 2008-04-20 at 19:38 -0400, Bishop Bettini wrote: >> While I agree the code is horrendous in many places, I caution against >> a wholesale rewrite, for the reasons Joel gives here: >> http://www.joelonsoftware.com/articles/fog0000000069.html >> >> But, if that is the tack taken for v3, we should define the >> requirements, write the functional specification, identify re-use and >> re-factor candidates, decide on the platform tools, draw the road map, >> and declare milestones. In other words, do it right and try not to >> make the same mistakes. >> >> On that note, is there a wiki or some other collaboration space where >> this information (requirements, specifications, etc) can be maintained? >> >> bishop >> >> Quoting Franky Van Liedekerke <lie...@te...>: >> >> > On Sat, 19 Apr 2008 20:21:28 -0400 >> > Matthew Gregg <mat...@gm...> wrote: >> > >> >> So many things need to be redone in the current code base: >> >> * Permission system >> >> * User management >> >> * The admin UI <-biggie >> >> * Survey results export >> >> * Survey question storage export/interchange >> >> * etc... >> >> and it's already in a pretty ugly state, that I have had "flip the >> >> switch and start over" in my head for a long time. I have worked >> >> privately on a few proof of concepts for this, but never pushed to >> >> have something usable. Current code could be put into maintenance >> >> mode and new dev only on this "branch". >> > >> > well, I agree here: the current code is ugly and I sometimes thought >> > about beginning from scratch again also. So I'm in favour of starting >> > over also. >> > >> > Franky >> > >> > ------------------------------------------------------------------------- >> > This SF.net email is sponsored by the 2008 JavaOne(SM) Conference >> > Don't miss this year's exciting event. There's still time to save $100. >> > Use priority code J8TL2D2. >> > >> http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone >> > _______________________________________________ >> > phpESP-devel mailing list >> > php...@li... >> > https://lists.sourceforge.net/lists/listinfo/phpesp-devel >> > >> >> >> > -- > Matthew Gregg <mat...@gm...> > > > ------------------------------------------------------------------------- > This SF.net email is sponsored by the 2008 JavaOne(SM) Conference > Don't miss this year's exciting event. There's still time to save $100. > Use priority code J8TL2D2. > http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone > _______________________________________________ > phpESP-devel mailing list > php...@li... > https://lists.sourceforge.net/lists/listinfo/phpesp-devel > -- Bishop Bettini ideacode, Inc. (main) +1 919 341 5170 / (fax) +1 919 521 4100 Visit us on the web at: ideacode.com Professional software research and development reviewmysoftware.com Improve sales! Review your software before you release bytejar.com Solutions to those annoying development problems |
From: Matthew G. <mat...@gm...> - 2008-04-21 01:25:58
|
Joel may be correct with projects the size of mozilla, but I'm not so sure with something as small as ESP. Especially since I would hope a great deal of what is currently custom in the code-base would be provided out of the box in most modern frameworks. As for as a space for collaboration. I can enable the wiki on the Sourceforge site or drop an instance of Trac on our hosting service. IRC is available here: irc://irc.freenode.net/phpesp/ Or if you would rather have a Jabber/XMPP conference room I can have that available in a few seconds. On Sun, 2008-04-20 at 19:38 -0400, Bishop Bettini wrote: > While I agree the code is horrendous in many places, I caution against > a wholesale rewrite, for the reasons Joel gives here: > http://www.joelonsoftware.com/articles/fog0000000069.html > > But, if that is the tack taken for v3, we should define the > requirements, write the functional specification, identify re-use and > re-factor candidates, decide on the platform tools, draw the road map, > and declare milestones. In other words, do it right and try not to > make the same mistakes. > > On that note, is there a wiki or some other collaboration space where > this information (requirements, specifications, etc) can be maintained? > > bishop > > Quoting Franky Van Liedekerke <lie...@te...>: > > > On Sat, 19 Apr 2008 20:21:28 -0400 > > Matthew Gregg <mat...@gm...> wrote: > > > >> So many things need to be redone in the current code base: > >> * Permission system > >> * User management > >> * The admin UI <-biggie > >> * Survey results export > >> * Survey question storage export/interchange > >> * etc... > >> and it's already in a pretty ugly state, that I have had "flip the > >> switch and start over" in my head for a long time. I have worked > >> privately on a few proof of concepts for this, but never pushed to > >> have something usable. Current code could be put into maintenance > >> mode and new dev only on this "branch". > > > > well, I agree here: the current code is ugly and I sometimes thought > > about beginning from scratch again also. So I'm in favour of starting > > over also. > > > > Franky > > > > ------------------------------------------------------------------------- > > This SF.net email is sponsored by the 2008 JavaOne(SM) Conference > > Don't miss this year's exciting event. There's still time to save $100. > > Use priority code J8TL2D2. > > http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone > > _______________________________________________ > > phpESP-devel mailing list > > php...@li... > > https://lists.sourceforge.net/lists/listinfo/phpesp-devel > > > > > -- Matthew Gregg <mat...@gm...> |
From: Bishop B. <ph...@id...> - 2008-04-20 23:38:17
|
While I agree the code is horrendous in many places, I caution against a wholesale rewrite, for the reasons Joel gives here: http://www.joelonsoftware.com/articles/fog0000000069.html But, if that is the tack taken for v3, we should define the requirements, write the functional specification, identify re-use and re-factor candidates, decide on the platform tools, draw the road map, and declare milestones. In other words, do it right and try not to make the same mistakes. On that note, is there a wiki or some other collaboration space where this information (requirements, specifications, etc) can be maintained? bishop Quoting Franky Van Liedekerke <lie...@te...>: > On Sat, 19 Apr 2008 20:21:28 -0400 > Matthew Gregg <mat...@gm...> wrote: > >> So many things need to be redone in the current code base: >> * Permission system >> * User management >> * The admin UI <-biggie >> * Survey results export >> * Survey question storage export/interchange >> * etc... >> and it's already in a pretty ugly state, that I have had "flip the >> switch and start over" in my head for a long time. I have worked >> privately on a few proof of concepts for this, but never pushed to >> have something usable. Current code could be put into maintenance >> mode and new dev only on this "branch". > > well, I agree here: the current code is ugly and I sometimes thought > about beginning from scratch again also. So I'm in favour of starting > over also. > > Franky > > ------------------------------------------------------------------------- > This SF.net email is sponsored by the 2008 JavaOne(SM) Conference > Don't miss this year's exciting event. There's still time to save $100. > Use priority code J8TL2D2. > http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone > _______________________________________________ > phpESP-devel mailing list > php...@li... > https://lists.sourceforge.net/lists/listinfo/phpesp-devel > -- Bishop Bettini ideacode, Inc. (main) +1 919 341 5170 / (fax) +1 919 521 4100 Visit us on the web at: ideacode.com Professional software research and development reviewmysoftware.com Improve sales! Review your software before you release bytejar.com Solutions to those annoying development problems |
From: Franky V. L. <lie...@te...> - 2008-04-20 14:55:57
|
On Sat, 19 Apr 2008 20:21:28 -0400 Matthew Gregg <mat...@gm...> wrote: > So many things need to be redone in the current code base: > * Permission system > * User management > * The admin UI <-biggie > * Survey results export > * Survey question storage export/interchange > * etc... > and it's already in a pretty ugly state, that I have had "flip the > switch and start over" in my head for a long time. I have worked > privately on a few proof of concepts for this, but never pushed to > have something usable. Current code could be put into maintenance > mode and new dev only on this "branch". well, I agree here: the current code is ugly and I sometimes thought about beginning from scratch again also. So I'm in favour of starting over also. Franky |
From: Matthew G. <mat...@gm...> - 2008-04-20 00:21:26
|
So many things need to be redone in the current code base: * Permission system * User management * The admin UI <-biggie * Survey results export * Survey question storage export/interchange * etc... and it's already in a pretty ugly state, that I have had "flip the switch and start over" in my head for a long time. I have worked privately on a few proof of concepts for this, but never pushed to have something usable. Current code could be put into maintenance mode and new dev only on this "branch". On Sat, 2008-04-19 at 18:02 -0400, Bishop Bettini wrote: > Matthew raises a very good point. In one of our products, we had a > similar hurdle: lots of very old code (early PHP 4 based) that was > rapidly produced in a not-so-modular fashion. Wholesale rewriting, > while desired, was not feasible given the clients using the code and > the sheer number of lines to change. > > To incorporate standardized testing, we first defined exactly what we > wanted tested (ie, specific areas that were prone to changes or known > to be problematic) and how we wanted to test (ie, unit, stress, > penetration, and coverage testing). > > Then, we settled on a robust framework -- phpunit2 -- that would grow > with us in that, and other, products. > > Finally, we made two rules: > 1. All new code SHOULD conform to our testing policy > 2. All bugs MUST get a test case to expose them and to prove they have > been fixed > > (Interpret MUST and SHOULD according to RFC2119) > > That process allowed us to slowly migrate a consistent testing > strategy into the old code. It has been more cost effective than a > whole sale restart. > > Here's how we usually set up tests structure: > > test/ > smoke/ > regression/ > stress/ > security/ > > Smoke tests are those that absolutely must pass each build. phpESP > doesn't really have a "build" process (IMO, it should), but the type > of tests in this category are "config file exists, is readable, and > parseable by PHP", "database can be accessed and has good schema", > "web directory exists and is readable by the web server", etc. > > Regression tests are every thing else: bug fix tests, new code tests, etc. > > Stress tests are a particular breed of regression tests, in that > they're designed to wallop the web UI or DB with a large number of > requests to exercise the code under significant duress and make sure > it meets its performance/responsiveness requirements. > > Security tests, also a breed of regression, specifically try to pry > open the application: SQL injection attacks, man in the middle > attacks, brute-force or dictionary attacks, etc. > > Then as new scenarios come up, we drop unit tests into the appropriate > spot. We exercise the software with our build tool phing, such as: > "phing build", "phing regression", "phing stress", and "phing penetrate" > > We definitely didn't get there overnight. It's been a steady task of > adding in tests. Over time, it becomes a natural reaction of the > developer and a significant suite is developed. We just had to draw a > line in the sand and exclaim "Today, we incorporate tests." > > > So, leaders of phpESP: what is the testing policy? Do we incorporate > slowly as legacy evolves, or start fresh? I'm in the incorporate > slowly camp, but maybe that's because I never worked for Netscape: > http://www.joelonsoftware.com/articles/fog0000000069.html > > > bishop > > > Quoting Matthew Gregg <mat...@gm...>: > > > Unit testing sounds like a great thing to add. My concern is the work > > to add and maintain would be significant given phpESP legacy code base. > > Perhaps more work than starting over using an off the shelf framework > > that supports proper unit testing. > > > > Thoughts? > > > > On Sat, 2008-04-19 at 12:52 -0400, Bishop Bettini wrote: > > ...snip... > >> Now, a bigger question: any votes on adding a unit test framework to > >> phpESP so that this bug can be installed as a test case? (We use > >> phpunit extensively on our other products, and I recommend it.) One > >> problem is that the phpESP code is a bit resilient to unit testing: > >> the UI, business logic, and DB code are all wrapped into one. I > >> suppose it could be done by munging POST, including the file, and > >> checking the results both in the DB and a regex/DOM parse of the > >> output buffer. Thoughts? > > -- Matthew Gregg <mat...@gm...> |
From: Bishop B. <ph...@id...> - 2008-04-19 22:03:07
|
Matthew raises a very good point. In one of our products, we had a similar hurdle: lots of very old code (early PHP 4 based) that was rapidly produced in a not-so-modular fashion. Wholesale rewriting, while desired, was not feasible given the clients using the code and the sheer number of lines to change. To incorporate standardized testing, we first defined exactly what we wanted tested (ie, specific areas that were prone to changes or known to be problematic) and how we wanted to test (ie, unit, stress, penetration, and coverage testing). Then, we settled on a robust framework -- phpunit2 -- that would grow with us in that, and other, products. Finally, we made two rules: 1. All new code SHOULD conform to our testing policy 2. All bugs MUST get a test case to expose them and to prove they have been fixed (Interpret MUST and SHOULD according to RFC2119) That process allowed us to slowly migrate a consistent testing strategy into the old code. It has been more cost effective than a whole sale restart. Here's how we usually set up tests structure: test/ smoke/ regression/ stress/ security/ Smoke tests are those that absolutely must pass each build. phpESP doesn't really have a "build" process (IMO, it should), but the type of tests in this category are "config file exists, is readable, and parseable by PHP", "database can be accessed and has good schema", "web directory exists and is readable by the web server", etc. Regression tests are every thing else: bug fix tests, new code tests, etc. Stress tests are a particular breed of regression tests, in that they're designed to wallop the web UI or DB with a large number of requests to exercise the code under significant duress and make sure it meets its performance/responsiveness requirements. Security tests, also a breed of regression, specifically try to pry open the application: SQL injection attacks, man in the middle attacks, brute-force or dictionary attacks, etc. Then as new scenarios come up, we drop unit tests into the appropriate spot. We exercise the software with our build tool phing, such as: "phing build", "phing regression", "phing stress", and "phing penetrate" We definitely didn't get there overnight. It's been a steady task of adding in tests. Over time, it becomes a natural reaction of the developer and a significant suite is developed. We just had to draw a line in the sand and exclaim "Today, we incorporate tests." So, leaders of phpESP: what is the testing policy? Do we incorporate slowly as legacy evolves, or start fresh? I'm in the incorporate slowly camp, but maybe that's because I never worked for Netscape: http://www.joelonsoftware.com/articles/fog0000000069.html bishop Quoting Matthew Gregg <mat...@gm...>: > Unit testing sounds like a great thing to add. My concern is the work > to add and maintain would be significant given phpESP legacy code base. > Perhaps more work than starting over using an off the shelf framework > that supports proper unit testing. > > Thoughts? > > On Sat, 2008-04-19 at 12:52 -0400, Bishop Bettini wrote: > ...snip... >> Now, a bigger question: any votes on adding a unit test framework to >> phpESP so that this bug can be installed as a test case? (We use >> phpunit extensively on our other products, and I recommend it.) One >> problem is that the phpESP code is a bit resilient to unit testing: >> the UI, business logic, and DB code are all wrapped into one. I >> suppose it could be done by munging POST, including the file, and >> checking the results both in the DB and a regex/DOM parse of the >> output buffer. Thoughts? -- Bishop Bettini ideacode, Inc. (main) +1 919 341 5170 / (fax) +1 919 521 4100 Visit us on the web at: ideacode.com Professional software research and development reviewmysoftware.com Improve sales! Review your software before you release bytejar.com Solutions to those annoying development problems |
From: Matthew G. <mat...@gm...> - 2008-04-19 21:00:55
|
Unit testing sounds like a great thing to add. My concern is the work to add and maintain would be significant given phpESP legacy code base. Perhaps more work than starting over using an off the shelf framework that supports proper unit testing. Thoughts? On Sat, 2008-04-19 at 12:52 -0400, Bishop Bettini wrote: ...snip... > Now, a bigger question: any votes on adding a unit test framework to > phpESP so that this bug can be installed as a test case? (We use > phpunit extensively on our other products, and I recommend it.) One > problem is that the phpESP code is a bit resilient to unit testing: > the UI, business logic, and DB code are all wrapped into one. I > suppose it could be done by munging POST, including the file, and > checking the results both in the DB and a regex/DOM parse of the > output buffer. Thoughts? > > bishop > -- Matthew Gregg <mat...@gm...> |
From: Bishop B. <ph...@id...> - 2008-04-19 16:52:16
|
Hi Franky, Quoting Franky Van Liedekerke <lie...@te...>: >> Can you debrief on the issue(s) here? > > well, it's like I said: I never tested save/resume before, so it might > be that the bugs were new due to session variables for the response-id > or not ... (the bug was that resuming didn't work, you always had a > new response session). Anyway, I got it fixed :) I believe the bug's there (:>), but it doesn't sound like it was in 2.0.2. I say that because I'm very actively using 2.0.2, and no user has reported a problem with resume, nor did our extensive testing reveal an issue. I'll do a diff in the trees to see what changed, and if 2.0.2 is impacted. > I thought this to be self-explanatory: due to the _addslashes on eg. > the password, the password variable was never empty, even if you didn't > fill it in (because you were changing an existing user). And so, eg. in > admrespondent.inc, upon submit (old code): > > $u_password = _addslashes($_POST['password']); > > ==> this would cause $u_password to be "''" (meaning a string with two > single quotes) when you left the field empty in the html form. > > Further down the test is made whether or not the password was empty: > if (!empty($u_password)) > $u_password = "password=".db_crypt($u_password).","; > and this would then cause a change of the password to "''" in the db > when the UPDATE statement just below that line was executed (it happened > to me) It was explanatory, but I hadn't heard a problem report from our admin users -- undoubtedly because they only change the password when they visit those affected screens -- they have no business case to change any other data, as that's bulk loaded from a registrar database. I'll merge the change in -- thanks for noticing this. Now, a bigger question: any votes on adding a unit test framework to phpESP so that this bug can be installed as a test case? (We use phpunit extensively on our other products, and I recommend it.) One problem is that the phpESP code is a bit resilient to unit testing: the UI, business logic, and DB code are all wrapped into one. I suppose it could be done by munging POST, including the file, and checking the results both in the DB and a regex/DOM parse of the output buffer. Thoughts? bishop -- Bishop Bettini ideacode, Inc. (main) +1 919 341 5170 / (fax) +1 919 521 4100 Visit us on the web at: ideacode.com Professional software research and development reviewmysoftware.com Improve sales! Review your software before you release bytejar.com Solutions to those annoying development problems |
From: Franky V. L. <lie...@te...> - 2008-04-19 16:31:01
|
On Sat, 19 Apr 2008 11:59:28 -0400 Bishop Bettini <ph...@id...> wrote: > Hi Franky, > > Quoting Franky Van Liedekerke <lie...@te...>: > > > - Fixed some issues with save/resume surveys (I have to admit: I > > never tested this before, so how old these bugs were, I have no > > idea) > > Can you debrief on the issue(s) here? well, it's like I said: I never tested save/resume before, so it might be that the bugs were new due to session variables for the response-id or not ... (the bug was that resuming didn't work, you always had a new response session). Anyway, I got it fixed :) Come to think of it, it might even be that there's still an issue there with the url presented in the page when you save the survey. iirc the survey id wasn't always passed to the url ... I still need to double check that as well. Not too serious there, but still ... that slipped my mind ... > > - Changing a user or designer caused his password to become empty, > > not very wise (who knows how long this has been in ...). This was > > due to using _addslashes on all entered data and only checking > > emptyness afterwards, but when a variable contains just quotes, it > > is no longer empty ... this was probably already in 2.0.2 as well. > > I have not noticed this in 2.0.2 -- can you elaborate? I thought this to be self-explanatory: due to the _addslashes on eg. the password, the password variable was never empty, even if you didn't fill it in (because you were changing an existing user). And so, eg. in admrespondent.inc, upon submit (old code): $u_password = _addslashes($_POST['password']); ==> this would cause $u_password to be "''" (meaning a string with two single quotes) when you left the field empty in the html form. Further down the test is made whether or not the password was empty: if (!empty($u_password)) $u_password = "password=".db_crypt($u_password).","; and this would then cause a change of the password to "''" in the db when the UPDATE statement just below that line was executed (it happened to me) Franky |
From: Bishop B. <ph...@id...> - 2008-04-19 15:59:33
|
Hi Franky, Quoting Franky Van Liedekerke <lie...@te...>: > - Fixed some issues with save/resume surveys (I have to admit: I never > tested this before, so how old these bugs were, I have no idea) Can you debrief on the issue(s) here? > - Changing a user or designer caused his password to become empty, not > very wise (who knows how long this has been in ...). This was due to > using _addslashes on all entered data and only checking emptyness > afterwards, but when a variable contains just quotes, it is no longer > empty ... this was probably already in 2.0.2 as well. I have not noticed this in 2.0.2 -- can you elaborate? regards, bishop -- Bishop Bettini ideacode, Inc. (main) +1 919 341 5170 / (fax) +1 919 521 4100 Visit us on the web at: ideacode.com Professional software research and development reviewmysoftware.com Improve sales! Review your software before you release bytejar.com Solutions to those annoying development problems |
From: Franky V. L. <lie...@te...> - 2008-04-19 13:21:27
|
Hi all, in order to fix some bugs with 2.1.0, 2.1.1 has been released. No DB changes have been made. From the changelog: - Fixed some issues with save/resume surveys (I have to admit: I never tested this before, so how old these bugs were, I have no idea) - Fresh installations didn't have initial data due to an xml schema mismatch, easy to fix but inconvenient. For those curious on how I fixed this: just changed "0.2" to "0.3" in scripts/db/data.xml. That'll teach me to update the adodb-schema class and not updating all versions ... - Changing a user or designer caused his password to become empty, not very wise (who knows how long this has been in ...). This was due to using _addslashes on all entered data and only checking emptyness afterwards, but when a variable contains just quotes, it is no longer empty ... this was probably already in 2.0.2 as well. To update: just replace the current phpESP dir with the new one and log in to the admin section. Enjoy the update! Franky |
From: SourceForge.net <no...@so...> - 2008-04-18 10:43:44
|
Bugs item #1945462, was opened at 2008-04-18 09:48 Message generated for change (Comment added) made by arturmail You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=108956&aid=1945462&group_id=8956 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: SQL Group: v2.0.2 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Artur Kusmierek (arturmail) Assigned to: Nobody/Anonymous (nobody) Summary: incorrectly data when exporting Initial Comment: I've noticed that exported data from larger surveys are different from data generated by "View Results from a Survey" and data received via submission e-mails! The only way to get the proper data from MySql database is to export data directly from MySql database (i.e. phpMyAdmin) and sort them in i.e. MS Excel firstly by "response_id" field and secondly by "choice_id". It is not an issue when the survey has 1 or 2 to answers (I can't repeat this error on small group of answered surveys). Maybe it is connected with save survey sessions (getting back later to finish, the "choice_id" field is not set one after another from one person's answer). -- Regards, Artur ---------------------------------------------------------------------- >Comment By: Artur Kusmierek (arturmail) Date: 2008-04-18 12:43 Message: Logged In: YES user_id=2066340 Originator: YES I tried to attach screenshots as a file but looks messy to me. This particual responce id is 91. I'm not an expert but in simple words for me it looks like when tha data is gathering via www and e-mail it is sorted by responce_id and choice_id (don't sure about question_id if it can get tricky). But when the data is being exported it is sorted only by responce_id and question_id (not choice_id) which causes unsorted answers within particular questions. File Added: Rysunek1.jpg ---------------------------------------------------------------------- Comment By: Artur Kusmierek (arturmail) Date: 2008-04-18 12:00 Message: Logged In: YES user_id=2066340 Originator: YES File Added: email.jpg ---------------------------------------------------------------------- Comment By: Artur Kusmierek (arturmail) Date: 2008-04-18 11:59 Message: Logged In: YES user_id=2066340 Originator: YES File Added: www.jpg ---------------------------------------------------------------------- Comment By: Franky Van Liedekerke (liedekef) Date: 2008-04-18 09:55 Message: Logged In: YES user_id=109671 Originator: NO Hi, could you tell me what you mean by differences? An example would be great to track down the problem ... I will see what the save survey sessions do for now and see if I can detect a problem there. Franky ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=108956&aid=1945462&group_id=8956 |
From: SourceForge.net <no...@so...> - 2008-04-18 10:00:05
|
Bugs item #1945462, was opened at 2008-04-18 09:48 Message generated for change (Comment added) made by arturmail You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=108956&aid=1945462&group_id=8956 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: SQL Group: v2.0.2 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Artur Kusmierek (arturmail) Assigned to: Nobody/Anonymous (nobody) Summary: incorrectly data when exporting Initial Comment: I've noticed that exported data from larger surveys are different from data generated by "View Results from a Survey" and data received via submission e-mails! The only way to get the proper data from MySql database is to export data directly from MySql database (i.e. phpMyAdmin) and sort them in i.e. MS Excel firstly by "response_id" field and secondly by "choice_id". It is not an issue when the survey has 1 or 2 to answers (I can't repeat this error on small group of answered surveys). Maybe it is connected with save survey sessions (getting back later to finish, the "choice_id" field is not set one after another from one person's answer). -- Regards, Artur ---------------------------------------------------------------------- >Comment By: Artur Kusmierek (arturmail) Date: 2008-04-18 12:00 Message: Logged In: YES user_id=2066340 Originator: YES File Added: email.jpg ---------------------------------------------------------------------- Comment By: Artur Kusmierek (arturmail) Date: 2008-04-18 11:59 Message: Logged In: YES user_id=2066340 Originator: YES File Added: www.jpg ---------------------------------------------------------------------- Comment By: Franky Van Liedekerke (liedekef) Date: 2008-04-18 09:55 Message: Logged In: YES user_id=109671 Originator: NO Hi, could you tell me what you mean by differences? An example would be great to track down the problem ... I will see what the save survey sessions do for now and see if I can detect a problem there. Franky ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=108956&aid=1945462&group_id=8956 |
From: SourceForge.net <no...@so...> - 2008-04-18 09:59:33
|
Bugs item #1945462, was opened at 2008-04-18 09:48 Message generated for change (Comment added) made by arturmail You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=108956&aid=1945462&group_id=8956 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: SQL Group: v2.0.2 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Artur Kusmierek (arturmail) Assigned to: Nobody/Anonymous (nobody) Summary: incorrectly data when exporting Initial Comment: I've noticed that exported data from larger surveys are different from data generated by "View Results from a Survey" and data received via submission e-mails! The only way to get the proper data from MySql database is to export data directly from MySql database (i.e. phpMyAdmin) and sort them in i.e. MS Excel firstly by "response_id" field and secondly by "choice_id". It is not an issue when the survey has 1 or 2 to answers (I can't repeat this error on small group of answered surveys). Maybe it is connected with save survey sessions (getting back later to finish, the "choice_id" field is not set one after another from one person's answer). -- Regards, Artur ---------------------------------------------------------------------- >Comment By: Artur Kusmierek (arturmail) Date: 2008-04-18 11:59 Message: Logged In: YES user_id=2066340 Originator: YES File Added: www.jpg ---------------------------------------------------------------------- Comment By: Franky Van Liedekerke (liedekef) Date: 2008-04-18 09:55 Message: Logged In: YES user_id=109671 Originator: NO Hi, could you tell me what you mean by differences? An example would be great to track down the problem ... I will see what the save survey sessions do for now and see if I can detect a problem there. Franky ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=108956&aid=1945462&group_id=8956 |
From: SourceForge.net <no...@so...> - 2008-04-18 07:55:38
|
Bugs item #1945462, was opened at 2008-04-18 09:48 Message generated for change (Comment added) made by liedekef You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=108956&aid=1945462&group_id=8956 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: SQL Group: v2.0.2 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Artur Kusmierek (arturmail) Assigned to: Nobody/Anonymous (nobody) Summary: incorrectly data when exporting Initial Comment: I've noticed that exported data from larger surveys are different from data generated by "View Results from a Survey" and data received via submission e-mails! The only way to get the proper data from MySql database is to export data directly from MySql database (i.e. phpMyAdmin) and sort them in i.e. MS Excel firstly by "response_id" field and secondly by "choice_id". It is not an issue when the survey has 1 or 2 to answers (I can't repeat this error on small group of answered surveys). Maybe it is connected with save survey sessions (getting back later to finish, the "choice_id" field is not set one after another from one person's answer). -- Regards, Artur ---------------------------------------------------------------------- >Comment By: Franky Van Liedekerke (liedekef) Date: 2008-04-18 09:55 Message: Logged In: YES user_id=109671 Originator: NO Hi, could you tell me what you mean by differences? An example would be great to track down the problem ... I will see what the save survey sessions do for now and see if I can detect a problem there. Franky ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=108956&aid=1945462&group_id=8956 |
From: SourceForge.net <no...@so...> - 2008-04-18 07:48:41
|
Bugs item #1945462, was opened at 2008-04-18 09:48 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=108956&aid=1945462&group_id=8956 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: SQL Group: v2.0.2 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Artur Kusmierek (arturmail) Assigned to: Nobody/Anonymous (nobody) Summary: incorrectly data when exporting Initial Comment: I've noticed that exported data from larger surveys are different from data generated by "View Results from a Survey" and data received via submission e-mails! The only way to get the proper data from MySql database is to export data directly from MySql database (i.e. phpMyAdmin) and sort them in i.e. MS Excel firstly by "response_id" field and secondly by "choice_id". It is not an issue when the survey has 1 or 2 to answers (I can't repeat this error on small group of answered surveys). Maybe it is connected with save survey sessions (getting back later to finish, the "choice_id" field is not set one after another from one person's answer). -- Regards, Artur ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=108956&aid=1945462&group_id=8956 |
From: Matthew G. <mat...@gm...> - 2008-04-16 16:56:16
|
We are just about ready to begin using the translation services on Launchpad. If you are a phpESP translator or would like to help keep translations up to date. Please head over to http://launchpad.net/ sign up for an account. Then send me your Launchpad userid and language you can translate, so I can add you to the phpESP translator group. Once you have been added you can contribute/update translations here: https://translations.launchpad.net/phpesp/trunk/+pots/phpesp Thanks. |
From: SourceForge.net <no...@so...> - 2008-04-15 11:39:57
|
Feature Requests item #902808, was opened at 2004-02-23 11:42 Message generated for change (Comment added) made by bishopb You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=358956&aid=902808&group_id=8956 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Closed Priority: 5 Private: No Submitted By: Jeff (skrysakj) Assigned to: Nobody/Anonymous (nobody) Summary: Stop multiple admissions from same IP Initial Comment: For public surveys, have an option whereby the same person from the same IP address cannot submit more than once. This is NOT a perfect solution for a common problem, but having the option may be nice. ---------------------------------------------------------------------- >Comment By: bishop (bishopb) Date: 2008-04-15 07:40 Message: Logged In: YES user_id=1982963 Originator: NO Additionally, (and similarly to portrower8's comment) you can force users to authenticate, set the survey to non-public, and set the response count to 1. That effectively prevents duplicate submissions, especially when used with the dashboard that stops them from going to the unavailable survey. ---------------------------------------------------------------------- Comment By: Franky Van Liedekerke (liedekef) Date: 2008-04-15 04:28 Message: Logged In: YES user_id=109671 Originator: NO The cookie feature does this now, we never block from an ip. Again: this is not perfect as well, but works for the common man. Franky ---------------------------------------------------------------------- Comment By: Matthew Gregg (greggmc) Date: 2005-07-19 14:01 Message: Logged In: YES user_id=14116 That should have said... The IP is already logged for public surveys. ---------------------------------------------------------------------- Comment By: Matthew Gregg (greggmc) Date: 2005-07-19 13:58 Message: Logged In: YES user_id=14116 If the IP is already logged for public surveys. The IP shows up when you export the survey. ---------------------------------------------------------------------- Comment By: Harry Mangalam (mangalam) Date: 2005-07-19 13:54 Message: Logged In: YES user_id=4526 I would add a request that the IP's just be logged and included in the analysis/report. I have to do this manually via the apache logs, and it's not a huge problem, but it would certainly be easier if it was a built-in option. ---------------------------------------------------------------------- Comment By: Matthew Gregg (greggmc) Date: 2004-05-10 08:29 Message: Logged In: YES user_id=14116 Multiple submissions blocking should be configurable. If the survey is deployed in a controlled env. where it is known that IP's are unique then an IP block would be an option. ---------------------------------------------------------------------- Comment By: Kon Angelopoulos (angek) Date: 2004-05-10 02:45 Message: Logged In: YES user_id=198398 What would happen in the case that the user connects to the survey via a proxy? the ip that would be captured would be of the proxy and ends up creating problems eg. having blocked access to the survey for all others using the same proxy (eg from the same organisation etc). How about a snippet of code that disbales the submit button once the survey has been submitted. I know this isn't the best solution either as people can click the back button on their browser several times and keep reposting the results however it should suffice for the average user and in fact I have this implemented on my system and have had very few problems with multiple submissions. ---------------------------------------------------------------------- Comment By: Kon Angelopoulos (angek) Date: 2004-05-10 02:44 Message: Logged In: YES user_id=198398 What would happen in the case that the user connects to the survey via a proxy? the ip that would be captured would be of the proxy and ends up creating problems eg. having blocked access to the survey for all others using the same proxy (eg from the same organisation etc). How about a snippet of code that disbales the submit button once the survey has been submitted. I know this isn't the best solution either as people can click the back button on their browser several times and keep reposting the results however it should suffice for the average user and in fact I have this implemented on my system and have had very few problems with multiple submissions. ---------------------------------------------------------------------- Comment By: Kon Angelopoulos (angek) Date: 2004-05-10 02:43 Message: Logged In: YES user_id=198398 What would happen in the case that the user connects to the survey via a proxy? the ip that would be captured would be of the proxy and ends up creating problems eg. having blocked access to the survey for all others using the same proxy (eg from the same organisation etc). How about a snippet of code that disbales the submit button once the survey has been submitted. I know this isn't the best solution either as people can click the back button on their browser several times and keep reposting the results however it should suffice for the average user and in fact I have this implemented on my system and have had very few problems with multiple submissions. ---------------------------------------------------------------------- Comment By: Kon Angelopoulos (angek) Date: 2004-05-10 02:42 Message: Logged In: YES user_id=198398 What would happen in the case that the user connects to the survey via a proxy? the ip that would be captured would be of the proxy and ends up creating problems eg. having blocked access to the survey for all others using the same proxy (eg from the same organisation etc). How about a snippet of code that disbales the submit button once the survey has been submitted. I know this isn't the best solution either as people can click the back button on their browser several times and keep reposting the results however it should suffice for the average user and in fact I have this implemented on my system and have had very few problems with multiple submissions. ---------------------------------------------------------------------- Comment By: portrower8 (portrower8) Date: 2004-04-30 00:51 Message: Logged In: YES user_id=1032335 What about asking respondants for last four digits of their social...or their name or something... ? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=358956&aid=902808&group_id=8956 |
From: SourceForge.net <no...@so...> - 2008-04-15 08:30:55
|
Feature Requests item #999821, was opened at 2004-07-29 02:06 Message generated for change (Comment added) made by liedekef You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=358956&aid=999821&group_id=8956 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: gui Group: None Status: Open Priority: 4 Private: No Submitted By: Matthew Gregg (greggmc) Assigned to: Nobody/Anonymous (nobody) Summary: required questions notification Initial Comment: Suggestion from one of our users. Posting here for reference. ---- When survey has required fields that aren't completed when the survey is submitted........ Instead of citing the full questions, couldn't you simply tell which answers are missing by listing the question numbers (like Question 2, 6, 7) It would gain a lot in legibility, and you can scroll down immediately to the question numbers indicated... Since you're fixing this, wa red frame (+ faded red background) around the warning text "You are missing the following required questions: " + the list of questions numbers would make this tool, I'd say, close to perfection... ---------------------------------------------------------------------- >Comment By: Franky Van Liedekerke (liedekef) Date: 2008-04-15 10:31 Message: Logged In: YES user_id=109671 Originator: NO Since most the times the questions aren't numbered, this is not a good idea. Maybe another way would be to indicate the missing questions in red background or so ... ---------------------------------------------------------------------- Comment By: Yunus KALDIRIM (colderthanice) Date: 2005-05-25 15:08 Message: Logged In: YES user_id=1225311 i do request this ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=358956&aid=999821&group_id=8956 |
From: SourceForge.net <no...@so...> - 2008-04-15 08:28:41
|
Feature Requests item #908425, was opened at 2004-03-02 18:07 Message generated for change (Comment added) made by liedekef You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=358956&aid=908425&group_id=8956 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None >Status: Closed Priority: 5 Private: No Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: Cookie control Initial Comment: As an alternative to the IP-based method of reducing multiple posts by the same person (which I think tends to eliminate too many honest users), I suggest an optional cookie-based method. Although not impossible to circumvent, it does discourage casual cheating. ---------------------------------------------------------------------- >Comment By: Franky Van Liedekerke (liedekef) Date: 2008-04-15 10:28 Message: Logged In: YES user_id=109671 Originator: NO already in the latest version ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=358956&aid=908425&group_id=8956 |
From: SourceForge.net <no...@so...> - 2008-04-15 08:28:20
|
Feature Requests item #902808, was opened at 2004-02-23 17:42 Message generated for change (Comment added) made by liedekef You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=358956&aid=902808&group_id=8956 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None >Status: Closed Priority: 5 Private: No Submitted By: Jeff (skrysakj) Assigned to: Nobody/Anonymous (nobody) Summary: Stop multiple admissions from same IP Initial Comment: For public surveys, have an option whereby the same person from the same IP address cannot submit more than once. This is NOT a perfect solution for a common problem, but having the option may be nice. ---------------------------------------------------------------------- >Comment By: Franky Van Liedekerke (liedekef) Date: 2008-04-15 10:28 Message: Logged In: YES user_id=109671 Originator: NO The cookie feature does this now, we never block from an ip. Again: this is not perfect as well, but works for the common man. Franky ---------------------------------------------------------------------- Comment By: Matthew Gregg (greggmc) Date: 2005-07-19 20:01 Message: Logged In: YES user_id=14116 That should have said... The IP is already logged for public surveys. ---------------------------------------------------------------------- Comment By: Matthew Gregg (greggmc) Date: 2005-07-19 19:58 Message: Logged In: YES user_id=14116 If the IP is already logged for public surveys. The IP shows up when you export the survey. ---------------------------------------------------------------------- Comment By: Harry Mangalam (mangalam) Date: 2005-07-19 19:54 Message: Logged In: YES user_id=4526 I would add a request that the IP's just be logged and included in the analysis/report. I have to do this manually via the apache logs, and it's not a huge problem, but it would certainly be easier if it was a built-in option. ---------------------------------------------------------------------- Comment By: Matthew Gregg (greggmc) Date: 2004-05-10 14:29 Message: Logged In: YES user_id=14116 Multiple submissions blocking should be configurable. If the survey is deployed in a controlled env. where it is known that IP's are unique then an IP block would be an option. ---------------------------------------------------------------------- Comment By: Kon Angelopoulos (angek) Date: 2004-05-10 08:45 Message: Logged In: YES user_id=198398 What would happen in the case that the user connects to the survey via a proxy? the ip that would be captured would be of the proxy and ends up creating problems eg. having blocked access to the survey for all others using the same proxy (eg from the same organisation etc). How about a snippet of code that disbales the submit button once the survey has been submitted. I know this isn't the best solution either as people can click the back button on their browser several times and keep reposting the results however it should suffice for the average user and in fact I have this implemented on my system and have had very few problems with multiple submissions. ---------------------------------------------------------------------- Comment By: Kon Angelopoulos (angek) Date: 2004-05-10 08:44 Message: Logged In: YES user_id=198398 What would happen in the case that the user connects to the survey via a proxy? the ip that would be captured would be of the proxy and ends up creating problems eg. having blocked access to the survey for all others using the same proxy (eg from the same organisation etc). How about a snippet of code that disbales the submit button once the survey has been submitted. I know this isn't the best solution either as people can click the back button on their browser several times and keep reposting the results however it should suffice for the average user and in fact I have this implemented on my system and have had very few problems with multiple submissions. ---------------------------------------------------------------------- Comment By: Kon Angelopoulos (angek) Date: 2004-05-10 08:43 Message: Logged In: YES user_id=198398 What would happen in the case that the user connects to the survey via a proxy? the ip that would be captured would be of the proxy and ends up creating problems eg. having blocked access to the survey for all others using the same proxy (eg from the same organisation etc). How about a snippet of code that disbales the submit button once the survey has been submitted. I know this isn't the best solution either as people can click the back button on their browser several times and keep reposting the results however it should suffice for the average user and in fact I have this implemented on my system and have had very few problems with multiple submissions. ---------------------------------------------------------------------- Comment By: Kon Angelopoulos (angek) Date: 2004-05-10 08:42 Message: Logged In: YES user_id=198398 What would happen in the case that the user connects to the survey via a proxy? the ip that would be captured would be of the proxy and ends up creating problems eg. having blocked access to the survey for all others using the same proxy (eg from the same organisation etc). How about a snippet of code that disbales the submit button once the survey has been submitted. I know this isn't the best solution either as people can click the back button on their browser several times and keep reposting the results however it should suffice for the average user and in fact I have this implemented on my system and have had very few problems with multiple submissions. ---------------------------------------------------------------------- Comment By: portrower8 (portrower8) Date: 2004-04-30 06:51 Message: Logged In: YES user_id=1032335 What about asking respondants for last four digits of their social...or their name or something... ? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=358956&aid=902808&group_id=8956 |
From: SourceForge.net <no...@so...> - 2008-04-15 08:26:38
|
Feature Requests item #998816, was opened at 2004-07-27 17:56 Message generated for change (Settings changed) made by liedekef You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=358956&aid=998816&group_id=8956 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Priority: 5 Private: No Submitted By: Jay Luker (lbjay) >Assigned to: Franky Van Liedekerke (liedekef) Summary: handler.php should use $sid and/or $sname Initial Comment: First off, phpESP is excellent. Thanks for the code. This should be a fairly simple request. I have multiple sites using phpESP across multiple servers, some dev, some production. The dev and production servers use different dbs. Since my $sid for the same survey can differ from the dev to the production dbs, it would be nice to have the handler.php script pick up a variable defining the survey name in addition to, instead of, in the absence of, etc. the $sid. Thanks. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=358956&aid=998816&group_id=8956 |
From: Matthew G. <mat...@gm...> - 2008-04-12 19:04:40
|
Official releases should only be distributed from SF. On Sat, 2008-04-12 at 15:35 +0200, Franky Van Liedekerke wrote: > Hi, > > either use sourceforge for this: > http://sourceforge.net/project/showfiles.php?group_id=8956 > > Or get it from my webpage: > http://www.e-dynamics.be/programs/phpesp/phpESP-2.1.0.tgz > > Franky > > On Sat, 12 Apr 2008 09:26:07 -0400 > Geof Collis <gc...@ne...> wrote: > > > Hi Frankie > > > > Got a quick link to the download page? > > > > cheers > > > > GeofA > > > > t 08:15 AM 4/12/2008, Franky Van Liedekerke wrote: > > >Hi all, > > > > > >the latest and best of phpESP has been released: version 2.1.0. > > >Many things have changed, but the most changing one is the split of > > >the config file in 3 seperate files, allowing easier updates (see the > > >CHANGELOG file). > > > > > > >From the changelog: > > > > > >- Dashboard implementation (by Bishop Bettini) > > > > > >- start/stop date for a survey (by Bishop Bettini) > > > > > >- A conditional question resulted in a "non-required" for the > > >question it depends on, this limit has been removed. > > > > > >- You can now do authenticated ldap binds when searching for the uid, > > >some LDAP servers need this (is more secure than anonymous binds > > >anyway) > > > > > >- A default config file has been added > > >(admin/phpESP.ini.php.default), your own changes should go into > > >admin/phpESP.ini.php. The advantage is that new options can be added > > >to the default file and you don't need to change anything to your > > >own config file. Also a fixed part has been added > > >(admin/phpESP.ini.php.fixed) containing values that should not be > > >changed. The sequence is: require (phpESP.ini.php.default); ==> > > >defaults, gets overwritten with every new release require > > >(phpESP.ini.php); ==> your own values, never gets overwritten > > >require (phpESP.ini.php.fixed); ==> fixed parts, you can change > > >these, but they get overwritten with every new release > > > > > >- Web based updates and web based installs are now possible, no more > > >manually entering sql statements in the db > > > > > >- Switching/changing database table prefixes is now possible > > > > > >- An answer to a question of type textbox, essay or numerical can now > > >be required to be unique > > > > > >Any feedback is welcome. Enjoy! > > > > > >Franky > > > > > >------------------------------------------------------------------------- > > >This SF.net email is sponsored by the 2008 JavaOne(SM) Conference > > >Don't miss this year's exciting event. There's still time to save > > >$100. Use priority code J8TL2D2. > > >http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone > > >_______________________________________________ > > >phpESP-general mailing list > > >php...@li... > > >https://lists.sourceforge.net/lists/listinfo/phpesp-general > > > > Editor > > Accessibility News > > www.accessibilitynews.ca > > ---- > > Badeyes Design & Consulting > > Specializing in Accessible Web Design > > Phone: 705-357-2117 > > Fax: 705-357-1833 > > Url: http://www.badeyes.com > > > > > > > > ------------------------------------------------------------------------- > This SF.net email is sponsored by the 2008 JavaOne(SM) Conference > Don't miss this year's exciting event. There's still time to save $100. > Use priority code J8TL2D2. > http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone > _______________________________________________ > phpESP-devel mailing list > php...@li... > https://lists.sourceforge.net/lists/listinfo/phpesp-devel -- Matthew Gregg <mat...@gm...> |
From: SourceForge.net <no...@so...> - 2008-04-12 14:51:08
|
Feature Requests item #1868765, was opened at 2008-01-10 19:40 Message generated for change (Comment added) made by liedekef You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=358956&aid=1868765&group_id=8956 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: survey format Group: None >Status: Closed Priority: 5 Private: No Submitted By: Nobody/Anonymous (nobody) Assigned to: Franky Van Liedekerke (liedekef) Summary: DB Tables naming convention Initial Comment: Add phpesp_ to all of the tables so I can install this into an existing database and ensure I won't have any conflicting tables already in the table. My Provider only provides one mysql db and I have wordpress and drupal installed in the DB. ---------------------------------------------------------------------- >Comment By: Franky Van Liedekerke (liedekef) Date: 2008-04-12 16:51 Message: Logged In: YES user_id=109671 Originator: NO This has been fixed in the latest release. Franky ---------------------------------------------------------------------- Comment By: Matthew Gregg (greggmc) Date: 2008-03-26 21:55 Message: Logged In: YES user_id=14116 Originator: NO If your 2.0.2->2.0.3 script does the renaming of existing tables then that is what I mean by migrating and we are good. ---------------------------------------------------------------------- Comment By: Franky Van Liedekerke (liedekef) Date: 2008-03-26 21:17 Message: Logged In: YES user_id=109671 Originator: NO Could you elaborate? If I adjust the update script for 2.0.2->2.0.3 to have the renaming statements in them, and change admin/phpesp.ini.php accordingly, isn't that enough? Anyway, I'm thinking this should all be more automatic ... like a web itf for when db updates need to happen, so you don't need to do this by hand ... Franky ---------------------------------------------------------------------- Comment By: Matthew Gregg (greggmc) Date: 2008-03-26 20:52 Message: Logged In: YES user_id=14116 Originator: NO It's more involved than renaming current tables, it will need to be a "migration" for existing tables. ---------------------------------------------------------------------- Comment By: Franky Van Liedekerke (liedekef) Date: 2008-03-26 20:45 Message: Logged In: YES user_id=109671 Originator: NO A reasonable request ... for the next release this can go in, since it only involves renaming the current tables ... Franky ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2008-01-10 22:57 Message: Logged In: NO bishop <ph...@id...> Doesn't the $DB_PREFIX configuration variable address this request? (Of course, you have to go through and manually update the SQL to reflect that prefix.) Or is the request to come out of the box with a phpesp_ prefix, so that the end user doesn't have to care? That sounds like a reasonable default to me, as people who need it will want it and people who don't need it won't care. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=358956&aid=1868765&group_id=8956 |