Using URL Replace to fix pictures?

Indeed. This is a most significant use of the module. Typically:

• choose a prefix you'll always apply to the HREF and SRC attributes you'll want to rewrite, like "/images"
• configure url_replace_filter to replace /images/ with http://www.example.com/public_html/pictures/
• insert images as <img src="/images/foo.png" alt="some explanation" />
• they'll be rewritten to access the absolute URL you defined, like public_html/pictures

If this answers your question, please set to the issue status to "fixed"

Forgot to set status

Yes, this is a bug fixed by the patch in #330640: Module configuration screen is not themed. It is only cosmetic anyway. Without the patch, the left column is on rows 1, 3, 5 and the right column is on rows 2, 4, 6. You can apply the patch, or just not worry, and set the left element on row one, and the right on row two, and it works just fine.

Or you can apply the patch, or just paste this at the end of the module, and clear cache:

function url_replace_filter_theme() {
  return array(
    'url_replace_filter_settings_form' => array(
      'arguments' => array('form' => NULL),
    ),
  );
}

Actually no: the default textarea fields in profile.module do not have an input format, so no filter can apply to them : they are always submitted to check_plain() during the render process (see includes/form.inc#theme_textarea).

If you want to use advanced content for profiles, you might want to check http://drupal.org/project/profileplus and/or http://drupal.org/project/content_profile

No answer from requester in two weeks. Assuming issue fixed.

On 6.19 (don't know if on previous also) after fresh install this module from dev (where path is applied) this problem is not fix. Maybe cause template but I don't think so - I use Pixture reloaded

warning: Parameter 1 to theme_url_replace_filter_settings_form() expected to be a reference, value given in /public_html/includes/theme.inc on line 656.

PHP 5.3 compatibility issue

I suspect you are using PHP 5.3, aren't you ?

Yep. I alredy know that this is PHP 5.3 compatibility issue just for let other know also.

Module maintainer is now Mathiaz.sk; unassigning myself.

This now works even on 5.4.