Geeklog Forums

Monday, October 18 2004 @ 06:40 PM EDT

After the conversion most of my posted images (for story articles) are messed up.

This is a repost under the correct Forum.
The images are listed as
<img width="400" height="262" src="http://<a href="http://www.mysite.com/images/articles/20041015124926673_2.jpg">

I guess the important part to notice is the anchor in the middle of the src of the image.

What to do?

As I flip through the code, it appears the <anchor> is being inserted as a result of the find http:// code.
Can this be fixed?

toggling url_rewrite does not fix the problem either.
A look at the actual database shows that the articles contains everything that is needed to display the pictures properly.

<img width=\"400\" height=\"269\" align=\"right\" src=\"http://www.mysite.com/images/articles/20041015124926673_1.jpg\" alt=\"\">While away...

the problem is the <anchor> being inserted in the middle of the src=" "

For anyone else having the same problem, here is my temporary fix.
Edit lib-common.php
Goto line 5649
it starts with
function COM_makeClickableLinks( $text )
{

after the { add the line

return $text;

and save lib-common.php

This will fix your images until the makeClickableLinks funciton is fixed to exclude images.

Or just make the whole thing be:

function COM_makeClickableLinks( $text )
{
$text = preg_replace( '/ ((www\.)[a-z0-9%&_\-\+,;=:@~#\/.\?\[\]]+(\/|[+0-9a-z]))/is', ' <a href="http:\/\/\\1">\\1</a>', $text );
return $text;
}

This makes things clickable links only if they are not preceded by http://

This is good because often if things are preceded by http:// they are already a link in the page!

This could go one step further and check if the http:// is preceded by a <a or a <img src= etc. etc. etc.

When the update comes out that adds this functionality I will add it. Until then ....

Thought I would provide some additional info to the developers on this too...

My PHP version:
[QUOTE author="PHP"]PHP 4.3.9 (cli) (built: Oct 3 2004 11:46:57)
Copyright (c) 1997-2004 The PHP Group
Zend Engine v1.3.0, Copyright (c) 1998-2004 Zend Technologies [/QUOTE]

Couple things to think about in developing a solution:

1) If you are determined to get the doesnt start with at " solution working include the ht(f)tps? in the variable [ ] so if it is https or ftp(s) it can be reused later, else you are just going to mess up those links. better not to capture those links if you can't properly link to them.

2) do the capture of the link when the story is posted this has several advantages:
Efficiency primarily, why not do a regular expression ONCE rather than ONCE every time a story is loaded? My site shows 10 stories at a time. Everytime someone visits my page a regular expression is run on 10 stories. High volume sites will see tens of thousands if not millions of additional regular expressions running per day!

Secondarily perhaps the poster does not want his text linked to, or creating a link distorts the message (code dump for instance), or something intended to be copied and pasted. Doing it at post time gives the poster an opportunity to opt out of having his story linked to (some code required)

I'm surprised nobody has replied to this post.
I don't know how I would be the only person experiencing these problems.
[Quote Author="PHP"]
PHP 5.0.2 (cli) (built: Oct 29 2004 11:34:42)
Copyright (c) 1997-2004 The PHP Group
Zend Engine v2.0.2, Copyright (c) 1998-2004 Zend Technologies [/Quote]
The problem continues to persist in PHP 5.

This all sounds quite strange to me.

What editor are you using to edit the files? Did you check if the pictures show this behavior in the database as well as in the displayed HTML? What version of geeklog are you running?

Why "Some" pictures only? What is the difference between those that work and those who dont? Any reproducible behavior?

If I understand you correctly, you assume that the [imge1]-link is stored in the story and then re-evalued to become normal HTML each time when the story is openend. AFAIK, this is not the case. The story is saved with the proper links once posted. Check you database with phpMYAdmin to see how it is in your case.

[Quote author="tokyoahead"]What editor are you using to edit the files? [/Quote]
I generally use Vim.
[Quote author="tokyoahead"]Did you check if the pictures show this behavior in the database as well as in the displayed HTML? What version of geeklog are you running?[/Quote]
Yes I did. The images are in the database as proper links.
I am running 1.3.10rc2
[Quote author="MySQL"]'<img width="400" height="269" align="right" src="http://www.mysite.com/images/articles/20041015124926673_1.jpg" alt="">[/Quote]
[Quote author="tokyoahead"]Why "Some" pictures only? What is the difference between those that work and those who dont? Any reproducible behavior?[/Quote]
I can't see why some of them work. Infact the workable ones may simply be cached or the browser screwing up in some way.
[Quote author="tokyoahead"]If I understand you correctly, you assume that the [imge1]-link is stored in the story and then re-evalued to become normal HTML each time when the story is openend. AFAIK, this is not the case. The story is saved with the proper links once posted. Check you database with phpMYAdmin to see how it is in your case.[/Quote]
The regular expression is being parsed each time it is displayed.
I am certain of this.
I do not thing that [image1] is stored in the database however. I believe [image1] is expanded to <img width height src="http://etc"> in the database, and the COM_makeClickableLinks evaluates over the story each time it is displayed.
The proper links to the images are mangled when the regular expression is run. It appears some effor has gone into create a regular expression that avoids links (ht|f)tps?) that start with at "(([^"]), this however does not seem to work. (With Linux (2.6.8, and 2.6.9) Php 4.3.9 or 5.0.2).

If the make clickable only affected stories being posted it would not break the existing story images, which it does.

Disabling COM_makeClickableLinks (by returning $text) fixes the broken images, or modifying COM_makeClickableLinks (by only catching ((ht|f)s?:// ) links with a <space> before them also fixes the problem.

Any comments would be appreciated.

Sincerely,

Astrogen.

See the end of this discussion.

bye, Dirk