redimp / otterwiki Goto Github PK
View Code? Open in Web Editor NEWA minimalistic wiki powered by python, markdown and git.
Home Page: https://otterwiki.com
License: MIT License
A minimalistic wiki powered by python, markdown and git.
Home Page: https://otterwiki.com
License: MIT License
In v2.0.0-beta24 internal Wiki Links are converted to the
[Article Name}(/Article Name)
schema.
If the article name has a space in it the schema is broken. I think a valid approach would be to replace a space in the URL with "%20".
This is a problem for (at least) my use-case where JS is not always available in the visitors web browser.
Missing JS should not break basic functionality, it should be more like an icing on a cake (in my opinion)
There is something broken in the tests, the order of the tests excuted matters and must not.
e.g.
pytest tests/test_attachments.py tests/test_preferences.py
works fine (reference commit 98ead75)
but
pytest tests/test_preferences.py tests/test_attachments.py
fails.
Even using only one method from test_preferences.py
and one of test_attachmets.py
will make test_app_with_attachments
fail:
$ pytest tests/test_preferences.py tests/test_attachments.py -k 'test_admin_form or test_app_with_attachments'
...
platform darwin -- Python 3.10.7, pytest-7.1.3, pluggy-1.0.0
rootdir: /Users/redimp/projects/otterwiki
collected 10 items / 8 deselected / 2 selected
tests/test_preferences.py . [ 50%]
tests/test_attachments.py F [100%]
============================================== FAILURES ===============================================
______________________________________ test_app_with_attachments ______________________________________
test_client = <FlaskClient <Flask 'otterwiki.server'>>
def test_app_with_attachments(test_client):
response = test_client.get("/Test/view")
> assert response.status_code == 200
E assert 404 == 200
E + where 404 = <WrapperTestResponse streamed [404 NOT FOUND]>.status_code
tests/test_attachments.py:47: AssertionError
Is there a place in the interface the push the wiki to a git remote location? It would be cool if there was a "Push" or "Sync" feature. This could be very tricky if there are remote changes that conflict with local, but it would great to do this in the UI
It would be great to be able to navigate content via nested menus.
Initially it can just be 'parent/child' directory, according to how the pages are created.
Long term, one solution could be:
When creating a new page, select it's parent page and sort order.
If no parent page is defined, the page is considered top of the directory tree
Sort order field is numerical only. Sort order starts from 1 (0 reserved for home / root, at very top if tree). Form input is validated to numerics only. No upper numerical value for sort order.
If no sort order is specified, enter a default value of 1
Nav bar sorts parent --> child relationships first numerically, then alphabetically
Currently, the file structure is as follows:
attachment.xyz
for an article article.md
is located in article/attachment.xyz
in that root directory.For linking, we have the following:
[linktext](/article)
and even [linktext](/article.md)
[linktext](/article/a/attachment.xyz)
Ideally, I would like to be able to link stuff consistently with how linking would work if I were to view the same markdown files in a text editor that can handle markdown links I made the following observations:
[linktext](./article)
and even [linktext](./article.md)
, but this is broken in preview mode.[linktext](./article/a/attachment.xyz)
, but this is broken in preview mode, whereas [linktext](./a/attachment.xyz)
works but only in preview mode while previewing the article article
.[linktext](./article/attachment.xyz)
or [linktext](/article/attachment.xyz)
.(I hope that I didn't make any mistakes)
I suspect the reason for 1 (and the second part of 2) is that in preview mode, a relative path gets appended to the path of the article, which doesn't happen normally.
Also, filenames are automatically made lowercase in the underlying file structure, no matter the casing of the article name in the otterwiki viewer. I can imagine multiple reasons for this, but it might make linking stuff more confusing, since links could break when viewing the files in other markdown viewers that follow the link directly and are therefore case-sensitive. Also, where does otterwiki track how the casing is, if it can't see it in the filename? It seems weird to have extra metadata just for that.
So additionally to the preview bugs, I would personally heavily prefer it if links were made to be compatible with the file structure in a way that any other markdown viewer would handle it for relative paths.
Some thoughts:
article/a/
for each article and put attachments there? Or is that nonsensical?article
folder, and have the path name for the http request also as it currently is with /a/
in the path name, but at least have linking work with links with a relative pathname ./article/attachment
. The otterwiki viewer could just handle it however it likes, as long as the linking works.I just want it to be consistent with viewing the markdown files in other settings.
Attachments to a page should be accessible analogous to the file system.
e.g. Home
with the attachment example.jpg
.
Currently you get
/Home/a/example.jpg
the attachment/Home/t/example.jpg
a thumbnail of the attachment/Home/t/example.jpg/100
a resized (max 100x100) thumbnail of the attachmentProposed feature: You get
/Home/example.jpg
the attachment/Home/example.jpg?thumbnail
a thumbnail of the attachment/Home/example.jpg?thumbnail=100
a resized (max 100x100) thumbnail of the attachmentThis is follows one of the ideas in #39.
when the ß
character is in the middle of a word in a title (e.g. straße
), everything is fine, however, when it is in the beginning of a word of a title, (e.g. ßuper ding
, tolle ßau
), the links in the "A-Z" page capitalize it and convert it to an "Ss" (e.g. Ssuper Ding
, Tolle Ssau
), which breaks the link.
typing in the link by hand works of course.
what is the use case? well, it is not too important, but sometimes it is practical to clump batches of articles together in seperate "categories", so that the "A-Z" page doesn't clutter up, for example "Meeting 2022-11-14" and so on. this is done by using a special symbol at the beginning so that they get sorted after all of the letters. so the titles would be "ß Meeting 2022-11-14" and so on.
this is not very important, we found other special characters like the euro symbol etc, but this is how we found this glitch.
To make the initial app empty app a bit more 'friendly' I think rather than displaying the 404 (which, is quite nice actually), there should be a boilerplate home page. Maybe it can incorporate a bit of the markup guide + an edit button. Just an idea! Feel free to reject it.
As I've been using the wiki, I'm still finding it a bit tricky to get around. There is the alphabetized listing of articles, which is helpful, but I wonder if something more akin to a Table of Contents page would be helpful. This would traverse the created pages (including sub folders) and come up with a hierarchical view.
I have a prototype for this, it includes looking in sub directories and specifying depth. This page would have a slight leg up on the A-Z view, as once sub folder are in and the user starts organizing the wiki, that organization would be clear to see in this view. I will push a PR for you to look at.
It would be handy to use [[egg]]
in certain places without getting replaced by a link. The Wikipedia handles the situation by using HTML encodings of [
([
). That already works except when used inside code, e.g. `[[foo]]`
. Probably the same problem with triple ticks.
A possible solution might be to write a lexer for mistune or use a Renderer as described on the mistune README.
Currently there is no manual (apart from the markdown syntax guide) in the app.
Adding a manual available via the "three dot" menu on the navbar.
The manual should be include at least a "User" and an "Admin" Section. The "Markdown Guide" should be part of it, too.
If you write <script>alert(1)</script> on a site in the wiki it doesn't get escaped. And is executed on viewing of the page.
I expected it to get escaped or at least the site content loaded into a sandboxed iframe.
Is escape=False really necessary for the function of the wiki?
so far, no email is sent after a user has been approved. this would be a nice feature
Title explains it, pretty much. This is useful for pages like the home page that you don't really want random people editing, but you want the rest of the wiki to be editable by other people.
Hello!
No bugs to report, just a friendly heads up that the word "software" is an uncountable noun, so there cannot be "a software" or several "softwares". Correct wording would be:
An Otter Wiki is Python-based software for collaborative content management, called a wiki.
Hello! I was curious if you had a plan to implement sub-directories/folders. I'd be happy to work on this. This morning I actually dove in to come up with a structure that could work:
This will yield:
respoitory/
home.md
a_folder/
a_folder.md
Navigating to the URL of /a_folder
will yield /a_folder/a_folder.md
(kind of like it's index.html page). This works from some simple matching logic to check if the pagepath you're trying to access is a folder or a page. This moves the 'storage' checking aspect upfront (before crafting the paths on disk).
Let me know if you'd like me to proceed with a PR.
at the moment, the head title of every page reads the wiki page name, and then "An Otter Wiki". it would be nice to have SITE_NAME
as in app-data/settings.cfg
there instead.
I'd like to be able to find and replace text from within the editor.
sed -i '#^${EV}.*#d' ${OTTERWIKI_SETTINGS}
The '
has to be a double quote "
I feel like given the way some of these types of apps function there are a few design patterns that could be used. Here are some ideas:
Let me know how you like these changes and I will issue a PR
The editor should (auto) save drafts while editing a page.
Notes:
As discussed in #60.
The wiki should display a warning, in case the user has edited the page, is either in the Editor or on the Preview Page and would discard the changes when naviating away from there.
Reported in #60.
When following the readme to deploy to docker, the docker container stops with this error:
otterwiki-web-1 | /usr/bin/env: ‘bash\r’: No such file or directory
... I suspect it has to do with the #! /usr/bin/env bash
at the top of docker-entrypoint.sh on windows.
it might be useful to have read only access for some users and read and write access for some other users.
currently, it is only possible to differentiate between users via being unregistered (anonymous user), registered, approved, and admin. i want to have the wiki be hidden from public, i.e. not give read access to anonymous users, give all approved users read rights, and some users additionally write access. currently, this is only possible by making the latter group of users admins.
it is not an option for me to make registered users have read access and approved users have write access, as anyone could instantly circumvent this by registering. i want to manually approve who can see, and manually approve who can write.
currently, our setup is that we have http authentication (.htpasswd
).
Really loving otter wiki! It's super simple, which I appreciate. I have a list of "quality of life" features if you're open to PRs 😀
I've found it's somewhat arduous to create a new wiki page. It take 3 clicks steps (name of page, add content, add commit message). I think a really good model for how to do this is how GitHub does it. They have all these things on one page. When you go to submit, if that page exists, it will return this message:
I have a handful of other ideas. Should I submit additional issues (I'm happy to work on this, and other enhancements)?
Just clicking the search bar and pressing enter causes Error 500.
With pip 22.3 you get the warning
DEPRECATION: htmlmin is being installed using the legacy 'setup.py install' method,
because it does not have a 'pyproject.toml' and the 'wheel' package is not installed.
pip 23.1 will enforce this behaviour change. A possible replacement is to enable the
'--use-pep517' option. Discussion can be found at https://github.com/pypa/pip/issues/855
We could install wheel
with the pip upgrade in the make venv
step of the Makefile
, but this feels lazy. Will switch to pyproject.toml
.
I'm having an issue on my docker instance of the current version of OtterWiki, where the linked URI elements that are entered with header links, do not jump down the page when clicked. They also can't be auto scrolled to when using the #whatever at the end of the URL.
I can sort of cludge this to work by using a "#:~:text=" and then entering the text I'm trying to jump to, but that's a lot less elegant and doesn't fix the sidebar "on this page" links.
From the things I've tried, by forcing a div id/class on a section, it hasn't worked.
Seems like if you delete a page, the attachments should also get deleted, as that page is the access point for those attachments.
If you edit a page on mobile, go to a random line and delete each character from that line, you cannot use the backspace to delete the line itself.
The "blame" functionality should work similar to the one of git
.
Within the code space, in order to execute latex code, two options are available:
```math
$x=\frac{-b\pm \sqrt{b^2-4ac}}{sa}$
```
for
However, other markdown setups can generate the above code without the singe or triple ticks marks. I was wondering, is it posible to have the Markdown logic expand to include latex without requiring tick marks?
Hello, when I clone the repo, it appears the tests are failing. I'm not sure if this is to be expected or not. The short output is below:
========================================================================================== test session starts ===========================================================================================
platform darwin -- Python 3.8.2, pytest-7.1.3, pluggy-1.0.0
rootdir: /Users/marcleonard/Desktop/otter-o
collected 93 items
tests/test_attachments.py ..... [ 5%]
tests/test_auth.py ............F........... [ 31%]
tests/test_essentials.py .... [ 35%]
tests/test_gitstorage.py ................. [ 53%]
tests/test_helper.py ... [ 56%]
tests/test_otterwiki.py .....F.... [ 67%]
tests/test_preferences.py FFFFF [ 73%]
tests/test_preview.py ... [ 76%]
tests/test_renderer.py ........F [ 86%]
tests/test_util.py ............. [100%]
When a user renames an attachment, the existing links in the pages should be updated with the same commit.
Reported in #60.
I am attempting to use a custom site logo and it does not seem to work even though I think I have the configuration correct. I even attempted to make sure it wasn't a permissions issue and made the owner and group of the image file the same user as all the other files in the app-data directory.
There screenshots are from after I saved the configuration. The original site logo disappeared but the one I'm trying to use does not appear.
Suggestions?
If I enter a title like "NAS Setup" on the Create page and click "Create and open in editor" the title gets changed to "Nas Setup", which is incorrect case because it's an acronym and should remain all upper case.
I assume this is because the somethings is trying to give what is seen as "proper" case to the page title but IMO it should not be making this decision for the users. As seen above there are cases where the title may have acronyms or for other reasons the user does not want Pascal Case for the title.
It is not possible to change ones own display name. This should be possible, as everything is managed via git, and git should support that, as users are identified via email address. It would be a nice feature.
How the switching between Editor
and Preview
currenlty works is far from perfect. I would like to change that in a way like it works in e.g. github. This would solve the issue with loosing the Undo/Redo history as well.
As discussed in #60.
I encountered a glitch (or maybe it is intended):
If I name a page "ABCDEFG", it gets renamed as "Abcdefg".
I ran into an interesting situation. I was moved some .md files from an old repo into my current dev repo, and when trying to navigate to the page I was confronted with a 404. I chased it down the debugger and realized it's because it had not been added under version control (which makes sense why it would fail). Since it was able to load the page just fine from the filesystem (before it raised an exception from git), I was thinking we could add a warning like this:
Let me know what you think! Happy to submit a PR! I could see this being a useful feature if you are haphazardly throwing .md files in your repo folder.
when using the history feature to show an older revision, it still shows the most up to date commit. the url clearly shows, that an older revision should be served, e.g. ?revision=d584ac
is added to the url, but the content is not correct
the comparison feature works as intended and shows the diff.
A declarative, efficient, and flexible JavaScript library for building user interfaces.
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google ❤️ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.