ExportHTMLWiki-Talk

Summary: Talk page for ExportHTMLWiki.
Maintainer: HansB
Users: (View? / Edit)

This space is for User-contributed commentary and notes. Please include your name and a date along with your comment.

Congratulations, Hans. This could be very useful for heavily read static pages on wikis. I assume it doesn't handle url request variables. To take a simple example, I assume there is no way to show the results of action=history as of the last time the page was saved, let alone show a page generated by custom requests. All you can do is show what the page looks like the moment after "save" is pressed after editing, although JavaScript such as your wonderful Toggle recipe should work. - RandyB January 11, 2016, at 09:30 AM

Yes, you are completely correct, Randy. Url parameters are not handled at all, since no PHP script is called, simply a static HTML page is served. Javascript will function. Forms will submit data too, but their success depends on a) is the url for the script called correct (the recipe tries to render a correct url for forms in the HTML page), and b) what shall the outcome be of a form submission, can a user be returned to some static HTML page, or some dynamic page showing some results, but which can be used as if it is part of the static HTML pages (i.e. any links on this page pointing to HTML pages, not wiki pages). For instance I could not get a functional Search form on a static HTML page, but I managed to get a functional Contact form, with redirection to a static HTML page. So clearly there is scope to improve the recipe, and it has some severe restrictions. HansB January 12, 2016, at 03:55 AM

I have a problem saving the HTML files. Before every letter in HTML there is a sequence ../..// . Is it a configuration issue of my local wiki? Bernhard May 8, 2020

Hi HansB,
I'm using pmwiki for a long time as a place for notes and HowTos. To keep it portable I'm using the standalone recipe and I'm very comfortable with it.
Now I want to set up a small personal webpage using static HTML, based on a local instance of pmwiki for editing. So I tried your recipe and I do like it.
Unfortunatly I got the same problem Bernhard posted at May 8, 2020 and I'm sure it's a configuration problem I have to solve.
There are two other issues I found while I was testing:

  • Using the configuration option "'update' => true" will add a "| Bearbeitet" (I'm using germnan language pack) to the title tag in the HTML-file, which does not make sense to me. The alternative is to disable it. This means to save the changed page, logout, use action=html and then login again to edit the next page. Not very comfortable.
  • The link to css-folder ist not converted. I prevent using the "loclhost:80" and use "localhost:8080" instead. So the converted page allways tries to find css at "//localhost:8080/pub/css", which is not available at the webserver. I tried with "$SaveHTML["localhost"]" and "$SaveHTML["serverhost"]" but it didn't work. Is there an other way to realise it?

Greeting (an other) Bernhard

HansB: Regards #1: You could try and add your own replacement pattern rules. The key is a regex, which would be replaced by the value. In your case add the following to config.php before including the script:

   $HTMLRewritePatterns['!| Bearbeitet!'] = '';

Regards #2: Setting different values for $SaveHTML["localhost"] and "$SaveHTML["serverhost"] should normally do the trick. The first gets replaced by the second. Again you could add a more specific replacement rule to $HTMLRewritePatterns. Hope this may help a little! I am not sure what is going on regards to the problem reported above by Bernhard May 8, 2020. Perhaps $SaveHTML['htmldir'] needs to be set to something specific, the default is a relativ path "../"

Dear HansB,
of cause

  $HTMLRewritePatterns['!| Bearbeitet!'] = '';
does the job and I should have known that ...
Using $SaveHTML doesn't work, but $HTMLRewritePatterns['!http://localhost:8080/pub!'] = '../pub';
in config.php is a fix (OK, it's quick and dirty, but it works!).
Adding $HTMLRewritePatterns['!../..//!'] = '';
to config.php will not solve the problem with the strange patterns in html file, so I have to find a solution for that. Of cause the dirty solution is to use a texteditor to fix that ...
Thank you for the tipps
Bernhard (still the other one ...)

HansB: could you give me an example of those strange "../..//" insertions? What in the wiki text is changed to what in the HTML? Thanks!

Here is an example (I just used ?action=html, but saving it after editing is the same result):
../..//<../..//!../..//D../..//O../..//C../..//T../..//Y../..//P../..//E../..// ../..//h../..//t../..//m../..//l../..// ../..// ../..// ../..//P../..//U../..//B../..//L../..//I../..//C../..// ../..//"../..//-../..///../..///../..//W../..//3../..//C../..///../..///../..//D../..//T../..//D../..// ../..//X../..//H../..//T../..//M../..//L../..// ../..//1../..//.../..//0../..// ../..//T../..//r../..//a../..//n../..//s../..//i../..//t../..//i../..//o../..//n../..//a../..//l../..///../..///../..//E../..//N../..//"../..// ../..// ../..// ../..//"../..//h../..//t../..//t../..//p../..//:../..///../..///../..//w../..//w../..//w../..//.../..//w../..//3../..//.../..//o../..//r../..//g../..///../..//T../..//R../..///../..//x../..//h../..//t../..//m../..//l../..//1../..///../..//D../..//T../..//D../..///../..//x../..//h../..//t../..//m../..//l../..//1../..//-../..//t../..//r../..//a../..//n../..//s../..//i../..//t../..//i../..//o../..//n../..//a../..//l../..//.../..//d../..//t../..//d../..//"../..//>../..// ../..//<../..//h../..//t../..//m../..//l../..//>../..//

It should be:
<!DOCTYPE html

	PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" 
	"http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">

HansB: okay, that is so weird! Can you provide any customisation/configuration settings you use with the recipe? Does this happen when you got other recipes/customisations disabled on your wiki? What skin do you use? Does it happen with the default skin?

Um, a in a regular expression pattern, a "dot" is a meta character that means "any character", and the "|" character separates between alternative subpatterns. So '!../..//!' and possibly '!| Bearbeitet!' may mean something different from what you intend. --Petko

HansB]]: Yes, Petko, thanks!
The vertical line should be escaped for the regex: $HTMLRewritePatterns['!\| Bearbeitet!'] = ;
And $HTMLRewritePatterns['!../..//!'] =
; should not be used. Question is what is inserting those "../..//" characters when a wiki page gets saved as HTML? I have never encountered such. If I would troubleshoot this, I would comment out the code line
ExportHTMLUrlRewrite($pagename, $group, $html);
so the script does not do any pattern replacings, just to see if the "../..//" before every character still happens, to rule out that there are bad patterns at work. I suspect something else is happening.

