Adam Franco

Upon further investigation, this error was triggered by editing an already saved post with an OSM shortcode that includes a broken KML link. I’m not sure how this got saved previously, but having the file_list parameter end in just / instead of an actual filename seemed to initiate the sequence of errors.

[osm_map_v3 map_center="4.176581, -80.231335" zoom="3" width="90%" height="800" control="scaleline" file_list="https://site.example.edu/files/2019/06/"]

@kwekkeboom, without more information I don’t know what might be going on and why you are being redirected to the login page. I’m running 3.3.2 and the plugin works fine. My one thought is that maybe you are running another authentication plugin that has a “lower” priority (so that it executes earlier) than Private-Feed-Keys and therefor is redirecting to the login page before Private-Feed-Keys gets a chance to authenticate.

One thing you could try to do is change the priorities on lines 31 and 34 of the PFK source from 9 to something smaller:

// Authentication actions
add_action('wp_authenticate', 'private_feed_keys_authenticate', 9, 2);
// private blog plugin checks authentication in template_redirect, so be sure to
// authenticate before it.
add_action('template_redirect', 'private_feed_keys_authenticate', 9, 2);

The other thing you could do is add a debugging line in private_feed_keys_authenticate() to just ensure that function is being executed before the redirect happens.

@kwekkeboom, without more information I don’t know what might be going on and why you are being redirected to the login page. I’m running 3.3.2 and the plugin works fine. My one thought is that maybe you are running another authentication plugin that has a “lower” priority (so that it executes earlier) than Private-Feed-Keys and therefor is redirecting to the login page before Private-Feed-Keys gets a chance to authenticate.

One thing you could try to do is change the priorities on lines 31 and 34 of the PFK source from 9 to something smaller:

// Authentication actions
add_action('wp_authenticate', 'private_feed_keys_authenticate', 9, 2);
// private blog plugin checks authentication in template_redirect, so be sure to
// authenticate before it.
add_action('template_redirect', 'private_feed_keys_authenticate', 9, 2);

The other thing you could do is add a debugging line in private_feed_keys_authenticate() to just ensure that function is being executed before the redirect happens.

Here is a screen-cast that goes over what to expect with PrivateFeedKeys:
https://www.youtube.com/watch?v=PHCyCR9N6CU

Hopefully this explains what the plugin does better and clears up your issue. Don’t hesitate if you have further questions, but I’m hoping this will help get us on parallel tracks.

@the_oilman, feed keys will only be listed in the user’s profile if they have been accessed at least once. The list is built with the follow query:

SELECT
	*
FROM
	".$wpdb->base_prefix."private_feed_keys
WHERE
	user_id = %d
	AND num_access > 0
ORDER BY
	last_access

To see Keys in a user’s profile, log in as that user, copy the feed URL that contains the key, log out and go to the feed URL or open the feed URL in another browser, then look at their profile.

Hi nerlyjen, Colin,

I’m not sure why the keys aren’t showing up in your user profile. The plugin uses

add_action('show_user_profile', 'private_feed_keys_edit_user_profile');

as documented here to add a block of HTML to the end of every profile screen. It should at least give you a Private Feed Keys heading on the profile.

We’re running WordPress 3.2.1 at the moment. What version are you having problems with?

Best,
Adam

Hello alekarsovski, nearlyjen,

There shouldn’t be any change to the feed XML. The keys only should show up in the feed URL when browsing the blog and logged in. Additionally, the key will only be added to the feed URL if the blog is private, since if the blog is publicly visible then the feed can be loaded normally without a per-user key.

Hope this helps,
Adam