Skip Navigation

[Resolved] Using Types and Views with MapPress plugin

This is the technical support forum for Toolset - a suite of plugins for developing WordPress sites without writing PHP.

Everyone can read this forum, but only Toolset clients can post in it. Toolset support works 6 days per week, 19 hours per day.

This topic contains 4 replies, has 2 voices.

Last updated by Brad 8 years, 6 months ago.

Assigned support staff: Caridad.

Author
Posts
#16041

I have a display page with the body consisting of only the two shortcodes below:

[mashup show="query" show_query="posts_per_page=-1&zoom=10&width=800&height=600&post_type=units&marker_body=marker"]
[wpv-view name="UnitListView"]

Problem #1:

The mashup displays properly, and the outer view of UnitListView displays properly, but results in “No posts found?? on the inner view of UnitListView.

The incorrect output looks like this:
Unit 1 information
No posts found.
Unit 2 information
No posts found.
Unit 3 information
No posts found.

Removing the mashup shortcut produces almost (see Problem #2) the expected result on both outer and inner views of UnitListsView.

The expected output looks like this:
Unit 1 information
Officer A information
Officer B information
Unit 2 information
Officer C information
Unit 3 information
Officer D information
Officer E information

It seems that the MapPress query is interacting with the View query. (Strangely only on the inner view of officers, not the outer view of units.) Can you suggest a solution?

I have also asked about this on the MapPress site. See hidden link.

Problem #2:

When the UnitListsView displays the specific fields specified in the UnitListTemplate, it displays additional, undesired content as well. The MapPress plugin is configured to automatically generate and display a map at the top of a Unit post being viewed. The automatic map display is desired when I display a particular Unit post in its entirety, but not when I wish to display only specified fields within a Unit post by using a Content Template.

The actual output looks like this:
Unwanted automatic map 1
Unit 1 information
Officer A information
Officer B information
Unwanted automatic map 2
Unit 2 information
Officer C information
Unwanted automatic map 3
Unit 3 information
Officer D information
Officer E information

It seems that MapPress is generating the automatic map whenever ANY portion of a post, not necessarily the whole post, is displayed. Can you suggest a way to filter out the unwanted automatic maps when using a Content Template?

I have also asked about this on the MapPress site. See hidden link.

Thanks.

Brad

#16047

In mappress.php the function the_content provides several methods to determine whether to add a shortcut that will create an automatic map or not. Would it be possible to set an appropriate variable prior to or within the Content Template so as to match one of the existing methods, thereby not creating an automatic map?

Or, can you suggest any code additions to the mappress function the_content so that it can determine whether the Content Template is asking for the entire post body (automatic map desired) or just a particular field (no automatic map desired)?

Thanks.

Brad

#16124

Dear Brad,

I tried installing the plugin and I couldn't get the automatic maps to show (is it a pro feature?). I also didnt get the mashup shortcode processed. Can you confirm the url of the plugin you are using?

Regards,
Caridad

#16137

Hi Caridad,

Automatic maps are a feature of both the free and pro versions of MapPress. Automatic maps relate to Problem #2 that I presented. Creation of automatic maps depends on the existence of a user-configured custom field for the address, or fields for lat and lng. If a post has valid values in either the address or the lat/lng fields and automatic maps are enabled, a map is displayed. The function "the_content" in mappress.php shows when these maps are displayed. In the context of Types and Views, the problem is that when a view is set up to return just a particular field, not an entire post, an automatic map is probably not desired. Chris, the author of MapPress has been very helpful and suggested that I could address this problem by adding some code to the mappress 'the_content' filter, such as
if ($myvar == true)
return;

I'm not quite sure where to put that code, though. Any suggestions? I'm still corresponding with Chris on that. I do see how modifying mappress.php could address this, but I believe Chris wants to address this outside of the mappress core.

Mashups are a feature only in the pro version. Mashups relate to Problem #1 that I presented. There does seem to be a direct conflict between MapPress and Types and Views here. When I do the mashup before the view, the inner view produces No posts found. When I do the mashup after the view, the view produces the desired result, and so does the mashup. All well and good unless you want the mashup at the top of the page. This makes me think there is a conflict with the query. Any other ideas? I tried to save the query, do the mashup, then restore the query but that didn't help. Maybe you can suggest a change to the shortcodes that I defined:

function qs_save_query() {

global $wp_query, $qs_temp_query;;

$qs_temp_query = clone $wp_query;
// return $qs_temp_query;
}
add_shortcode( 'save_query', 'qs_save_query' );

function qs_restore_query() {

global $wp_query, $qs_temp_query;;

$wp_query = "";
$wp_query = clone $qs_temp_query;
// return $qs_temp_query;
}
add_shortcode( 'restore_query', 'qs_restore_query' );

I am running the MapPress pro version 2.38.6. This version was provided by Chris for testing some new features regarding map icons and is not generally available. However, perhaps you and Chris could exchange your full version plugins in the interest of improving compatibility and support for your common customers. You can contact Chris at hidden link.

The URL from which you can get development versions of the free MapPress is http://wordpress.org/extend/plugins/mappress-google-maps-for-wordpress/developers/.

Thanks for your help.

Brad

#17125

This issue was resolved by Chris at MapPress.