Hi HansB,
my first test was to comment out all other recipes in config.php. The result is the same, so I don't think other recipes are the reason for the pattern.
The next step was to comment out the line ExportHTMLUrlRewrite($pagename, $group, $html). Now the result is HTML without strange pattern. But of cause the $HTMLRewritePatterns has no effect any more.
To your configuration in the recipe I only added $HTMLRewritePatterns and two groups to the excluded pages. But the strange patterns appeared before I made these changes.
Bernhard

HansB: okay. So some code line in function ExportHTMLUrlRewrite may cause that havoc. What is your setting for $SaveHTML["htmldir"]? What if you set it to, for example, $SaveHTML["htmldir"] = 'HTML'; I can see potential problems how this is handled in the script. I can see also problems how the script tries to determine file paths, especially the directory of the wiki field. PmWiki has no variable for that. I am revising the script, so customisation of relative paths are handled better.

Bernhard: Changing $SaveHTML["htmldir"] = 'HTML' doesn't work. It creates a new HTML folder but the pattern is still the same.
To make sure there is no problem with the PHP version I created a new instance on my local webserver with PHP 8.2.6 and created an actual release of pmwiki in a folder I called Testwiki.
Now the strange pattern is ../Testwiki/. So it seems to be a problem of replacing something by the pathinfo, or inserting if before each letter in html ...

HansB: I updated the script. It needs now explicit setting of $SaveHTML['wikipath'] for the path from the web root to your wiki field. $SaveHTML["htmldir"] is set as default to 'HTML/', which will be the folder name for the HTML files, under the wiki field directory. I added an option to set $SaveHTML['relativeurls'] = false; in order to get absolute URLs, in case the default relative URLs don't work. This update might not cure your problem with the inserted dots and slashes in front of every character, as I do not understand what is causing this in your setup.

Bernhard: With relativeurls = false it works fine now, there are no patterns any more. Setting relativeurls = true still has a pattern ../../. So I will use relativeurls = false and $HTMLRewritePatterns to replace the path to css.
Having the issue with the patterns I set up a very simple instance to make sure there is no issue using a wrong version for PHP, pmwiki or even other recipes. It's a XAMPP(latest with PHP 8.2.6) and a pmwiki(latest). The config is the sample-config out of the docs folder. ExportHTMLWiki is the only recipe I added to cookbook and config.php.
Thank you for your patience and for the cool recipe! Bernhard.

HansB: If you would like this further investigated, perhaps you could check which of the code lines with replacement patterns in function ExportHTMLUrlRewrite() is causing this behaviour in your setup when $SaveHTML['relativeurls']=true;. You could comment out a line at a time and see what the result is, find a culprit for the insertion bug. Each replacement pattern is applied in turn to the html output. Maybe I can take it from there. But really like to replicate the bug, which I have not been able to do.

Bernhard: When I comment out line 270 ('!'.$UploadUrlFmt.'!' => $root.$UploadDir,) html is fine. As it is a basic installation neither $UploadUrlFmt nor $UploadDir is set in config.php. Adding them to config.php makes it work fine.

HansB: Oh thank you for finding this bug! Newest release should work now. I had not realised that an empty regex pattern will match any character! With Uploads not enabled we had a replacement pattern of '!!' => '../../'. Thank you for your perseverance and help!

Bernhard: The new release is working fine. Thank your for this recipe.

Talk page for the ExportHTMLWiki recipe (users?).