[squidsk]

That's alright sometimes I make sense to myself but not to others.

The product check system on vb.org as it works now requires that each mod must have a unique pid. This means that if a mod is released for multiple versions of vb each needs to have its own pid. This makes the upgrade script to port a mod to a new version difficult, because all phrases, settings, plugins, templates, etc. need to have their associated pid updated or in the case of the entry in the product table it needs to be removed.

For example, I'm maintaining a vb4.x mod that was ported from vb3.8. In the vb3.8 mod thread the pid is yet_another_awards_system. Since the vb4 version of the mod is the same just updated it continues to have the pid of yet_another_awards_system, but since the vb4 mod thread must have a different pid, in this case yaas4, this means that the check version functionality in vbulletin is broken either because I have to point it to the vb3.8 mod, which has incorrect version info, or because it checks against the different pid for the vb4 mod which causes the check to fail outright. Currently the only solution is, as I mention above, to detect the product with the old pid and then alter all of its contents so that they are part of the new pid.

My solution is to reduce the pid uniqueness constraint from unique on vb.org to unique for each version of vb that vb.org allows (see the list in my first post), so for example the vb3.8 thread for the mod would continue to have a pid of yet_another_awards_system, but instead of having a different pid for the vb4 thread it would also be allowed to have a pid of yet_another_award_system. The url would have the additional field on the query string to differentiate between the vb3.8 pid and the vb4 pid.

I hope what I'm asking for is clearer now, along with the reasons for it. If I can clarify anything just ask.