Feedback on 3.0.0

[cromelex]

Just wanted to provide some feedback on the usability and look of the pages for 3.0.0.

Overall, this looks really good.

I do have a few points/suggestions:

1. The default page now seems to be an auto generated "Latest" rather than the previous home.md. Would like to be able to set a default page instead, as per previous behaviour. If not "home.me" then "index.md".

2. The navigation bar/file tree shows the filenames with extension. In my opinion you should overwrite this with the note's title: property

3. The date being shown under each note is nice (as is the tag), but I assume it's being derived from the upload date?
   I haven't tried yet, but can it be overridden by a date: property? And can it be hidden/blank by setting the property to something specific?
   I'd like to publish some notes where it absolutely makes sense to have a date, but for a "Home" or "About me" kind of section, it would look better not to have any date.

[cromelex]

I am seeing some weird behaviour on a list with inline italics. The italics line always gets placed in a separate line. Seeing this in multiple places.

Sample .md

## Kyoto

### 15

- 10.30am Train to Kyoto
- Himeji (*optional, to be decided*)

Here for github rendering

Kyoto

15

• 10.30am Train to Kyoto
• Himeji (optional, to be decided)

markopolis rendering

[cromelex]

After doing some more testing, I grabbed a couple of screenshots of the same .md put through markopolis and obsidian-webpage export just to compare.
Markopolis is looking really neat straight away. The use of space for wider content is working really well (compare the mermaid timeline).

If anything, the only suggestion I would have is to add back the outline/table of contents (ideally make it optional), as for longer pages/content it will help with navigation.

Thanks!

[rishikanthc]

Thank you so much for your feedback. Really appreciate them. I can fix the issues you raised. As of now you are right in that the date shown is the date uploaded and currently there's no way to override it. Tbh the date in the frontmatter is not considered at all even though it's available and stored. So that's an easy fix. I can revert to the home page too and the titles in the fileTree. The real reason I removed ToC was I didn't know where to lay it on the screen. It looked ugly dangling on it's own. I guess I can make it available as a togglable pane like the tag explorer. Feel free to let me know if you have any other suggestions for the ToC UI.
I'll push a patch later this week addressing these. I have jumped major versions too many too fast now. Now that I'm set and satisfied with the core architecture of the app, I can spend some time to fix UX before doing new features.

[cromelex]

The real reason I removed ToC was I didn't know where to lay it on the screen. It looked ugly dangling on it's own. I guess I can make it available as a togglable pane like the tag explorer. Feel free to let me know if you have any other suggestions for the ToC UI.

Yes, I think a togglable pane is the best option. All you need is a button, and in terms of appearance what you had in 0.x.x was absolutely fine. Just a simple outline with all the (clickable) headings.

I have jumped major versions too many too fast now. Now that I'm set and satisfied with the core architecture of the app, I can spend some time to fix UX before doing new features.

I think you have a solid base to work from now.

Take your time and look at what your roadmap.
If you intend to add customisation down the line, have a think about how to integrate the UI changes and what you might want to allow changes on (if at all)

ie,

• tag explorer:
  • show
    • start collapsed
    • start expanded
  • don't Show
• table of contents
  • show
    • start collapsed
    • start expanded
  • don't Show
• graph view (from the roadmap)
  • show
  • don't Show

etc. That might make it a bit easier to handle further down the line.

Also, please find below some additional issues that I spotted in the meantime.

• 3.0.0 ignores the publish:false property. The note is getting published regardless of the property being false or missing entirely.

---

• link alias is not working.
  (To be fair I have not seen this mentioned as a feature, but relative path linking in Obsidian uses this feature.)

  • On my home.md I have a link that reads [[about me|cromelex]], which would display cromelex but link to about me.md. The link works correctly, but markopolis is rendering about me|cromelex on the page.

  • The same happens with links to items in subfolders. My home.md links to blog/test.md as [[blog/test|test]], which would display test. But markopolis is rendering blog/test|test

Folder structure if you want to try and replicate.

├── about me.md
├── blog
│   └── test.md
├── home.md

---

• On a note without the title: property, I think a / in a link is messing up the page title/backlink.

