-
Notifications
You must be signed in to change notification settings - Fork 7
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
RFC: blog integration #100
Comments
tl;dr: I agree with most of your suggestions. Except: author filter is imo unnecessary, category can be integrated in tags.
Yeah because this is not a separate webapp this sounds reasonable to do.
Do we need
Depends on how ambigious you want to make the parsing. When it is only year and tags it will work without the prefix (one is a number, the other text). When you add author you need a prefix. Will be the link
Imo categories are not needed. When you look at discourse they only rely on tagging and this is good enough (we just have to agree on which tags to use).
ack
Agree. This is the only one I use. When you have a good feed reader you can do client-side filtering (e.g. if you only care about Player). Though the blog is so low volume that nobody will care if there is one uninteresting post per year 🤷.
When embedding doesn't work they could be also manually linked (btw maybe this is even useful for the (Player) guides to ask questions directly?) Guess the old comments will be lost (?) though this is not a huge loss imo. About the mediaWhat do you plan to do with the media? Currently this is just all in a single subdirectory. Imo this is pretty messy and could be relocated in media directories per blog post. The media should be versioned as it belongs to the blogpost. Problem I see is with the videos (.webm). Some of them are huge. I have most of the assets archived locally so if you need anything reencoded from the source material e.g. in VP9 just tell me. WorkflowDo you have an idea for the workflow when writing a blog post? Like there could be a new repository "blog-wip" that contains the drafts for upcoming blog posts. All of us have edit permissions to still allow improving the PR. At the end it is squashed and a PR against the website repo sent (because the history will be a mess with all the "edited with the online editor" changes :)). |
While integrating the blog posts was mostly an easy task, I am now writing code for the auxiliary pages and need to clarify some ideas to make some implementation decisions and explain the current decisions taken. So everything here is not written in stone and up for discussion:
The stem of the url will stay the same, but I would like to move the blog back from the subdomain to subdirectory to have a more integrated overall image.
That means we need some redirects to not break bookmarks and external links:
blog.easyrpg.org/year/month/slug
→easyrpg.org/blog/year/month/slug
Wordpress provides some taxonomy pages, that will have a paginated view of categories, tags, authors and of course archives of years and months. While this may make sense for an automated CMS, this will duplicate a lot of pages in a lot of ways.
I therefore slimmed these down to a link list style, that means single pages with all related posts linked, not included. This way the content is not duplicated.
That means for example the archive for the year 2021 will contain:
Because of this and the low post-per-year count, the fine-grained monthly pages from wordpress are not needed. So another two redirects are required:
blog.easyrpg.org/year/month/
→easyrpg.org/blog/year/
blog.easyrpg.org/year/
→easyrpg.org/blog/year/
For the taxonomies I would like to move them from the prominent top level links to archive namespace, but it might be better to keep wordpress style?
blog.easyrpg.org/year/
→easyrpg.org/blog/archive/year
blog.easyrpg.org/tag/
→easyrpg.org/blog/archive/tag
blog.easyrpg.org/author/
→easyrpg.org/blog/archive/author
Also a different naming would be okay like adding
by-
, like/archive/by-category/
or/posts/by-category/
.Another question is the Feed integration. nanoc can create atom feeds, but the content and location is open for discussion, since wordpress writes a lot of them as well.
IMO only the post feed is needed, maybe category/tag feeds, but the rest not.
Comment feeds are possible, but some additional work to inject by javascript, since comments are loaded from discourse in the future.
The text was updated successfully, but these errors were encountered: