This is an example of a Wiki. Wikis represent a slightly more exotic form of web development. The software being used for this Wiki is DokuWiki. I read about a number of different Wikis, and, Dokuwiki had a lot of smart people saying good things about it. I'm reading the documentation about start.txt. I'm going to be making a lot of notes and bookmarks in this Wiki concerning how to manage a DokuWiki application. Just like anything, there are a lot of nuances to the Wiki niche, and, there are a number of thoughts on what constitutes good wiki style. And, others have recorded plenty of wiki tips.

This wiki will be focused upon wiki development. This will facilitate a functional bit of practice and research about how this software works. While DokuWiki's own documentation is really quite good and comprehensive; this Wiki has a different advantage as you can read right along with me as I learn and figure out the software. I experience a lot of things that you probably would if you just started from scratch with the software. So, I think this Wiki does offer a unique and useful purpose.

Here is a pretty comprehensive list of other wiki software with reviews. Here is another.

This wiki is being developed by the Harrisburg web development firm WebGlad.

You know how you display code without rendering it? You just indent it two spaces. Doh!
//Italic Text// ===== Level 2 Headline ===== [[http://example.com|External Link]]

After playing around with this for a few days, I have one great way to set permissions. Here's what you do:

• For the site root (*), you allow “ALL” to read. This ensures that unregistered people aren't going to vandalize the Wiki.

• For the site root (*), you allow all “USERS” permissions up to and including uploading; but, not deleting! So, they can read, edit, create, and upload.

• For the Playground, set the permissions so “ALL” can do anything including delete. No harm can be done to your Wiki. These permissions are isolated.

• Determine the name of your home page, and then set the permissions for “ALL” to only allow reading. This ensures that the admin maintains ultimate control over the very front page of the site.

• Then, you can set permissions for particular namespaces as the unique situations of your Wiki calls for. And/or unique permissions for particular users.

• It does appear that permissions set on any individual page over ride any other permissions with the exception of the admin's. This is important to know because I'd like to set the very home page to READ ONLY for everybody but the admin while allowing users to edit other pages.

I noticed that the permission statements above the ACL rules didn't match; however, I tested and all the ACL rules performed exactly as they should. I figured this must be a bug, and I asked. Turns out it is a minor bug. As long as the rules function correctly, I'm not concerned that the permission statements have a bug. It has no consequence on functionality. It wouldn't stop me from using the software.

The section above about a great way to set permissions still applies.

After working with this software for a few days, it now dawns on me that the wikitext for tables could prove useful in some limited circumstances. Tables, of course, were abused by many in html (pre-CSS and still today); and, their purpose of organizing data became secondary to being used as a layout tool. I could picture using one on the home page to organize perhaps a list of posts of particular interest or popularity…and, maybe an rss feed. Here is the table syntax

Let's experiment a bit with tables right here:

And, let's try this:

And, this:

I see that the content sets the width: not blank space.

The syntax for this software is interesting. Wiki markup is known as Wikitext.

Here is the DokuWiki Manual.

With a bit of retrospect, I see that when writing it's a good idea to keep in mind the pages that you've written so you can hyperlink them as you go along, and this will help a lot with your internal link structure. …just double bracket them as you go along.

One really cool thing is that it's a piece of cake to set-up pretty urls with DokuWiki (just like WordPress.) In the case of DokuWiki, you just go into the Admin panel and select configuration settings. Then, under the “Nice urls” box, select “DokuWiki Internal.”

It also appears that DokuWiki has a wide-range of templates available. Templates are a good thing.

I see they also have a support forum…this is also a very good thing.

Here's the DokuWiki security info…and permissions

Now, it's Nov. 28, 2008. I posted a bit about wikis the other day on the blog. In this test Wiki, I will be copying and pasting text from Wikipedia to serve as dummy text. This is being done to test the functionality of the DokuWiki software.

It seems I may have broken Wiki rule:

All URL in a wiki should lead to an editable page so that users can freely create/edit/delete the pages. NOTE: Make sure you properly link your newly created page from other pages, when using one of the alternative methods. Otherwise no one may find your page. (Though these pages may still be found by the index feature or through the search engine.)

I was wondering about how one creates pages in a Wiki. I found my answer:

“In DokuWiki pages are created as in every other wiki. Simply create a link from an existing page to a non-existing page, follow this link, and click on Create this page. This is the most common and recommended way. It ensures all your pages are linked together correctly and you don't create orphans anywhere.”

Just delete the content and save the blank page.

So, I am going to create a page about Wikis here on the Webglad Wiki by hyperlinking the previous text that says “wikis.”

You'll see a lot of talk about namespaces in the documentation: it's really mainly a way to use the Wiki syntax to automatically create a directory structure.

This is built-in functionality to prevent multiple users from simultaneously editing the same page.

I slapped a template on here by a fellow named Slaad, and, presto: a new and better look. I like this base compared to the default as it's already structured with a fixed width, and, it's an easier one for me to go in and tweak-up as it's already closer to what I ultimately have in mind.

