Mr Blunt, to be sure I understand this, are you suggesting that If I do a forum upgrade (vb2 to vb3) with existing Commish's hack, that I should NOT install your hack until you've made the "product update" data import hack? and so in the meantime, files will just reside without me being able to track downloads?

Most hacks aren't transferrable between "major" vb revisions.
vb2 hacks won't work with vb3.
vb3 hacks won't work with vb350.
Whodownloaded_IP is strictly a vb350 hack.

So if you have Commish's old vb2 hack installed, you'd have to get rid of any edits before the upgrade to EITHER vb3 or vb350 ... meaning clean vb files and reverting your old templates.

If you move into vb3.0.8 then you'll have to settle for my super old vb3 hack.

If you move into vb3.5.0 then you have the option of using either of my vb350 whodownloaded hacks (with IP or without), but note that if you choose the OTHER non IP version, then you still aren't saving dates which is "somewhat dumb" if you plan to use this IP version in the future.


Now note:
Files and templates are not "database data".

The "data" that was saved with each download won't get touched while you do the vb upgrade and will remain stored in the database. The only thing that changes when you upgrade vB is it will stop logging downloads from that day forward (until you install a hack for that version) and there won't be a way to view the saved data since your templates and files won't have the "hack" to process the data.


So summary....
New IP hack can be installed on vb350 at any time no matter if you've got old data sitting around or not ... because new IP hack is independent.

We just won't add to the old column anymore.
The old data won't be "viewable today"!!!
Soon it will be viewable ... as if it was never missing.

Let it sit where it is in the database and "I'll import it" when I make the proper install script. Once it's imported, then it will magically be "viewable again". The imported data will be easy to spot because there will be a date from 1969 (since old hack didn't track dateline).

Feel free to install this the same day you upgrade to vb350!!


LAST NOTE:
This is still beta so I do NOT suggest installing it on a live forum just yet.
I'm not saying "you can't", because you can.

If you do, just make darn sure you "CLICK INSTALL" on this thread so you will get a notice when I make a major change to this .... and do not overlook changes I make ... until such time as I remove the "beta checkmark" at the top of the thread.

I have a long agenda (you saw the todo list).
I've already dropped a month of my life into this.
And I expect at least one more month before I finish that list!!
There's still no major flaws that I know of, so that's a plus, LOL.

nope im not.

I'm on it...
How stupid of me to think you couldn't use a quote in name.
What would the irish do, LOL.

I think $myvar = addslashes($vbulletin->userinfo['username']) should fix it.
I tested it on my forum yesterday and it seems to work fine.

Can anyone with experience verify that this is all I need to do??
And then I just stripslashes() after reading from DB?

What I don't understand is why I don't physically see the slashes in my database fields.
I just see the exact text name in the db.
Is this normal?

Addslashes is depreciated in 3.5, please use $vbulletin->db->escape_string instead.

And you will only see something different in the database if you use a special character like a quote.

Thanks MarcohH64!!
I really appreciate you following me around and helping me out.

I looked at that function and see it used "during" the db connection.
Does this imply that there's no "special handling" needed for after a db read?

Also while searching vb's code, I notice escape_string() is used for IPADDRESS in places, so I suppose I should do this for 4 of my 6 insertion variables (username, filename, ipaddress, & alt_ip)??

I'm so close with this thing ....
For the past few days I've been learning how to JOIN LEFT, ROFLMAO.
So that is knocking off a couple queries for me now.
I'm getting there....

Basicly you should sanitize all 'untrusted' (ie provided by outside sources like user input) variables used in queries.

<font size="4">I just posted a new version (v105)!!
This is a crtical update!!
To anyone who had issues - I'M SORRY!!</font>

I also rewrote many parts of the top post so might I suggest re-reading it please. The v105 zip file's readme is the same as the post (as of this writing) so pick one to read. Sometimes I think I spend more time writing the readme's than I do the researching and writing code, LOL, but it's for YOUR own good .... not mine!!

Please see the version history for full list of changes.
The really critical update is for the ENABLE LOGGING plugin.

Boofo,
New screen shots are posted!!

C.Birch and MarcoH64,
Thanks guys for pointing out why and how to better clean things like usernames before trying to write them into the database!! If someone can double check me, I think I have all the bases covered now ... as far as db writes go anyways. I now clean all the non numeric numbers (hope that's sufficient, if not, could someone please say so??).

C.Birch,
Sorry it took me a few days before posting a fix, but I didn't want to post a patch when major release with many changes was so close to being ready.

Laycomp,
Now that I'm feeling good about this version ... Here's my short answer!! No better time than the present to install this. The longer you wait, the less data you'll have to retrieve about those downloads later on. I PROMISE that soon I will figure out how to automate the process with a product update and your old saved data will reappear like it was never gone. Think of the old saved data as simply "not available today, but will be soon".

Thank you very much for the new Release.

Great Great Great Mr.Blunt !!!!

Has this been added yet? ;)