Blog Documentation Book a Demo
HackerOne users: Testing against this community violates our program's Terms of Service and will result in your bounty being denied.

Articles Rewrite: Concept

ShadowdareShadowdare MVP
edited January 2016 in Feedback

I've written down a conceptualization for the Articles application rewrite for you all to see outlining some of the main functionality. The rewrite will be released as Articles v2.0.0 when it's finished.

Fellow developers, please have a look at the questions at the bottom of this post. I would like your feedback on this. =)

OBJECTIVE

Create an application that provides a way for Vanilla Forums users to publish articles.

This will be a rewrite of the current Articles application, which is independent because it has its own article model. It will be implemented with Vanilla 2.2 using the existing Vanilla discussion model as the base functionality.

As a result, the new "Article" content type inherits all functionality of Vanilla discussions, comments, and categories, so it's not necessary to list out the inherited features below.

DEVELOPMENT

The features listed below are tentative.

Key Functionality

  • Ability to set permissions for article categories. Necessary permissions include: add, close, delete, and edit for both articles and article comments. These permissions already exist in the Vanilla category model.
  • Be compatible with addons such as Advanced Editor and the Yaga application.

Main Features (more within the conceptualization below)

  • [v2.0.0] Ability to change the display author for an article if the current user has edit permission, also known as the "attribution author." This could just modify InsertUserID.
  • [v2.0.0] Profile fields for users who have permission to write articles: author bio and author display name.
  • [v2.0.0] Ability to upload images to be embedded within an article. This could be provided by the Advanced Upload plugin.
  • [v2.0.0] Ability to upload an article thumbnail. This will be separate from the Advanced Upload plugin.
  • Toggle-able guest commenting for articles.
  • Publishing workflow consisting of draft, pending review, and published article states. This must work smoothly with permissions.

Modules

  • Article categories module. Articles could be hidden from discussion indexes and Vanilla categories designated as article categories will be hidden from the Vanilla views.

Database Structure Additions

Here is a list of properties necessary for articles along with alternative names (see questions below).

Article (new table)

-> ArticleID
-> DiscussionID
-> UrlCode
-> Excerpt
-> Status (possible values: Draft, Pending, Published, Trash / could work with DraftModel)
-> ArticleThumbnailID

Reasoning for new table: Discussions don't need fields like UrlCode since Vanilla uses the discussion ID in URLs to select discussions so it wouldn't be clean to put the field in a new column in the Discussion table and, for articles, UrlCode needs to be queried on to check for uniqueness, so it wouldn't be efficient to set it as an attribute for discussions; therefore, a new table is the cleanest way to implement these fields. Subsequently, the other article-related fields should be in this table since they aren't used for non-article type discussions in general to keep things clean.

Comment

-> GuestName / ArticleGuestName
-> GuestEmail / ArticleGuestEmail

User

-> CountArticles (for de-normalization purposes if articles are to be "detached" from the discussion indexes)

ArticleThumbnail

-> ArticleThumbnailID
-> ArticleID
-> Name (e.g., "ABC1XYZ5DLMF.jpg")
-> Path (e.g., "articles/2015/12/ABC1XYZ5DLMF.jpg")
-> Type (e.g. "image/jpeg")
-> Size
-> ImageWidth
-> ImageHeight
-> DateInserted
-> InsertUserID

UX

[v2.0.0] Articles Page

  • List articles in a single-column blog style format that is paginated. If an article has a thumbnail, it will be displayed to the left of the article. If an article has an excerpt, the excerpt will be displayed; otherwise the complete article body will be shown.

[v2.0.0] Article Page (Single)

This page will consist of two parts: the article display and the article comments.

  • The article display can use the same view as discussions do, but I may create a new one in order to utilize HTML5 elements and display an author info box.
  • The article comment display can use the same view as comments do.

Discussions Index

  • Articles won't be hidden alongside discussions and will have a tag that says "Article" in the meta.

[v2.0.0] Categories Index

