Clover13

It's only logical to be extensible. Almost every client will want to have customization capabilities and the strong majority will want truly bespoke features to stand out in their own marketability (even as hobbyist sites). Whether they are created internally or via a third party is irrelevant, the need for that ability remains and there's no escaping that. There will be more common use cases where many communities seek out the same features/apps, and that is where a marketplace has value to those communities. The same pattern we have now, but we have less visibility here on Invision Community once marketplace was removed and even less here once Providers Directory is gone. In trying to understand the value of removing the marketplace and Providers Directory for Invision Community as a company, IMHO its one or both of these things Their market is increasingly enterprise and hosting/promoting a marketplace or Providers Directory is inferior optics for their own marketing. It doesn't evoke enterprise solution grade features with a directory of independent freelance developers. That's not to say the solutions aren't high quality, it's just the optics as seen by an enterprise coming in to review the IC software and finding that level of feature enhancement support being promoted by the vendor. This is much different than being partnered with a large scale tech company that has strong brand awareness and marketability, which is high value to enterprise clients and immediately recognized when reviewing software for adoption within your enterprise. Promoting a marketplace or Providers Directory directly competes with their own custom services and costs them revenue if clients seek out those developers instead of IC developers. Doesn't really make sense for their bottom line to promote competitors of their own services, and lets face it, they're evolving IC and growing their own assets, they don't NEED third party developers for their core emerging client market. I can't blame them if those two points are accurate. They're a company, they're growing, they've been resilient in this market. With that said, it puts the responsibility on third party developers to make their own way. That's what we've seen already and will continue to see, again IMHO.

When I hear "major", I think 6.x I'd imagine you mean some new "major features" (significant), not a new major version already right? 😀 Looking forward to the website and doc updates and great idea to delineate Cloud from Classic to improve discovery/usability for those customers!

I understand the argument of deliberately building features for the IC cloud packages that use cloud native solutions (AWS products in this case) to build suite enriching features. Chances are IC will only continue to do more of that as they are cloud committed and their client base is a cloud majority. However in that you have inevitably increasing costs. The more innovative they get that relies on cloud products to enrich their own product, the more expensive their own costs become. So there is a level of pragmatism in carefully selecting features to target and understanding the scaling of their own cost and its impact on clients. That is a game (yes game) of calculated business risk and client tolerance. With that said, IC is becoming more sophisticated and professionally oriented, gravitating farther away from hobbyist sites. The cost of their chosen growth gets passed on to their clients, that is natural. And in order to be affordable, their clients will need their own revenue to support their sites. Feature growth and richness don't correlate with low cost. Now I don't know if IC needed to push to the cloud and I don't know how much of what they built truly relies on it, but they wanted to be more than a software distributor and become a hosting solution as well. The cloud provides them native uniformity, stability, scalability, security and (cloud) product extensibility while allowing them to focus on innovation AND also gain a revenue stream from hosting. Smart business but a bigger cost/revenue game that increasingly prices out smaller clients. FWIW I am self hosted on 4 sites now and want to continue to be primarily due to cost and flexibility (IC has their defined hosting terms and you have no say in customizations you may want beyond that). I'm hopeful they continue self hosted licensing and more so don't choose to release features to the cloud just to drive business there and forcefully phase out self hosting through an inferior subset of features. Only time will tell.

Right, sorry not to confuse with actual Guest member group of the software but a guest relative to the member who is RSVPing to the event. The overarching goal is to not require member's guests to an Event to sign up just for the sake of being accounted for in the Event's headcount. The +N approach was my thought as to how to solve for this as well, but it needs to be accounted for in the total RSVP count whereas if you have a threshold set, it's clear how many spots are left. I did create a topic awhile back on this here: https://invisioncommunity.com/forums/topic/472005-suggestion-enhance-event-management-to-include-plus-n-attendees-in-rsvp/ Was hoping in v5 it would be considered since it wasn't for v4.

Question on Events and RSVPs, was there or is there any intention of having Guest level RSVP? It's pretty rare in my events to have just members coming, i.e. say a father is a member and we have a dinner, then he wants to bring his wife and two kids. It's not reasonable to expect the wife and kids to sign up just to join the Event, however it's very important to maintain an accurate headcount for RSVPs relative to capacity at the Event restaurant. If v5 Events don't handle this, I'm curious to see how others manage it or plan to. It has historically been a challenge on my sites.

Regarding the patch to 4.7.20, it did seem to run the full upgrader on my sites (assuming by full upgrade you mean when all of the templates/CSS files, database, etc are going through batches of checks and updates)

Hey @Matt , it's a nice facility within the AdminCP that it auto-detects the version differences (based on the underlying code perspective) and adds a banner to update. The only caveat in this instance is there is already a version 4.7.20 and now a new patched version 4.7.20, there should never be two 4.7.20 versions. IC seems to follow semver in convention but not practice, as this security fix should have probably been 4.7.21, but I see there is already a 4.7.21 in Beta (https://invisioncommunity.com/release-notes/4721-beta-1-r133/). Given that, this security patch should have been 4.7.22 and that existing 4.7.21 beta never goes beyond beta but instead gets merged into a new 4.7.23. I know it can be a pain to manage, but this would make it clear as to what is included in what version and also display properly in the AdminCP (although the banner helps allude to which version of 4.7.20 is actively running in this case, but that isn't good practice). And thanks to Egidio Romano for identifying the security issue! 👍

Is there any benefit to deleting themes before versus after? Or is deleting them via the ACP after not possible (i.e. they are removed from the ACP)?

Awesome news! For the self hosted clients, I'd imagine this is an opportunity to clean up a lot of old/unused v4 files as well given the significant changes in v5. Is that handled as part of the v5 upgrade or would you recommend we do some cleanup before/after?

These are phenomenal enhancements to the suite! Very well done and excellent presentation!

That's beautiful! Really well done! Great video identifying the limitations of v4 and addressing enhancements to close those gaps. Looking forward to giving this a try!

Any sense on conversions of v4 Pages assets to v5?

Got ya, yeah I had no idea how that check worked or if developers reviewed and approved every bug/patch release to pass that check. The upgrade check (assuming developer has implemented it) should also pull in changes once you've upgraded but you'd only know that after you upgrade and something potentially broke. So I guess it's always a matter of how much you're willing to risk with third party apps working and the amount of effort you feel you need to put into verifying it before doing a live site upgrade.

So as some of you have upgraded to the latest version of IPS v4.7.14 with Marketplace removed, what is your workflow for the upgrade now that the upgrade itself no longer verifies third party apps/plugins are approved for the target IPS version by the developer? Running a TESTINSTALL website and upgrading everything then manually spot checking everything before upgrading any official sites (good practice BTW) Going to N developer sites and verifying each of your apps/plugins is marked as compatible, noting some just say 4.7+? It was certainly always helpful to get a comprehensive preview of what was identified as version approved by devs during an upgrade. Not sure how this exactly worked, but that part is missing now.