Sessions are distinct from users. One user may have multiple sessions, public and admin sessions are stored in separate tables, and neither are stored in the user table. We don't have separate accounts for each though, and that won't be changing.
It’s not that they won’t be updated, it’s that the update could be attributed to the wrong version ID at the time they’re imported into the machine the add-on is built with, which only later impacts things like template customization tracking for admins.
I think it’s far less likely to happen...
The avatar function call it gets compiled into supports a defaultname attribute, unless I'm misunderstanding:
<xf:avatar user="{{ null }}" size="xxs" defaultname="John Smith" />
It's possible to mangle the tracked version of templates and phrases, especially when working with many parallel branches spanning multiple release cycles. Granted this can be mitigated somewhat if you can build linearly from a blessed installation which tracks the canonical versions in the...
You've posted the URL, Google has no issue crawling or indexing them if it's deemed worthy. Google (and browsers in general) use the Content-Type header and other context clues to determine the resource type, regardless of the file extension in the URL itself (or lack thereof). In the same way...
Right, but this option is for the xf_content_activity_log table, which does not store IPs:
The records in xf_session_activity are pruned via cron every hour.
This will actually be related to us re-enabling the Clear-Site-Data: cache header for logouts:
https://xenforo.com/community/threads/logout-bug-when-guest-caching-is-enabled.200977/#post-1746197
We had it briefly a while back but it caused hangs for quite a while...
The xf_ip table is the central place. The option you noted will prune the records after a period of time. The activity log option is for something else (it logs activity to power trending content) which does not contain IP records. The other records are removed by the logging option values, or...
You can do this somewhat trivially through edits to the login template alone, no add-on or code is required. We actually achieve this for the admin page by overriding the page container template:
<xf:page option="template">LOGIN_CONTAINER</xf:page>
You can create a custom LOGIN_CONTAINER...
The public and admin sessions are entirely separate architecturally, but we clear most cookies when logging out of the public app, including the admin session cookie. We do this because otherwise many people will inadvertantly leave their admin session active, so it's more of a deliberate...