hugo/bDS
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

chore: reformat for better visibility

Browse Source
This commit is contained in:
hugo
2026-02-13 22:14:53 +01:00
parent 99f05418d0
commit 7240bae3ec
1 changed files with 287 additions and 222 deletions
Download Patch File Download Diff File Expand all files Collapse all files

509
VISION.md
View File

@@ -1,312 +1,377 @@
# blogging Desktop Server
Back in the day I had a tool named Python Desktop Server that was a self-contained blogging engine with
an integrated webserver and database that allowed management of blog posts in an easy local way and a
sync to a cloud system for syncing data and also rendering the full blog.
Back in the day I had a tool named Python Desktop Server that was a
self-contained blogging engine with an integrated webserver and database that
allowed management of blog posts in an easy local way and a sync to a cloud
system for syncing data and also rendering the full blog.
## Main Vision
create a electron app in this folder that uses typescript for all the logic code and sqlite and a proper
database framework around it for local storage of data. The UI should be aligned with the UI patterns
used by vscode. The name of the application is "blogging Desktop Server" and the shortname is bDS. Startwith
default layout for edit and view menues and things like that. I don't want the app to use raw SQL, I want some
proper layer between those and proper wiring where all actual functional code is kept in engine classes and the
UI realy just does presentation and reacts to state changes properly, so that long-running processes can
properly integrate as async tasks.
create a electron app in this folder that uses typescript for all the logic code
and sqlite and a proper database framework around it for local storage of data.
The UI should be aligned with the UI patterns used by vscode. The name of the
application is "blogging Desktop Server" and the shortname is bDS. Startwith
default layout for edit and view menues and things like that. I don't want the
app to use raw SQL, I want some proper layer between those and proper wiring
where all actual functional code is kept in engine classes and the UI realy
just does presentation and reacts to state changes properly, so that
long-running processes can properly integrate as async tasks.
The main area of the window must be a tabbled view, where multiple tabs can be open at the same time and are
retained over program runs. The tabs can be different tabs like media file tabs, post tabs for multiple
posts and setting tabs or whatever will come later.
The main area of the window must be a tabbled view, where multiple tabs can be
open at the same time and are retained over program runs. The tabs can be
different tabs like media file tabs, post tabs for multiple posts and setting
tabs or whatever will come later.
Blog post metadata should be managed in the SQLite database in the user local folder, so it persists
application runs properly. for blog posts, create a subfolder /posts/ there where each post is stored as a
markdown file with a properties segment in the top of the file with YAML like property definitions, so all
metadata can always be reconstructed from posts. Do the same with images, keeping them in /media/ under the
user local path, in that case storing the image file sand for each image file a properties sidecar file that
uses the same header structure as for posts.
Blog post metadata should be managed in the SQLite database in the user local
folder, so it persists application runs properly. for blog posts, create a
subfolder /posts/ there where each post is stored as a markdown file with a
properties segment in the top of the file with YAML like property definitions,
so all metadata can always be reconstructed from posts. Do the same with images,
keeping them in /media/ under the user local path, in that case storing the
image file sand for each image file a properties sidecar file that uses the same
header structure as for posts.
The application must be offline-first, everything must work in airplane mode (except exporting / AI of course).
It must be fully self-contained during editing and previewing and managing content. Every internal structure
must have reflections in the filesystem, so available tags, available categories, all those things must be
automatically reflected to the filesystem in a per-project way. Use a meta/ folder under the project folder
for those files.
The application must be offline-first, everything must work in airplane mode
(except exporting / AI of course). It must be fully self-contained during
editing and previewing and managing content. Every internal structure must have
reflections in the filesystem, so available tags, available categories, all
those things must be automatically reflected to the filesystem in a per-project
way. Use a meta/ folder under the project folder for those files.
There should be good cloud-storage based syncing that can be triggered when online again and should use
asynchronous syncing with auto-resolving of issues. The solution should be end-user friendly and not
too technical in setup.
There should be good cloud-storage based syncing that can be triggered when
online again and should use asynchronous syncing with auto-resolving of issues.
The solution should be end-user friendly and not too technical in setup.
The application must be able to support multiple projects (ie web sites), so there must be a way to create
new projects and select current project. The UI is only showing all data of the current selected project and
all tools are only working against the selected project. I can imagine that projects will be separate
databases and folders for post and media.
The application must be able to support multiple projects (ie web sites), so
there must be a way to create new projects and select current project. The UI is
only showing all data of the current selected project and all tools are only
working against the selected project. I can imagine that projects will be
separate databases and folders for post and media.
I want proper full-text search for posts based on the integrated sqlite database using fts5, so that I can
quickly find posts. So build proper text search index update into the core model right away, so that
regardless how posts come into the system, they are always properly indexed.
I want proper full-text search for posts based on the integrated sqlite
database using fts5, so that I can quickly find posts. So build proper text
search index update into the core model right away, so that regardless how posts
come into the system, they are always properly indexed.
Additionally bring in a good markdown library, because all posts will be formatted in markdown for easy
portability to future systems. Media files can be attached to posts and can be referenced with standard
markdown notation with a post-relative path, so it is easy for the user to include images. The post editor
should support both a wysiwyg editor and raw markdown editor, so the user does not have to know markdown,
but everything is handled by the editor, but for complex parts, markdown is available for power users.
Additionally bring in a good markdown library, because all posts will be
formatted in markdown for easy portability to future systems. Media files can be
attached to posts and can be referenced with standard markdown notation with a
post-relative path, so it is easy for the user to include images. The post
editor should support both a wysiwyg editor and raw markdown editor, so the user
does not have to know markdown, but everything is handled by the editor, but for
complex parts, markdown is available for power users.
Integrate toasts as notification mechanism that will be used whenever anything has to communicate success/failure to the user.
Integrate toasts as notification mechanism that will be used whenever anything
has to communicate success/failure to the user.
Integrated images in posts should be shown with a lightbox effect als galleries when there are multiple
photos, or just as single images with lightbox when there is only one. The wysiwyg editor should support
this at least on a basic level.
Integrated images in posts should be shown with a lightbox effect als galleries
when there are multiple photos, or just as single images with lightbox when
there is only one. The wysiwyg editor should support this at least on a basic
level.
## Posting life-cycle
New posts start in draft state. Drafts are automatically saved in the background, but the draft content is
not directly part of the publishing pipeline. A user can discard a draft, which either deltes a new post
or reverts a post that is edited to the last published state.
New posts start in draft state. Drafts are automatically saved in the
background, but the draft content is not directly part of the publishing
pipeline. A user can discard a draft, which either deltes a new post or reverts
a post that is edited to the last published state.
A user can publish a post, that moves the content from the draft state to the published state. Also a user
can start editing in a published post, that moves it to draft state with a copy of the original post as
the starting point.
A user can publish a post, that moves the content from the draft state to the
published state. Also a user can start editing in a published post, that moves
it to draft state with a copy of the original post as the starting point.
So essentially posts have two content fields, one for draft and one for published. Editing only happens on
the draft state. Undo/Redo is also only available on the draft state editing session in the text field
with standard mechanisms.
So essentially posts have two content fields, one for draft and one for
published. Editing only happens on the draft state. Undo/Redo is also only
available on the draft state editing session in the text field with standard
mechanisms.
published posts have a delete button that allows deleting a post that exists. This will internally switch
the post to deleted, and filter it out, but will not remove it fully from the database, because the publishing
pipeline later might need the fact of the deletion as information source to do its thing (update relevant
files).
published posts have a delete button that allows deleting a post that exists.
This will internally switch the post to deleted, and filter it out, but will not
remove it fully from the database, because the publishing pipeline later might
need the fact of the deletion as information source to do its thing (update
relevant files).
So a post starts in "draft" and can go to "published" and from there to "archived". From "draft" it can only
go back to "published" (via discard) or vanish fully from the database (because drafts for new posts are
not relevant for the pipeline, as they never were published before).
So a post starts in "draft" and can go to "published" and from there to
"archived". From "draft" it can only go back to "published" (via discard) or
vanish fully from the database (because drafts for new posts are not relevant
for the pipeline, as they never were published before).
Posts in draft are automatically saved during edit when idle and a dot in the tab title gives
information about its state as unsaved. The user can force the save with the standard hotkey for that
purpose or just wait. Switching to another post will also save a draft automatically.
Posts in draft are automatically saved during edit when idle and a dot in the
tab title gives information about its state as unsaved. The user can force the
save with the standard hotkey for that purpose or just wait. Switching to
another post will also save a draft automatically.
Important for the handling of posts is that draft content is always kept in the database and only when
the user uses the publish button the content is moved to the filesystem and the content in the database
is set to empty again. This is meant to keep draft content in the database, as it is volatile, and only
published content in filesystem, where it is then later used by the publishing pipeline.
Important for the handling of posts is that draft content is always kept in the
database and only when the user uses the publish button the content is moved to
the filesystem and the content in the database is set to empty again. This is
meant to keep draft content in the database, as it is volatile, and only
published content in filesystem, where it is then later used by the publishing
pipeline.
So only posts in state draft have content in the database, but whenever something goes to state published,
the draft content is set to empty. draft content contains text content as well as metadata content that
was changed. So even if the user changes tags or the category or the title or whatnot, the actual data
is first only kept in the database and only on publish moved to the file.
So only posts in state draft have content in the database, but whenever
something goes to state published, the draft content is set to empty. draft
content contains text content as well as metadata content that was changed. So
even if the user changes tags or the category or the title or whatnot, the
actual data is first only kept in the database and only on publish moved to the
file.
Database rebuild at startup is not overwriting draft content, it is only recreating missing posts.
Database rebuild at startup is not overwriting draft content, it is only
recreating missing posts.
Published content is only ever updated when the publish action is done by the user.
Published content is only ever updated when the publish action is done by the
user.
Deletion warns if some media file or post is dependent on the one you are about to delete, because that
will break the relation.
Deletion warns if some media file or post is dependent on the one you are about
to delete, because that will break the relation.
## UI and UX specifics
The UI and UX should be aligned with modern applications like vscode. I want iconbar and left sidebar and the
big main area with tabbed views. Open views will be automatically opened again on next start, so the user
does not have to reselect everything.
The UI and UX should be aligned with modern applications like vscode. I want
iconbar and left sidebar and the big main area with tabbed views. Open views
will be automatically opened again on next start, so the user does not have to
reselect everything.
All sidebar areas and panels can be resized easily and resizings are persisted so they are the same on next
application start. UI configuration is persisted on the project level, so when I switch projects, I get the
same layout and opened tabs as the last time I worked on that project.
All sidebar areas and panels can be resized easily and resizings are persisted
so they are the same on next application start. UI configuration is persisted on
the project level, so when I switch projects, I get the same layout and opened
tabs as the last time I worked on that project.
Sidebar will be shown/hidden by repeated clicking on same icon, just as with vscode. Also the title bar
has the typical "show/hide left sidebar" icon as vscode has it.
Sidebar will be shown/hidden by repeated clicking on same icon, just as with
vscode. Also the title bar has the typical "show/hide left sidebar" icon as
vscode has it.
The main area is a tabbed layout with proper tab support that stay open even on sidebar switching and that
grow and shrink accordingly when the sidebar is activated or deactivated.
The main area is a tabbed layout with proper tab support that stay open even on
sidebar switching and that grow and shrink accordingly when the sidebar is
activated or deactivated.
There are no lengthy synchronous actions in the UI thread, everything is offloaded to the main thread and
if it is complex, to async tasks, with proper integration with the UI and notification about state of those
asynchronous tasks via toasts. There is a central notification framework used by everything, so we are sure
that the user is informed about ongoing activities at all times.
There are no lengthy synchronous actions in the UI thread, everything is
offloaded to the main thread and if it is complex, to async tasks, with proper
integration with the UI and notification about state of those asynchronous tasks
via toasts. There is a central notification framework used by everything, so we
are sure that the user is informed about ongoing activities at all times.
There is a bottom status bar in the app that for example shows how many async tasks are running at any time,
so if we run maybe two importer in parallel, the user will be able to see that there are 2 tasks running
and will be abl to click on that to see a small popup that lists all active async tasks.
There is a bottom status bar in the app that for example shows how many async
tasks are running at any time, so if we run maybe two importer in parallel, the
user will be able to see that there are 2 tasks running and will be abl to click
on that to see a small popup that lists all active async tasks.
All preferences are always local to the selected project and project settings are easily reachable via
a gear icon in the bottom of the iconbar. Also login credentials can be managed via a user icon in the bottom
of the icon bar directly above the gear icon. This is similar to what vscode does, separating logins and
settings.
All preferences are always local to the selected project and project settings
are easily reachable via a gear icon in the bottom of the iconbar. Also login
credentials can be managed via a user icon in the bottom of the icon bar
directly above the gear icon. This is similar to what vscode does, separating
logins and settings.
Tags are something that should be mainly focus on reusing but need easy ways to add new tags. This should
not be a simple text field, but more a feature like tags in gitlab, where you can easily select multiple
available tags, but also can quickly create new tags. Tags should have a color and there should be a way
to manage tags in the preferences, too, so that users can create tags upfront to posts.
Tags are something that should be mainly focus on reusing but need easy ways to
add new tags. This should not be a simple text field, but more a feature like
tags in gitlab, where you can easily select multiple available tags, but also
can quickly create new tags. Tags should have a color and there should be a way
to manage tags in the preferences, too, so that users can create tags upfront to
posts.
Categories are a simple selection via dropdown and a preferences panel that allows category management.
Categories are mainly used to denote different styles of posts and posts are only of one style.
Categories are a simple selection via dropdown and a preferences panel that
allows category management. Categories are mainly used to denote different
styles of posts and posts are only of one style.
## Organizing
Blog posts should be organized in the app in the main post view where the sidebar lists posts and the main
tab area can have multiple posts (new or selected from the sidebar) open, just like vscode manages text files.
The sidebar for posts must also include a calendar view at the top that allows to go to specific dates or
date ranges (by selecting a whole month of a year for example) and then accordingly filter down the post
list in the sidebar.
Blog posts should be organized in the app in the main post view where the
sidebar lists posts and the main tab area can have multiple posts (new or
selected from the sidebar) open, just like vscode manages text files. The
sidebar for posts must also include a calendar view at the top that allows to go
to specific dates or date ranges (by selecting a whole month of a year for
example) and then accordingly filter down the post list in the sidebar.
And there must be a way to use markdown links of a specific short-form to reference other posts, so that
I can link to other places, if needed, and those references should also be part of the information about
posts. So each post should give a "links to" part in the UI (right sidebar or lower area of left sidebar
like with vscode?) and a "linked to by" part where incoming links are shown.
And there must be a way to use markdown links of a specific short-form to
reference other posts, so that I can link to other places, if needed, and those
references should also be part of the information about posts. So each post
should give a "links to" part in the UI (right sidebar or lower area of left
sidebar like with vscode?) and a "linked to by" part where incoming links are
shown.
Post need to support drag-and-drop image insert, and adding images must automatically create the related
media file entry, so that metadata for images can easily be set in the UI, but users get their posts
set up quickly without lots of hassle. Images that are referenced by posts are also linked in metadata to
the post, so that we have full overview what imags a post references in the actual post data. And that data
is also included in the published post file on the file system.
Post need to support drag-and-drop image insert, and adding images must
automatically create the related media file entry, so that metadata for images
can easily be set in the UI, but users get their posts set up quickly without
lots of hassle. Images that are referenced by posts are also linked in metadata
to the post, so that we have full overview what imags a post references in the
actual post data. And that data is also included in the published post file on
the file system.
Linkage data must be recoverable form posts and image links must be discoverable from post text, too,
so that a blog can be repaired if anything goes wrong. There must be a strong focus on being indestructable
for the blog, the most that could get lost can be draft content, but everything published must be
fully recoverable from data on the file system.
Linkage data must be recoverable form posts and image links must be discoverable
from post text, too, so that a blog can be repaired if anything goes wrong.
There must be a strong focus on being indestructable for the blog, the most that
could get lost can be draft content, but everything published must be fully
recoverable from data on the file system.
### default category "article"
This is for articles that are focused on long text. They will show fully only on the full page, but will
be summarized in overview pages.
This is for articles that are focused on long text. They will show fully only on
the full page, but will be summarized in overview pages.
### category "picture"
This is a variant of article with less text-focus but usually a strong focus on attached images. This
will show the image in a wide format if it is just one, or a gallery view, if it is multiple images
and will only show thumbnails for overviews. This means we will need a library to manage image sizes
properly for thumbnails during media storage. those thumbnails must be created automatically.
This is a variant of article with less text-focus but usually a strong focus on
attached images. This will show the image in a wide format if it is just one, or
a gallery view, if it is multiple images and will only show thumbnails for
overviews. This means we will need a library to manage image sizes properly for
thumbnails during media storage. those thumbnails must be created automatically.
### category "aside"
This is a short-form article that does not need a full-article-page, because it will just be a link and
a short comment that is shown after the link. This is meant for link collections and should be rendered
in a compact form in the overview pages. More on rendering in the publishing pipelin description.
This is a short-form article that does not need a full-article-page, because it
will just be a link and a short comment that is shown after the link. This is
meant for link collections and should be rendered in a compact form in the
overview pages. More on rendering in the publishing pipelin description.
### category "page"
This is a post that behaves mostly like an article, but is ignored in overview pages, because it is just
meant to be linked to menues. So menu editing needs to be able to reference posts of category page
and overview templates need to ignore posts of category page. Other than that, they are just like article,
so have long form text, short form summary and title. Pages can be assigned different header images that
override the project image.
This is a post that behaves mostly like an article, but is ignored in overview
pages, because it is just meant to be linked to menues. So menu editing needs to
be able to reference posts of category page and overview templates need to
ignore posts of category page. Other than that, they are just like article, so
have long form text, short form summary and title. Pages can be assigned
different header images that override the project image.
### Project definition
A project is not just the collection of posts, media and publish settings, it is also a base project
container with title, author and other elements like that. So there needs to be project related settings
that allow to give the project a title, set up a main author that can be referenced in metadat and for
example set up header images that can be used when publishing.
A project is not just the collection of posts, media and publish settings, it is
also a base project container with title, author and other elements like that.
So there needs to be project related settings that allow to give the project a
title, set up a main author that can be referenced in metadat and for example
set up header images that can be used when publishing.
## Migrating
Prepare a proper mass-data importer that can read wordpress backup files, so the user can bring in old
wordpress blogs easily. That importer should run asynchronously and properly communicate progress to the
user while it is running in the background. The import has to rebuild all metadata properly, so check if
we have all the metadata in our model set up in a similar way as Wordpress handles it, so that we have a
seamless integration. Posts in Wordpress backups are html, but should be interpreted and transformed into
proper markdown in the import.
Prepare a proper mass-data importer that can read wordpress backup files, so the
user can bring in old wordpress blogs easily. That importer should run
asynchronously and properly communicate progress to the user while it is running
in the background. The import has to rebuild all metadata properly, so check if
we have all the metadata in our model set up in a similar way as Wordpress
handles it, so that we have a seamless integration. Posts in Wordpress backups
are html, but should be interpreted and transformed into proper markdown in the
import.
In general, HTML elements of the post have to all be transformed into markdown equivalents, and not use
embedded HTML, for as much as possible. We want clean markdown in the posts after the import, not a mix
of markdown and HTML.
In general, HTML elements of the post have to all be transformed into markdown
equivalents, and not use embedded HTML, for as much as possible. We want clean
markdown in the posts after the import, not a mix of markdown and HTML.
For this AI support during import to work, the blog application needs to provide post management and media
management functionality as proper AI tools to the OpenCode Zen API, so that it will be able to work
on those posts.
For this AI support during import to work, the blog application needs to provide
post management and media management functionality as proper AI tools to the
OpenCode Zen API, so that it will be able to work on those posts.
The AI importing agent must discover the language of a post and put that in an attribute. Posts must have
the database structure of translations, so that a post that is discovered as being german can be automatically
translated to english and vice-versa. After import, all posts are available in two languages.
The AI importing agent must discover the language of a post and put that in an
attribute. Posts must have the database structure of translations, so that a
post that is discovered as being german can be automatically translated to
english and vice-versa. After import, all posts are available in two languages.
Another thing the AI importing agent must do is create summaries of posts to put into a summary attribute
on posts in the database, so that those can be used in overview pages if needed (usually that is the
case for article-type posts).
Another thing the AI importing agent must do is create summaries of posts to put
into a summary attribute on posts in the database, so that those can be used in
overview pages if needed (usually that is the case for article-type posts).
Imports must be able to recognize duplicates of posts to some degree, so that we don't create additional
posts from new import runs if the original posts are already there. In the case of recognized duplicates,
the original post will just be linked to the same tag of the new import, so that the user can see it was
Imports must be able to recognize duplicates of posts to some degree, so that we
don't create additional posts from new import runs if the original posts are
already there. In the case of recognized duplicates, the original post will just
be linked to the same tag of the new import, so that the user can see it was
referenced by multiple imports.
Essentially my main idea for imports is that the importer is classes that can read websits from different
sources (starting with wordprss backup and HTTP URL) and that each discovered element is handed to the AI
to convert to markdown and in the case of the HTTP URL also separate out posts, then use the tools to
check for duplicates and update tags or create new posts based on the process.
Essentially my main idea for imports is that the importer is classes that can
read websits from different sources (starting with wordprss backup and HTTP URL)
and that each discovered element is handed to the AI to convert to markdown and
in the case of the HTTP URL also separate out posts, then use the tools to check
for duplicates and update tags or create new posts based on the process.
Import runs can be shown in the main panel, so that the user can see what came with what import and can
manage posts and media from imports that way. Migration is the main interesting part of this tool, because
migrating blogs is hard work and needs to be properly supported.
Import runs can be shown in the main panel, so that the user can see what came
with what import and can manage posts and media from imports that way. Migration
is the main interesting part of this tool, because migrating blogs is hard work
and needs to be properly supported.
Migrating posts puts them into published state directly, not draft state, because that would make the
database explode. The whole point of migration is to get those posts into a published state as soon as
possible.
Migrating posts puts them into published state directly, not draft state,
because that would make the database explode. The whole point of migration is to
get those posts into a published state as soon as possible.
## Organizing II
Since we have an AI assistant planned for the migration phase, we also want an AI chat feature as another
view in the app, so we can activate it and use the AI assistant to query blog posts and media files in the
system and also create blog posts with AI support.
Since we have an AI assistant planned for the migration phase, we also want an
AI chat feature as another view in the app, so we can activate it and use the AI
assistant to query blog posts and media files in the system and also create blog
posts with AI support.
All SDK tools must also be made available as MCP server that is hosted inside the application, so that I
can hook the app into a normal AI coding agent.
All SDK tools must also be made available as MCP server that is hosted inside
the application, so that I can hook the app into a normal AI coding agent.
Also the AI should be available to create summaries just with a button click in the post editor area, so
that the summary is filled in based on AI summarization to help speed up the blogging process. Also the
AI can be used to generate a good slurl that is not just generically from the title and even the title
can be AI-generated from the text. That way the user can focus on writing the core text and if all matches,
just accept AI summary and title and post it.
Also the AI should be available to create summaries just with a button click in
the post editor area, so that the summary is filled in based on AI summarization
to help speed up the blogging process. Also the AI can be used to generate a
good slurl that is not just generically from the title and even the title can be
AI-generated from the text. That way the user can focus on writing the core text
and if all matches, just accept AI summary and title and post it.
## Previewing
There should be an integrated web server that can be opened from the file menu in a browser (menu item
"open in browser" starts the default browser with the localhost URL) too look at what the site would look
after publishing. The preview should just run live through what the exporter would do to each page that
is sent to the server. This gives a proper preview of things to come.
There should be an integrated web server that can be opened from the file menu
in a browser (menu item "open in browser" starts the default browser with the
localhost URL) too look at what the site would look after publishing. The
preview should just run live through what the exporter would do to each page
that is sent to the server. This gives a proper preview of things to come.
Preview should include draft content, so that even before publishing the user can see what will be there
after publishing. Also this will allow background-publishing to automatically happen when new content
is put into publish state, if we want that later.
Preview should include draft content, so that even before publishing the user
can see what will be there after publishing. Also this will allow
background-publishing to automatically happen when new content is put into
publish state, if we want that later.
## Publishing
Publishing should target static HTML/CSS/JavaScript situations. There must be a asnyc exporter, that will render
all affected pages based on the structure of the export and auto-update affected files when the posts or media
that are used in the page were changed. This requires a cross-reference table that links posts and media entries
with actual HTML files that are referencing them. This needs to be based on how templates use posts in the
export pipeline.
Publishing should target static HTML/CSS/JavaScript situations. There must be a
asnyc exporter, that will render all affected pages based on the structure of
the export and auto-update affected files when the posts or media that are used
in the page were changed. This requires a cross-reference table that links posts
and media entries with actual HTML files that are referencing them. This needs
to be based on how templates use posts in the export pipeline.
Essentially the publishing pipeline knows what posts changed since last publishing (maybe a version number
that is pulled from a central place, so that any change will raise that version and any post and media
that has a higher version number of the last publish run is seen as changed) and will run the relevant templates
to recreate all linkd pages of the publishing (single post pages for the post but also many overview pages) and
of course each page is only updated once in the publishing run, collecting all changed posts for that.
Essentially the publishing pipeline knows what posts changed since last
publishing (maybe a version number that is pulled from a central place, so that
any change will raise that version and any post and media that has a higher
version number of the last publish run is seen as changed) and will run the
relevant templates to recreate all linkd pages of the publishing (single post
pages for the post but also many overview pages) and of course each page is only
updated once in the publishing run, collecting all changed posts for that.
The main driver is a proper blog structure with templates. For this I want proper templates I can manage and
edit in the application itself. Template editing should provide proper syntax highlighting, so something like
monaco is important. Choose a good solid template engine for node-js based tools that is especialy targeted
to easy template creation.
The main driver is a proper blog structure with templates. For this I want
proper templates I can manage and edit in the application itself. Template
editing should provide proper syntax highlighting, so something like monaco is
important. Choose a good solid template engine for node-js based tools that is
especialy targeted to easy template creation.
For the styling I want the system to be based on css templates, so that the look can be easily swapped
to the wish of the user. There should be a selection of light and dark themes bundled with the application,
so that starting is simple. New css templates must be easily integrateable into the application,
maybe even with easy importing from a central repository site or something like that. I think Pico CSS is a
good choice, since it sticks to semantic HTML and auto-adapts to light/dark mode settings of users.
I want to work minimalist, but still allow some style influence into the site based on user prefs.
For the styling I want the system to be based on css templates, so that the look
can be easily swapped to the wish of the user. There should be a selection of
light and dark themes bundled with the application, so that starting is simple.
New css templates must be easily integrateable into the application, maybe even
with easy importing from a central repository site or something like that. I
think Pico CSS is a good choice, since it sticks to semantic HTML and
auto-adapts to light/dark mode settings of users. I want to work minimalist, but
still allow some style influence into the site based on user prefs.
Check the site https://hugo.rfc1437.de/ for its structure, this is the structure of blog I want to be
capable of building with this tooling. So we need templates for overview pages and ways to manage menues
that reference overview pages and structure the menu according to site structure. Also support calendar views
to allow users to go to specific months and years of the blog. Build up a sensible set of templates that
come with a new project, so that the user can start right away without a lot of hassle. Base the templates
on the structure of above website, but keep out website title and images, of course.
Check the site https://hugo.rfc1437.de/ for its structure, this is the structure
of blog I want to be capable of building with this tooling. So we need templates
for overview pages and ways to manage menues that reference overview pages and
structure the menu according to site structure. Also support calendar views to
allow users to go to specific months and years of the blog. Build up a sensible
set of templates that come with a new project, so that the user can start right
away without a lot of hassle. Base the templates on the structure of above
website, but keep out website title and images, of course.
Categories and tags must be able to define a template selection for post templates, so that different types
can be represented differently. this is especially important for the standard categories "article", "picture"
and "aside", as they should come right away with templates for their article page and their use in overviews.
Every post can define via category or tag (tag-related templates override category templates but can be
overridden via article-specific template selections).
Categories and tags must be able to define a template selection for post
templates, so that different types can be represented differently. this is
especially important for the standard categories "article", "picture" and
"aside", as they should come right away with templates for their article page
and their use in overviews. Every post can define via category or tag
(tag-related templates override category templates but can be overridden via
article-specific template selections).
There must be way to open a browser tab in the application that then uses the applicaiton itself and does
dynamic rendering of the content, using the same templates and everything else, so that the user can do
a propoer preview before deciding to update the remote static web storage. The browser tab will of course use
the correct styling of the website.
There must be way to open a browser tab in the application that then uses the
applicaiton itself and does dynamic rendering of the content, using the same
templates and everything else, so that the user can do a propoer preview before
deciding to update the remote static web storage. The browser tab will of course
use the correct styling of the website.
Publishing of files can be configured to be done via FTP or SSH, connection data must be configureable in
preferences for the website.
Publishing of files can be configured to be done via FTP or SSH, connection data
must be configureable in preferences for the website.