Although I am not a huge fan of PHP, there are some things it does well. One of those is content reuse on web pages. Having previously built a (no longer extant) website which used little more of PHP than the include function, I admit the choice saved a lot of time and code for little cost. A little PHP enabled content reuse without a CMS.
This post describes a simple “re-skin” of an existing HTML5 output. The idea is to use the topic files and the Toc.xml file to recreate a navigation and topic display. This will be a simple example without many bells and whistles and no CSS. But you can build on it if you find it useful. This example does not goes as far as using the Title attribute for the text of the links or indenting the links based on topic level. This is just a proof-of-concept.
To create the PHP “skin,” you can install PHP on the web server hosting the skin, place the Flare HTML5 output on the web server, and place the code sample in a file called Index.php at the root of the Flare HTML output folder. You can read more about how PHP works at:
In the PHP file, HTML5 syntax will be used for the HTML portions and the scripting will be PHP tags. The “skin” will have a list of linked topics based on Toc.xml in the Data folder of the HTML5 output and a view of the selected topic which appears at the top when you click a link.
A previous post described how to return all of the Link attributes in the TocEntry elements in the Toc.xml file in an HTML5 output with XPATH. That was a building block post. Now we are going to use that block to build the list of linked topics.
In Flare HTML5 output, the URLs for topic navigation appear as a pound sign and topic file name after the URL for the main help file: http://localhost/flareoutput/default.htm#topicname.htm
With this PHP “skin,” the URL will look like this: http://localhost/flareoutput/Index.php?topic=topicname.htm
The first PHP script checks if there is a topic qualifier in the URL. If there is a topic qualifier, the script removes the / from the beginning. This is because Toc.xml stores the paths that way and PHP expects no / at the beginning of relative URLs in this case. It loads the topic into an iframe at the top of the page. There is also a check to see if the qualifier is there: isset.
The second script uses the XPATH expression to get all of the Link values for TocEntry elements in Toc.xml. It displays each as a hyperlink with a format which uses Index.php and the qualifier with the topic name.
You can install PHP on your web server, copy a Flare HTML5 output to it, place an Index.php file containing the sample below at the root of the output, an open the URL to Index.php to see this work.
Index.php:
<!DOCTYPE html>
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
<title>Simple Flare Skin</title>
</head>
<body>
<?php
if (isset($_GET['topic'])) {
$topic = $_GET['topic'];
$topic = substr($topic, 1);
echo "<iframe src='", $topic, "'></iframe>";
}
?>
<?php
$xml = simplexml_load_file("Data/Toc.xml");
$tocentries = $xml->xpath('//TocEntry/@Link');
while (list(, $tocentry) = each($tocentries)) {
echo "<p><a href='?topic=", $tocentry, "' target='_self'>", $tocentry, "</a></p>";
}
?>
</body>
</html>
Interesting concept and exactly the case where PHP is the solution. And PHP is the solution to many other tasks. Sites like Facebook and Wikipedia as well as plenty of media sites using WordPress as CMS are entirely built with PHP. Not sure why PHP always gets such a bad rap and blogs like this one diss it.
I agree that usage lends some credibility to a language. For example, I’m discussing PHP on my blog even though I’m not a fan, which I don’t consider to be a diss.
Cool concept. I wonder if this would solve my problems with the search function…
Very cool idea! I’m interested in using this technique to reskin the HTML5 output and I’m wondering if there’s a straightforward way to use flare’s search on this index.php site. Any idea what I’d need to do to get that working or if it’s possible?
I should post an update to this. Since writing this post, MadCap has replaced the XML data file for the TOC with a JSON format. So the steps to parse that are a little different. You can read the search files in a similar manner. Also the process is a little more complicated when the search or the TOC is chunked out into multiple files. Thanks for reading. I’ll see if I can post a follow up to this soon.
I’ve been working around the TOC chunk issue simply by grabbing the appropriate .fltoc file and putting it in the output as an .xml file instead. There’s probably a more elegant solution, though.
That is a pretty cool trick.
I go into a little more detail about how to to use RequireJS to load the TOC data in the Revisualizing a TOC with arbor.js. It doesn’t go all the way. But it may be helpful.