Chris Anderson

IT's hard to know the overall value of any particular thread. Just because it has lots of comments and some posts have some likes it's hard to gauge its overall value. Having a visual que that a topic has an overall positive value would be helpful (like a Rotten Tomatoes score for movies), this might be thought of as a sentiment score. Does each new contribution increase the sentiment score or not? This might be attained by helping to keep the conversation on point and bringing useful insights and knowledge into play Instead of "liking" a post you might instead acknowledge the value that post brings to the conversation and community as a whole. Maybe this type of "liking" wouldn't' be publicly viewable but is tracked to determine an overall sentiment score. Is it worth my time to read through the comments and participate further or should I ignore it and skip onto the next forum topic? It's really hard to know for sure. Sometimes a topic for discussion will have multiple instances being commented upon at the same time. Which one do you participate in, well if one has a higher sentiment score that might be the better one to participate in. Tracking member likes has value, but there might be even more value in tracking their contributions to topic sentiment scores. The more they contribute and get acknowledged for their contributions the higher their score becomes. The score could reset on a yearly basis. This would encourage people to keep returning on a continuous basis so that they can continuedly be seen as a valuable contributor to the site.

There are portions of the codebase that doesn't get utilized by the average site owner. There could be certain settings that get enabled that utilize a section of code that might not play well with new PHP releases. It's in the realm of possibility that one site might not encounter any compatibility issues. One site claiming that all is well in the world doesn't necessarily mean that everyone's world will be peachy. It's quite possible that there might be problems yet to be discovered. Although some folks step us to beta test each build its pretty much a free for all. People will randomly test things likely leaving portions of the suite untested. With "some" structure thrown around client beta testing a larger amount of the code could be tested minimizing the amount of follow up releases needed to be fully compatible with each new PHP release. Helping marketplace developers better address future PHP releases would be a worthy conversation to have between IPS and the community.

@Adriano FariaInclusion of the Members Shop on a site could become quite integral to a site's continued success. If a feature suddenly disappears or is altered, it could adversely affect a finely tuned implementation. With IPS and the PHP developers adding, changing and deprecating functionality at a steady pace. One wonders how that might affect the Members Shop codebase you took over just over a year ago. Do you anticipate having to rewrite portions of the code to ensure the product will continue to work in the coming year or two? If so, do you have a high confidence level that any such changes will not substantively alter or break existing functionality in such a manner it might adversely impact a site? I'm trying to design a rather complex site and Members Shop could prove to be a huge value add. That is likely to be the case for everyone that has or will purchase the app. A Members Shop implementation will likely be pretty much set in stone, as such, one wonders how likely one might be faced with a release that materially affects said implementation? Launching a site only to have to revamp it could prove the downfall of a site. As such, I'm sure your customers would appreciate ample heads up if such an occurrence is even remotely possible and to work with your customer base to find ways to minimize the negative impacts such a release might cause. This is an app your customers are quite invested in, as such they will want it to have a very long lifespan. The world is becoming increasingly unpredictable, and you might find yourself in a position where you can no longer continue to maintain this app or your many others. It would be nice to have some plan in place to gracefully hand your apps over to an equally talented developer or developers, if the need suddenly arises. Thanks for all that you do!

I'm not advocating that you keep us apprised of features like: "A friendly reminder before posting" that you announced yesterday ahead of time. This feature is entirely opt-in. Those sites that want to take advantage of the new feature are free to do so on their schedule. If an upcoming feature will require a fair amount of social engineering and configuration to use it to its fullest, more of a heads up would be helpful. A feature that would fit this scenario well would be “Member Achievements”. The various languages and third-party integrations you utilize are constantly being updated to stay compliant with new standards or to markedly improve their utility. At various points in time, you may have to rewrite portions of the suite to extend the product's lifespan. Some things might remain unchanged, and some things might require a complete reset such as subscription renewals. (Just using this for illustrative purposes). That could be “consequential” for sites with little to no cash reserves to tide them over until all the subscription renewals could be reenabled for all the effected members get around to restarting their subscription. I am advocating that you keep your customer base apprised of such occurrences with as much head's up time as you can. If for example you must fundamentally rearchitect themes, we will be forced to use your provided default theme until such time as the theme creators revamp their offerings. If the changes are too radical and time consuming many if not all the existing providers might exit the marketplace. It could take time to recruit replacements and a variety of compliant themes get released due to a high learning curve. Some sites could readily adapt to the default theme, and some might not as their members are extremely attached to the look and feel of the site and various community value adds that are integrated into the theme. You may have a multitude of different projects on your radar. I’m in no way advocating you to keep us apprised of all of them just, the “consequential” ones we will have to address in the next rolling six to twelve months.

@Andy MillneCould you elaborate further on this setting: How can one utilize this setting above to its full effect? Some illustrative use cases would be appreciated. How could one utilize this functionality to be able to increase the value of every match made? If this app was used on this site, would I be matched up with everyone that uses the "Meow" reaction. What does that say about my interests? Did I express meaningful interest in this topic? If someone else uses the "Meow" reaction a lot, do we share any meaningful interests? How do you weigh each reaction to determine if someone shares similar interests considering no two sites are likely to use exactly the same ones? I don't often react to posts here as there isn't really an appropriate reaction available. Based on that I would unlikely be well matched up with anyone else here. Has this app been fully tested to be compatible with PHP8 and 4.6.11?

