IncludeAble
<< | Cookbook-V1 | >>
Note: The recipes here are for PmWiki versions 0.6 and 1.0 only. For PmWiki 2.0 recipes, see Cookbook.
Joris abandoned project due to lack of time, personal need and interest from others.
Sorry folks...
Problem
One night I woke up, looked at the screen and saw a missing feature. Right now, PmWiki is a standalone system, it produces it's own formatting, html headers etc.
Goal
This project tries to make the wiki work as an include from another webpage.
It could also be used to build another navigation system arround the wiki.
Some people understand it better when you say it's like WebMenu, but the other way around.
It's based upon PmWiki v 0.50. The philosophy is that both PmWiki and the user's web pages should be modified as little as possible.
BTW, another approach to doing all of this, rather than redefining all of PmWiki's formatting variables, might be to simply define a new function/action to replace HandleBrowse/browse. The new function could do exactly what is desired. --<#>?
Installation
I'm trying to get the installation instructions together, at the moment the are not completed.
- Install pmwiki the regular way
- If you want to keep both pmwiki native style and includable, I suggest you copy the pmwiki.php file to something like includablepmwiki.php
- Create a local.php with the contents you find below
- path the wiki file you intend to make includable (includablepmwiki.php) with the patch you find below
- Create includewiki.php with the contents you find below
- For the moment, make sure a link
wiki.dexists in the php dir (webdir) to the real wiki.d and local.php. - Include the includewiki.php on every page you intend to make includeable, and make sure it's the very first code, before any output starts (or you'll get a Header already sent erorr)
- Include the includablepmwiki.php in your page wherever you want it in the page layout. See below.
- Cross fingers.
In action
To show the idea and my experiments:
[(approve links)
edit
diff]
Don't mind the other stuff on the page, the wiki is on the right.
had not been working for many days...(weeks?).
not working on 20031028 for many days...(weeks?).
Progress
It's almost done :)
- Done
- Include
- Remove html headers
- History broken (I was too drunk/sleepy, I think - it's not broken)
- Redirect after editing...
- Remove the top navbar
- Include logos
- Todo
- The other wikinav links are broken
- URL's after editing
- Turn the second include into a function()
- It needs a few system links
- Distill this page, remove dev chat text
- Add "ESC :wq" saving, vi style ;)
Problems
- The other wikinav links are broken
Both WikiHelp and SearchWiki are broken. Probably because of not passing parameters correctly. Low priority.
- Systemlinks
The wiki needs a wiki.d in the current dir (the including page's dir, not the pmwiki.php dir).
On unix systems, a symlink works just fine, but it's still an ugly solution.
Pm suggested adding this to the preloader:
$cwd = getcwd(); chdir("path/to/pmwiki");
include("pmwiki.php");
chdir($cwd);
Also, to make your local.php work, you need a system link in the same fasion as wiki.d ...
- Turn the second include into a function()
We can define a function in the includewiki.php that does the page inclusion.
The user would then do includewiki(pagename) instead of include blahblah.
This could make the solution to the previous problem more clean.
I'm not really a php god. In fact, I still have to learn how to define functions. So this might take a while.
- URL's after editing
After an editing session, the browser finds itself in [(approve links)
edit
diff]
Any relative links on the resulting page, are therefore put on top of yourfirstpage.php/Group/ wich, obviously, breaks regular links.
If it's unclear what I mean, have a look at my testpage: [(approve links)
edit
diff]
Before you edit, the browser is at that url, and the links, wich are relative (and bogus ;) ), point to [(approve links)
edit
diff].
Now edit the page a little, hit Save. Your browser ends up at [(approve links)
edit
diff], and therefore the relative links point to [(approve links)
edit
diff].
It can be solved by patching pmwiki not to do the redirect, and handle it with the loader script. (see the "Modify pmwiki" topic)
Working stuff
- Remove the top navbar
Since the intention is to include the thing right in the middle/bottom of another page, the top nav bar is a bit intrusive. Low priority.
Could be done with $HandleBrowseFmt = array('function:PrintText'); .
}
Another possibility is of course to add
$PageHeaderFmt = "";
And since the rest of the functions is broken, why not hide them:
$PageFooterFmt = "<hr /><small>
<a href='\$PageUrl?action=edit'>Edit Page</a> -
<a href='\$PageUrl?action=diff'>Page Revisions</a> -
Page last modified on \$LastModified</small>
<img src="http://www.pmichaud.com/uploads/Cookbook/pm-s.jpg" width="114" height="42 alt=PmWikiLogo border="0">";
- Redirect after editing
Solved
After editing the page, you get a Warning: Cannot add header information - headers already sent . This is, I think, because the php file where you include from already sent the headers...
A solution is to comment out the line "header("Location: $pageurl");", but then for some yet unknown reason the wiki dissapears after hitting the save button.
And refreshing doesn't work (at least in Opera 7.11 for linux), you have to re-enter the url. This can probably be solved with some smart html headerin'
This is a big problem. The way that the save (actually "post") operation works is that it saves the page to disk, then sends a Location: header back to the browser to tell it to reload the updated page from the server. But if pmwiki.php is embedded in another file and that file has already begun outputting things to the browser (text, etc.), then pmwiki.php has no way to tell the browser to reload the page after it's been saved. In theory pmwiki.php could just output the updated contents immediately rather than redirecting the browser to the page, but this causes a ton of serious browser cache problems (which is why PmWiki/PmWiki does it the way it does). I've commented on this a bit more in pmwiki-users. --<#>?
Solution:
First of all, don't try this at home. I mean, at production servers... Yet. Unless you're nuts, like me.
In your pages, add an include("includewiki.php"); at the very beginning. That makes two places where you need to include something to get this to work. I'm sorry, but that's the way it is for now.
includewiki.php would then look like this:
<?
if ($REQUEST_METHOD=="POST") {
require("path/to/pmwiki/includeablewiki.php");
exit();
}
?>
- Include
Do this in your main page, wherever you want the wiki to be:
$pagename = "Cookbook.IncludeAble";
require("/some/path/includeablewiki.php");
- Remove html headers
The following local.php can be used to remove both the extra http-headers pmwiki tries to send and the opening/closing html code:
<?php
$HTTPHeaders="";
$HTMLDoctypeFmt = "";
$HTMLTitleFmt = "";
$HTMLEndFmt = "";
?>
- Modify pmwiki
Ughm. It's back...
I don't understand the need for this patch -- and it's modifying function Redirect, not PrintFmt. I could also work on coming up with a modification to pmwiki.php so that this patch isn't necessary (I try to keep pmwiki.php so that people aren't having to patch it). --<#>?
It's not necessary, I just realised. It's a leftover from my trials to fix the redirect earlier... (just as a part of the includewiki.php)
After some testing, it turns out this is a solution to the URL's after editing problem. I built it by accident!
315,316c315,316
< header("Location: $pageurl");
< exit;
---
> // header("Location: $pageurl");
> // exit;
If the pmwiki is going to be included or embeded in other web pages, I thougt some powered by logos might be a good thing.
 |  |  |  |
Good idea, credit where credit is due :) Also, make them linkable
Notes
I'm a little concerned that adding all this to a webpage will increase it's cpu requirements. It might still be very little compared to something like *nuke, but...
Contributors
joris [snail] linux [period] be pmwiki-2.3.32 -- Last modified by {{}}?