Fix broken images in Joomla after SEF

what is the best way to do it?

[seosutra]

I am using a Joomla site with Search Engine Friendly URLs..

In the error logs on my server, i see a lot of 404 error generated... some examples are listed below:

/templates/rt_equinox_j15/rokzoom/images/blank.png
/AboutUS/images/blank.png
/ContactUS/images/blank.png
/Services/ServicesOne/images/blank.png

Actual Location on the image is www.mysite.com/image/blank.png

below is the joomla SEF code:

########## Begin - Joomla! core SEF Section
#
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteCond %{REQUEST_URI} !^/index.php
RewriteCond %{REQUEST_URI} (/¦\.php¦\.html¦\.feed¦\.pdf¦\.raw¦/[^.]*)$ [NC]
RewriteRule (.*) index.php
RewriteRule .* - [E=HTTP_AUTHORIZATION:%{HTTP:Authorization},L]
#
########## End - Joomla! core SEF Section

Can anyone please advice what is causing the problem?

Thanks
Seosutra

[jdMorgan]

Please see my first post in response to the question in this thread [webmasterworld.com] for more information, then post specific questions back here.

Jim

[seosutra]

thanks for the reply...

i am trying to do the following now:

RewriteCond $1 \.png$ [OR]
RewriteRule ^/[A-Z]{2}/images/(.+)$ /images/$1 [PT,L]

Is this correct? how do i test it?

Please advice.

Thanks
Seosutra

[seosutra]

also, please note that I am also using the '-' in our services link...

so it appears as:

/Services/Services-One/images/blank.png

[jdMorgan]

The best way to fix the problem is to change the coding on your pages so that images and other included objects are linked using server-relative or canonical links. In other words, the source code for image links in the HTML should use <img src="/images/blank.png"> or <img src="http://example.com/images/blank.png"> and not a page-relative link such as <img src="../images/blank.png">. If you use page-relative URLs in these links, then the browser will resolve the URLs incorrectly when you rewrite URLs and include "virtual directories" in your published URLs as the SEF plug-in does.

There is a work-around, but it should be used only if you cannot correct the image links on your pages, since it creates duplicate-content problems which may affect your ranking in image search, and lower the 'quality score' for your site overall. I strongly suggest that you only use this work-around if Joomla's linking cannot be corrected:

RewriteRule ^([^/]+/)+images/([^./]+\.[^/]+)$ /images/$2 [L]

Jim

[seosutra]

I have tried to change the links, but the SEF function seems to overwrite the settings...

I am not sure if i would like to invite the duplicate content problem from google.

Do you have any other idea on how we can fix this?

I have checked on the Joomla forum but there too there is no answer to this problem.

[g1smd]

Making the links to images start with a / must fix it.

Make sure you clear your browser cache and test again.

[seosutra]

I have already done that... infact, i replaced all code pointing to images/blank.png with http://www.example.com/images/blank.png

but it seems the SEF function is creating some issues. not sure tho

[edited by: jdMorgan at 1:48 pm (utc) on Oct. 2, 2008]
[edit reason] example.com [/edit]

[seosutra]

jdMorgan,

Can you please tell me in the current situation what would be greater of the 2 evils!?

1, should i leave those 404 errors for blank.png file as is?

or

2, should i use the method you suggested? knowing it might result in duplicate content?

How would search engine rank me for each of these solutions?

Thanks

[jdMorgan]

In many cases, the ranking problem for duplicate-URL images isn't much of a concern. In this case, since the URL is "blank.png" it sounds like you're using it as a 'spacer,' foreground overlay image, or 'web-beacon,' so it's doubtful that you care about how that image might rank in image searches.

Having that image missing from your pages is certainly the 'greater evil' because it means your pages are functionally broken. Not to mention all those requests 'polluting' your Web server error statistics na making them less usable for finding real problems.

Be sure to report your problem to the "SEF" developers. They are usually "applications programmers" rather than SEOs, server experts, or Webmasters, and so often have little knowledge of all the hows and whys of URL rewriting, and therefore need feedback when problems like this occur.

