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 :)