passthru.php, shtml files, etc.

I have noticed, in connection with users of the Freebie package having problems installing it when they are also using the Co-Op network, that there are some peculiar variants of the passthru.php file floating around, and--much more important--some apparent misunderstandings about how that file is supposed to be used.

The crux is sites that have, or may someday add, any .shtml pages.

As Shawn clearly pointed out when the thing was first given, it is expressly for use on:

"a site where the server supports mod_rewrite and PHP, but all your files are .htm or .html..."​

which says nothing about having .shtml files present .

If we look at the relevant .htaccess lines for using passthru.php, we see:

RewriteCond %{REQUEST_FILENAME} ^(.*).htm [NC,OR]
RewriteCond %{REQUEST_FILENAME} ^(.*).html [NC]
RewriteRule ^(.*) /passthru.php?file=$1​

As written, those will also pick up all .shtml filespecs and send them through the passthru.php script. (That is because the dots in .htm/.html are not escaped, and a bare dot, in "regular expressions", is an any-character wildcard, so an 's' will match as well as a real period.)

But the way passthru.php works is by reading the actual file off disk, not by fetching it via HTTP. In .htaccess, this--

RewriteRule ^(.*) /passthru.php?file=$1​

--just gets the filespec within the site's directory structure, and in passthru.php, this--

file_get_contents(str_replace('../',NULL,$_REQUEST['file']))​

--reads that file off the local file system.

The crux is that a nominally-shtml file so read is not been parsed by the server, and so its SSI directives are not acted on.

What has been happening is that users who did not previously have any .shtml files on their site are, when installing the package, finding that the many .shtml files in it are not doing their SSI jobs (except that the users often don't see what is happening, and I have to sort it). And that will, in any event, be true of any .shtml files in their site, extant or later-added.

The simplest solution, to me, for using the co-op script with a mixed bag of shtml and html/htm files is to do these things:

1. Slightly modify the .htaccess directives to avoid picking up shtml files: replace the three lines above with:

RewriteCond %{REQUEST_FILENAME} ^(.*)\.html?$ [NC]
RewriteRule ^(.*) /passthru.php?file=$1​

where the backslash escape keeps the period a true period (and, if I have this right, the ? after the 'l' in .html makes it optional, thus capturing both .htm and .html extensions).


2. In the site's root, make a new php file, perhaps named shtml-ads.php, looking like this:

<?php 
include ('ad_network.php'); 
echo $ad_network[0];
?>

PHP:

Then, in each shtml file, where wanted (say, perhaps, just above the </body> directive), put this SSI directive:

<!--#include virtual="/shtml-ads.php" -->​

That will call the new php script, and all will be well.

(I think I remember seeing something sort of like in another thread.)

The suggested new php script is, of course, thoroughly minimal--a bare display of a single ad. A fuller, more realistic sample might look like this:

<?php 
$crlf=chr(13).chr(10);
include ('ad_network.php'); 
echo '<center><font face="Verdana" size="1">'.$crlf.
      $ad_network[0].'&nbsp;&nbsp;-&nbsp;&nbsp;'.$crlf.
      $ad_network[1].'&nbsp;&nbsp;-&nbsp;&nbsp;'.$crlf.
      $ad_network[2].'&nbsp;&nbsp;-&nbsp;&nbsp;'.$crlf.
      $ad_network[3].'&nbsp;&nbsp;-&nbsp;&nbsp;'.$crlf.
      $ad_network[4].$crlf.
      '</font></center>'.$crlf; 
?>

PHP:

where the $crlf's just put the resultant HTML code on separate lines, so if you're looking at a page with "View Source", it's easy to see what's what; the &nbsp; and pipe characters make nice-looking dividers; and the font details and centering exemplify ways you can set your ad display. (And you can use from 1 to 5 ads, as you will.)

That works, and, to me, looks tidy enough. If there are more elegant solutions, please post.

 

.phtml works a treat.....

 

For the .shtml files, certainly. But there are, it seems, many sites that have a mix of .htm/.html and .shtml files, and so have to have distinct methods for each.

One could, of course, convert all the .htm/.html files to .shtml files, but that would involve mod_rewrites and perhaps other messiness, even though, in the long run, it is--I think, anyway--the superior soultion.

While it is true that having a file that has no actual SSI directives in it be evaluated by the server has a small performance overhead, it is just that: small. And, in this particular instance, the Network ads, it is no worse than running the HTML through a php re-writer (and maybe better); so, since the ads have to be on all pages anyway, it makes sense (again, to me) to make all site pages .shtml pages and use the clean method throughout.

But, as I say, for those reluctant to undertake massive filename changes (even though they can be handled by a single .htaccess mod_rewrite line), it is as well to know how to deploy both methods in parallel such that each does its own job (and no inadvertent other).