Chris Anderson

Already done as noted above. I run "Disk Cleanup" on my PC, clear my cache in my browsers and use Wise Disk Cleaner to further clean up my PC several times a day to minimize cookie tracking and ensure my browser has a minimal amount of potential problems lurking in the caches. I don't do this while actively browsing the ACP. It happens before or after. I use browsers with added security features enabled when browsing other sites but for accessing my site I use default browsers with no added plugins or tweaks to the settings. I want to mimic as best I can the "average" user who may be accessing my ACP or front end.

No to both. I also disabled Rewrite URLS to eliminate that as a possible cause. These are proof of concept sites at this point in time. The only person interacting with the site is me.

When it pops back to the right formatting it isn't just for the menu page I just clicked but all of the ACP.

Stored Access Information has been updated on all sites. Uploads directory and all subdirectories are all assigned the same permissions for all sites. Uploads 0775 Sub Directories 0777 Logs 0775 Mind you the ACP pages are properly formatted 99.9999% of the time and the errant behavior can snap back if I click on the right menu option. This doesn't happen on just one site but all 4 primary sites. This isn't a recent problem it has been happening off and on for weeks.

All jokes aside, not everyone visually processes things the same way when it is in a small, medium, or large format. A one size fits all approach will leave some folks at a disadvantage. If someone has less than "normal" vision, it can be quite challenging to comfortably read everything that is presented to us as we visit one site after another. It would be nice if sites running this software suite could be the exception to the rule. There may be value in offering a variety of different fonts instead of being locked into one. Doing so would likely increase the amount of content actually read and reacted to, increasing overall engagement. If one font appealed to one and all there wouldn't be thousands of free or purchasable fonts out there. A vast majority of these fonts are created to be aesthetically pleasing, not for increased readability. There are some fonts that might work far better for some portion of your members, as it stands today, we can't readily offer them an option. If your site is geared more towards educating, then things get more complicated. People learn in a variety of different ways. Some like to read content, some like to hear it, and some want to visualize the material being presented, and many want a combination of all three at their fingertips. Having an all-text site leaves many people out in the cold. Having a built-in ability to hear text would be great for those that want to give their eyes a break or are severely sight impaired. So, I'm not sure if @Jordan Millerwas being lighthearted in offering up the Bionic font for discussion or was trying to strike up an earnest conversation around fonts and how they can be better utilized to serve our communities.

I imagine for some folks it would be NSFW so its best we don't delve too deeply into this subject.

Simply clicking on random ACP menu items will occasionally create a situation where the page loses formatting. This has happened dozens of times. Exiting out of the ACP and back doesn't correct the problem. This doesn't happen just on one site but on multiple ones. Purposely clicking on random menu items never seems to elicit this behavior. It happens when you aren't looking for it. Clicking on one of the menu items again "sometimes" brings the formatting back, but most of the time it doesn't. In order to recover full functionality of the ACP I have to thoroughly clean the browser cache. This doesn't happen solely with the Edge Browser. I tried Mozilla Firefox and it happened with that browser as well. When you click on the errant menu item there seems to be a brief pause before the normally formatted ACP menu item changes to an abnormally formatted ACP page. So far, it's always IPS menu items and not third-party ones that are exhibiting this behaivor.

This Bionic font might be appealing to a segment of one's audience but likely not all. It would be interesting to see if you could provide a toggle to change the display font and size.

Just wanted to give you a head's up as it might not be something you might overlook as part of your compatibility testing.

Testing 4.7 Beta 6 today with the Invite System 2.6.6 app enabled. When I click on any of the groups, I get the following error: As long as "Invite" is enabled you can't modify "any" group settings. So, it's a bit of a problem. 😑 This occurs if server is running PHP 7.4 or PHP 8.

This will be toggled on or off via your hosting provider. Some providers will have a user accessible php settings page where you should find this setting. There is no consistent location for php.ini files from hosting provider to hosting provider. Sometimes they are hidden from view and sometimes they are unalterable by users or certain settings are ignored. You should be able to view your php.info output in your ACP support page. If you can't readily find your php.ini file and aren't provided access to turning off php display errors then you might have to contact your hosting provider customer service and ask for help.

Currently running 4.7 Beta 5. I downgraded to PHP 7.4 and I am now getting prompted to upgrade to PHP 8 not once, but twice. Many an admin will "Fix This" and wonder why they experience problems they never had before. I will get off of my soapbox now.

