Chris Anderson

This also occurs when trying to save permissions for these menu items too:

Store/Donations
Store/Gift Cards
Store/Subscriptions
Store/My Details/Account Credit
Store/My Details/Alternative Contacts
Store/My Details/Payment Methods
Store/My Details/PayPal Subscriptions
 

Unable to further debug for several hours as I am not at my usual computer.

The "Guidelines" menu item fails to save any specific permissions you set on Version 4.7.12.  Please see below for an example:

Normally when you click on the "Save Menu Item" the screen goes back to the Menu Manager main menu.  But for this menu item I am consistently presented with the following screen instead:

The new permissions are not saved and the "Publish this menu" button remains greyed out.

30 minutes ago, Chris Anderson said:

we'll be requiring 8.1.

Based on the plusses and minuses of 8.3 you mentioned above, will you skip supporting PHP 8.2 and jump to PHP 8.3 as your next required PHP version once you have updated the calendar app and taken advantage of the new Read-only classes and json_validate() functionality? 

12 minutes ago, Matt said:

we'll be requiring 8.1.

With 8.3 being released at the end of this year do you see any potential problems with the v5 codebase and tools working with that version considering upcoming new features and deprecations?

Is there anything in 8.3 you are at all excited about?

2 hours ago, jesuralem said:

multiple sellers for the same product

IPS has a larger development team and is more familiar with the codebase so they will invariably release a new product or feature that will widely be used by the vast majority of their customers, but occasionally a developer might create a better version that "some" customers may prefer to purchase.  

An open marketplace should encourage innovation by all developers including IPS.

This would also better address continuity of service. 

Products are often supported for finite periods of time by both IPS and marketplace developers and once a product is no longer supported it leaves customers in a precarious position. 

Having the ability to have more than one version of a product in the marketplace gives everyone the option to be able to migrate to a competing product if the need suddenly arrises or a competitor offers a far superior product from other marketplace developers or IPS themselves.

1 hour ago, Matt said:

I was curious as to what changes you'd like to see

There have been quite a few developers and theme designers that have left the marketplace or are on the fence as to whether they will continue developing for v4 let alone the v5 platform.

Your team has been working extensively on two different codebases and have become quite intimate with it. 

I would recommend trying to visualize how difficult it would be for a developer new to the platform to setup a development environment and learn how to effectively create programs that meet your marketplace acceptance criteria.

Things to generally think about:

• How closely do your programmers adhere to common programming methods for each of the languages you utilize?

• Is your codebase entirely PHP 8 compliant or are you still utilizing code written for earlier versions?  

• Are your APIs intuitive to use?

• Is the cost for entry too high for the first couple of years a developer is learning how to write really good programs and their sales are next to none?

• Could your error messages be more informative?

• How does a programmer effectively test their apps? 

• What lessons learned from your testing team could be useful to a new programmer or to your customers that help beta test two different versions of your suite until such time as v4 is fully deprecated?

• Would it be beneficial to put a little more structure around public beta testing to minimize the number of additional betas or dot releases after final release.

• What might you do differently to make becoming a developer more appealing to make recruitment "MUCH" easier and to keep the ones you already have for the long term?

Are all of the marketplace files you have installed from invisioncommunity.com or did you download them from the developer's site?  It's a possibility that one of their files has been compromised.

23 hours ago, Adriano Faria said:

That’s not a feature and I really doubt I will add something like this. Users earn invitations making posts, bringing content to your site, so I don’t think it’s fair to take away these invitations from them.

Most coupons, sales, and specials only last a short span of time. I think there would be value in being able to set an expiration date (or not) for these types of earned invitations.  This would increase the options available to a site in how they want to utilize your fine app. 

Seems rather counterintuitive to have all of the rest of the modules be able to toggle on and off and the "Support" module doesn't "really" get turned off if you disable it in the ACP.  I will leave it "enabled" and remove it from the front menu as I won't be using it as it's being deprecated.

I have observed the following behavior for several months on two different servers with multiple installs. One running cPanel and the other running Plesk.

I install the Invision Community Suite and set up a cron job running once a minute. This starts the process of each task getting run at different time intervals.

I then go ahead and install various marketplace apps that create tasks that are supposed to run at certain timeframes in order for them to work "as expected".

Upon installing a monthly update or an update to address various fixes I see that all of the tasks are reset.

I have included screenshots of a fresh install on my testbed server just a while ago:

Fresh 4.7.10 Install:

Upgrade to 4.7.11.1

After waiting a few minutes:

As you can see above all of the tasks are reset and start afresh with a new date and time for each task to run.

Resetting tasks will be particularly problematic if you have tasks that should run once every seven days or once a month.  The new timeframe for these tasks will be much greater than a week or a month which might prove problematic. 

Weekly tasks "should" run at the very end of the week and monthly tasks "should" run at the very end of the month not simply 30 days starting on some random start date tied to an update. Having a task run 1 day and 15 minutes is also a problem as you might want that task to run consistently at some point in time but it won't, it will run 15 minutes later each and every day. These random task run times will also make it difficult to plan and successfully execute backups that have everything in an ideal state to relaunch a site again if you have to restore from the backup.

If you happen to do a backup right in the middle of a task(s) and later restore it the site will be in an inconsistent state.   No telling how minor or major this inconsistency will be.  Subsequent restores will further aggravate the situation.  This will likely cause difficulties at some point in time when a site is updated as your programming logic will expect certain things to be in the database or the database might have corrupted data. 