An ArticlesController->Categories() method could be added to display only articles in reverse chronological order, but for now, let's just stick with the Vanilla categories index.

  • Articles won't be hidden alongside discussions and will have a tag that says "Article" in the meta.
  • Articles will have their thumbnails and excerpt text shown next to it if it has one or a sliced version of the body text.

User Profile Page

  • [v2.0.0] In the user's discussion tab: (1) articles won't be hidden alongside discussions and will have a tag that says "Article" in the meta, and (2) articles will have their thumbnails and excerpt text shown next to it if it has one or a sliced version of the body text.
  • Articles may be hidden from the user's discussion index and shown on a new tab called "Articles." This tab will only be shown if the user is an author (can write articles) or if their article count is greater than zero.
  • Article comments will be shown as normal alongside the existing "Comments" tab.

[v2.0.0] Compose Article Page

  • It will look similar to the discussion post page, but with new fields for: article URL code (slug), excerpt, article thumbnail, attribution user name, and article status.

Compose Dashboard

This page will be a place for authors to view the latest articles in a list, latest comments on articles, and so on like the dashboard in WordPress. Users with the appropriate permissions will be able to see articles pending review and possibly others' drafts.

QUESTIONS

I'm trying out the built-in types system like what the QnA plugin does. One issue is that that the setting to select which types of discussions can be made in a category is a bit hidden and could let people mix different types of posts into a category. (see: this image) On the other hand, if we don't need to hide articles from the discussion indexes and have them be displayed instead, this won't be a problem.

Alternatively, I can do what BlanderBlog does, where you can check categories you want to designate as blog categories and their IDs will be stored in an array in the config file.

  • How "detached" should articles be or appear from discussions?
  • Should they be hidden from the discussion indexes?
  • How should discussion counts and article counts be dealt with?

Other Questions

  • Would any of the proposed features be nearly impossible or too much trouble to implement using the Vanilla discussion model?
  • Which database structure properties for the Discussion and Comment tables should be stored within the existing "Attributes" column and which should have their own columns? (see: Articles Idea: Category-Based Permission Model and this post)
  • [Profile fields feature]: since permissions to add articles will be per-category, how could we determine if a user has the permission to write articles?

If you have any other questions or ideas, feel free to leave a comment here.

Add Pages to Vanilla with the Basic Pages app

Tagged:

Comments

  • LincLinc Admin

    @Shadowdare said:

    • [Profile fields feature]: since permissions to add articles will be per-category, how could we determine if a user has the permission to write articles?

    Check out the NewDisussionModule.

    Gdn::session()->checkPermission('Vanilla.Discussions.Add', true, 'Category', 'any');

  • ShadowdareShadowdare MVP
    edited January 2016

    I've been keeping up development of the rewrite and everything's progressing well so far.

    Articles are essentially discussions that have their Type field set to Article. I've created another table in the database to store article data for discussions. This table is called GDN_Article and it contains these columns at the moment:

    ArticleID
