Skip to content

Threaded post support for NodeBB

Let's Build It
  • odd i see this code in dev console, search better 🙂

    I see too li.pt-4.self-post.highlight.threaded I don’t have this

    EDIT :

    yes resolved by this code :

    .page-topic .topic .posts.timeline .timeline-event.highlight, .page-topic .topic .posts.timeline > [component="post/placeholder"].highlight, .page-topic .topic .posts.timeline > [component=post].highlight.threaded {
        border: 2px solid var(--bs-post-unread) !important;
        border-radius: var(--bs-border-radius);
    }
    
    li.pt-4.self-post.highlight.threaded {
        margin-left: 0rem !important;
      }
    

    – RESULT :

    blink2.gif

  • Here I am again Mark @phenomlab 😉

    I am contributing to this code to add a tooltip to the button.

    The position can be changed according to your wishes.
    For my part, I prefer to put it at the bottom because if we put it at the top it can be annoying.

    Tell me what you think about it ?

    function threaded() {
        $(document).ready(function () {
            // Check if the screen width is 1200px or more
            if ($(window).width() >= 1200) {
                // Check if the dropdown already exists
                if ($('#enableThreading').length === 0) {
                    var threadView = $('<div class="threads-wrapper"><i class="fa fa-fw fa-bars left"></i><form class="form"><div class="form-check form-switch sticky-tools-bar"> \
                        <input class="form-check-input" id="enableThreading" type="checkbox" data-field="enableThreading"> \
                        <label class=" d-none d-md-inline fw-semibold" for="enableThreading"><i class="fa fa-fw fa-bars-staggered right"></i></label> \
                    </div></form></div>');
                    $('.topic .sticky-tools ul [component="topic/browsing-users"]:last-of-type').append(threadView);
                    // Check if there's a stored state for the checkbox and update it
                    var storedState = localStorage.getItem('enableThreadingState');
                    if (storedState === 'true') {
                        $('#enableThreading').prop('checked', true);
                    }
                }
                
                // Add a tooltip to the button
                $('#enableThreading').tooltip({
                    title: 'Thread View On/Off', // Replace with your tooltip text
                    placement: 'Bottom', // Adjust the placement as needed
                    trigger: 'hover', // Show tooltip on hover
                });
                
                // Toggle the class 'threaded' on or off when the checkbox changes state
                $('#enableThreading').on('change', function () {
                    var isChecked = $(this).is(':checked');
                    if (isChecked) {
                        console.log('Thread view is active.');
                        $('ul[component="topic"]').addClass('threaded');
                        $('.posts-container').addClass('threaded');
                        $('ul[component="topic"]').addClass('threaded');
                        $('.post-container').addClass('threaded');
                        $('.timeline-event').addClass('threaded');
                        $('[component="post/footer"]').addClass('threaded');
                        $('[component="post"]').each(function () {
                            // Add the 'threaded' class to matching elements
                            if ($(this).hasClass('pt-4') || $(this).hasClass('self-post')) {
                                $(this).addClass('threaded');
                                $('.topic .sticky-tools').addClass('threaded');
                            }
                        });
                    } else {
                        console.log('Thread view is inactive.');
                        $('[component="post"]').removeClass('threaded');
                        $('ul[component="topic"]').removeClass('threaded');
                        $('.posts-container').removeClass('threaded');
                        $('ul[component="topic"]').removeClass('threaded');
                        $('.post-container').removeClass('threaded');
                        $('.timeline-event').removeClass('threaded');
                        $('[component="post/footer"]').removeClass('threaded');
                        $('.topic .sticky-tools').removeClass('threaded');
                    }
                    // Store the checkbox state in localStorage
                    localStorage.setItem('enableThreadingState', isChecked);
                });
                // Check for changes in the checkbox state when the page loads
                $('#enableThreading').trigger('change');
            }
        });
    }
    
    $(window).on('action:ajaxify.end', function (data) {
        threaded();
    });
    
    $(window).on('action:posts.edited', function (data) {
        threaded();
    });
    
    $(window).on('action:posts.loaded', function (data) {
        threaded();
    });
    

    CYA my friend

  • @DownPW looks good to me 😀 I started to write this a few days ago, but got sidetracked and never finished it.

    Good job.

  • I forgot the screen 🙂

    image.png

  • @DownPW looks great.

  • And just modified this for better display (centered)

    .threads-wrapper {
        display: flex;
        position: relative;
        /* top: -2px; */
        top: 1px;
    }
    
  • @DownPW yes, it was styled for this site because it uses heavily modified css.

  • @phenomlab

    I note, however, that here on Sudonix, our own posts and those of other users are not shifted (to the left). Only those of the author of the topics are.

    In the code you provide on Github, the author’s posts and those of others are shifted (to the left), only our own posts are not.

    I do not know if it’s normal.

    It actually seems logical to me that only our own posts are not shifted to just better identify our own posts

  • @DownPW Correct. The design in DEV and the code on Git reflects the points you raised, which is why it was developed from scratch in DEV and was not a copy of PROD. It’s a matter of personal taste 🙂 You can fairly easily change the cosmetic behavior to suit your needs - it’s not set in stone.

  • @DownPW Maybe go one better perhaps, and toggle the on/off state depending on the switch selection (I’m doing that here)

    See https://github.com/phenomlab/nodebb-harmony-threading/blob/main/functions%2Cjs

    Enabled

    9a9261ae-7730-4212-a650-04bf1d6807ba-image.png

    Disabled

    ce2cb828-32a9-4c95-905a-4b8f84a24bd0-image.png

  • it’s cool too ^^

  • this code does not work for me. No button

    EDIT:

    The code on github is OK, not the last share above

  • @DownPW said in Threading support for NodeBB:

    The code on github is OK, not the last share above

    Sorry - changed that to the Git link

  • Just don’t forget to comment out lines for browsing-users plugin

    I’m got screwed 😉

    Good work my friend

  • @DownPW This part?

    $('.topic .sticky-tools ul .hidden-xs').append(threadView);
    // If you have browsing users plugin, comment out the above line and uncomment the one below
    //$('.topic .sticky-tools ul [component="topic/browsing-users"]:last-of-type').append(threadView);
    

    Yes, I need to fix that! Thanks for the reminder.

  • For anyone else browsing here who has tried the code in git but wants it to look exactly like Sudonix, please note that this code is not public because it is heavily adapted to match the layout of this site. There are some Sudonix “clones” around so you can actually have this code if you really want it, but it comes with some conditions;

    1. You should consider buying me a coffee - see “Buy me a Coffee” link
    2. You have to provide a backlink to this site from your own - it needs to be visible and cannot be hidden - obviously, I can’t (and won’t) make you do this, but it’s courteous to recognize the original author - particularly when hundreds of hours were spent creating all of this eye candy 🙂
  • Hello @phenomlab

    I see this, when someone composes, it is displayed via the plugin like this (To the left of the Thread View button.). I do not know if it’s normal or if it is better to put it on the right like the others ?

    image.png

    or myself for example :

    33a99e14-13e5-4e67-beaa-25d02b39bb59-image.png

  • @DownPW Mmmm - I thought that this would happen. In your js function, can you locate this line

    $('.topic .sticky-tools ul .hidden-xs').append(threadView);
    

    Replace it with

    $('.topic .sticky-tools ul.list-unstyled').append(threadView);
    

    51179c3a-e0cf-4f1f-a36b-79beb1655e88-image.png

    The issue here is that the hidden-xs class is being manipulated by js which forces the position and does not use relative. This new code should hopefully work around that. It will change the placement of the threaded toggle, but for the better I think. If this works, I’ll commit the code to git

  • @phenomlab

    I don’t use this line, I commented out this line as stipulated in the script

    $('.topic .sticky-tools ul .hidden-xs').append(threadView);
    

    But use this line :

    $('.topic .sticky-tools ul [component="topic/browsing-users"]:last-of-type').append(threadView);
    

    image.png

    maybe change for this ?

    $('.topic .sticky-tools ul.list-unstyled [component="topic/browsing-users"]:last-of-type').append(threadView);
    

