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

[Marco van Herwaarden]

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

What other modification authors decide to do is up to them

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.

[Natch]

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.

[Andreas]

@MarcoH64

About the phrasetype's, this means that all coders will now change their installers to support automatic finding the next available id?

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.

[Carnage]

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.

PHP Code:

<?php

include("includes/init.php");

foreach ($_BITFIELD AS $KEY => $VALUE) {
        echo "<b>" . $KEY . "</b><br>";
        foreach ($VALUE AS $L1KEY => $L1VALUE) {
                if (!is_array($L1VALUE)) {
                        echo "--" .$L1KEY . "=>" . $L1VALUE ."<br>";
                } else {
                        echo "<b>--" . $L1KEY . "</b><br>";
                        foreach ($L1VALUE AS $L2KEY => $L2VALUE) {
                                echo "----" .$L2KEY . "=>" . $L2VALUE ."<br>";
                        }
                }
                        
        }
}
?>

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

PHP Code:

<?php

include("includes/init.php");

$addto = "adminpermissions";
$addwhat = "candoanything";

//create new bit field
foreach ($_BITFIELD AS $KEY => $VALUE) {
        if($KEY != $addto) {
                foreach ($VALUE AS $L1KEY => $L1VALUE) {
                        if($L1KEY != $addto) {
                                continue;
                        } else {
                                echo "<pre>\$_BITFIELD['" . $KEY . "']['" . $L1KEY . "'] = array(<br>";
                                foreach ($L1VALUE AS $L2KEY => $L2VALUE) {
                                        echo "        '" . $L2KEY . "'    => " . $L2VALUE . ",<br>";
                                        $lastvalue = $L2VALUE;
                                }
                                $newvalue = $lastvalue * 2;
                                echo "        '" . $addwhat . "'    => " . $newvalue . "<br>);";
                        }
                }
        } else {
                echo "<pre>\$_BITFIELD['" . $KEY . "'] = array(<br>";
                foreach ($VALUE AS $L1KEY => $L1VALUE) {
                        echo "        '" . $L1KEY . "'    => " . $L1VALUE . ",<br>";
                        $lastvalue = $L1VALUE;
                }
                $newvalue = $lastvalue * 2;
                echo "        '" . $addwhat . "'    => " . $newvalue . "<br>);";
        }
}

?>

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

[Paul M]

Originally Posted by KirbyDE

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

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

[Andreas]

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.

[Carnage]

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.

[Marco van Herwaarden]

Originally Posted by Carnage-

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.

[Andreas]

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

[Paul M]

Originally Posted by KirbyDE

includes folder

Huh ?

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