Skip to content
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

Open
carstene1ns opened this issue Apr 7, 2024 · 1 comment
Open

RFC: blog integration #100

carstene1ns opened this issue Apr 7, 2024 · 1 comment

Comments

@carstene1ns
Copy link
Member

carstene1ns commented Apr 7, 2024

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/slugeasyrpg.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:

Archive of Year 2021
[EasyRPG Player 0.7.0 "Sword"](blogurl/2021/10/easyrpg-player-0-7-0-sword/)
[Translate your favourite games - With EasyRPG](blogurl/2021/3/translate-your-favourite-games-with-easyrpg/)

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.

@Ghabry
Copy link
Member

Ghabry commented Apr 8, 2024

tl;dr: I agree with most of your suggestions. Except: author filter is imo unnecessary, category can be integrated in tags.

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.

Yeah because this is not a separate webapp this sounds reasonable to do.

easyrpg.org/blog/year/month/slug

Imo year and month isn't even needed due to the low-volume. But this appears to be the standard (compared it to Dolphin emu blog). nvm I didn't read the full post. Just year 👍

blog.easyrpg.org/author/

Do we need author as a filter? Usually I'm marked as the author because I submit them, with multi-authorship it would be almost always c1 and fdela and Ghabry. Not really useful imo.

blog.easyrpg.org/year/easyrpg.org/blog/archive/year

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 blog.easyrpg.org/2022 valid with your approach or does it need blog.easyrpg.org/archive/2022. This imo confusing because a link to an article has this still: `blog.easyrpg.org/2022/some-blog-post-here`` and is valid.

category

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).

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.

ack

IMO only the post feed is needed

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 🤷.

Comment feeds are possible, but some additional work to inject by javascript, since comments are loaded from discourse in the future.

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 media

What 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.

Workflow

Do 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 :)).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Development

No branches or pull requests

2 participants