File Extension v3.1.1 - path output sometimes full, other times just file name ???

You’re not switching between using it as a single tag, and using it as a tag pair, right? Could the system be seeing the closing of one as the closing of the other? Anything like that could cause weird output glitches. Does it happen when you only call one per page?

Hey…thanks for responding.

No, I’m just using the Single Variable option. In fact, once I noticed this I set up a test template to pull in just the data to each entry (without all the extra goodies) to try and determine the cause of this situation.

This is all that’s in the test template and I’m still seeing this problem:

{exp:weblog:entries weblog="in_fashion" sort="desc" limit="25" disable="member_data|pagination|trackbacks"}<div class="new_entry">
  <h3>{categories}{category_name}{/categories}</h3>
  <h2>{title}</h2>
  {if article_thumb}image path in question:   <strong>{article_thumb}</strong>{if:else}no thumbnail uploaded{/if}
  Article image: {article_image}
======================================


{/exp:weblog:entries}

Some entries return {article_thumb} with the full path, some with just the file name and extension; and this all happens within the same page.

I’m not doing anything special in my upload preferences. I’ve checked the file naming convention I’m using to see if that has any affect but I don’t see changes to it having any affect on this situation.

The strange thing is if I take an entry where {article_thumb} is not writing the full path and upload a new image, sometimes (thought not predictably) I get the full image path…which is why I was looking at the images themselves.

Any insight would be much appreciated.

Thanks.

What about getting rid of the short-style conditional and using the actual comparative values for it: {if article_thumb != ''}?

If the comparative value doesn’t help, what about doing this:

{exp:weblog:entries....}
{article_thumb}
{article_image}
{/exp:weblog:entries}

Do you still have it outputting different types of values in that case?

Still the same results.

I went back to investigating the img(s) as the culprit. The current images whose url’s are not displaying in full are jpg’s. I’ve swapped with gif’s and png’s to test the offending entries and when changed the full path t those files is returned.

Digging a bit deeper I began to look at how the offending jpg’s were saved (Progressive, ICC Profile, Compression settings, etc.) to see if the jpg’s required certain settings. However, each test image rendered a full path as well. So, I decided to go back and test the original offending images and they still just return the filename and extension.

I’m not too sure I’m going to be able to figure this out. But at least I know that I can resolve this situation by simply saving new images.

Odd to say the least.

So…I’ve figured out the cause of this issue…and it is the naming convention I was following. As I said I’m not doing any resizing/cropping, or generating of thumbnails via this extension. However, I liked the file-naming convention presented in the docs for thumbnails; e.g.

your_file_name_thumb.extension

The culprit seems to be the ”_thumb”. I’m now guessing it’s reserved given what I’m seeing.

So, if you’re using this extension and have the need to manually upload a thumbnail image, you will run into trouble if you use the same naming structure for your uploaded file that the extension follows when it dynamically creates a thumbnail image for you.

Glad you got it working! Yes, the _thumb files in the documentation are the automatically generated thumbs that the system appends that filename to.

That’s good advice for future users of the extension.