*** Joins: dhx1 (~anonymous@60-242-108-164.static.tpgi.com.au) | 02:33 | |
*** Joins: Cupertino (~Cupez@unaffiliated/cupertino) | 02:34 | |
*** Quits: dhx1 (~anonymous@60-242-108-164.static.tpgi.com.au) (Ping timeout: 276 seconds) | 02:46 | |
*** Joins: dhx1 (~anonymous@60-242-108-164.static.tpgi.com.au) | 02:54 | |
*** Joins: cerf (~quassel@mcl71-3-78-241-52-239.fbx.proxad.net) | 03:06 | |
*** Joins: asm89 (~asm89@5ED18FE0.cm-7-2c.dynamic.ziggo.nl) | 03:15 | |
*** Quits: asm89 (~asm89@5ED18FE0.cm-7-2c.dynamic.ziggo.nl) (Changing host) | 03:15 | |
*** Joins: asm89 (~asm89@unaffiliated/asm89) | 03:15 | |
*** Quits: asm89 (~asm89@unaffiliated/asm89) (Ping timeout: 276 seconds) | 03:34 | |
*** Joins: asm89 (~asm89@unaffiliated/asm89) | 03:44 | |
*** Quits: dhx1 (~anonymous@60-242-108-164.static.tpgi.com.au) (Ping timeout: 240 seconds) | 04:09 | |
*** Joins: dhx1 (~anonymous@60-242-108-164.static.tpgi.com.au) | 04:26 | |
*** Quits: Ragnor (~Ragnor@dslb-178-001-198-063.pools.arcor-ip.net) (Ping timeout: 244 seconds) | 04:28 | |
FreeAir | What are the chances of solving the back button loses everything bad behaviour? It seems like it could be integral in how things are done? Firefox does most of the work here, I guess. What is stopping it refilling the comment field when I go back after the session time out thing? | 04:29 |
---|---|---|
FreeAir | Or, what is stopping it remembering it and going forward with a "session was invalid" button and remembering what you wrote in the app, afterall, the data WAS sent to the app, and dropped! | 04:30 |
FreeAir | IE, why do I have to retype the epic comment that I just wrote, from scratch, now, because I forgot to reload the page before typing it? | 04:30 |
FreeAir | Wouldn't the best behaviour be to log out, or switch back to a view or something if sitting too long? | 04:31 |
FreeAir | I'm still logged in after these events, so it's clearly not a security thing. | 04:31 |
FreeAir | And yes, I am fully aware that it's a server side setting, however bumping it up to a month seems like the wrong solution to a problem that isn't with the server, really. | 04:32 |
* FreeAir is done ranting, but hopes that some of the above soaks into someone here, as behaviour like that is the sort of thing that turns people off usage... | 04:32 | |
* FreeAir goes back to write his comment again. | 04:33 | |
*** Joins: Ragnor (~Ragnor@dslb-178-009-208-170.pools.arcor-ip.net) | 04:36 | |
*** Joins: soustruh (~Miranda@ip-86-49-121-75.net.upcbroadband.cz) | 05:06 | |
*** Joins: asm89- (~asm89@unaffiliated/asm89) | 05:45 | |
*** Quits: asm89 (~asm89@unaffiliated/asm89) (Ping timeout: 276 seconds) | 05:48 | |
*** Joins: asm89 (~asm89@unaffiliated/asm89) | 05:50 | |
*** Quits: asm89- (~asm89@unaffiliated/asm89) (Ping timeout: 245 seconds) | 05:50 | |
*** Joins: Smiley (~Smiley@last.fm/resident-dj/Smiley) | 06:21 | |
Smiley | aaaaaah, i was here a few days ago attempting to set the url which goes out in emails and ended up with $g_path = isset( $t_url ) ? $t_url : 'https://mantis.oxygen8.com/'; | 06:22 |
Smiley | however someone told me how to set it so its ALWAYS the set url... | 06:22 |
Smiley | do i just remove the iseset stuff | 06:22 |
Smiley | and have $g_path = 'url here' ? | 06:22 |
*** Quits: Cupertino (~Cupez@unaffiliated/cupertino) (Quit: I give up...) | 06:33 | |
Smiley | Ah, but the whole "security token - did you submit twice" thing is appearing | 06:37 |
Smiley | no one submitting twice, simply taking a long time to submit | 06:38 |
FreeAir | Smiley: I just had a big rant about a similar thing :-) | 06:38 |
Smiley | FreeAir: any idea of a fix? | 06:39 |
FreeAir | There is a setting that you can change in apache2 conf that helps that issue, but if you don't have access to the apache2 config it won't help you, and it's a patch anyway. | 06:39 |
Smiley | it seems to be going on for around 2 years now o_O | 06:39 |
Smiley | i find bugs in 2009 mentioning it | 06:39 |
* Smiley isn't exactly sure whats happening. | 06:39 | |
FreeAir | Yes, I think it's an architectural thing, but I'm just guessing. | 06:39 |
Smiley | php invalidating the session/thing? | 06:39 |
FreeAir | they use php sessions, and those auto expire | 06:39 |
FreeAir | yep | 06:39 |
FreeAir | so you can just make it take longer to expire | 06:39 |
Smiley | so if i have access to the php.ini.... can i change it? | 06:39 |
FreeAir | but that doesn't help you when you lose all the info you typed in... | 06:40 |
Smiley | that'll work, I'll set it to 3 days :D | 06:40 |
FreeAir | it's infuriating to say the least | 06:40 |
FreeAir | yes, you can | 06:40 |
Smiley | tbh if someone types up a ticket and takes 3 days to submit it, its likely already fixed here. | 06:40 |
FreeAir | LOL | 06:40 |
FreeAir | Fair enough! | 06:40 |
Smiley | So erm.... | 06:40 |
Smiley | where can you change the timeout? | 06:40 |
FreeAir | I leave un-dealt-with things open in my browser and deal with them as I get to them... and they've always timed out with the stock settings | 06:41 |
FreeAir | I have it on a day or two or 3 now myself | 06:41 |
FreeAir | but i got screwed by it this morning | 06:41 |
FreeAir | back button doesn't get you your content and there is no forward button in the app | 06:41 |
FreeAir | the setting... one second | 06:41 |
FreeAir | i'll check my /etc git commit log | 06:41 |
FreeAir | Date: Wed Jun 15 13:49:34 2011 +0000 Add to control, and update session from 1440 to 7200 seconds for mantis use. | 06:42 |
FreeAir | let me diff it | 06:42 |
FreeAir | I might bump it up even higher myself now too... | 06:43 |
FreeAir | still, the app needs a proper solution to this IMO | 06:43 |
Smiley | Funny thing is - application error 11 - i.e. you've missed something out, DOES save your input? | 06:43 |
FreeAir | hmm, i've not caught that one | 06:44 |
FreeAir | do i just not fill out one of hte required fields to get it? | 06:44 |
Smiley | don't select a category or a time or something. | 06:45 |
Smiley | yup | 06:45 |
* Smiley thinks its a POST vs GET issue | 06:45 | |
FreeAir | session.gc_maxlifetime = 14400 | 06:48 |
FreeAir | apparently i tweaked it in alater commit without mentioning it in the commit comment... | 06:49 |
Smiley | tut tut ;) | 06:49 |
Smiley | where is that option? | 06:49 |
FreeAir | php.ini | 06:49 |
FreeAir | line 1500 or so in my squeeze version | 06:49 |
FreeAir | tut tut indeed, i only screwed myself, it's a private repo :-) | 06:50 |
Smiley | ; After this number of seconds, stored data will be seen as 'garbage' and | 06:50 |
Smiley | ; cleaned up by the garbage collection process. | 06:50 |
Smiley | ; http://php.net/session.gc-maxlifetime | 06:50 |
Smiley | session.gc_maxlifetime = 1440 | 06:50 |
Smiley | hummm | 06:50 |
FreeAir | add one zero, or two :-) | 06:50 |
Smiley | but wont "other" garbage clog up the system too? | 06:50 |
FreeAir | maybe! | 06:51 |
FreeAir | it seems to be OK on my server, but i confess, it's not under high load yet :-) | 06:51 |
Smiley | 1440 in seconds? | 06:52 |
Smiley | 1440 = 297 021 321 arcseconds | 06:53 |
Smiley | thanks for that google >_< | 06:53 |
FreeAir | LOL | 06:53 |
FreeAir | 1440 seconds in hours | 06:54 |
FreeAir | Where in the UK are you? | 06:54 |
FreeAir | your main site could do with a favicon :-) | 06:55 |
Smiley | main site? | 06:55 |
Smiley | oxygen8.com ? | 06:55 |
Smiley | Birmingham btw. | 06:55 |
FreeAir | www.oxygen8.com yes | 06:55 |
FreeAir | OK | 06:55 |
Smiley | I'll let the dev guys know | 06:56 |
*** Quits: kirillka (~Miranda@195.242.142.17) (Read error: Connection reset by peer) | 06:59 | |
*** Joins: kirillka (~Miranda@195.242.142.17) | 07:00 | |
*** Quits: soustruh (~Miranda@ip-86-49-121-75.net.upcbroadband.cz) (Ping timeout: 260 seconds) | 07:23 | |
jreese | FreeAir: http://www.mantisbt.org/bugs/view.php?id=9813 | 07:25 |
jreese | feel free to write that :P | 07:25 |
Smiley | lol | 07:32 |
* FreeAir clicks | 07:33 | |
FreeAir | jreese: If only I had the time... I have 120 issues assigned to me right now, mostly self reported... however I'd be happy if just clicking back allowed me to copy my main body text out before reloading... | 07:35 |
FreeAir | that would be a HUGE improvement | 07:35 |
FreeAir | and perhaps an easier interim fix? | 07:35 |
jreese | "If only I had the time..." is my point ;) | 07:35 |
jreese | the easier fix is to increase the session timeout in php.ini :P | 07:36 |
jreese | any sort of proper fix is going to require not only creating and maintaining a proper data store for it, but also a way to map that to users, etc | 07:38 |
FreeAir | can code be borrowed from phpbb3? they do it right | 07:38 |
FreeAir | you get a "shit went wrong, click here" and when you click, your content is still there... | 07:39 |
jreese | or it will require a total rewrite of how we handle all of our forms so that it immediately returns all that data to the user instead of giving them an error page | 07:39 |
FreeAir | you'd probably want to tell them why it didnt just get submitted... | 07:39 |
jreese | well, even borrowing code will require somebody to spend time on integrating it | 07:39 |
FreeAir | in between | 07:39 |
FreeAir | sure | 07:39 |
FreeAir | why doesnt the back thing work though? | 07:40 |
FreeAir | what causes it to be blank | 07:40 |
dhx1 | jreese: THECODE.TXT has the answers! | 07:40 |
jreese | dhx1: don't make me /kick you :P | 07:40 |
FreeAir | LOL | 07:40 |
dhx1 | jreese: haha (it was in reference to http://www.mantisbt.org/bugs/view.php?id=9813 btw) | 07:40 |
jreese | I know | 07:40 |
dhx1 | ok, just checking :) | 07:41 |
dhx1 | that bug report is 100% wrong | 07:41 |
jreese | if the back button is returning you to a blank form, then for some reason it's not getting the appropriate caching headers from the server | 07:41 |
FreeAir | oh | 07:41 |
FreeAir | so this could be my fault | 07:41 |
FreeAir | great, keen for a fix | 07:41 |
dhx1 | my understanding is that it is to do with POST/GET sequences? | 07:41 |
FreeAir | help a brother out | 07:41 |
dhx1 | hmm actually, good point on caching headers | 07:41 |
jreese | are you using a proxy server? | 07:42 |
FreeAir | no | 07:42 |
jreese | hmm, what browser? | 07:42 |
FreeAir | a VPS self configured, so probably not configured very well | 07:42 |
FreeAir | ff 6 | 07:42 |
FreeAir | on mac | 07:42 |
FreeAir | but its the same on debian iirc | 07:42 |
jreese | most default apache configurations should work just fine | 07:42 |
dhx1 | jreese: I think the problem may be a case of forms doing a POST to the server with the data | 07:42 |
jreese | dhx1: yes, but the browser should be retaining that data, so that when there's an error, the user can press the back button and still have all of their form filled out... | 07:43 |
dhx1 | jreese: then the server will _always_ redirect to either an error/confirmation page before redirecting to the destination page? | 07:43 |
jreese | dhx1: oh, you're talking about the proper solution? | 07:44 |
dhx1 | jreese: wouldn't it be the only solution? | 07:45 |
jreese | imo, the proper solution is that we should be using a proper MVC architecture that allows our controller to simply redisplay the form page (with all of the user-submitted content already in place) rather than force the user to hit the back button, and without requiring a redirect | 07:45 |
*** Joins: soustruh (~Miranda@ip-86-49-121-75.net.upcbroadband.cz) | 07:45 | |
dhx1 | jreese: where is interim form data stored? the browser? PHP session? | 07:46 |
dhx1 | sorry, rereading... I agree | 07:46 |
jreese | even if it was just a matter of having our form submission scripts do an include() of the original form page to redisplay them, I think that would be a proper solution | 07:46 |
dhx1 | data validation error pages should just reload the page with clear notice of what needs to be fixed | 07:46 |
jreese | exactly, and that's what 9813 is trying to get at | 07:47 |
jreese | forcing the user to press back is a terrible crutch, and because browsers are very picky about caching, dangerous and frustrating to the users | 07:47 |
dhx1 | is it possible to retain unsubmitted form data if the user accidentally clicks a link/presses the back or forward buttons when completing a form? | 07:48 |
dhx1 | I haven't looked into browsers enough to know when they do/don't retain data from forms | 07:48 |
jreese | not without using ajax to continually pass that data to the server, but in that case, it's not the app's fault, and the browser should still be saving that data | 07:48 |
jreese | anywho, I need to shower :P | 07:49 |
dhx1 | I've got to head off too | 07:49 |
jreese | good morning btw :P | 07:49 |
dhx1 | will chat later :) | 07:49 |
jreese | cheers | 07:49 |
dhx1 | likewise, hello :) | 07:49 |
dregad | @FreeAir - since you're using Firefox, the easiest fix for you is to use a plugin called Lazarus - check it out | 07:53 |
FreeAir | dregad: that's cool, however it's 2011 and I'm somewhat used to that being the default ;-) Plus, I also use Chrome and occasionally Safari and even Konquorer :-o NEVER IE though :-) I don't have any win machines except an XP vm. | 07:57 |
FreeAir | Point being, what about all of my devs/users/friends... | 07:57 |
dregad | I know | 07:58 |
FreeAir | if there is a server setting that can help with this, i'm all ears, jreese suggested that there might be | 07:58 |
FreeAir | I will place a link to that plugin in the "mantis quirks" section of my issue tracker guide thread :-) | 07:59 |
FreeAir | It's shocking how many have no idea what issue tracking is all about... | 07:59 |
dhx1 | dregad: thanks for the follow-up email on ADOdb, I didn't know they were still releasing | 08:01 |
dhx1 | dregad: I'll reply in full tomorrow, but in short: the only changes in the MantisBT-bundled version is from someone accidentally removing extra white space/new line characters | 08:02 |
dhx1 | dregad: therefore we should be upgrading to the latest version of ADOdb for the next 1.2.x release | 08:03 |
dhx1 | dregad: I'm happy with patching the MantisBT-bundled version but would prefer we push ADOdb to release a new version with a roll-up of any patches we deem necessary | 08:03 |
dregad | dhx1: the diffs in ADOdb is not just whitespace | 08:35 |
dregad | the diff command I used excludes these changes (-wB) | 08:36 |
*** Joins: Cupertino (~Cupez@unaffiliated/cupertino) | 09:08 | |
jreese | FreeAir: the only server side setting that affects that issue is the php session timeout; my question about a proxy server is because we've had users with caching proxy servers that munged caching headers, or worse, cached pages for the user that broke mantis' ability to actually work period | 09:24 |
FreeAir | ouch | 09:32 |
jreese | btw dregad, I would say as long as you document the changes you're making, eg put a diff somewhere or something, then you should be fine. fixing oracle for tarball users is more important to me than dealing with distros; peolpe installing from distro packages won't be using oracle IMO | 09:46 |
FreeAir | pretty unlikely :-) | 09:49 |
*** Quits: Rixie (~Rixie@188.177.20.182) (Quit: Rixie) | 10:15 | |
*** Joins: Rixie (~Rixie@188.177.20.182) | 10:16 | |
*** Quits: Rixie (~Rixie@188.177.20.182) (Read error: Operation timed out) | 10:18 | |
*** Joins: Rixie (~Rixie@188.177.20.182) | 10:25 | |
*** Quits: asm89 (~asm89@unaffiliated/asm89) (Quit: WeeChat 0.3.5) | 11:16 | |
dregad | jreese: thanks for your comment. Is it not sufficient to use the git history as a track record of changes ? | 11:35 |
*** Quits: kirillka (~Miranda@195.242.142.17) (Ping timeout: 244 seconds) | 11:36 | |
dregad | @dhx - forget my comment above, confusion due to 1.3.x running ADOdb 5.11 while 1.2.x (where I develop the oracle branch) is on 5.10. You are correct that there is only whitespace diffs with 5.11 | 11:52 |
dregad | see my e-mail to the mailing list. | 12:08 |
jreese | dregad: for packaging and tarballs, it would be best to have that documentation versioned in the repo itself, rather than needing to extract it from history | 12:15 |
dregad | like in library/README.libs ? | 12:17 |
jreese | and I agree with your email that it should be considered a bug to be fixed for 1.2.x | 12:17 |
jreese | dregad: either that, or depending on size, create a .patch file in library/ and reference that from redame.libs | 12:17 |
*** Quits: soustruh (~Miranda@ip-86-49-121-75.net.upcbroadband.cz) (Quit: visit http://wormscesky.cz) | 12:41 | |
*** Quits: chris38` (~chris38@AGrenoble-751-1-1-213.w90-9.abo.wanadoo.fr) (Ping timeout: 244 seconds) | 13:03 | |
*** Joins: chris38` (~chris38@AGrenoble-751-1-18-119.w86-206.abo.wanadoo.fr) | 13:09 | |
*** Quits: angelete2 (~angelete2@212.183.206.162.static.user.ono.com) (Ping timeout: 240 seconds) | 14:15 | |
*** Joins: angelete2 (~angelete2@212.183.206.162.static.user.ono.com) | 14:15 | |
*** Joins: soustruh (~Miranda@ip-86-49-121-75.net.upcbroadband.cz) | 14:19 | |
*** Quits: cerf (~quassel@mcl71-3-78-241-52-239.fbx.proxad.net) (Remote host closed the connection) | 14:37 | |
*** Joins: kirillka (~Miranda@195.242.142.17) | 14:53 | |
*** Quits: kirillka (~Miranda@195.242.142.17) (Client Quit) | 14:54 | |
*** Joins: Paul24 (~IceChat09@2001:470:9310:aaaa:4105:8672:a499:a780) | 15:06 | |
*** Quits: angelete2 (~angelete2@212.183.206.162.static.user.ono.com) (Ping timeout: 260 seconds) | 15:09 | |
*** Quits: FreeAir (57dd0301@gateway/web/freenode/ip.87.221.3.1) (Ping timeout: 265 seconds) | 16:45 | |
*** Quits: Cupertino (~Cupez@unaffiliated/cupertino) (Quit: I give up...) | 17:43 | |
*** Quits: Paul24 (~IceChat09@2001:470:9310:aaaa:4105:8672:a499:a780) (Read error: Connection reset by peer) | 18:14 | |
*** Quits: dhx1 (~anonymous@60-242-108-164.static.tpgi.com.au) (Remote host closed the connection) | 18:27 | |
*** Quits: soustruh (~Miranda@ip-86-49-121-75.net.upcbroadband.cz) (Quit: visit http://wormscesky.cz) | 19:16 | |
*** Quits: sdfjkljkdfsljkl (~sdfjkljkd@static.96.23.63.178.clients.your-server.de) (Remote host closed the connection) | 20:00 | |
*** Joins: sdfjkljkdfsljkl (~sdfjkljkd@static.96.23.63.178.clients.your-server.de) | 20:00 |
Generated by irclog2html.py 2.10.0 by Marius Gedminas - find it at mg.pov.lt!