FailureStories

I think there is a good failure story in the PmWiki Users Digest. Pmwiki-users digest, Vol 1 #94 - 4 msgs:

• PmWikiUsers:2003-April/000367.html
• PmWikiUsers:2003-April/000368.html
• PmWikiUsers:2003-April/000369.html
• PmWikiUsers:2003-April/000370.html

Ah, yes, this is a bit of a failure. Of course, as far as I know no wiki system can run on a web hosting service that doesn't allow scripts (see the above). And while other wiki systems may have security problems, PmWiki has been carefully designed with security in mind - I'm a server administrator myself! --Pm

I will add an additional comment, but since it is almost two years since the first post, it will be for other peoples benefit. We are negotiating with our ISP on how to set up a Wiki. Our situation is different from the one you describe, we have PHP scripting, but we do not have write permissions to save the files. Our plan will be to use this for internal communications and documentation for the organization, and we will be setting up Basic Authentication on the site to keep the public out. This might overcome the objections of an ISP who has security concerns. If not, you should probably move to a Wiki that uses a database to store information.

I failed getting PmWiki started when I first tried, but now I got one Step further. Hope it ends up in SuccessStories. See InstallationWorkbench? for Details. --Mike

The only failure stories i can think of, are not really failures, just stuff that is sometimes made difficult. I have found that the server is very important when using PmWiki. Some servers don't give you access to hidden files, and sometimes you can't see the files in the wiki.d directory even though they are there. I had some minor issues in transferring a PmWiki site over to a new server. Main thing is have good WikiServerSpecs?, then everything is fine and dandy. Shell Access is important, and makes things easier also.

PmWikiFriendlyHosting

I use PmWiki locally on my machine for note taking, so it seemed like a good idea to adapt it for a web project. For various reasons, I just wanted the render engine, and to handle the whole CMS thing myself.

Picking out the rendering, and adapting it proved to be harder than it first looked. Text_Wiki (http://wiki.ciaweb.net/yawiki/index.php?area=Text_Wiki&page=HomePage) proved to be a better fit for what I was doing.

This is not really a failure just maybe my inability to code php. I have been trying to make a style switcher using php. I changed the pmwiki.php file and added a form to the pmwiki.tmpl. so I got the homepage to be able to change styles but I don't really know how to keep the variable that to stay in the address bar for the other pages and to actually keep the style changed. any help would be appreciated. enejlander@hotmail.com Otherwise I think pmwiki is awesome and thanks for the creating it.

After an initial enrapture with PmWiki, me and several others in my vicinity have started migrating to other wikis.
Most notable reasons:

• Small audience -> few plugins.
• Plugin architecture not mature enough -> plugins tend to break.
• Plugin architecture not mature enough -> writing your own can be hard.
• Lack of contract documentation on plugin APIs -> plugin writers don't know what properties of the interface they can rely on for future revisions of PmWiki -> plugins tend to break as soon as the API changes, because their and Patrick's assumptions about what's stable and what isn't differ.
• Lack of easy import/export.
• Lack of WYSIWYG editing (important for non-techies).
• Patrick likes to keep the development focused, but that means the development process does not allow for serious help from others, slowing down PmWiki development.

PmWiki does have some nice A-has, but it won't ever get into widespread use and stay a niche - good enough for tech-savvy people who don't mind dirtying their fingers with occasional PHP, but not inviting enough to the real PHP wizards, and too tech for the non-techies out there. That's a narrow niche.

I am quite surprised by the "plug-ins tend to break" part. We have a policy that a PmWiki upgrade should not break existing 2.x installations (unless people modify core files) and we are always ready to help admins and authors of plug-ins if that happens: either revert the core changes, set some config variable, or apply some fix on the plug-in. --Petko? April 12, 2011, at 09:07 AM

I run 30+ PmWiki installations, a variety of plug-ins (some my own, many others...) and have NEVER had a plug-in break on a client's website or one of my own. And when I upgrade, I usually roll out to all the websites at once. I don't think there's too few plug-ins. I've loved how pluggable PmWiki is. After years of trying to customize other PHP packages in some cases to having to overwrite core files, PmWiki has the most elegant and easy plug-in/plug-in writing system I've seen. I'd love wysiwyg, but ONLY for my clients. Frankly, I love and prefer the wiki code interface, and again I have many clients who use & update their own websites. And if anyone wants to, they can send people to the videos I've made on using PmWiki (at http://websitevideohelp.net). I'm still using PmWiki for myself and clients, even after 9 years. XES? April 06, 2012, at 09:16 PM

Back to Success Stories.