Input Files Supported by Fiverizer
What Type of Files Can Fiverizer Convert?
In general, Fiverizer can only convert a web page if the following conditions are true:
Your web pages contain valid, well-formed XHMTL 1.0 (Strict or Traditional). One way to find out if this is true is to use the W3 Consortium's free HTML validator to check your page. If the validator says that it is XHTML 1.0 with no errors or warnings, it means that it satisfies this condition.
Your web page must use the Unicode UTF-8 encoding. It can also be in plain ASCII, since the latter is a subset of UTF-8. Unlike earlier versions of HTML, HTML5 only allows the UTF-8 encoding.
Note that if your page is in the Windows-1252 encoding (referred to by Windows as "ANSI") or in ISO 8859-1, Fiverizer may still be able to convert it correctly, without corrupting the output (assuming that the original page contained valid XHTML 1.0). However, the HTML validator will not regard the resulting page as valid HTML5, since, as I said, UTF-8 is the only character set accepted in the HTML5 specifications.
Fiverizer is not an HTML validator. It does not check if your page is well-formed and valid or that it is in the correct encoding. It assumes that it meets these requirements, and blithely tries to convert it. As such, if your page has errors or if it is in the wrong encoding, it's possible that you will end up with a mangled file.
It's very important that you make a back up of your entire website before starting the conversion process. This is the case even if you know for a fact that all your pages are perfect, with zero errors. Any software of sufficient complexity is likely to have bugs, since they are made by fallible humans who are not omniscient. With a backup, you don't have to worry whether your pages have errors or whether there is a bug in Fiverizer that might make it choke on them. If anything goes wrong, you can just restore the original files.
Can Fiverizer Handle SSI or PHP Code?
Fiverizer is not a PHP interpreter nor is it an SSI handler, and as such, does not understand PHP code or SSI directives.
That said, when Fiverizer encounters a block demarcated by "<--#
" and "-->
"
(used for SSI), or "<?
" and "?>
" (used by PHP), it treats anything
enclosed within it the way it treats HTML comments. That is, it ignores the contents, and does not
attempt to convert anything included therein.
This may (and notice that it's only a "may") allow it to work in a very limited way for extremely simple cases. Take for example, the following SSI code used to insert the HTML for the side column of a web page:
<--#include virtual="side-column.html" -->
</div>
and its PHP equivalent:
<?php include "side-column.html"; ?>
</div>
The SSI directive and the PHP code (1) occur outside an HTML element (ie, tag), and inserts content that is (2) self-contained and (3) unrelated to the existing HTML on the page. Fiverizer ignores everything in that block and resumes parsing only after the closing angle bracket. It treats that section as though your page had an HTML comment at that location that needed no processing. As such, in this particular case, everything seems to work fine and is indeed fine, since the SSI and PHP code has no impact on the code that Fiverizer needs to convert.
Note, however, the following:
The PHP or SSI block cannot occur in the middle of an element tag. For example, the following code may cause problems with the conversion process.
<div <?php echo $div_attributes;?> id="this_may_not_work">Even if Fiverizer does not mangle the code in your specific situation, it is not designed to deal with such a construction.
The inserted content must be self-contained. That is, it must be complete in itself (where the HTML is concerned). For example, if you start a
<div>
in it, the closing</div>
tag must also be in that inserted content. Don't use Fiverizer on files where you put a starting tag in the main file, and the closing tag in the inserted code, or vice versa. That way madness lies.The inserted content must be unrelated to the existing HTML code on the page. By unrelated, I mean in an HTML sense. For example, Fiverizer will trip over the following code (that is, it will fail to convert it correctly):
<p>This will NOT work correctly!</p>
<frameset cols="20%,80%">
<php echo $left_frame_html_code; ?>
<frame src="right-frame.html" />
</frameset>The above code starts a frameset, and has one of the "
<frame>
" lines generated via PHP. Since Fiverizer does not run PHP code, it will only see the final "<frame>
" line, and think that your frameset has only one "<frame>
" line specified. This will lead to it having a wrong understanding of your code, and generate the wrong HTML5/CSS equivalent.
Fiverizer relies on your page having valid and well-formed XHTML. If some of your code is generated by a server-side programming language or directive, it will be not be visible to it. All Fiverizer sees is the page in its original condition, before the web server has got its hands on it to alter it. If there are things inserted into the page by PHP or SSI that changes the meaning or flow of the HTML tags, Fiverizer will not know about it and you may end up with output that is nonsensical.
If, in spite of what I said above, you still want to run Fiverizer on a page that has SSI or PHP code, make sure you really have a back up of your XHTML 1.0 site, so that if things go awry, you can just replace the HTML5 output with a copy of your original page.
Another important thing to remember is that Fiverizer only converts the web pages that you ask it to convert. It will not seek out and convert any files that you include via an SSI directive or PHP command. After all, it doesn't understand SSI or PHP code. As such, don't forget to manually convert the code in those files as well.
In case you are wondering why I bothered to make Fiverizer ignore PHP and SSI blocks when they aren't even in the XHTML specifications, it's because I originally created Fiverizer to convert my own websites, thesitewizard.com, thefreecountry.com and howtohaven.com. Nearly all my pages have SSI includes that insert common code into the pages (similar to the very first example given above), and I wanted Fiverizer to be able to handle this specific situation.