Vanilla 2.5 Articles

kopna

how to fix this error

kopna

sorry, updated the version, it not works

Shadowdare

Here is the fix for that: https://github.com/austins/Vanilla-App-Articles/commit/a83d18c589e3731ae9345119ae247f507b05dc98

You should be able to install it with this fix, but Articles doesn't support Vanilla 2.5 yet. Some links will not work and there will be design issues. I will work on an update when I get time.

kopna

@Shadowdare thanks for the answer
I will wait for the application update

rbrahmson

and there will be design issues.

I repeat my preference of using a new discussion type rather than an entirety separate application. I believe it will better integrate with all the other plugins, be more compatible and in the long run simpler to maintain.

Shadowdare

@rbrahmson, I may revisit the idea in the future. Both ways have their own benefits. I haven't checked, but it's possible that the new dashboard might make it easier to configure discussion types for each category unlike previous versions, which was a factor in going the standalone way.

rbrahmson

I had no hesitation of using a different discussion type in my FeedDiscussionPlus plugin (imported discussions has a "Feed" type). I also use my filter discussion plugin to create filtered discussion lists so it's easy for me to only look at feeds (or not) based on the type. All in 2.3 (I still have to try matters in 2.5)

Ayb

@Shadowdare, This is such a great plugin... any plans on updating it for 2.5.1?

Shadowdare

@rbrahmson said:
I repeat my preference of using a new discussion type rather than an entirety separate application. I believe it will better integrate with all the other plugins, be more compatible and in the long run simpler to maintain.

I'm revisiting this discussion type concept. The main advantages would be immediate support for Vanilla discussion features, such as bookmarks, notifications, permissions system, and moderation. Additionally, addons that modify discussions, such as Yaga, would work without any modification. Articles can show up in discussion indexes, increasing visibility of new comments and promoting more discussion. Furthermore, it may be cleaner just to use the built-in Media model for thumbnails and so on.

Adding a new discussion type has some quirks, but I hope we can make it work.

• When adding a custom discussion type, it is enabled on all categories by default. In order to limit the types of new discussions a category can take, you have to go edit the category and then toggle the custom permissions to see a list of types to select. Assumption: admins would likely have "article contributors/authors" be opt-in by role, so we should somehow disable this default behavior on all categories. Would an admin find it inconvenient if we just let it stay auto-enabled and having to go to set custom permissions for each category? This is how Vanilla implemented their custom discussion types system.
• A visitor of your website will browse articles and experience them as being abstractly different from discussions: (1) the articles index would look different than the discussions index, of course, with thumbnail images, excerpts and large headers, (2) sidebar would show only categories that allow the article type, (3) links within the article view and article categories module would link to a custom category controller action that shows a view like the articles index. Handling proper display and separation of categories from the articles controller and discussions controller all the way to user profile indexes should be approached with attention to detail because I think articles should be separated from discussions in some places.
• When I first created the Articles app, I was still learning the ways of Vanilla and copied a lot of code from the forum components. In this discussion type concept, there would still be some code borrowed over from Vanilla, such as index logic and views since there just aren't enough events to hook into or something has to be modified in the middle, but the rest of it requires the same code, etc.
• Special case: users may want to hide articles from all discussion indexes and only show it on the articles index. Probably don't need this, but it can be added in as a config option toggle and a where clause to DiscussionModel if there are sufficient events to inject code.

This project would introduce "breaking changes" and proper instructions on upgrading would need to be written and carefully followed by admins. An export/import script would probably have to be made.

rbrahmson

The issue of which discussion types to display and where (and when) could be handled with filters. In our intranet we did it with the filter discussion plugin but of course it could be done within the articles app/plugin itself.

rbrahmson

Until such time where plugin developers get stats on how many users actually use their plugins I'd consider not coding the migration script.

Shadowdare

I already put together a new test addon for this concept to see how it goes. I store article metadata in a table called Article with columns ArticleID, DiscussionID, UrlCode, Excerpt, and Status. More fields can be added later such as thumbnail media ID. Discussions are saved from the /post/article page with "Article" in their Type column.

One implementation of joining the article metadata:

Plugin event handler

    public function discussionModel_setCalculatedFields_handler($sender, $args) {
        if (val('Type', $args['Discussion']) === 'Article') {
            (new ArticleModel())->joinArticle($discussion);
        }
    }

ArticleModel

    public function joinArticle(&$discussion) {
        // Enforce type for now and if data has already been joined (see the "pre-query" join example below)
        if ($discussion->Type !== 'Article' || isset($discussion->ArticleID)) {
            return;
        }

        // Join article metadata "post-query"
        $article = $this->getByDiscussionID($discussion->DiscussionID);
        if ($article) {
            $discussion->ArticleID = $article->ArticleID;
            $discussion->UrlCode = $article->UrlCode;
            $discussion->Excerpt = $article->Excerpt;
            $discussion->Status = $article->Status;

            // Overwrite link to discussion
            $discussion->Url = articleUrl($discussion);
        }
    }

