Forum Replies Created
-
AuthorPosts
-
Thanks; will forward your reply and be in touch.
Jim P.
Nope, looks like it’s a random error, always the hardest to diagnose, but we definitely continue to experience it. It’s possible it’s a back-end cache issue on the WPEngine side, as the page noted above was excluded from their cache (by their admins…I have no control over this, vs. other caches I’ve worked with) and it consistently loads, though with all other pages (e.g., this one I just did to test, using exact same mashup code as the one above) it seems necessary that they are invoked via https:// (i.e., avoiding their cache) vs. desired http:// in order to load correctly.
Thanks again for your input.
Regards,
Jim P.
…and now it seems to work fine. A support person ran a file permission fix for another error; not sure if these are connected.
Will be back in touch if we reproduce the error.
Jim P.
Okay, got it. We’ll experiment with this over the next month. I can imagine some rather simple KML text edits, then, that will accomplish what we desire.
Many thanks,
Jim P.
Thanks. I looked at this in a bit more detail, and it appears that in the cases I was testing (which were exports from apps such as fulcrumapp.com and pdf-maps.com) the KML extendeddata element was used, which is somewhat more convoluted than a simple description element. Is this what may’ve messed with what you provide above?
Jim
Okay, thanks. Was just checking in, as realized this is on an older site; newer site is in MapPress latest.
Not sure if others would have this need, but we are working with relatively complex KMLs for which InfoWindow content is crucial, and it’d be tedious to manualy re-add. (In other cases users want to work with KMZs, including e.g. images, which also would not be immediately supported in MapPress without manually editing.)
Regards,
Jim P.
Thanks, Chris! Your reply prompted me to look at another place in the template code, and indeed my workaround from the previous problem (in that I now on this template specify post_type by listing each) became the problem this time around…now it’s fixed, and had nothing to do with hyphenated custom post types.
Cheers,
Jim
January 22, 2013 at 6:06 am in reply to: mashups with post__in no longer working after upgrade #11434Thanks; this works too!
Jim
January 22, 2013 at 5:08 am in reply to: mashups with post__in no longer working after upgrade #11430Chris, thank you! I’m using post_type=any as the routine harvests geotags from several post types, including custom posts…will wait for update, and sure appreciate it…
Jim
January 21, 2013 at 4:05 am in reply to: mashups with post__in no longer working after upgrade #11418Chris, thanks; link to sample page with this code is here. I’ve temporarily uncommented the $mapIDs echo so you’ll see that string at top. What you’ll see is a blank map. The full query code is below; it basically harvests geotagged posts (of several kinds) that were selected by the user. Again, it all worked great up to the upgrade.
As to your replacement code, can you actually do <?php echo ‘[shortcodegoeshere]’;?> and not include the do_shortcode?? Guess I have stuff to learn ;-).
Cheers,
Jim
Yes, you’re correct in your assumption; it’s in a template file, and the line is
<?php echo do_shortcode(‘[mashup width="100%" height="360" maptypeid="hybrid" marker_title="post" marker_body="excerpt" directions="none" overviewmapcontrol="false" show="query" show_query="cat='.$cat.'&post_status=publish&posts_per_page=-1"]‘); ?>
The problem is that we’re running this site with other institutions, and I need to warn them that there will be this (hopefully temporary) behavior. If you’re available just now to give it a try, I can install .9 and wait for the results, but optimally we’ll come back up with successful mashup maps soon…just be in touch, and thanks…Jim
Okay, got this one! Thanks, and on to your other reply.
Jim
Ah, just tried on our other WP instance using 2.38.7 beta and the POI marker drags just fine…was this problem introduced with 2.38.8?
Regards,
Jim P.
Ah, yes, you have it! I didn’t suspect this setting (which is not important to our site anyway), as the previous edits to zoom were preserved with this setting enabled.
I think it works now; will be in touch if questions.
Jim
Yes, okay, so we’re on the same wavelength. What I did was the following:
-I posted to our blog using the WP app.
-I checked the posting, and the default zoom had been applied.
-I then edited the posting’s MapPress map by rolling over Automatic, clicking Edit, zooming in or out on the map, and clicking Save.
-I then clicked Update on the post, then viewed it. The zoom is unchanged from the default.Am happy to give you a login so you can try it yourself; will send separately via email.
Many thanks for all your great support.
Jim P.
-
AuthorPosts