In the case of this particular template, first thing I did was go into main.php (<div class=“header”>) and hyperlink the title at the top to lead back to the wiki home page. I didn't like how the first navigational link lead to the site index rather than the index page.

Then, I added some links to the static navigation bar that runs across the top of the page by editing the unordered list in main.php.

To get a header image up there rather than text, look for this line in design.css:

/*.header{margin:0; padding:0; height:100px; line-height:100px; background:transparent url(images/NAME.EXTENSION) no-repeat 10px 25px;} .header span{position:relative; left:-9999px;}*/

About Flash Media

DokuWiki can rescale images with two methods. By default it uses PHP's libGD support if installed. Better results can be achieved with the imagemagick command line tool.

When using libGD, resizing can fail when not enough memory is available or the image format is not supported by the installed libGD version.

For resizing external images, they need to be cached at your server. To do that, you have to allow DokuWiki to download external files by increasing the size restriction in the fetchsize option.

To scale an image proportionally, give the wanted width in pixels:

This image is scaled down to a width of 20 pixels.

When you give the width and height, the image will be scaled to exactly that height, ignoring the aspect ratio:

This image is scaled to a width of 20 pixels and a height of 50 pixels.

In the development version of DokuWiki, giving both width and height will crop the image before scaling to avoid distorting the image.

DokuWiki allows you to put images in a page and have them link to a page providing details about the image or to a page that contains the full image. It also allows you to include images that do not link to any other page.

By default, clicking on an image brings up a “detail” page. The detail page is rendered by the detail.php template file. The standard detail.php file shows a larger version of the image along with a listing of EXIF and IPTC metadata contained within the the image (such as caption, author, date taken, etc.), along with other descriptive information.

The following syntax embeds an image in the page at full size, and clicking on this image produces a detail page providing metadata for the image:

Here's another example of adding an image to a page.

It's a good practice to just set width as this ensures aspect ratio is maintained. Basically, just append a question mark ”?” (no quotations) after the file type followed by the desired pixel width dimensions… so, example: picture.jpg?200

This is useful as you can have the smaller image in the post and on click open a page with a bigger version of the image with metadata. I have this set-up right now to take advantage of PHP's libGD support. I understand that imagemagick does a nice job of this as well. And, I think there might even be a Lightbox hack for DokuWiki; I'll look into that later because I LOVE Lightbox.

After the ”?” add “no link” (no quotation marks)

That's what I'm going to figure out now. Ah, very clever! It works by using left or right whitespaces! I am impressed with how clever this is.

(this also reminds me of something that I've been forgetting to do because in normal web and blog design I don't have much need for it generally…but, of course, you can also link out to those long manual pages using named anchor to cut right to the middle of the document etc.)

Access control lists are of fundamental importance as they control who can edit and delete pages from your wiki.

I see that namespaces are also of funamental importance in Wiki development. They basically are an organizational tool that allow for a directory (folder) structure. So, let's say I want to branch this site off into a tangent that discusses (has separate pages for) websites that have been developed using the DokuWiki software. Okay, that's a reasonable, real-world sort of application. So, what I'm going to do is create a namespace called “websites”. I'm going to be doing this right below in a sec.

Okay, there are a number of ways to do this with different levels of complexity. And, ultimately, namespaces, of course, can be nested in namespaces. This makes sense because life and organization tends to get hierarchical.

But, for now, let's create just one “website” namespace that will be within the root-level of the site.

So, the syntax will be website:index betweeen the double brackets on each side … this will create a namespace called “website” and a page called “index” within the “website” namespace. The index page will contain a list of DokuWiki websites and each site in that list will link to a separate page devoted to that particular site.

index

The idea behind a wiki is community collaboration in creating documentation. The DokuWiki software can be configured in several ways through the admin configuration. I believe I have it set right now so that unregistered users can edit the Wiki. This is a test of this. I am currently not logged-in under any type of permission set. This text should be visible to all. It should also be possible for the admin to roll-back the new edit if it's not desirable.

In the Configuration Manager you have the ability to disable these actions:

* Backlinks
* Index
* Recent changes
* Old revisions

• Search
• Subscribe/Unsubscribe
• Namespace Subscribe /Unsubscribe
• Register
• Send new password
• Update Profile
• Edit this page
• View source/Export Raw
• Check

If you're wondering why I'm documenting so much about NameSpaces, it's because they are crucial in understanding how to run this software. They create the directory structure. They facilitate for the creation of complex permissions.

The namespaces are stored in the data folder in the subfolder pages. It's there that you can see that each namespace you create receives its own folder, and, within that folder you will see .txt files of the pages that are created on the root of the page that's the actual namespace.

That sounds a little confusing, but, basically, if you create a namespace called xfiles, and, within on that namespace page link to other characters of the show like mulder, scully, et al …then, within the pages of your data folder you will see a nested folder called “xfiles,” and, within that you'll see the mulder.txt page and the scully .txt page.

For an experiment, let's actally do this… let's create the xfiles namespace: X Files remember when creating a namespace to use a colon and no space between the namespace and anchor text. First comes the name of the namespace and then the anchor text. Force yourself to remember that namespaces get a colon with no separation between the namespace followed by the anchor

And, within that X Files namespace, let's create pages for Fox Mulder, Dana Scully, and Marita Covarrubias. And, as Marita's involvement with the Syndicate is important, off of her page, let's create a namespace for the Syndicate that creates two pages: one for history and one for goals; and maybe upload and try to align some images, and then look at how the directory structure for everything appears.

When you create a namespace within a namespace the url doesn't continue to next the path. That's one thing I was curious about. It just tacks on the new namespace to the base url and disregards the namespace which it's nested within.

Let's say you wanted to use DokuWiki as your own personal CMS, and, you didn't want anyone to be able to alter anything. This, of course, somewhat goes against the Wiki spirit; but, I could picture someone wanting to be able to do this…and, I can already say this software offers certain advantages for somebody with that aim that wouldn't be available in, say, WordPress or another CMS.

So, how to do that?

Go to Configuration Manager > Authentication Settings > Disable DokuWiki Actions > and tick the check box that says “Edit This Page.”

Another, and, I think better way to handle this is to the Admin Panel > Access Control List Management > at the bottom you'll see it says Current ACL Rules … what you want to do is look at Page | NameSpace … the icon that looks like a box with a star next to it indicates everything, and if you set that to Read, the user won't be able to edit anything…now, the way the permissions work is that they grant the option checked and all the options to the left of it also

Since I started playing around with DokuWiki, I quickly thought about how I could use it as a blog-like CMS for my new sites. It obviously would function a bit differently than a blog…but, that's okay. I see today that there are a number of plugins to facilitate blog functionality and even a DokuWiki Blogsuite Bundle. Very cool: will have to look into this.

If my FF extension is working properly, and, I believe it is…it appears that by default a lot of the internal linking on this Wiki is being nofollowed. This is definitely an issue to understand and resolve. I see all the links to internal pages are highlighted in red. In the admin gui, there is a nofollow box which I unchecked. I was looking around in the code for what's doing this, and, I couldn't find it: will have to ask about this in the forum.

I went into the software's forum and posed a question. It doesn't seem to be an incredibly active forum; but, there is some chatter, and, I'll check back to see what sort of support I get.

Ah, this is very cool.

I don't think I have any real need for the underscored page title that is up at the top of the page (right beneath the Wiki Title and search box. I think I'll remove that.

If you have a page created for the term, then when the term comes up in another page, simply enclose it in the double bracket syntax. So, for example, if I put Dokuwiki Reviews in the double brackets…instant link. Just make sure a page of that name already exists or you'll be creating a blank page.

Read more about plugins.

This one could be very useful.

Let's test it out on this page.

I want to edit the css to give the left and right-aligned videos some padding.

I changed upload_max filesize in php.ini to 1M. So, no image files over 1mb can be uploaded. It was bothering me that people could upload huge images. That could create problems. I write about this issue in a bit more detail here.

RSS is really big these days. RSS and Dokuwiki

Spent a bunch of time figuring this out. You may first want to take a peek at this: RSS and Dokuwiki. That explains how to create pages of RSS feeds in a DokuWiki wiki and also highlights how and why this will be to your advantage. One of the coolest things, to me, is incorporating your blog's feed into the DokuWiki of the same domain. This creates a beautiful, cross-pollinating integration.

Then, it naturally follows you'll want to have an RSS feed from your DokuWiki embedded into your WordPress installation. Right? That's a beautiful thing when you have both applications pointing at each other and updating.

Okay, that can get a tiny bit tricky. First thing you need to do is install a WP Plugin that parses the DokuWiki RSS feed. There seem to be a number of them, and, I found one that works pretty well: RSS Import Plugin by Frank Bueltge.

Okay, you want to download that and install in your plugins directory and activate. This plugin was last updated 8/29/08, and that's a good thing. It doesn't work with sidebar widgets, and that's okay.

This is the syntax that you'll be adding to your WP template. I chose to add it to header.php, because that allows you to create the feed right on the left sidebar of the template I'm using.

Example: <?php RSSImport(10, “http://www.yourblog.com/feed”, false, true); ?>

The 10 can be changed. It indicates how many posts will be added to the feed. I set it to “false, true,” because that adds just the titles of the posts in that manner. In rssimport.php, you can determine how many characters of the titles you want to add. This is a good thing, because by default the wiki titles have underscores so they don't wrap. We could write a little code to strip them, and we'll probably get to that. Anyway, in rssimport.php look for this:

// both 21s were changed from 30 kbf

		if ($truncatetitle && (strlen($title)>21)) {
				$title = substr($title, 0, 21) . " ... ";

That's how you control the number of characters. Then it's just a question of styling the CSS to get the RSS feed looking how you want. I guess that's about it.

For a wiki that's going to be widely accessible, it may not be realistic to expect that everyone can become familiar with and competent with wikitext. I understand that there is a formatting panel and a preview option; but a lot of people have become accustomed to a wysiwyg (what you see is what you get) type of posting interface.

So, I'm releasing making the DokuWiki wysiwyg section.

And, a bit on other wiki applications that feature wysiwyg functionality.