Blog schema updates

[friep]

minor updates after recreating blog schema.

• pubdate -> publication_datetime (align with podcast)
• collection is named Blog_Posts, not Posts (which was confusing for new people)

open questions / issues:

• [x] i adapted the parsing of the person (people.js) because i (wrongly) added the description to the person itself and not to the content creator. Question: do we want to keep it? As expressed before, I feel like most people in CorrelAid have "one description" and it's unnecessary complexity to have different descriptions for content creators, global admins, ... if we want to add this layer later, we still could?! --> reverted
• [x] date is currently shown to be "invalid"
• [x] the list of blog posts is full width even though i did not adapt any code of this (afaik)
• [x] person description is still shown as HTML (i put wysiwyg, i guess it was just textarea before?) --> reverted to textarea.

[vercel[bot]]

The latest updates on your projects. Learn more about Vercel for Git ↗︎

1 Ignored Deployment

| Name | Status | Preview | Comments | Updated (UTC) | | :--- | :----- | :------ | :------- | :------ | | **correlaid** | ⬜️ Ignored ([Inspect](https://vercel.com/correlaid/correlaid/D7FnXn8gzkgzfmocXHqkWRxgpxFv)) | [Visit Preview](https://correlaid-git-adapt-blog-schema-correlaid.vercel.app) | | Aug 9, 2023 1:16pm |

[jstet]

re width: did u add a custom section to the entry in the pages collection?

[friep]

thanks that fixed it!

[jstet]

re description, how would u deal with the situation of people needing more than one description/a context depended description in this case?

[friep]

tl;dr: i would not deal with it.

in my opinion the use case is not worth the complexity and added effort of maintaining them in different places. imo there's no harm in using general descriptions that cover all that the person does within CorrelAid. For example, if Marco shows up on LC Konstanz, it's also ok to write that he's part of the board and vice versa. I'd actually argue that it's a plus because it shows that people can be involved in different roles at once.

For blog posts, temporal stability is actually more of a problem (aka: Johannes 8 years ago has the same description as content creator Johannes today) but again, for me, i'd keep it as simple as possible.

If you think this has implications too far for a PR. i can move my comment to the related issue and revert the changes (i guess i am just frustrated that i manually added things in the wrong place in directus)

[jstet]

Okay that makes sense! Fine by me to do it that way

[KonradUdoHannes]

@friep I just have some general comments on dealing with these changes and PRs in general.

• currently the CI action chokes a minor linting error. This should not be possible if the pre-commit hooks are set up correctly. As described in the readme dev setup npm run init_pre_commit should do the trick. Now that the changes are already committed npm run format and npm run lint can be used to apply the respective tools to the entire codebase not the staged files only. Not sure whether these files are in the readme, but they can all be looked up in the package.json. If there are any issues here please let me know because we absolutely want to make sure that CI and pre-commit hooks are aligned.
• When making changes to the parsing the best way to check whether everything is still working is to run npm run build-and-test with a configuration for static site building as described in the readme. This will catch a lot of errors when either the build or the tests fail. Its not part of the CI but was (and will be again) part of CD.
• For changes that simply rename fields in directus to make work for the content creators easier/more intuitive we don't necessarily have to touch parsing every time. Instead we could use the the alias syntax from GraphQl and just modify the queries. For instance the change Post {...} to Post : Blog_Post {...} will fetch the Blog_Posts instead of Posts from graphql, but it will give the Blog_Post the alias Post afterwards. This means that any code coming after the fetch won't see a difference.

[cloudflare-pages[bot]]

Deploying with    Cloudflare Pages

Latest commit:	616d9ec
Status:	✅  Deploy successful!
Preview URL:	https://fa342d45.correlaid.pages.dev
Branch Preview URL:	https://adapt-blog-schema.correlaid.pages.dev

View logs

[friep]

@jstet i reverted the changes related to the people description. Let's better do this in a controlled manner another time. 👍 i commented in #204 . Then we can also take the time to do refactoring properly.

@KonradUdoHannes thanks for the pointers.

1. I installed the precommit hooks. linting gives one warning related to image_alt in events.. I don't want to touch this here.
2. I ran this and did minor changes to svelte.config.js. It then fails later on the projects and event routes which makes sense, right?
3. interesting and good to know! I still think it's good to have this aligned in the code as well so that we don't diverge terminology wise too much. I've worked in projects where at some point frontend code was using different terminology than backend code and found that quite exhausting to think about. But if it's. important to you to keep the shorter Posts, i won't die on this hill :)