The default behavior may not be suitable for our use at this point because all categories don't have the "this category has custom permissions" setting checked, meaning that both discussions and articles can be posted in the category, so the PostController form would list all categories. This seems like it would get messy,
But this is actually an advantage because it's up to the admin to manage how they want things to appear. It would be nice to have a visual in the discussion list to show that an entry is an article (in fact, it would be nice to have such visual to every type). Perhaps "Discussion Prefix" like plugin could be created to add a visual to all discussions types (polls, events, articles, questions, even Bug-tracker I saw someone was working on).
@rbrahmson said:
It would be nice to have a visual in the discussion list to show that an entry is an article (in fact, it would be nice to have such visual to every type). Perhaps "Discussion Prefix" like plugin could be created to add a visual to all discussions types (polls, events, articles, questions, even Bug-tracker I saw someone was working on).
That actually sounds like a good idea. The QnA plugin already does that itself, so just adding an option into this proposed rewrite of Articles should do the job. Having the admin going into each category settings page and clicking the check boxes to "convert" them to article categories does sound tedious, but it sounds like a good idea to make use of the built-in Vanilla discussion type functionality.
Categories that has more than one discussion type set, including articles, can have the discussions index show a discussion prefix to indicate that a discussion is an article among all mixed types of discussions. This could bring up an inconsistency with the index listings being different from how articles and discussions will be shown independently in the profiles and in other places on the forum.
The best way to use articles is to have categories with only the articles type set. They can have a modified display or entirely new view that will show discussions in article content style with the excerpt/full text, thumbnails, and so on.
I have been busy this week and will still be in the upcoming weeks, but I'll try to look into how we can rewrite and integrate articles into Vanilla better and see how it turns out. I've already got a development application set up to work on this.
@hgtonight said:
Just take care of adding extra columns to the discussion table.
Let's say that, at most, we will only be needing to store data for an excerpt, status for workflow, attribution/author user ID, article thumbnail/preview image ID, and date published time if we decide to make it separate from the DateInserted column.
There are a couple main ways this could be done:
Add columns called ArticleExcerpt, ArticleStatus (string), ArticleAuthorUserID, ArticleThumbnailID, and ArticleDatePublished to the Discussion table. As an alternative for the ArticleStatus column, an ArticlePublished (boolean) column could be added if discussion drafts could be used, with false indicating that it's pending review.
Use the ForeignID column or add a column called ArticleID that could be used to join a discussion with article data stored in another table. Foreign IDs should be synchronized.
@Shadowdare said:
Let's say that, at most, we will only be needing to store data for an excerpt, status for workflow, attribution/author user ID, article thumbnail/preview image ID, and date published time if we decide to make it separate from the DateInserted column.
The key thing is only put columns in the data base that you want to query/join on, or can be useful to other applications (the use of, not implementation of). So, DatePublished, Status, Author. Everything else should be either an attribute, or in a separate table.
The reasoning of this is since you are modifying the discussion table, EVERY discussion will have these fields.
Comments
@shadowdare wrote:
But this is actually an advantage because it's up to the admin to manage how they want things to appear. It would be nice to have a visual in the discussion list to show that an entry is an article (in fact, it would be nice to have such visual to every type). Perhaps "Discussion Prefix" like plugin could be created to add a visual to all discussions types (polls, events, articles, questions, even Bug-tracker I saw someone was working on).
That actually sounds like a good idea. The QnA plugin already does that itself, so just adding an option into this proposed rewrite of Articles should do the job. Having the admin going into each category settings page and clicking the check boxes to "convert" them to article categories does sound tedious, but it sounds like a good idea to make use of the built-in Vanilla discussion type functionality.
Categories that has more than one discussion type set, including articles, can have the discussions index show a discussion prefix to indicate that a discussion is an article among all mixed types of discussions. This could bring up an inconsistency with the index listings being different from how articles and discussions will be shown independently in the profiles and in other places on the forum.
The best way to use articles is to have categories with only the articles type set. They can have a modified display or entirely new view that will show discussions in article content style with the excerpt/full text, thumbnails, and so on.
I have been busy this week and will still be in the upcoming weeks, but I'll try to look into how we can rewrite and integrate articles into Vanilla better and see how it turns out. I've already got a development application set up to work on this.
Add Pages to Vanilla with the Basic Pages app
Let's say that, at most, we will only be needing to store data for an excerpt, status for workflow, attribution/author user ID, article thumbnail/preview image ID, and date published time if we decide to make it separate from the DateInserted column.
There are a couple main ways this could be done:
falseindicating that it's pending review.What do you recommend, @hgtonight? This reminds me of the "Modifying existing table structure - best practices?" discussion.
Add Pages to Vanilla with the Basic Pages app
The key thing is only put columns in the data base that you want to query/join on, or can be useful to other applications (the use of, not implementation of). So, DatePublished, Status, Author. Everything else should be either an attribute, or in a separate table.
The reasoning of this is since you are modifying the discussion table, EVERY discussion will have these fields.
This is an interesting case.
Search first
Check out the Documentation! We are always looking for new content and pull requests.
Click on insightful, awesome, and funny reactions to thank community volunteers for their valuable posts.