DokuWiki: Recently Opened Tasks

[issue-open]: Extension manager fails to download large plugins (e.g. dw2pdf) due to hardcoded 25s timeout in extension helper

heitmanr — Sat, 19 Sep 2026 16:44:28 +0000

### The problem

### Description
When trying to update or install large plugins like `dw2pdf` (which is ~48MB) via the Extension Manager, the download consistently aborts after exactly 25 seconds with a "Download not possible" error.

### Cause
While `$conf['http_timeout']` can be adjusted in `local.php`, the Extension Manager bypasses this setting due to a hardcoded timeout value within the core extension plugin.

The hardcoded limit is located here:
`/lib/plugins/extension/helper/extension.php`
```php
$http->timeout = 25; // Or similar hardcoded assignment
```

### Proposed Solution
Instead of a hardcoded `25`, the Extension Manager should respect the global `$conf['http_timeout']` setting, or at least have a significantly higher default timeout (e.g., 120 seconds) to accommodate large plugins that include heavy third-party libraries (like mPDF in dw2pdf).

Changing this value manually to `120` immediately fixed the issue and allowed the download to complete successfully.

to be honest - I changed _every_ hard-coded "timeout = 25" at 4 places, "extension.php" was the last change which made it work.

sudo egrep -rn "timeout = 120.*25" /var/www/html/dokuwiki
**/var/www/html/dokuwiki/lib/plugins/extension/Installer.php**:295: $http->timeout = 120; // max. 25 sec (a bit less than default execution time)
**/var/www/html/dokuwiki/lib/plugins/extension/helper/extension.php**:923: $http->timeout = 120; //max. 25 sec
**/var/www/html/dokuwiki/inc/io.php**:713: $http->timeout = 120; //max. 25 sec
**/var/www/html/dokuwiki/inc/media.php**:1892: $http->timeout = 120; //max. 25 sec

### Version of DokuWiki

2026-07-14c "Mort"

### PHP Version

8.3

### Webserver and version of webserver

Apache 2.4 on Ubuntu Linux

### Browser and version of browser, operating system running browser

any

### Additional environment information

_No response_

### Relevant logs and/or error messages

```text

```

[issue-open]: Parts of the links in the table of contents are not working

update-freak — Fri, 18 Sep 2026 19:02:35 +0000

### The problem

From the subsection "Blueprints" it can be seen that the links on the table of contents are not reacting (no underlined naming). A click on the "disabled" items does not have an effect.
https://github.com/user-attachments/assets/55ea544a-5868-4e8c-aa91-c9f2852de15c

### Version of DokuWiki

2026-07-14c "Mort"

### PHP Version

8.5.10 fpm-fcgi

### Webserver and version of webserver

_No response_

### Browser and version of browser, operating system running browser

Firefox 156.0

### Additional environment information

docker compose for dokuwiki

```
services:
dokuwiki:
container_name: dokuwiki
image: ghcr.io/linuxserver/dokuwiki
restart: always
ports:
- 1041:80
volumes:
- /volume1/docker/dokuwiki:/config:rw
environment:
- PUID=1026
- PGID=100
- TZ=Europe/Berlin
```
Installed on a Synology NAS.

Firefox extensions:
- Bitwarden
- ClearURLs
- Cookie Auto Decline
- SingleFile
- uBlock Origin

DokuWiki Extensions
- Bootstrap Wrapper Plugin
- bpmnio Plugin
- Changes Plugin
- cleanup Plugin
- DataTables Plugin
- diagrams Plugin
- DOI Plugin
- DW2PDF Plugin
- Faster DokuWiki Plugin
- Folded Plugin
- ImgPaste Plugin
- Katex Plugin
- Move Plugin
- sectiontoggle Plugin
- ToDo Plugin
- Video Share Plugin

### Relevant logs and/or error messages

```text

```

[issue-open]: code copy button copies itself

simmstein — Fri, 18 Sep 2026 14:47:04 +0000

### The problem

Quick and dirty fix:

```diff
if (codeLines.length === 0) {
// hide button so its text is excluded from innerText
this.hidden = true;
textToCopy = preElement.innerText; // normal code block
this.hidden = false;

+ let lines = textToCopy.split("\n");
+
+ if (lines.length > 1) {
+ delete lines[lines.length-1];
+ }
+
+ textToCopy = lines.join("\n");
} else {
textToCopy += Array.from(codeLines)
.map(line => line.innerText)
.join("\n");
}
```

### Version of DokuWiki

2026-07-14c "Mort"

### PHP Version

8.2

### Webserver and version of webserver

Apache2 on Debian

### Browser and version of browser, operating system running browser

Firefox 156.0, Chromium 153.0

