PositionDescriptions /
Webmaster
Documentation
Important Dates
5/25/2008 - Domain expiration date, need to renew before then. updated for 5 years.
PmWiki
What is PmWiki?
PmWiki is the software that runs the backend of the website. It is an open-source, PHP-based wiki that saves data in flat files (instead of a database). The application is set up so you can edit the content of each page through a web-interface. This means the backend is rarely accessed once it is set up. This makes for easy backups and updating. Wiki software uses a special system of notations to indicate formatting. Once you are used to it, it makes updating infinitely more easy that actually coding html.
How is the site organized?
PmWiki has a basic two-tier structure: Groups and Pages. Each of the general categories in the menu system (the top level) has a group with that name. A group's default page is a page of the same name (i.e. Pictures/Pictures). The Group/Page structures is built into the url of each page. For example, this page "Webmasters" is in the group "Officers," so it has the url utsailing.com/Officers/Webmaster. When you don't have subpages (i.e. the Calendar) or have a base page (i.e. Pictures), PmWiki uses the default page for the group (i.e. utsailing.com/Calendar goes to utsailing.com/Calendar/Calendar).
Unfortunately PmWiki only allows two-tiers, so you have to get creative when you have more than that. The only instance where I've needed subpages is in the Officers section. I usually just name the page with the officer position first (i.e. Officer/Social-T-shirts). Also, logically, there might be a page only accessed from another page (i.e. Officers/Webmaster linked from Officers/PositionDescriptions). In this instance the user will think of the linked page as a subpage (i.e. should be Officers/PositionDescriptions/Webmaster). Since this is not possible with the two-tier structure, I usually add a backlink at the top to the logical second tier page (i.e. Officers/PositionDescriptions). I do this by removing the title (with the (:notitle:) tag) and adding in my own second tier link then the title (with this !!PageTitle tag). Just look at the code for this page to see an example. The only exception for the default page is Main/HomePage. MeetingMinutes has its own group.
The Site group is where the templates for PmWiki are stored. They will look funny when not incorporated for their actual use. For instance, there is a template for the format of the editing page. This means you can change around how the editing page looks without going into the backend. I also added Bugs page that is open to anyone so problems can be listed. Beware that this might attract spam (being open to anyone), so subscribe to the RSS feed or check it often or restrict its access.
How does the page load?
There isn't an html file assiciated with each page of the website. PmWiki builds each page each time it is called. It loads the recipes and properties defined in the config.php file and page actions. Then, it finds the appropriate skin and contents for the requested file. Finally, it generates a html page that is sent to the user.
Cookbook/Recipes
These are the plugins that can be added to the basic PmWiki program. Check out PmWiki/Cookbook for more. There are literally hundreds. Listed are the ones currently used for the website.
- Skin Change - enables users to choose a specific skin.
- Email List Form - inserts a simple form that can sign people up for a mailing list.
- GoogleCalendar - embeds a Google Calendar into the page.
- Static JavaScript - adds a custom static javascript function to the page (used for the Weather Channel insert on the front page).
- Google Maps - inserts a Google Map into the page.
- Progress Bar - creates a progress bar to show how much of a task is complete.
- To Do - creates a list of items that can be prioritized and sorted.
- Web Feeds - creates RSS and ATOM feeds for RecentChanges pages.
- Feed Links - adds RSS and ATOM links in header so browsers know web feeds are available.
- Thumblist - creates a gallery of all the pictures in a particular upload directory.
- Site Analyzer - checks the website for vulnerabilities and version numbers (disabled by default, can be enabled in config.php).
- RSS Feed Display - reads an external RSS feed and then displays it on the page (used for text-only version of Google Calendar).
- Include Url - includes external websites in the page (can only be used for SaturdaySails, used for including Google Maps).
- PageTableOfContents - creates a table of contents based on headers in the page.
- Footnotes Extended - creates footnotes for a page.
Skins
In the skins directory (utsailing.com/pub/skins) there are several templates that can be used to build a page. PmWiki follows those templates to build the page. Skins can be changed using the Skin Change recipe. There are five skins installed:
- I Say! - the default classic theme
- Arrgh! - a pirate themed one
- Mobile! - a text-based minimal theme designed for mobile devices
- Print - used when generating a printable page
- PmWiki - came with the installation but is no longer used, although it can be accessed
Menu system
This is an email the webmaster sent to a curious officer:
Date: Thu, 30 Aug 2007 12:57:30 -0500 From: Daniel Roesler <droesler@mail.utexas.edu> To: Parker Dillmann <p_dillmann@mail.utexas.edu> Subject: Re: PMwiki Theme Question
I'm sure this is a whole lot more than you asked for. If you want to look at the
actual templates (I would think it would be easier than reading all of this), go
to the public folder for each skin:
http://utsailing.com/pub/skins/arrgh/ http://utsailing.com/pub/skins/isay/ http://utsailing.com/pub/skins/mobile/ http://utsailing.com/pub/skins/pmwiki/ http://utsailing.com/pub/skins/print/
The old website had a javascript menu system setup. It used images for the links
and a table to line them up. There were three problems with this.
- First, if a user didn't have javascript enabled, he/she didn't get a menu
system AT ALL. Suck for them.
- Second, there were no text links to pages on the site. This is problem for
search engine robots and text-only browsers. Granted, they could look at the
'alt' tag on the image, but that sure doesn't improve your rank with google. It
also takes forever to load, and flickers when you click on something.
- Third, it used tables to align the images. How 1990s. Tables prevent skins from
changing around the layout.
I wanted the new menu system to look exactly like the old one, so I was kind of
restricted in my technique. I wanted an entirely css-based menu, so
non-javascript users wouldn't be a problem. I also wanted to use text links
instead of images. And I wanted to use divisions or a list for the text layout.
I ended up having to use a little javascript.
The way it works:
- There is a top menu div where each choice is div.
- There is a div for each submenu set where each choice in each set is a div.
- All the sets have id's and each choice has an id.
- The styles are controlled through the linked css file. All you see on the html
side is the divs. This makes for easy creation of new skins.
- By default, all of the submenu div sets are visible. At the beginning, the
javascript says which submenus should be hidden (all but the current one). So
if someone doesn't have javascript, the whole menu with all submenus is shown
(try it). It looks ugly, but you don't lose any usibility.
- When a user clicks on a top menu choice (that has a submenu with it), the link
calls a function that hides the current submenu and makes visible the requested
submenu. The function also changes the background of the selected item and
defaults all the others.
- All the content is loaded at the start, it's just hidden, so the browser
doesn't have to load anything for onclicks. I used the javascript link, not the
'onclick' element in links because I would have to use a '#' for the href
element, which would cause the page to scroll to the top. Fuck that, I know
it's not go practice to link to a javascript function, but find something that
prevents a scroll up, bitch.
- I had to do some non-compliant css hacks for the menu to work in IE6, so I
added those css elements in a separate file and hide them from the validator.
Apparently, this is common, and there is even a comment that only IE reads and
everything else skips. Bastards.
- This is the trickiest part: getting all the submenu sets not to display when
the page loads, then suddenly disappear once the page is loaded. That's really
annoying. You have to use a dumb trick for this one. Normally, you just use an
'onload' element in the body tag, but that waits until the whole thing is
loaded, then runs the function. I had to find a way to test whether the user
had javascript before the page was even loaded, and if it was, hide the submenu
before it was displayed. To do this you add a javascript function that
document.writes a frickin' <style> tag set! How lame is that?! All it does is
hide the frickin' submenus! Ass.
Things I wanted but didn't get:
- No javascript. Had to for onclick action. I could have used pure css for hover
actions, but not clicks.
- Wiki-dynamic menu. One of the cool things in wiki's is that you can modify the
menu through the wiki. This is what happens on the mobile skin. There is a wiki
page that has a list, which then gets included into the template. I couldn't
figure out how to make a list work like the old menu, so I had to use
divisions, which prevented me from using a wiki page as a source, since I
needed specific id's and classes (wow, horrible grammar). This sucks because I
have to go in and change each template and javascript everytime there is a
change in menu setup. I wish I could find a way to implement it into a wiki
page.
- Black hover for the orange bar area above a current selection. This was the
only part I was not able to mimic from the old menu system. When the mouse
hovers over a top menu system the background turned black, except for the
orange bar. When the mouse hovered over the current top-menu choice (the
current page category), it would turn the orange bar area AND the top menu
choice black. Right now, it only turns the choice black and the orange bar area
remains blue (since it's selected, the orange bar has disappeared). This would
be easy to do by just loading an image background, but then the browser would
flicker as it called for the image and loaded it. Flicker and post-load loading
= not cool. The only other way was to use 'onmousein' and 'onmouseout' elements,
which was more trouble than it's worth.
- IE hover on submenu sets. For some reason, IE6 doesn't expand the hover bgcolor
change in the submenu choices. It looks like just the text changes background,
not the text-area defined. Stupid IE. If only IE read hover css on non-anchor
tags.
- Dumbass mobile phone browsers. I originally planned not to have a mobile phone
skin. I assumed that the javascript wouldn't work on mobile phone browsers, and
the menu system would expand like always. But it turns out that mobile phones
have partial support for javascript, so only the top menu gets displayed, but
no submenus are underneath (probably from the document.write business), and
nothing is clickable. Lame. So created a mobile skin without any javascript or
css. Dumbass browsers. I should just set it up to automatically serve mobile
content to the phones (I haven't looked into that much yet).
Anyway, look at the actual code. I would think it makes a lot more sense than my
email. I really need to go back and add comments in the code, though. If there
is anything confusing about any of this (I would bet there is), let me know and
I'll try to clear it up. It took me just as long to do the menu system as it did
to do the rest of the site, and it still isn't perfect. It works, I'm taking a
break.
Avast! Daniel Roesler droesler@mail.utexas.edu (512)769-1164
Quoting Parker Dillmann <p_dillmann@mail.utexas.edu>:
> Hey Daniel, was looking at the PM wiki stuff and I am wondering how did > you get the menu icons at the top to go into sub menu icons? Also what > theme (if any) did you base the UTSC website on? > > Thanks, > Parker >
|
Attributes
Groups and pages are locked by default (including reading). Therefore, the admin has to set the passwords for each group or page to allow reading/editing/etc. Otherwise, only the admin's password will work to read/edit/etc. the page.
This is a list of passwords assigned to pages. GroupAttributes assign those passwords to that group. @nopass means that there is not password required for that function (i.e. anyone can read/edit/etc.). To change a password for a page go to that page's url and add a ?action=attr to the end (i.e. http://utsailing.com/Site/Passwords?action=attr). Then, put in the Admin password (unless you have a attr password set for that page). You will see a list of boxes that show what passwords are set and what are not. If you want to set passwords for a group, go to the GroupAttributes page for that group (if it doesn't exist, just create it and leave it blank) in the same way as any other page (i.e. http://utsailing.com/Officers/GroupAttributes?action=attr). More on PmWiki passwords.
The Passwords page of this website contains a list of all the passwords used by utsailing club (including a list of which page gets what attribute). It needs to be maintained and kept up to date.
Attachments
Attachments are saved in the utsailing.com/uploads folder. They are saved in the folder of their group and page (i.e. foo.pdf file attached to GeneralInfo/Paperwork will be saved as utsailing.com/uploads/GeneralInfo/Paperwork/foo.pdf). The config.php file defines the size limits on uploads. Since files can be uploaded only one at a time, pictures for the gallery will often be uploaded via ftp. Instructions? for that are well documented and need to be maintained. PmWiki/Uploads contains more documentation.
Gallery
This is an email the webmaster sent to a curious officer:
Date: Tue, 11 Sep 2007 14:53:44 -0500 From: Daniel Roesler <droesler@mail.utexas.edu> To: Parker Dillmann <p_dillmann@mail.utexas.edu> Subject: Re: another question about the website
First, I use a recipe called ThumbList, not PictureGallery (I go under the
handle 'diafygi', so I'm not the Daniel in PictureGallery). It allows you to
create a simple list of thumbnails of the attached files. Also, I configured
uploads to create a folder for each page, not each group. So every gallery has
it's own folder. ThumbList is postcardware, so you have to send a postcard to
the creator when you use it (I sent one with actual longhorns, so don't send
that one).
Here is the link to ThumbList: http://www.pmwiki.org/wiki/Cookbook/ThumbList
I also use Thumblist for the main Pictures page, but using a different technic.
Basically, for each semester I have a pagelist that looks for pages that begin
with that semester's name and year (i.e. Fall2007). The list uses ThumbList to
takes a thumbnail of a random picture from each listed folder and outputs it.
So there is a different pagelist for every sememster following the same basic
template. All of the galleries follow the same basic naming format
<semester><year>-<event>-<date> (i.e. Fall2007-SaturdaySail-09-01-07). The
biggest problem I had was the number of pictures in the gallery. I actually had
to write a function that would count them. I also had to create a variable for
to display the truncated name of each gallery (i.e. Saturday Sail-09-01-07).
The pagelists are also supercached, so the gallery and main page need to be
'purgethumbnails'ed when I change something in a gallery. It goes really slow
if I don't supercache.
Here is the code I used for the pagelist in Site.LocalTemplates. I hid it with
the condition 'if false' so it would only be called from some other page, not
LocalTemplates.
(:if false:)
[[#gallerylist]]
(:template defaults order=name group=Pictures
name=-Pictures,-GroupAttributes,-RecentChanges,-ImageTemplate:)
(:template first:)
(:template each:)
|| width=auto style="display:inline;"
|| [[{=$FullName}|(:thumblist "Pictures.{=$Name}" limit=1 shuffle=1 link=-1
supercache=1:)]] ||
|| '''[[{=$FullName}|{=$Nametruncated}]]'''[[<<]]({=$NumUploads}) ||
(:template last:)
[[#gallerylistend]]
(:ifend:)
Here is a list of example pagelists: http://www.pmwiki.org/wiki/Cookbook/PagelistTemplateSamples
When you click on a picture in a gallery, ThumbList generates a page based on a
template in the Pictures group. I customized it to be the way it is. Currently,
the pictures don't maximize into a new window, just the current one. I might
change that later. You can look at all of the code for the Pictures group by
logging in with the password '****'. There is also a handy tutorial for the
maintainer of the pictures section.
Here is the template ThumbList uses for each individual picture:
http://utsailing.com/Pictures/ImageTemplate
Here is the tutorial for how to add galleries. If you see anything that is
unclear or I need to add, please let me know.
http://utsailing.com/Pictures/HowTo
Avast! Daniel Roesler droesler@mail.utexas.edu (512)769-1164
|
Site Map
The site map is just a searchs for all viewable pages. The "list=all" search will return all pages that can be read. If the searcher doesn't have permission to view a page, it won't be displayed.
XHTML and CSS
This website should always be XHTML 1.0 Transitional and CSS compliant. There are links for the W3C validator at the bottom of each page. PmWiki should be compliant, but some of the recipes used are not, so they were modified to make them compliant. The webmaster needs to check to make sure all of the recipes they put onto the site keep it in compliance.
Upgrading
Upgrading PmWiki should be a relatively straightforward process. All the webmaster needs to do is download the new version of PmWiki, copy over the new directories (after backing up the current version) and pmwiki.php, and that's it (I usually delete the new docs folder and README.txt). At bottom of this page, the version used will be displayed. You need to read the changelog to make sure that any incompatibilities can be fixed.
You can easily upgrade recipes by simply replacing the file in the cookbook. However, be sure to look at their changelogs to make sure any incompatibilities can be worked out. The Site Analysis recipe can be useful in determining which version of which recipe you have.
Moving
The beauty of PmWiki is that it stores all content in a flate file structure, which means that there is no database to maintain. So, moving the website is fairly easy. The only thing that needs to be changed is the config.php file (you will see what to chage in the comments, only a few things). Everything else is drag and drop. This site requires several things:
- PHP 4 or 5
- PHP mailing enabled
- Outgoing http requests enabled
- Apache .htaccess file recognition
Backups
All that needs to be done to back up the entire website is to copy the entire directory to your backup location (usually via ftp). Also, since this is a wiki, you rarely need to change the actual backend of the website (unless adding a recipe or config.php file modification). If you haven't made any changes to the backend, then all you need to backup is the wiki.d and uploads directory (if you've attached anything new). The wiki.d directory contains all the page contents. The only thing that doesn't get backed up when copying the file tree is the file permissions. So a list of file permissions is maintained here:
- wiki.d folder has chmod 777
- uploads folder has chmod 777
- all folders and subfolders inside uploads folder has chmod 777
Webserver Admin
Changelog
The UTSC_Changelog.txt is located in the local/ folder of PmWiki's backend. It is one fo the most important files on the whole server. It contains a step-by-step description of the current website's entire setup. Theoretically, one should be able to reconstruct the entire backend of the website with this one file. It needs to be updated EVERY TIME the backend is changed (i.e. every time you change something that isn't in wiki.d/ or uploads/). The first few paragraphs of the file tell how the file is to be maintained. The reason this file needs to be maintained is because of the high turnover rate of Webmasters. Since a new webmaster comes in every year or so, they need to have a running history of the changes made to the website. Wiki.d/ contains a history of the content for each page, but UTSC_Changelog.txt is the only history for the backend (and it has to be updated manually). SO KEEP IT UP TO DATE!!!
Cpanel
Cpanel is the adminstrative utility for the webserver. It contains statistics on vistor usage, password administration, etc. You can access it at http://utsailing.com/cpanel. This application is provided by the server host (CentexITS) and is quite useful.
CentexITS
An alumni of the club, Andrew Chasteen, runs a local Internet hosting service. He has generously donated some of his server space for our use. If there is ever a problem with the server, he will let us know. His email is webmaster SQUIGLY THING centexits PERIOD com or andrew PERIOD chasteen SQUIGLY THING gmail PERIOD com. Be sure to thank him for the free space every time you contact him.
GoDaddy
GoDaddy.com is the registrar for the domain utsailing.com. It is set to expire 5/25/2008, so the club will have to scrounge up some money to renew it. Through GoDaddy's account management, you can setup the DNS servers and domain information. The login info is on this website's Passwords page.
GoogleApps
We use Google apps to manage the officers emails and the calendar. We also use Google Docs for some documents and spreadsheets. I sent out emails about each one to the officers so they could understand how it works. I've included those emails below. To manage Google Apps, see the Passwords page.
Email
Date: Tue, 12 Jun 2007 18:35:52 -0500 From: Daniel Roesler <droesler@mail.utexas.edu> To: utsc-officers@utlists.utexas.edu Subject: How Your Officer Email Works
Ahoy,
So you've notice that you're getting email addressed to <your_officer_position>@utsailing.com? Well, that's because the website has contact emails for all the officers, and I'm going to tell you how it works so you can customize it to your liking.
In the spirit of google ( http://tinyurl.com/yszact ), google catches every email sent to utsailing.com. Every officer has a google gmail set up for there email. Currently, they are all set to just archive and forward the emails on to your respective email addresses. You can also log into your gmail account directly. Here's how:
1. go to http://partnerpage.google.com/utsailing.com 2. click "Email" 3. type in your officer user name (i.e. "social" for social@utsailing.com) 4. type in your password (I'll send individually tonight) and click "Sign In" THIS IS YOUR EMAIL ACCOUNT :) 5. You can send emails directly from your *officer*@utsailing.com account here. 6. You can also change your forwarding settings by clicking on "Settings" at the top right. Then, select "Forwarding and POP" and change whatever setting you want.
If you are fine with the way your email works right now, don't worry about a thing. If you have any questions or changed something and now don't know how to fix it, please don't hesitate to ask. Technology is supposed to help, not be a pain in the ass.
Avast! Daniel Roesler droesler@mail.utexas.edu (512)769-1164
|
Calendar
Date: Tue, 12 Jun 2007 18:04:00 -0500 From: Daniel Roesler <droesler@mail.utexas.edu> To: utsc-officers@utlists.utexas.edu Subject: How To Edit The Website Calendar
Ahoy!
If you've ever been to the website, you'll notice that we use Google Calendar to schedule events (http://utsailing.com/Calendar). I'm usually the one to update it, which is fine. If you want something added, I'll be glad to add it for you. If you would like to add it yourself, that's fine too. Here's how you do it:
1. go to http://partnerpage.google.com/utsailing.com 2. click "Calendar" 3. enter your officer email username (i.e. "social" for social@utsailing.com) 4. enter your password (I'll email this to you individually tonight) THIS BRINGS YOU TO THE CALENDAR :) 5. you can use the "Month" tab at the top to find the day you want 6. click on the day you want to add an event 7. type in the name of the event 8. *IMPORTANT* for 'Which Calendar': choose "UT Sailing Club" (otherwise, it won't be visible on the website, and you just added an event to your user's calendar) 9. click "Create Event" 10. click the event you just created and select "edit event details" 11. include all the information you want about the event (try to put exact times and locations) and click "Save" YOUR DONE! Go to http://utsailing.com/Calendar to view your event!
If you have any questions about this, please don't hesitate to ask. Technology is supposed to help, not be a pain in the ass.
Avast! Daniel Roesler droesler@mail.utexas.edu (512)769-1164
|
Docs
Date: Tue, 11 Sep 2007 19:37:03 -0500 From: Daniel Roesler <droesler@mail.utexas.edu> To: utsc-officers@utlists.utexas.edu Subject: Google Spreadsheets on website!
Ahoy!
So I just added Google Docs and Spreadsheets to the website. I've already created a Budget and Roster spreadsheet. It will be up to their respective officers to actually add content to them. Here's how they work:
To create a NEW document or spreadsheet: 1. Go to http://docs.google.com/a/utsailing.com 2. Log in with your username (i.e. webmaster, social, etc.) and password 3. You are now logged into Google. Here you can create new spreadsheets. Note: Only YOU will be able to see the document or spreadsheet by default. If you want other officers to be able to see/edit it, see the instructions below.
To share a document or spreadsheet with the other officers: 1. Open the document you want to share. 2. Click on the share tab in the top right. 3. Uncheck all the boxes (click 'OK' when it warns you). 4. Check the box that says 'Anyone at utsailing.com can view/edit...' 5. Choose whether you want others to be able to view or edit it. 6. An internet address will appear below the checkbox. This is the direct address for your spreadsheet! 7. Copy the address and send it to the officer list. If you want to add it to your officer page on the website, let the webmaster know. 8. Only officers with logins will be able to sign in to view/edit this document or spreadsheet. If you want everyone in the world to be able see it, let the webmaster know.
To view/edit someone else's document or spreadsheet: 1. You should have a link or address of the document. 2. Log in using your username (i.e. webmaster, social, etc.) and password 3. View or edit the document or spreadsheet 4. 'Save and close' if you edit the document or spreadsheet
Here are the links to the officer page with the link to the Budget spreadsheet:
http://utsailing.com/Officers/Treasurer
Here are the links to the officer page with the link to the Roster spreadsheet:
http://utsailing.com/Officers/Secretary
I'm not in charge of either of these, so have fun. Please let me know if you have any questions or want to add/change a document or spreadsheet.
Avast! Daniel Roesler droesler@mail.utexas.edu (512)769-1164
|
Mailing List
Our mailing list is provided by UT. To access the list, go to http://utlists.utexas.edu/ and login. If you haven't been there before, you can create an account. I just used my utexas.edu email and password. There are currently three email lists that belong to the club: utsc, utsc-officers, and utsc-alumni. utsc-alumni hasn't really been used, but it's there if the need should arise. utsc-officers is used for the officers discussion. Previous officers can still be subscribed to it, but only current officers can send emails. If a previous officer wants to email the officers list, he/she can ask a current officer to forward the email to utsc-officers. utsc is the general club list. All members are subscribed to this list, and it is open to the public. It is mainly used for announcements.
Here are the email addresses:
utsc@utlists.utexas.edu
utsc-officers@utlists.utexas.edu
utsc-alumni@utlists.utexas.edu
Owners
The owners of the list have two tiers: Normal and Privileged. Normal owners can edit the subscriber list and most other admin functions. Privileged owners can edit the normal owners list. The officers of the club are generally listed as normal owners and the webmaster and commodore are listed as privileged. utsc and utsc-officers are setup so that only owners can send out emails. To change the list of owners, go to http://utlists.utexas.edu/, login, and then navigate to YourList -> Admin -> Edit List Config -> List Definition.
Subscribing
There are three ways to subscribe to the mailing list. First, the web form on this website will generate an email that is then sent to UT's server, signing you up for the list. Second, you can send this email directy to the server (sympa@utlists.utexas.edu) with the body of text as subscribe utsc Joe Smith. Third, you can go to http://utlists.utexas.edu/ and register (if you haven't already) and sign up for the list there.
To unsubscribe, you can use any of the three ways. For the direct email way, just send an email to the server (sympa@utlists.utexas.edu) with the body of text as unsubscribe utsc.
Important Graphics
isay skin banner (GIMP file)
isay skin logo (Inkscape file)
3d waving pirate flag (Blender file)
A-frame back design (Inkscape file)
arrgh skin banner (GIMP file)
arrgh skin logo (GIMP file)
pirate fonts example (png file)
Current PmWiki Version
PmWiki Version: pmwiki-2.2.0-beta65