8f2f47e8aa
Added the IsoCode field to phrase files.
Rewrote a good portion of the widget system logic.
Added some tests for the widget system.
Added the Online Users widget.
Added a few sealed incomplete widgets like the Search & Filter Widget.
Added the AllUsers method to WsHubImpl for Online Users. Please don't abuse it.
Added the optional *DBTableKey field to AddColumn.
Added the panel_analytics_time_range template to reduce the amount of duplication.
Failed registrations now show up in red in the registration logs for Nox.
Failed logins now show up in red in the login logs for Nox.
Added basic h2 CSS to the other themes.
Added .show_on_block_edit and .hide_on_block_edit to the other themes.
Updated contributing.
Updated a bunch of dates to 2019.
Replaced tblKey{} with nil where possible.
Switched out some &s for &s to reduce the number of possible bugs.
Fixed a bug with selector messages where the inspector would get really jittery due to unnecessary DOM updates.
Moved header.Zone and associated fields to the bottom of ViewTopic to reduce the chances of problems arising.
Added the ZoneData field to *Header.
Added IDs to the items in the forum list template.
Split the fetchPhrases function into the initPhrases and fetchPhrases functions in init.js
Added .colstack_sub_head.
Fixed the CSS in the menu list.
Removed an inline style from the simple topic like and unlike buttons.
Removed an inline style from the simple topic IP button.
Simplified the LoginRequired error handler.
Fixed a typo in the comment prior to DatabaseError()
Reduce the number of false leaves for WebSocket page transitions.
Added the error zone.
De-duped the logic in WsHubImpl.getUsers.
Fixed a potential widget security issue.
Added twenty new phrases.
Added the wid column to the widgets table.
You will need to run the patcher / updater for this commit.
2.8 KiB
Contributing
First and foremost, if you want to add a contribution, you'll have to open a pull request and to sign the CLA (contributor level agreement).
It's mainly there to deal with any legal issues which may come our way and to switch licenses without having to track down every contributor who has ever contributed.
Some things we could do is commercial licensing for companies which are not authorised to use open source licenses or moving to a more permissive license, although I'm not too experianced in these matters, if anyone has any ideas, then feel free to put them forward.
Try to prefix commits which introduce a lot of bugs or otherwise has a large impact on the usability of Gosora with UNSTABLE.
If something seems to be strange, then feel free to bring up an alternative for it, although I'd rather not get hung up on the little details, if it's something which is purely a matter of opinion.
Coding Standards
All code must be unit tested where ever possible with the exception of JavaScript which is untestable with our current technologies, tread with caution there.
Use tabs not spaces for indentation.
Golang
Use the standard linter and listen to what it tells you to do.
The route assignments in main.go are legacy code, add new routes to router_gen/routes.go instead.
Try to use the single responsibility principle where ever possible, with the exception for if doing so will cause a large performance drop. In other words, don't give your interfaces / structs too many responsibilities, keep them simple.
Avoid hand-rolling queries. Use the builders, a ready built statement or a datastore structure instead. Preferably a datastore.
Commits which require the patcher / update script to be run should be prefixed with "Database Changes: "
More coming up.
JavaScript
Use semicolons at the end of statements. If you don't, you might wind up breaking a minifier or two.
Always use strict mode.
Don't worry about ES5, we're targetting modern browsers. If we decide to backport code to older browsers, then we'll transpile the files.
Please don't use await. It incurs too much of a cognitive overhead as to where and when you can use it. We can't use it everywhere quite yet, which means that we really should be using it nowhere.
Please don't abuse const just to shave off a few nanoseconds. Even in the Go server where I care about performance the most, I don't use const everywhere, only in about five spots in thirty thousand lines and I don't use it for performance at all there.
To keep consistency with Go code, variables must be camelCase.
JSON
To keep consistency with Go code, map keys must be camelCase.
Phrases
Try to keep the name of the phrase close to the actual phrase in english to make it easier for localisers to reason about which phrase is which.