I've been testing HTML import and am stuck with a problem. I imported a manual for a piece of software and made a menu for it. After some suffering, everything finally was the way it supposed to be... I thought. It appeared that my images weren't visibible. The problem is that their src isn't correct.

I used a "Import Site Prefix" "fred/13/manual/". This was necessary to get all my pages to have a URL alias /fred/13/manual/* . So far so good. But it seems that the src's of my img's are also rewritten. My "Extra File Storage Path" is configured to be at "sites/default/files/imported/nl/fred/1.3/manual". A source of an image then should be "/sites/default/files/imported/nl/fred/1.3/manual/attachments/5177410/5373977.png" for example. BUT it is rewritten to "/fred/13/manual/sites/default/files/imported/nl/fred/1.3/manual/attachments/5177410/5373977.png".

I have no idea why this is happening and I can't really find a solution. (I suppose this could be a mistake in the "rewriting" of the images?)

Some help or a fix would be appreciated!

Comments

dman’s picture

dman commented

It sounds like your analysis of the issue is correct. I would not expect the 'prefix' to be getting glued on to the front of the file paths, given that the file storage path is set and *should* be the place to point at.
Now, there *is* a known issue with some cases if you point at an image using an href <a href="path/to/image">view image</a> because the rewriter thinks that's just another link and thus just another page, and thus not specifically expected to be in sites/default/files or anything. But that doesn't sound quite what you've got.

I'll admit that use of the url prefix option has not been well tested for a few years, through a couple of version upgrades, while the rewrite rules have certainly been modified a few times. It's likely something is out of whack there.

To investigate, you can try
- in the settings, under advanced, turn the debug level right up.
- import just one page that this trouble occurs in
- view the import_html results (a tab) and show 'more' info.
- see if the debug info provides a clue about where this bogus rewrite is being introduced. It's almost definitely going to be the 'rewrite_href_and_src' phase - but the debug dump should tell you what rules it has calculated when going into that process.

I'll see if I can replicate it some time

Trinorae’s picture

Trinorae commented

Is this were it goes wrong?

Rewrite patterns: Path to the top of this (relative) server is /fred/13/manual/ . Path to top of the prefixed section (fred/13/manual/) from here (View folder rights.html) to our import base (fred/13/manual/) would be '/fred/13/manual/'. Path to a relative neighbour of this page would be (/fred/13/manual/) or to find the base for relative resource files over in the file storage area (sites/default/files/imported/nl/fred/1.3/manual/) would be '/fred/13/manual/sites/default/files/imported/nl/fred/1.3/manual/'

I don't know wether it's normal, but in the very first window were you can see the code of the HTML-page (Inserting New Node View folder rights with content from /home/stef/fred/manual/html/XENFRED-1.3/View folder rights.html) you can already see the "wrong" source in the image.. That's way before the part with the rewrite...

dman’s picture

dman commented

That's precisely the message I meant, yes.
My debug logs may be ridiculously verbose, but sometimes they come in useful :-)

This narrows down the point of failure exactly, and tells me we should try:
import_html_process.inc:1433

  // Create the prefix for resource sources
  // Is url() OK for files with unclean urls? - NO. Neither is file_create_url
-   $src_root = $site_root . ensure_trailing_slash($profile['file_storage_path']);
+   $src_root = ensure_trailing_slash($profile['file_storage_path']);

Reading the code, it looks like that particular line had never been tested against the 'site prefix' option, as I suspected.

Trinorae’s picture

Trinorae commented

I've tested this and can confirm it works like a charm!

Thank you very much for your quick reply and solution, dman!

dman’s picture

dman commented
Version: 6.x-1.1 » 7.x-1.x-dev

Clearing the old 6.x issues from the issue queue for a cleanup.
Bumping to 7 as it's something that should be re-tested. Not sure it's fully solved, or that the solution was committed in 7