Issue Details (XML | Word | Printable)

Key: MDL-17237
Type: Bug Bug
Status: Open Open
Priority: Minor Minor
Assignee: Eloy Lafuente (stronk7)
Reporter: Dean Thayer
Votes: 7
Watchers: 5
Operations

Add/Edit UI Mockup to this issue
If you were logged in you would be able to see more operations.
Moodle

Can't edit a wiki with a # (hash, number sign, pound sign) in it's name.

Created: 15/Nov/08 12:20 AM   Updated: 14/Jul/09 04:23 AM
Return to search
Component/s: Wiki (1.x)
Affects Version/s: 1.9.2
Fix Version/s: None

Issue Links:
Relates
 

Participants: Charles Fulton, Dean Thayer, Eloy Lafuente (stronk7), Kenneth Newquist and Paul Grzesina
Security Level: None
Affected Branches: MOODLE_19_STABLE


 Description  « Hide
If a wiki is created with a # in its name, the edit tab will truncate the pagename at the #. Then it will commit the edits to the wiki_pages table with the incorrect pagename. Thus, the edits will be reflected in the edit tab, and in the view tab after an edit has been performed, but they will never make it to the main entry displayed by view.php. The truncated pagename field results in abandoned records in the database because there is no way to relate the wiki id to the truncated pagename. Have only confirmed this on 1.9.2, but I suspect it is in 1.9.3 and prior.

 All   Comments   Change History   Version Control      Sort Order: Ascending order - Click to sort in descending order
Dean Thayer added a comment - 15/Nov/08 12:25 AM
Seems that some characters in the name of a wiki are not handled properly. Perhaps they can be identified and escaped.

Kenneth Newquist added a comment - 19/Nov/08 02:06 AM
I can confirm the bug exists. It gets to be even more fun when you add groups to the mix. Just in case it's not clear, the wiki will allow you to create a page with the pound sign in the name, but subsequent edits will truncate the name at the pound sign.

That's the problem at its most fundamental level.

In our case, we had people creating new pages that some how got the original text into the new page, which isn't behavior I saw in my tests. Yet if I look at the initial page for these wiki pages, I can see that they started with the same text as the initial page, and I don't think the students or instructor copied text over into the new page.

In any case, the truncation does happen, and causes exactly the sort of havoc that Dean describes as the initial page gets divorced from subsequent versions.


Charles Fulton added a comment - 10/Jan/09 04:29 AM
I think this might be a function of HTML purifier; it the wiki itself does it I couldn't find where. I think the desired behavior would be for the pound to allow internal linking to an anchor within the target page.

Paul Grzesina added a comment - 14/Jul/09 04:23 AM
It appears to be a problem with the generation of links for the tab bar. The following patch seemed to fix it for me, but I haven't exactly run extensive tests:

Index: view.php
===================================================================
— view.php (revision 972)
+++ view.php (working copy)
@@ -375,7 +375,7 @@
$currenttab = '';
foreach ($tabs as $tab) {
$tabname = get_string("tab$tab", 'wiki');

  • $row[] = new tabobject($tabname, $ewbase.'&page='.$tab.'/'.s($ewiki_id), $tabname);
    + $row[] = new tabobject($tabname, $ewbase.'&page='.$tab.'/'.s(urlencode($ewiki_id)), $tabname);
    if ($ewiki_action == "$tab" or in_array($page, $specialpages)) { $currenttab = $tabname; }