Settings option to exclude opening and closing PHP tag from PHP-only code-blocks
jjeff - April 28, 2007 - 15:15
| Project: | Code Filter |
| Version: | 5.x-1.x-dev |
| Component: | Code |
| Category: | feature request |
| Priority: | normal |
| Assigned: | Unassigned |
| Status: | needs work |
Jump to:
Description
Here's a patch that adds an "Include opening/closing PHP tags" checkbox on the filter settings page (enabled by default). When this checkbox is disabled, blocks such as the following will have their opening and closing PHP tags removed.
<?php
// this is a comment
print_r($GLOBALS);
?>I find that most of the time I will want to display PHP code, but I don't want to imply that people should enter the opening and closing tags.
When enclosed within [code] tags, the PHP opening and closing tags will still appear.
| Attachment | Size |
|---|---|
| codefilter-phpstrip.patch | 1.7 KB |
#1
Yes, I find that we get lots of newbies grabbing snippets from the handbooks with the php tags in there and then a barrage of help questions on the book page to explain that they need to just use the code and remove the php tags. I'd love to see this implemented. Will try to test the patch later this weekend.
#2
I support this being configurable, definitely...
However, I wonder if it wouldn't be better to make it configurable per block of text, and use the settings page as a default. For example, we also have pages in the handbook where you literally do need to include the PHP tag (or at least the opening one). So we may end up with just as many comments in the handbook about "make sure you remember to include the opening PHP tag." Maybe something like:
<?php#SHOWTAG=TRUE
blah blah blah
#SHOWTAG=FALSE
?>
Not sure though, this is probably scope-creep.
#3
Well it's configurable per input format. So you could conceivably have one with and one without PHP tags.
But the easier thing to do is to simply enclose the PHP block inside a CODE block. This would display the PHP tags.
If you had PHP tags turned off and you wanted to display them, you could just do this (substitute < and > for { and }) :
{code}
{?php
return foo($bar);
?}
{/code}
#4
In case that wasn't clear, #3 will work with the current patch without any changes.
#5
I like this idea, but the module also handles ASP-style and (strangely) php tags that start with [ instead of < (see the codefilter_filter() 'prepare' section of the module). So the patch should too.