Back to MoinMoinTodo | Things that are MoinMoinNotBugs or MoinMoinKnownProblems | MoinMoinTests contains tests for many features
1. Creating A Bug Report
First make sure you run the latest version of moin, see FrontPage (this is either the latest released version if you want to report a bug in a release, or that latest developer version, if the bug happens in a developer version).
Then select a good wiki name: BugName - the name should describe the bug in few words.
Insert a link in this page to your bug, in this format: * /BugName under the proper topic. Add a topic if needed.
- Save this page and click your link. A page creation page will be opened.
Important: Select the BugTemplate from the list of templates.
- Read the instructions and fill in the requested data.
1.1. What if I don't know if its a bug?
Maybe we should create a page for these? ["/IsThisABug"]
First look if it is on MoinMoinFeatures.
2. Current Bugs
Already fixed bugs are marked with - if the bug is superseeded by either a new release or a new developer version, the bug will be removed from here.
2.1. Actions
2.2. User Preferences
2.3. Wiki Markup
- ["WikiSandBox/IsThisTOCMacroBug"]
2.4. Macros
2.5. System Information
2.6. Themes
/RightSideBarExtraDiv (sorry, not a bug in moin, a bug with wikipedia)
2.7. Email Sending
2.8. Localization
2.9. Install
2.10. Language Issues
2.11. RecentChanges
2.12. Not Bugs?
Cosmetic problems, wishes, wrong installation problems, etc.:
- ["/Apache2"]
3. Bugs To Be Sorted
These bugs should be sorted into their own pages, soon as possible
3.1. User Interface
3.1.1. Named <div> needed before output from diff
The output from clicking on a diff icon needs to be surrounded by a named <div> so it can be highlighted if a theme administrator so desires. The output from a no differences found:
<p><strong> Differences between versions dated 2004-03-10 14:20:39 and 2004-03-10 14:20:39 </strong></p>No differences found!
When differences are found, they are shown inside a named table, but the heading is outside the class definition.
<p><strong> Differences between versions dated 2004-03-10 14:20:38 and 2004-03-11 18:29:58 </strong></p> <table class="diff"> <tr> <td class="diff-removed"> ...
A nit, but a named class before the heading would allow css highlighting.
3.1.2. Navi_bar and /SubPages
If you include a link to a sub page as such [FrontPage/BookMarks Bookmarks] This works fine unless you are in a subpage of frontpage, either bookmarks or another subpage... at which point this link now points to FrontPage/FrontPage/BookMarks instead of FrontPage/BookMarks -- JonathanDietrich
3.2. Other Issues
3.2.1. InterWiki links
InterWiki links should either display the destination Wiki name or generate the A tag with a TITLE attribute so that (at least in IE) the full destination is displayed by floating the cursor over the link. At the moment, it's too hard to figure out where the link goes. With that many InterWiki destinations recognised, we can't expect everyone to be able to recognise the URL.
- Hover over the interwiki icon and you'll already get a tooltip, I'll look into the title attribute stuff.
- Ta.
3.2.2. paragraph bug redux
They render identically with IE5. Provide some info on your browser & OS. And the HTML is identical:
Some text. <p> <b>window</b> <ul> The main, rectangular background, control and data area of an application. <p></ul> <b>dialog boxes</b> <ul> A temporary, pop-up window created by the application, where the user can enter information and provide commands. <p></ul>
Please note that they aren't actually identical: the P that precedes dialog boxes is interrupted by the closing /UL tag, whereas the P preceding windw is not followed by a closing /UL.
3.2.3. Variable substitution
If we refactored code to use wiki DOM, don't replace @VARS@ in code displays.
3.2.4. Bad interwiki behavior
See MarkupProposals for discussion how the linking markup should look like
wiki:MoinMoin is treated as a bad tag, while [wiki:MoinMoin] is working as a local page. It seems to be a bad idea to using wiki:PageName as a local link. It may cause a unwanted situation. For example, wiki:MoinMoin/FrontPage works well. But does it works well if somebody makes a MoinMoin/FrontPage page in that wiki?
How about to introduce thw self URL scheme? wiki:self:PageNmae could be shorten as self:PageName.
-- CD
See HelpOnLinking, and
MoinMoin/FrontPage would be MoinMoin/FrontPage or MoinMoin/FrontPage or wiki:MoinMoin/MoinMoin/FrontPage and quite some other variations, also involving "[]". Confuzed enough?
Dangling links (anything in this wiki, possibly the front page):
- JH
Confusing #1:
[wiki:MoinMoin/MoinMoinTest]
[wiki:MoinMoin/MoinMoinTestTest]
Different results for the existing page (MoinMoin/MoinMoinTest) and the non-existing page(MoinMoin/MoinMoinTestTest)!
Confusing #2:
[wiki:HelpOnEditing/SubPages]
- CD
And what is this supposed to tell us? Half of them are undefined or broken, and bracketed links are always rendered differently than plain ones.
3.2.5. Attachments Content Type
There should be some problems with the content type specified on the attachment upload form because i always get a xul file for which i have specified the content type application/vnd.mozilla.xul+xml as text/html . I have tried text/xml too....
I have an example on MozillaSideBarPanel
3.2.6. #DEPRECATED handling
When first adding #DEPRECATED, a final backup should be made; currently, you have to remember to do this manually.
- When #DEPRECATED appears on the backup page, the #DEPRECATED handling seems to be triggered repeatedly; this is of course wrong.
Overall, people appear to have problems with grasping how the stuff works. Maybe a better way would be to change full-text search to look at the pragma instead of the special edit/display handling.
3.2.7. Incorrect Numbering for Subpages
The numbering for headers in subpages is incorrect, see the example at my home page MarkProctor
The issue seems to be in Include.py (line 180) where you have:
level = 1
This resets the level of headers creating the effects visible in MarkProctor.
3.2.8. ACLs and Email
Currently a user who is not allowed to view a page, but is subscribed to it, is still sent a diff with changes. Being sent an email is not necessarily bad, as the fact the page changed also appears on the recent changes page, but they should definately not receive diffs. (I have added this elsewhere, but this is probably where I should have put it.)
Yes, this is a bug. may uses request.user.name (this is the one who was editing the page) instead of a name we should give it as parameter. Done. -- ThomasWaldmann DateTime(2004-05-26T21:21:38Z)
3.2.9. MissingPage div bug
In 1.3, when you go to a missing page it has two content divs, so if you have a theme that has margins for the content div, the content div has double the margins.
In 1.3 this happens because Moin sends the content div and when the page doesn't exist, it sends MissingPage which adds another content div. This is around line 600 in Page.py.
-- EricDavis
3.2.10. DivContentIssues
In 1.2.2 the version-history and system-info pages get the <div id="content"> twice and thus are indented twice in themes that give the content margins (sidebar-themes)
Suggested solution: change in wikiaction.py:
delete lines 336 and 384 (request.write('<div id="content">\n') # start content div)
Reason:
the <div id="content"> is already produce for all info pages in do_info on line 535
Also the preview in the editor gets indented twice.
Suggested solution: change in PageEditor.py:
after line 401 add a line "self.request.write('</div>\n')"
Reason:
- this way the content_div gets closed and the preview is displayed across the whole width (without the content-margins)
For your convenience here is a patch (for both) against moin-1.2.2: attachment:content_div-issues.patch
-- NiklasGidion