my ideas.md contains:

- [[home]]
- [[blog/test]]
- [[blog/123]]

The title is being rendered as 123]]. Backlinks are then showing 123]] but the links work. So there is something with that / impacting the title if the title: property is non-existing.

---

• separately, I had an issue where uploading blog/test.md was failing every time until I added a title: property.
  Not sure why, other than the fact that it is in a subfolder (and that it was being linked to by other notes).
  The note only had a couple of words test abc 123 so I don't think it was content related.
  As soon as I added the title: property the upload worked.

Console error was
Error in upload API: Error: File metadata with url is missing.
at transformer (file:///app/build/server/chunks/_server.ts-DrfCyMwa.js:1161:13)
at wrapped (file:///app/node_modules/mdsvex/dist/main.mjs:180:19)
at next (file:///app/node_modules/mdsvex/dist/main.mjs:275:26)
at done (file:///app/node_modules/mdsvex/dist/main.mjs:210:16)
at then (file:///app/node_modules/mdsvex/dist/main.mjs:217:5)
at wrapped (file:///app/node_modules/mdsvex/dist/main.mjs:200:9)
at next (file:///app/node_modules/mdsvex/dist/main.mjs:275:26)
at done (file:///app/node_modules/mdsvex/dist/main.mjs:210:16)
at then (file:///app/node_modules/mdsvex/dist/main.mjs:217:5)
at wrapped (file:///app/node_modules/mdsvex/dist/main.mjs:200:9)

[rishikanthc]

Lol I completely missed the publish: true setup. In the rewrite I did not implement the logic for checking if publish is set to true. I'll implement this.

Regarding the title: property I'm not sure I'm understanding this correctly. so you have a note within the blog folder called 123.md and when it's being rendered the page title and the backlinks show up as 123]] ? I'm not understanding what issue the / is causing here.. Could you elaborate a bit more ? I'm a little confused and not understanding this correctly sorry xD

For the upload yes, if you don't add a title: property in your frontmatter it will fail. As currently the upload logic explicitly looks for a title in the frontmatter to extract and reference it in the database and there's no error handling in that flow, so if you don't have a title then it's going to throw an error. Think the easiest way to handle this is to default the title to the filename if it's not explicitly set in the frontmatter.

Once again thanks a tonne mate for the feedback !! Your interest in this project and your thorough feedback on the various aspects of it makes me so happy and is a big encouragement to contribute more to it. Appreciate it a lot :)

[cromelex]

Regarding the title: property I'm not sure I'm understanding this correctly. so you have a note within the blog folder called 123.md and when it's being rendered the page title and the backlinks show up as 123]] ? I'm not understanding what issue the / is causing here.. Could you elaborate a bit more ? I'm a little confused and not understanding this correctly sorry xD

ideas.md is the note that I uploaded, without title. It got uploaded successfully, despite not having a title property.
This note contains a link to folder blog/123.md, so basically the last line on ideas.md was [[blog/123]].

ideas.md was showing up with the title 123]], and backlinks to ideas.md were showing as 123]]. They still worked

Based on what you said below, this should be failing to upload as the note doesn't even have a title.
If the title property is populated this doesn't happen.

Not a big deal, but it leads me to believe it's messing with the upload logic?

For the upload yes, if you don't add a title: property in your frontmatter it will fail. As currently the upload logic explicitly looks for a title in the frontmatter to extract and reference it in the database and there's no error handling in that flow, so if you don't have a title then it's going to throw an error. Think the easiest way to handle this is to default the title to the filename if it's not explicitly set in the frontmatter.

Think that's a sensible approach.

Once again thanks a tonne mate for the feedback !! Your interest in this project and your thorough feedback on the various aspects of it makes me so happy and is a big encouragement to contribute more to it. Appreciate it a lot :)

You're welcome!
I can't/don't code, so feedback is the help I can give.
This is still the most straightforward way to publish .md I've seen (for someone who is already using docker). I am currently using Obsidian, but I don't have to (I can take my .md to any other app), and I'd rather use something to publish that is similarly source agnostic.

[rishikanthc]

1. The default page now seems to be an auto generated "Latest" rather than the previous home.md. Would like to be able to set a default page instead, as per previous behaviour. If not "home.me" then "index.md".
2. The navigation bar/file tree shows the filenames with extension. In my opinion you should overwrite this with the note's title: property
3. The date being shown under each note is nice (as is the tag), but I assume it's being derived from the upload date?
   I haven't tried yet, but can it be overridden by a date: property? And can it be hidden/blank by setting the property to something specific?
   I'd like to publish some notes where it absolutely makes sense to have a date, but for a "Home" or "About me" kind of section, it would look better not to have any date.

Just pushed 3.0.1 which fixes these. The markopolis cli python package has also been updated to 3.0.1 which now respects publish. Now the default behavior is to publish all markdown. You override by setting publish: false to exclude files from being published.

You can override dates with values in your frontmatter and dates are now optional. Not including one in the frontmatter will simply not show a date on the page.

docker images are being pushed as I type :) Let me know if you face any issues.

[cromelex]

Currently away for a couple of weeks but once I get the chance I will test and provide feedback.

Thanks for the update!

[cromelex]

Ok finally had the time to test 3.0.1 today.

publish: is working
navigation bar/file tree is showing the title: as expected

date: is working but formatting looks a bit weird to me.
I tested with date: 2024-10-01 and this works, populates a date when present and omits otherwise. However, it renders as a full date with time and all 2024-10-01T00:00:00.000Z. Is this expected or just to do with how you've set the format?

Thanks for the update, these minor fixes really enhance the usability for this.

[rishikanthc]

That's just the default format in which timestamps are stored. I can change that to show only the date.
Also I released 3.0.2 earlier this week which fixes even more quirks. Do check it out :)

[cromelex]

I've seen that, and I'm currently trying it out!

That's some clear progress, I think you've closed out the majority of the open items.

To sum it up, I'm currently only seeing the 2 following issues:

• date format (timestamp format)
• wikilink aliasing not working (ie, [[foo|bar]] is expected to link to foo.md and display bar)

Otherwise, in functional terms, pretty much everything I've checked seems to be working. I'll report back with any other findings.

[cromelex]

Following up from the above, there's a few more quirks on the wikilink aliasing. If I have a test.md with title: "this is a test", but create a link as [[test]], then it will be displayed as "test" regardless.

Not sure if you want to implement some logic to allow the link to be rendered based on the title. However, if you implement aliasing (ie, [[foo|bar]] is expected to link to foo.md and display bar) then it's easy to workaround this.

[cromelex]

Separate note, you might want to reimplement the "latest" tag for the docker images. At the moment people will have to specify the image version, meaning the sample docker compose wouldn't work, for example.

[rishikanthc]

Good point. I'll do that. At this point I'll probably set up a GitHub actions.

[cromelex]

Hi rishikanthc, I have a couple more random suggestions.

In the example docker compose, I think the 8080 port should be removed, or at least marked optional. As far as I can see it's only needed if someone wants to access the pocketbase ui directly. I don't think there's any reason for most users to use it. It's not required to be exposed to allow the container to works. Exposing it only decreases security in case someone doesn't change the sample passwords.

Secondly, whenever I restart the container (which I did a few times as I was trying a few things on my VPS), Markopolis always seems to go through the rebuild process again. This was killing my low powered vps until I put in some resource limits in the docker compose.

I am just wondering if whatever is being "built" is being stored in temporary storage? Is there a way to optimise this so it is stored in a volume so as not to get erased with every restart, just to avoid this?
Thanks

[rishikanthc]

Point well taken. I'll remove that.
About the build part yes it can definitely be optimized. I'm working on a new release that irons out this.
I'll be releasing a new version sometime tomorrow or today. Will introduce some new features and it should be more polished than all other releases so far.
Svelte 5 released so I had to migrate the entire project from svelte 4 to 5 and in that process I was able to optimize a lot of things about the app.
The new version should be significantly faster to use and overall provide a much more polished and smooth user experience.
I have also made sure to check all issues you have made so far are resolved.
Really excited for this release and looking forward to your feedback :)