Re: Problems updating global preferences

More on this...

If I restart the Apache service, and pop back over to the client machine, 
and refresh admin.php (after first attempting a plain old post), it will 
work fine, every time.

If I do the same, and then go and try to post, it will fail. It will 
continue to fail no matter how many times I try to post, and/or refresh the 
page, once I have tried to post.

This is just weird. The 'go' variable is also used on the newuser.php page, 
and does not at all experience the same thing. I even tried changing the 
value of go to something other than change, and it does the same thing.

What a puzzle!

Thanks,
--Scott Brown



At 01:11 PM 9/26/2003, you wrote:
>The plot thickens...
>
>I haven't been able to try 0.2.4pre yet... will likely do so shortly, 
>although a diff between the two admin.php files (1.28 and 1.30) doesn't 
>show me anything that would affect the issue first reported yesterday!
>
>I have found some other quirks, though, not quite sure what they mean. I'd 
>much rather run this on a *nix box, but here I am...
>
>1) d_DoDiff
>
>This is probably a quirk on my end, but my mail server didn't like mixed 
>case on Cc:, so I had to change it to CC:.
>
>1.5) newuser.php
>
>Similar to the above, probably a quirk unique to my setup, but I had to 
>change line 117 so that it did not include $rname. My mail server (I 
>*think*; at least I didn't see where the code was doing it, except around 
>$email. PHP might be, but chasing that would be a pain!) would add the 
>carats "<>" around the entire thing, like <User Name 
><username-9IKiO1iGCm/[email protected]>> and throw a syntax error. So my newuser.php just 
>sends $email to @mail (no carats). I still need to change it where $go == 
>"newpass" (line 16).
>
>Those two might be good for a "getting Anthill running on Windows" FAQ or 
>something. Or ArgoSoft Mail Server Pro. It looks like it was designed with 
>Sendmail in mind?
>
>2) The thing with admin.php (previous thread)
>
>Strangely, if I repeatedly refresh the page after a POST, I can 
>*occasionally* get the setting change to take (very unpredictable), and 
>get the success message at the top of the page. I have been over and over 
>the code, and can't for the life of me see what is going on. Even when I 
>successfully get a change to "take", I have to refresh the page again to 
>see the font change. None of the elements, or any combination of elements, 
>alleviate the issue. I don't *think* it is a client issue. If someone 
>wanted to check it out, I can email them off-list with the URL and a 
>username and password. It's strictly in a (more or less) sandboxed area 
>for evaluation at the moment, so I'm not sweating it. It would certainly 
>help me to determine whether or not this is a client issue, or a server issue.
>
>The screwy thing is, every other form works fine. I even reviewed my 
>settings in my php.ini to make sure safe mode was off (it is, and was). As 
>a note, variables_order is set to "EGPCS". Does this matter? gpc_order is 
>also commented out (deprecated) does this matter?
>
>The only thing I can think of is that for some reason, this statement:
>
>if ($go == "change")
>
>Doesn't resolve properly, yet on every other page, it seems to do just 
>fine! Maybe IE6 thinks "change" is a reserved word or something, and isn't 
>posting it properly. I might try changing it (pardon the pun) to something 
>else. The reason I say that it must be this statement is because I would 
>expect that if it were resolving, but a database error occurred, I would 
>still get the success message at the top of the page, but it would fail to 
>do the update. No errors are thrown, and whenever I see the message, the 
>update was successful.
>
>Needless to say, I am stumped!
>
>Another thing I should probably add is that I copied my 0.2.1 db over to 
>the new install of 0.2.3; I don't see any changes to its structure, or to 
>adminÃöÒ between 0.2.1 and 0.2.3, though. Also, I am able to reproduce 
>the same problem in the 0.2.1 install... and since I can sometimes get it 
>to take the changes by refreshing the page, I don't think that's it.
>
>3) Style sheet and BODY statement conflicting?
>
>I did notice that the style sheet over-rides the settings, anyway (mostly 
>playing with the font sizes above), if I am set up correctly (initially, I 
>don't think I was, and it was not finding the style sheet). My initial 
>setting had 'webroot' set to the actual www web root, which is a directory 
>above the location of the Anthill install. I changed webroot to the 
>webroot including path info, and thought I had blown something out (hehe), 
>because suddenly, everything was darkcyan. It's a VirtualHost now ;-), 
>lol. I caught it when I fixed the emails, and the link was wrong.
>
>I believe this is expected behavior in IE, that style sheets supercede 
>BODY tags, but I could be wrong. They don't supercede FONT tag containers, 
>methinks. Gotta install Mozilla to see... Although, since they are 
>conflicting concepts, maybe a way to turn styles on and off, which, when 
>on, disables the font options on the admin screen (and removes them from 
>the body tag) in a future version?
>
>Maybe this is already on the change list for 0.2.4pre. If so, forgive me! 
>I seem to remember it (the changelog) mentioning something somewhere on 
>the styles. I'm not beta testing, but evaluating the production version, 
>for use. So, I am skeptical of using a pre-release for testing.
>
>4) Just a question...
>
>In the email(s) when changes are made to a bug report, I am getting some 
>weird text that includes path info in it:
>
>--- 2   2003-09-25 17:17:34.000000000 -0700
>+++ C:/OpenSA/Apache/htdocs/cc/ICS/shadow\2.t562.tmp    1969-12-31 
>16:00:00.000000000 -0800
>@@ -1,43 +0,0 @@
>
>I looked at the .tmp file directly, and it isn't in there, and the 
>date/time above is just wacky. Is this expected behavior with the windiff 
>I downloaded from the main site? Can I get rid of it? I don't see where 
>the code is adding it right off...
>
>I hope I am not overstepping myself here, just wanted to throw out some 
>things I unearthed. The real big issue here is the admin.php not working. 
>I can manually go into the db through an administrative tool for MySQL I 
>am using and make changes, but I'd really like to nail this down.
>
>On an aside, the fix for the query screen in IE is super! Much better (I 
>started out yesterday with 0.2.1).
>
>Thanks again!
>--Scott Brown
>
>
>
>_______________________________________________
>Anthill-users mailing list
>Anthill-users-+mQDA36h6dWw5LPnMra/[email protected]
>http://vmlinuz.ca/mailman/listinfo/anthill-users



_______________________________________________
Anthill-users mailing list
Anthill-users-+mQDA36h6dWw5LPnMra/[email protected]
http://vmlinuz.ca/mailman/listinfo/anthill-users