Ah silly me, thanks for finding that!

@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.

This is good 👍

@crazycells yes, I’m aware of that. Need to fix

EDIT- fixed. Caused by the same CSS that is used to absolutely position the “verified” group badge in the posts view. Amended this CSS so that is specifically targets the post stream as below

li[component="post"] a[href*="/groups/verified"] { position: absolute !important; left: 8px; z-index: 2; margin-top: 1px; border-radius: 999px !important; line-height: 14px; display: block; height: 22px; margin-left: 0px !important; }

@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.

@Panda said in Sidebar Widget is no longer on the side!:

Ah, so sidebar wont work on mobile?

Correct. If you review the docs on bootstrap, you’ll notice that it is designed on a grid system

https://getbootstrap.com/docs/5.0/layout/grid/

What I mean by changing the category is moving it on here to general as you posted it in bugs, when it isn’t.

@Panda Just circling back here with something of an update (which I think you’ll like). I’ve completely restructured the ranking system. There are now less ranks, with a higher point threshold to reach them.

More importantly, if you reload the site, you’ll notice that the ranks are now icons.

I also removed the “Author” badge, and made this a single icon, which (to me) looks much better.

@phenomlab
Ah, got it working!
I reversed the CSS addition to put z index high, and then I could see another error box saying fork title must be at least 3 characters.
So made the new fork title longer and button responded.

@Panda said in Interesting Widget code, but can’t fetch API:

How did you drop that widget into the post there?
I hadnt seen this BSgenerator anywhere on sudonix site, do you use it somewhere already?

Yes, here

https://sudonix.org/topic/414/corporate-bullshit-generator?_=1687774393044

It’s not a “post” or “topic” in the common sense. It is actually a page in it’s own right and leverages nodebb-plugin-custom-pages. This in turn creates a new “route” which behaves like a page, meaning it is then exposed for widgets.

@Panda said in Interesting Widget code, but can’t fetch API:

Also can you explain more what you mean by calling the code externally. In my API call example, how would I go about doing that?

By this, I mean create all the required code in an external JS file that is reachable by the NodeBB instance - so, in “public” for example - or in my case /public/js. The widget then “calls” that file and because it runs outside of the scope of NodeBB, you just need to return the values to the widget.

Hope this makes sense?

@DownPW Yes, it is. It’s set far too low meaning other elements with a higher preference will sit over the top of it.

@DownPW I’d have to agree with that.

@DownPW exactly. Not really a new concept, and in all honesty, not something I’ve ever used.

If you consider the need to add links and references, or citations, you’d need to be able to see other parts of the screen!

@phenomlab Thanks, have DMed you

@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; }

@dave1904 I’d start by adding a console.log function to hookData so you can see what is being returned

return hookData; console.log(hookData):

@Panda as, yes, now I understand and that makes 100% sense. It means those who get down voted can still have an opinion and use common services.

And yes, you’re right. Rather than down vote, just ignore if you don’t agree.

@Panda said in Smart Widgets:

So why is that, or conversely why would the function to expose username ever be required, as it seems app.user is already an available global object?

It is, yes, but not if you are using it outside of a widget. The function I wrote is also historical and comes from the 2.x train 🙂

@Panda yes, for some reason, that is the case. If you need an urgent response, it’s probably better to post here because of the time difference.

@Panda said in Upgrade to NodeBB v3? 2BB or not 2BB, that is the question!:

So although thats a plugin it has Widget like element and stopped working on the Theme change

Which is normal based on the widgets being reset when you change themes.