Kyle Phillips

My first inclination would be to question if it’s a conflict with page cache, but there are workarounds in place for both favorite buttons and shortcode-generated lists specifically for this.

There isn’t anything I can think of that you would be doing wrong.

Is this something on a public site you could link to?

Christopher,

I may have misread your question earlier in our offline communication. If you’re looking for a way of displaying user favorites all in one place… yes, you’ll only have access to registered users.

Non-registered users’ favorites are saved by either session or cookie, not in the DB.

As for styling, I believe you can use the get_user_favorites() function to get what you’re looking for.This function returns an array of post IDs. You can either loop through that array, or pass the array of IDs to a new WP_Query object (using the post__in parameter):

https://gist.github.com/kylephillips/9fe12f195c671c989af3

1) I probably should been more specific in the documentation. The favorite count is not part of the default favorite button, although I can see where that would be a nice feature. By post entry screen, I’m referring to the default wp admin edit screen. The count is available via the template function the_favorites_count(). I like the idea of having the option to display that in the button itself… I’ll look at adding that in a future release.

2) RightBeatRadio is correct… there is an AJAX call that updates all the buttons on the page after it has loaded. This is a workaround for sites with cacheing enabled. There will be a noticeable delay if you have other elements loading that hold up the dom from being ready, or if the server is slow to respond to the request.

3) I’m guessing this may be related to #2. If the server is slow to respond, and the page is refreshed before the action is complete, it may prevent the favorite from being saved. I’ll look add adding a “loading/saving” indicator to the button to provide a visual cue that something is happening in the background.

Sorry for the late reply. You may want to ensure the plugin scripts are loaded and available for your custom scripts. Try adding the plugin scripts as a dependency when you enqueue your custom scripts:

wp_enqueue_script('your-script-name',  '/path-to-your-script', array('simple-locator'),
'version');

@jivedig, that’s a great solution. Thanks for posting. I may try working something like that into the plugin core/options.

If you’d like to show all locations, regardless of proximity, you can do that using a standard WordPress loop, querying the “location” post type.

If you’re looking for a way to keep the search form, but “preload” in all your locations without doing a location query, there isn’t a way to currently do that.

Is there any other info you could provide that is specific to your site(s)?

I’ve run a test on a fresh WPMU install and the Media Library is still showing (after both individual plugin activations and network activations).

It’s most likely due to the “public” parameter being false.

If setting that to true resolves your problem, I will make some tweaks to the plugin to accommodate (another user was having a similar issue with another CPT, but I never got confirmation about a possible fix).