= Description =

## Please read this page. Lines prefixed with ## such as this one are comments,
## you can remove them (except for those after the "Plan" section.)
## Please follow the instructions given in those comments and the text.
## After creating the bug page, please subscribe to it! We may have questions
## that only you can answer, and if you get email when your bug changes it'll
## be much faster to get it fixed since you can answer the questions!

If you create a page with a colon in the name, for example HowTo:DoSomeTask, when you try to edit
the page, all of the buttons (save, preview, cancel, etc) are broken.

I tracked the problem down. It seems that in the !PageEditor.py, where it generates the form
for the editor, the action= part gets a string from request.href(self.page_name). It seems
the href method is what doesn't like the colons, and if you pass a page name with a colon
in it, the href method doesn't return the /full/path/to/pagename, but just the page_name
itself. This breaks the submission form.

I tried to escape it before passing it to href, but it ends up double escaped.
Did some further digging, and it seems that werkzeug's href uses a method called
url_quote which by default marks both '/' and ':' as "safe" chars, so they don't
get quoted. Not exactly sure how to get around this.

== Steps to reproduce ==
## Describe the steps needed to reproduce the bug. If we can't reproduce it, we  probably can't fix it.
 1. Create a page with a colon in the name, like !HowTo:DoSomeTask
 2. Try to edit the page
 3. Try to click save, cancel, or preview once you've entered the editor


== Example ==
##Add URL that show the bug, screenshot or test wiki markup that fail...

##URL: 

##{{attachment:screenshot.png}}

##{{{
##Example wiki markup that fail
##}}}

== Component selection ==

## Where you think is this bug happening ? (general, plugin [plugin name], theme [theme name], ...

 * Error is in the !PageEditor.py (and any other files that generate the edit form)
 * Problem is either with werkzeug's href method, or the fact that moinmoin doesn't escape the page before sending it to the href method, depending on how you look at it.

== Details ==

## If you got a traceback, please save the traceback page as html and attach here:
## [[attachment:traceback.html]]

## if the bug is in this wiki, just kill the table and write: This Wiki.

## If a traceback is not available, please fill in the details here:
|| '''!MoinMoin Version''' || 1.9.2 ||
|| '''OS and Version''' || Ubuntu 10.04 ||
|| '''Python Version''' || 2.6.5 ||
|| '''Server Setup''' || ||
|| '''Server Details''' || ||
|| '''Language you are using the wiki in''' (set in the browser/UserPreferences) || EN ||

== Workaround ==
## How to deal with the bug until it is fixed

No real work around. A good solution would probably entail modifying werkzeug's code to either
remove the ':' from the safe char list in it's url_quote method, or some how allow you to pass
in your own safe char list to over ride the default.

= Discussion =
Isn't the colon syntax recognized as an InterWiki?

Can the Request.href function be passed a URL which actually has a http: prefix? I'm not sure, but in this case,
: should be part of safe_chars. Prefixing the relative URLs with ./ before passing it to werkzeug's Href
seems to make it do the correct thing. [[attachment:wiki-colon-link-hackyfix1.diff|Here is a horrible patch that implements this hack.]] --BernardB.

Very similar issue: [[MoinMoinBugs/PagenameContainingColumn]]

I filed a werkzeug bug about this, let's see what happens:

https://github.com/mitsuhiko/werkzeug/issues#issue/46

= Plan =
## This part is for Moin``Moin developers:

 * Priority: 
 * Assigned to:
 * Status: looks like fixed in more recent werkzeug releases (we'll bundle a more recent one into 1.9.4 also)

----
## If you are a moin core developer, replace the category to Category* in these cases:
## Category MoinMoinNoBug - if this is not a bug.
## Category MoinMoinBugConfirmed - if you can confirm the bug on current code.
## Category MoinMoinBugFixed - after the bug is fixed in current code.
CategoryMoinMoinBugFixed