You can now like posts and see a count of how many people liked the post. Clicking that will show a full list of the people who have liked that post, including you. The people list has the same style as other people lists (thread views, people here).

That was it. Might want to fix the cause of that, though. Not everyone will Ctrl + F5 with such updates intuitively. There needs to be a way to uncache a page or javascript file with versioning or something. I hate webdev, or i'd know what it was and point you to it.

A thing me and a buddy once tried before was doing versioning based on dates. As soon as we "recompiled," it was already a new version, so we didn't even have to bother. Is it a javascript file, or what?

Right, so you naturally do need it cached, normally, but uncached when the version changes.

I think there's a way to do this, but the issue of cache clearing makes this problem hard to google. There's ways to do this from php, javascript, etc. The issue is, you want to make it conditional. Maybe with an extra cookie, make the cookie match the version, and if the version doesn't match, update the cookie and clear the cache?

That said, it doesn't solve the rolling of massive changes slowing down as everyone updates at the same time, but that will happen simply because you're relying on a massive javascript file. Have you considered splitting the file up?

yeah that makes the browser request the JS file anew every time it loads the page, which is not desirable.

Best idea I've come up with so far is some variation of:

1. Request the file like this: new.js?v=(some md5 hash)
2. Pull the hash out of the database. Or save it to a file or something.
3. Have something on the server occasionally scan the file and update the database's version of the hash of the file accordingly.

What would be ideal for #3 is this process happening as I save that specific file so there isn't load on the server like a one-minute cronjob that is only useful once every 1,675,231 attempts. Maybe I can configure my SFTP settings or something.

The proposed fixes still don't solve the server load issue when everyone updates the js file at once, but if you can get a reasonable system started, you should be able to pull it off for multiple files, when you then take as an opportunity to split that javascript file into multiple parts which each get tracked and then invalidated with 1.

The idea is that this issue could cause problems down the road if you make a major change that's important. You don't want to have to avoid making necessary changes for fear it'll crash and burn.

Also the ?v= thing is a totally legit way of fixing that particular problem, but without some kind of auto-scanning solution I have to update the places where that JS file is called each time it updates which gets old fast.