yarnboy

Yes, it works with 8.1.

@jewelclark2020 Glad I could help!

Hello again @jewelclark2020. My institution needed to get wp-cassify up and running with PHP8 while we look for a replacement, so I did end up doing some quick fixes. I’ve got a working git repo. Feel free to use if you still need it.

https://github.com/loesberg/wp-cassify-php8/

• This reply was modified 1 year, 2 months ago by yarnboy.

OK, after digging around in this today, I’ve decided that patching this plugin isn’t the best use of my time. My institution will be switching to a different plugin for managing our CAS integration. In the meantime, since you’re on Pantheon, you can temporarily resolve the problem by adding this line to your pantheon.yml file:

php_version: 7.4

This isn’t a long-term solution, as everything ought to be on PHP 8 now, but it’ll get wp_cassify working again until there’s an update, or until you choose PHP 8-compatible solution.

I am having the same issue with the identical setup; the site in question is on Pantheon. We require login for all users, and the site is now throwing a fatal error. I can confirm that this is a PHP 8-specific issue. Version 8 is more strict about the status of variables passed as arguments, and things that were not fatal in 7.4 are most definitely fatal in 8.

I have done some work on this plugin in the past. If I can get a fix in place, I will post it here.

Thanks for the reply, @bizanimesh. Unfortunately, I think I’m going to have to go with changing the ALLOW_UNFILTERED_UPLOADS constant, since, as you stated, WordPress already allows .m4a files. There’s something about this particular file that isn’t totally kosher, and I’ll be darned if I can figure out what it is.

@needle Ah yes, I neglected that part. Thank you! Works like a charm now.

@needle Sorry to reopen this, but I’m having a problem I was hoping you could address. I was able to successfully hook into the civi_wp_member_sync_rules_applied action, but it does not appear that the memberships array is being passed to my function, as the documentation seems to indicate. According to my error logs, the only argument being passed is the user object.

Am I missing something?

Thanks for pointing me in the right direction, @needle. Much appreciated.

Great! I’m not sure wp-config.php is the best place for the custom code, though, as it might get wiped out again by the next update. In my installation, I’ve edited the plugin itself (see my post above). Maybe the plugin author will include my fix in the next update.

Possibly. Depends on how wp-cassify broke. Can you be more specific? Any error messages?

• This reply was modified 6 years, 4 months ago by yarnboy.

The changes are all to the wp_cassify_get_current_url function in wp_cassify_utils.php. See the comments in the code:

	public static function wp_cassify_get_current_url( $wp_cassify_default_wordpress_blog_http_port = 80, $wp_cassify_default_wordpress_blog_https_port = 443 ) {

		$current_url = ( @$_SERVER[ 'HTTPS' ] == 'on' ) ? 'https://' : 'https://';

		// If cassified application is hosted behind reverse proxy.
		if ( isset( $_SERVER[ 'HTTP_X_FORWARDED_HOST' ] ) ) {
			$current_url .= $_SERVER[ 'HTTP_X_FORWARDED_HOST' ];
		} elseif (isset( $_ENV['PANTHEON_SITE'] )) { // Are we on Pantheon? Use HTTP_HOST
			$current_url .= $_SERVER['HTTP_HOST'];
		}
		else {
			$current_url .= $_SERVER[ 'SERVER_NAME' ];
		}

		if( ( $_SERVER[ 'SERVER_PORT' ] != $wp_cassify_default_wordpress_blog_http_port ) &&
			( $_SERVER[ 'SERVER_PORT' ] != $wp_cassify_default_wordpress_blog_https_port ) &&
			!isset( $_ENV['PANTHEON_SITE'] ) ) // Don't use the port if we're on Pantheon
		  {
			$current_url .= ':' . $_SERVER[ 'SERVER_PORT' ];
		}

		// Specific use case configuration for WordPress hosted on nginx behind AWS loadbalancer.
		if (
			isset( $_SERVER[ 'HTTP_HOST' ] ) &&
			isset( $_SERVER[ 'HTTP_X_FORWARDED_PORT' ] ) &&
			isset( $_SERVER[ 'HTTP_X_FORWARDED_PROTO' ] ) ) {

			$current_url = ( @$_SERVER[ 'HTTPS' ] == 'on' ? 'https://' : 'https://' ) . $_SERVER[ 'HTTP_HOST' ];

			if( ( $_SERVER[ 'HTTP_X_FORWARDED_PORT' ] != $wp_cassify_default_wordpress_blog_http_port ) &&
				( $_SERVER[ 'HTTP_X_FORWARDED_PORT' ] != $wp_cassify_default_wordpress_blog_https_port ) ) {
				$current_url .= ':' . $_SERVER[ 'SERVER_PORT' ];
			}

			if ( $_SERVER[ 'HTTP_X_FORWARDED_PROTO' ] == 'https' ) {
				$current_url = str_replace( "http:", "https:", $current_url );
			}
		}

		$current_url .= $_SERVER[ 'REQUEST_URI' ];

		return $current_url;
	}

I am having this same problem. It appears to be caused by Contact Form 7 (I have the problem when the plugin is activated, it goes away when it is deactivated). Did you ever get a solution to this?

Thanks Chris! Worked brilliantly.

This is now fixed. I checked with my host and there was a conflicting security rule.