DiscussionID
UrlCode
Excerpt

    I have the code working such that discussions are joined with article data via the SetCalculatedFields event that's fired in the DiscussionModel. The join works by retrieving the entry from GDN_Article with the discussion ID. This works fine and there are no problems.

    My question is: would it be better to remove the DiscussionID column from GDN_Article and add an ArticleID column in GDN_Discussion? In other words, how should the foreign key be implemented for this "1-0..1" relationship? In any case, the result is the same, but is there any reason to do one database schema design over the other as described above?

    @Linc said:
    If I had a plugin that would selectively add quite a bit of data to discussions (as in, only some discussions, and lots of data I'd need to query on) I might favor the separate table approach, but probably not outside that use case. That's how we do Polls, for instance, but not Q&A, which uses new columns.

    (source: Modifying existing table structure - best practices?)

    @Linc: where does Polls store its foreign ID?

    Thanks in advance to anyone who would like to add their thoughts on this. :)

    Add Pages to Vanilla with the Basic Pages app

  • LincLinc Admin

    @Shadowdare said:
    @Linc: where does Polls store its foreign ID?

    We currently do as you do: a DiscussionID column on GDN_Poll.

  • rbrahmsonrbrahmson ✭✭✭

    When I first proposed using the discussion model for articles I listed the advantages of leveraging everything that is supported by the model. I'm thrilled that you accepted that notion and seeing Link's note above I add my vote (for whatever it is worth) that you add fields to the discussion table rather than keep data in a separate table. I think it will make plugin support much easier, especially for already written plugins.

  • ShadowdareShadowdare MVP
    edited January 2016

    I have completed a lot of the main features and pushed out the latest code in the develop branch of the Articles GitHub repository. :)

    Alpha Testing

    I would like help from other developers and members who are interested in testing the current development code (2.0.0a3) if you all have a chance sometime soon to test it out and see how it looks so far. @hgtonight, @Bleistivt, @R_J, @vrijvlinder, etc.

    Important Info

    • Do not use the code from the Articles develop branch in a production install of Vanilla.
    • There is currently no upgrade path from Articles v1, so this must be installed on a new development-only install of Vanilla where Articles has never been installed.

    Grab a zip file from the develop branch on GitHub and copy the files into a folder called articles within your Vanilla's /applications folder and enable it from the dashboard. Allow certain categories to have articles posted in them (see: this image) and then post some articles from the front-end.

    You're going to need to make this small change to a core Vanilla 2.2 file: https://github.com/vanilla/vanilla/commit/9dc6b2bb81342422da720d9d81d1b2696058d572

    Notes / Looking for Feedback

    Apart from the awesome features you could already see, such as being able to set permissions of categories, bookmark an article, more addon compatibility, and so on, here are some things to take note of while testing it out.

    • Guest commenting hasn't been implemented. In order to provide an upgrade path, this should be implemented. How could we do it with the Vanilla comment model? We could refer to @Linc's Glue plugin.
    • I've decided to not implement threaded comments for this release at the moment. What do you think?
    • Drafts, now using the discussion model, don't save with all the necessary data yet. Articles will use DraftModel->save() events to store article form input in the Attributes field. See: Storing Discussion Type with Drafts
    • No custom permissions have been added. Permissions can be set via categories. However, how can we check to see if the user can post within a category where the article type could be posted? Perhaps do something similar to the category selector in the PostController form. This could be used to hide the "article author display name / author bio" fields from the profiles and while editing them. Fixed: the discussionTypes can have an AddPermission key.
    • There's no compose dashboard at the moment since you could have a category called "Pending Review," for example, then re-post them into public categories and change the authors. What would be a better workflow that works alongside the Vanilla discussion model?
    • Articles are shown alongside discussions in indexes and counts aren't separated, so I didn't create an "articles" profile page index or a category page displaying articles in reverse-chronological order.
    • To-do: update the social media buttons plugin after this has been released, or since the ArticleController mimics the DiscussionController, perhaps we can just use the built-in social plugins, such as the Facebook, Google+, or Twitter plugins, which adds a little icon under discussions and comments to share them. This has to be tested to see if we can modify the text that gets created for those share buttons if necessary.
    • You can embed images in articles by uploading them via the Advanced Editor, so you should enable the Advanced Editor plugin.
    • The Yaga application (development version) works from what I've tested so far. Try some other addons that you use that add to discussions, but shouldn't show up in articles, that you think may cause conflicts.
    • Mimicing the DiscussionController could possibly cause conflicts, but so far, I believe it is a better option for complete compatibility with the Advanced Editor - although we could possibly call Advanced Editor's attachUploadsToComment() method via class.hooks.php and addons such as Yaga could target the ArticleController alongside the DiscussionController, in which case we could rename some events.
    • If you remove a role's permission to add to all categories that allow the article type, the PostController->Article() method could still be viewed.

    This is certainly a very large project for one person to do alone, so please feel free to contribute and submit a pull request on GitHub with any changes and bug fixes you may have. Thanks in advance for any help. =)

    Add Pages to Vanilla with the Basic Pages app

Sign In or Register to comment.