christopher-w

Yes, agreed - although restricting access to privileged groups (below) will at least prevent overuse. Nice job, looks like a fab feature. Glad it can be controlled though, maybe add daily/weekly etc usage limits in the next update to prevent eye candy overload.

Quick pre sales question. If user visits something like Classifieds, or VideoBox, will that show up anywhere? thanks Chris

+1 I requested custom development for FFmpeg back in 2018: No takers, but if there is someone out there with the required skills, then I'd be happy to contribute towards a solution.

Is there somewhere else we should be posting 'support' requests?

Thanks yes, I did that, but it wasn't working. I assumed I was doing something wrong. I will try again. Thank you.

Yes Pages blocks. Can you show me the syntax please?

Hey, Can I place custom blocks similar to {block="xx"} inside the HTML block? Many thanks

Hey @DesignzShop You know I have no doubt as to the ability and efficacy of the dev team here. They've clearly been thinking ahead of the curve in terms of functionality - but just as with the 8088/286 legacy issues that somewhat thwarted progress of x86 .exe development, the future decisions regarding code direction that face all application architects are wide ranging. As has been pointed out, Invision has lots of active clients, which is both great from a business perspective, but problematic in terms of updating them if you make a fundamental direction change in terms of how you build pages. Which is what deploying a versioned API amounts to. Although, wrapping core as it stands in an API wrapper is a possibility I guess, although probably not desirable in terms of performance. Either way, deploying a versioned API is not something you are going to roll out as part of a mid year x.xxx update. It's a fundamental change in how pages are built, with controller methods just as, if not more likely, to be executed on the client with async server fulfillment - promises etc, than backstage via waterfall PHP. As for themes, and for that matter plugins, with a documented client side API and CSOM, themes and plugins can transform themselves from passive to active devices. I appreciate there's already the odd plugin making async server calls, but having an API and CSOM would make it the norm. And thinking more on this, it probably means an entirely new branch of code - operating in parallel with the existing legacy installations for the short - mid term. Whether this is in Invision's plans? Who knows but I am sure they will make the right decision as they see it and thereafter execute them to a high standard. And of course, it's easy for folks like me to suggest this and that. These guys have the real hard job. Making the decision and then making it work. I worked with the NodeBB platform for a few months and was impressed with its sheer economy of design. What it did, it did very well, and as you say was/is quick out of the box - but there wasn't enough of it. Third party plugins augmented what you'd argue, should be in core, but just as with most community platforms, they worked with varying degrees of success and the irony being, the more you planned your new site, the less comfortable you felt relying on an individual plugin developer to deliver core functionality for the foreseeable future. But as we know, that's not specific to one platform - it's the industry we're in. With regards Discourse, I think they are in much the same boat as NodeBB, albeit more widely used, and for good reason given the dedication and provenance of the founders. But as I mentioned earlier, they made decisions that, in my view at least, crippled their desktop offering. But apart from that, I do really like the immediateness of the Discourse platform - especially how changes to the model (both app data and CSS) are instantly pushed to the view (clients) - alarming when you first see it in action, with for example, the theme changing before your eyes, without a page refresh, a second or so after it's been updated on the server. Well yes, exactly.

Yes, I am sure that's the intention, but the larger the user base, the more generic the solution - just look at O365. Which is why I advocate core being wrapped in a versioned API, which allows theme devs and more advanced owners to construct their own front end presentation. Plus themes don't break when core is updated because they will be authored against an API version.

You see, I'm stuck on that comment. Invision's not perfect, but I've not seen much to compete. There was a time when Telligent ruled the roost (2007/11), but went off track when it sold out. Now who is there to compete with Invision? I spent hours today trying to find alternatives. As I do every few months. But came across the same old suspects - LinkedIn clones, or forums trying their best to be multi app platforms, So assuming I've missed something, who is there? Who would/do you recommend in Invision's place? Totally understand if you consider that information to offer you a competitive advantage and is therefore propriety and confidential.

I just wanted clarification - hoping it wasn't as clichéd as it turned out to be. Lost interest at that point.

your point is what exactly?

Same. Although for feelings to run that deep I assume there's more to this than meets the eye. I reckon this is not just about mobile/desktop split, or for that matter, a rift between 1 or more members. I wonder, do the Invision team discuss their plans, or for that matter, take input from the community before setting out on a dev path.? After all, there appears to be some highly experienced folks on here, and many of them are not working for Invision. I am wondering whether there's frustration creeping in. For folks that have invested considerably in this platform over the years, either as devs or clients, I am sure they want to be part of the collective decision about platform direction, rather than waiting to see where it's gone, following the latest release.

Am I able to show multiple member lists per page? I can't see a way of doing that.