User Contributed Notes 기본 문법(Basic syntax) |
add a note |
11-Oct-2001 07:34 |
|
I use FrontPage 2000 exclusively for creating my PHP documents. I use the
<% %> style syntax. I can put code anywhere, before head (as is
required for cookie data) and anywhere else in between. Using advanced
flow control, i can design an entire page in html, and then put PHP
control statements around it. This is much easier than <% echo %>
commands. You can drop in/out of PHP at ANY time, and the only reason to
ever use <% echo %> is for variables. Save yourself some hassle and
write your html in html and avoid the echo mess.
|
|
mrtidy at mail dot com
12-Dec-2001 07:36 |
|
[Ed Note:
This is because of short_tags, <?xml turns php parsing on,
because of the <?.
[email protected]]
I am moving my site
to XHTML and I ran into trouble with the <?xml ?> interfering with
the <?php ?> method of escaping for HTML. A quick check of the
mailing list confirmed that the current preferred method to cleanly output
the <?xml ?> line is to echo it:
<?php
echo("<?xml version=\"1.0\"
encoding=\"UTF-8\"?>\n"); ?>
|
|
paquerette_only at hotmail dot com
16-Jan-2002 08:40 |
|
Under php 3.0.14 : if you have a line like this : echo "?>
written to file"; And you wish to comment this line, you'll do
this : //echo "?> written to file"; But this will
generate a parse error at the end of script (even if this line was in an
include script).
Why? because '?>' is ignored as long as it is
inside "". But once you've commented, the echo function is
ignored, and '?>' takes its signification : end of script!
I
guess it was corrected on next version, but if you run under php 3.0.14 be
careful, it make me loose a lot of time!
Paquerette
|
|
dave at [nospam] dot netready dot biz
18-Mar-2002 11:21 |
|
A little "feature" of PHP I've discovered is that the <?PHP
token requires a space after it whereas after the <? and <% tokens a
space is optional.
The error message you get if you miss the space
is not too helpful so be warned!
(These examples only give a
warning with error_reporting(E_ALL) )
<?PHP/*<Some
HTML>*/?> fails... <?/*<Some HTML>*/?> works...
|
|
stodden at in dot tum dot de
18-Jun-2002 09:51 |
|
if you're experiencing problems with php PIs when generating creating
mixed php/html content with e.g. an XSLT processor in html output
mode: it's not the processors fault. an _SGML_ processing
instruction is actually written as <?php ..>, i.e. without a
trailing question mark.
<xsl:processing-instruction
name="php"> echo
$hello; </xsl:processing-instruction> will therefor not not
work like it should.
a sane solution to work around this is
generating <script> tags instead.
|
|
php at 3wheel dot net
22-Nov-2002 07:29 |
|
"The closing tag for the block will include the immediately trailing
newline if one is present."
This is extremely annoying, and
there should be some way of disabling this behavior. If you're generating
HTML it's not really a problem, but I'm using PHP to generate text emails
using templates- and not getting out what I put in is pretty annoying.
|
|
carl (at) thep.lu.se
07-Dec-2002 08:13 |
|
If you have code that uses the short open tags "<?" and
"<?=", and you want to be able to turn off
short_open_tags, you will need to change those tags to
"<?php" and "<?php echo". For a small
program this is trivial to do manually, but if you have thousands of
lines of code, it makes sense to do this in a more automated way. A
simple search and replace will only work if you don't have the string
<? in any strings or comments. Quite likely you don't, but to solve
this not-quite-a-problem, I've written a program that does the job and
does it right. I challenge you all to come up with a PHP program that
changes its behavior after being passed through this tag expander.
(Programs that examine their own source don't count!) The thing can
be found in the CVS repository for BASE at sourceforge: (you need to
reassemble the URL - I had to cut it to be able to post it)
basedb/contrib/ConvertShortTags/
|
|
de \ kibo \ niels
19-Dec-2002 01:19 |
|
A follow-up to the first posting on this page: If you're writing PHP code
on a non-UNIX system like MacOS (and even on a UNIX system like Mac OS
X!), be very careful about line breaks.
Although this was
apparently fixed in 4.0.5, I got the weirdest errors while testing PHP
scripts that I wrote in BBEdit (6.5) on MacOS X (10.2, running Apache
1.3.27 with PHP 4.1.2).
The Mac-style line breaks (\r) that BBEdit
usually produces by default confuse the PHP parser, and it will report the
strangest parse errors. (I even got errors in lines of code that were
commented out! This drove me nuts for days).
Your documents have to
use UNIX-style linebreaks (\n) to prevent these errors. It's advisable to
configure BBEdit to produce UNIX line breaks by default in every new
document (preferences!).
This problem possibly also occurs with
DOS/Win systems whose linebreaks are \r\n.
|
|
nd at mad dot scientist dot com
14-Feb-2003 11:07 |
|
As for the "an _SGML_ processing instruction is actually written as
<?php ..>, i.e. without a trailing question mark." issue I
rather prefer <xsl:text>?</xsl:text> at the very end of the
<xsl:processing-instruction> element. This nicely outputs a question
mark first and then the closing bracket, XML style
("?>").
Be sure to include the <xsl:text>
element, otherwise the parser may add additional whitespace after the
question mark.
Andreas
|
|
02-Mar-2003 09:45 |
|
11-Oct-2001 01:34 I use FrontPage 2000 exclusively for creating my
PHP documents. I use the <% %> style syntax. I can put code
anywhere, before head (as is required for cookie data) and anywhere else
in between. Using advanced flow control, i can design an entire page in
html, and then put PHP control statements around it. This is much easier
than <% echo %> commands. You can drop in/out of PHP at ANY time,
and the only reason to ever use <% echo %> is for variables. Save
yourself some hassle and write your html in html and avoid the echo mess.
|
|
add a note |