Exclusive eBooks, Software Solutions, Quality Guaranteed
Web NukeBiz
Welcome to NukeBiz · Members
of 6

 #182 » IpTracker use of preg_match
 Date Open: Jun 02, 2014 at 10:11:07    Last Update: Jun 04, 2014 at 01:19:05 Bugger Off: Jun 04, 2014 at 01:19:05 
 Description: Hola! Having finally moved everything to DF9.4 I thought I'd be able to upgrade and use IPTracker at 9.3.5. But still getting:

Fatal error: Call-time pass-by-reference has been removed in /home/waldron7/public_html/modules/IP_Tracker/admin/httpbl.php on line 35

Line in question:

preg_match('/[0-9]{1,3}.[0-9]{1,3}.[0-9]{1,3}.[0-9]{1,3}/', $ip, &$matches);

I'm using PHP 9.4.21

Thkx, rgds, mark
 Request: Bug
 Application: Module
 Module: ip_tracker
 Bugger From: Layingback
 Debugger: Phoenix
 Group Access: All Visitors
 DiscussIt Forum: IP Tracker
 DiscussIt Topic: IpTracker use of preg_match
 Status: Done
 Priority: Alert
 Topic Replies:
 Jun 02, 2014
Yeah, sorry about that - noted and fixed some months back when I went to PHP 5.4.

Since someone else is now in that territory, I'll have to package up the changes and release the update.

There may been other issues and there were with a couple of other modules, so I'll have to track them down too.
 Jun 04, 2014
Done http://nukebiz.com/Downloads/details/id=37/
 Jun 04, 2014
Thanks for very quick turnaround.

Confirming Admin issues are fixed.

I still see a few usernames not matching IP addresses - eg my IP on other users' names. So have Pruned the Db back to 0 records again after update, and will now monitor under 9.3.6

Will get back to you only if issue resurfaces.

Thanks again!
 Jun 05, 2014
Unfortunately I'm still seeing usernames incorrectly assigned. At least 5 users (incl me) and 6 IP addresses involved. At multiple times.

My hunch would be just the usernames are wrongly assigned, but hard to judge.

Happy to diagnose if you give me some pointers on where to start ...

Or reset things as you see fit ...

Or I can email you any required samples. (While I trust you with the IP addresses, I can't really post them here.)

 Jun 05, 2014
Can confirm, I think, that it is just the usernames that are incorrectly linked.

If I click on my IP address, even though it is displayed against 3 different usernames (including my own), it is always my own accesses that are listed. (Confirmed because I am the only one with access to IP-Tracker.)
 Jun 05, 2014
hmm, I haven't encountered that before - I'll have to trace the code and see if there's a reason.

Maybe a silly question, but does it do that for the default theme?
 Jun 06, 2014
Phoenix wrote:
Maybe a silly question, but does it do that for the default theme?
Oooh, that'll be hard to test. (In the middle of a big membership drive - hence why I'm watching IP_Tracker so hard!)

I'm wondering if it could be due to having been running with problems (eg older ver with DF9.4, then PHP preg_match, etc) in the past. Ie. corruption.

I've pruned to 0 a couple of times, but is there a more complete "reset" I can do (eg. from phpmyadmin) to be sure any past corruption has been removed?
 Jun 06, 2014
I wouldn't have expected this issue to be occurring due to an older version, certainly not the code and I doubt the database.

The ultimate prune/purge would be to uninstall/install which would at least regenerate the db tables - the table field properties are certainly critical.

It's more likely to be associated with the page generation code rather than the data collection code which is relatively simple to check and appears okay.

Unless of course, you're actually seeing the issue directly in the db.
 Jun 07, 2014
Phoenix wrote:
Unless of course, you're actually seeing the issue directly in the db.

Happy to uninstall/install, but before I did that and potentially lost evidence, I tried looking at the Db.

First in IP_Tracker I did Host search on 1st 2 octets which listed my IP, with my nick on 626 hits, nothing/null (not logged in?) on 59, 4 on a user-only nick I use for testing, but also 11 other nicks (incl "Anonymous") which are not mine with between 1 and 4 hits each.

Those other nicks usually appear with their correct respective nicks, so the "error" is transitory in nature.

So in DB file _iptracking in phpmyadmin, I first sorted by ip_address, and then looked for layingback nick. Sure enough mixed in with the "layingback"s where Null, Anonymous, and each of the other - incorrect - nicks.

Does this rule out the theme, or could it still be a substituted .php somewhere. Using a refinement of my reDesign3+ but I've not added or removed any included .php or .inc files that I remember, so would expect it to be same as reDesign/redesigned - unless I've messed up, which is of course more than poss.

What should I look at/for next?

[ I thought it could be logged in as Admin and not User but I can see other users who are showing up with other IP's (in the wrong country). ]
 Jun 08, 2014
Okay, let's confirm db structure - see below.

It is normal to see your nick, Anonymous or nothing associated with your IP.

I vaguely recall an issue that can happen with IPT associated with the DF user system but it was long ago - I think it was more related to IPs of but thought that was resolved.

I've been through 300,000 listings in my IPT, sorted on IP ascending and can't find any irregularities.
 Jun 09, 2014
I think mine is functionally equivalent. See attachment.

I would imagine I got to 9.3.6 via 9.21, 9.2.2 then had to omit 9.3.5 as on outdated DF version.

Will try to PM you with excerpts of IPT display showing some of the cross-indexing. It is well more than just Anon and null on Admin.

Please advise if you would rather continue diagnosis, or restart with fresh install (which might mask a real issue, or not). I'm happy to proceed either way.
 Jun 10, 2014
Many thanks for the data.

I think it's now best to do a fresh install because I simply can't see an issue in the code.

The iptracking.inc code that generates username:
$ipuname = (is_user() || is_admin()) ? $userinfo['username'] : ((SEARCHBOT) ? SEARCHBOT : '');
It's simple code
 Jun 15, 2014
Just to summarise for others reading this forum looking for solutions, the coding error was mine! :oops: And although the fix did show up a very minor issue with IPT, it was in a different area, not directly related to this problem.

Thanks to Phoenix for helping me focus on the correct issue.
150 buggers listed, 109 buggered off, 31 declined, 8 on hold.