Awesome extension, great job!

Very small nitpick: When returning via your browsers back button to the category view the scroll position is not saved. Is it possible to save and restore it?

8 days later

Unfortunately, there's a bug in the tags extension about getting / refreshing the last discussion. I've openned a PR here: flarum/tags78.

One temporary workaround I'm considering is adding a console command that would refresh discussion/comment/last posted discussion count, and could be run regularly as a cron job. This would provide a temporary workaround to that issue. If there's interest in something like that, please let me know!

by the way, I just realize, this extension slows down homepage loading (load fine visible part but the "x" above left of the browser keeps more time)

    teletubbie by the way, I just realize, this extension slows down homepage loading (load fine visible part but the "x" above left of the browser keeps more time)

    Could you provide a link to a forum that's experiencing this issue so I could look into it? Thanks!

      askvortsov
      ok, I just enabled the extension, let me know when you've seen it to disable it again. thanks!
      [deleted url]

      The entire site is quite slow for me (regardless of which page I'm on). Does that only happen when categories is enabled?

        askvortsov
        I just disabled the extension, check again please.
        My admin panel load slow too when the extension is enabled.

        V1.0.0: The Performance Update

        ** Please note that this version requires Flarum beta 13.

        Upgrading

        composer require askvortsov/flarum-categories ^1.0.1
        php flarum migrate
        php flarum cache:clear

        Changes

        • Massively improved performance, the bigger your forum, the better the improvement. If you have a small forum with 3 categories and 20 posts, there probably wont be that big a difference. But if you have an enormous forum, changes should be tremendous. However:

          • Private discussions / posts are no longer counted in stats. This is required to make these performance improvements possible.
          • Discussions/posts in a subtag that people can't see, WILL be counted in the parent tag's count. Once again, not that much of an option here (needed for performance): if this is a dealbreaking issue, use a previous version, or reorganize your forum a bit.
        • If these are deal breaking issues, you can turn on 'Small Forum Optimized' mode in settings to use the previous system. Please keep in mind that this is only recommended for small forums, and WILL slow down your forum as it grows. Even so, that mode has also been improved a fair bit thanks to @luceos. That being said, on medium-large forums (and probably on most small ones too, if we're being honest), no one is counting / checking how many discussions / posts there actually are, so the above 2 "drawbacks" are a non-issue, and 'Small Forum Optimized' mode should be turned off.

        • A new console command, php flarum tags:recalculate_stats, will update the post count, discussion count, and last posted discussion info for all tags. You can run this manually, or set up a cron script to run it automatically on an interval. After flarum/tags78 is merged, discussion count and last posted discussion should become A LOT more accurate, but even then, occasionally recalculating these stats cannot hurt. This command uses a raw SQL script to boost performance, meaning that it can be run regularly even on very large forums.

        • A unique CSS class has been added to every category, meaning that you can use custom CSS to customize individual categories (e.g. to add background images). On that note, if there emerges an extension / functionality in tags to upload background images, I WILL add support for that in categories, but I do not currently plan to develop that for categories by itself.

        • Post count and discussion count will always return an integer.

          V1.0.1

          • Fixed php flarum tags:recalculate_stats not working with database prefixes

          askvortsov The update really saves TTFB for me! But how about use Laravel command scheduler instead of php flarum tags:recalculate_stats like what Diff extension doing?

          16 days later

          Is it possible that the tags:recalculate_stats does not work if there are no posts in a particular tag?

          I have been migrating posts from phpBB to Flarum (using my own PHP script to populate the database directly) and I have your extension installed. I have been migrating the posts and then deleting them all various times while testing the migration. I have just deleted all of the posts I had migrated and ran tags:recalculate_stats to reset all of the numbers back to zero but it didn't reset the numbers in any of the tags which now have zero messages in them. There was one tag which had just one message remaining and the stats were correctly reset for that tag, but all of the others continue to show the number of posts and discussions that they showed before, even though they are actually empty.

            Yes, I updated to the most recent Flarum Categories extension to ensure it wasn't fixed in the new version, so did:

            composer require askvortsov/flarum-categories ^1.0.1
            php flarum migrate
            php flarum cache:clear
            php flarum tags:recalculate_stats

            Interestingly, when I run tags:recalculate_stats it outputs a number which seems to be the number of tags which have been recalculated, so while I have about 100 tags, only 1 has posts in it, and the number output is 1. When I fill up a second tag with posts then the number increases to 2.

            Looking at the source code I can see that the SQL is filtering out all tags with no posts, that's why it isn't working. By moving the WHERE into the LEFT JOIN it seems to fix it. I changed the file sql/update_all_data.sql to this:

            UPDATE [PREFIX]tags tags,
              (
                SELECT
                  a.tag_id as tag_id,
                  a.discussion_count as discussion_count,
                  a.post_count as post_count,
                  b.last_posted_discussion_id as last_posted_discussion_id,
                  b.last_posted_at as last_posted_at
                FROM (
                    SELECT
                      t.id as tag_id,
                      count(td.discussion_id) as discussion_count,
                      COALESCE(sum(d.comment_count), 0) as post_count,
                      MAX(d.last_posted_at) as max_last_posted_at
                    FROM [PREFIX]tags t
                    LEFT JOIN [PREFIX]discussion_tag td ON t.id = td.tag_id
                    LEFT JOIN [PREFIX]discussions d ON td.discussion_id = d.id
                    AND d.is_private = FALSE AND d.hidden_at IS NULL # Moved this line here instead of in a WHERE
                    GROUP BY
                      t.id
                  ) AS a
                LEFT JOIN (
                    SELECT
                      d.id as last_posted_discussion_id,
                      d.last_posted_at as last_posted_at,
                      td.tag_id
                    FROM [PREFIX]discussions d
                    LEFT JOIN [PREFIX]discussion_tag td on d.id = td.discussion_id
                    WHERE
                      d.is_private = FALSE
                      AND d.hidden_at IS NULL
                  ) as b ON a.max_last_posted_at = b.last_posted_at
                  AND a.tag_id = b.tag_id
              ) AS source
            SET
              tags.discussion_count = source.discussion_count,
              tags.post_count = source.post_count,
              tags.last_posted_at = source.last_posted_at,
              tags.last_posted_discussion_id = source.last_posted_discussion_id
            WHERE
              tags.id = source.tag_id;