### Additional environment information

Same issue as #4617: the code copy button does not only copy the code but also the button text itself.

https://myapp/wiki/lib/scripts/page.js <=> https://raw.githubusercontent.com/dokuwiki/dokuwiki/refs/heads/master/lib/scripts/page.js

[issue-open]: Empty backticks break markdown tables

tylerlwsmith — Sun, 13 Sep 2026 23:15:50 +0000

### The problem

I was working on the following markdown table in my wiki:

```md
|n|description|ls|binary|umask|
|---|---|---|---|---|
|`0`|No permissions at all|`---`|`000`|``|
|`1`|Only execute|`--x`|`001`|``|
|`2`|Only write|`-w-`|`010`|``|
|`3`|Write and execute|`-wx`|`011`|``|
|`4`|Only read|`r--`|`100`|``|
|`5`|Read and execute|`r-x`|`101`|``|
|`6`|Read and write|`rw-`|`110`|``|
|`7`|Read, write, and execute|`rwx`|`111`|``|
```

I hadn't filled out the empty backticks in the **umask** column. When I previewed the table, the **umask** column consumed the content from the next row, putting it in a code block.

I would expect that when empty backticks are in a table column, it would render nothing or render the backticks as is: not absorb the next row. For example, I get the following when rendering the same markdown table in VS Code:

I love the new built-in markdown featur–thanks for everything!

### Version of DokuWiki

2026-07-14b "Mort"

### PHP Version

8.5.4

### Webserver and version of webserver

_No response_

### Browser and version of browser, operating system running browser

_No response_

### Additional environment information

_No response_

### Relevant logs and/or error messages

```text

```

[issue-open]: markdown breaks some entities

krodelabestiole — Fri, 11 Sep 2026 18:48:35 +0000

I think markdown is treated _before_ entities replacement, even whit syntax set to `dw+md`.

in the documentation there is this example :
```
\_
```

which is the only way I found to add a non breaking space before : and ; ! ? etc. (and is useful in a few other places)
this is mostly because the usage of trim seems to forbid the use of space in entities declarations as shown in
https://github.com/dokuwiki/dokuwiki/pull/3018
which is another topic, sorry !

anyway...

the issue here is that these `\_` that we have been adding everywhere are replaced by `_` (instead of ` `) when activating markdown.

I think entities should be treated before markdown !

[issue-open]: Syntax hightlighting numbering can use letters instead of numbers

schplurtz — Thu, 10 Sep 2026 05:52:10 +0000

### The problem

When using syntax highlighting within a numbered list, default CSS uses letters instead of numbers for line numbers. Problem is visible at https://www.dokuwiki.org/playground:letternumber

The following wiki markup does not render as intended:
```
- open file
- add a line as shown


doc= {
  a: 1,
  b: 2,
  c: 'hello',
  d: 'bye bye'
};

- Save and quit
```

The codeblock `...` produces this output:

```
a. doc= {
b. a: 1,
c. b: 2,
d. c: 'hello',
e. d: 'bye bye'
f. };
```

The expected rendering is:

```
1. doc= {
2. a: 1,
3. b: 2,
4. c: 'hello',
5. d: 'bye bye'
6. };
```

### Version of DokuWiki

master

### PHP Version

any

### Webserver and version of webserver

_No response_

### Browser and version of browser, operating system running browser

_No response_

### Additional environment information

_No response_

### Relevant logs and/or error messages

```text

```

[issue-open]: Incorrect display of resized PNG and SVG files

HMJR — Wed, 09 Sep 2026 11:30:14 +0000

### The problem

Incorrect display of resized PNG and SVG files in Mort version. See the two examples below, showing how they are correctly displayed in Release 2025-05-14a “Librarian” and Release 2026-07-14c “Mort”.

### Version of DokuWiki

Release 2026-07-14c "Mort"

### PHP Version

8.2.31

### Webserver and version of webserver

_No response_

### Browser and version of browser, operating system running browser

_No response_

### Additional environment information

_No response_

### Relevant logs and/or error messages

```text

```

[issue-open]: INFO:syntaxplugins bug and crashes

SKruch — Sun, 06 Sep 2026 14:24:11 +0000

### The problem

TypeError: dokuwiki\MailUtils::obfuscate(): Argument #1 ($email) must be of type string, null given, called in /var/www/doku-test/inc/parser/xhtml.php on line 1161
An unforeseen error has occured. This is most likely a bug somewhere. It might be a problem in the info plugin.

More info has been written to the DokuWiki error log.

### Version of DokuWiki

2026-07-14c "Mort"

### PHP Version

8.4.22

### Webserver and version of webserver

Ubuntu 22.04.5 LTS; Apache/2.4.68 (Ubuntu)