@Sonya*The app you are asking about is the LearnPlusLMS which was a custom app job.

I reached out to Spanner's widow to see if some arrangement could be made to transfer his apps to someone else, and she indicated his will stipulated he did not wish his work to be transferred.

Please see my findings attached below. If a customer installs the suite on a site running PHP 8 or higher one would assume that all of the marketplace apps would be compatible based on the statement above. Even though PHP 8 has been around for 1 1/2 years many marketplace apps are not in fact fully compatible and in some instances, they will break a site hard if they are enabled with PHP 8 running. You might be expecting marketplace developers to keep their apps compatible with each new PHP release, but they are not consistently meeting those expectations. A lot of assumptions are at play here. I'm simply recommending that IPS and marketplace developers be more explicit around PHP compatibility to minimize problems going forward. Encouraging customers to upgrade to PHP 8 could be very problematic if many custom and marketplace developers have not ensured their apps are fully compatible. A site is bound to show very strange behavior that will be difficult to trace from a customer's perspective and IPS support and marketplace developers. I updated to PHP 8 approximately a month ago while testing out 4.7 betas. I reenabled all of my third-party apps and I couldn't log into the ACP any longer. Revert back to PHP 7.4 and I could. After disabling all third-party resources, I painstakingly reenabled them one at a time to find out the last resource was NOT compatible with PHP 8. It's quite possible that those individuals that had purchased that particular resource hadn't updated to PHP 8 so the developer never received any reports of incompatibilities, I myself had used the app without any incident for a year but on PHP 7.4. Once being apprised of the situation; I was told the resource had not been vetted to run on PHP 8. So as long as I don't enable that app which has great value to my site, I can use all of the others. I have only installed a small portion of third-party apps so I don't know how many more will be problematic. There might be just enough apps incompatible with PHP 8 that I won't be able to update to that version for some time. So I will revert back to PHP 7.4 which will be problematic as some of my resources will only support PHP 8 going forward as the developer has chosen to drop support for PHP 7.4 going forward. Each PHP version currently available has minus and plusses in their use. I'm simply encouraging some clarity around the issue so that customers can choose a version that's best for their unique needs and have the requisite information to make an informed decision. That should come from both the IPS team and marketplace developers. The more forthcoming you are the less one-on-one support interactions you will have to endure. PHP Audit.docx

Many self-hosted servers are setup to support running just one version of PHP. All PHP scripts need to support that particular version or there will be compatibility issues. Now that PHP 7.4 is approaching it's EOL there will be a concerted effort by developers to ensure their PHP code supports PHP 8.0 and PHP 8.1 in the very near future. The challenge is that some developers will release products that will only work when PHP 8.0 or PHP 8.1 is running on a server as they will have decided to abandon support for PHP 7.4 all together. So IPS and custom and marketplace apps will support (or not) a variety of vastly different PHP versions for the next several years. With the upcoming release of 4.7 developers are already starting to upload compatible updates of their apps. The rule of thumb in the past has been that marketplace submissions had to fully support PHP 7.4 and support for PHP 8 or higher was optional, so there was little reason to note PHP compatibility. Now that PHP 8 support is no longer going to be optional but will soon be a necessity the marketplace will need to track PHP compatibility for each new release. After a quick audit of the new marketplace releases, some developers are being very diligent and are clearly noting which PHP versions are supported and some are not. It would be nice to put into place a marketplace guideline that all new uploads post 4.7 should clearly state which PHP version or versions that release is fully compatible with. That way customers can audit their marketplace purchases to see if all of them will uniformly support a particular PHP version. It would be great if IPS added an additional "File Information" attribute as shown below to allow customers to more readily see and search for PHP version compatibility on this site and in the ACP marketplace. Hopefully, PHP 8.2 and beyond we won't have to worry so much about PHP compatibility.

Okay, cloud customers may not have their very own server, but they do have a centralized place to manage various settings and install and manage custom and third-party apps. Some additional functionality to assist in troubleshooting and fixing minor issues with custom or third-party apps would go a long way towards helping convert a subset of self-hosted customers to become cloud customers or those individuals thinking about becoming a hosting customer.