Jim

[seosutra]

Hello Jim,

I am using the following code:

RewriteCond $1 \.png$ [OR]
RewriteRule ^/[A-Z]{2}/([0-9]+)$/images/(.+)$ http://www.example.com/images/$1 [PT,L]

however, it doesnt seem to work.. I still see the 404 error for /images/blank.png being generated.

Please advice

[edited by: jdMorgan at 1:48 pm (utc) on Oct. 2, 2008]
[edit reason] example.com [/edit]

[g1smd]

Is this a rewrite or a redirect you are attempting?

A redirect includes a hostname (and should also have [R=301,L] or similar).

A rewrite does not include a hostname, just the internal server path, and has just [L].

The leading "/" on the path mentioned "on the left" of your RewriteRule will be an issue. That will cause the matching to fail.

[jdMorgan]

Never put an [OR] flag on your last RewriteCond. This will break the code.

[added]
There is a spurious and invalid "$" in your regular-expressions pattern.

... and you could more-efficiently code that rule without the RewriteCond as:

RewriteRule ^/[A-Z]{2}/([0-9]+)/images/(.+\.png)$ http://www.example.com/images/$1 [PT,L] 

Also, I assume you're putting this code into httpd.conf, conf.d, or some other server-config-level file. If this code is intended for use in .htaccess, you must remove the leading slash from the RewriteRule pattern.

This pattern will match only URLs having the format <two uppercase letters>/<one or more digits>/images/<one or more of any characters>.png
So it will not match the "/Services/Services-One/images/blank.png" example URL that you posted above.
[/added]

Jim

[edited by: jdMorgan at 1:50 pm (utc) on Oct. 2, 2008]

[seosutra]

Hi,

I dont know much of this... but can you check if the following code will work correctly in the .htaccess file?

RewriteRule ^(.*)/images/blank.png$ http://www.example.com/images/blank.png [PT,L]

[g1smd]

In place of

(.*)/images

I would use something like

^(([^/]+/)+)images

for efficiency.

[jdMorgan]

Since no back-reference is being used, the pattern ^([^/]+/)+images/blank.png$ should work fine, and will be processed a bit faster than a pattern using using ".*"

Jim

[InnerFlash]

Hi,

I've just started in a host that charges me on the basis of CPU use. It's not the most usual among hosting plans but I can say the provider is quite popular.

In the admin panel at this hosting I get a report of all the files/scripts that load the CPU most. My problem is that 60% of my resources have been "eaten" by a common problem: a "/images/blank.png" in the end of every possible URL, even those created dynamically by Wordpress.

RewriteRule ^([^/]+/)+images/blank.png$ http://www.example.com/images/blank.png [PT,L]

(at the very end of the .htaccess file)

I have used this line of code below in my .htaccess for two weeks and not seen any difference. All the URLs continue to have a "/images/blank.png" at their end, which result in 404 errors.

I'm using a png fix, a popular one. The code is as follows:

<!--[if lte IE 6]>
<style type="text/css">
img { behavior: url(<?php bloginfo('template_url'); ?>/iepngfix.htc); }
</style>
<![endif]-->

The only thing I haven't tried is to disable this. Any idea if it will help? My site has a wide public, 15% are still using IE6. But I'm seriously thinking to cut all kind of support for IE6 and encourage them to change their browser or upgrade.

Anyway, if anyone has a similar problem, please let me know if you've solved it.

Cheers,
Wallace

[edited by: InnerFlash at 4:41 pm (utc) on Oct. 14, 2008]

[InnerFlash]

Problem solved, for that and all the redundant 404 errors on my site.

Everything that had a non-existing relative path, i.e. "images/blank.png", "css/style2.css" was added to the end of every dynamic URL in Wordpress.

Deleting the calls for these files or simply putting a slash "/" before them (with the correct path whenever the file was necessary) solved the problem.

Anyway, thanks ;)