### Browser and version of browser, operating system running browser

_No response_

### Additional environment information

_No response_

### Relevant logs and/or error messages

```text
AH01071: Got error '; PHP message: PHP Warning: Undefined array key "url" in /var/www/dokuwiki/lib/plugins/info/syntax.php on line 124; PHP message: PHP Warning: Undefined array key "date" in /var/www/dokuwiki/lib/plugins/info/syntax.php on line 127; PHP message: PHP Warning: Undefined array key "email" in /var/www/dokuwiki/lib/plugins/info/syntax.php on line 130; PHP message: PHP Warning: Undefined array key "author" in /var/www/dokuwiki/lib/plugins/info/
syntax.php on line 130', referer: http://dokuwiki.svityaz.loc/wiki/plugins/info
```

[issue-open]: Code block highlight options are silently dropped unless every value is quoted

splitbrain-bot — Sat, 05 Sep 2026 15:07:13 +0000

### The problem

Code block highlight options are silently dropped unless every option is written as `key="value"`. Two separate mis-parses in `parseHighlightOptions()`:

**1. A bare flag followed by a comma loses its name.** The comma is absorbed into the key, so the key becomes `enable_line_numbers,`, which then fails the whitelist and is dropped:

```


$a = 1;

```
renders with **no line numbers at all** — even though `start_line_numbers_at` was accepted. Written the other way round (`[start_line_numbers_at="10",enable_line_numbers]`) it works, because the bare flag is last.

**2. An unquoted value swallows the rest of the option list.** `(\w+(?:=[^\s]*))` runs to the next whitespace, so everything after it up to `]` becomes part of the value:

```
[start_line_numbers_at=10,highlight_lines_extra="2"]
```
yields `start_line_numbers_at = 10` (the trailing junk is dropped by `(int)`) and loses `highlight_lines_extra` entirely.

Nothing is logged, so the option just appears not to work.

### Details

The regex in `inc/Parsing/Helpers/Code.php:61` is

```php
preg_match_all('/(\w+(?:="[^"]*"))|(\w+(?:=[^\s]*))|(\w+[^=\s\]])(?:\s*)/', $options, $matches, PREG_SET_ORDER);
```

The third alternative, which handles bare flags, is `\w+` followed by `[^=\s\]]` — one mandatory character that is not `=`, whitespace or `]`. For `[enable_line_numbers]` that character is the final `s` of the name (backtracking off the `]`), so the key comes out right by luck. For `[enable_line_numbers,…]` the `,` satisfies it instead, and the key keeps the comma. `trim()` only strips whitespace, so it survives into `array_intersect_key()` and is dropped there.

Full results, straight from the helper:

```
[enable_line_numbers] => {"enable_line_numbers":true}
[enable_line_numbers,start_line_numbers_at="10"] => {"start_line_numbers_at":10}
[start_line_numbers_at="10",enable_line_numbers] => {"start_line_numbers_at":10,"enable_line_numbers":true}
[enable_keyword_links,enable_line_numbers] => {"enable_line_numbers":true}
[start_line_numbers_at=10,highlight_lines_extra="2"] => {"start_line_numbers_at":10}
[enable_line_numbers="true",start_line_numbers_at="10"]=> {"enable_line_numbers":true,"start_line_numbers_at":10}
```

So the only forms that always parse correctly are fully quoted `key="value"` pairs, plus at most one bare flag in last position. The examples on [wiki:syntax](https://www.dokuwiki.org/wiki:syntax#syntax_highlighting) all use the quoted form, which is presumably why this has gone unnoticed.

Both affected keys are booleans (`enable_line_numbers`, `enable_keyword_links`), which are exactly the ones a user would naturally write bare.

This is not new — the same regex is in `inc/parser/handler.php::parse_highlight_options()` in release-2025-05-14 and earlier; the recent split into `Parsing\Helpers\Code` only moved it. It now also affects GFM fenced blocks, which share the helper: ` ```php [enable_line_numbers,start_line_numbers_at="10"] ` drops the option in exactly the same way.

Found while looking into #4755.

### Version of DokuWiki

master (2026-07-14c "Mort" and current master; also reproduced against release-2025-05-14)

### PHP Version

8.5.4

### Webserver and version of webserver

PHP built-in server (irrelevant, this is pure parsing)

### Browser and version of browser, operating system running browser

n/a — server side

### Additional environment information

Reproducible directly against the helper, no wiki needed:

```php
use dokuwiki\Parsing\Helpers\Code;
var_dump(Code::parseHighlightOptions('[enable_line_numbers,start_line_numbers_at="10"]'));
```

### Relevant logs and/or error messages

```text
none — the options are dropped silently
```