@Jordan MillerI'm not advocating for radical change in clarity but incremental improvements here and there that one day will lead to something substantially more useful to the community as a whole.

@MattI will give your team kudus for talking about some of the substantial features in advance. But often times less substantial features don't get mentioned when they are to be added or changed ahead of time. When they are mentioned the details are often lacking to make an informed decision as to whether or not to implement it or the likelihood that it will undergo additional development based on customer input. I strongly advocated for a comprehensive release notes and I applaud your efforts to track adds, changes and deprecations. You track a lot but there are some that don't get addressed or could benefit from a "little" more information here and there. This would be especially helpful to those individuals that don't yet have a great understanding of the platform or particular feature usage. When is a feature complete (for all intents and purposes) and when are you open to further development? Further development might bring the feature to a point that it would be useful on one's site, or it could make it unsuitable. There are dozens of features that make up the software suite. They all are intertwined together. When meshed together in just the right way you have the makings of a real "community". A feature that is in continual development with no clarity of when said development is "feature complete" one can't reliably know when it makes sense to implement it (or if it will ever work for your unique environment). An example of this would be Member Achievements. Member Achievements is a feature you can toggle on or off but that isn't the case for all features. Some features you are forced to use whether or not they are really fully developed (for your purposes) and bug free. A feature could work for your site with just "one" change or addition to it. Are you the only one that wants it or is there actually significant pent-up demand for its inclusion? When is it prudent to hold off updating your board, one month, two months or six months? Without better clarity from your team its next to impossible to make an informed decision. Also, you have to live with all of the unpatched bugs or security vulnerabilities that are discovered and corrected in the interim. Skipping too many monthly releases in a row increases the likelihood of encountering unrecoverable upgrade issues. You aren't actually pushed to upgrade but not doing so could come at a price. Features that include a lot of different configuration choices are likely the ones that could benefit the most from additional clarity. Changing just one of those choices "could" materially change a feature's behavior, especially if toggled on or off by default. That behavior could be beneficial or not. Being made aware of such would be useful to know prior to deciding to upgrade and give customers an opportunity to say, "Hey wait a minute", let's rethink this feature prior to release.

I mentioned that myself in my initial post but deleted it figuring it would be akin to preaching to the choir.

Social media companies are constantly adding value and creating better user experiences for "free" for their users to partake of. How will any upcoming features (or improvements to existing features) being planned for release in the next year "really" tip the balance in our favor for current or future users to pay us for what they can readily get free elsewhere? "Your" heart might be in the right place, but the lack of clarity from IPS makes it difficult to plan, grow and monetize a site that will be around for years to come with just a vague hint here or there of what might be upcoming in the months to come. As it stands today, there is no way to plan for the long term, how can one do that based on vague hints here or there? The only real chance of being a successful site is to plan for the future so that one can implement a new feature in such a way as to minimize disruption to the existing community and to maximize its overall value, and maybe, just maybe figure out how one might monetize it. Having new features sprung on us on a monthly basis with little to no forewarning that they are on the way prevents their introduction to the community in a planned fashion. Often times a new feature or refinement of an existing feature has an impact on the community forcing users and admins to be in constant reaction mode. Many folks like platforms with a modicum of stability and notices of upcoming changes, unfortunately with you as our software platform provide, we can't offer that to them. Maybe IPS could create a new user group for those that would like to be kept a little more in the loop. Anyone that opts into such a group would be kept more apprised of your long-term development plans and changes you might make to said plans or upcoming deprecation of features. Inclusion to this group would come with the promise to not mention anything discussed with those not a member of the group without express permission from IPS management. This group wouldn't necessarily be tasked with providing input in favor or disagreement of any upcoming feature. That should be left to the customer base as a whole and should happen more often than you currently do. IPS management and developers have pretty good instincts but could benefit from other pair of eyes on occasion. I'm particularly vocal of late as I've had to start and stop a large project as you have deprecated certain features or added or changed features that completely altered various planned implementations. I think that I've hit upon a platform that would work but I have zero expectations that by the time I set up the platform suite and third-party apps that it will still play well with each other in the months to come. I don't expect 100% clarity on the part of IPS (at least overnight), but a significant improvement would certainly be welcomed by the community I'm sure.

IPS has implemented a variety of different integrations with third-party sites that are better funded and employ folks well-versed in solving particular pain points. There are so many pain points IPS can address internally based on their development budget, talent and time. Being transparent up front when encountering such pain points better addressed by others will go along way in engendering customer loyalty. With the announcement of a swag store it would have been nice to have a blog posting highlighting all the pain points you would have encountered in implementing such a turnkey solution in-house and the steps you took to address it via an external third-party. It's quite possible that "some" of your customers would like to offer a similar solution themselves. Why didn't you think to provide a step-by-step tutorial on how we could implement such functionality ourselves? That would have provided a nice value add for those that could benefit from your experience.

