Changes to 2.4.2 and Vesrions of Nuke after 7.6

Posted: Fri Oct 07, 2005 1:35 pm

Two comments.

I wanted to mention that Raven's distribution of the update only for the IP2C is fine, but it should be noted that there are some file changes as well so people that have 2.4.1 should really run the entire update to 2.4.2

Next, in 2.4.2 there are some attempts to address the TinyMCE Editor issues by disabling the editor. This is fine; however, I am noticing a problem relative to textarea data (whether the editor is disabled or not) in that the database (in versions such as 2.1.3) has that data as a list. For example:

Database Table: PREFIX_nsnst_blockers
Field 6 - Blocker = Harvester:
BROWSE of the LIST data reveals:

Code:




alligator


anonymiz


asterias


backdoorbot


black hole


blackwidow


blowfish


botalot


builtbottough


bullseye


bunnyslippers


catch


cegbfeieh


charon


cheesebot


cherrypicker


chinaclaw


combine


copyrightcheck


cosmos


crescent


curl


dbrowse


disco


dittospyder


dlman


dnloadmage


download


dreampassport


dts agent


ecatch


eirgrabber


erocrawler


express webpictures

However, in versions of late, that code now appears as:

Code:




alligator anonymiz asterias backdoorbot black hole blackwidow blowfish botalot builtbottough bullseye bunnyslippers catch cegbfeieh charon cheesebot cherrypicker chinaclaw combine copyrightcheck cosmos crescent curl dbrowse disco dittospyder dlman dnloadmage download dreampassport dts agent ecatch eirgrabber erocrawler express webpictures

Now the problem (as I see it) is that some of these puppies have spaces between the name values. For example: "dts agent"
In this case, with the data separated by a space, that is being seen as "dts" and "agent" which creates a serious issue.

Now in my case, while the variable exists in the save file to convert returns into \r\n, I noticed that it had no impact if I went through each item and hit a hard return. Probably as I suspect that no <br> or <br /> function is created by doing that. To combat this (doing some playing) I first ended up changing some of the code in the ABConfigSave to be like this:

Code:

$xblocker_row['list'] = $listblocker;


$listblocker = str_replace("<br />", "\r\n", $listblocker);


$listblocker = str_replace("<br>", "\r\n", $listblocker);


absave_blocker($listblocker);


Header("Location: ".$admin_file.".php?op=$xop");

Then in the ABConfigHarvester I changed my code to actually add the <br> elements (which get replaced on the save) to this:

Code:

blocker_config($blocker_row);


$blocker_row['list'] = str_replace("\r\n", "<br />", $blocker_row['list']);


echo "<tr><td bgcolor='$bgcolor2' valign='top'>".help_img(_AB_HELP_019)." "._AB_HARVESTERLIST.":</td><td><textarea name='xblocker_row[list]' $textrowcol>".htmlspecialchars(($blocker_row['list']), ENT_COMPAT)."</textarea></td></tr>\n";


echo "<tr><td align='center' colspan='2'><input type=submit value='"._AB_SAVECHANGES."'></td></tr>\n";

This sometimes solved the problem, but I have ended up doing this inside the database itself and saving the data as a list there to avoid the issue, but it doesn't resolve the overall problem for editing or adding.

I'm not really sure (given the different versions of Nuke) how to address this problem permanently. My solution was kind of a nasty, "try as you go to fix the problem" workaround.

I am not even convinced that the data setup is as it should be (meaning, I'm not sure how to address these spaces, nor can I confirm that this is how the blocker in question will see the referrer, havester or any other analyzed source).

Should divided variables (two worded titles) be seperated by a defined "dts" and "agent" type function?

Should these definitions maybe resided in a seperate table where they might be listed individually instead of as part of a textarea mass field?
For example:
PREFIX_nsnst_blockers_harvester
Field1: ID
Field2: Name
BROWSE:

Code:




ID=1 Name=alligator


ID=2 Name=anonymiz


ID=3 Name=asterias


ID=4 Name=backdoorbot


ID=5 Name=dts agent

etc....

Thoughts?

Site Admin/Owner Joined: Aug 27, 2002 Posts: 17088

64bitguy wrote:

I wanted to mention that Raven's distribution of the update only for the IP2C is fine, but it should be noted that there are some file changes as well so people that have 2.4.1 should really run the entire update to 2.4.2

Actually, that is not necessary other than maybe for clarification. This is simply to address the data that changed on the ip2country table. You do not need the file changes for the ip2country table as there are no schema changes in the full upgrade. I also have released the 2.4.1 to 2.4.2 files that changed in a separate download. There's no reason to load all the ip2country data just to get a few changes.

Posted: Fri Oct 07, 2005 3:39 pm

I didn't know about the other download, (though I thought I remembered seeing an article about it) the only one I noticed in the NukeSentinel Downloads area was the 2.4.1 to 2.4.2 IP2C version. After looking again, I see how they are clarified.

My bad. Smack

Posted: Thu Oct 20, 2005 6:15 am

This is a bump to ask bob/raven about the problem report and how the data in these "textarea" tables should actually look.

Thanks