Nathan Explosion

Yeah, you haven't done it. Go to the acp. Edit your group. Locate the 'Can post HTML?' settings. Enable it. Save the group. Got to the front end...you should now see the source button.

Have you done this?

No The one titled 'Source' - you said that ...so it had to be assumed that you had. If you didn't then you should check your group to see if you have the "Can post HTML?" setting is enabled for it. You're adding whatever your html code is

It was a link to a resource on the Marketplace, which no longer exists...hence it no longer shows.

Wouldn't it help to provide the URL of the page so that it can be understood what application etc this relates to within the suite?

You used the HTML option within the Code box button...that literally just posts code as text. Click the Source button in the editor to edit the html.

You won't get it. Request a backup of your data, host the provided DB yourself

This is what you should expect to happen: Anyone having share on twitter problem_ - Technical Problems - Invision Community — Mozilla Firefox 2023-11-29 16-45-31.mp4 But all that going on within the popup box...that's Twitter's issue. Personally, the fact that it displays what looks like CSS as plain text right at the start indicates that they likely haven't tested whatever the heck it is that they are now doing when sharing.

Yes

This is what is there currently, so looks like sitemap has been rebuilt:

Simpy upload your image via the functionality available in the emoji section of the ACP, and put the short code in for it: :)

Old IPB v3.x files; if you're on v4.x then they are not part of if it (the 'public' folder doesn't exist in v4) - you might want to provide a screenshot of all the directories you see under public_html/forum as there are likely others that you can remove too.

Edit your conf_global.php file and change the http to https for your URL there.

Did you update your conf_global.php to reflect the change from http to https in your URL?

Just want to double check something, and happy to be wrong on this... Is there a reason why uninstalling an Invision application doesn't remove that specific application's javascript from the core_javascript table of the database? It's easy to check: Install a new instance of the full suite Check core_javascript and there's all the javascript files for all the applications. Uninstall a random application (say, Blog) Check core_javascript and there's all the javascript files still there for that specific application. Reason I am asking is that I've just spotted that an old test instance of mine where I had uninstalled all my own applications but left behind the Invision apps, all the JS from my own apps were still in the table. Always been under the impression that removal of application JS files from core_javascript was done at uninstallation time by the framework (it does for plugins), but it appears it is not. Taking a look at the delete() function in \IPS\Plugin, there is a clear removal of the JS from the table: $hasJs = \IPS\Db::i()->delete( 'core_javascript', array( 'javascript_plugin=?', $this->id ) ); But amongst all the tidy up in the equivalent function in \IPS\Application, there is no clearing of the application's JS from the table. If someone reinstalls an application at a later point, there is a deletion of existing done by importXml in the \IPS\Output\Javascript, prior to importing the new. Just double-checked to see if maybe it was implemented via the Uninstall extension, and nope.

If you are going forum by forum, then change your approach by going to the group listing and click the padlock icon there for the group: You then get this which is a one stop shop:

In that very document you linked to...

Set to what, exactly? Help people see what you have done by posting a screenshot that shows what you have set as the permissions.

Only if you allow them to do so - you might want to check their group settings and disable the ability to do that via the Blog tab, if you don't want them to be creating blogs or commenting on entries.

Yes it does - enable the field.

Search for "edit" in your ACP and click on the "edit log" result

You have replaced this: setting="base_url" You haven't replaced this: {setting="base_url"} notice the curly braces you have left behind, that you should be removing?

No, you would replace all of the provided content: {setting="base_url"} ...with your chosen content.

@sadams101 - all you have to do here is post up the content of the message you are receiving, and not just a subject or screenshot. Why? Because there is only one thing that is called by cron related to Invision and that is the following file: applications/core/interface/task/task.php That file is then responsible for running the task queue - and as the output from the file is usually nothing then the cron will usually get nothing back to identify which specific task is being run within the queue. If the messages are indeed related to that then it's a task within the Invision-space that needs further investigation. Currently, you're looking for a needle in a haystack.