* feat: #8734, jquery-ui, jquery-form, timeago
get rid of forum/footer.js move that code to app.js & wait for app to load before calling ajaxify.end
make sockets.js a requirejs module
move jquery-ui to node_modules and load via requirejs
move jquery-form to node_modules and load via requirejs
move timeago to node_modules and load via requirejs
only include the css for needed jquery-ui widgets
* feat: keep socket/io global for backwards compat
* refactor: move socket listener to chat
There was an odd issue where non-superadmins could not use
the /admin route to access the ACP, even though they had
appropriate access. For whatever reason, it could not
be reliably reproduced on my dev. As it turns out, the
reason was because I was checking the wrong privilege,
and my dev database had this wrong privilege leftover
from the initial development of the ACP admin privileges
feature. Dumb.
Anyhow, that fixes this issue.
9adaccd036 introduced the ability to
configure an assetBaseUrl, but the timeago strings were still
calling a hardcoded value as it was handled server-side. There's
no need for the strings to be loaded until timeago is initialised.
* feat: acp privileges (WIP)
* fix: restore global privilege hooks
* refactor: using cid 0 in admin privs
* fix: no need for zebrastripe-reset
* feat: manage:categories privilege WIP
* feat: renamed prefix to admin:, settigns and dashboard privs
* fix: nofocus on acp privs group find modal
* refactor: privileges.x.get() to not used hardcoded privs
* fix: crash if unable to get latest version
* feat: setting acp priv
* Revert "fix: crash if unable to get latest version"
This reverts commit afdb235f48.
* feat: user/privilege acp privs
* fix: category selector in manage/privileges
* fix: guests potentially becoming admins
* fix: bug in setting admin privs
* fix: some last minute things + api docs
* fix: some more last minute fixes
* refactor: make middleware.admin.renderHeader async
* refactor: making rendering of header and footer async functions
* fix: use app.renderAsync instead of promifying it
* feat: fix session mismatch errors by clearing cookie on logout
* feat: remove app.upateHeader
ported from 2.0
* feat: handle if user doesn't click button and just refreshes page
After some more thought, a response hook should be checking for
whether headers are sent, and executing (or not executing) the
default logic in that case.
Before, we were relying on hooks to call data.next() to continue
execution, but it makes more sense to have the listener either
send a response or not, and handle the behaviour afterwards.
