i'll try that!Quote:
Originally Posted by xeno
Printable View
i'll try that!Quote:
Originally Posted by xeno
Umm... no. I'm puzzled here. If you send an email, there is no 'extension' to it... it's just data (text) sent as part of the message body. In that case, won't matter what 'format' it is in... it'll just be interpreted as html/plain text/viewer default/etc.
Attaching a .php file will just cause errors... they cannot be run locally unless you happen to have a php server setup on your home computer, which I doubt your customers will have.
Even if there is no php code, I'm unsure as to whether they can view the page as html.
If you do require changing the name, there are functions listed on php.net under 'file handling' and/or 'strings', depending on what your specific needs may be.
You ask for a method to send them 'only specific things'... sure. USE PHP to OUTPUT as HTML. The outputted html can, as programmed into the php, contain only those 'specific things'.
Then, assuming the email viewer has support for html, and your mail function has a properly coding html encoding setting (not used to this myself... sounds like you've managed to email html before... that's good), then it should display as a form.
forms aren't php. they are html. plain and simple.
In your form, use this:
<form ... action="nextpage.php" target="_blank">
Which will
1. send to a php page to interpret the data (data can only be interpreted serverside AFTER it is sent TO the server.)
2. open in a blank new window... so the email's website's frames and such don't have problems. I am not sure how/if this will function in programs like outlook... but I would assume, I suppose, that it would be as a link would... open a browser window... default browser.
the other option would be to JUST send a LINK to a page on your site.
That link could be like this:
<a href="http://site.com/page.php?ordernumber=2349032940>click</a>
or something like that, where the php (using $_GET['ordernumber']) would be able to get the number of the order (or another ID code/username/etc etc) and display the correct form, info, etc. AND be running from your server WITH php functioning properly.
The downside to this method is that you would have to store the data in the form, etc, until the user came to view it (and, maybe, after). This could be done using a database, or, even, html pages (php?) GENERATED on your server via the php code in the first place... but this is kinda complex. Or you could use that info sent to dynamically generate a new page that has the right info, but you'd have to send a lot of info with get; probably too much.
Output buffers! Terribly handy things.
At the start of your page:Then, before the mail call (presuming you've already output all the HTML you want in the email):Code:<?php ob_start(); ?>
$page will now contain the page's HTML.Code:<?php
$page = ob_get_contents();
ob_end_flush();
?>
Only if they have that set up as an association, or if they're smart enough to open it in a browser themselves.Quote:
Even if there is no php code, I'm unsure as to whether they can view the page as html.
Right.... I guess it's possible to view php locally with no code, IF they know to open... makes sense. But "general customers" might not, and definitely shouldn't be expected/assumed/required to.
So... that ob_start/end thing stores everything that is output into $page?
Interesting... useful, indeed.
Quite right.Quote:
But "general customers" might not, and definitely shouldn't be expected/assumed/required to.
Indeed so. Especially when you want to include() a local PHP page and make a few adjustments to the output before displaying.Quote:
Interesting... useful, indeed.
But... no.... include outputs right away, yes?
Oh... buffer... meaning it delays output till you say? Or does it also output?
If it delays... that's a really nice feature... I just thought it logged.
Nope, it doesn't actually output anything to the client until you call ob_flush() or ob_end_flush().Quote:
Oh... buffer... meaning it delays output till you say? Or does it also output?
what's the difference there? (sorry... being lazy... could look it up.. but you're explaining well) :)
ob_flush() simply prints the current contents of the buffer; ob_end_flush() does so and then destroys the output buffer as well. Antonym: ob_end_clean(), which simply destroys the buffer.Quote:
what's the difference there? (sorry... being lazy... could look it up.. but you're explaining well)
hey, I just wanted to say thanks Twey, that OB stuff is exactly what I was looking for =] worked out quite nice.