Matt

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.

twoStep_activation isn't a standard column, so I'm unsure what the default value is on that. It might be easily fixed by editing core_members in PhpMyAdmin or similar to ensure the table column has a default value (such as NULL if it's a VARCHAR, or 0 if it's an INT).

To be clear, I'm not assigning blame; we create enough of our own bugs 🙂 but it is a working reality that a portion of our support volume is caused by code that is not ours. We have added tools to speed up the debugging but it's not always clear that a third party app/hook is the problem. There's a lot we can do of course but our problem is just people-hours. We make a loss on the marketplace currently when you factor in battling fraud, chargebacks, as well as debugging support issues. We are OK with that, but it does mean that we do not have a lot of resources to put into it beyond what we already do. I'm also not entirely convinced there's a pool of younger newer coders who would be willing to learn our framework and develop modifications. The problem isn't so much that people are leaving the marketplace (life changes, etc), it's that there's fewer to replace them. Part of the barrier is the cost of course, and I do recognise that but also PHP isn't a "cool" language anymore. Most developers are learning javascript (node, react, etc). This is why our future efforts are in building APIs, events and triggers that JS languages can take advantage of.

No dates planned, no. 🙂

Bad for SEO, bad for screen readers, bad for visual clutter, not really a "thing" with modern community platforms.

I do not think that is a fair assessment. We bear the support burden when a third party item has a bug. We are the first point of contact when a customer's community throws an error. To help reduce this burden, we do review submissions before they are published. It helps, but we still get tickets daily that are caused by third party items. This is the nature of code, it breaks sometimes. Free development licences have been discussed before and we could not formulate a fair plan without effectively giving away copies of the software to anyone who was thinking about creating a plugin or theme. We could consider a new model where we take 30% of sales, but do more to help authors by giving out free licenses, etc but we really want to meddle less in what you do, not tighten the rules further and take a bigger cut to offset the losses on license sales, etc. Technology marches on. We are investing time into developing forward thinking architecture that marketplace authors can leverage, such as GraphQL, new workflows based around triggers and events. These changes mean much less code overloading and more API use which will be upgrade resistant. We have always strived to help marketplace authors both with development and marketing of their products. If you look at all of our peers, not one of them has invested as much time and money into developing systems third parties can take advantage of. Marketplace sales are still very strong. There are still gaps in what we offer that marketplace authors can take advantage of. Our feedback forum is open to read and a great place to start when looking for ideas.

Which version are you currently using? I've just checked most tables with a member ID, and they are already bigint(20).

You can ignore the support tool warning. We will revue member ID columns and increase to bigint where they are not already.