Re: Problems updating global preferences

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.php 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