eserrano

You’re welcome, Ben! Great plugin, by the way.

I think you’re right about the settings page: having its own page would make it more intuitive.

I guess this should be marked as solved now.

That part isn’t updated yet on the “installation” tab. But it is already updated in the plugin description.

In WordPress 3.5+, the configuration options of this plugin are inside Settings > Reading

I’m glad it helped!

I still don’t know why this happens only in some of my installations, but if I didn’t add that line of code, it would keep failing.

So I don’t know the causes, but I know what happens if you don’t filter out revisions in that query.

The post_type retrieved could be revision (not post or page). So if we are given data from a revision, we would always end up inside the function:

custom_permalinks_original_post_link($post_id)

Continuing with the execution, right after the filters are removed, and precisely in line 666, we would execute:

get_permalink( $post_id )

And since $post_id is the ID of the revision (not the ID of the original post or page) tracing the output would always return something like:

[ID]-revision

Which isn’t what we expected and leads to a 404 error. However, if we used the ID of the original post or page when calling get_permalink, the function would return something like:

my-custom-permalink

This is what we expected, and it works flawlessly. That explains why filtering out revisions in the query performed at line 164 solves this issue.

I think I found it. At first I thought that it was some kind of cookie conflict related to the usage of the deprecated function wp_setcookie instead of wp_set_auth_cookie, so I went ahead and updated it replacing:

wp_setcookie($user_login, $user_pass, false, '', '', $rememberme);

by:

$theUser = get_userdatabylogin($user_login);
wp_set_auth_cookie($theUser->ID, $rememberme);

inside wp-members-core.php. But I had no luck with that, as the user wouldn’t be kept logged in.

So then I thought about the $rememberme variable. I couldn’t find where it was set. So maybe I was missing something, but $rememberme just didn’t seem to be set.

Since we had already taken the given value of the rememberme option from the user input, just a couple of lines above all that:

$creds['remember'] = $_POST['rememberme'];

I decided to use that value when setting the remember me cookie. So the resulting code was:

$theUser = get_userdatabylogin($user_login);
wp_set_auth_cookie($theUser->ID, $creds['remember']);

And it worked! The logged user can be remembered from now on.

Maybe the form could also use some esc_attr-style parameter sanitization for security reasons, but other than that, the fix should work perfectly.

By the way, it is a great plugin, Chad.

Maybe it is now a problem just on the interaction between Headspace 2 and ACF.

Is anybody having a plugin interaction issue between Advanced Custom Fields and other plugin different from Headspace 2? I know my problems where fixed when upgrading to ACF 3.0.2

I think that the version 3.0.2 of Advanced Custom Fields seems to fix this issue. It did for me. Great work, Elliot. Thanks.

Okay, I’m not sure about why some plugins might be conflicting with Advanced Custom Fields 3.0.0 or 3.0.1 on WordPress 3.2.1 but, my problems seemed to be completely fixed when updating to Advanced Custom Fields 3.0.2. I guess that version fixes the issues.

So do you think it is caused by a plugin interaction?

I don’t have Headspace2 installed. So if this is a plugin interaction between Advanced Custom Fields and other plugins, it is not limited to Headspace2.

Headspace2 adds some additional fields to the edit post interface, doesn’t it? Maybe plugins adding more fields to the edit post interface should be the suspects of such malfunction.

Just checked the Advanced Custom Fields version 3.0.1 in WordPress 3.2.1 and the conflicts between the links of the edit post / edit page with ACF persist. Most links and buttons remain unresponsive. I verified this keeps happening on the latest versions of Firefox and Chrome.

Elliot, these issues are still there in the 3.0.1 version of the plugin combined with WordPress 3.2.1.

I think it’s the same as initially reported on this thread.

It’s not only about the “Insert Link” option but about several other links in the edit or create new post / page interface (edit slug, insert image, select featured image, add tags, change scheduling date, etc.)

Thank you for the suggestion, Jackie, but I have already checked that. And I’m 100% positive that I have the features I want enabled on those checkboxes. I even tried to unmark the checkboxes and then enable them again, with no luck. On top of that, I actually see the links and buttons I want to click – it’s just that they aren’t responding. So the problem isn’t there.

I’d say that there’s some kind of conflict between Advanced Custom Fields and the Javsacript of WordPress, making several elements (visible buttons and links) in the edit post interface not work at all.

The only workaround I found so far is to disable the plugin of Advanced Custom Fields and then performing those tasks that were failing before that (like editing the slug, inserting images, editing the publishing date, setting the featured image, etc.) And then, re-enabling the plugin again (fortunately, the configuration data of the Advanced Custom Fields aren’t lost in this process.)

But of course, this procedure causes some downtime of the features depending on Advanced Custom Fields, and I really fail to find where the conflict between the plugin and the WordPress buttons and links is.