Issues labeled “Doku Plugin idea”

display section numbers in the page and table of contents

KamarajuKusumanchi — Wed, 08 Sep 2021 15:20:11 GMT

It would nice if dokuwiki can display section numbers in the page as well as in table of contents.

For example, with a markup like

===== Overview =====
foo
===== Introduction =====
bar
==== Outlook ====
baz
==== Size ====
qux

We currently get a page that looks as below: /* The top part is the table of contents and the bottom part is the actual page */

  Table of Contents
  * Overview
  * Introduction
    * Outlook
    * Size

Overview
foo

Introduction
bar

Outlook
baz

Size
qux

Desired behaviour:

  Table of Contents
  1. Overview
  2. Introduction
    2.1 Outlook
    2.2 Size

1. Overview
foo

2. Introduction
bar

2.1 Outlook
baz

2.2 Size
qux

Note that in the example above, I am requesting for section numbers to be displayed in both table of contents and in the actual page. From an implementation point of view, you can have multiple options to control this. For example, let's say you have two options - section_numbering_in_contents, section_numbering_in_toc and then the user can turn it on or off depending on their preference.

Feature Request: Having possibility to show unused Syntax plugins

fstorck — Fri, 05 Jun 2020 07:38:06 GMT

It would be helpful to have a kind of automatic scan to identify unused syntax plugins or to check whether a specific syntax plugin is used still on certain pages in case it is outdated etc. A workaround could be the usage of Batchedit, but this is rather comfortable. Kind of button in the plugin list would be very handy.

Integrate MediaManager (lite) into Pageditor

igittigitt — Tue, 15 May 2018 14:41:17 GMT

Working with many images is a pain in Dokuwiki. Always popup the Mediamanager, scroll to the wanted image, place one and doing it again and again takes too much time and makes no fun.

I would prefer to see images of current namespace in the pageditor as a sidebar. So easy scrolling without loosing page context, drag and drop to page (even with multiple images) can be done.

Provide oEmbed tags/endpoint

chrisblech — Sat, 12 Nov 2016 15:13:21 GMT

Social platforms, CMS, and discussion boards are more and more automatically generating a "Preview-box" (or "Onebox") when a user shares a Hyperlink.

"oEmbed is a format for allowing an embedded representation of a URL on third party sites. The simple API allows a website to display embedded content (such as photos or videos) when a user posts a link to that resource, without having to parse the resource directly." (quoted from http://oembed.com)

When I paste a link to my DokuWiki, my discussion board doesn't find any oEmbed Infos, and therefore it shows only the naked URL, instead of a nice preview of the DokuWiki Article.

Is it possible to include oEmbed Provider functionality to DokuWiki (similar to RSS)?

add a header <link rel="alternate" type="application/json+oembed" ... > to every page
provide a JSON Output with title, first paragraph, and a picture of the requested wiki page

Spam protection measures

Traumflug — Fri, 04 Dec 2015 18:46:25 GMT

Let's face it: DokuWiki comes with close to zero spam protection measures. Spammers get in only hours after an installation and then new users flood in, one every 3 minutes.

So let me talk a bit about my several years of experience in this field:

Blocking by IP address is pretty pointless. These spammers have thousands of IPs available. Many of them being changing DSL addresses, so if you block them, you also block legitimate users.
Blocking by keywords helps a bit, but not much. Ever recognised that the spammer's favorite "Nike" is also in the legitimate word "Elektroniken"?
Making their spam useless, like adding a 'rel=nofollow', is pretty pointless as well. They spam as much as they can, without looking right or left or at what's actually happening.

What does work? Well, these spammers have weaknesses, too.

One of them is that they generate plenty of accounts. All with different email addresses and from different IPs, but on average wikis there is no flood of 1000 new users a day, even if you're open to everybody.
They don't read the pages shown. Just small deviations from the default registration process, well described for legitimate users, keep them away.
Almost all their spam posts contain external links. Spreading such links is the entire point of their spamming, so they can't work around doing so. On MediaWiki it has worked very well to reject the first 5 edits with external links. 98% less spam. It's perfectly fine to explain the workaround (create a number of edits without external link) on the rejection page. Legitimate users read what's written there, so they get their stuff in without too much hassle anyways.
My current spammer doesn't use the link in the confirmation email. I get email rejection notices, the account is created anyways. Apparently this link is predictable. Fail.
My current spammer also uses no user agent. I'll get back to this in a minute.
IP address. It looks valid (192.95.4.148), but doesn't respond to a ping and also no DNS entry. Not sure how they manage to send HTTP requests from such an address, but doing simple tests like a DNS lookup would kick them out.

Our wiki is here: RepRap DIY. For nice looking wikis, DokuWiki is really great!

Possibility to use Tinypng when upload image ?

LeDistordu — Mon, 15 Jun 2015 09:47:57 GMT

It'd be nice if we could automatically use tinypng when image upload. It would be enough to add the API key in the admin area.

It should also be the ability to optimize already existing pictures.