Artifacts in the code

[lesliekirk]

The reference to phpMyAdmin must be a clue. In my own work, I often find myself logging into phpMyAdmin repeatedly during a long work session. If that data string is phpMyAdmin's equivalent to a session ID, I suppose it could be used to keep a session alive at times when I'm not clicking any buttons in that browser tab. That could be handy, although putting the field into every form in the store seems kind of extreme.

It may have to do with the use of phpMyAdmin to export the MySQL database to install on a new server. Since I know that I didn't work in phpMyAdmin I know it wasn't me but perhaps it could have happened during the dump process? Perhaps the gaining host had to do something in the database to prep it for a move? I do seem to recall needing to supply access to it as part of a move from one host to another back when.

[Kent Multer]

The reference to phpMyAdmin must be a clue. In my own work, I often find myself logging into phpMyAdmin repeatedly during a long work session. If that data string is phpMyAdmin's equivalent to a session ID, I suppose it could be used to keep a session alive at times when I'm not clicking any buttons in that browser tab. That could be handy, although putting the field into every form in the store seems kind of extreme.

[lesliekirk]

Yup, I agree with Scott - it was for sure non-Miva hosted sites and I remember simply find/replace (as in delete) them and everything still worked fine.

I've known that deleting all these "artifacts" never broke a site, as I had to do it for a number of sites. I was just really trying to see if anyone knew how they got there. I seem to recall it happening when I site was moved from one host to another. I don't think it was anything put there on purpose since I seem to recall it showing up after a site was moved to a new host (and just due to the sheer numbers of these I have had to remove in a single site).

[GDesigns]

Yup, I agree with Scott - it was for sure non-Miva hosted sites and I remember simply find/replace (as in delete) them and everything still worked fine.

[ids]

This may jog a memory...

Years ago prior to Ready Themes for sure, and possibly from the ancient times of the original 5.0 when Miva wasn't Miva managed, but by someone else, I took over a couple stores originally done by pro services (again, the early days of this). These sites had these codes everywhere. I don't think I remember the specifics of my experience with these, but I am fairly sure these sites weren't Miva Hosted (Miva Hosting was in infancy). By the time I got these stores, the tag appeared to be completely ineffective. I was able to remove them and the pages still worked.

Maybe the tag/code was needed to make a secure/valid connection with the MySQL Tables for some reason? Then, later updates of Merchant and server configurations eliminated the need?

Scott

[GDesigns]

I think, but I could be wrong, it had to do with the server setup back then. Also non-miva hosted site/s

[oliverands]

You could check on the server to see if there is a directory that's not a standard Miva one. If this were the case, there would probably be some other code, not Miva native, living on the server. You might be able to track it down that way.

[lesliekirk]

Could it have been installed by a third-party module?

That's an interesting thought, but I don't recall any module that did this. It would have had to have been a pre-2007 module.

[oliverands]

Could it have been installed by a third-party module?

[lesliekirk]

I recall seeing that and cleaning it up, but i swear it's been at least 12 years and I can't for the life of me remember the issue

It has been quite a while since I've seen this too. This particular site is MMUI still has a lot of lingering MM5 to it. The nav bar still has the old Miva logo in it

[lesliekirk]

It could have been used for Troubleshooting, updating something, or giving access to phpMyAdmin again for troubleshooting.

I could understand it being used perhaps on one page, but this is in every form on every page in the site, including forms that don't even have a Miva function. I can confirm that this latest site was hosted with more than one host, I just don't know when they moved to their current host.

[GDesigns]

I recall seeing that and cleaning it up, but i swear it's been at least 12 years and I can't for the life of me remember the issue

[Nerd Boy Inc]

It could have been used for Troubleshooting, updating something, or giving access to phpMyAdmin again for troubleshooting.

[Rick Wilson]

That I don't know

[lesliekirk]

That was never stock Miva code.

LOL, yes, that much I knew. I'm just trying to figure out how it got inserted into a number of sites over the years. It may be as much as 10 years since I last saw this happen.