Matt

You should be able to log into the front end with the same details that you use for the AdminCP, and that should then allow you to use the Page Builder feature.

It's not something that is part of our feature set, but I'm curious to learn about your use-case for this.

It's difficult right now given the AdminCP interface for editing colours. We'd need to duplicate that to offer a dark option, then update all the CSS which would be a lot. When we build a new interface, it's something we'll consider.

It's on our list for this year, but it's a significant undertaking given that we have many custom plugins that touch core areas such as drag and drop uploading, emojis, normal uploading and more.

You are getting exactly what we promised when you paid for your license. We continue to make monthly releases with a mix of bug fixes, minor and major feature updates. We have a lot in the pipeline that is coming to all platforms. We have recently released news of our Events update, Gallery refresh and GraphQL API which came to all platforms. This was covered in great detail here:

As it should.

Yes, a lot of support volume, probably around 70% is from hosting and environment issues. We have to investigate each one that takes time. Redis and Elasticsearch already consume support volume. Each ticket can take days of back and forth and involve multiple support techs and developers. It would significantly increase development time to make it universal and the cost of the hosted services would likely be around the cost of our cloud packages.

I will happily discuss concerns and explain the “why” but the continual allegations of being greedy or dishonest are disappointing. You need more than PHP and MySQL to deliver modern features. It’s the way it is. We continue to move with the times.

If you serve your JS and CSS from a CDN, and get your CDN to cache as per the Invision Community headers, you will get a very fast guest view. It's how our cloud operates.

Unfortunately, it is not possible to deliver Live Topics to a classic self-hosting environment. Our "cloud" is not simply "some server space" but rather a complex array of technologies wrapped up in custom configuration and code. Live Topics is not a PHP and MySQL application. It is actually a React and NodeJS app and uses the following technologies: NodeJS via ExpressJS server, ReactJS, Web Sockets/Socket.io, JWT Authentication, Redis, AWS SQS, AWS EC2 and MySQL. Those technologies are managed via a custom SQS queue which triggers command runners and workers. All this is bespoke to our cloud environment. Even if you managed to set up all those services, you'd still need our configuration and custom elements. By developing on a single platform allows us to rapidly deploy new features and functionality. This makes it unsuitable for a self-hosting environment.

Even though we're not quite ready to go super in-depth about Live Topics, our live question and answer event platform built into Invision Community, we're very excited to share a sneak peak! Let us know what you spot!

Yes, absolutely. I'll see what I can do. I do want to fix this properly, but I went down into a bit of a rabbit hole with it yesterday. 🐇

I've taken a look and it's complicated. The publish date field was designed and coded to allow content to be published in the future. This would effectively be hidden content until the publish_date was less than the current time. It kind of allows previous dates but it may actually un-publish them now. It's not an easy fix to allow past dates without changing the publish state as all that code is very central. The tag bug we can fix, and that seems specific to Pages. I need to think a bit about this as we risk destablishing the entire future publishing code by allowing past dates and need to decide when and how to un-publish a topic/article.

Sounds like our self hosted option is a good fit for you at this time.

That explains a lot

I’ll PM you.

I understand your reasoning but adding a resource hungry feature with the ability to turn it on rarely ends well. People will just turn it on and then send in a support ticket when their site is very slow or taking 15 seconds to load a page. This is from experience not hypothesis. 😁

Building what we call "widgets" is very expensive. It adds significant database overhead, which is why we almost always cache them. It means that one process builds them, and this built version can be shared with hundreds and possible thousands of subsequent page views. The downside is that we cannot allow any personalisation of the widget based on the member that created the cache for it. This is why we cannot show unread topics in widgets (or feeds as discussed here). It is a logical resource problem, not an ideological problem. We have a duty of care to ensure that your site, no matter if it receives 100 clicks a day, or 1000 clicks a minute responds quickly and doesn't consume a disproportionate amount of resources to the point where performance degrades. Marketplace authors often write plugins that significantly increase the resource footprint in a way that would be unsustainable for customers with the busiest communities but offer more functionality such as unread markers for widgets. We allow it because they benefit some communities but it is not something we can offer in the core software because we simply cannot allow a community to degrade as it scales.

It's most likely because the unformatted data comes directly from the search index whereas the blog feed comes from the blog database.

What do you need from us, Jon? If you need to inspect POST requests, you can use your browser inspection tools or 3rd party apps designed to listen in and show POST data.

This topic was posted in here which triggered the notification, then moved to the Set Up forum. As the notification data is gathered when you view it, it's just pulling in the forum name from its destination forum, not the forum it was posted in. I can see the confusion however.

The issue looks to be outdated email templates. Check in the AdminCP for any customisations to your email notification templates.

Not a bad idea.

Yes, CKEditor claim to have resolved the issue, so we're going to allow Grammarly again and see how it goes.