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
php is not the only language susceptible to x-browser attacks... seems unfair to single it out. And as previously pointed out, many times it the developer's fault for writing that insecure code Bastien From: "JupiterHost.Net" <[EMAIL PROTECTED]> To: php-db@lists.php.net Subject: Re: [PHP-DB] Re: Sending filing attachments using PHP Date: Fri, 12 May 2006 18:53:13 -0500 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 -- 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
I think we may have to agree to disagree. I love PHP. I've never had a problem with it that couldn't be solved that's made me want to switch. Just to make it clear I do try the so-called "up-and-coming" development trends, and over the years have tried most of the existing systems. I recently started using Rails, which has some very nice features but I find it far too restrictive for development of anything more than 'toy' apps. Just wanted to make the point that I'm not pro-PHP for no reason. I've tried the rest, I've settled on what I believe to be the best. JupiterHost.Net wrote: 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 ;) No more so than building Perl or Python or Ruby IMHO. 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) Again, this is not true. As far as I know, PHP is architected as a core engine with modules for all userland functions, including what could be considered basic features such as array operations. What this means is that each module that provides additional functionality can be built as a dynamically loaded object. That is to say separate from any other functionality. 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. Not so. Or rather, I should say, build the .so. 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 Build the .so. Run php on the command line with a script that uses the dl function to dynamically load the new module. If it doesn't work it hasn't broken anything since it's dynamically loaded. If it does work then you update the configuration file that lists the extensions to be loaded at startup and restart Apache. 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 :) Likewise with adding MySQL to PHP, as long as you do it right. Do it the lazy way (which is just to recompile) and you could encounter problems. 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 :) Same with PHP. 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" We're talking about different things. The only point I was making is that building PHP and Apache do not *require* root. In fact only installing it requires root. You certainly don't need root to run either. You seem to be extending this to include whether users are capable. That's irrelevant - they can if they want to, but in most cases it's not worth their while. In your example of "bob" and his CURL module, it's as simple as building to .so (bob can do this if he's able), sticking it in the right directory and running a test script (as I described above) to ensure it doesn't break anything. No recompilation of PHP, or any other "major stuff" needed, and nothing gets broken. 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 :) And that justifies it how? All I'm gett
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
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] Re: Sending filing attachments using PHP
JupiterHost.Net wrote: Stut wrote: 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 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. 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. I think you're grossly over-estimating the number of PHP systems that use Zend Optimizer, not so much as an actual number but more as a percentage of all software written in PHP. 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. 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. How so? Take any other interpreted language, and you don't usually get 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. I'll freely agree that there are a number of things that exist in PHP that are not ideal, and could appear to have been implemented by a drunken developer trying to meet a deadline. However, having been a lurker on the PHP-Dev list for a long time now I can say with absolute confidence that most of the decisions made regarding what gets into PHP and what doesn't are well-justified. PHP is not a small system, and it takes a huge effort to manage the ongoing development. Mistakes have been made and undoubtedly will continue to be made, but I'm sure the same can be said for any similarly-sized open-source project. 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. IMHO, 13,000 servers should be just as easy to manage as 13 - it all depends on the infrastructure (in terms of tools) you have in place to assist you in the task. 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? 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? Yeah, I don't stop them - more hassle than it's worth. But they'll be compiling it in their own directories, they'll be running their own copies. They can't interfere with the systems installation of either because file permissions don't let them, but that doesn't stop them working on their own copies of it. Any user with shell access with the required build tools available to them will be able to do the same. If you think otherwise I encourage you to try it. 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. 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
Re: [PHP-DB] Sending filing attachments using PHP
2006/5/12, JupiterHost.Net <[EMAIL PROTECTED]>:
> 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 :)
Developers are aware (well most of them). Designers are not, project leaders
are not (with the exception of a few), marketing people are not, and all the
people higher up in the administration are not. This is mostly our fault,
there really aren't enough effort applied to educate those outside the IT
world.
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 :)
Because it has cons, and lots of them. It's not a language who was designed
for web development and this becomes a hassle. Its language constructions
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
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.
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 :)
I think they have proved they don't care too much about backward
compatibility. You have just to see what happened to the [] and {} string
operator: deprecated, undeprecated and so on. They only care about keeping
the core features of PHP (those that really made the language stand where it
is).
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 doesn't have too much overhead when it's used in its most primitive way.
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.
--
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
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] Too stupid to UPDATE...
Don't have time to totally disect it, but you might change the "if($num_rows)"
to "if($num_rows > 0)" just to make sure.
Also, try echoing out your SQL statement to check and make sure things like
$table got a real value or other silly things.
Lastly, I usually use single quotes for SQL statements.. in this case, it would
simplify your PHP SQL statement by removing the necessity to escape all the
double quotes \"
If you echo the SQL and it looks ok, try running it manually through mysql's
command line or via a program like WinSQL Lite on Windows to try to isolate if
it's the query or your PHP.
Good luck!
-TG
= = = Original message = = =
I am trying to write a script to handle event registration. Most of the
people that will be registering are already in the database, but not all,
and those that are may not have current information.
Here is my latest effort, or at least a snippet of it... Can anyone point
out where I went stupid, or if there is a better way of doing this?
THANKS!!!
<<<===--- BEGIN SNIPPET ---===>>>
$db = @mysql_select_db($dbname, $connection) or die("Couldn't Select
Database.");
$link = mysql_connect("$server", "$user", "$pass");
mysql_select_db("$dbname", $link);
$result = mysql_query("SELECT * FROM $table WHERE first_name='$first_name'
AND hs_last_name='$hs_last_name' AND last_name='$last_name'", $link);
$num_rows = mysql_num_rows($result);
if($num_rows)
$sql = "UPDATE $table SET first_name=\"$first_name\",
last_name=\"$last_name\", hs_last_name=\"$hs_last_name\",
guest_name=\"$guest_name\", street_address1=\"$street_address1\",
street_address2=\"$street_address2\", city=\"$city\", state=\"$state\",
zip=\"$zip\", phone1=\"$phone1\", phone2=\"$phone2\",
email_address=\"$email_address\", number_attending=\"$number_attending\",
payment=\"$payment\", registration_comments=\"$registration_comments\",
date_registered=\"$today\" WHERE first_name=\"$first_name\" AND
last_name=\"&last_name\"";
$result = @mysql_query($sql,$connection) or die("Couldn't Execute Query.");
else
$sql = "INSERT INTO $table
(first_name, last_name, hs_last_name, guest_name, street_address1,
street_address2, city, state, zip, phone1, phone2, email_address,
number_attending, payment, registration_comments, date_registered)
VALUES
(\"$first_name\", \"$last_name\", \"$hs_last_name\", \"$guest_name\",
\"$street_address1\", \"$street_address2\", \"$city\", \"$state\", \"$zip\",
\"$phone1\", \"$phone2\", \"$email_address\", \"$number_attending\",
\"$payment\", \"$registration_comments\", \"$today\")
";
$result = @mysql_query($sql,$connection) or die("Couldn't Execute Query.");
<<<===--- END SNIPPET ---===>>>
___
Sent by ePrompter, the premier email notification software.
Free download at http://www.ePrompter.com.
--
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
Then Please, stop posting here...it just is not constructive... 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. All the rest if useless diatribe. Regards Bastien From: "JupiterHost.Net" <[EMAIL PROTECTED]> To: PHP DB Subject: Re: [PHP-DB] Sending filing attachments using PHP Date: Fri, 12 May 2006 15:39:44 -0500 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 -- 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
[PHP-DB] Too stupid to UPDATE...
I am trying to write a script to handle event registration. Most of the
people that will be registering are already in the database, but not all,
and those that are may not have current information.
Here is my latest effort, or at least a snippet of it... Can anyone point
out where I went stupid, or if there is a better way of doing this?
THANKS!!!
<<<===--- BEGIN SNIPPET ---===>>>
$db = @mysql_select_db($dbname, $connection) or die("Couldn't Select
Database.");
$link = mysql_connect("$server", "$user", "$pass");
mysql_select_db("$dbname", $link);
$result = mysql_query("SELECT * FROM $table WHERE first_name='$first_name'
AND hs_last_name='$hs_last_name' AND last_name='$last_name'", $link);
$num_rows = mysql_num_rows($result);
if($num_rows) {
$sql = "UPDATE $table SET first_name=\"$first_name\",
last_name=\"$last_name\", hs_last_name=\"$hs_last_name\",
guest_name=\"$guest_name\", street_address1=\"$street_address1\",
street_address2=\"$street_address2\", city=\"$city\", state=\"$state\",
zip=\"$zip\", phone1=\"$phone1\", phone2=\"$phone2\",
email_address=\"$email_address\", number_attending=\"$number_attending\",
payment=\"$payment\", registration_comments=\"$registration_comments\",
date_registered=\"$today\" WHERE first_name=\"$first_name\" AND
last_name=\"&last_name\"";
$result = @mysql_query($sql,$connection) or die("Couldn't Execute Query.");
}
else {
$sql = "INSERT INTO $table
(first_name, last_name, hs_last_name, guest_name, street_address1,
street_address2, city, state, zip, phone1, phone2, email_address,
number_attending, payment, registration_comments, date_registered)
VALUES
(\"$first_name\", \"$last_name\", \"$hs_last_name\", \"$guest_name\",
\"$street_address1\", \"$street_address2\", \"$city\", \"$state\", \"$zip\",
\"$phone1\", \"$phone2\", \"$email_address\", \"$number_attending\",
\"$payment\", \"$registration_comments\", \"$today\")
";
$result = @mysql_query($sql,$connection) or die("Couldn't Execute Query.");
<<<===--- END SNIPPET ---===>>>
--
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
2006/5/12, Martin Alterisio <[EMAIL PROTECTED]>: ... I hate not having a proper application framework, ... Sorry, there is a mistake there. I meant to say that I hate not having an application server, although I also think currently available framework are just not the way to go. They are too big and produce too much overhead.
Re: [PHP-DB] Sending filing attachments using PHP
2006/5/12, JupiterHost.Net <[EMAIL PROTECTED]>:
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
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.
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.
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
without harming the spirit of PHP in future versions or future enhacements,
and that our needs will be somehow be heard. If not, well they will realize
soon that current trends are leading to a different kind of solutions (not
that utopic Web2.0 but a more realistic Web1.5).
Thanks for sharing your opinion and concerns, I really appreciate them.
Re: [PHP-DB] Re: Sending filing attachments using PHP
Let me start by apologising if my posts came across as personal. Check the archives for my posts, primarily on php-general and you will see that I have a very sarcastic personality. No offence was meant or is meant by what follows. JupiterHost.Net wrote: 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 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 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. 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 I've never had a problem with version issues. And I have to say that in my experience other tools have more problems with this. Perl used to be a nightmare for us until we rewrote the scripts we had in PHP. I'm not blaming PHP for this, I'm just trying to point out that problems related to version mismatches are usually related to the administrators understanding of that particular package. For me that means Perl caused me more issues than PHP because I know PHP better. 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. 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 at that but I know a huge number of developers and sysadmins who are more than happy with working with PHP, and nearly all of them have been through the process of trying the alternatives before landing on PHP as the right solution for them. 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. 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"? 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. 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. I hope you understand that I wasn't getting personal, but you must accept that your answers so far have suggested that you don't actually know much about what you are talking about. Good day to all, sorry if I was to ambiguouse or I've offended. 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? -Stut -- 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] 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
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] Eliminating character sets from DB entry
trap the IP and do a lookup on some service to detmine the origin of the user...if not from the country(ies) you want to serve redirect that user away to some other page or provide a custom 404 page to mess with the bots bastien From: "Chris Payne" <[EMAIL PROTECTED]> To: Subject: [PHP-DB] Eliminating character sets from DB entry Date: Sun, 30 Apr 2006 19:59:06 -0400 Hi there everyone, Is there a way to allow Only English character sets in database entry with MySQL and PHP? I'm getting an awful lot of SPAM which is in Chinese/Japanese and i'd love to be able to block these charactersets from being inserted into my databases. Chris -- PHP Database Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DB] Adding url to google
Sounds like you're asking how to programmatically add your web site to Google's search. I didn't dig very deep, but it doesn't look like Googles API provides for the ability to submit (only search) and by Google's "addurl" page (http://www.google.com/addurl/?continue=/addurl) it appears that they don't want you to be able to automate the adding of URLs or else they wouldn't be using CAPTCHA methods to prevent bots from spamming them. You may look into software like SubmitWolf or some of the others that automate submissions and try to figure out how they do it (if at all) but I'm guessing it's not going to really be feasible for you to do this... not easily at least. -TG = = = Original message = = = Hi all, I am developing the site using php and mysql. I have to add the url at google site through php code. If any one have idea about it, please help me. Regards Manoj ___ Sent by ePrompter, the premier email notification software. Free download at http://www.ePrompter.com. -- 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
" 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?
-Original Message-
From: JupiterHost.Net [mailto:[EMAIL PROTECTED]
Sent: Friday, May 12, 2006 10:10 AM
To: 'PHP DB'
Subject: 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
JupiterHost.Net wrote: 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. What planet are you on? Seriously? Because PEAR does not need to be compiled into PHP. Zend Optimizer is no different to the optimizers available for other scripting languages. Version mismatches are a fact of life with all tools, deal with it. And last but not least, you do not have to be root to do anything with PHP, or indeed Apache except to listen on a port lower than 1024, which is true for all tools since it's a platform limitation. 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. 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. -Stut -- If ignorance is bliss, you must be in heaven! -- 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
JupiterHost.Net wrote: 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. Agreed, but the subject does say "using PHP". 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. Why are you rebuilding PHP and Apache? In what way does phpmailer (a completely PHP-based solution with no external dependancies) force you to do this and "break[ing] PHP functionality for everyone"? And besides its in a non strutcutered way to maek it even more impossible to maintain. I assume that's a generic dig at PHP. For me, the lack of an enforced structure makes it easier to maintain since it gives you the freedom to put in your own structure. I don't know you from Adam, but for whatever reason you seem to hate PHP. I'm sure whatever it did it wasn't personal. Please do us all a favour and unsubscribe from this list, or at the very least please stop posting pointless and time-wasting answers. -Stut -- If ignorance is bliss, you must be in heaven! -- 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] 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
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
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] Adding url to google
Manoj Singh wrote: Hi all, I am developing the site using php and mysql. I have to add the url at google site through php code. If any one have idea about it, please help me. PHP is server-side technology. Google will never see it. The matter of placing your site in a search engine is a whole industry called "search engine optimization" or SEO. You can submit your site (manually) to Google here: http://www.google.com/addurl/?continue=/addurl If you want to submit all the pages on your site to google, you should consider: Google site maps - https://www.google.com/webmasters/sitemaps/login?utm_campaign=sitemaps-us-sbmtcnt&utm_source=EM Google Base - http://base.google.com/base Froogle - For ecommerce sites. It looks like submissions to Froogle are made thru Google Base. http://www.google.com/sellonfroogle/ Hope that helps, --J -- PHP Database Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DB] Adding url to google
Hi all, I am developing the site using php and mysql. I have to add the url at google site through php code. If any one have idea about it, please help me. Regards Manoj
