[dokuwiki] Re: dokuwiki comments from a newbie

Jason, Welcome to the Team ;-)

Jason Keltz wrote:
As you know, the default Dokuwiki template does not include an optional sidebar. In order to get a sidebar, you need to go out an install one of the custom user-written templates. sidebars are very common these days. I would love if the default installation included a simple sidebar. If I use the default template on my site, I can be pretty much guaranteed that as new versions of Dokuwiki come out, that the template that I am using for my site is going to work because it will have been tested *with* the dokuwiki version being released. I can't really say that about the custom user-written templates. On the templates page on the DokuWiki site, you can see that some templates are frequently updated, and others have stopped working many versions ago. It would also be nice if there were a few other template choices that came directly with the system.
I like the "default" templates, even if, like you, the first customization I did was the sidebar template with a navigation tree to the left. I'm with Andi in saying it shouldn't be core because there are numerous options now as plugins and non-plugin solutions; no matter what you choose, you simply can't make everyone happy since some will want each of the options. However, once you've done your own template, you realize that adding a sidebare to your site template is pretty simple so not making it core opens your options by reducing overhead from the core and . I've used several implementations of side bars in the several years I've been using Dokuwiki (http://www.puzzlers.org/); I'm now using the IndexMenu plugin to generate that same dynamic HTML navigation. One of my biggest pains in an upgrade is to re-apply my "patches" in the new version. For example, the default sort for the HTML tree is bad in my case because I need folders with names like years (2007, 2006, 2005 ...) sorted to the top in descending order since we always prefer to see the most recent year first. More core means that I need to make more patches to my site's version of the code.
I do like your suggestion about sidebar files, and I think you'll find that most "stock" styled templates include a "hook" for headers and footers; your sidebar can be done the same way with a simple PHP block and some <div> tags. I think it has the advantage of being simple and highly customizable.
The biggest problem for me by far is that there are so many plugins that I want to use to increase the default capabilities of Dokuwiki (and I know I'm not alone here), yet if I use these plugins, each written by a different developer, then each and every time I upgrade my Dokuwiki package, I need to be aware that I need to individually test each plugin that I am using. Plugins which aren't released with the package may/may not work with a new version. If they don't work, the developer may choose to update it, or may choose not to update it leaving me without a plugin. It would be wonderful if Dokuwiki users could vote on the plugins on the site, and if there was enough interest in a particular plugin, it would be great if it could be integrated right into the default install so that it could be tested and released with the package. This would save a lot of time, effort, and trouble. Of course having the capability for everyone to write their own plugins is wonderful, and I'm glad that there are a lot of people writing great extensions to Dokuwiki. 
Jason.
Early on, I found a way to "shim" custom forms into my pages using some "if (file_exists($file)) { @include($file); }" style logic. Simple, fast, and it worked, mostly. It avoided the need to turn on PHP for all users, mostly.
When I discovered plugins, I tried to rewrite ALL my custom forms as plugins with mixed success ... then it occurred to me I was re-inventing the wheel and writing too much "new" code that copied the last plugin. In the end, I wrote one plugin that simply allowed me to reproduce my "shim" method and inject all my old forms in a new way. Now, I only write plugins if I can't do something reasonably straight forward with an injectable form. I occasionally write plugins because they are configurable where my forms aren't; Booknav is a good example since you can configure almost the user text, the images, and several layout options. I've learned that plugins have some overhead, and you need to choose when to consume that, and when not to; when you have a hammer, it often seems that every problem can be solved by the application of more nails, and it just isn't so.By the way, that one plugin I wrote is called INCL_FORM and the source is on Andi's Wiki. I have forms that use curl to suck pages in from other websites for me, I have pages that interact with MySQL, and some that execute server side grep on lists of hundreds of thousands of words. Almost all of those are (or were) written as included forms. Generally, I've found the rule to be simple: if I want to configure a form either using an admin page or using data embedded in the page, I'll probably write a plugin. If you need more than one language, a plugin is useful since it has built in support.
But, if I just need to search a DB or a file and all I care about is "what did the user ask for?" then I include the form.
Oh, and I don't think I've had one plugin break between versions. I have customized almost all the plugins on my web site, too. Maybe that is just good luck. 

Kite



--
DokuWiki mailing list - more info at
http://wiki.splitbrain.org/wiki:mailinglist

Other related posts: