Need help showing results in page with SSI

[aschecht]

I've tried to follow the instructions in the FAQ on including server side includes in the search results page but I can't get it to work right.

I suspect it's something simple that I'm doing wrong.

I've created a custom search page here: http://www.icdmeister.com/demo/search/icdsearch.html
which includes all of my SSI content (header, navigation, footer) and this include for the search:
<!--#include virtual="/demo/search/search.php?${QUERY_STRING}" -->

From the search_template.html file, I stripped out the redundant HTML, HEAD tags which left me with just the <!--ZOOMSEARCH--> command.

I set the configuration so the Link back URL was icdsearch.html

When I conduct a search from http://www.icdmeister.com/demo
the results open without formatting. When opened directly, the icdsearch.html page opens with all the proper formatting and SSI's.

I'm confused as to how the search script should know to use icdsearch.html as a template for the results screen?

Help will be greatly appreciated.

Thanks in advance,

Andrew

[David]

On your demo page you have a search form.

Your code for your form looks like this.
<form method="get" action="/demo/search/search.php">

But this will of course call the search.php script.

If you want to call your own script then you should change this to be,
<form method="get" action="/demo/search/icdsearch.html">

I think there are also a number of unrelated issues going on. Like your logging settings are not correct. And there is some strange text corruption going on in an iframe on your page, but this doesn't seem to be from our code.

[aschecht]

Thanks. I knew it was something simple like needing to change the form code.

I'll look into the other issues too.

THank you,

Andrew

[aschecht]

I changed the form code as you suggested and now the search results do appear with all of the correct server side includes and formatting. The search results though are gibberish.

The only code on my icdsearch.html page in that div is the search.php include as follows:

<div class="iframed">
     <!--#include virtual="/demo/search/search.php?${QUERY_STRING}" -->		
</div>

Don't know if this is relevant or not but . . .while the div class is named "iframed" it is not actually an iframe (it used to be but then I switched to using SSI instead).

Re: Logging settings. I'd unchecked the box for recording logging settings so not sure what's up with that.

Any idea what's going on with my search results?

Andrew

[Ray]

Hard to tell from here without doing some direct testing on the server.

But one guess would be that you have compression enabled for PHP output. See this thread on another forum which discusses this.

Also, let us know if you have made any modifications to "search.php".

Perhaps you could consider using a PHP page which performs the server-side includes instead. This way, you can use include() or virtual() as described on our FAQ page and compression should make no difference.

[aschecht]

Ray,

I have a parallel folder on the same server with Zoom search setup here:
www.icdmeister.com/site

This search uses the same search.php file, is on the same server and works without problems. The search.php file has not been edited in any way. This makes me think that it is not a problem with compression of PHP output (as this should effect both search installations the same, no?)

I'm not familiar enough with PHP to start making pages with it (incorporating SSI was already a stretch).

What else can I do to fix this?

A.

[Ray]

That version of the site is quite a different scenario.

For this other one, you are using an IFRAME for the main content of the page. The "search.php" script is being opened within the frame, and no "#include virtual" call is being used.

Compression works fine when the PHP script is directly accessed by the browser (which is what happens with an IFRAME), so this does not indicate that your PHP output is not being compressed.

We have confirmed that there IS compression enabled on your server. It may or may not be limited to PHP output. It may, in fact be applied to all pages (HTML and PHP) returned from your Apache server.

You can check this by using the HTTP response tool from web-sniffer.net.

First, we will confirm that the following URL points to your search page which uses the #include virtual call (and is displaying the garbled search results as we're currently seeing). Open the following link in a browser to confirm:
http://www.icdmeister.com/demo/searc...oom_query=test

Enter this URL in the web-sniffer tool. Note the default option that is enabled is "Accept-Encoding: gzip". This tells the server that we are willing to accept compressed data (GZIP is a compression method) if the server has this enabled. The web-sniffer utility will also decompress the response from the server accordingly.

Now, if the server does not have compression enabled, turning on or off this option would have no effect. But you will see that it does have an effect on your server.

When you make the request saying that you will accept GZIP encoding, the response (the HTML source code in the "Content" box) is what we are seeing in IE, that is the rest of the page comes through, but the search results (the bit that you used SSI #include virtual) are returned as gibberish).

When you make the request with GZIP unchecked, the response comes back with a full valid page. The search results HTML is also intact and ungarbled.

This little experiment indicates that GZIP compression is enabled on your server.

What is most likely happening (this may get a little confusing), is that when Apache comes across the SSI call, it executes the PHP script, and compresses the output from PHP. It then sticks this in the middle of the HTML page, and then compress the HTML page containing the compressed PHP output.

This means that when it gets sent across to the browser, which will in turn, uncompress the output, it will successfully uncompress the first layer of compression (that is the HTML page), but it won't uncompress the second layer (that is the PHP page included within). Clear as mud? Think of a ZIP file which contains another ZIP file. If the browser tries to unzip this file for you, the second file will remain zipped afterwards.

To summarize, it would seem that you cannot use SSI to call a PHP file from a HTML page, if you have compression enabled in either Apache or PHP. There may or may not be ways around this, but it is really a question left to the Apache/PHP documentation or forums.

I would suggest either disabling compression on your server, OR not using SSI to call PHP pages. The PHP include is probably the best method. There's not much to it, but you might want to find a developer friend who is familiar enough to show you the basics.

[aschecht]

Thanks for the intricate and thoughtful analysis. Very helpful. I'll first try to disable compression on my server by contacting my web host. If this doesn't work, I may redo the search page to use an iframe instead of SSI. I'll save the PHP include method as a last resort just because it'd be a steep learning curve for me.

Thanks again for your help.

Andrew

[aschecht]

I ended up solving this problem with a very simple solution.
For the search results template page only, I included the SSI content right on the page rather than including it with SSI. Inelegant perhaps but it works. Only limitation is I'll have to update the search template page if I change any of the include content.

Andrew