Summary: Add edit notices/warnings in a consistent fashion, and
                    put them in a sensible order
           Product: MediaWiki
           Version: 1.16-svn
          Platform: All
        OS/Version: All
            Status: NEW
          Severity: trivial
          Priority: Normal
         Component: User interface
            Blocks: 18654

As best I can tell, the four functions in EditPage.php that add messages above
the edit window add them in approximately the following order:
   1. interface editnotice
   2. no-such-user warning
   3. Custom editintro supplied by &editintro= GET parameter
   4. new-article help
   5. log extract for deletion/move logs
   6. talk page editnotice
   7. Per-namespace editnotices, and per-page editnotices where those are still
(accidentally) enabled
   8. Edit conflict warning
   9. warning you get if you try to create a new section and save it with no
  10. force-edit-summary-warning
  11. force-edit-summary-warning for new sections
  12. Messages generated by hooks such as Capthas, AbuseFilter, etc
  13. warning about browsers that mangle unicode
  14. warnings related to RevDelete
  15. editing-an-old-revision warning
  16. warning about the wiki being locked
  17. not-logged-in warning
  18. JS warning
  19. JS/CSS preview notices
  20. warning about semi-protection or full-protection or cascading protection
or creation protection
  21. long page error or warning

A logical order would have the most general notices
([[MediaWiki:readonlywarning]] and then [[Mediawiki:Talkpagetext]]) first,
followed by namespace-specific notices (all of which could/should be
implemented through the per-namespace editnotice system), followed by per-page
editnotices and finally warnings about the particular edit the user is trying
to make.  And they should be added in a consistent fashion that ensures they
are properly parsed, don't get random extra classes added to them, and have
consistent ids.

Configure bugmail:
------- You are receiving this mail because: -------
You are the assignee for the bug.
You are on the CC list for the bug.

Wikibugs-l mailing list

Reply via email to