[PHP-DB] --with-mysqli and --with-mysql
Howdy list, http://us2.php.net/manual/en/ref.mysqli.php under "Installation" is says: "If you would like to install the mysql extension along with the mysqli extension you have to use the same client library to avoid any conflicts." So, assuming PHP5 and MySQL > 4.1.3: These are the two ways to do both --with-mysql and --with-mysqli correct: a) --with-mysql --with-mysqli=/path/to/mysql_config b) --with-mysql=/usr --with-mysqli=/usr If not, whats the proper way to do --with-mysqli with: a) -with-mysql b) --with-mysql=DIR TIA! -- PHP Database Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DB] --with-mysqli and --with-mysql
Howdy list, http://us2.php.net/manual/en/ref.mysqli.php under "Installation" is says: "If you would like to install the mysql extension along with the mysqli extension you have to use the same client library to avoid any conflicts." So, assuming PHP5 and MySQL > 4.1.3: These are the two ways to do both --with-mysql and --with-mysqli correct: a) --with-mysql --with-mysqli=/path/to/mysql_config b) --with-mysql=/usr --with-mysqli=/usr If not, whats the proper way to do --with-mysqli with: a) -with-mysql b) --with-mysql=DIR TIA! -- PHP Database Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DB] --with-mysqli and --with-mysql
JupiterHost.Net wrote: Howdy list, http://us2.php.net/manual/en/ref.mysqli.php under "Installation" is says: "If you would like to install the mysql extension along with the mysqli extension you have to use the same client library to avoid any conflicts." So, assuming PHP5 and MySQL > 4.1.3: These are the two ways to do both --with-mysql and --with-mysqli correct: a) --with-mysql --with-mysqli=/path/to/mysql_config b) --with-mysql=/usr --with-mysqli=/usr If not, whats the proper way to do --with-mysqli with: a) -with-mysql b) --with-mysql=DIR As per: "Compiling PHP5 with mysql and mysqli Database Drivers" at http://www.johnberns.com/ seems to indicate that --with--mysqli=/path/to/mysql_config applies to both "a" and "b" Is that indeed the case? That is what is necessary and will make sure that it will "use the same client library to avoid any conflicts" ? Is "[7 Sep 2004 7:52am CEST] [EMAIL PROTECTED]" at http://bugs.php.net/bug.php?id=29860 true? Also when does the broken Makefile in regard to this expected to be fixed? -- PHP Database Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DB] --with-mysqli and --with-mysql
So PHP5 can't so mysql and mysqli together? Perhaps this project would be better suited by Perl or Python since apparently PHP5's mysql support is too ambiguous. JupiterHost.Net wrote: JupiterHost.Net wrote: Howdy list, http://us2.php.net/manual/en/ref.mysqli.php under "Installation" is says: "If you would like to install the mysql extension along with the mysqli extension you have to use the same client library to avoid any conflicts." So, assuming PHP5 and MySQL > 4.1.3: These are the two ways to do both --with-mysql and --with-mysqli correct: a) --with-mysql --with-mysqli=/path/to/mysql_config b) --with-mysql=/usr --with-mysqli=/usr If not, whats the proper way to do --with-mysqli with: a) -with-mysql b) --with-mysql=DIR As per: "Compiling PHP5 with mysql and mysqli Database Drivers" at http://www.johnberns.com/ seems to indicate that --with--mysqli=/path/to/mysql_config applies to both "a" and "b" Is that indeed the case? That is what is necessary and will make sure that it will "use the same client library to avoid any conflicts" ? Is "[7 Sep 2004 7:52am CEST] [EMAIL PROTECTED]" at http://bugs.php.net/bug.php?id=29860 true? Also when does the broken Makefile in regard to this expected to be fixed? -- PHP Database Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DB] Future Event
Mark Bomgardner wrote: Is there a way in php to execute a SELECT statement in the future? What only if its running in the future :) You can trigger it when a visitor visits your page but what are the chances someone will visit it at 2:000 AM exactly every night? You can run it as a daemon, which woudl be kind of stupid, plus if they don;t let you run cron they probably don;t want a script to run 24/7 just to send an email at 2:00 AM You can cron it. You can cron a script on a different server to run your script on the non-cron machine via SSH, HTTP, etc... BTW, this applies to scripting of any kind, Actually there are soem Perl modules that can do this, have you looked on CPAN? I am wanting to do is use a page to parse a database at a future time. I want to send out some email about an event I am putting on, but I don't want to execute the select statement until 2:00am. I could use cron for this, but I would perfer not, as I am writing an application in which cron may not be an option. Is there 3rd party engines that will do this? Yes, Cron is one that 99% of servers will have and several Perl Modules on CPAN. -- PHP Database Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DB] Mail Function
Mark Bomgardner wrote: I have been racking my brain for the better part of a day with a simple mail function. I am trying to generate a list of events from MySQL and then use the php Mail function to email the list in an html email to a mailing list. I keep getting a parse error on a section that I can not figure out why. ok, this is a general PHP question not realy a php-db type but 'sall good ;) a) the parse error is likely form a rogue quote (in the html perhaps) making a syntax error, hard to say with out the actual error b) are you sure mail() can tell that that is html and create the appropriate multi part MIME message? Highly doubtful since all mail() does is pipe the data to sendmail, I'd recommend using a valid MIME/SMTP tool like Perl's Mail::Sender::Easy module (http://search.cpan.org/perldoc?Mail::Sender::Easy) You can easily use Perl's DBI to do your MySQL query so there really is no need to try to hack up PHP's lame mail() function to do something it simply can't. HTH -- PHP Database Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DB] Renaming a table once it has been created
Ron Piggott (PHP) wrote: Is there a way to re-name a table once you have created it? Ron Depending on the type of DB some sort of ALTER TABLE statement I imagine, not sure what this has to do with PHP though... -- PHP Database Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DB] Passwords
Benjamin Stambaugh wrote: Hi, I have created a user login/registration page. As of now I am using a MySQL database to store the info of the user. To validate the user I also have the password stored in the same DB. I was wondering if there is a way that I can store the password in the DB so that it is encrypted or something. Just so it is not in plain text. Sure, mysql.com and seasrch for crypt. Not sure why this is asked on a PHP list since it has nothing to do with PHP. -- PHP Database Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DB] Passwords
Bastien Koert wrote: Not PHP? Correct, not PHP. most DB engines have built in encryption funtions for use in their INSERT (IE "store the password in the DB so that it is encrypted") and SELECT (for verifying it with the same funtion you used in INSERT) http://us3.php.net/crypt yes "Not PHP": a) crypt() has nothing to do with a query b) every language has a crypt function The question has more to do with a general idea of how to accomplish a task, the most suitable answer to is to be had in their DB documentation, since data should be independant of the language handling it (whether it a real language like C or Perl or a wanna be duct taped hack like PHP - no need for flames, I won't listen or care ;p) -- PHP Database Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DB] Passwords
Dwight Altman wrote: Sure, mysql.com and seasrch for crypt. Not sure why this is asked on a PHP list since it has nothing to do with PHP. b) every language has a crypt function Then I guess it's okay to have crypt questions/answers on "every language" list. Sure whatever, its just this list is specifically about PHP and DB use so PHP's crypt() is pretty much the lamest recommendation since most DB sngines have lots of good encryption and you can use it in your queries. So then they need look in theri DB's documentation for what their type/version offer. At that point it has 100% nothing to do with PHP :) If they just want to crypt() some string for an /etc/passwd type system then they need to post to a PHP basics list not a DB specific one. Not really a big deal but why have specofoc lists if they arn't kept specific :) -- PHP Database Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DB] test
Paul Anderson wrote: new user test please don't do tests to a public list, its spam -- PHP Database Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DB] Unable to Send Mail
We are having problem with ONE function. Any time a php script or form is supposed to send a response or email to us or a user, or the mail is not sent. We have tried various formail.php versions, sendmail.php and written our own most basic scripts. This would be more appropiate for a general PHP list and not one that is PHP/Database specific. -- PHP Database Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DB] Manipulate an image automatically
Henry Ortega wrote: What is the quickest way to manipulate an image? I have a 300x100 image of something (template), and I want text to be inserted to that graphic at a certain coordinate (e.g. lower right), how would I do that? This has nothing to do with databases and PHP, I think you want an image manipulation list or documentation. How about http://search.cpan.org/perldoc?GD HTH :) -- PHP Database Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DB] auto_increment
Ron Piggott (PHP) wrote: How do I change the auto_increment / auto_index value? Ron Do a query that does what you want. Without knowing the type of DB you're using (and since this is a "PHP and Database" list not just specific DB list) or any other info, there really isn't much you can get from here. You should likely ask on a list specific to your question. This will help in your search for info: http://www.catb.org/~esr/faqs/smart-questions.html -- PHP Database Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DB] auto_increment
Ron Piggott (PHP) wrote: I am using mySQL In that case, mysql.com woudl have MySQL specific resources since it has nothgin to do with PHP (aside form that is apparently what you're using to interact with MySQL) Please read http://www.catb.org/~esr/faqs/smart-questions.html#forum the entire URL is excellent but that specifric section will apply to this thread. Also *please* do not top post :) -- PHP Database Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DB] PDF BLOB to Email
Adrian Bruce wrote:
Hi
Hello,
I have pdf's stored as a blob in a MySQL database, how can i set a
script (PHP obviously!) to email these blobs as pdf files. The only way
No, not "Obviously", PHP is not well suited for many tasks (or has a
high cost to get the suit tailored) :)
If you branch out you'll find a whole world of alternatives that are
easier to code and maintain server wise. All without the onslaught of
PHP security vulnerabilities and performance bloats.
i can think of at the moment is to write them to disk and then attach
them to the mail before sending it. This doesn't seem that efficient
but perhaps it is the only way??
Nope, its fine to attach it from a variable, in fact an example of how
to do just that can be found at
http://search.cpan.org/perldoc?Mail::Sender::Easy
under the "EXAMPLE" header.
you'd simply:
my($pdf_guts) = $dbh->selectrow_array(q{SELECT pdf_guts FROM pdf_store
WHERE id = '123'}); # http://search.cpan.org/perldoc?DBI
PHP's mail() is a lame lame function with limited ability and even
higher hackability, don't use it.
HTH :)
--
PHP Database Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DB] PDF BLOB to Email
Adrian Bruce wrote: [snip] No, not "Obviously", PHP is not well suited for many tasks (or has a high cost to get the suit tailored) :) [/snip] "Obviously " because i am posting to a PHP list, numpty! but thank you for the recommendation anyway. Obvious in that sense sure ,but just pointing out that there are much much much better alternatives to PHP to do your Database-to-web task. Most PHP folks have this image that since its so shiny its just the best which in fact is the opposite: the nice graphic designers that skin PHP projects do very well (images/css/html which are all independant of PHP), but its like dressing up a turd in silk, its still crap underneath :) -- PHP Database Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DB] PDF BLOB to Email
Most PHP folks have this image that since its so shiny its just the best which in fact is the opposite: the nice graphic designers that skin PHP projects do very well (images/css/html which are all independant of PHP), but its like dressing up a turd in silk, its still crap underneath :) A bit indelicate for posting to a PHP list, don't you think? If that's your Not if there is a better solution for what he's asking how to do :) (Q: how do I get a nail driven in with a wrench A: use a hammer) opinion, please unsubscibe from the list. There's enough negavitiy swirling around the world as it it. I do understand how a PHP list would be offended by negative comments about PHP and I apologize. However the fact remains, that the principles I stated are very true and using PHP for anything but the simplest tasks (unless you have a dedicated server with one admin user and one normal user (IE one website), tops, to run your major app on) is a really really bad idea and its starting to bite people. No offence all :) I love everyone and I wish the best in all your programming endevors. -- PHP Database Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DB] PDF BLOB to Email
I think you're confusing php (the language) with bad programming practices (the developers). They aren't the same. A true enough statement, except what i am referring to is that PHP (the language) lends itself to bad practice and has extremely bad security issues (example: your config info is usually in world readable files so *anyone* can get your database connection info and have there way with your data) and has general unnecessary administration concerns (to add support for the simplest thing can break apache or PHP for the entire server, yeah yeah PECL, PEAR, etc whatever, they're crap). Or why not just touch ~/php.ini and all your "secure" php.ini settings are turned right off (yeah yeah until you do Zend Optimizer's php.ini, but again more bloat for your buck) -- PHP Database Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DB] Sending filing attachments using PHP
Ing. Edwin Cruz wrote: Have a look on this: http://framework.zend.com/manual/en/zend.mail.attachments.html It seems to be easy with zend framework How about a way to do it without having to install a huge system wide binary and configruation that might potentially break apache and all PHP sites? http://search.cpan.org/perldoc?Mail::Sender::Easy -- PHP Database Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DB] PDF BLOB to Email
At the risk of extending empathy where none is given, perhaps you should I do appreciate that thanks :) tell us what experiences have led to your negativism. You've been a subscriber to this list for quite a while, and as far as I can remember, your posts have never been critical of the language. Surely something must have happened... Well, its a long story, actually many ;p I'll break it up in categories and summarize, and I will attempt to be more positive ;p a) development: - no structure, no CPAN - random DB funtionality different combinations of --with-mysql --with-mysqli on versions 4.x and 5.x all behave differently and take different args - likely to not run the same on the same server = More expensive to develop and maintain b) resources: - php *has* to run under apache and optional "optomizers" because its s huge and hoggy = more expensive to run c) administration: - add simple "foo" funtionality you might break apache and you may break all PHP scripts - more support for end user since the user's script that worked on the last server doesn't work on this one (which takes back to the simple functionality adding bit above) = more expensive to operate d) security: - config files are generally world readable (IE anyone on the server can get to your authentication info and have complete access to your data) - directories are generally world writable (IE people ahve uploaded ISOs and stolen bandwidth from other accounts) - php.ini can be overridden so its pointless - I've seen root kits and other malciouse stuff uploaded to "protected" places via the web (IE phpbb patch google attack) - SQL injections and other input attacks because some feature is assumed to be on when it isn;t so the protection never gets applied = much more expensive (lost customers, time, etc) yes you can have this with any langauge given a bad programmer but with PHP you have an inherently flawed system that can unexpected overcome a good programmer. The thing that raaallly irks me is that the general vibe is: "PHP looks nice so it must be nice" when its simply good graphic design covering many hidden dangers and all funtionality and more can be had easier and without all the fuss with so many other technologies -- PHP Database Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DB] Re: Sending filing attachments using PHP
Ron Piggott (PHP) wrote: I came up with some code today. I started e-mailing myself file attachments to see what my e-mail program did in preparing them and when I opened the e-mails I changed the view to "show e-mail source". The biggest challenge is the boundary that separates the e-mail message text from the file attachment. I found this command on php.net here to generate the boundary: You're piping a hand crafted mime message to sendmial via mail()? You are a glutton for pain :) (and oh yeah theres about a zillion MIME issues you've overlooked that will come back and bite you later, gauranteed) use a tool thats made for it: http://search.cpan.org/perldoc?Mail::Sender::Easy -- PHP Database Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DB] Sending filing attachments using PHP
Chris wrote: JupiterHost.Net wrote: Ing. Edwin Cruz wrote: Have a look on this: http://framework.zend.com/manual/en/zend.mail.attachments.html It seems to be easy with zend framework How about a way to do it without having to install a huge system wide binary and configruation that might potentially break apache and all PHP sites? http://search.cpan.org/perldoc?Mail::Sender::Easy The OP is asking for a PHP solution and you point to cpan.. Hmm. Yep, because PHP is not usually (some say *never*) the best solution *and* this *is* a PHP + DB list so the OP actually has nothing to do with thei slist anyway. phpmailer (phpmailer.sourceforge.net) handles everything for you.. even if you want to roll your own, that code will give you a good starting point. Right after rebuilding php and apache and breaking PHP funtionality for everyone, just so you can send a semi complex MIME message? That is the epitome of PHP's lameness and why I can't sit quietly by and not recommend an easy to install and use and maintain solution. And besides its in a non strutcutered way to maek it even more impossible to maintain. Look at the EXAMPLE section of that url, see how incredibly easy and intuitive it is to sent complex emails? And all the server admin has to do is: perl -MCPAN -e 'install Mail::Sender::Easy;' - no fiddling with apache - no fiddling with the interpretet binary - no possibility of breaking anyone's scripts Or else you could do liek the one guy and make your own MIME message but that is even dumber than insisting that PHP has to be used. -- PHP Database Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DB] Re: Sending filing attachments using PHP
Alister Bulman wrote: On 12/05/06, JupiterHost.Net <[EMAIL PROTECTED]> wrote: You're piping a hand crafted mime message to sendmial via mail()? You are a glutton for pain :) (and oh yeah theres about a zillion MIME issues you've overlooked that will come back and bite you later, gauranteed) use a tool thats made for it: http://search.cpan.org/perldoc?Mail::Sender::Easy I agree - don't get bitten on the ass, but OTOH, there's already a PHP Mime encoder - no need to point him to a Perl library http://pear.php.net/package/Mail_Mime Yes there's a huge need, PHP is way to problematic and many folks don't even realize thats its one of a hundred possible tools. Most of which are better suited for most things. Plus, what if you don't have Pear compiled into PHP? Now theres more hoops, oops need zend optimizer, more hoops, oops that version doesn;t work on that verison, more hoops. Oh yeah and you have to be root to do all this, nice. And that module is not a MIME tool in itself, it uses perl's MIME tools and SMTP tools but it abstracts all of that for you so all you have to do is make a hash that represents your mail. No knowlege of SMTP or MIME necessary. And you can install it as a regular user and use it yourself if need be, what could be easier :) -- PHP Database Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DB] Sending filing attachments using PHP
Edward Vermillion wrote: Ummm... dude... Zend Framework is NOT a "system wide binary"... Semantics. The point is its more fiddling, why fiddle (and likely break something) when you don't need to. besides is like way beta right now... fun to play with, sure, but they're not really recommending it for production yet. try phpmailer or some of the other mail classes Getting closer, but now you better hope you have Pear or PECLsupport compiled in, if not, more fiddling Or els e you have to use a php file that has some functions you can use (in no structered or organized way, lame lame lame) -- PHP Database Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DB] Sending filing attachments using PHP
Edward Vermillion wrote: You've made it obvious by all of your replies that you have no idea what you're talking about, so maybe it would be a good time to *not* reply and let the folks that know what they're talking about actually try to help people? Eh? Maybe? a) Im speaking in generalitites of working with PHP not specifics componentss of the technology. b) I am trying to help :) Good day to all, sorry if I was to ambiguouse or I've offended -- PHP Database Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DB] Re: Sending filing attachments using PHP
What planet are you on? Seriously? Because PEAR does not need to be compiled into PHP. Zend Optimizer is no different to the optimizers I was referring to --with-pear, sorry "compiled" was not the right word * available for other scripting languages. Version mismatches are a fact I was referring to how Zend Opt is "required" for some stuff mainly because its necessary to offset the bloat. * of life with all tools, deal with it. And last but not least, you do not And PHP tends to have a greater majority of them, have you ever managed PHP on multiple servers? If you have you kwo exactly what I'm referring to. have to be root to do anything with PHP, or indeed Apache except to I was referring to building PHP/Apache in general * listen on a port lower than 1024, which is true for all tools since it's a platform limitation. * I'm speaking in generalitites of working with PHP not specifics components of the technology. And that module is not a MIME tool in itself, it uses perl's MIME tools and SMTP tools but it abstracts all of that for you so all you have to do is make a hash that represents your mail. No knowlege of SMTP or MIME necessary. And you can install it as a regular user and use it yourself if need be, what could be easier :) Yeah, you're definitely smoking somethin'. The PEAR package Mail_Mime is another example of a pure-php class. It certainly does not use anything perl related at all. I'd really like to know what makes you think it does. I never said PEAR or any specific package used Perl, I'd simply offered a better solution that happend to be done in Perl. Oh, and there's nothing stopping you installing any of the PEAR classes as a regular user and using it yourself. What could be easier? Not having to read your ignorant emails. I was outlining some of PHP faults, not getting personal which truly *is* ignorant. Good day to all, sorry if I was to ambiguouse or I've offended. -- PHP Database Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DB] Sending filing attachments using PHP
Dwight Altman wrote:
" Right after rebuilding php and apache and breaking PHP funtionality for
everyone, just so you can send a semi complex MIME message? That is the
epitome of PHP's lameness and why I can't sit quietly by and not
recommend an easy to install and use and maintain solution."
This command breaks Apache?
require("class.phpmailer.php");
" And besides its in a non strutcutered way to maek it even more
impossible to maintain."
Classes and Object Oriented Programming?
Thanks Dwight, good info.
I'm speaking in generalitites of working with PHP not specifics
components of the technology.
As an example of this general clutter/bloat/mess that PHPs basic
paradigm is see:
http://tnx.nl/php
Disclaimer: Note that that url is a comparison of Perl to PHP, which is
not what I'm saying in all this mess. Just look at each point of PHP and
if you don't see whay iots so bad look at how Perl does it and hopefully
it will make more clear where I'm coming from for at least part of my
argument (the deve part) that PHP has many negatives things about it
that are either not an issue in other langauges or are not nearly as
pronounced or common to run up against.
I'm very sorry if this makes some uncomfortable but note that I'm
pointing out downfalls of PHP, a "thing", I am not getting personal and
would appreciate the same courtesy. (which Dwight and Edward have done,
thanks ;p)
--
PHP Database Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DB] Sending filing attachments using PHP
It's a fact that I can't deny any of the bad points you have exposed about PHP. I even agree with you that most of this problems are really awful and it's pointless to hide them. But the fact that PHP is by preference the language for developing small and middle web solutions aimed to be economic and rapidly developed is also undeniable. All languages have their pros and cons, and trying to compare them outside of the context of the target market is pointless. It just happens that PHP pros fit better the desires of the web solutions market, and they also don't care much about current PHP cons. Most people aren't aware of the cons, thats my point :) For example: If Mr. big wig was aware that phpBB has a history if being uber hackable and even being used in a rootkit scheme a time or two he'd not choose PHP. But its shiny so he says "go with that it looks nice". That is how its popularity has grown, ignorance of the facts. Anyway, this market is evolving and its needs are changing, so it's normal for developers to try and anticipate future development needs and try to make PHP fit into other philosophies, methodologies or technologies it was not designed to work with, and everyone who has tried this (including me) have started to hate PHP in a certain way. But that's all there is to it, I hate not having a proper application framework, I hate not having namespaces, I hate the overhead of working with OOP, I hate magic quotes, but I still use PHP because it is still the most appropiate development enviroment for a small or middle sized web solution. Why not use Perl, it has all the "pros" but does not have the cons :) In fact, I use it for several high volumn websites: - with persistent database connections and persistently running instances of the script (which is the *only* positive PHP has, except it means running PHP as "nobody" and with really really bad permissions) - without doing *anything* with apache - works with SuExec so it runs as the user so the permissions can be 700 and config files 600 - try that with PHP without days of fiddling and breaking stuff and finally giving up ;) Now you have the only "benefit" of PHP (but better) without *any* of its downside. I'm guessing this part, but I think you think alike and that's the reason you're still on this list and trying to make a point out of your bad experiences with PHP. We can still hope that this problems will be solved It won't, for "backwards compatibility" they'll have to keep the cobbled up mess. Or else make it new from scratch and remove the crap, but in that case itd be a brand new langauge and would have all the problems inherent with that :) > Thanks for sharing your opinion and concerns, I really appreciate them. My pleasure, I've been managing hundreds of servers for nearly a decade and PHP has always had seriouse drawbacks. I've really honestly tried to make a go of it but its just to much overhead to be worth it, IMHO :) -- PHP Database Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DB] Re: Sending filing attachments using PHP
Stut wrote: Let me start by apologising if my posts came across as personal. Check If? How else can "What could be easier? Not having to read your ignorant emails." be taken? No worries though I understand, thanks :) What planet are you on? Seriously? Because PEAR does not need to be compiled into PHP. Zend Optimizer is no different to the optimizers I was referring to --with-pear, sorry "compiled" was not the right word * I'm not familiar with the switch you are referring to. If you look into in PHP source: ./configure --help PEAR a bit closer you will find that it is simply a package of classes. It does not need any changes to your PHP binary for it to work correctly. available for other scripting languages. Version mismatches are a fact I was referring to how Zend Opt is "required" for some stuff mainly because its necessary to offset the bloat. * I'm not sure what gives you the impression that Zend Optimizer is "required" for anything. ZO is a system for pre-compiling PHP code to If a PHP system has been "Optimized" then it requires ZO. Most admins need to have ZO since at least one of theri users will want to use sucha PHP system. bytecodes such that the PHP source files do not need to be interpreted each time they are run. While it is true that some commercial software written in PHP is encoded and requires ZO, but this is a choice of that particular developer and is not attributable to PHP as a language or as a technology. But it does epitomize PHP's overall paradigm of "you want to add funtionality for XYZ? ok lets drunkenly add support for it without tryign to be consistent or plan for anything in the future. of life with all tools, deal with it. And last but not least, you do not And PHP tends to have a greater majority of them, have you ever managed PHP on multiple servers? If you have you kwo exactly what I'm referring to. I maintain 13 servers in total, each of them have PHP installed, and try 13000 :) 13 is child's play and can be easily managed. have to be root to do anything with PHP, or indeed Apache except to I was referring to building PHP/Apache in general * You do not need to be root to build PHP or Apache, or in fact anything else, so I'm not sure where you're getting that requirement from. So any user on your systems can recompile apache or PHP at will? listen on a port lower than 1024, which is true for all tools since it's a platform limitation. * I'm speaking in generalitites of working with PHP not specifics components of the technology. In that case I would point out that your personal experiences with PHP are not necessarily a reflection on PHP. I hope you don't take offense My personal experiences with PHP and many other internet technologies is quite extensive. Quoting your original post... "it uses perl's MIME tools and SMTP tools". How is that not saying "PEAR or any specific package used Perl"? Because I was refering to the URL I'd sent to Perl's Mail::Sender::Easy module. Your solution was not "better" given the context of the question. Specifically that the question was asking about doing something in PHP and was asked on the PHP list meaning it's not a great leap to assume the guy need a solution in PHP. A solution is a solution, PHP is just one tiny option, I was offering an easier to work with alternative. Feel free to ignore the rest of this post, which I hope you'll take in the spirit it is meant, but please answer me this. What has PHP done to you? Why are you so anti-PHP? And specifically why are you on a PHP list suggesting people use a different technology? PHP has all the problems I've been specifying, that costs time and money, and I'm sick of it :) I'm on this list because I am a developer for a company that makes an apache install system and I needed to find out some info on the specific oddness of PHP4 and PHP5's --with-mysql and --with-mysqli options so that its would work properly. Which in fact PHP4/5 + --with-mysql[i] *is* a huge example of what makes PHP the last choice for any project. -- PHP Database Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DB] Sending filing attachments using PHP
Bastien Koert wrote: Then Please, stop posting here...it just is not constructive... I will, but I think it is If you have these issues that need addressing to make it a better langauge, then talk to the nice people at Zend and get invovled in making things better. No thanks, trying to get out of that pit of despair. I am however trying to help make things better by doing non-PHP stuff. All the rest if useless diatribe. Its not useless if one person benefits from it and at least considers that an alternative to PHP may be a better choice and that PHP is not gods gift to nerds but rather Satan's snare of the nerds :) -- PHP Database Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DB] Re: Sending filing attachments using PHP
in PHP source: ./configure --help I've had a look and it would appear that all that switch does is install PEAR for you during the build process. That doesn't change the fact that it's still just a collection of PHP classes and does not require rebuilding of PHP to benefit from it. sure no problem, again mostly I was speaking in gernalities about how its works and referencing the switch since you'd never heard of ti. You're also making it sound like adding ZO to a PHP installation is a mammoth task... it's not. It's just as simple as building PHP itself. Which is a mammoth task ;) How so? Take any other interpreted language, and you don't usually get Even though PECL and PEAR alleviate some of the headache by trying to be CPAN, much funtionality is based on build options (mysql, curl, etc) So if I find that my server does not have, say, mysql support built in or I need a special kind (see ./configure --help for a list) then PHP will most likely need recompiled. If it breaks, you may break PHP for everyone, it may even take down apache if the .so got goofy. With Perl perl -MCPAN -e 'install DBD::mysql;' if it breaks then - all scripts still work - apache still works pre-compilation for free. Correct me if I'm wrong but this goes for Perl as much as it does for PHP. You have to 'jump through hoops' to get it. one command, no possiblity of breaking anything, one hoop, very low to the ground and about ten feet tall :) Out of curiosity, why do you find it easier to manage Perl on 13,000 servers? What specific advantages does it have over PHP when it comes to this? Perl just works and make sense so its easier to code with. Any issue sthat do come up now and then are usually resolved by a moduel upgrade, one CPAN cpmmand :) So any user on your systems can recompile apache or PHP at will? Yeah, I don't stop them - more hassle than it's worth. But they'll be Ok, i guess I'm refering to running a webserver that all the user's share. If "bob" needs --with-curl then PHP needs to be recompiled. in practice most hosting customers are hosting customers because they woudln't knwo anythgin about compiling their own anything. Its all really besides the point though, perhaps I shoudl have just phrased it "you have to recompile some major stuff just to add minor functionality" My personal experiences with PHP and many other internet technologies is quite extensive. I don't doubt that, but I'm not understanding what Perl gives you that makes it easier to manage than PHP. Please explain it to me so I can As I stated I'm not doing a Perl vs PHP rant I'm doing an "anything but PHP" rant :) learn something from this exchange. You clearly feel quite passionate about it, so please share. Actually since most everyone has expressed an interest in stopping this thread, I think I will. Teh facts are there do as you wish :) A solution is a solution, PHP is just one tiny option, I was offering an easier to work with alternative. Without adequately explaining why it's easier. And more to the point you Sure I did, no one wants to hear it though :) are still on a PHP list, and as I've stated before, the question was clearly asking for a PHP solution. True enough, but if you want to be strict then why not send them to a none DB list? Feel free to ignore the rest of this post, which I hope you'll take in the spirit it is meant, but please answer me this. What has PHP done to you? Why are you so anti-PHP? And specifically why are you on a PHP list suggesting people use a different technology? PHP has all the problems I've been specifying, that costs time and money, and I'm sick of it :) Yeah, I got that already :). What I haven't grok'd is what specifically makes Perl easier and therefore cheaper to manage. As I stated I'm not doing a Perl vs PHP rant I'm doing an "anything but PHP" rant :) Which in fact PHP4/5 + --with-mysql[i] *is* a huge example of what makes PHP the last choice for any project. Again, this is a statement that makes no sense to me. You've made a statement saying you hate something without explaining why. Do you see Because its got *s* many problems, security, development, admin wise - details throughout this thread :) why it's very hard to learn from you when you don't justify your hatred? What's the problem with the MySQL modules available for PHP? I Those configure flags have so many combinations to get unpredicatabel behavior this is the pseudo thought process while doing it: --with-mysql (make sense so far) but lest add the super duper mysqli stuff: Oi crap what arg do you give it depending on what --with-mysql 's value is? --with-mysql=/usr --with-mysqli=path_to_mysql_config --with-mysql --with-mysqli=/usr Is all of that mess the same on PHP 4 and 5 ? What if you have mysql 4.0, 4.1, or 5 ? and once you get your head wrapped around it are all the badly named funitons gogin to behave
Re: [PHP-DB] Sending filing attachments using PHP
there really aren't enough effort applied to educate those outside the IT world. Working on it :) > but I still use PHP because it is still the most appropiate development > enviroment for a small or middle sized web solution. Why not use Perl, it has all the "pros" but does not have the cons :) Because it has cons, and lots of them. It's not a language who was designed "it is still the most appropriate development environment.."As I stated previously, I'm not trying to do a Perl vs PHP debate but rather "use anything but PHP" the "why not use Perl" was directed at the statement. In other words "Why is the most appropriate" when its a security problem and a hassle, and zillions of other technologies do the same stuff, and more, and much much better. for web development and this becomes a hassle. Its language constructions Why/ just output headers and HTML and you're done. Separate logic and presentation. are not as intuitive as other languages, there are too many ways of doing the same thing, and too many different "code conventions" (if they can be Oi, did you even look at the url I sent? all the randomly named functions that do the same thing? called as such). So it really becomes complicate to make one perl developer work with another perl developer. There are too many basic data structures for a scripting language, PHP arrays work better in almost any situation, are easier to understand and use. Debugging a perl application requires a higher level of programming skills. Not really. You're just used to PHP data structures, thats all. PHP doesn't have too much overhead when it's used in its most primitive way. But when is it? Mostly never, people always need this or that option compiled in and pretty soon: a 20 Meg binary and lots of headache :) Everything procedural, everything on arrays and only load what you need. This way it can run as fast as anyone. But this can only be used for small solutions and some medium web solutions, it isn't applyable to every need. Thats a programmer doing a good job, and that can be done in any language. Its no positive feature of PHP. -- PHP Database Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DB] Re: Sending filing attachments using PHP
Stut wrote: I think we may have to agree to disagree. I love PHP. I've never had a Ah I completely forgot about this sort of fun thing that I find in my email almost once a week, just got this one: http://forums.gentoo.org/viewtopic-t-460727.html now how many phpinfo() pages do you think there are and how many are vulnerable to the cross-site scripting attack. So this report means you have to upgrade your binary and it addresses: - system level problems (buffer overflow, memory leak, potential crash) - web based secuity attacks (corss-site scripting) - code based security attacks (restriction bybasses) *exactly* the sort of stuff thats jaded me :) Time to upgrade each install of PHP on all 13 server's :) The phpingo(0 reminds me of the one they had where a php file with only this line: would allow an attacker to upload a rootkit and damage the system, saaaweeet ;p or a cross site scripting/SQL injection thing that'd allow people to post HTML to your site and make it show whatever they wanted... good times, good times Peace everyone, its been really fun :) -- PHP Database Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DB] Re: Sending filing attachments using PHP
Bastien Koert wrote: php is not the only language susceptible to x-browser attacks... seems unfair to single it out. Why not? Its the only I've seen that actually has hackability built in! (see below) So it singles itself out, thats the whole point :) And as previously pointed out, many times it the developer's fault for writing that insecure code Yes developer does cross-site scripting suseptable code = developer's fault * but if a script has *only* this as its content: And *that* script has cross-site vulnerabilities is the programmer at fault for writing bad code? No, he's at fault for using PHP I rest my case ;) The only solution is to upgrade the binary. That SUCKS big time! -- PHP Database Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DB] Re: Sending filing attachments using PHP
So why bother wit a language no ene knows how this crappy syntax works? Because you are mistaken based on your preference and experience and calling it "crappy" is not a very professional way to make your argument. Again I was simply pointing out some *major* drawbacks of PHP, not doing a one lang vs another comparison. -- PHP Database Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DB] Re: Sending filing attachments using PHP
Michelle Konzack wrote: Am 2006-05-12 15:39:44, schrieb JupiterHost.Net: Why not use Perl, it has all the "pros" but does not have the cons :) Oh yes it has... Perl is a memory monster... Anything is a memory monster if the task is memory intensive. many benchmarks of multi languages (not just Perl/PHP) doing similar task show PHP as one of the highest actually. I have no problems to soupport over 17.000 Users on 32 CPU machine with 64 GByte of memory using apache 1.3 and php5. Perl would just kill the machine... Thats good that you have had good experince on one machine or cluster. Have you tried 17000 servers yet? -- PHP Database Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DB] Re: Re: Sending filing attachments using PHP
Michelle Konzack wrote: Am 2006-05-12 11:58:37, schrieb JupiterHost.Net: I was referring to building PHP/Apache in general * What do you talking about? -- I have compiled Apache and php5 the standard way and ABSOLUTLY NOTHING was missing. Great, I'm talking about managing multiple servers with multi needs. Generally its a cludge. If you have to build it only one a hadnfull of servers only when updates come upt, super. listen on a port lower than 1024, which is true for all tools since it's a platform limitation. * I'm speaking in generalitites of working with PHP not specifics components of the technology. ??? Generally: PHP is more prone to have the "true for all tools" probelms. Yeah, you're definitely smoking somethin'. The PEAR package Mail_Mime is another example of a pure-php class. It certainly does not use anything perl related at all. I'd really like to know what makes you think it does. I never said PEAR or any specific package used Perl, I'd simply offered a better solution that happend to be done in Perl. No, it is NOT a better solution, because if I use perl I have to maintain TWO scripting languages and install I do not know how many modules from CPAN... maybe 100-200? I install about 10 generally. I think you're starting to get into a "my dad can beat up your dad" thing which is pointless. Good day to all, sorry if I was to ambiguouse or I've offended. Good by! Seriously, chill, I wasn't getting personal. Reckon I touched a nerve. Its too bad if you don't want to consider another idea. your loss not mine :) -- PHP Database Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DB] Conditional updating...
Grae Wolfe - PHP wrote: Sorry I have been out of touch... I thought I had this problem beat, but I was wrong. I decided that the best thing to do was to filter the variables as the $sql statement was being created. I tried using the following code, and got a message back that it was invalid and my Query couldn't execute... Can anyone tell me where I screwed this one up?? Print out $sql and then try to manually do it in your mysql (or whatver DB engine) shell. I imagine you have a syntax error and that will tell you exactly what and where it is :) And I hope you're only criteria for the value of each colum isn't that its just not empty. If so you will be vilnerable to SQL injection attacks and your data will be compromised. You should at the very least quote the values with a valid SQL quoting function. (IE not just wraping it in quotes but one that actually escapes certain characters and wraps it in quotes as need be) Do not rely on that automaticaly being done (IE think how crappliy unreliable and dangerous relying on "Magic Quotes" is, oi what pile *that* is...) -- PHP Database Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DB] Conditional updating...
Grae Wolfe - PHP wrote: Thank you for the thought, however, I don't have a shell that I can run in, hence, I have to rely on help from others. get a GUI client then and use that... -- PHP Database Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DB] LIMIT
chris smith wrote:
On 7/1/06, Dwight Altman <[EMAIL PROTECTED]> wrote:
Thanks, but that's an additional query.
I was wondering if there may be a PHP function that can operate on the
$result or perhaps $link of the single query that uses a LIMIT clause and
I'm not sure how this would be done in PHP (simply because I am not a
PHP coder) but in Perl (as an example of the principle, so please keep
your flames at bay for th etime being ;p) I'd do this:
my $results_arrayref = $dbh->selectall_arrayref($query);
my $number_of_results = @{ $results_arrayref };
print "Number of results: $number_of_results\n";
for my $record( @{ $results_arrayref } ) {
# do what you want with each record...
}
I'm sure PHP has a way to count how many is in a given result set
without needing an additional query.
--
PHP Database Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DB] LIMIT
Bastien Koert wrote: Your example predicates that the resultset it passed to an array which you then take the size of, which would only give you the LIMIT value if that clause is specified in the query... I see, I misunderstood the OPs question then they wanted to know that there are 25000 records that match their WHERE but only SELECT 100 of them. Gotcha ;p yeah thats pretty much got to be 2 queries, although if caching is involved it might not be that expensive... -- PHP Database Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
