1.8.3c Checklist

Creating

• Hitting “New page” should create a new page underneath the current page of the hierarchy
• Default page title should follow the format defined by the localization resource key Article.Common.new-page-title (Default: Page Title$1)
• Creating a new page deep in a hierarchy that doesn’t exist creates “placeholder” pages (Example: if page Foo doesn’t exist, and I create page Foo/Bar, then Foo will be a placeholder page)
• The variable passed to the localization key should be an incrementing number, depending on other pages which already exist
  • Example: Creating a new page underneath page Foo, where Foo/Page Title already exists should yield a new default title of Foo/Page Title 2
  • This rule is ignored if Foo/Page Title is a redirect page – a new page will overwrite redirect pages
  • Regression: If Foo/Page Title is a deleted page, the new page should still be named Foo/Page Title and not Foo/Page Title 2
• Created pages inherit the restrictions of their parents
• All failed states on save should return the editor with the new contents
  • Pages with blank titles or invalid titles (Example: “./Title”) fail explicitly with an error message
  • Setting the title to the title of an existing page fails explicitly with an error message (this can happen for pages that do not appear to user – hidden restricted pages)

Editing

• The editor should be accessible from ?action=edit on any URL (example: /index.php?title=Foo&action=edit
• When two separate users load the editor for the same page at the same time and submit different changes to save, two things can happen:
  • If the changes were made to separate parts of the document, the changes will be automatically merged, and a message will be returned to the user
  • If there are changes in the same area, the changes will be saved, but a notice will be given to a user that some changes were overwritten – a link is provided where they can see the change that they deleted, and then add in the changes manually.
• Hovering over a header while in view mode displays an edit icon – this allows for section editing
• Text with header styles appear in the Table of Contents (TOC); they are ordered by ranking (for example, a <h3> title below a <h2> becomes nested underneath the <h2> in the TOC
  
• For 1.9.0: Changing the title for a page no longer moves the page, but rather updates the display title. The display title is the title the user sees in the user interface, including the navigation pane, the HTML <title>, as well as the page contents. Changing the display title does not change the path of the page in the URL ("path title").
  
  • When the page title is changed in the editor on save, the URL will stay the same, but the display title will change. The page will not be moved
  • There is no limitation (except a character limit) to what you may put as the display title - in the past, you could not start a title with ./, but now you may.
    
  • Clearing the title from the editor on save will revert the display title to be the same as the path title once again
  • Display titles may be set for any and all editable pages
  • HTML is still invalid in page titles for security reasons
• For 1.8.3: Changing the title for a page will move the page to that title, but within the same hierarchy (it will treat slashes as part of the title).
  • Example: if I am editing page Foo/Bar and the title is changed to “Bar/Baz”, then the page’s title will become “Bar/Baz” and be a part of the path of “Foo”

Restrict

• View/edit permissions may be restricted to certain users or groups
  • Administrators can see all restricted pages, even when they are not explicitly added to a page
  • All other users are subject to the rules of the restriction (public, semi-private (view = all, edit = some), private)
  • When adding users or groups to restrictions, the auto-complete must be utilized to select groups
• Restrictions may be set for a single page, or cascaded down to all children
  • When restrictions are cascaded, the difference of the restrictions on the current page are calculated and then applied downwards (See the spec for a more formal explanation)
• Privately restricted pages should not show up in the nav pane

Moving

• Pages can never have redirect pages as their parent – there should always be a placeholder page
• Moving a page will move all content as well as children to the new location
• Moving a page does not affect the display title of the page
  
• Moving a page creates a redirect page at the old title
  • Attempting to access the old URL will automatically redirect you to the new location, with a Redirect icon
  • Clicking the redirect icon will take you back to the old URL with a message that the page has been redirected (this page can now be edited or deleted)
• Failed operations with move should redirect back to the old title with an error message, with no action taken:
  • A page cannot be moved as a child of itself
  • A page cannot be moved over an existing page, unless the existing page is a redirect
  • Pages which contain restricted children you do not have access to
    • TOFIX: Better UI error handling
  • Pages that cannot be moved:
    • Root user pages (Example: User:JohnSmith)
    • The home page cannot be moved
    • Special/Admin pages
    • User: and Template:

Navigating

• If the skin enables the navigation pane, it should appear with a list of all sibling pages as well as child pages
• Ensure subpages behave correctly for pages in User: namespace (see #3183)
  
• For 1.9.0: The navigation pane is ordered by the path title, not the display title. 
  

Deleting

• Pages can never have deleted pages as their parent – there should always be a placeholder page
• Individual page or whole hierarchies can be deleted
• Deleting removes all comments and files from the page as well
• Restoring a page is possible by visiting the URL of the deleted page as an admin
• Creating a new page (not restoring) with the same title of a deleted page will create a new history for that page
• Pages that cannot be deleted:
  • Home page
  • Pages you do not have access to edit

Restoring

• Restoring a page as an administrator should return the last known page content’s along with its history and metadata (tags and comments); files and images are currently not restored
• If multiple sets of pages were deleted, restoring should only return the last set of pages
  • Example: Create page Foo and edit it once (Foo1). Delete this. Create a new Foo page and edit it once, then delete it (Foo2). Attempt to restore page Foo; it should only restore Foo2

Tagging

• Saving tags:
  • Tags are separated on input with linebreaks and may contain spaces and commas
  • On save, all tags are stripped of HTML tags, trimmed of spaces before and after the tag, and are converted into lowercase
  • Tags may be prefixed with define: or date: to trigger special behavior on view
    • Only one page may hold the definition for a tag (“define:foo”); if you save a page with this define tag, and another page has this define tag, the older define tag will revert to a regular tag (“define:foo” => “foo”)
    • Chonotags accept a wide range of inputs like date:now, date:next week; see PHP’s strtotime() functionality, which handles this
• Viewing tags:
  • Every page shows a comma separated list of tags sorted by their type (define tags, chronotags, normal tags)
  • For every definition tag a page holds, a “Pages with this tag:” will shows up below the tag list which takes the place of the Special:Tags page if any other pages has this tag
• Clicking a tag has different behavior depending on the tag type:
  • Normal tag – links to a Special: Tags page which shows all other pages which has this same tag, in alphabetical order of page title (not hierarchy)
    • If another page has defined this tag (“define:foo”), then clicking the link will redirect you magically to that page
  • Chronotag – links to a Special:Events which shows all other events occurring on the same date

Emailing

• A link to any page in Deki Wiki may be emailed by a logged in user to an email address
• On sending:
  • The username of the logged in user and the URL of the page is filled in
  • Multiple recipients for the email may be specified by using commas (usernames are also valid inputs)
    • If the same email addresses are specified in a list, multiple emails should not be sent – only one copy per unique email address

Commenting

• Registered users may comment on any page as long as they have access to view the page – we use flat comments
• Viewing
  • Shows the last 15 comments (set by $wgCommentCount) in chronological order (older -> newer)
    • Since comments are generally a discussion, showing in reverse chronological doesn’t make sense – likewise, for a long thread, the older comments tend to degrade in value over time
  • “Viewing all” comments show them in chronological format, including messages for deleted comment (“Comment #X was deleted”)
  • Comments are stored in plain text format (no HTML); linebreaks are converted into HTML linebreaks
  • Each comment is associated with a permalink, using the comment # (Example: /Foo#comment4)
• Editing
  • Only the original commenter may edit their comments (to prevent a rogue administrator from messing with the content of a comment)
  • Editing a comment displays a message saying “Comment last edited ____” (this is set in the localization file)
• Deleting
  • Deleting an comment may be done by the original commenter or an administrator
  • Deleting a comment requires a Javascript confirmation
• Verify all edit, delete, and view functionality works after posting a comment (there might be a bug in the inline loading after posting comment)

Printing

• Printing a page prints its contents and some associated metadata
• All metadata checkboxes should correlate to the output of the content; all checkboxes should be stored between page views
• Metadata:
  • Show Table of Contents: Shows the table of contents, if it exists (generated from headers)
  • Show Page Modified Info: Shows the URL of the page
  • Show Link Endnotes: Loops through all links in the content, and explicitly generates link URLs for display (like references)
• Using “Print” from the browser (and not the Deki Wiki feature) should print just the content (no UI) for all skins

History

• Clicking the “last modified” link should return a list of page revisions – these apply only to page edits and no other actions
• Items should be paginated, 50 edits per page
• Clicking on “View version” should return what that version of the page looked like
• Selecting two revisions with the checkboxes and doing a “Revision Comparison” will show the differences between the two copies (green is added text, red is removed text)
• Clicking the “Revert” button should return the current copy of a page to the selected older version

Watch/Unwatch

• A registered user may watch/unwatch any page; when a page is watched, the “My Watched Pages” shows a listing of last updates to this page

Link dialog

• Launching the link dialog always launches the search mode first; highlighting unlinked text populates the search result with the highlighted text - otherwise, the URL of the link is input into the search box
  • External links are not searched

Image dialog To enable image dialog in 1.8.3c:  in editor/Xinha/core/plugins/MindTouch/mt-cng-xinha.js, edit line 950; follow instructions in code comments

• In navigation mode, 2nd pane is converted into a small preview mode for image
• For image dialog, navigation mode is launched by default, with current page selected
• There are two sets of options for image dialog:
  • Image size: Small, Medium, Large, and Custom
    • When editing, size will always show up as "custom" with pixel sizes specified
    • When inserting external image, only custom option is available
      
  • Image alignment: Insert as own block, insert with text wrapped left & right
    

Move dialog

Incomplete for now.  

Attaching

• Files up to the size limit (configuration key: files/max-file-size) set in the config table and PHP can be attached to any page; extensions are checked (configuration key: files/blocked-extensions)
• Files with the extensions contained in the list of allowed image extensions (files/imagemagick-extensions) and are less than the maximum image size (max-image-size) generate thumbnails and are stored in the image gallery
• Files that are uploaded to a page in which a file with the same filename was deleted but not purged from the recycling bin, will be renamed, following {filename (#).extension} format (Example: “file.jpg” would become “file (1).jpg”)
• When files with the same filename are added, the files should be versioned together

Viewing

• Files table
  • All files should be listed in alphabetical order
  • Revisioned files should have a “+” icon which shows the other revisioned files
    • Revisioned files should not have an “Actions” menu
  • If a file extension is in $wgWriteViewer, $ wgCalcViewer, or $wgShowViewer, a “Preview” link shows up
    • Clicking this link will display a preview of the document using ThinkFree, if anonymous viewing of files is allowed (credentials are not passed along to ThinkFree)
• Images table
  • Images are shown in an NxN grid (defined by $wgGalleryRows and $wgGalleryCols) with pagination
  • All images may be shown
  • Images are sorted according to the “Order by…” select dropdown; by default, reverse chronological order
    • Selecting any of the other options should show the correct sort order
    • The correct sort order should be maintained when paginating through
  • Clicking an image launches the lightbox view, which navigates through the whole gallery, not just the 6 that are showing
  • Long filenames are truncated to prevent UI overflow
  • The original image can be viewed by clicking “View original image” in the Actions menu of the image
  • If revisions exist for an image, a + sign appears next to the filename; this and the “Previous Versions” in the Actions menu both will show all versions ofthe file in chronological order – from this view, clicking “Back to main gallery” or “View All” returns you to the image gallery
    • TOFIX: This seems slightly buggy right now

Editing

• Files & image description editing
  • From the “Actions” menu, the description of the file should be successfully saved (reload the page to make sure the changes took place)
    • If no description is set, then the file is defaulted to the “No description” message
    • Descriptions should be rendered in plain text – HTML text is allowed, but it should appear literally

Deleting/Restoring

• Deleting a file or image will remove it from the page and make it available in the recycling bin
• The “Recycling bin” from the Control Panel allows administrators the ability to restore files to their original pages
  • Clicking the file link should allow the administrator to see the file
  • Files that are restored should maintain all revisions and metadata (description)
  • Files that are restored to a deleted page should create a new page with placeholder text and not restore the deleted version

RSS Lists:

• Ensure that "What's new" and "My watchlist" RSS feeds are outputting data (see #3149)
  

Popular Pages:

• Should return the most popular $wgSpecialPagesCount pages - popularity is calculated based on views

Sitemap:

• Returns all pages in the main namespace in a hierarchical tree view
  • /sitemap.xml should return this list in the sitemap format
    
  • /sitemap.gz should return /sitemap.xml gzipped
    
• Permissions checks should be enforced on all pages