docelic / fluence Goto Github PK

When a directory contains pages, it appears as a non-clickable folder in the index.
But when it is empty, then it appears as an empty page.

Code should be changed so that empty directories get transparently removed.

The wiki already supports internal links via [[page]].

This model should be made more prominent and useful within the whole user interface.

(E.g. below the ToC there could be 3 lists -- one as a collection of links to internal pages, one as a collection of external links, and one as a collection of referenced files from the internal media library)

When support for layout placeholder is added, use them to put 'var uploader =' from show.slang in them, and dump those contents before the closing body tag.

Also, above it, put all the inscrybmde includes that should be moved from the top of application layout to there.

Currently, index is read from file ./meta/index.

On Wiki startup, there should be options to rebuild the index and/or check information for freshness.

(For example, actions made by users writing files directly on the filesystem should be visible in the Index after restart, such as adding and deleting pages, or modifying pages and affecting the list of internal links.)

It seems InscrybMDE (and most probably SimpleMDE) render ordered lists with bullets, instead of increasing numbers.

Currently we have options like "Edit" and "Rename" visible in the menu on the right of the page content.

These options should either be properly styled, or even moved into some sort of a clickable menu.

On show.slang, allow sending a parameter which says whether the editor should be initialized in edit or preview mode.

Links pointing to edit mode should be used by default for pages which do not exist.

Maybe also upon Save as well if the editor was in Edit mode when Save was clicked.

We should add the ability to automatically upload media to a web-accessible location and insert a link to it in the wiki page, and/or to be able to insert links to any media already existing/uploaded to the media gallery.

Currently, pages /sitemap and /mediamap show hierarchies of wiki pages and any of their attached media.

Maybe it would make sense to join the two pages in one.

E.g. so that /sitemap is a split screen showing wiki pages in the left pane, and media files in the right pane.

Alternatively, media files could appear directly under the entries in the sitemap, under the individual wiki pages to which they are attached.

In sitemap, shown on the left of every page, the display of pages and subpages should be adjusted.

If a page has subpages, two things should be done:

1. There should be only one entry for the main page, instead of currently existing one entry for the page, and one for its directory which contains subpages

2. The ordering should be such that pages and its subpages are listed first (before listing further pages), instead of all pages first and all directories second

Currently, logging in with a non-existent username results in an application error in Kemal, rather than being gracefully handled within the application.

This should be handled in the same way how a username/password mismatch is reported to the user.

All operations in the wiki should be reviewed to use Index and its processed/prepared information instead of actual filesystem acces.

Also, as part of this, the FileTree class should be completely removed and replaced with Index..

When media support is added (#2), the existing search function should be updated to include media files in the search.

If FileTree is used for search, this might even work automatically since both pages/ and media/ are found under Fluence::OPTIONS.basedir, which if I am correct, is the basis for search.

In the inherited view files there are a number of visual misalignment, misspellings and grammar bugs. We should fix those as we see or scan for them.

Fluence works, but the tests are failing due to old/unupdated test code.

Make hardcoded values like prefix = "/pages" configurable via config/application.cr

When an existing page is moved to a new location, internal links need to be rewritten to the new location.
This comes down to finding matching internal links in the on-disk pages and modifying them.

Some buttons should not be visible when in preview mode.

The most obvious example is the "Save" button currently seen below the page even when the page is in preview / non-edit mode.

Registered users should be able to have a "profile" and own settings.

Examples of settings to configure per-user would be:

• Use edit or view mode by default
• Use fullscreen and/or side-by-side by default
• Autosave interval
• Color scheme

It is possible to edit wiki files directly on the filesystem.

Add a file watcher like:
https://github.com/Sauilitired/FileServer/blob/master/src/file_server.cr

And rebuild/update index etc. as necessary.

Currently the ToC does not work as a consequence of moving from Index of Index::Entries to Index of Pages.

We should change the toolbar icons depending on whether the page is in edit or preview mode.

Two things should be done here:

1. Figure out if there is a way to immediately open the editor in preview mode. (Currently we do this by manually invoking togglePreview() after the editor has initialized itself in edit mode)

2. Figure out if the editor can be configured to automatically change the icons based on mode.

If it can't be configured to automatically change, then we need to implement it ourselves:

First we should see whether Inscryb/inscryb-markdown-editor#17 is a bug or not. That is, whether we can easily test whether the editor is in preview mode or not.

Then, one option (possibly not very favorable) would be to destroy the toolbar and create it anew with different icons when mode is changed. We have a prototype of this working, but it currently does not properly create a toolbar when editor is in full screen mode (this is probably another bug in SimpleMDE/InscrybMDE).

Another option (not tested yet) would be to modify the toolbarComponents array to take out and bring back individual icons when mode is changed. Hopefully the editor.render() method would work correctly and we'd have no other work than just adding or removing toolbar objects from that array.

This is a lower priority task, but at some point we should add I18n support.

Available options are:

https://github.com/akzhan/crystal-cldr
https://github.com/olbat/icu.cr
https://github.com/TechMagister/i18n.cr (and related https://github.com/TechMagister/kemalyst-i18n)

@imdrasil has done some work on I18n, we should check if something new can be found in the list of his repositories.

Also people interested in this should read amberframework/amber#56 for general introduction to I18n challenges in Crystal projects.

Decide whether it would be useful to open new pages in edit mode by default, while existing pages would open in preview by default.

Currently, when a person visits a nonexistent page, if they have permissions to create pages, then they are presented with a notice that the page does not exist yet, and an empty page body. From there, if they really wanted to create a new page, they could enter Edit mode, type in page content, and click Save.

This change would make it so that new pages are open in Edit mode automatically, saving a click.

A potential drawback is that if a person was actually looking for an existing page and not intending to create a new one, then not only would they be informed that the page does not exist, but they would also find themselves in Edit mode, which may be even further from what they originally intended.

It would probably make sense to just save the desired behavior as a user preference.

• If user has no permission to edit page, don't open Edit mode
• Similarly, don't show file upload functionality

In addition to page titles, internally we also convert titles to slugs which can be used in URLs.

So, with a page title "My Page Title", this page could theoretically also be accessible via an URL /titles/my_page_title.

There is an idea that in such case, if multiple pages are found, we could concatenate their contents.

For example, if a team of 5 people all create a page named /USERNAME/calendar, then visiting /titles/calendar would combine the pages and display all 5 calendars at once.

Comments welcome.

Currently, everything that says "# ... " gets parsed as a heading, even if it is found inside code or blockquote blocks.

This should be fixed.

Searching in file contents could be done by e.g. using a grep-like approach, or to use a database like ElasticSearch for search.

In the spirit of using files (which we currently do), probably grep would be more in tune with what users would expect from a file-based wiki.

Comments welcome.

Please provide your comments as to whether you prefer Fluence to keep using file-based storage versioned using Git (like it does now), or we should switch to a database-powered model.

Currently, in pages_controller 2 lines of code have been commented, which would otherwise delete a page when it is saved with empty content.

Whether saving a page with empty content should mean a request for deletion should be added to user preferences, and then delete or not based on that.

1. Show newly attached files in the list dynamically, without having to reload page to see them
2. Re-style the current ol/li list of attachments and add Download and Delete buttons to each entry
3. Download option should sent Content-Disposition: attachment; in the response header

Currently, Page objects are pretty much disposable. One mostly creates them just to convert a page name into a Page object and then access page-specific functions.

We need to change this so that these objects can also be non-disposable and contain the complete page content in them. Then, PAGES index would be a collection of pages all of which have the content embedded and don't require disk access.