Localhost Works Fine but Live Site Generating Header Error

I’ve no idea what’s causing those errors. The usual reason for different behavior between XAMMP and hosted servers is either the version of PHP running or variations in the different php.ini files.

Hmmm, interesting. My XAMPP is running PHP 5.3.8 and my web server is running 5.3.16 but surely it’s highly unlikely something so significant could be the cause?

I appreciate the input bud, but I’ve tinkered and it’s born no fruit.

Any other ideas?

Well the notices are happening because WP Access Control is trying to access properties of something that isn’t actually an object. Based on line numbers and assuming you’re running the current version of WP Access Control, it’s trying to get the ID property of the $post object, except it seems that $post is not actually an object, which seems odd since it is using the global $post object.

If everything is running fine on your local machine, I would assume that this is a small bug or plugin conflict. My educated guess would be that your local server just isn’t reporting warnings and notices to the screen. If you are getting the desired results and a looking for a quick solution, you can try this:

First confirm that the notices are actually triggered on you local copy. Add the following code to the top of your functions.php file, inside of <?php tags: error_reporting( E_ERROR | E_WARNING | E_PARSE | E_NOTICE);. If you are now seeing these warnings on your local copy then the difference is the error reporting. If this is the case you can delete that line and check with your host about turning off PHP notices. You could turn them off yourself by adding ini_set('display_errors', 'strerr');. Ideally, you’ll have your host change the error setting on a higher level, but if they can’t help you this should work.

Ideally you would do some debugging with the error_reporting function above and see if there is a plugin conflict. If this problem occurs with all other plugins disabled I would put in a support ticket with the developer of WordPress Access Control.

Good luck! Respond if you need any help

Thanks for that bud, I just tried adding the extra error reporting to my local site, you’re not going to believe this, nothing, no errors it still works perfectly!

The first two errors may be linked to something else, but regardless they’re only warnings, the header error on the other hand is fatal and is what is dragging the site down. Now I understand why header errors are generated, because something is trying to write data to the header after it is already loaded, but I just can’t see how that helps me!

I’ve tried deactivating the plugin and it stops the error, which is both useful and a massive pain as my security structure was built around this plugin! I’ll take your advise and raise a ticket with the dev’s but I’ve never had much luck getting responses from dev’s so if you have any other thoughts please feel free to share.

Thanks for all your help.

I would still try disabling errors on your live copy. You’re right that the first two are “just notices” that don’t really “stop” anything. The third, which is fatal, actually happens because the server is allowed to write out these errors, so it is printing errors to the browser screen, which is fine, but then later WordPress is trying to write header information, which cannot be done because stuff has already been written to the document (once document writing starts you cannot write header information).

If you’re OK with coding and modifying the plugin you could wrap the two if conditions that are causing the notices in additional if conditions to test that $post is an object. It may also be as simple as running setup_post($post); before the $post object is used, I’m not too familiar with this plugin.

Ok, I’ve been digging into this and I think I know exactly what the problem is I just don’t know what to do about it.

It seems you were right I was hasty to dismiss the two notices, as you pointed out they indicate that the $post global is being read as empty. Here is the section of code that’s playing up (note this is from the plugin so not my work, but the dev’s have unanswered tickets from over a year ago):

function check_for_members_only()
	{
		global $post;

		if ( is_admin() ) return;

		// Check for a members only blog
		$blog_is_members_only = get_option( 'wpac_members_only_blog', false );

		if ( $blog_is_members_only && ! is_user_logged_in() ) {
			$redirect_to = get_option( 'wpac_members_blog_redirect', wp_login_url( $_SERVER['REQUEST_URI'] ) );

			if ( empty( $redirect_to ) ) {
				$redirect_to = wp_login_url( $_SERVER['REQUEST_URI'] );
			}

			header( 'Location: ' . add_query_arg( 'redirect_to', $_SERVER['REQUEST_URI'], $redirect_to ) );
			exit();
		}

		if ( get_post_meta( $post->ID, '_wpac_is_members_only', true ) && ! WordPressAccessControl::check_conditions( $post->ID ) ) {
			if ( is_singular() ) {
				$redirect_to = get_post_meta( $post->ID, '_wpac_members_redirect_to', true );

				if ( empty( $redirect_to ) ) {
					header( 'Location: ' . get_bloginfo( 'wpurl' ) . '/wp-login.php?redirect_to=' . $_SERVER['REQUEST_URI'] );
				} else {
					header( 'Location: ' . add_query_arg( 'redirect_to', $_SERVER['REQUEST_URI'], $redirect_to ) );
				}

				exit();
			}
		}
	}

The equivalent for non-members has the same problems. The specific line that is throwing the error is:

if ( get_post_meta( $post->ID, '_wpac_is_members_only', true ) && ! WordPressAccessControl::check_conditions( $post->ID ) ) {

This suggests that you’re right and for whatever reason the global $post is empty so the code cannot run this check.

I’ve tested three scenarios for loading this page, navigating to it works fine, after the refresh has been called (after changing the post url and title) it errors and if you try navigating to it directly it errors.

All of these scenarios work correctly locally.

So this leaves me with a definite problem at least, why is the global empty? But leaves two obvious questions: What do I do about it? Why is it only on live not local?

Any ideas bud?

I fixed this problem.

The issue was when the code modified the page title / url then refreshed, for whatever reason the global was returning empty.

So to circumvent this I added a little bit of code that checked if the global $post was populated, if it wasn’t then it would pull the current url and explode it, using / as a separator it then finds the last bit of the url (the post name in WordPress), converts it to the correct format as a string and then uses some other functions I’ve previously written to find the post id from the title and use this instead.

This has plugged the error but I also had to add a manual field to give the new posts of custom post types the security status.

Beyond that it is now working as expected, just had to modify the plugin slightly.