You should be able to get the post thumbnail to scale by specifying both dimensions- {@post_thumbnail_32x32}
Also try {@the_excerpt}
Thanks Josh but neither of those are working, all the widget is presenting is the title and link!
As a slight aside but relevant for testing if others are working, I’m curious about the identifiers, I realise perhaps some are originating in the plugin but I think I read in one of your tutorials that some of the magic tags originate in WordPress core – any link? (I’m not familiar with them)
The above related to Custom Post Type I have now tried it with Advanced Content Type specifying a thumbnail field and I uploaded a file for it through the pod mechanism.
In custom template on the widget I have
<a href="{@permalink}">{@name}</a>
{@thumbnail}
And the output is a string filespec for the jpg.
Additionally the permalink is not going to the correct url. I have the widget employed in a category page and it is trying to route me to http://adventurebod.com/activities/horseriding-holidays-in-the-high-atlas.
permalink is working on the Custom Post Type.
its not a production site! simply for test purposes.
Cheers
I have now tried this with all other widgets deactivated and across other themes including 2011, 2013, Celestial – Lite and my preferred theme was Suffusion.
Its the same everywhere!
Sounds like you’re pretty close.
With an Advanced Content Type @permalink will return the post slug, so you will need to add the rest of the link in the html. You should stick to using a Custom Post Type though.
As far as the thumbnail goes, you should be able to do <img src={@thumbnail_url.thumbnail} />
or substitute any registered image size or image dimensions.
Be sure to check out this page for more information on magic tags:
http://pods.io/docs/build/using-magic-tags/
so this is what I am getting:
<img src={@post_thumbnail_url.32x32} />
is returning the featured image seemingly limited by the size of the containing div and or section, that is, it is not scaling.
<img src={@thumbnail_url.32x32} />
returns src=http://adventurebod.com/ (incomplete of course) as does .thumbnail as per your last suggestion, and indeed just plain @thumbnail
I am going to be able to presumably work around the issue using CSS but just for the record I am using File/Image/Video Field Type, would that be correct?
What is the name of the file/image/video field you are wanting to display from?
thumbnail tried also calling it image and then after this prompt changed it to more likely unique podimg but the results were the same in all instances.
OK, that is probably a big part of why this isn’t working properly. You should avoid naming custom fields the same as built-in fields. I would recommend changing the name of the field to something unique.
Sorry about the overlap – this was due to the latter test after starting a re-edit. So no this is not the issue.
If it is called podimg try {@podimg._src_thumbnail} and if you need to, substitute ‘thumbnail’ for any registered custom image size.
Have tried it as is above and it is still not working. Will have to move away from this issue for now as time dictates.
The problem I have to move onto still relates to your plugin however Josh so hopefully you will be able to put me in the best direction regarding Filtering on Taxonomies and is covered in separate post!
In case anyone else has similar problems my workaround was to rely on CSS If it helps anyone then:
added this to CSS
div.pod-database-entry{
white-space:nowrap;
overflow:hidden;
text-overflow: ellipsis;
-o-text-overflow: ellipsis;
width: 100%;
}
div.pod-database-entry img{
width:32px;
height:32px;
margin-right:10px;
vertical-align: middle !important;
}
div.pod-database-entry a{
vertical-align: middle !important;
}
and this was in the custom template fro the widget:
<div class="pod-database-entry" ><a href="{@permalink}"><img src={@post_thumbnail_url} />{@name}
</a></div>
I just did some testing and can confirm that using the image dimension array in the magic tag does not work. I have opened an issue here:
https://github.com/pods-framework/pods/issues/2027
This has been fixed in Pods 2.4