Privacy laws will likely evolve over the coming years so it's best to keep abreast of their requirements as well. Payment processors may also review your site guidelines and privacy policy and if it doesn't meet their internal requirements you might have your account placed on hold or closed. One privacy policy trend is to include a brief set of explanations for each section highlighting the overall gist of it. You need to ensure you address you and your customer's interests and all the legal and payment processor requirements you may be bound to in both a simplistic and legally binding manner which often times requires lots and lots of words as way of explanation and to minimize legal exposure. Doing your privacy policy entirely on your own provides about a dollars worth of protection. If your exposure is greater than that then you should seek out someone with privacy expertise to assist you in creating a comprehensive site guidelines and privacy policy.

You might consider reading some of the privacy policies from some of the Enterprise customers using this software to see how they address the data they collect. They should be able to allow you to figure out what things you should address in your site's privacy policy which should put you in a better position of being approved by Facebook. You will also have to audit every app and plugin you install to determine if it collects any personally identifiable data points and include them as well. If you delete a user there is a possibility that an app or plugin they used might not delete or anyomize the data it collected during use. This may impact on whether or not you choose to use it or not.

I think more than ever sites are looking at any means they can to help monetize their sites as expenses to run their sites keep increasing. <Here's looking at you IPS> Are any "new features" in the pipeline this year likely to appreciably help us to further monetize our sites? We can't effectively compete against Social Media companies by "trying" to replicate their feature set so why are we chasing down that path? A conversation we should be having is what unique features could we collectively come up with to entice people to spend their precious time on our sites and cover our expenses more readily and maybe make a few dollars for ourselves. 💰

Disregard, poster posted while I was composing post.

When I click on the Download Event as shown below a calenderevent.ics file is created. When I import the .ics file it creates an event in your email client as shown below: If a member clicks on "Accept", Tentative" or "Decline: one would assume that the response would be sent to the appropriate calander and processed. I don't believe that is the case, but I may be wrong. Does the calendar app indeed accept responses or not? If it does how do I setup my site to accept those responses? If it doesn't, why are you including the "Respond" options in the imported .ics file?

I would be interested as well.

It's nice to offer social logins as they minimize the friction of signing up, but by doing so the site doesn't collect a password from the member. This can be problematic if the social media site goes down or the site loses access to the API. If a member can't login they could very well not return. Accounts created via social logins have the password field unavailable to set. This field only becomes available if a member clicks on the "Forget your password" as shown below, after they have created their account. I'm looking to see if there is some setting that I could enabled to prompt for a password as part of the initial account creation so I can gather passwords for everyone.

@Marc Stridgen Governmental agencies throughout the world are battling with how to protect their citizenry from bad actors near and far. Some of the protections implemented will be well thought out and some will be unmitigated disasters. Sites with minimal technical expertise and or sufficient funds to hire that expertise out will unfortunately find they won't be able to be compliant with various legal requirements. These sites will be forced to close which will begin to impact your bottom line. As much as your customer base would like IPS to dedicate your entire programming staff to adding ever cooler features there may be value in dedicating more of your staff's time figuring out what legal requirements we will likely find ourselves having to address and see if they can be programmatically dealt with. There may be a time in the not-too-distant future where this platform won't be able to be used in certain locales as it simply won't be economically viable to alter it by IPS or a third-party developer to be in continuous legal compliance. Can we as a community come together in partnership with IPS to minimize such occurrences. Every site that closes will diminish the overall value proposition of the internet so it's in our collective best interest to minimize these occurrences.

I added the following customization to the login screen: When I enable your plugin the system ignores your customization, as shown below: Is there any way to use your plugin AND format the "Forget your password?" as well?

Check out the how to here: Constant: CP_DIRECTORY

Applications-System-Contact Us (Deselect Guest) Applications-System-Content Discovery (Deselect Guest) 2 Instances need to be changed. This removes "All Activity" directly to the right of the two instances of home as shown in the screenshot above. You may have deselected Guest access for "All Activity" in the menu but the value may still be cached so it still shows. You may consider running the "Clear System Cache" in the Get Support page and possibly your browser cache. If it still shows you may want to verify all deselections of Guest stuck.

You can utilize the menu in the acp to limit access to menu items and sub menu items by deselecting guests. Once a person registers and logs into the site the menu choices are viewable. You can also deselect guest access to various components in applications, such as search. Click on the lock icon to set permissions. I am using the marketplace Landing Page App and mark it as the default app and assign guest access to it. I then can create a welcome page. With the default menu items non viewable to guests they don't know what the site looks like or it's offerings until they become members.

Logging into the front end did the trick of resetting the time zone for the admin account. Once logged back into the ACP the times showed correctly. Thanks for tracking this down for me. It's behavior I had never seen before after many, many installs so it seemed like something was amiss considering it wasn't consistent.

Even though 24 hours have passed since I installed to the main domain the tasks still show a 7-hour offset. The two sub domains show accurate time stamps. Here is a screenshot showing the 7-hour offset: Please let me know what additional troubleshooting your developers would like to do to help figure out the underlying problem.