Home
| Calendar
| Mail Lists
| List Archives
| Desktop SIG
| Hardware Hacking SIG
Wiki | Flickr | PicasaWeb | Video | Maps & Directions | Installfests | Keysignings Linux Cafe | Meeting Notes | Linux Links | Bling | About BLU |
Some additional information about MediaWiki... On Sun, Aug 28, 2011 at 4:11 PM, David Kramer <david at thekramers.net> wrote: > On 08/28/2011 12:31 PM, Tom Metro wrote: > > Kyle Leslie wrote: > >> Any suggestions on a set up. I have seen some things about TikiWiki and > >> MediaWiki. > > > > My vote is for Twiki (http://twiki.org/). > > I used to have a TWiki instance on my server for a long time, but I > ditched it because there were an incredible number of security problems. > They were pretty good about fixing them, but one exploit hit my server > and I lost a lot of work. This was a long time ago, so I don't know if > it's still true, but I personally would never use it again. > > I have long ago switched to PMWiki (http://www.pmwiki.org), which I find > easier to use, easier to work with as an administrator (it's written in > PHP instead of Perl), and has an extensive collection of plugins. I use > it on many projects. > > > MediaWiki obviously has the advantage that almost everyone is familiar > > with it due to Wikipedia, but I find that the markup syntax is > > inconsistent enough that I still refer to the documentation, despite > > perhaps a decade of semi-regular document authoring in MediaWiki. > > > > Can you even get a WYSIWYG editor for MediaWiki? > > That's what I don't get about MediaWiki. It doesn't have WYSIWYG built > in, the markup is well documented, but a bit awkward, especially for > tables, which I use a lot, but it's got this reputation for being the > best. You can add a WYSIWYG plugin though: > http://smwforum.ontoprise.com/smwforum/index.php/WYSIWYG_extension > > That's a nice plugin which I didn't know about. There has been a lot of work at various WYSIWYG implementations for mediawiki, as the http://www.mediawiki.org/wiki/WYSIWYG_editor page points out. That page does not mention the one I've used for a long time called wikEd which is a pseudo WYSIWYG editor: http://en.wikipedia.org/wiki/User:Cacycle/wikEd_help > > It doesn't seem to > > provide much of a framework for setting up a document hierarchy with > > standard navigation controls to move up/down the hierarchy. (Maybe with > > a plugin?) Instead you get a breadcrumb trail that reflects whatever > > random path you took to the current document, with no real indication > > where the document fits in or how to navigate to siblings or parents. > > I don't fault MediaWiki for that, because what you're looking for works > counter to Wiki philosophy. To state that there is a fixed breadcrumb > trail to a given page is to state that there is only one (or one > "official" way to get to that page. Wikis are about crosslinking from > multiple places, and that's what gives them power over a simple document > repository. > I tag my wiki articles into categories using natural language nouns, verbs and phrases, and use a category cloud on the home page to expose the contents of the wiki. > > Your particular usage may lend itself to breadcrumb trails, and you can > probably create them yourself, but I wouldn't expect that to be > automatic (though it is in Confluence, which we use at work, and the > breadcrumbs often get "confused" because there isn't just one path to > most documents). > > For instance, in PMWiki, pages can be divided into groups, and you can > define many things at the group level, including the header and footer. > So for my Agile New England (http://www.agilenewengland.org) project, > the PMWiki instance we use to coordinate volunteers has a separate > WikiGroup for each team, and each team's WikiGroup has a defined header > with links back to the main project page and the team's page. We also > define authorization at the group level. > > For hosting wikis with multiple groups, one approach is to create a wiki "farm" (or family of wikis) from a single codebase, but with separate configurations and thus you can separate out the access controls. http://en.wikipedia.org/wiki/Wiki_farm > ... > > > Like Dan said, wikis need maintenance, and a wiki that lets you automate > > some of that helps. > > Another feature I like about PMWiki is that page content is stored in > text files on the hard drive rather than in the database. That means I > can do many administrative tasks (eg global search and replace of a > person's email address, finding all pages that have text matching a > regular expression, etc) very easily, and backups get compressed down > very small. > One directory in the source of MediaWiki is the 'maintenance' scripts directory. Lots of interesting goodies in there. http://www.mediawiki.org/wiki/Manual:Maintenance_scripts (In addition to regular database backups,) I use http://www.mediawiki.org/wiki/Manual:DumpBackup.php to create a text backup of the current wiki contents every hour which serves as a text-based version which can be grepped easily if the server itself is down.
BLU is a member of BostonUserGroups | |
We also thank MIT for the use of their facilities. |