Are we in the admin folder?



  • Okay, here is the code which has caused me so many headaches:

    // require_once "../common/common.php";
    if (eregi("supporter", $_SERVER[PHP_SELF]) || eregi("admin", $_SERVER[PHP_SELF]))
        require_once "../lang/$default_language.lang.php";
    else
        require_once "lang/$default_language.lang.php";


     It's PHP, and it's part of a Helpdesk tracking package called One Or Zero. (I should also post a bug report with them, but posting here first is somehow more satisfying...)

    The PHP_SELF bit is the path to the currently executing script. The eregi() checks to see if that path contains the text "supporter" or "admin." This is because if you are in one of the scripts in the root level, you ned to include ./foo, but if you are in one of the scripts inside the directories with those names, you need to include ../foo

    Unfortunately, if you happen to install the package inside a directory with a name containing the text 'admin,' it explodes. (I learned that the hard way...) I couldn't figure this out for the life of me until another guy sat down with me to help me debug my installation. We saw this line about halfway through the process, long before it occurred to him that it was the cause of the problem. He pointed it out as being ugly. I actually said "Sure, it's a bit ugly, but it's not like it would hurt anything." I regret having defended it now. :)



  • @forkazoo said:

    if (eregi("supporter", $_SERVER[PHP_SELF]) || eregi("admin", $_SERVER[PHP_SELF]))

    Why did they use eregi? Why not strstr, strpos, or something more lightweight? And if they are addicted to use eregi, then why didn't they use it to check for 'supporter' or 'admin' at the same time?



  • Why do they even use a relative path for this "lang" directory?  Since it doesn't move when you change directories then get it right once as an absolute path and forget about it.  Don't forget to send a patch back with that bug report.

     

     



  • Although this is probably the wrong place to ask, is indexOf or strPos typically faster than a regex matches in most languages? I used to use them to quickly check strings for a substring. When I felt comfortable with regex, I used it instead, feeling as though it was "cleaner," but probably only in the sense that it was more powerful and returned a "real" result instead of a number that I'd have to compare to -1.

    Any thoughts are appreciated (BTW, if it matters which langauges, I code mostly in PHP, JavaScript, Java, and ActionScript)...

    Edit: It might also be worth mentioning that if using it for said simple substring search, I don't use /g, which I assume cuts some time off?



  • I have my doubts about code quality. They should take a look at some of the better open source packages and learn from them.

    Btw: the language file is called <English.lang.php> - i find that rather... stinky<FONT size=2>

    </FONT>


  • @boolean said:

    Although this is probably the wrong place to ask, is indexOf or strPos typically faster than a regex matches in most languages?

    strange thing, i was certain that indexof should be much faster than regex, but my quickly put together test script in perl showed that regular expressions are consistently three to four times faster than substring matches, which makes no sense. for the record, i am matching 600000 random 10-character strings against a random 20000-character string (all strings are only lowercase letters). i'm comparing ($target =~ /$match/) against (index($target, $match)). the random string sets are the same for the regex loop and for the substring loop.


Log in to reply