phraseid numbers ..... big problem! ... i warned that this would happen!
 

Hi all ...

I raised concerns a week or so ago in a pvt forum with regard to the possibility of 2 hacks using the same phraseid no. i suggested that a phraiseid number registration system should be put in place so that this cant happen,

I proposed before a hack (that requires its own new phrase id) is released the author must register the phraseid with vb.org so it dosnt clash with another.

Most of the replies to my concerns said that it would be unlikley to happen ..... WELL IT HAS!

My members choice hack has clashed with the geek articles hack ..... and is causing the installers of both hacks major headaches as you would be able to understand ... just read page 4 of the members choice voting hack thread.

Before you start accusing me that i used a phrase id for the members choice that i know would clash ... think again .... i released the members choice for vb3 origionally on vb.nl when vb3 hacks couldnt be released here. I used the same phraseid on the release here as on vb.nl

Lets get this phrasesid registration system coded on vb.org, before it happens again .... if it already hasnt with other hacks. It should be very easy to code a system here to automate the registration on phraseid's

trafix

Yes it is very likely that this would happen one day. I think the same goes for the permission bitfields.

Am I missing something obvious here ? - Why not just use 'null' in the insert code when you install the phrase, and let mysql allocate the number ?

unfortunatly that wont work :(

When setting up a new phrase group you need to add a row to the phraseid db table and then the phrases added to the phrase db table have to echo the same id number .... null wont work unfortunatly

Sorry, are you talking about the phraseid or phrasetypeid ?

oops both

you need to add the row to the phrasetypeid table and then phrases to the phrase table

i spose you could add it the phrasetypeid with null .... but then you would have to quiry what phrase id was allocated then use a string to add the phrases ...

But what about hack updates .... its gonna need a more complex installer again to assertain the phraseid before any new phrases are added .........

then there is another problem that a hack uses x phraseid for your forum and y if its installed on my forum ......

I think its better if the phraseid stays unique for every installation of the hack

shouldn't the phrasetype name be unique for each hack?
so if you know the typename, then you can get the type id, and with that id, you can get the correct phrases.

actually there i don't really see a problem.

the bitfields on the other hand could be a bit more problematical, as these would need users who know the details behind them before installing a hack...

Yes the phrasetype name and phrasetypeid have to be the same in both phrasetype and phrase db tables.

as it is at the moment when coders add a new phrasegroup for their hack they pluck a number out of the sky and use it ....... unfortunatly the coder of the geekarticles and myself plucked out the same number to use as the phraseid .....

if you read the members choice hack thread ... you would see the conflict that has been reported and basicly the best way to fix the problem is that both hacks have to be un installed and reinstalled using different phrase id nos

PS thanks Xenon for you fast reply to this matter

trafix

Ah, I see what you are talking about now - the phrase types.

The phrasetypeid field in the phrasetype table is not an auto-increment field, so you cannot add a new record with a null value and expect mysql to allocate a value to it - you have to supply a number.

However, the phraseid, in the phrase table is auto-increment, and you can add actual phrases with a null value and let mysql number them - this is what I thought you were referring to as you quoted phraseid rather than the typeid.

Also the typeid is an unsigned smallint - which means you only have up to 65,500 (ish) to play with.

I would suggest using something like typeid = (10000 + int(time() / 10000) to give you a unique id at installation time (the value of this would currently be around 21,000 and changes every 2.75 hours).

as far as i am aware ..... it is coded into vb to ignore phraseids above 1000 ... whick narrows it down from 65,000 odd :(

Is it ? I wonder why ......

Oh well, the installation script could just run a query to find the largest current typeid, and add 1 ......

I wouldn't know .. but I think its simply a limitation of field storage in mysql ?

hmm, i wonder why phrasetypid doesn't have the autoincrement.

Did the devs just forgot it?
or has it a reason, would be nice to know

As I said above, the field [in the mysql table] is an unsigned smallint, so it can range from 0 to 65535, trafix seems to imply the limitation has been coded into vB for some reason. I haven't checked it, just taken his word as correct. :)

well actually im not sure how it works but spacial phrase groups use id nos above 100 for ex
email body = 2000
email subject = 3000
something else uses 9000

but they are all multiples of 1000

and what about all the phrase ids that are currently scattered between where vb stops and 1000 i have used
153 for the members choice ... i will have to change it
888 for the jukebox .... i dont know if anyone else is using it
152 for the trader .... i dont know if anyone else is using it

there again if i change the idno for the members choice ... i have to code the installer to check which one is used before updates can be made

i think its delibrate as the phraseid have to be identical in both tables

Well the phrasetypeid is a real problem with the way hacks are made right now, but this could be solved with some intelligent installer. The question is however, do we want that for 1 hack different phrasetypeid's will be used on every installation. That don't make life easier.

About the permission bitfields, i really think this is a much bigger problem. These normal require manual file edit's, where you must manually check in the sources if a wanted number is still free, and if not decide on a new number. With deciding on a new number it is very easy for a non-coder who don't have god knowledge about how bitfields work, to choose the "wrong" number.

I think it would be a great improvement to hacks released for vB (and thus an improvement of the experience users have with vB) if coders can make good agreements on this, and that jelsoft will support this with a registration system of used id's.

...Either that, or we could use $DB_site->insert_id(); ;)

Just make a function to check if the phraseid/phrasegroupid is available. Then if it's not try another one. It's not hard :) This was done with vB2 hacks and the setting/settingroup table :)

