Additions:

[[KlenwellAdminOnlyInstaller Admin-Only Installer]]

Deletions:

===Note on Installer===
(I can't seem to post this anywhere else):
Is it possible to restrict the installer pages to an admin? I upgraded to 1.3.2 just now. I had completed the install on a local dev version and planned to just upload that. But I found I needed to run the installer on my production site, too, to make the database updates. I noticed that while it was running, the install/upgrade pages were accessible to non-logged-in guests. This seems like a potential security vulnerability as it may display the config file.
Next time, I upgrade, I'll look into adding this restriction myself if it doesn't already exist.

Additions:

===Note on Installer===
(I can't seem to post this anywhere else):
Is it possible to restrict the installer pages to an admin? I upgraded to 1.3.2 just now. I had completed the install on a local dev version and planned to just upload that. But I found I needed to run the installer on my production site, too, to make the database updates. I noticed that while it was running, the install/upgrade pages were accessible to non-logged-in guests. This seems like a potential security vulnerability as it may display the config file.
Next time, I upgrade, I'll look into adding this restriction myself if it doesn't already exist.

Deletions:

Additions:

my wikka site: http://klenwell.com/is/
blog: http://klenwell.com/press/
===Wikka Development===
Since upgrading to version 1.2, I've become more interested in exploring Wikka and developing some extension and features. More information on the development projects I'm working on can be found on [[http://klenwell.com/is/ProjectWikka my wiki]].
I've redesigned my wiki site using the [[http://docs.wikkawiki.org/WikkaThemes new theming system]]. The source code for that, and other wikka features I'm working on, can be found at [[http://code.google.com/p/klenwell/source/browse/trunk/projects/php/wikka/#wikka/templates/klenwell my Google code site]].
The wish list below includes a sampling of features I'd like to find or develop for the Wikka package. The [[http://klenwell.com/is/ProjectWikka updated list]] is available at my site.
===Wikka Wish List===
Command Line Interface (esp. for cron jobs)
Daily Report Scripts (run as cron jobs with CLI)
Gmail Integration
ReCaptcha-protected Comment and Login Forms

Deletions:

my wikka site: http://www.klenwell.net/is/HomePage
blog: http://phosphorusandlime.blogspot.com/
===Code Contributions===
[[http://www.klenwell.net/is/WikkaSkinCustomization Wikka 3-Column Layout Customization]]
[[http://www.klenwell.net/is/WikkaChangeNotifier Wikka Recent Changes Notifier]]
""<a id="handler_source"></a>""
===Proposed Page Handler Revision===
A good first step in intelligently refactoring the page handler code would be identifying the discrete html elements that make up the html it outputs. I've created the following page to list out the html elements and controller events that output core wikka page:
HandlerShowSchema
The page-rendering code (''handlers/page/show.php'') for wikka, at the moment, is a bit disorganized. I notice there are some references to a new templating model in [[http://wush.net/trac/wikka/browser/trunk/handlers/show/show.php the latest release]] and notice the improvement being made. But I think this part of the code could benefit by following a more organized controller logic. Find my proposed revision of ''handlers/page/show.php'' below:
**Its advantages**
- eliminates confusing mixture of logic and presentation layers
- preserves all elements of the current source code
- offers a controller for more cleanly determining which elements of the page get displayed
- distinctly identifies each element of the resulting layout
- provides a simple prototype for a templating model
- makes it easier to change major layout elements for web designers
- my tests of it thus far have been successful
Note: this was submitted to Wikkawiki dev site as [[http://wush.net/trac/wikka/ticket/532 Ticket #532]]
**Code Source**
[[KlenwellCodeHandlerShow564 show.20070712.php]] (based on [[http://wush.net/trac/wikka/changeset/564 revision #564]])
[[KlenwellCodeHandlerShow637 show.20070805.php]] (based on [[http://wush.net/trac/wikka/changeset/637 revision #637]])

Additions:

A good first step in intelligently refactoring the page handler code would be identifying the discrete html elements that make up the html it outputs. I've created the following page to list out the html elements and controller events that output core wikka page:
HandlerShowSchema

Additions:

The page-rendering code (''handlers/page/show.php'') for wikka, at the moment, is a bit disorganized. I notice there are some references to a new templating model in [[http://wush.net/trac/wikka/browser/trunk/handlers/show/show.php the latest release]] and notice the improvement being made. But I think this part of the code could benefit by following a more organized controller logic. Find my proposed revision of ''handlers/page/show.php'' below:
**Its advantages**

Deletions:

The page-rendering code (''handlers/page/show.php'') for wikka, at the moment, is pretty sloppy. I notice there are some references to a new templating model in [[http://wush.net/trac/wikka/browser/trunk/handlers/show/show.php the latest release]] and notice the improvement being made. But I think this part of the code could benefit by following a more organized controller logic. Find my proposed revision of ''handlers/page/show.php'' below:
**It's advantages**

Additions:

Deletions:

Additions:

The page-rendering code (''handlers/page/show.php'') for wikka, at the moment, is pretty sloppy. I notice there are some references to a new templating model in [[http://wush.net/trac/wikka/browser/trunk/handlers/show/show.php the latest release]] and notice the improvement being made. But I think this part of the code could benefit by following a more organized controller logic. Find my proposed revision of ''handlers/page/show.php'' below:

Deletions:

The page-rendering code (''handlers/page/show.php'') for wikka, at the moment, is pretty sloppy. I notice there are some references to a new templating model in the latest release and I admit that I have not investigated it yet. But I did rewrite the code to follow more of a MVC pattern. Find below the actual rewritten file for ''handlers/page/show.php''.

Deletions:

Additions:

===New Page Template===
The page-rendering code (''handlers/page/show.php'') for wikka, at the moment, is pretty sloppy. I notice there are some references to a new templating model in the latest release and I admit that I have not investigated it yet. But I did rewrite the code to follow more of a MVC pattern. Find below the actual rewritten file for ''handlers/page/show.php''.
**It's advantages**
- eliminates sloppy mixture of rendering logic and output
- preserves all elements of the current source code
- offers a controller for more cleanly determining which elements of the page get displayed
- distinctly identifies each element of the resulting layout
- provides a simple prototype for a templating model
- makes it easier to change major layout elements for web designers
- my tests of it thus far have been successful
**The Source**
%%(php)
<?php
/**
* Display a page if the user has read access or is an admin.
*
* This is the default page handler used by Wikka when no other handler is specified.
* Depending on user privileges, it displays the page body or an error message. It also
* displays footer comments and a form to post comments, depending on ACL and general
* config settings.
*
* @package Handlers
* @subpackage Page
* @version $Id$
* @license http://www.gnu.org/copyleft/gpl.html GNU General Public License
* @filesource
*
* @uses Wakka::Format()
* @uses Wakka::FormClose()
* @uses Wakka::FormOpen()
* @uses Wakka::GetConfigValue()
* @uses Wakka::GetPageTag()
* @uses Wakka::GetUser()
* @uses Wakka::GetUserName()
* @uses Wakka::HasAccess()
* @uses Wakka::Href()
* @uses Wakka::htmlspecialchars_ent()
* @uses Wakka::LoadComments()
* @uses Wakka::LoadPage()
* @uses Wakka::LoadUser()
* @uses Wakka::UserIsOwner()
* @uses Config::$anony_delete_own_comments
* @uses Config::$hide_comments
*
* @todo move <div> to template;
* @todo replace $_REQUEST with either $_GET or $_POST (or both if really
* necessary) - #312
*/