I can appreciate why locking down a cloud server would be appropriate for a VERY large portion of IPS's clientele but by doing so they lock out a segment of their client base that would consider choosing to purchase a cloud server subscription if they were afforded the ability to manage and troubleshoot "some" aspects of their cloud server environment such as marketplace and custom apps. Maybe IPS could open up a section of the ACP that would provide a little more access to "that" server instance, but it would require agreeing not to hold IPS accountable for any missteps. If something were to go amiss IPS would simply offer to restore the site to a prior state. I'm thinking that the additional access to be able to manage "some" aspect of one's own server would only be granted to those individuals that have shown they have a team in place that knows what they are doing, as evidenced by the client's support tickets (or lack thereof) over a course of time for new and existing customers. This might be done via the installation of a plugin. If a client manages their cloud server well the plugin remains installed, the moment they show they aren't up to the task of minimally self-managing their server a customer support person would simply uninstall the plugin.

You tested PHP version 7.3.33 which the requirements checker found suitable. I would recommend switching to the other PHP versions and rerun the checker again to see if one of the required modules isn't being loaded for that particular php version.

You might consider installing the Requirements Checker found below on your server to see if the current PHP settings meet the minimum requirements for the IPS Suite. Once installed you open up a browser and type in your domain followed by ips4.php like this: https://www.mydomain.com/ips4.php It's not out of the realm of possibility that one of the required php addons is not being loaded. This checker may alert you of which one. If one or more are not being loaded, then you need to work with your hosting provider to get them loaded for you. If you manage your php settings via a GUI interface all you might have to do is to select the missing addons and save the settings.

@Jordan MillerCould you please be a little more specific in regard to these lists. The above list seems to indicate a list of identified issues that the developers have acknowledged as being a verifiable issue warranting a fix. What is up for debate is when one could expect each of the above fixes to appear in a release. Is it the next beta, 4.7, or in some future 4.7.x release yet to be determined? Knowing "approximate" release times helps an admin better manage issues such as workarounds or managing customer expectations. An issue that will be fixed next week requires an entirely different management approach than that of an issue that could take several months before being resolved. This would also assist in the beta testing process, knowing when a reported problem is supposedly resolved the beta testers could test the fix one more time to ensure that it is fixed under a variety of different testbeds. This would really be helpful now that we have a near monthly release schedule.

The problem is that the big social media companies have zero loyalty to their users or those of us that would like to integrate with their platforms. They giveth access one week and pull it the next with little to no notice or exclamation. That means integrations have an extremely short shelf life. Then you factor in the fact that they randomly revoked access at the individual level on what seems like a whim. When things go amiss IPS is likely the one blamed when they are trying to be helpful to us.

There seems to be a fair amount of forum topics related to Facebook, here is one to get you started:

Well, IPS has outlasted all but a few competitors. While that has benefits, a little good old-fashioned competition is good for businesses as it often inspires employees to be ever more creative and to push themselves and their company as a whole to be just a little bit better year in and year out. Without competition businesses often become more and more complacent and more willing to accept the status quo. There's a term in the startup world, the MVP or minimum viable product. Too often that becomes the norm for product release cycles and not for the early months while you are striving to make it big. With no "real" competitors companies tend to release a string of "nice" features and never seem to stive to release only "great" ones. They embrace quantity over quality. Meeting you customer's needs is "fine", but delighting them? That can really set a company apart and make them truly competitive in the marketplace, even against far larger competitors. Instead of releasing a bunch of features one after another I would encourage looking more holistically at the product suite and release features that work together to better allow communities to interact more effectively and truly delight their membership. Release a feature once with all of the things one would want on day one not fill in the missing pieces over the course of many subsequent releases. Release a feature once (and be bug free) then move on. Repeat the process with the next feature. That would be something I would like IPS to strive for in the future, doing so would put the last remaining competitors in their dust.

If I remember correctly setting up Zapier required downloading two .htaccess files one went to the same directory as your index.php file resides and another would be placed in the /api directory. The htacess file needed to have a period placed in front in order for the system to register it's intended purpose. Both files would become hidden unless you control panel was set to unhide it. When the two files were in place a new configuration screen was shown to me to configure the Zapier credentials. Have you at least made it to that step? You might need to refresh the system cache after placing the two htaccess files for the configuration wizard to recognize their existence and proceed to the next step. That helped for me if my memory is correct.