Editing posts

[Yamikuronue]

Hey @administrators , is there a setting to let people edit their posts forever? If not, is there a bored @blubar who can make one magically appear?

CC: @masonwheeler

[masonwheeler]

Yes, this would be greatly appreciated.

(And also probably abused to comical or -worthy effect by certain elements. But it's still a good idea on balance, especially if late edits record a post history.)

[izzion]

@Yamikuronue
I think such a setting would probably also strongly merit having viewable edit histories for posts -- do mods even have access to that, or is it just a non-feature in NodeBB?

[boomzilla]

There is. Currently set to 604800 seconds after the post, which is 7 days.

[Yamikuronue]

@boomzilla Can it be set to a bajillion seconds?

[Yamikuronue]

@izzion said in Editing posts:

do mods even have access to that,

No

[boomzilla]

@izzion said in Editing posts:

I think such a setting would probably also strongly merit having viewable edit histories for posts -- do mods even have access to that, or is it just a non-feature in NodeBB?

NodeBB does not track versions. There are some...ahem...special cases that we log here. But not terribly easy to go back and look up later on.

[RaceProUK]

@Yamikuronue said in Editing posts:

Can it be set to a bajillion seconds?

While a good choice, I think a real number would be better :P

[Yamikuronue]

@RaceProUK I think "off" (infinite seconds) is the best option ^_^

[anotherusername]

How about let's not change it. It's rare that anyone would need to, and if it's important enough it'd probably be better for them to just post a followup.

[Yamikuronue]

@anotherusername This was brought up because of things like index posts where you really want to keep adding to it as time goes on. Right now you have to bug a mod to update it later, or be one.

[masonwheeler]

WRT viewable post histories, I really like the way Stack Overflow does it: For the first couple minutes, edits are "free". It pretends it was always that way, because you're probably just correcting typos or finishing incomplete thoughts anyway. But after about 5(?) minutes, it starts tracking a post history that can be viewed by the entire world.

No idea how much work it would be to set that up, but assuming the DB architecture isn't completely insane (inb4 mongo snark that's admittedly probably correct) it shouldn't be too hard...

[anotherusername]

@Yamikuronue ok, I could see the benefit in having specific posts excepted from the edit time limit. But I wouldn't want any and all posts to be excepted from it.

[Yamikuronue]

@anotherusername Yeah, it's one of those where most posts don't need it, but it doesn't hurt much to have it on IMO. It'd be better to mark certain posts as infinitely editable. I liked the wiki post function from Discourse for those things.

[hungrier]

@masonwheeler That was the way it was on , and surprisingly enough it worked pretty well.

[anotherusername]

@masonwheeler said in Editing posts:

WRT viewable post histories, I really like the way Stack Overflow does it: For the first couple minutes, edits are "free". It pretends it was always that way, because you're probably just correcting typos or finishing incomplete thoughts anyway. But after about 5(?) minutes, it starts tracking a post history that can be viewed by the entire world.

No idea how much work it would be to set that up, but assuming the DB architecture isn't completely insane (inb4 mongo snark that's admittedly probably correct) it shouldn't be too hard...

did this too, but users could decide whether they wanted their edit histories to be public or not, and mods could decide to purge the edit history at any time (the  stayed, though).

[Yamikuronue]

Really, discourse did editing better than NodeBB. Someone should fix that.

[masonwheeler]

@hungrier Not surprising, considering Jeff is also one of the guys behind StackOverflow.

[anotherusername]

@Yamikuronue said in Editing posts:

I liked the wiki post function from Discourse for those things.

Agreed. It'd be nice if certain posts could be designated as wikis, and a specific set of users (or all users) could be designated as editors for that post.

Preferably, those posts would be identified somehow ( or icon?) and hovering over that would show which users or groups were editors...

[Yamikuronue]

@anotherusername if I hadn't just started a new project, I'd try my hand at making a plugin for nodeBB...

[groo]

@Yamikuronue like special Discoursey wiki posts

[groo]

Can we have unlimited time for deleting them? It's not that different from editing, and it's even easier for mods to see the previous content.

[Yamikuronue]

@groo I'mma be honest, I saw your username and "deleting" and immediately went:

[groo]

....

[loopback0]

@groo said in Editing posts:

Can we have unlimited time for deleting them?

You can have it limited to 0 for deleting and editing.

[groo]

@loopback0 0 == limit disabled

[loopback0]

@groo said in Editing posts:

@loopback0 0 == limit disabled

I didn't say set to 0, I said limited to 0.

[anotherusername]

@groo said:

Ha! You didn't beat my script.

[groo]

This post is deleted!

[anotherusername]

@groo said in Editing posts:

@anotherusername is this script scraping all threads from the forum all the time? Isn't this heavy on the server?

It doesn't have to scrape; it just has to listen. NodeBB streams every new post in real-time (that's posted in a category I'm able to see... it won't stream posts that are posted in the mod's special lounge, because I can't see that). That's how, when you're on one of the topic lists, it can display that "new posts, click to refresh" message, and it's how it can automatically load new posts to the topic you're reading. It doesn't matter which page you're viewing, though; it'll stream posts even from other topics... if you're in a topic, the client-side code only displays them if they're in that topic; otherwise it doesn't do anything.