Task running times should be consistent and run at expected times that match up with that year's calendar, so weekly and monthly tasks always run at the appropriate times.  As it currently stands that isn't the case.

Various "Support" related functionality is still active throughout the ACP even though the app has been disabled.  This shouldn't be the case. 

As it makes no sense to start using the “Support” app built into Invision Community Suite as it will be deprecated soon, I went ahead and disabled the app.  Unfortunately, it doesn’t fully disable the app after all as you can see below.

If you disable “Support”:

“Support” related tasks continue to get run daily:

supportAssignedReminder
Sends a reminder email to staff members who have open support requests assigned to them.

supportAutoresolve
Marks old support requests as resolved.

“Support” still shows up in the Menu Manager:

Go to your ACP and navigate to Themes and click on the "Edit HTML and CSS" option as shown below:

Navigate to:
core/front/global/globalTemplate

Append the following just above </body> which is located at the very bottom:

      <a rel="me" href="https://Your Mastodon Server Name/@UserName"></a>
    </body>
</html>

This will place a hidden rel="me" on the front page of your site that your server should see and validate you.

<a rel="me" href="https://Your Mastodon Server Name/@UserName">Mastodon</a>

"If" you include the underlined "Mastodon" as shown above you will get a clickable link shown up on your webpage which probably is not ideal which is why I did not include it.  You could also place the rel="me" code on other pages you might have on your site but you need to include the page in your profile such as shown below:

https://mysite.com/aboutme.html

Your profile will show your website as being validated but with the page appended to the website.

Depending on your server it could take anywhere from a few seconds for your domain to be validated to several hours.

On 3/14/2022 at 7:59 AM, Andy Millne said:

It matches cases where multiple users leave positive reputation on the same content. The more content you both like the more the algorithm will weight you as having similar interests.

For example if you and I both like the same five topics we will be more likely to show to each other than someone else that has only liked two of the same topics.

The algorithm does not distinguish between different reaction types. It responds to all positive reactions regardless of the specific reaction given. e.g. you may react with a "like" and I may react with "haha" but as they are both positive interactions then the chance of us sharing similar interests is higher.

@Andy Millne I do not see any tasks created that relate to this app.  Did you add additional functionality to an existing task?  If so which one? 

I'm trying to gauge the impact this app might have on a server.  If you have a site with tens of thousands of members all reacting positively to each other how will that impact a site's CPU, memory, and database size?

If a particular member gets a bunch of new likes from other members today how long will it take before they show up in "Similar Interests"?

@Andy Millne The latest uploaded version seems to have corrected both issues.  Thanks for posting such timely updates.

@Andy Millne Unfortunately, when I upgrade to 1.3.1 the site goes offline:

I also got a message from Plesk that the site is offline.  So whatever change you made is not playing well with the site.  I disabled the app and things go back to normal.  Reenabled it and things go amiss.  I also cleared the system caches. 

No errors are being logged in the ACP and the PHP8 Compatability Scanner notes no problems.

I went ahead and disabled your app on my test server while waiting for you to figure out what needs to be fixed.  Plesk sent me an email that the site is back online.

@Stuart Silvester Thanks for letting me know account deletions are being logged in the Administrator Logs. I never thought to look there.

I noticed an anomaly in the Administrator Logs:

Deleted member: Member 4 #9

Not sure what the "#9" stands for.  Could you please elaborate on its significance?

Please look into why your app is causing the error below and fix it.  Thanks...

As it currently stands in Version 4.7.11 Beta 2, once you click on the check mark shown below the deletion process is executed, and no trace of the action is logged.

I suggest that upon clicking on the check mark the request is moved to a new section called "Deletion Requests Completed" with the photo and email redacted as they would be considered PII.  But the deletion request and the day it is completed should be logged for auditing purposes.

This way you could detail later that a member by the name of "X" who joined on a particular date was ultimately deleted "per request" on another particular date.

Here are the steps I took to get the error:

Upon clicking on the "Download" button the following error is produced:

Here is the ACP error message:

11 minutes ago, Square Wheels said:

Well, I set the endpoint back to the default of s3.amazonaws.com.

That endpoint might work "today" but I would recommend reaching out to Amazon to see if that endpoint will always work.  I would hate to have you start relying on the data being available to your users via S3 and one day that endpoint no longer works as Amazon really wanted you to point to a specific endpoint like: s3.us-east-2.amazonaws.com which is what worked for me in the past.
 

I poked around some more at Amazon and discovered that the Group and User that I had created via the how-to guide over a year ago had been deleted so of course I no longer have the requisite permissions to access any S3 buckets I created.  I can understand disabling buckets but not groups or users.

I deleted the account and will create a new one so I can start fresh.  I am not sure if the problems you are seeing are due to missing a step or if there might be some setting buried deep within Amazon AWS that needs to be configured to allow for S3 to work with the IPS suite. 

@Square WheelsYou're not alone in getting the error message above.  I was able to set up and use Amazon S3 in the past using the provided instructions but last night I spent several hours trying to get it to work once again to no avail on several different sites.  The error message doesn't provide sufficient clues as to what might be amiss.

Also "following" a post and immediately removing it gives you an extra point that doesn't seem to get taken back.

Also "liking" a post and immediately removing it gives you an extra point that doesn't seem to get taken back.