Related Topics
  • 3 Votes
    2 Posts
    92 Views

    Very great 😉

  • Material View Support for Stock NodeBB

    Unsolved Let's Build It
    51
    15 Votes
    51 Posts
    3k Views

    Oh yes, that’s what’s super cool, I learn something every day. Afterwards I start from so low in JS

  • Threaded chat support for NodeBB

    Let's Build It
    35
    19 Votes
    35 Posts
    2k Views

    @DownPW said in Threaded chat support for NodeBB:

    Better like this : add shadow and border-left on self answer

    Of course - you style to your own requirements and taste 🙂 I’ll commit that CSS we discussed yesterday also

  • Nodebb design

    Solved General
    2
    1 Votes
    2 Posts
    271 Views

    @Panda said in Nodebb design:

    One negative is not being so good for SEO as more Server side rendered forums, if web crawlers dont run the JS to read the forum.

    From recollection, Google and Bing have the capability to read and process JS, although it’s not in the same manner as a physical person will consume content on a page. It will be seen as plain text, but will be indexed. However, it’s important to note that Yandex and Baidu will not render JS, although seeing as Google has a 90% share of the content available on the web in terms of indexing, this isn’t something you’ll likely lose sleep over.

    @Panda said in Nodebb design:

    The “write api” is preferred for server-to-server interactions.

    This is mostly based around overall security - you won’t typically want a client machine changing database elements or altering data. This is why you have “client-side” which could be DOM manipulation etc, and “server-side” which performs more complex operations as it can communicate directly with the database whereas the client cannot (and if it can, then you have a serious security flaw). Reading from the API is perfectly acceptable on the client-side, but not being able to write.

    A paradigm here would be something like SNMP. This protocol exists as a UDP (UDP is very efficient, as it is “fire and forget” and does not wait for a response like TCP does) based service which reads performance data from a remote source, thus enabling an application to parse that data for use in a monitoring application. In all cases, SNMP access should be “RO” (Read Only) and not RW (Read Write). It is completely feasible to assume complete control over a firewall for example by having RW access to SNMP and then exposing it to the entire internet with a weak passphrase.

    You wouldn’t do it (at least, I hope you wouldn’t) and the same ethic applies to server-side rendering and the execution of commands.

  • Composer options on nodebb

    Solved Configure
    8
    3 Votes
    8 Posts
    387 Views

    @Panda You should be able to expose the CSS for these using F12 to get into console

    3591518c-e3a3-4ada-a43c-6b32a5e0359c-image.png

    a2b8ed46-4157-4ff2-85f0-576543380107-image.png

    That should then expose the element once selected

    89d9c545-a47a-40d1-98f4-80cf3b958e8f-image.png

    Here’s the below CSS you need based on the screenshot provided.

    .composer .formatting-bar .formatting-group li[data-format="picture-o"], .composer .formatting-bar .formatting-group li[data-format="spoiler"] { display: none; }
  • Setup OGProxy for use in NodeBB

    Moved Let's Build It
    110
    21 Votes
    110 Posts
    11k Views

    @crazycells said in Setup OGProxy for use in NodeBB:

    are they cached for each user separately?

    No. It’s a shared cache

    @crazycells said in Setup OGProxy for use in NodeBB:

    additionally, this is also handling youtube videos etc, right?

    No. This is handled by nodebb-plugin-ns-embed

  • 11 Votes
    14 Posts
    786 Views

    @dave1904 excellent news. Thanks for the feedback

  • [NODEBB] Help for my custom CSS

    Solved Customisation
    193
    38 Votes
    193 Posts
    32k Views

    OMG make sense

    Thanks dude 🙂