http://news.netcraft.com/archives/2005/07/04/php_blogging_apps_vulnerable_to_xmlrpc_exploits.html
single quotes? whodathunkit?
I wouldn't be so inclined to say that all PHP users are dumb. There are a lot of PHP utilities out there that are very secure. PHPNuke is not one of them.
It's not a flaw in a PHP utility, it's a flaw in a PHP library that's fairly widely used. Furthermore, it's a really, really idiotic mistake that any decent programmer should have understood not to make.
Snarky!
It's so cute how he blames it on the programming language instead of the crap libraries and crap code that uses the crap libraries. Nothing wrong with the language (other than a bad case of the ugly stick)
The language was just following orders!
>>6 The guy who wrote it (a friend of mine) and his wife are both programmers and have many bad experiences with PHP. Now they are both very much fans of Python, and little else.
The bug was eval() being used inappropriately, but on a deeper level it had to do with the way that in php, string interpolation is done via the grammar of the language.
For the purposes of the example, I'll illustrate a non-stupid usage in PHP of string interpolation, SQL.
execute("UPDATE foo SET age = '$age' WHERE id = '$id'"); seems perfectly reasonable, except that in this instance, we have a situation where an attacker could 'inject' data into the sql query by crafting a string
?age=14',access_level='admin
Giving the attacker's user account admin access.
The solution is to use mysql_quote_string, making the code more verbose, i.e.
mysql_query("UPDATE foo SET age='".mysql_escape_string($age)."' WHERE id='$id'");
But this isn't right yet, there's a possibility that gpc_magic_quotes is on, in which case you have to remove those quotes before you do this, otherwise you\'ll get that nasty bug where \' quotes get a \\ infront of them when they\' retrieved from the database. (bash.org suffers this at the moment).
so:
if (get_magic_quotes_gpc())
$age = stripslashes($age);
mysql_query("UPDATE foo SET age='".mysql_escape_string($age)."' WHERE id='$id'");
But! that's wrong again. This can be attacked based on what combination of mysql character encoding is being used, so we have to change this again:
if (get_magic_quotes_gpc())
$age = stripslashes($age);
mysql_query("UPDATE foo SET age='".mysql_real_escape_string($age)."' WHERE id='$id'");
Okay, now that's all over, lets look at how a real language handles it. Instead of using string interpolation that requires the above series of backflips to escape each untrusted argument, and very_long_function_names and string concatenation to break the very feature that makes php string interpolation easy, this is how to do the same kind of thing in perl or python, two other scripting languages.
$db->execute("UPDATE foo SET age=? WHERE id=?", $age, $id);
and
db.execute("UPDATE foo SET age=%s WHERE id=%d", (age, id))
By doing string interpolation via a library call that is aware of the specific needs of the database, it's possible to moot the entire issue.
PHP is stupid, and so are its users for putting up with this crap.
/me applauses in the background.
And here I used to wonder why Perl's DBI did that. Great post.
"mysql_real_escape_string" is a totally hilarious function name.
"Nah, we were just kidding about that one. Here's the real one!"
My favorite is mcrypt_module_get_supported_key_sizes. Hey, self-documenting code is good, but that's over the top.
There's also gems like recursiveiteratoriterator_getsubiterator.
>>9
That was most enlightening, thank you. As a "young" PHP coder (scripter?) I'm aware of these issues, but didn't know how they could be exploited until now. So far my practise has been to sanitise every bit of input from the client. I don't know if this is too inefficient or kludgy for other uses, but for me it's perfect.
PHP has better things, though. PEAR has a DB interface module that I believe does things like that to make it all safe. (syntax like C's printf where it's correct to do printf("%s", stringVar) and whatnot. I haven't heard of any vulnerabilites with it, but then, I haven't checked. Either way, it's a much nicer interface than using lots of ugly PHP function calls.
class DBI {
function DBI($server,$user,$pass,$base) {
if (isset($this->cxn)==false) {
$this->cxn=mysql_connect($server,$user,$pass) or die("Connection error.");
mysql_select_db($base,$this->cxn) or die("Database selection error.");
}
}function clean($call) {
if (get_magic_quotes_gpc()==0) {
//This will hopefully kill injection attacks. Hopefully.
$call=mysql_real_escape_string($call);
}
return($call);
}
function myassoc($call) {
//echo($call."<br />");
return(mysql_fetch_assoc(mysql_query($this->clean($call))));// or return null;
}
function myresult($call) {
//echo($call."<br />");
$dog=mysql_query($this->clean($call)) or die(mysql_error()."<br />".$call);
if ($dog===false || mysql_num_rows($dog)==0) {
return(null);
}
return(mysql_result($dog,0));
}
function myquery($call) {
//echo($call."<br />");
$dog=mysql_query($this->clean($call)) or die(mysql_error()."<br />".$call);
if ($dog===false) {
return(null);
}
return($dog);
}
} $dbi=new DBI("server.xyz","username","password","database);
$result=$dbi->myquery("blah blah blah")
That can't work, can it? It'll escape all the quotes that are supposed to be in there too. You need to separate out the inserted values and the query itself.
Aw, hell. Well, the code works flawlessly if Magic Quotes is on, but I tried turning it off in php.ini, and sure enough, it severely broke things. Hmm, and I thought I was just around the corner from shipping this thing, too. Good thinking.
Ah well, it probably won't be that bad. I can just take the clean() call out of the myassoc()/myarray()/myquery() functions, then just run clean() on every bit of text that comes in otherwise. Fixing this shouldn't take too long. Thanks again for the heads-up; just as with other things, it often takes another pair of eyes looking over someone's code to see where they screwed up.
(Heh, maybe PHP users really are dumb...)
Perl fanbois can get quite idiotic, bash PHP, and bash PHP programmers, when it's they who are bad PHP programmers.
mysql_query(sprintf("UPDATE foo SET age='%d' WHERE id='%s'", $age, $id));
That's the equivalent to Perl's. And BTW, you shouldn't be calling mysql_query directly. Instead, use a DB abstraction layer, like ADODB, PDO, etc.
So stop bullshitting and learn proper PHP first if you want to point out its flaws.
Hey, when you can't drive, don't blame the car.
age so you can rage
Uh... yeah.
$id="0'; UPDATE foo SET access='admin' WHERE id='me';"Does your code snippet there protect against that? The only thing sprintf will do is protect you against insertion in number arguments. Strings will still leave you wide open for attacks. You are missing the point completely.
The only language I've seen that didn't accidentally encourage bad programming practices is Pascal, but it's not used much professionally. PHP's strong suit is string parsing and handling, but it's up to the individual programmer to recognize when commands and functions get too powerful. PHP's weakness is that its low entry barrier doesn't discourage sloppy programming.
PHP users are dumb only in the same vain that Basic programmers or Bash scripters or C++ programmers are dumb: The techniques for good solid programming have been taught for decades, regardless of language, but too few programmers recognize the consequences of skipping basic data sanity checks, even after getting bit by the resulting bugs.
One thing Perl has that PHP doesnt: Taint checking
Y'see, with taint checking on, it forces the code and the programmer writing it to be more secure about vars/arrays that have values set by the user. You then regex/substr/whatever any data that was inputted, "untaint" it, and voila! More security. To do that in PHP requires a bit more, umm.. is it even possible?
Yes, it's possible, and it's good programming practice to treat external arguments as tainted whether the language forces it or not. Don't get me wrong; I'm not knocking Perl here, but I'm saying dumb programmers exist and are programming in all kinds of languages, online and off, not just in PHP.
So why is it all the dumb ones seem to hang around PHP more than the others?
That's easy: Because PHP targets newbie programmers. There's nothing wrong with that, as I've said earlier - the problem is that PHP doesn't protect protect them from making dangerous mistakes when writing things they do not fully understand. At least, that's part of the point of >>9.
>>26
Perhaps it was a mistake to make PHP [b]look[/b] so easy. The good programmers doing PHP just because it's more productive for certain tasks get bashed all the time by the Perl fanbois.
Which tasks are those, exactly? Mixing HTML and code is one, but that doesn't seem to be what you're referring to.
>>28
I was referring mainly to that, besides some system scripting (where I'm using both Perl and PHP depending on what I feel like using).
>Mixing HTML and code is one
This is actually considered bad practice nowadays. I personally can't stand scripts that mix HTML output with code... they're an eyesore, and they cause you to have to read or write at least two files' worth of code at once (the script and its output). Even for small projects, I'll use templating of some sort.
I think one of PHP's strengths is its ubiquity and its ease with respect to getting it to do its original purpose; that is, chuck output at a web server and to a web client. I considered switching to Python a couple of weeks ago, but it's such a pain for web output, namely because there's so many ways that that can be done; as a slow CGI script, as a FastCGI script, using mod_python, using Python's built-in web server and/or a server built in Python itself... What a mess! Is there any way to write a single script that will work the same on all possible setups? With PHP, it's not a concern.
(I'm still possibly interested in switching, though, so the question above is not rhetorical if someone knows the answer...)
> This is actually considered bad practice nowadays. I personally can't stand scripts that mix HTML output with code... they're an eyesore, and they cause you to have to read or write at least two files' worth of code at once (the script and its output). Even for small projects, I'll use templating of some sort.
And yet, this is the one thing I think PHP was ever good at. And thus it seems to me that PHP is busy abandoning the things it was designed for and was good at, in exchange for becoming a solidly mediocre scripting language. It is as if the language has this huge inferiority complex towards the other scripting languages, and wants to be just like them.
> I considered switching to Python a couple of weeks ago, but it's such a pain for web output, namely because there's so many ways that that can be done; as a slow CGI script, as a FastCGI script, using mod_python, using Python's built-in web server and/or a server built in Python itself... What a mess!
So flexibility is a drawback now? If Python is anything like Perl in this respect, you'll only need to follow some basic good programming practices to run properly on anything. Also, you can just design to be run as a normal CGI script, which is the overwhelmingly most common option.
> Is there any way to write a single script that will work the same on all possible setups? With PHP, it's not a concern.
...and I can't just let that one slip by: What about the myriad of different PHP installation options? Magic quotes? Safe mode? Differing PHP versions and installed modules? Don't go pretending PHP is some perfectly homogenous environment.
> It is as if the language has this huge inferiority complex towards the other scripting languages, and wants to be just like them.
Not rly, but there seems to be a lot of anti-PHP fanbois for some reason, who will bash even its name.
> What about the myriad of different PHP installation options?
Ever heard of ini_set(), pal? Learn to use PHP properly before being a fanboi against it.
> Many settings, although they do get set, have no influence in your script.... like upload_max_filesize will get set but uploaded files are already passed to your PHP script before the settings are changed.
> [[[Editors note: Yes, this is very true. Same with register_globals, magic_quotes_gpc and others. ]]]
Why am I, who knows hardly anything about PHP, correcting you here? It's easy enough to dismiss anyone who has an opposing opinion to your own as a "fanboi", but it neither makes for good discussion, nor does it make you look very clever when you go ahead and get it wrong.
Next up, try presenting some actual arguments and opinions beyond simple personal attacks, OK?
I don't know enough about PHP, so I've been largely avoiding this joyous thread. However, I took a look at the documentation for ini_set(), then looked at all directives listed in the appendix.
Yikes that's ugly.
>So flexibility is a drawback now?
Of course not; flexibility is why I want to switch to Python for all my projects in the first place. I guess you could say, though, that Python is so flexible with respect to web apps that I have no idea where to start with one.
>...and I can't just let that one slip by: What about the myriad of different PHP installation options? Magic quotes? Safe mode? Differing PHP versions and installed modules? Don't go pretending PHP is some perfectly homogenous environment.
You have a point, though, from my experience, most installations are fairly "normal," and it's not that hard to stick with standard PHP modules. But I was speaking with respect to just getting output to the web client.
Ignore what >>32 says about ini_set(). As far as I can tell, that only works if you have permission to tweak those settings, which isn't likely if you're using a shared server.
>most installations are fairly "normal,"
To expand on this a bit, if you're a hosting company, you have pretty good incentive to use a set-up of PHP which is widely compatible, because you're not going to want to deal with support tickets from every schmuck who follows the installation directions for phpBB to the letter but still can't get it to work because you've tweaked some esoteric setting or other. Most of those settings are for people who are running their own server and need to specifically tweak PHP just for their needs. This is why, aside from some common tweaks (magic quotes namely... safe mode has no effect on 99% of scripts), having to adapt your script for different PHP environments isn't an issue.
Well, the same is true for other languages (although I guess you are already heading towards esotericness by using Python in the first place), and in the case of Python the common case would be plain CGI. That's what you'd design for if you wanted a script everyone can use. If you were designing for a webserver you have full control over and wanted to tweak for speed, you'd probably be using mod_python. The rest are fairly esoteric.
I haven't used mod_python, but the corresponding mod_perl will run normal CGI scripts as long as they follow some simple guidelines. It also offers some additional features that aren't available to CGI scripts, but if you don't use those, it's easy enough to make scripts that run on either.
I don't know, mixing code and html is no problem when using, let's say ruby on rails, but I've seen some awful stuff with php and some of the java frameworks out there.
The important thing is separating your presentation layer from the others and keeping the presentational code simple, readable and keeping as much logic away from it as possible.
That's true for large apps, but for quick hacks, nothing beats mixing code and HTML. And I always though PHP was good for the latter but not as much the former, yet the direction the developers of the language have taken has been consistently away from the former.
The PHP developers don't seem to know what they're doing at all, dragging the language in several directions at once and trying to fit every programming paradigm in a language that's only good for the simplest of the simple dynamic websites.
∧＿∧ ∧＿∧ ∧＿∧ ∧＿∧ ∧＿∧
（ ・∀・） （ ｀ー´） （ ´∀｀） （ ﾟ ∀ﾟ ） （ ＾∀＾）
（ つ┳∪━━∪━∪━━∪━∪━∪━┳⊂ つ
｜ ｜ | ┃This thread has ended┃ ｜ ｜ ｜
（_＿）＿） ┻━━━━━━━━━━━━━━┻（_＿）＿） Thank you.
The way PHP was envisioned on working is in a broken way. By default PHP supports and pushes for the mixing of business and presentation logic.
To by default PHP supports very bad practices.
Even worse the lead developer of PHP said he doesn't know how to make a programming language. This is obvious. Just look at the shitty syntax in PHP, the arbitrary function names, the 49 different functions which the do exact same thing.
relevant?
There's not all that much wrong with PHP. If it didn't have crazy scoping rules and $ variables I wouldn't have much that I'd complain about.
Those can be disabled in .htaccess, as far as I know.
"those" are magic quotes
>Although register_globals now defaults to off in the PHP distribution, the majority of web hosting providers re-enable it
Um... not.
even PHP is most user create their Homepage with... is because PHP have GPL license.. i Can't say PHP is very tought.. He has weakness tooo...
BTW... is good if your languages using class.. not only simple echo echo procedure..
>>39 I agre with u... mixing html with php is wrong... u should use bbcode instead and re produce using procedure before show in HTML/homepage
>>52 is exceptionally on-topic, I'm thinking.
>>53
i concur.
Ouch. lol
i have no idea what this does, but it showed up as a result in a google search and i thought it might be relevant:
http://www.64bit-world.com/forums/impex/tools/cleaner.php
Wow, that's awesome. Listing the contents of all private messages at the end is a nice touch!
>>56-57
i would tell them about it, but...
http://www.64bit-world.com/modules.php?modid=4
and i was also unable to figure out how to post on their forum... kept giving me some nonsense about "You are not logged in" and "The administrator may have required you to register before you can view this page."
Send it to webmaster@64bit-world.com and maybe a few made-up names @64bit-world.com (since IPS often redirect it)? Use a throwaway mail account if you do, though, people who keep such pages live may not understand you're doing them a service by notifying them.
Thanks all
>>62
You're welcome :)
> vBulletin Message
> No Thread specified. If you followed a valid link, please notify the administrator
lol, how nice of them.
>>61
lol, they fixed dis, but forgot about www
http://tinyurl.com/75k8f
In response to topic. Duh.
When following design patterns like Model-View-Controller (MVC) in PHP, it is important that the the HTML View code is well separated from control code. I see most people doing this using a template system like smarty. But can template systems become bloated and effect performance?
I like to use the PEAR libraries (http://pear.php.net/) as much as posable for their stability and easy to use APIs. However, PEAR does not seem to have a fully featured template system that works well with other PEAR components like HTML_QuickForm and DB_DataObject.
Can anyone suggest the best template system to use with PEAR for building web apps?
PHP is the best templating language you could use with PHP. Bad template systems make it harder to get stuff done, and great ones merely make it more complicated, error-prone, and require to learn yet another language.
Well, one of the many advantages of using a templating system is that it makes it easy to tweak the template without worrying about possibly mangling the PHP code itself. So if you want to make it easy for others to design templates for your system, Smarty is the way to go.
Also, Smarty has a resource-saving caching system, which is way better than "live"-rendering everything as you would have to do just using raw PHP -- unless you were to write your own caching system.
> So if you want to make it easy for others to design templates for your system, Smarty is the way to go.
what
For a non-programmer, Smarty would be as difficult to learn as some simple php. It'd be hard to beat PHP at being a simple straightforward template language.
PEAR already provides a decent cache, you don't need to depend on Smarty's one.
Choosing a templating system because of a minor feature like a cache doesn't sound very wise, consider what will happen if using this template system is a maintenance nightmare (but hell, what isn't one in PHP).
I'm pretty sure the idea of managing to separate program logic and presentation for something that needs to output HTML is largely a myth. I've tried, again and again, to do this, but no matter what, you end up with HTML in your program code or program code in the HTML (even if the program code is some templating language, it's still code).
For a really simple app, maybe you could pull it off in some meaningful manner, but for anything even a little bit complex, there's just too many cross-dependencies between presentation and logic.
> I'm pretty sure the idea of managing to separate program logic and presentation for something that needs to output HTML is largely a myth. I've tried, again and again, to do this, but no matter what, you end up with HTML in your program code or program code in the HTML (even if the program code is some templating language, it's still code).
That doesn't mean you shouldn't make an honest attempt.
I like the way Wordpress or Ruby on Rails apps do it:
The first uses PHP files as the templating language. You use well-documented functions to fetch data, so the templates are really flexible, yet free enough from business logic, especially since plugins are quite easy to write.
In Ruby on Rails, the views are .rhtml templates which work a lot like PHP, which look like this:
<% @things.each |thing| %>
<div class="thing">
<%= link_to thing.name, :action = 'show', :id = thing %>
</div>
<% end %>But you'll still often code methods that spit out some HTML snippets outside of the views.
If you want to suceed at web applications, you certainly need a lot of discipline and to never allow a prototype to grow into a module without some serious clean-up, but you shouldn't follow the MVC approach all the way: the end users don't want to interact with applications, but with websites, and most web apps (especially PHP ones) feel way too stiff because coders are too disciplined to know when to blur the line between code and data.
The key to keep the website agile and the app seamless is to know the rules, to apply them religiously, and to break them all the time. That's really hard.
Well, sorry for going way off-topic.
>>71
I'd settle for the code in the HTML being side-effect-free and just evaluating simple expressions, perhaps based on cookies for instance.
>>74
It was a response to >>71. "Code" in the HTML is okay by me, provided it only consists of expressions to be evaluated and spliced into the output, and it doesn't change any data on the server, i.e. no side effects. In an imperative language, that really means just write code that gets some data and prints it, nothing more.
>For a non-programmer, Smarty would be as difficult to learn as some simple php. It'd be hard to beat PHP at being a simple straightforward template language.
Yes, if the non-programmer is trying to do programming-type stuff with the templates. But if they're just trying to make simple changes to the appearance of the rendered page, then it's best to keep them separated from the actual code which they could accidentally mess up, and they'll feel much less uncomfortable looking at it. A page marked up with Smarty still looks mostly like a normal HTML page, whereas if you've combined and interweaved the two, it can get very confusing.
For non-programmers who just want to change the appearance a bit, HTML with bits of non-vital code in it is better than vital code with bits of HTML in it.
>a minor feature like a cache
I would hardly call it a minor feature...
> I would hardly call it a minor feature...
It shouldn't be considered when choosing a templating though. Features like that should be regarded as marketing when deciding wether to use a system, then just as a bonus afterwards.
And it IS a minor feature because any decent templating system should make caching trivial. The hard part is making sure the cache never goes stale, and no template system will do that for you.
Well, that's a good example of what I was talking about. That Ruby -in-HTML code is pretty much incomprehensible to anyone but a Ruby programmer, and thus, the only person who can safely work with the HTML templates is still the programmer.
>>78
Yeah, this is why the code in the HTML should just be expressions to evaluate (i.e., math, basically).
>>78,79
I still don't think it's good enough a reason to use 'dumb' templates. They cause inflexible apps, where the designer is only allowed to write HTML loops in a well-defined zone of the page and just insert placeholders. Sites made this way often look like data dumps straight from the DB, with a lot of needless metadata around, and a lot of opportunities to make the user's life easier lost.
I think that the designer must be able to do very basic programming (loops, conditional logic), and the coder must understand design (but doesn't have to be talented). Ideally, they should be the same person, but that isn't often possible. The coder should be able to do most of the HTML the designer requires, so that the designer should only need to work with CSS.
As I see it, the choice is wether to have a programming language, or just having placeholders. In-between options are also possible, but they tend to be the worse of both worlds. I will always go for the first option, because it allows me to do a better work in less time - maybe that's just because I'm lucky enough to be able to do both the app and the design myself, but when I see the limitations and missed opportunities caused by using non-coder-friendly templates, I just think there's no place in web apps for people who aren't versatile enough.
>>80
News flash: You don't need loops to program. Look at any functional or array language.
I am not at all saying the code in the HTML shouldn't be powerful, but writing it in an imperative style would be distracting and easy to mess up.
> News flash: You don't need loops to program. Look at any functional or array language.
Thank you so much for the information! As a designer, I struggled a lot to understand looping over some content for my website, so I hit wikipedia:
> Functional programming is a programming paradigm that treats computation as the evaluation of mathematical functions. Functional programming emphasizes the definition of functions rather than the implementation of state machines, in contrast to procedural programming, which emphasizes the execution of sequential commands. A purely functional program does not use mutation: rather than modifying state to produce values (as is done in imperative programming), it constructs new values from (but does not overwrite) existing values.
This is definitely what I needed for my templates! Oh boy, my websight's gonna be great.
From a webmasters perspective, PHP is a fucking security nightmare. There are about a hundred thousand different ways to execute arbitrary code on a webserver using PHP just by uploading a simple script. Using mod_security on Apache takes some of those out, but even then a badly designed PHP script can open up your server to everyone and everything. This is probably same for other languages, but never has such a bad language existed which allows for such... originality when writing bad code that works yet doesn't.
All in all I've sworn on PHP for being so shitty. Either you castrate it with mod_security (twenty pages of rulesets) so that only dynamic rendering works, or you enable extensions and run the risk of getting your server fucked over in five minutes. And PHP is especially fun because it doesn't support modern threading techniques like Perl or Ruby-On-Rails. No no no, it has to fork off the httpd into a separate process with a separate memory allocation every time a single .php script is run. Thanks guys.
ADMIT THAT RUBY IS AWESOME.
SWITCH FROM PHP TO RUBY.
> ADMIT THAT RUBY IS AWESOME.
> SWITCH FROM PHP TO RUBY.
NEVER.
Or at least not until I ship, I really need the competitive advantage so I'd appreciate it if Ruby kept its 'lol jap crap' reputation for a few additional months.
Ok, this has sat here for days now, and I still don't understand a word of it. What the hell are you talking about?
I think he's working on a commercial product coded in PHP.
Good luck with that.
I think he's a convict and is going to get shipped to Australia.
He's making a product in Ruby, and considers it a competitive advantage. He wants the competition to remain using PHP so he'll have the leg up.
>>88
So he wants to ship something that he hopes remains considered "jap crap"? How does that make sense?
Heh.
Most users (probably) don't care about the underlying language, so long as the software works well.
I still say he stole a loaf of bread and is getting shipped to Australia.
>>91
We don't want him.
>but even then a badly designed PHP script can open up your server to everyone and everything.
That's why if you code a WELL DESIGNED PHP script, PHP doesn't suck and isn't unsecure. Amazing! As posters in the beginning of the thread have stated, learn it before you hate it. It's very possible to code a PHP script which can't simply be altered by outside means.
Of course, I'm going to admit right now though that NO CODE is ever 100% secure. There's always another way in EVERY language where the server can be broken into.
>>93
That's fine in theory. But in practice, I need to use other people's libraries, because re-implementing things would often take more time. And a significant amount of open-source PHP libraries are done by stereotypical dumb php users. Even if you are very security-conscious, there's nothing you can do about it.
And most quality PHP code available will assume you are using a shared hosting environment, aiming for the lowest common denominator in terms of features used.
It is in large part a hobbyist language. You can use it to make secure scripts and quality code, but you just can't rely on the community.
Because of this, I only use PHP for small independant web scripts that won't do anything more complicated than accessing a Sqlite database.
In a way, PHP is a victim of its own success and simplicity, which attracted the attention of crap-writing, copypasta, trial and error n00bs, but this doesn't mean you can't come up with high quality code in a highly productive manner with it, and some libraries are like this. This comes from an expreienced PHP developer who has had to deal with both good and terrible PHP code.
well!! sory about that!!
every code have weakness.. but the person try to find weakness is not bad person..
PHP are dumb.. that shock me up.. but i realise it..
btw... the source php are from perl.
>>96
Thanks for bumping
>>98
lurk more