The above event handler is run after the discussion query get and it works thanks to the setCalculatedFields event that's fired in every get method in DiscussionModel. However, the results can't be filtered before pagination.

The best way to filter discussion queries is to join the data before the query is run so we can add in proper wheres statements that will provide proper results before pagination (see below), but it seems to have some quirks as well because it seems like beforeGet event gets called on nearly every method except getID. There is an event in getID, but it's before the SQL statement gets built, unless you can set a where clause before that out-of-order? Of course, this would attach these properties to all discussion objects; there probably won't be conflicts with the names, but a prefix can easily be added.

    public function discussionModel_beforeGet_handler($sender) {
        $sender->SQL->select('a.*')->leftJoin('Article a', 'a.DiscussionID = d.DiscussionID');
    }

Anyway, I'm not sure if we need to join the actual query yet as I haven't got to the point in this test addon I just created to need to filter the results pre-query. Could probably use d.Type != 'Article'.

rbrahmson

Why dealing with joins when the articles themselves can be discussions with type "discussion"? Also, you could similarly handle versioning in comments under the discussion (filtering/hiding as you see fit). I'd go all the way into discussions....

Shadowdare

I have a join table for article metadata because I don't want to clutter the discussion table with extra columns that many other discussions won't be using and it's nicer than using the discussion built-in serialized attributes column for sure.

Another issue I just thought of is the article workflow. Discussions already have drafts, which don't get saved as real discussions, but as an entry in the "Draft" table/model. Have you ever tried to create a Q&A post, save it as a draft, but come back to the draft and it gets converted into a normal discussion? I submitted an issue/pull-request a while ago to add "Type" column to the built-in Drafts as it doesn't store that, but it hasn't been implemented.

I'm thinking of going around this by removing the "save draft" button and just sticking with the style that the current Articles app has. This would probably require the pre-query join in order to filter the results based on article status.

Trying to discuss out potential quirks, edge cases, and anything that may prevent functionality that I hope to have in an articles addon. If it works out, I hope to keep it as Vanilla as possible apart from having to copy some code here and there and possibly having to hack a few things, but it should be more awesome than the non-discussion-type way.

Shadowdare

@rbrahmson, better go all-in on discussions. One of the reasons back then was maybe someone wants to just have a blog that runs better than WordPress and not a forum, but it's clear that, while Vanilla is built upon Garden framework, it's meant to stay enabled, so separation from forum isn't a necessary point now.

@Ayb said:
@Shadowdare, This is such a great plugin... any plans on updating it for 2.5.1?

Thank you Are you using Articles in production? I use Articles on a website where I replaced WordPress with 100% Vanilla and it's definitely made everything awesome nonetheless, but I would like to get something out for Vanilla 2.5+ too so we all can upgrade.

rbrahmson

Another issue I just thought of is the article workflow.

One of the unreleased plugins we have in our intranet has a work flow implementation. It's sort of a support system where "discussions" are assigned to users. We did it by adding an "assignee" column to the discussion table and change the value in that field by user actions and rules derived from another table. Assignees see their "tasks" through filters on that column. Dialogs regarding the "case" are stored in the normal content. Very simple and clean.

You may consider a variant of that concept.

rbrahmson

I wouldn't use the vanilla"draft" state as your article draft state. While the word is the same the meaning in the article app is different. Vanilla draft state is the state before the discussion "article" is created. Your article draft state is until it is published. So rather than hiding it I'd consider renaming it so that the terms wouldn't be confusing to the user. As for the articles draft state, I'd store the "state" in a new discussion table column where you may keep the article state (draft, published, in review, etc.)

R_J

@Shadowdare said:
The best way to filter discussion queries is to join the data before the query is run so we can add in proper wheres statements that will provide proper results before pagination (see below), but it seems to have some quirks as well because it seems like beforeGet event gets called on nearly every method except getID. There is an event in getID, but it's before the SQL statement gets built, unless you can set a where clause before that out-of-order?

Are you speaking of

    public function getID($discussionID, $dataSetType = DATASET_TYPE_OBJECT, $options = []) {
        $session = Gdn::session();
        $this->fireEvent('BeforeGetID');

        $this->options($options);

        $discussion = $this->SQL

You can use discussionModel_beforeGetID_handler($sender) { and then $sender->SQL->where... without a problem. I've done that in one of my never released plugins and Bleistivt did this in his UnsubscribeDiscussion plugin.

But is getID really a problem? When a dedicated "discussion" is requested and it is an article, shouldn't the request be made from an Article page? Was that understandable?

When drafts are a problem, why not create a second Articles category called "Drafts"? That would ensure that no information is lost which can be part of an Article.

Shadowdare

Absolutely right, @R_J. Yeah, there will still be special controllers for articles, especially since they'll require a little bit of different views than normal discussions.

The code may be useful to join the article data--perhaps prefix it like "ArticleExcerpt" but still keep it stored in the extra table--in case I want to filter out the articles from the discussion results for some features and views. The performance impact of a small join over many discussions is likely minuscule.

I'll see what I can come up with.

K17

Hey @Shadowdare is there something planned ?