Chris Anderson

Does your ACP resemble this?

I've done some extensive testing of clubs over the past week and noticed some anomalous behavior around the use of "Pages" other than not being able to delete them. Not sure if this is due to other club code interacting with the "Pages" code or the anomalous behavior is only related to the "Pages" code. So, it's in the realm of possibility that there might be one known issue as noted above and another one yet to be fully identified.

If the developers are already reviewing the club code, they might keep in mind that there may be something else amiss and be more mindful with their review. They might spot something they might have otherwise overlooked if they were solely focused on addressing the bug I initially reported. 

As we don't know the extent of the problem related to "Pages" it's hard to gauge this bug's potential negative impact on other club functionality or third-party apps that integrate with Clubs.  Some guidance from your development team on this issue would certainly be appreciated by developers and customers alike. 

I experienced this bug last night and knew that IPS would want me to reliably duplicate the error. I installed 4.6.12.1 fresh on 4 different test sites.  The only configuring I did was to setup a Cron job and to name the site in the "General Configuration" screen.  i did not install any plugins or other marketplace apps.

I went ahead and created a test club on all 4 test sites and then proceeded to create multiple "Pages".  I then attempted to delete them by doing this:

The following screen popped up.  I went ahead and clicked on the "OK" button.

An error message is consistently displayed. A screenshot will be provided below.

I created "Pages" and attempted to delete them multiple times on the 4.6.12.1 install.  I then went ahead and deleted all of the clubs and error messages from the ACP.  I then updated to 4.7 Beta 8.

I created 4 different Test Clubs on each of the 4 test sites and proceeded to create lots of "Pages" and attempted to delete them.  I consistently get the error noted above.  All told I tried deleting 40 different "Pages" with the same errant result.

These are all on test-install sites, so you don't have access details in the ACP.  If you want to take a look at any of my sites let me know and I can provide you with login details.

6 minutes ago, Jim M said:

While I understand this is frustrating having an issue that is not reproducible, however, without seeing/experiencing the issue myself, it would be hard for us to investigate/understand what may be happening outside of the only factor involved (your personal PC).

If it had only happened once on each site and on one browser, I would have marked it down to a random glitch and not reported it.  But as it has happed more than once on all 8 sites something is amiss.  Whether the root cause is attributable to browsers or to your code it's an issue you should be aware of.

27 minutes ago, Jim M said:

Any of this done automatically? That might explain why this is happening to you.

NO

27 minutes ago, Jim M said:

Browsed around, waited, browsed again to mimic behavior of an active admin for a while.

That's just the thing, I can click around for hours or several days in a row and everything works as expected. It isn't happening on just one of the 8 sites I'm testing but all of them have exhibited this behavior (more than once) over the course of the 4.7 betas. When this errant behavior strikes on one site, I will have visited the other seven sites soon after and none of them went into an errant state. The same browser condition, no changes to settings or clearing of browsers. The problem isn't occurring on just one version.

I have two duplicate test sites made up of 4 servers each.  One running 4.6.12.1 and the other the latest 4.7 beta.  I do this so that it is much easier to duplicate issues prior to submitting a bug report to you or to a third-party developer.

When I make changes on the 4.6.12.1 site I immediately switch over to that site's twin running the latest 4.7 beta.  In this way all of the settings on one platform get duplicated to the other.  I also do this to try to figure out what has changed between the two releases.  I tend to click on each ACP menu item and sub menus in my quest to discover what might be different between versions, so yeah, I dive pretty deeply into the ACP. That's what a beta tester does.

I also clear system caches prior to embarking on any testing.

Just now, Jim M said:

I am happy to check it out if you would like to update credentials.

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.

Just now, Jim M said:

Are you using any CDNs? Are you imposing custom browser caching rules?

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.

12 minutes ago, Nathan Explosion said:

So, what are you guys managing to do with the time you've saved reading these items faster?

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.   

1 minute ago, Adriano Faria said:

this a test site

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.

11 minutes ago, MAHMUT ORHAN said:

Public Display of PHP Errors Enabled

Your server is set to display PHP errors. This is not recommended for production environments as it may cause sensitive information to be publicly disclosed. You should contact your hosting provider or system administrator and ask them to set the display_errors PHP setting to Off. 

 

How to turn this off I dont want it on my website, I cant find PHP.ini or anything where this is located?

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.  

23 hours ago, Stuart Silvester said:

We expect Marketplace resources to be compatible with the same versions that the version of the software it is for is compatible with. There have been a few exceptions to this ( I'm thinking of something @CodingJungle wrote ) where the PHP requirements were clearly stated in the description.

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. 

1 hour ago, Rikki said:

You don't have 'a' server when running in the cloud. Our cloud platform has hundreds of instances (which doesn't even necessarily equal the number of actual physical servers) and your site is running on all of them at once. Which one actually handles a user request is decided by a load balancer.

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. 

1 hour ago, Sonya* said:

And what do you use with Cloud clients?

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.