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.

// 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.

CommentFileSizeAuthor
codefilter-phpstrip.patch1.7 KBjjeff

Comments

add1sun’s picture

add1sun commented

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.

webchick’s picture

webchick
she/they
Primary language English
Location Vancouver 🇨🇦
commented

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:

#SHOWTAG=TRUE
blah blah blah
#SHOWTAG=FALSE

Not sure though, this is probably scope-creep.

jjeff’s picture

jjeff commented

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}

jjeff’s picture

jjeff commented

In case that wasn't clear, #3 will work with the current patch without any changes.

johnalbin’s picture

johnalbin
they/他
Primary language English
Location Taipei, Taiwan
commented
Status: Active » Needs work

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.

cameron tod’s picture

cameron tod commented
Status: Needs work » Closed (won't fix)

5.x, no longer supported, and thankfully, snippets are pretty much a thing of the past. However, if you want this kind of functionality in 7.x, feel free to reopen and change the version.