On several projects I’ve worked on I seem to run into a situation that happens intermittently where, in my resulting mark-up, a newline is created in my image references (not intentionally) .
I’ve attached and example image of the resulting mark-up. This may in fact be something that can’t be addressed thru Technical support because I’m using Mark Huot’s File extension and in some cased this is used in conjunction with Dan Waltons Extract URL Plus plugin.
However, the example I’m showing does not use the extract_url_plus plugin. With this particular case the image is actually called via a query, listed below:
{exp:query
sql="SELECT
t.url_title as entry
, d.field_id_13 as img
, d.field_id_27 as stl
, t.entry_id as queryID
FROM exp_weblog_titles as t
LEFT JOIN exp_weblog_data as d
ON t.entry_id = d.entry_id
LEFT JOIN exp_relationships as r
ON d.entry_id = r.rel_parent_id
WHERE r.rel_child_id = '{embed:client}'"
}{if total_results > 1}{if count == "1"}
Other projects we've completed for {embed:client_name}
{/if}{/if}
{if queryID != '{embed:selected_entry}'}
{if img ==""}
<a href="/our_work/project_entry/{entry}">_ /scripts/phpThumb/phpThumb.php?src=/images/uploads/projects/{stl}&w=75&h=75&zc=1&fltr[]=usm|20|0.5|3&q=95_</a>
{if:else}
<a href="/our_work/project_entry/{entry}">_ /scripts/phpThumb/phpThumb.php?src=/images/uploads/projects/{img}&w=75&h=75&zc=1&fltr[]=usm|20|0.5|3&q=95_</a>{/if}
{/if}
{/exp:query}
Here’s a link to a live example. The images where this is occurring are called with the {stl} alias.
I’ve thrown together a test page that calls all my data, no formatting, via weblog tags here and this seems to show everything as being ok.
I’ve also put together a template that has the above query hard coded less any formatting and the anomaly shows up - here. (the phpThumb missing image indicators are not errors, images simply do not exist for the entries the indicator displays in)
I’m not sure what I’m doing to cause this. In some cases I’ve re-uploaded the source image and the anomaly goes away (for a period of time).
I’m at a loss…wondering is someone smarter than me could shed some light on this issue…maybe even provide a solution?
Thanks
Michael:
is d.field_id_27 the field for Mark’s File Extension? Looks like it needs to be tweaked to be trim() before it’s inserted into the db.
-greg
Hey Greg, thanks for responding.
is d.field_id_27 the field for Mark’s File Extension?
Yes, as well as d.field_id_13.
I began noticing this several installs ago. The trouble has been that that it doesn’t occur all the time. So I’ve had a very difficult time trying to pinpoint if it’s happening because of something I’m doing or if it’s due to an interaction between Mark’s extension and other things.
In looking through v3.1.1 I can see Mark’s executing the trim function
//#568
// =============================================
// Get Files
// =============================================
$files = array_filter(preg_split("/[\r\n]+/", trim($field_data)));
//#1139
// =============================================
// Are there files?
// =============================================
if(trim($row['field_id_'.$file_field['field_id']]) == '')
{
$tagdata = $this->clean_tagdata($tagdata, $file_field['field_name']);
continue;
}
This doesn’t occur all the time. And when I put together a stripped down template and call my weblog data I see no evidence of what I’m observing.
Wondering if I should maybe post on the How-to board to see how others are putting these items all together…(?).
This issue is not about the query either. No need to move to extensions…I’ll go add a post to one of the newer “File” threads to see what others might think about this situation.
Because it’s so intermittent I really don’t know where to think the cause of this lies. It may just be me and what I’m doing. The trouble is 98% of the time I see no problem. The only reason I wonder about Marks extension as the culprit is that when I re-upload the affected image, it tends to correct the issue.
Packet Tide owns and develops ExpressionEngine. © Packet Tide, All Rights Reserved.