And how to handle the permission bitfields then? Not in this way. Maybe we can find a way if we make good agreements among hack developers.

Permission bitfields is a different issue. There's no real way I can see at the moment of getting around it other than documenting what to do when there is a clash :)

Hmm must think, there must be something possible i think, but that would involve some piece of standard code (buildin? SDK?) that all coders should include in their hacks if they wanted to use bitfield permissions.

Yes but what ever is decided ALL coders have to follow the same path .... if they dont the whold thing will screw up again.

how damn easy is it just to register phraseid nos or bitfields into a db table for each hack that requires it .... it would be very easy to code and even easier for coders to comply ..... if the number that they want to use is taken by another hack, think of another number ..... then mycates and others like him wont have to manually uninstall 2 hacks and start over


what could be more simple?

PS .... it minght make plp installing hacks ask if the phraseid has been registered ... or even look it up in the db ...... i would think twice about installing a hack if i knew that the install could crash due to another hack using the same phraseids no's .....

Why are we mastercating about this?

For bitfields, I think the system is abit flawed.
I would think it was a better idea to have a function parse through the array of bitfields (so instead of "[fieldname] => [number],", it would just be "[fieldname],"), adding the incremental bitfield just like we have to do manually now, before running the function currently being ran to prepare the bitfield for SQL insertion.
Then, when the bitfield SQL is converted to array again, a sub-piece of the above function or a different function would parse through the array of bitfields one more time, this time matching up the two arrays thus assigning the correct bitfield with its correct permission field.
This would cause no extra queries, and very little PHP parsing time (unless a bitfield array had 10,000 array keys in it...).

But what do I know, $5 says the vB devs have a much better way lined up for the next vB :)

How many vb noobs out there would have read this thread and know now that there have been a crash between 2 hacks are wanting to install any hacks now incase it happens to them? i wouldnt be feeling very secure installing any hack to my board atm.....

This issue needs urgent addressing before any more crap happens .... its just as well mycates is relativly experiances with php and db's

I'll second that trafix.

Would also be nice if coders together could think of a way that more general functions fon't need to hack into the same place of php-files for every hack over and over again.

For a non-coder (or even for coders ;) an error in editing a file is easilly made, so the less edits, the better.

Maybe I am dumb, but I don't see the problem (except the limited range for phrasetypeids maybe).

If you call add_phrase_type() it will allocate a free id?

Nope, just include this method in your modification and your users won't have a problem. What other modification authors decide to do is up to them :)

im not fremilliar with "add_phrase_type()" as a function, i will have to investigate it :)

About the phrasetype's, this means that all coders will now change their installers to support automatic finding the next available id?
Can't really say that i am satisfied with the response I would be giving support if i wrote an installer according to the "rules" and later some other hack don't assign them dynamic and overwrite my phrasetypes, causing my hack to fail.


And what we can do with the bitfields? Something we can agree on together to avoid future problems?

Remember that in the end the users (admins) of the hack will blame the "product vBulletin" if things don't work how they want or cause them problems. Wether this can be blamed on teh core product or not.

Finding the next available phrasetype ID is the most responsible way to do this: you cannot be responsible for toher coders, only yourself.

Making a mountain out of a molehill is not the way to get around a molehill.

@MarcoH64
If all coders would use the standard vBulletin function add_phrase_type() instead of using their own code there would have never been a problem.
So I think nobody can blame vBulletin or Jelsoft for causing problems, only the coders who don't use common API.

As for bitfields: I'd vote to make a note in the manual that standard bitfields should be left untouched.

adding extra bitfields is easy isn't it? its always seemed that way to me... just multiply the last number in it by 2 not hard to write some dynamic code modifications to deal with that...

let me throw some code together... and work this out.

the above makes the bitfield echo out quite nicely so you can see whats allready there. step 2 is to create something to dynamically create the code to add and where to add it. be back in 20mins or so :p

not 100% complete but you get the idea... its not hard to do.

Where is this (and all the other) "common" API's documented ?

includes folder :)

@carnage
Well, even if you assign the value dynamically you can never be sure that future vBulletin versions won't ust it for its own purposes - and then ppl will wonder why hacks that rely on a certain bit don't work any longer.

well if they do when the instal script is re-run to install it after the upgrade, the bit field will be dynamically assigned to a higher number.

Yes but you would loose all permissions set prior to upgrade in best case scenario. Worse case the 'old' permissions of that hack are now being used (without being reset, since they in the eyes of jelsoft already where all 0) by some new standard permission, giving unwanted people access.

Worst-Case Scenario:
Jelsoft introduces a new Bit "Is Superadmin" (eg. does have all admin privileges) in usergroup permissions - while your hack used it for <place smth. harmless here>.
Now users unaware of this upgrade and - BANG

Huh ?

They are not documented anywhere as far as I can see, people are not going to use things they don't know about.