[IGOR] New page with semicolon in title results in colon in namespace about plugin-blog

[fiwswe]

DW 2022-07-31a "Igor", PHP 8.0.24, Blog (Last updated on 2020-09-19)

Confirmed.

Normally my test Wiki places blog pages into namespace blog:. When using the Title Test; Issue #114 the new page was placed into the sub-namespace blog:test: (id=blog:test:issue_114).

But this does not seem to be caused by the Blog plugin. I tried placing this source code on a wiki page: [[Test; Issue #114 alternate]] and it created a link to the (non-existent) page id=test:issue#alternate. This actually shows 3 problems:

1. Your issue that the ; is replaced with a :and thus makes the first part of the title a namespace.
2. The # was kept, despite it having a special meaning in URLs, the "fragment" with the value of alternate in my test case.
3. The remaining page id was shortened so much that might become ambiguous, leaving only issue

Note: It is interesting to see that the same title used in the Blog form does not cause (2) and (3). The Blog entry for Test; Issue #114 alternate is d=blog:test:issue_114_alternate. So it seems slightly different rules apply for converting a title to a page id. In the case of the Blog form the function cleanID() seems to responsible for the conversion. In the case of the link, i.e. (2) & (3), the function page_exists() might be involved, but I have not done intensive testing yet. It does split the name at the # though.

So it might be better to reopen this issue at https://github.com/splitbrain/dokuwiki/issues.

fiwswe

[DB1BMN]

Thanks! Yes, I tried the other special chararcters of the German keyboard at it seems a DW-specific problem to be.
Will post there: dokuwiki/dokuwiki#3857

[Klap-in]

I think this is an issue with the blog plugin.
This blog plugin creates an new entry ID with the following function:

plugin-blog/action.php

Lines 192 to 214 in 2808107

	function _newEntryID($ns, $title) {
	$dateprefix = $this->getConf('dateprefix');
	if (substr($dateprefix, 0, 1) == '<') {
	// <9?%y1-%y2:%d.%m._ -> 05-06:31.08._ | 06-07:01.09._
	list($newmonth, $dateprefix) = explode('?', substr($dateprefix, 1));
	if (intval(strftime("%m")) < intval($newmonth)) {
	$longyear2 = strftime("%Y");
	$longyear1 = $longyear2 - 1;
	} else {
	$longyear1 = strftime("%Y");
	$longyear2 = $longyear1 + 1;
	}
	$shortyear1 = substr($longyear1, 2);
	$shortyear2 = substr($longyear2, 2);
	$dateprefix = str_replace(
	array('%Y1', '%Y2', '%y1', '%y2'),
	array($longyear1, $longyear2, $shortyear1, $shortyear2),
	$dateprefix
	);
	}
	$pre = strftime($dateprefix);
	return cleanID(($ns ? $ns.':' : '').$pre.$title);
	}

The title is before the call of that function cleaned from the :, but not ;. In the cleanID() function that character is cleaned as well:
https://codesearch.dokuwiki.org/xref/dokuwiki/inc/pageutils.php#120

The cleaning behaviour and handling of the #, % etc are the right logic for the cleanID() function.

So what is needed, is that the _newEntryID() function takes more care of these characters as these have a special meaning.

[DB1BMN]

Sorry, I don't think so.
Try to create a new page by entering "new;page" in the address bar of the browser directly and you will end up in "new:page" i.e. a new sub-namespace.

[Klap-in]

That is on purpose. Here is assumed that if you type such a new or existing pageid (manually in url etc), that you could probably make a typo by swapping a ; for a :. In page id all these special characters are forbidden, the allowed set of special characters is rather small (see also https://www.dokuwiki.org/pagename#naming_conventions ).
Because they are forbidden, such auto replacement of ; for a : is a safe action to do, because it should not be there.

For a new blog entry there is a form for typing a title. This title is used in two manners: 1) as first heading (=title) on the blog page, 2) as page id. For the page id we have to convert it to a cleaned name, that respects the naming convention. This is done with cleanID(), because this cleaning interpret some characters different then desired, we should already in the _newEntryID() function clean for these special characters that are interpreted wrong by the cleanID().

[fiwswe]

Ok, if we restrict ourselves to just the Blog plugin then https://github.com/dokufreaks/plugin-blog/blob/master/action.php#L91 seems to be the place where any cleanup should happen, I think. Currently only : is filtered as @Klap-in mentioned:

87   function _handle_newEntry(Doku_Event $event) {
88        global $ID, $INFO;
89
90        $ns    = cleanID($_REQUEST['ns']);
91        $title = str_replace(':', '', $_REQUEST['title']);
92        $ID    = $this->_newEntryID($ns, $title);

Maybe changing this to filter out other special characters such as ;, #, &, %, /, \, ? would help?

91        $title = str_replace([':', ';', '#', '&', '%', '/', '\\', '?'], '', $_REQUEST['title']);

I have added PR #115 for this proposed change.

Note: I still think the issue is more general than the Blog plugin. Basically we should differentiate between a human readable title and a page id and treat them separately. But in the case of the Blog plugin we know that we are dealing with a human readable title, not a page id. So there is no need to invent complicated logic to figure out what we are dealing with.

• In the case of a directly entered URL, it is obvious that we are dealing with a page id.
• In the case of a link ([[Test; Something]]) it gets more difficult because both page ids and human readable strings are possible.
• The case of [[test:something|Test; Something]] is unambiguous as the page id and the human readable title are clearly specified.

But these are questions for https://github.com/splitbrain/dokuwiki, not for the Blog plugin.

Also other plugins that allow page titles to be entered, such as Add New Page Plugin might also require some changes. But I have not checked this yet.

And btw: https://www.dokuwiki.org/pagename#naming_conventions should probably mention ;as an alternate namespace separator.