vb.org Archive
Page 4 of 7 « First 23 4 56 Last »
Show 40 post(s) from this thread on one page

vb.org Archive (https://vborg.vbsupport.ru/index.php)
-   vB3 General Discussions (https://vborg.vbsupport.ru/forumdisplay.php?f=111)
-   -   phraseid numbers ..... big problem! ... i warned that this would happen! (https://vborg.vbsupport.ru/showthread.php?t=74373)

Marco van Herwaarden 01-25-2005 10:21 AM
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
Quote:
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 01-27-2005 12:25 AM
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 01-27-2005 12:49 AM
@MarcoH64
Quote:
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 01-27-2005 03:28 PM
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 :p

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 01-27-2005 04:20 PM
Quote:
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 01-27-2005 04:46 PM
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 01-27-2005 04:54 PM
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 01-27-2005 08:37 PM
Quote:
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 01-27-2005 09:27 PM
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 01-27-2005 10:35 PM
Quote:
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.


All times are GMT. The time now is 03:53 AM.
Page 4 of 7 « First 23 4 56 Last »
Show 40 post(s) from this thread on one page

Powered by vBulletin® Version 3.8.12 by vBS
Copyright ©2000 - 2025, vBulletin Solutions Inc.

X vBulletin 3.8.12 by vBS Debug Information
  • Page Generation 0.01210 seconds
  • Memory Usage 1,771KB
  • Queries Executed 10 (?)
More Information
Template Usage:
  • (1)ad_footer_end
  • (1)ad_footer_start
  • (1)ad_header_end
  • (1)ad_header_logo
  • (1)ad_navbar_below
  • (2)bbcode_php_printable
  • (5)bbcode_quote_printable
  • (1)footer
  • (1)gobutton
  • (1)header
  • (1)headinclude
  • (6)option
  • (1)pagenav
  • (1)pagenav_curpage
  • (4)pagenav_pagelink
  • (1)post_thanks_navbar_search
  • (1)printthread
  • (10)printthreadbit
  • (1)spacer_close
  • (1)spacer_open 
Phrase Groups Available:
  • global
  • postbit
  • showthread
Included Files:
  • ./printthread.php
  • ./global.php
  • ./includes/init.php
  • ./includes/class_core.php
  • ./includes/config.php
  • ./includes/functions.php
  • ./includes/class_hook.php
  • ./includes/modsystem_functions.php
  • ./includes/class_bbcode_alt.php
  • ./includes/class_bbcode.php
  • ./includes/functions_bigthree.php 
Hooks Called:
  • init_startup
  • init_startup_session_setup_start
  • init_startup_session_setup_complete
  • cache_permissions
  • fetch_threadinfo_query
  • fetch_threadinfo
  • fetch_foruminfo
  • style_fetch
  • cache_templates
  • global_start
  • parse_templates
  • global_setup_complete
  • printthread_start
  • pagenav_page
  • pagenav_complete
  • bbcode_fetch_tags
  • bbcode_create
  • bbcode_parse_start
  • bbcode_parse_complete_precache
  • bbcode_parse_complete
  • printthread_post
  • printthread_complete