[dokuwiki] Re: dokuwiki comments from a newbie
- From: Kite <kite@xxxxxxxxxxxx>
- To: dokuwiki@xxxxxxxxxxxxx
- Date: Wed, 18 Jul 2007 00:47:46 -0700
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:
