Closed GoogleCodeExporter closed 8 years ago
Original comment by TaQS...@gmail.com
on 9 Jul 2009 at 9:20
THdie("Abnormal reply");
OH I GUESS SO
Original comment by TaQS...@gmail.com
on 9 Jul 2009 at 9:26
$octets = explode(".", long2ip($ip), 4); -> $octets = explode(".", $ip, 4);
Because $ip = long2ip($ip);
Anyway I guess it's fixed. As well as any other banning issues we may have
been having.
But it looks like ban checking is now buggy. I'll work on this
Original comment by TaQS...@gmail.com
on 9 Jul 2009 at 11:43
SQLite has different syntax than MySQL, and the bans db couldn't be queried and
updated with the same code.
Original comment by TaQS...@gmail.com
on 14 Jul 2009 at 8:05
Banning an entire thread is broken right now because of how sqlite_feth_array()
(and
therefore $db->myarray()) works. It doesn't return anything if this:
$replies = $this->myarray("select id from " . THreplies_table . " where
thread=" . $id);
Warning: sqlite_fetch_array() expects parameter 1 to be resource, string given
in
dbi\SQLite-dbi.php on line 97
Also post data html (mostly brs and gtgts) get mangled when viewing the bans.
It's
most likely because of clean() in banip(), but I did a kind of hackish
workaround
when the ban is actually displayed.
Original comment by TaQS...@gmail.com
on 5 Aug 2009 at 5:57
function myarray($call)
{
if(DDDEBUG==1) { echo ("myarray: " . $call . "<br />"); }
$pup = sqlite_query(THdblitefn, $call);
$dog = sqlite_fetch_array($pup, SQLITE_NUM); // or return null;
if ($dog === false)
{
return (null);
}
return ($dog);
}
Original comment by TaQS...@gmail.com
on 7 Aug 2009 at 6:51
This should be fixed in the svn (apparently) but I will test it later to make
sure.
Original comment by TaQS...@gmail.com
on 7 Aug 2009 at 6:58
Okay I'm going to retitle this ticket one last time because it still is about
the bans.
I think that fix for myarray worked (it seems to be fetching all the posts in
thread
ban, where before it was stopping after the first or just failing completely)
but now
I'm having issues with banning mangling post data. I'm again blaming it on
clean()
and escape_string(). I also took out the nl2br() from banbody() because I know
for
sure that mangles posts (taking it out also preserved my test post of A CAT IS
FINE
TOO, which thorn used to break, and is the entire reason nl2br is even being
used).
I'll commit what I've got and then we can go from there. I'll give out more
details
about this later if requested.
Original comment by TaQS...@gmail.com
on 7 Aug 2009 at 11:19
banbody still doesn't accept its default, and there's an issue with this:
This ban duration was set to 1 hours. The ban will expire on
%08/%25/%09(%pm)%23:%Aug:%th
Both of which are probably easy fixes (I'll fix the last one first)
Original comment by TaQS...@gmail.com
on 26 Aug 2009 at 5:29
Well, I put a workaround in place, where it used to return is banbody wasnt set
(which it should have been because of the function declaration), but now:
if ($publicbanreason)
{
$publicbanreason = '<br /><br /><span class=ban>(' . $publicbanreason . ')</span>';
}
else
{
$publicbanreason = "<br /><br /><span class=ban>(USER HAS BEEN BANNED FOR THIS
POST)</span>"; //I guess this will work for now
}
Other than that's it's "Fixed"
Original comment by TaQS...@gmail.com
on 26 Aug 2009 at 5:44
Well, I guess we'll need to fix banbody anyway, because it's mangling again. It
successfully posts the default message now if the box is left blank, but it also
mangles whatever html is in the box (including old ban messages). This also
might be
a problem with editpost. I'll do some testing.
Original comment by TaQS...@gmail.com
on 26 Aug 2009 at 8:10
Fixed banbody (escape_string, actually) in SQLite. Fixed I guess.
Original comment by TaQS...@gmail.com
on 27 Aug 2009 at 7:18
Original issue reported on code.google.com by
TaQS...@gmail.com
on 9 Jul 2009 at 9:20