Start post types page

[askvortsov1]

A start to the post types documentation page. As a next step, I'd like to walk the readers through an example, but am unsure of what a good example would be. Perhaps just DiscussionRenamed?

[clarkwinkelmann]

Some thoughts:

The only post type available by default is the "Discussion Renamed" event post

I think we should list core extension's classes together with core if we list them in the documentation, with a note that it only exists with extension X.

• A database representation of the custom post type
• An Eloquent model to represent the custom post type.

Isn't it basically the same thing?

By default, event posts are stored in the posts database table

I don't think there is any other way? post types are a way to change how a post record is rendered, but there is no way to store them any other way. the "by default" doesn't make sense then.

---

Regarding the "store as much as possible data" part, I think it's important to note that by default, the whole payload is public. So storing more in preparation for future work might require some good thinking and planning, let's not encourage developers to inject a lot of data in somewhere public but not visible to untrained users.

---

Regarding post types, I think it's important to mention the concept of EVENT posts. Basically the base post just has a TEXT content that doesn't mean anything. COMMENT posts use that content to store TextFormatter-formatted XML. EVENT posts use that field as a JSON object and are a convenient abstract class for simple event posts like Flarum uses https://github.com/flarum/core/blob/master/src/Post/AbstractEventPost.php . But extensions are free to extend either AbstractEventPost, Post, or technically even CommentPost (but that wouldn't be advisable while we are in beta)

[askvortsov1]

A start to the post types documentation page. As a next step, I'd like to walk the readers through an example, but am unsure of what a good example would be. Perhaps just DiscussionRenamed?

[clarkwinkelmann]

Some thoughts:

The only post type available by default is the "Discussion Renamed" event post

I think we should list core extension's classes together with core if we list them in the documentation, with a note that it only exists with extension X.

• A database representation of the custom post type
• An Eloquent model to represent the custom post type.

Isn't it basically the same thing?

By default, event posts are stored in the posts database table

I don't think there is any other way? post types are a way to change how a post record is rendered, but there is no way to store them any other way. the "by default" doesn't make sense then.

---

Regarding the "store as much as possible data" part, I think it's important to note that by default, the whole payload is public. So storing more in preparation for future work might require some good thinking and planning, let's not encourage developers to inject a lot of data in somewhere public but not visible to untrained users.

---

Regarding post types, I think it's important to mention the concept of EVENT posts. Basically the base post just has a TEXT content that doesn't mean anything. COMMENT posts use that content to store TextFormatter-formatted XML. EVENT posts use that field as a JSON object and are a convenient abstract class for simple event posts like Flarum uses https://github.com/flarum/core/blob/master/src/Post/AbstractEventPost.php . But extensions are free to extend either AbstractEventPost, Post, or technically even CommentPost (but that wouldn't be advisable while we are in beta)

[askvortsov1]

A start to the post types documentation page. As a next step, I'd like to walk the readers through an example, but am unsure of what a good example would be. Perhaps just DiscussionRenamed?

[clarkwinkelmann]

Some thoughts:

The only post type available by default is the "Discussion Renamed" event post

I think we should list core extension's classes together with core if we list them in the documentation, with a note that it only exists with extension X.

• A database representation of the custom post type
• An Eloquent model to represent the custom post type.

Isn't it basically the same thing?

By default, event posts are stored in the posts database table

I don't think there is any other way? post types are a way to change how a post record is rendered, but there is no way to store them any other way. the "by default" doesn't make sense then.

---

Regarding the "store as much as possible data" part, I think it's important to note that by default, the whole payload is public. So storing more in preparation for future work might require some good thinking and planning, let's not encourage developers to inject a lot of data in somewhere public but not visible to untrained users.

---

Regarding post types, I think it's important to mention the concept of EVENT posts. Basically the base post just has a TEXT content that doesn't mean anything. COMMENT posts use that content to store TextFormatter-formatted XML. EVENT posts use that field as a JSON object and are a convenient abstract class for simple event posts like Flarum uses https://github.com/flarum/core/blob/master/src/Post/AbstractEventPost.php . But extensions are free to extend either AbstractEventPost, Post, or technically even CommentPost (but that wouldn't be advisable while we are in beta)

[askvortsov1]

A start to the post types documentation page. As a next step, I'd like to walk the readers through an example, but am unsure of what a good example would be. Perhaps just DiscussionRenamed?

[clarkwinkelmann]

Some thoughts:

The only post type available by default is the "Discussion Renamed" event post

I think we should list core extension's classes together with core if we list them in the documentation, with a note that it only exists with extension X.

• A database representation of the custom post type
• An Eloquent model to represent the custom post type.

Isn't it basically the same thing?

By default, event posts are stored in the posts database table

I don't think there is any other way? post types are a way to change how a post record is rendered, but there is no way to store them any other way. the "by default" doesn't make sense then.

---

Regarding the "store as much as possible data" part, I think it's important to note that by default, the whole payload is public. So storing more in preparation for future work might require some good thinking and planning, let's not encourage developers to inject a lot of data in somewhere public but not visible to untrained users.

---

Regarding post types, I think it's important to mention the concept of EVENT posts. Basically the base post just has a TEXT content that doesn't mean anything. COMMENT posts use that content to store TextFormatter-formatted XML. EVENT posts use that field as a JSON object and are a convenient abstract class for simple event posts like Flarum uses https://github.com/flarum/core/blob/master/src/Post/AbstractEventPost.php . But extensions are free to extend either AbstractEventPost, Post, or technically even CommentPost (but that wouldn't be advisable while we are in beta)

