- This topic has 2 replies, 2 voices, and was last updated 13 years, 6 months ago by
.
-
Posts
-
Chris, we fixed my earlier problem just fine, but I’m now discovering a lingering problem on the same pages. These portfolio pages (example here) exhibit a mashup map of all regular/custom posts the student selects, and things generally work fine except for certain custom post types. The only similarity I can see is that their name includes a hyphen, which I learned a bit late in the game is not recommended (e.g., see here). Otherwise, I’ve checked the post ID string I pass to MapPress and all IDs are fine, and I’ve even checked the SQL MapPress tables and all referenced IDs are fine there as well. Do you suspect that a post type name such as “user-concentration” or “situated-themes” could cause trouble on the MapPress end, but a name such as “post” or “research” would not? That’s my best guess at this point, and it’s a bit gnarly at this point to rename the custom post types so I’m hoping you have a solution. (Still on 2.39.7 Pro, btw; will update soon.)
Many thanks,
Jim P.
Hi Jim,
It does seem the hyphens can cause problems, there are a few mentions in the WordPress TRAC (Bug) database too.
For something like this, I suggest you just print out the results of your query using a PHP echo statement first. That will at narrow down whether this has anything to do with MapPress or if it’s just a query issue.
Assume your the query you normally use is in $query, you could put this in your template:
<?php $wpq = new WP_Query($query); print_r($wpq); ?>
MapPress adds a few extra parameters. If you want to compare the above query to how MapPress runs it, try adding this too:
<?php $query = "map=true&post_type=any&cache_results=false" . $query; $wpq = new WP_Query($query); print_r($wpq); ?>
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
- You must be logged in to reply to this topic.