I just set up an event listener that processes posts as they stream in. It also auto-likes them if they're in the Likes topic.

The only limitation seems to be that it frequently disconnects, but activity seems to prevent that from happening (as frequently).

[Yamikuronue]

@groo we can have a beef, but if you put cheese on mine, deal's off ^_^

[groo]

@anotherusername said in Editing posts:

NodeBB streams every new post in real-time

To all browsers? What a waste of bandwidth

[Yamikuronue]

@groo said in Editing posts:

@anotherusername said in Editing posts:

NodeBB streams every new post in real-time

To all browsers? What a waste of bandwidth

yeah, it makes debugging sockbot suck, because if you wait a few minutes with debug output on you get enough "incoming post" spam that you can't see the socket traffic you wanted anymore.

[groo]

@Yamikuronue you could have a toy NodeBB instance for a clean debug

[anotherusername]

@Yamikuronue I wrote my own socket monitor, with the ability to ignore anything I don't want to see.

[anotherusername]

@Yamikuronue here 'tis.

var ioMonitor; ioMonitor = ((log_s, log_x) => {
  var real_emit = socket.emit, real_onevent = socket.onevent, real_XMLetc = XMLHttpRequest, XMLHttpRequestCount = 0, removed = 0;
  var returnObj = {
    ignored_types: ['ping', 'pong'],
    remove: () => {
      if (!removed) {
        ++ removed;
        if (log_s) { socket.emit = real_emit; socket.onevent = real_onevent; }
        if (log_x) { window.XMLHttpRequest = real_XMLetc; }
      }
    }
  };
  const log = (...a) => !removed && console.log(...a);
  const ignore = s => Array.isArray(returnObj.ignored_types) ? returnObj.ignored_types.some(t => t.test ? t.test(s) : t == s) : false;
  if (log_s) {
    socket.emit = function emit(...s) {
      if (!ignore(s[0])) log("socket.emit:\n", ...s);
      var f = typeof s[s.length - 1] == "function" && s.pop();
      real_emit.bind(socket)(...[...s, function (...e) {
        if (!ignore && e.some(p => p !== null)) log("socket.emit", ...s, "response:\n", ...e);
        if (f) return f(...e);
      }]);
    };
    socket.onevent = function onevent(packet) {
      if (packet.type == 2 && !ignore(packet.data[0])) console.log("socket.on:\n", ...packet.data);
      real_onevent.call(socket, packet);
    };
  }
  if (log_x) window.XMLHttpRequest = function XMLHttpRequest(...a) {
    var count = ++ XMLHttpRequestCount;
    var req = new real_XMLetc(...a), real_send = req.send;
    for (var o = req; o; o = Object.getPrototypeOf(o)) Object.keys(o).forEach(n => {
      if (n in req && typeof req[n] == "function") {
        var orig_fn = req[n];
        req[n] = function (...e) {
          log(`XMLHttpRequest${count > 1 ? `{${count}}` : ""}.${n}\n`, ...e);
          var response = orig_fn.bind(req)(...e.map(p => typeof p != "function" ? p : function (...q) {
            log(`XMLHttpRequest${count > 1 ? `{${count}}` : ""}.${n} callback`, p, "\n", ...q);
            return p(...q);
          }));
          if (response !== undefined)
            log(`XMLHttpRequest${count > 1 ? `{${count}}` : ""}.${n} response:\n`, response);
          return response;
        };
      } else {
        var prop_desc = Object.getOwnPropertyDescriptor(o, n);
        if (prop_desc.get) {
          var getter_fn = prop_desc.get;
          prop_desc.get = function get(...a) {
            var value = getter_fn.bind(req)();
            log(`Get XMLHttpRequest${count > 1 ? `{${count}}` : ""}.${n}:`, value);
            return value;
          };
          Object.defineProperty(req, n, prop_desc);
        }
      }
    });
    log(`New XMLHttpRequest${count > 1 ? `{${count}}` : ""}:`, req);
    return req;
  };
  return returnObj;
})(true, true);

(true, true) at the very end indicates that the logging should be enabled for socket and for AJAX (respectively). It sets a variable, ioMonitor, with a remove() method to stop logging completely and return everything back to normal, and an ignored_types[] array of socket events that it should ignore (both string values and regexp values are allowed) -- of course, you can add to that array before running the code, but if you realize only afterward that you don't want to see a particular type of message, you can add it to ioMonitor.ignored types and it'll immediately take effect.

[CreatedToDislikeThis]

@anotherusername said in Editing posts:

