K | Wiki / Wiki

Notes on getting or writing new Wiki software go here.

MiniProjects • ShowPHP • Linoleum ? • OldNotes • Files • BitsOfPHP • AdaptPhed • Version001

2008-02-04: Reconsidering. Again.

(I come back to the idea of writing my own Wiki every time I run up against a limitation in software I'm already using. Today I did a search in PmWiki for a phrase and got back a long list of page titles, with no text to show me the context of the phrase within each page.)

Script folder for each feature.
- Each feature, each page you can go to, is a folder containing an index.php and one or more "plugin" scripts.
- Thus to add features, you add script folders.
- Each plugin script is a component used by a folder's index.php, which has to be written to be able to work with zero OR MORE helper scripts.
- Each page has no idea what other components exists, but each page has a certain number of "stock" variables that it might pass to any page it links to, such as "text" or "name" or "author" etc.
- System does not have to care about what markup is used, how pages are stored or retrieved, or how pages are displayed.
Self-modifying page. To help development, each index.php has a function to load itself into a textarea, let you edit it, and save the text to its own file. (Update: I now have a mod.php script. You just include it, then add a line "//----" below the include line, and put all of the code you want to modify below the "//----" line.)
Locks to prevent simultaneous edits. A file lock isn't really needed until it's time to save changes. (Each previous version of an entry is appended to a history file, so an unauthorized edit can be undone.) A file lock is only necessary to avoid multiple saves from becoming confused (i.e., multiple instances of the Wiki software trying to write to the same file at once).

An alternative, of course, is to write PHP scripts to work directly with the files created and edited with the Wiki's editor -- to edit the pages using PmWiki, but to use a new PHP script to grab the contents of the Wiki files directly, filter out those that don't fit certain criteria, and display the results on the screen.

The function to convert markup into HTML appears to be MarkupToHTML($pagename, $text) in wiki/pmwiki.php. This function does not appear to use $pagename at all, though.

2007-10-27: Get somebody else's wiki

Maybe I should just install someone else's Wiki because I'm getting tired of trying to figure out solutions to the problems I'm foreseeing, such as file locking.

I want a wiki that lets me see multiple articles on a page, based on tags I specify. Is there such an animal? (I'll settle for a way to display the first paragraph or so of each of multiple articles on a single page.) PmWiki, which I'm using now, doesn't do that.

TextPattern

I am seriously considering installing TextPattern (aka TXP) and giving it a try.

2007-08-06: No Wiki markup

The parts of my Wiki software:

The display engine (/w/show.php).
- I'll want to display entries:
  - One at a time (like a Wiki).
  - Many at a time, most recent first (like a blog).
  - Many at a time, in summary form, on a calendar.
  - Many at a time, in summary form (as in search results).
  - One at a time (as a flashcard in a series).
- The main file just grabs one or more entries from storage. The main file loads a "plugin" that decides how to display these entries (and may tell the main file whether to pull entries by name or by date, and whether to pull only the first few lines or the entire text of each entry). This allows me to, in the future, write a plugin that retrieves any sort of custom information from each entry, such as pictures (displayed in thumbnails on a page).
The display template (/w/template.html). The layout of the pieces of the page are stored separately from the programming logic (in show.php). The template contains no PHP -- only special "tags" such as "{CONTENT}" and "{SEARCH}" that tells show.php where to put things, and what things to put in.
The standalone editor (/w/edit.php). The editor has a "list mode" that displays entry names as links; click on one to edit the entry.
- The editor can edit plain text files. This is one advantage of having you enter straight HTML instead of markup. This also opens up the possibility of editing configuration files, e.g., "journal" files that list entry names in a hierarchy (which can be displayed by a "journal" plugin).
The URL fixer (/.htaccess).
- The URL looks like this: karig.net/plugin_name/criteria, e.g., karig.net/page/Entry_name, or karig.net/week/2007-07-30, or karig.net/month/2007-06, etc.

Code will be divided up into as few files as possible. However, code common to show.php and edit.php will go into a single file. Edit.php is separate from show.php so that it can be made inaccessible without affecting access to show.php.

When I was considering Wiki markup

My Wiki software is named Linoleum ?. Its markup is "line-based" -- that is, the first non-whitespace character in each line indicates what the line is: a line in a paragraph, data for a table cell, part of a blockquote, an item in a numbered or bulleted list, and so on. This makes Linoleum's code relatively simple, but it also makes the Wiki markup a bit unconventional.

I am using TigerWiki ? as a starting point for the code, because I admire TigerWiki's simplicity. All of the display, editing, and search code is in a single page ("index.php"), and the page template is in a file ("template.html") that can be edited separately.

DesirableFeatures

I am currently leaning against support for tag indexes. It's simpler for the user to add comments and then search comments for phrases.

I am leaning toward creating "journals" and "calendars" manually. You'd pull up the calendar and add an entry name to a given date and time. You might even be able to do this in the editor, via a utility in the bottom pane. (Dates on a calendar might just be entries, e.g., "2007_08_10". The editor might have a way to save ONE entry, such as a to-do item, as two or more, e.g., what to do, and when to do it, and maybe how urgent the task is.)

Don't forget the main justification for this: The ability to list multiple entries on a single page. (Entries can remain sorted in order by entry name.)