Change to version check functionality

[squidsk]

I'd like to propose a change to the version check functionality by adding a version to the url so that if you port a product to a new version you don't need to do a massive overhaul to change the pid of the product to get the version check functionality to work correctly.

Currently the url looks like:
https://vborg.vbsupport.ru/misc.php?do=productcheck&pid=my_product

I'd like to see it look like the following instead:
https://vborg.vbsupport.ru/misc.php?do=productcheck&pid=my_product&version=#

where # corresponds to the mod designations vb.org has, the current list of which is

5.x
4.x
3.8
3.7
3.6

If the version isn't on the url or doesn't match the list of mod areas the current behaviour is maintained.

[Paul M]

Not sure Im following this, can you provide examples and what you are asking to happen for each of them.

[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.

[Paul M]

Hmmm.

I see what you are trying to do, but I'm not going to remove the unique restriction on product ids. I'll have a think about any other way this could be done.

(Personally, I use new pids for different vB versions, on all my releases).

JFYI, nothing is going to happen for a while, as the upgrade take priority atm, not new features.

[squidsk]

No worries, I wasn't expecting instant change on this.

[Paul M]

Actually, I was looking at the version check code today, and the old code [when we used threadids] is still active, and in this case could be used for what you require.

The old format is

....../misc.php?do=checkversion&pid=myproductid&t=123456

Where t=123456 is the actual release threadid, and pid is the product id you want returning in the response XML.

This does not use the pid to locate the thread, it just blindly returns the pid you send and the version information from the thread.

(It should default to using the set pid if you dont send one in the request).

[squidsk]

Thanks, that's works like a charm. The only downside to that method is that you don't know when releasing a mod what the threadid will be, but that's a smaller hassle to deal with.

[Paul M]

Thats one of the reasons we have the newer pid based system.

We used to just create the release thread, then update the url in the product before uploaing it.