robbiejackson

Hi @keraweb

I’ve compared the wp_posts, wp_terms, wp_postmeta and wp_podsrel records for the problematic Walk with those of a Walk where there’s no problem, and I can’t see anything unusual.

However, I don’t really know the internals of pods, so I’m just looking at patterns in these tables, and the resolution of the query above may use some completely different mechanism.

I’ll have to leave it there, but thanks for the support anyway.

@keraweb – Just to confirm, this is fixed in 2.8.4.1

Many thanks!

Robbie

Just an update on this …

I renamed the Area from ‘Pyrenees Central’ to ‘Pyrenees Central old’ and then created a new Area ‘Pyrenees Central’ from scratch with the same data as the old one.

Then I updated all the walks which were related to (now) ‘Pyrenees Central old’ to set the walk_area to the new ‘Pyrenees Central’.

This worked ok, and the query returned the right records for the new ‘Pyrenees Central’ except that when I changed a specific one of the walks it caused the query to return the incorrect results. This problem record was input some time ago – probably a few years ago.

So I updated all of the other records to reference the new ‘Pyrenees Central’ and just left the one problem record pointing to ‘Pyrenees Central old’. This caused the query to work ok, except now there was no row returned relating to ‘Pyrenees Central old’, even though the problem record was still there pointing to it.

I then created a new Walk record from scratch with the data of the problem record, and moved the problem record to the wordpress bin. And now things are working fine.

So I’m happy to close this PR as it’s all now working ok, but can you let me know if you want any details of the offending record in order to troubleshoot what the cause of the problem might be. I reckon it must be something wrong in the pods internal wiring eg in wp_podsrel.

• This reply was modified 3 years, 4 months ago by robbiejackson.

ok thanks @keraweb I’ll keep a look out for the next release and update this issue when I see it.

Hi @keraweb

Wow, that was a fast response! Yes, that seems to fix it ok ??

Many thanks!
Robbie

I’ve installed version 3.2.4 (I didn’t get round to installing the earlier ones) and can confirm that this problem is now fixed.

Thanks Michael!

Robbie

Ok, thanks for the confirmation Michael. I couldn’t understand why it was working on some pages but not on others, so your statement about the meta description explains that.

Thanks for the response Jim, I’ve created this issue as requested,
Regards,
Robbie

Yes, I’m just on to raise the same issue with my site. In the meantime I’ve just deactivated the plugin.

Any idea when a corrected plugin version will be available?

Thanks Jim, I went through the videos and was reassured that I was doing it correctly.

I’d happily write up a little tutorial on this topic and send it to you if you feel you’d like to have some written documentation as well on your site. I don’t do blogs, so I wouldn’t have anywhere I could host it myself.

If you’re interested, let me know where I could email it, plus in what format it would be best to write it (eg .doc file, html etc).

Cheers
Robbie

Thanks for the clarification Jim. In the end I went down the route of using php.

I was a bit unsure about how to go about the php route though – is there any Pods documentation which describes what to do? I know there’s descriptions of Pods templates and of Pods pages, but the latter seem to be just for advanced content types.

I didn’t want to modify my theme’s files, so what I did was:

• Create a child theme
• Copy the main theme’s single.php file into a new file single-walk.php in my child theme
• Edited this single-walk.php file to get what I wanted using code below to get the Pod record

 $walk = pods( 'walk', get_the_id() );
 if ( $walk->exists() ) {
      $myfieldvalue = $walk->field('myfieldname');   
      ...

This worked fine, but is it anything like a recommended approach?

Thanks,

Robbie

• This reply was modified 8 years, 3 months ago by robbiejackson.

Thanks Jim, that’s a great idea, and reassures me about this being future-proof. For those interested, I updated my wis_extract_caption function to extract the src attribute (which is basically the attachment guid), found the attachment id from that, and then the caption (probably needs a bit more error checking!):

function wis_extract_caption($imgtag) {
    $src_start = strpos($imgtag, 'src="');
    $src_finish = strpos($imgtag, '"', $src_start + 5);
    $guid = substr($imgtag, $src_start+5, $src_finish - $src_start - 5);
    global $wpdb;
    $attachment_id = $wpdb->get_col($wpdb->prepare( "SELECT ID FROM wp_posts WHERE guid = %s", $guid));
    $attachment_details = wp_prepare_attachment_for_js($attachment_id[0]);
    return $attachment_details['caption'];
}

Alternatively you can use wp_get_attachment_metadata( $attachment_id, $unfiltered ); to get the caption.

Robbie

• This reply was modified 8 years, 6 months ago by robbiejackson.

No, I’m afraid that’s just giving me the same thing – the post_title, post_content and post_excerpt fields of my walk record.

Still no luck I’m afraid.

My setup is that I have a custom post type pod called “walk”, and this has a field called “photo”. I actually allow multiple photos, so the <figure> is within an

[each photo] ... 
[/each]

block. I’m not sure if this has any bearing on it.

When I disply {@photo.post_title}, {@photo.post_content} and {@photo.post_excerpt}, I get the post_title, post_content and post_excerpt fields of the walk record, not information associated with the photo.

Thanks Scott, I’ve just tried that, but it just gives the title of that instance of the custom post type pod.

To be honest, it doesn’t sound right either, because the image caption isn’t held within a post_title field. Instead it’s held as part of an encoded array within the meta_value field of the wp_postmeta record which associated with the image attachment wp_posts record. If that makes sense!

Robbie