No, but that doesn't mean that SSI's are not in use. Server side includes are completely independant of the PHP code in use. You can technically (albeit, not at all useful) use PHP to generate output to represent as a .shtml code and pass that back to the server to deal with the SSI's. Typically we don't, as that is slow and kinda pointless; on apache webservers if you *really* wanted to use the SSI directives you can invoke the virtual() function to carry them out. All I was getting at is that #include isn't a PHP directive. If that's in a php file such as:
PHP Code:
<?php
#include 'afile';
Than it will be ignored as # is a commenting character in PHP (along with //, block with /* */ and doccomment with /** */).
So the best way is to check your HTML source code. If you literally see in it the #include in an SSI directive, than this would require a removal of the SSI and placement where desired within the php code. The logic is near identical (I'll even specify it as a PHP block for both):
Code:
print 'Some PHP code';
print '<!--#include virtual="/directory/included.html" -->';
print 'Some more PHP code';
And assuming the SSI is outputable, you can simply replace it as such:
Code:
print 'Some PHP code';
include "/directory/included.html";
print 'Some more PHP code';
If your host states that .html isn't include-able, that's complete rubbish. Think of it as a structural change; you literally take what is read from the call of the include, and place it within your PHP script. The logic would be: include -> close PHP tags -> import content -> open PHP tags, so if your include script is .HTML without any preprocess directives, then its output type would be text so it would insert that into the output buffer at that location. If its in PHP blocks than it would parse that first.
Unless you mean that you cannot parse .html as .php code (as in you are accessing a .html that should be interpreted as .php), then Fumigator had it correct in the first answer for modifying the handles to accept .html as a php executable type.