Is it possible you've accidentally entered plain-text mode? If so, you can click the [ ] icon at the top right of the editor to return to rich text mode.
You'd want data-xf-init="quick-reply" on the <xf:form> element with an appropriate data-message-container attribute set to the selector for the element to append the messages to (see eg. the thread_view template). In your controller, you'll want to switch on the _xfWithData input to return a...
The add-on developer should create the widget definitions in the control panel (Development > Widget definitions) as necessary, ensuring they are associated with the add-on, prior to building the releases for you to install. The same with the admin navigation entries really.
Sorry, I missed the 2.2 prefix. Class suffixes were added in many places in 2.3. For 2.2, just use the short-name:
$input['message'] = $this->plugin('XF:Editor')->fromInput('message');
The editor only requires a column to store the BBCode, but you may also want embed_metadata if you plan to...
You should use the editor controller plugin to capture editor input:
$input['message'] = $this->plugin(\XF\ControllerPlugin\EditorPlugin::class)->fromInput('message');
As I pointed out in the other thread, that's simply untrue:
https://xenforo.com/community/threads/image-indexing-and-seo.232046/post-1752274
You'd want to set up redirects for SEO when changing the URI of any resource, and, even if you did that, the attachments would still be served a bit...
This isn't actionable as a bug report without many more details. Are you seeing this on every page? Is it when the page is loaded, or after taking some action? Unfortunately these warnings don't seem to include full stack traces, making them essentially impossible to track down without being...
Any files you upload to your server are served by your web server, which is almost certainly faster than attachments as those must go through XF/PHP.
If you mean using the asset uploader in the control panel, those are also served directly by your web server so there will be no discernible...
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. The users are unified 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...