Thanks Dude,
The reason behind wanting a variable was because I initially wanted to use pages instead of portfolio items, but I couldn’t see how to easily create a grid with thumbnails just like what a gallery does.
If there’s a way to easily create a gallery-like grid with thumbnails that point to pages, that would negate my need for portfolio items and work around the slug limitation.

Thanks, but that is not the portfolio page or style I was meaning. In the AJAX portfolio sample here.
http://kriesi.at/themedemo/?theme=enfold

If you click on Single Portfolio: Big Slider, the image and thumbnails are below, they are within the AJAX Porfolio page. They are not on a page on their own like the “other” Single Portfolio Big Slider sample page in the Portfolios section. (I know, it’s confusing for me too).

That is the one I was hoping could resize, when it is on the AJAX portfolio page. So image on the left, with the thumbnails below. When you roll over the thumbs, the image that loads above would resize (or show the full image), not just the “featured image” size.

Thanks for your help.

excellent. That worked. I added css styling to it:

$description = get_post_field('post_content', get_post_thumbnail_id());
echo '<div class="featured-caption">' .$description.'</div>';

Is that correct?

Working perfectly, thanks!

:o)

haha, sorry, realised you’d changed the original code/post…

…no code Yigit???

;o)

Many thanks Yigit.

That sorts out the thumbnails perfectly, but unfortunately it also affects the larger image above too – which had been fine…

Hi – yes, the gallery test page is here:

http://enamellers.org/bsoe/?page_id=2817

Hi Yigit!
The code is working only when I’m using “Image Element” to keep images.
But when I’m doing the same thing with gallery, its still not working.. :(
please check the link below. in this link left top three images are kept by using “Gallery from Media Element” and the last three images are kept by using “Images from Media Element”.. So its working when I’m using “Images from Media Element” which as I explained earlier I don’t really want to use it..
please have a look at the link below and compare the difference..
http://goo.gl/DJmeeH

Thanks

Thanks for your reply Yigit!
May be we can compromise on point number 1.
But regarding point number 2, actually it is allowing my to zoom in but to a certain level.. like if I want to zoom in and actual size is like 4000×3354 its not gonna show me the actual size which is 4000×3354.
For example try the link below,
http://goo.gl/Wnoecr

under this link try to access the picture on the top named “WTC Bahrain_Day1_HR_Temo” (which show the name in tool tip)
its actual size is 4000×3354 but now its not even showing me a buttong for the zooming in :(…
could you please solve this issue?

Point 3 has solved.. thanks for that :)

Looking forward for your reply

Thanks – worked a treat!

Here are some screen captures visually depicting my comment above in post id#184636

1. A hand-coded from scratch thumbnail gallery showing a part of my Youtube video gallery. This file resides outside of the WordPress environment and is fetched by an Ajax call. There is no < head > or < body > in the fetched HTML. It’s straight HTML with the CSS snagged from the parent page which hosts the < a > and href call firing the lightbox overlay hosting all the thumbs. This is illustrated in the screen capture below. Even with this complex Ajax fetch which requires perfect coding to execute correctly, no errors can be found with the automatically generated play graphic overlaying the automatically generated Youtube thumbnails. They are centered correctly. Compare this to the thumbnail in Item 4. below which shows the play graphic shifted downward in an Enfold template. Something in the CSS is affecting it and I haven’t nailed it down yet.

2. An example of the lightbox window that opens when clicking the thumbnails.

3. Enfold themed page with video thumbnail and comment section.

4. And here is the bottom of the page and an example where the play graphic shifts downward due to some CSS properties in Enfold. See red arrow. If img-width: 100% was not commented out in base.css, the thumbnail would be 480px wide and part of the graphic would reside outside the darker opacitized text content area on the right side of the page. FYI, 480px is a default size for youtube thumbnails in their API and my CSS shrinking the thumbnail is ignored in IE due to img-width: 100%

5. Point five is not related to img-width, but I thought I would share a tidbit about the CSS in your Comments system while I’m thinking about it. You may want to consider giving the .comment-entry CSS a property of display: inline-table;
It will vastly improve the flexibility of your comment layout for users. Right now, the entire parent Div will not expand and contract dynamically. For example, if you use the Ajaxify plugin recommended in your forum by Dude, the parent Div hosting the comments entry will now expand and contract like it should if displayed as an inline-table. The colored background DIV will work great and scale up and down. With the current CSS in Enfold, it does not. So clicking on “reply” or add a comment creates a big dynamic hole in the background where the comment form appears. The colored background properties are transparent and do not expand and contract due to the current CSS properties on .comment-entry. I am sorry, but all of this is being developed on Localhost and I have no public link to show you. The concept of an inline-table setting should not be hard for a coder to visualize if they know CSS. Pass it along. They will get it and it will add up.

And finally, the reason for showing you all these screen captures, is maybe lost in all the text here. It can be boiled down to two things:

6A. I am looking for some direction working around img-width: 100% as it relates to Enfolds performance. Is it important?

6B. What global CSS property might be shifting my play graphic downward? Point me in the right direction among your CSS files. I will probably figure it out from there.

Cheers.