Skip to content
Sudonix

NodeBB v3 Chat Very Slow

Moved Performance

Related Topics
  • DownPWundefined

    NodeBB socket with CloudFlare

    Unsolved Performance
    23
    1 Votes
    23 Posts
    2k Views
    phenomlabundefined

    @DownPW it’s your only realistic option at this stage.

  • DownPWundefined

    error with v3 in browser console

    Solved Performance
    4
    0 Votes
    4 Posts
    175 Views
    phenomlabundefined

    @DownPW it’s in relation to the response I provided above

  • Pandaundefined

    SEO and Nodebb

    Performance
    2
    2 Votes
    2 Posts
    180 Views
    phenomlabundefined

    @Panda It’s the best it’s ever been to be honest. I’ve used a myriad of systems in the past - most notably, WordPress, and then Flarum (which for SEO, was absolutely dire - they never even had SEO out of the box, and relied on a third party extension to do it), and NodeBB easily fares the best - see below example

    https://www.google.com/search?q=site%3Asudonix.org&oq=site%3Asudonix.org&aqs=chrome..69i57j69i60j69i58j69i60l2.9039j0j3&sourceid=chrome&ie=UTF-8#ip=1

    However, this was not without significant effort on my part once I’d migrated from COM to ORG - see below posts

    https://community.nodebb.org/topic/17286/google-crawl-error-after-site-migration/17?_=1688461250365

    And also

    https://support.google.com/webmasters/thread/221027803?hl=en&msgid=221464164

    It was painful to say the least - as it turns out, there was an issue in NodeBB core that prevented spiders from getting to content, which as far as I understand, is now fixed. SEO in itself is a dark art - a black box that nobody really fully understands, and it’s essentially going to boil down to one thing - “content”.

    Google’s algorithm for indexing has also changed dramatically over the years. They only now crawl content that has value, so if it believes that your site has nothing to offer, it will simply skip it.

  • cagatayundefined

    Header Menu After Upgrading V3.1.1

    Solved Customisation
    2
    2 Votes
    2 Posts
    153 Views
    phenomlabundefined

    @cagatay this relates to a change the css classes used for the brand header meaning it will now float to the left instead of right.

    If you’d like to retain the original behavior, you can add this css class

    [data-widget-area="brand-header"] { justify-content: end; display: flex; }

    Further information here

    https://community.nodebb.org/topic/17090/manual-build-a-custom-header-in-harmony/19?_=1684069325296

  • cagatayundefined

    NodeBB v3.0.0-rc.1

    Performance
    1
    1 Votes
    1 Posts
    92 Views
    No one has replied
  • phenomlabundefined

    Optimum config for NodeBB under NGINX

    Performance
    4
    3 Votes
    4 Posts
    673 Views
    phenomlabundefined

    @crazycells hi - no security reason, or anything specific in this case. However, the nginx.conf I posted was from my Dev environment which uses this port as a way of not interfering with production.

    And yes, I use clustering on this site with three instances.

  • DownPWundefined

    NodeBB 1.19.3

    Solved Performance
    33
    4 Votes
    33 Posts
    3k Views
    DownPWundefined

    @phenomlab

    I find the problem Mark 😉

    The error message indicated this path :

    http://localhost:4567/assets/plugins/nodebb-plugin-emoji/emoji/styles.css?v=6983dobg16u

    I change the path url on config.json

    47bacc80-f141-41e4-a261-3f8d650cc6f6-image.png

    And all it’s good 🙂

    Weird, I didn’t have to change that path before 1.19.3

    But this does not prevent the problem from a clean install with Emoji Plugin

    EDIT: After test, that resolv the problem installation for 1.18.x but not for 1.19.x (I have other error message when I run ./nodebb Setup

    For resume: NodeJS 16_x with 1.18.x is ok

  • DownPWundefined

    [NODEBB] Wallpapers BUG on Firefox Mobile ?

    Solved Customisation
    9
    0 Votes
    9 Posts
    818 Views
    phenomlabundefined

    @downpw I’m inclined to agree with this. There isn’t much else you can do, and provided it works with no odd looking artefacts in other browsers, then ok. The :before and :after are pseudo classes and very well supported across all browsers (except perhaps Internet Exploder, but who uses that these days ?)