This function on the WikiAdministration page creates a dir with all pages in xhtml format "so as to be used on a server with no web server".
The files created have no .html suffix and links between also do not reference with suffix's, but the code appears to try to add these - are the patches from Feb 2002 included or superceded by the 1.3.3 release?
Am i 'not getting' the intention of this function?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Originally we tried with .html suffix. However, do to difficulties in getting the cross-page linking working Carsten removed the suffix - it is currently at least self-consistent, though not correct.
I have been trying on and off for a while to get the cross-page linking working, but something to do with the encapsulation in PHP and phpwiki is getting in the way.
If we define a constant within the GeneratePageasXML() function, we can access it from within linkExistingWikiWord() as follows:
if (defined('HTML_DUMP')) {
$link->setAttr('href',$this->maybeSplitWikiWord($wikiword) . ".html");
}
And then we can re-enable the .html suffix in DumpHtmltToDir() and we're all set.
However, constants are bad news as the constant will still be defined after exiting GeneratePageasXML() and that could cause a conflict later...I'm not sure you can even undefine them. If we use a variable, it seems that no matter how global it is there is no way to get it from GeneratePageasXML() (which is in Template.php but outside that class) to anything within the Theme class, even if I try to mess with the creation of that instance of the theme. I've thought of writing a new constructor for Theme but have yet to find the time to do this.
On the flip-side, if a way can be found, then similar modifications to the linking scheme can be used to dump the Wiki in a form that is more suitable for hardcopy (e.g. putting the URL in brackets after external web links, numbering the topics, etc).
I'm sure this global variable issue is not just something annoying me - have others experienced the same? Are there any workarounds?
So, in short, you are getting the intention of this function, but intention doesn't quite equate to action!
Cheers,
CuthbertCat
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Actually there's been some progress on this since your post. Carsten changed the Theme class to add a new variable, and then modified this from within DumpHtmlToDir() - so if you define HTML_DUMP_SUFFIX to be '.html' in your index.php the functionality you want is now in there. The XHTML zip is still not working, and in any case we don't have a routine to intelligently mirror images (and adding them to the zip is hard, too) so there are still a few rough edges.
Hope this helps,
CuthbertCat
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Cheers - I'll check out the CVS and give it a try.
As background, what I am working towards is being able to use Wiki for internal development and collaboration docs, and then allowing a snapshot to be uploaded to an external web site for clients/managers to review.
Regards
Liam
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
This function on the WikiAdministration page creates a dir with all pages in xhtml format "so as to be used on a server with no web server".
The files created have no .html suffix and links between also do not reference with suffix's, but the code appears to try to add these - are the patches from Feb 2002 included or superceded by the 1.3.3 release?
Am i 'not getting' the intention of this function?
Originally we tried with .html suffix. However, do to difficulties in getting the cross-page linking working Carsten removed the suffix - it is currently at least self-consistent, though not correct.
I have been trying on and off for a while to get the cross-page linking working, but something to do with the encapsulation in PHP and phpwiki is getting in the way.
If we define a constant within the GeneratePageasXML() function, we can access it from within linkExistingWikiWord() as follows:
if (defined('HTML_DUMP')) {
$link->setAttr('href',$this->maybeSplitWikiWord($wikiword) . ".html");
}
And then we can re-enable the .html suffix in DumpHtmltToDir() and we're all set.
However, constants are bad news as the constant will still be defined after exiting GeneratePageasXML() and that could cause a conflict later...I'm not sure you can even undefine them. If we use a variable, it seems that no matter how global it is there is no way to get it from GeneratePageasXML() (which is in Template.php but outside that class) to anything within the Theme class, even if I try to mess with the creation of that instance of the theme. I've thought of writing a new constructor for Theme but have yet to find the time to do this.
On the flip-side, if a way can be found, then similar modifications to the linking scheme can be used to dump the Wiki in a form that is more suitable for hardcopy (e.g. putting the URL in brackets after external web links, numbering the topics, etc).
I'm sure this global variable issue is not just something annoying me - have others experienced the same? Are there any workarounds?
So, in short, you are getting the intention of this function, but intention doesn't quite equate to action!
Cheers,
CuthbertCat
What I did temp. is that I add the line...
$link->setAttr('href',$this->maybeSplitWikiWord($wikiword) . ".html");
just before the
return $link;
line in linkExistingWikiWord, Theme.php
... when I want to dump in XHTML and have the links ok
But a lot of unwanted html is still generated for What I want to do = dump the content as HTML documentation.
In fact this is the start of the usage of Wiki as a Web Content Management System.
Authors can contribute on a server and (x)html publishing would be deployed on another server.
By the way I have problems to load the generated XHTML with MSXML4... But not with Amaya...
JF
Actually there's been some progress on this since your post. Carsten changed the Theme class to add a new variable, and then modified this from within DumpHtmlToDir() - so if you define HTML_DUMP_SUFFIX to be '.html' in your index.php the functionality you want is now in there. The XHTML zip is still not working, and in any case we don't have a routine to intelligently mirror images (and adding them to the zip is hard, too) so there are still a few rough edges.
Hope this helps,
CuthbertCat
Cheers - I'll check out the CVS and give it a try.
As background, what I am working towards is being able to use Wiki for internal development and collaboration docs, and then allowing a snapshot to be uploaded to an external web site for clients/managers to review.
Regards
Liam