Wikka Mod 042
Type: Feature AdditionCredit
The author of WakkaWiki handlers/page/raw.php (assuming Hendrik Mans)Jason Tourtelotte (slimmed it down, and added passing the output through nl2br and htmlspecialchars)
GmBowen for prompting the development
Description
This modification adds a page handler that shows the raw code of a page, formatted somewhat for viewing.
Usage:
Add /showcode to the end of any page URL.
For example:
http://wikkawiki.org/HomePage/showcode
handlers/page/showcode.php
<?php
if ($this->HasAccess("read") && $this->page) {
// display raw page, slightly formatted for viewing
print(nl2br(htmlspecialchars($this->page["body"], ENT_QUOTES)));
}
?>
if ($this->HasAccess("read") && $this->page) {
// display raw page, slightly formatted for viewing
print(nl2br(htmlspecialchars($this->page["body"], ENT_QUOTES)));
}
?>
What I would like to see, instead, is something similar to what I called a 'rawcontent' method (http://wikka.jsnx.com/IncludeRemote), showing *only* the source of the page, with the header and footer stripped. The only difference with the current raw method (beside the absence of header and footer) is that the output is printed with a:
header("Content-type: text/plain")
which - BTW - already takes care of newlines, hence producing a 'readable' version of the page source.
Having a purely textual version of the source makes this source available for a number of uses, including the possibility of fetching content from another Wikka server (see the link above) and formatting this source in a "showsource" action, in the lines of what Mike had suggested on his page (the nl2br and htmlspecialchars conversions can always be performed at the end of the process, they need not be hardcoded in the method itself).
Your thoughts?
The current raw does not fulfill this need. For example, take a peak at the homepage using raw. You will not see the code for the wizard. The output needs to be passed through htmlspecialchars. So the current raw does not work for this situation. Something new is needed.
And if we only create an action that strips the header and footer, as you describe, this doesn't work very well either, because it will make the viewing experience disjointed. One minute you are seeing the site, the next minute you are seeing just a page of text.
I think two handlers are needed. One for someone who is curious about wikka formatting code, and one for backend processing.
I debated with myself last night whether we should modify the current "raw" handler to suit your proposal, now that we have this action to take care of those who just want a peak at the formatting code. What do you think?
I see two possible options for replacing the current 'raw' handler:
Option 1:
Create *two* different handlers handling 'upstream' the two different uses:
a) handlers/page/showcodepage - providing human-readable, clean and formatted source code of the current page along with header and footer;
b) handlers/page/rawcontent - providing plain-text page source with header and footer stripped;
Option 2:
Use only *one* handler (rawcontent) and create different actions to deal with the raw content 'downstream':
a) A {{fetchremote}} action will allow to use rawcontent from a remote server on a Wikka client;
b) A simple {{showcode}} action will format (nl2br, htmlentities etc.) the rawcontent of the current page in a way that can easily allow switching between the formatted and the raw view.
My suggestion was course 2) - which I still find more economic - but basically the two ideas are equivalent.
After all, the (wiki) content of a page _is_ plain text - so why not simply show it as such? KISS, and all that. :)
However as I've explained, there should be an additional handler that allows people to view the code without making it seem like they left the site.
If you switch to a page that is completely different from the previous page--without any formatting--doesn't it seem as though you have left the site?
Here's why: The showpagecode handler is needed when people don't have write access to a page. If they did have write access, they could just double-click on the page and view the source.
If they don't have write access, how can they use the {{showcode}} action?
Are we going to require that every page have a {{showcode}} action?
I'm not understanding why you would favor approach #2.
DarTar used the word "economic".
JavaWoman mentioned keeping it simple.
How can you get more simple and economic than handling this at the handler lever? That's pretty simple and economic.
Look at the two lines of code used in the handler on this page.
How many hoops would the PHP processor jump through if we handled this through an action? Now compare that to doing this through a handler.
Give me an example of how your proposed {{showcode}} would be implemented and perhaps I'll understand why it is a better idea.
I apologize if my comments seem a bit off the cuff. I just never expected such a simple change to draw such puzzling responses..... that make no sense. ;)
What do you wan't to do anyway?
1. Show the layout of a page to peoiple who have no write acess. Well, in Wikipedia, there is a link "show sourcecode" shown instead of the edit-link if you can't edit a page. Perhaps also possible here?
2. get raw pages from a server. Including would cause to much traffic, but how about an exportfunction wikka-wikka for a page?
Always expect the unexpected when creating software. ;-)
However, I agree showing (raw) page code should be a handler, not an action. But that enables serving it with a text/plain content-type, doesn't it? Or am I misunderstanding how a handler works? (I haven't looked at that side of Wikka much yet, I've concentrated mostly on actions and "supporting" code.)
@Jsnx:
Ok, I'm now convinced that two handlers are needed :-)
But then, if the showpagecode (long name, BTW, can't we find something shorter) is supposed to allow users to display the source of a page, why not adding some style (like some padding, perhaps a border around the code) and maybe a title: "==Source of ".$this->page."==" ).
I like also Nils suggestion of a link whose text depends on writing privileges, but this could hinder future development of WikkaMenus.
[raw handler]
@Nils
The issue of traffic is not really important if you consider that 'fetching' a Wikka page produces the same amount of traffis as 'browsing' that page - which a user looking for up to date documentation will do in any case. Actually, the traffic is even less, if the page is accessed in a raw mode.
@JsnX
Is the current 'raw' handler used somewhere in Wikka or can we just replace it with the new one? Please have a look at the last proposal I made in http://wikka.jsnx.com/IncludeRemote - if you agree with the basic idea, I might already modify wikka.php on this server to test and debug the FetchRemote plugin.
What if the big (and somewhat useless) pagetag link in the header allowed to switch between source view and formatted view? One click you see the source, another click and you're back to the page! :-x
I'd like to have your permission to modify wikka.php on this server to start testing the FetchRemote plugin. I'd also like to know if the current 'raw' handler is used somewhere in Wikka. If it's not the case, I might adapt the current 'raw' handler to work like what I called 'rawcontent' in the above "Option 1".
I'd prefer we use "raw"--it's not used anywhere currently. I've made the changes as requested. Check it out.