About The Website/To Do
This page contains a list of proposed or needed, features or bug fixes, which will or should be added to the wiki engine used by this site.
If you are not part of the team developing this website engine, please limit yourself to editing only the "proposed issues" section.
If you discover issues which could negatively impact the security or performance of this website please do not post them here. Contact the webmaster privately instead, as a gesture of courtesy towards SourceForge, who provides us with free hosting.
- 1 Proposed issues
- 2 Content issues
- 3 Code issues
- 2 Content issues
Feel free to post issues that you think should be improved, and add whatever details you feel necessary. Add a short and to-the-point description for every issue.
Do not edit this section unless you're a website maintainer. Otherwise, add your issues to the "proposed" section above.
- Create a KnownIssues? page, documenting the negative issues currently affecting Blackbox.
- Create a dedicated screenshot gallery, featuring hand-picked shots meant to show off the Blackbox environment (not eye candy). Perhaps make it into a graphical tour of Blackbox, like we had on the old site.
- Salvage what still applies from the old FAQ, talk to the maintainer about linking to the new FAQ, and link back to it for the benefit of people still using older versions.
- Several documentation sections still need content.
Only edit this section if you are part of the development team, please.
It would be useful to have an intuitive and at the same time very simple system to signal related pages, that will allow users to implement relations via a macro and which could be used to create automated "See also:" compilations.
- On edit pages, offer a text field containing a comma-separated list of page titles.
- Upon save, added or deleted pages cause adjustments of inter-page links in a dedicated many-to-many db table. Each added/deleted page will cause 2 links to be added/deleted: both to and from that page and the current one.
- PROBLEM: these modifications cannot be tracked by the normal wiki history/diffs system, since it does not operate on page text.
- Do not care about tracking relation modifications. (Bad idea).
- Add a "ghost" watermark to the current page text, marking the new page list only for the current page.
Possible implementation: [[RelatedTo pagename1, pagename2, ...]] macro which establishes the relation, and a [[SeeAlso]] macro which collects the relations, sorts them alphabetically and displays them. The collecting would have to be recursive, which is where the page cache could really help. This is different from the classical wiki (and 'Tavi) implementation in that it doesn't require the existance of "page categories" which define the "category" as a really obscure concept with no centralized administrator interface.
- Bug: Page A is saved with a link to a yet non-existant page B, and renders the link as "wanted". Page B is created. Page A still shows the link as "wanted", because it uses the cached version. Solution: when saving a page, parse the link table for pages linking to it and delete their cached copies, to force regeneration.
- Decrease headings: change the meaning of heading markers so that they signal +1 headings (ie. = means H2). This will be more intuitive for users. But we'll also have to run a one-time temporary script that parses all page contents and changes == to =, === to == and so on.
- When there's only one heading on a page, instruct the contents table renderer to NOT add numbers to the table and to the headings.
- No matter if we have [[ContentsTable]], still add anchors automatically to all headings. This way we can forever dispense of the need to add [[Anchor]]'s by hand, and the contents tables and references from outside the wiki will be kept in sync and valid.
- Bugfix: a [[ContentsTable]] for a heading that starts above 2 (ie 3+) will produce 0.1 numbering.
- Bugfix: [[Anchor]]'s inside headings are discarded when a contents table is in effect, why?