[askvortsov1]

A start to the post types documentation page. As a next step, I'd like to walk the readers through an example, but am unsure of what a good example would be. Perhaps just DiscussionRenamed?

[clarkwinkelmann]

Some thoughts:

The only post type available by default is the "Discussion Renamed" event post

I think we should list core extension's classes together with core if we list them in the documentation, with a note that it only exists with extension X.

• A database representation of the custom post type
• An Eloquent model to represent the custom post type.

Isn't it basically the same thing?

By default, event posts are stored in the posts database table

I don't think there is any other way? post types are a way to change how a post record is rendered, but there is no way to store them any other way. the "by default" doesn't make sense then.

---

Regarding the "store as much as possible data" part, I think it's important to note that by default, the whole payload is public. So storing more in preparation for future work might require some good thinking and planning, let's not encourage developers to inject a lot of data in somewhere public but not visible to untrained users.

---

Regarding post types, I think it's important to mention the concept of EVENT posts. Basically the base post just has a TEXT content that doesn't mean anything. COMMENT posts use that content to store TextFormatter-formatted XML. EVENT posts use that field as a JSON object and are a convenient abstract class for simple event posts like Flarum uses https://github.com/flarum/core/blob/master/src/Post/AbstractEventPost.php . But extensions are free to extend either AbstractEventPost, Post, or technically even CommentPost (but that wouldn't be advisable while we are in beta)

[askvortsov1]

A start to the post types documentation page. As a next step, I'd like to walk the readers through an example, but am unsure of what a good example would be. Perhaps just DiscussionRenamed?

[clarkwinkelmann]

Some thoughts:

The only post type available by default is the "Discussion Renamed" event post

I think we should list core extension's classes together with core if we list them in the documentation, with a note that it only exists with extension X.

• A database representation of the custom post type
• An Eloquent model to represent the custom post type.

Isn't it basically the same thing?

By default, event posts are stored in the posts database table

I don't think there is any other way? post types are a way to change how a post record is rendered, but there is no way to store them any other way. the "by default" doesn't make sense then.

---

Regarding the "store as much as possible data" part, I think it's important to note that by default, the whole payload is public. So storing more in preparation for future work might require some good thinking and planning, let's not encourage developers to inject a lot of data in somewhere public but not visible to untrained users.

---

Regarding post types, I think it's important to mention the concept of EVENT posts. Basically the base post just has a TEXT content that doesn't mean anything. COMMENT posts use that content to store TextFormatter-formatted XML. EVENT posts use that field as a JSON object and are a convenient abstract class for simple event posts like Flarum uses https://github.com/flarum/core/blob/master/src/Post/AbstractEventPost.php . But extensions are free to extend either AbstractEventPost, Post, or technically even CommentPost (but that wouldn't be advisable while we are in beta)

[askvortsov1]

A start to the post types documentation page. As a next step, I'd like to walk the readers through an example, but am unsure of what a good example would be. Perhaps just DiscussionRenamed?

[clarkwinkelmann]

Some thoughts:

The only post type available by default is the "Discussion Renamed" event post

I think we should list core extension's classes together with core if we list them in the documentation, with a note that it only exists with extension X.

• A database representation of the custom post type
• An Eloquent model to represent the custom post type.

Isn't it basically the same thing?

By default, event posts are stored in the posts database table

I don't think there is any other way? post types are a way to change how a post record is rendered, but there is no way to store them any other way. the "by default" doesn't make sense then.

---

Regarding the "store as much as possible data" part, I think it's important to note that by default, the whole payload is public. So storing more in preparation for future work might require some good thinking and planning, let's not encourage developers to inject a lot of data in somewhere public but not visible to untrained users.

---

Regarding post types, I think it's important to mention the concept of EVENT posts. Basically the base post just has a TEXT content that doesn't mean anything. COMMENT posts use that content to store TextFormatter-formatted XML. EVENT posts use that field as a JSON object and are a convenient abstract class for simple event posts like Flarum uses https://github.com/flarum/core/blob/master/src/Post/AbstractEventPost.php . But extensions are free to extend either AbstractEventPost, Post, or technically even CommentPost (but that wouldn't be advisable while we are in beta)

[askvortsov1]

A start to the post types documentation page. As a next step, I'd like to walk the readers through an example, but am unsure of what a good example would be. Perhaps just DiscussionRenamed?

[clarkwinkelmann]

Some thoughts:

The only post type available by default is the "Discussion Renamed" event post

I think we should list core extension's classes together with core if we list them in the documentation, with a note that it only exists with extension X.

• A database representation of the custom post type
• An Eloquent model to represent the custom post type.

Isn't it basically the same thing?

By default, event posts are stored in the posts database table

I don't think there is any other way? post types are a way to change how a post record is rendered, but there is no way to store them any other way. the "by default" doesn't make sense then.

---

Regarding the "store as much as possible data" part, I think it's important to note that by default, the whole payload is public. So storing more in preparation for future work might require some good thinking and planning, let's not encourage developers to inject a lot of data in somewhere public but not visible to untrained users.

---

Regarding post types, I think it's important to mention the concept of EVENT posts. Basically the base post just has a TEXT content that doesn't mean anything. COMMENT posts use that content to store TextFormatter-formatted XML. EVENT posts use that field as a JSON object and are a convenient abstract class for simple event posts like Flarum uses https://github.com/flarum/core/blob/master/src/Post/AbstractEventPost.php . But extensions are free to extend either AbstractEventPost, Post, or technically even CommentPost (but that wouldn't be advisable while we are in beta)