NodeBB streams every new post in real-time (that's posted in a category I'm able to see...

Seriously? My god.
That inflates the client & server bandwidth by several orders of magnitude! Explains all the disconnections.

[RaceProUK]

@CreatedToDislikeThis Discourse does the same thing

[Erufael]

@RaceProUK Which still doesn't make it a Good Idea. ;)

[groo]

@RaceProUK said in Editing posts:

@CreatedToDislikeThis Discourse does the same thing

If such a well thought out thing as discourse does it that must be a good idea

[Scarlet_Manuka]

@Yamikuronue said in Editing posts:

Really, discourse did editing better than NodeBB. Someone should fix that.

By making Discourse editing worse? Because we could probably get that to happen.

[remi]

@anotherusername said in Editing posts:

NodeBB streams every new post in real-time

Wouldn't it be more sparse on the bandwidth to only stream some kind of ID? At any given point you're probably only interested in a very limited subset of full posts (basically, the posts in the thread you're currently viewing), for all other posts knowing something like time, thread, author, reply-to and maybe a couple more thing should be more than enough?

Also, I like your event listener. I don't know anything about web development but I've always wanted to try and play with the console, I'll probably keep your stuff on the side as it seems a fairly good starting point to see (and later tamper with) what the server sends...

[Yamikuronue]

@remi said in Editing posts:

At any given point you're probably only interested in a very limited subset of full posts

The backend doesn't know if you're on the list page or a detail view, because the whole thing is handled by the client. If you're on the list page, the incoming messages trigger that "new posts" message above the list.

[accalia]

@remi said in Editing posts:

Wouldn't it be more sparse on the bandwidth to only stream some kind of ID?

sure? but then you cound't hack the client to do all sorts of awesome things on new posts, and you couldn't do what sockbot does either.

also Discorse did it that way, and do we really want to do as discourse do?

[groo]

@accalia said in Editing posts:

sure? but then you cound't hack the client to do all sorts of awesome things on new posts, and you couldn't do what sockbot does either.

There are more reliable ways of achieving this, and having it enabled in the topic list is a waste. I don't even want anything being updated online in my use of it.

[masonwheeler]

@accalia said in Editing posts:

sure? but then you cound't hack the client to do all sorts of awesome things on new posts, and you couldn't do what sockbot does either.

Why not? The workflow would go like this:

Server: New post in topic ID 365, category 4. Post id: 24599
Client: [I don't care about that. Do nothing.]
Server: New post in topic ID 42, category 7. Post id: 24600
Client: [I don't care about that. Do nothing.]
Server: New post in topic ID 555, category 4. Post id: 24601
Client: [I care about that one!] Server, plz send me teh codezmarkdownz for post ID 24601.
Server: (post content here)

Is there any reason why a scheme like that would cause problems for Sockbot?

[remi]

@Yamikuronue What I meant (and forgot to write...) is that you could get only some generic info from all posts and then the client could either just deal with it ("new post") or ask the server for the full message if needed (because you're on a thread view, or because you're on the list page and you want to show a couple of lines of the message or whatever).

In some cases (where you need to see all content of all posts), that wouldn't save a lot of bandwidth (and might even add a few with a couple more roundtrips to ask for more info), but in many cases (e.g. when you're reading a given topic) that would avoid streaming stuff that is discarded immediately.

I mean, I don't understand how you can design a web-thingy with the assumption that there will never be any bandwidth issue between the client and the server (especially if the client is doing some work on its side and should therefore be able to decide by itself what it needs!).

@accalia said in Editing posts:

you couldn't do what sockbot does either.

Well, it depends if the goal is to design a forum software for use by humans or by bots...

[accalia]

@remi said in Editing posts:

Well, it depends if the goal is to design a forum software for use by humans or by bots...

[Yamikuronue]

@remi I think I'd probably want to separate the stream you get on the list page from the stream you get on the thread pages. Probably by making a hard navigation point between them. Then you'd get the chattier messages on the list page, and only the ones for the thread you're on on the thrad page

[anotherusername]

@remi said in Editing posts:

Wouldn't it be more sparse on the bandwidth to only stream some kind of ID? At any given point you're probably only interested in a very limited subset of full posts (basically, the posts in the thread you're currently viewing), for all other posts knowing something like time, thread, author, reply-to and maybe a couple more thing should be more than enough?

It's a fairly small amount of data, really.

Also, I like your event listener. I don't know anything about web development but I've always wanted to try and play with the console, I'll probably keep your stuff on the side as it seems a fairly good starting point to see (and later tamper with) what the server sends...

Yeah, that's why I built it. Originally it just monkey-patched socket.emit, but I later added the monkey-patches for XMLHttpRequest and, eventually, the global incoming socket event handler (that one took a bit of googling because socket.on doesn't allow wildcards -- trapping all of them required monkey-patching the function it calls internally).

@Yamikuronue said in Editing posts:

The backend doesn't know if you're on the list page or a detail view, because the whole thing is handled by the client. If you're on the list page, the incoming messages trigger that "new posts" message above the list.

Actually it should -- the front end sends events to tell it where it is:

I assume the original plan was to have it keep track and only send stuff that was relevant, and then someone said ah, hell with it and just had the back-end send everything because it's really not that much data anyway.