• The forum software that supports hummy.tv has been upgraded to XenForo 2.1!

    This upgrade brings a number of improvements including the ability to bookmark posts to come back to later. Please bear with us as we continue to tweak things and open a new thread for any questions, issues or suggestions in Site/Forum Issues.

Another computer question...

Black Hole

May contain traces of nut
Win7/64

I use a program (KompoZer) which does mostly what I want but is annoying in that it fails to open files in certain very specific circumstances (loading CSS and images etc that are referenced from root instead of relative to the current location). BlueGriffon (another development of NVu) does exactly the same thing.

My idea is that if I could log file requests made by KompoZer, I could see why it isn't finding root-referenced resources and work out a way to plug the gap. How could I go about that? Is it possible to run a virtual environment to intercept the file system calls?

Another idea is to examine the source code - if it's well enough commented I might be able to spot the area of code that does it (but it sounds like a long job).
 

EEPhil

Number 28
As there is a lack of intelligent replies...
I'm not sure what you are doing that requires files to be located from root and why.
I have a very vague recollection of something similar using Dreamweaver - but that was over 15 years ago - and that was me doing something stupid!
An example of the problem could be helpful. eg. layout of files on the source disk, the intended layout of the website, and the failing references.
 
OP
Black Hole

Black Hole

May contain traces of nut
KompoZer/BlueGriffon (WYSIWYG web page editors, both based on NVu) load page resources fine as long as the path is relative to the current page, but not if they are relative to the root URL. For example (illustrative only):

On the web server:

<my_url>/index.html​
<my_url>/assets/image1.jpg​
<my_url>/pages/page1.html​

On my PC:

M:\index.html​
M:\assets\image1.jpg​
M:\pages\page1.html​

Supposing page1.html contains <img src="/assets/image1.jpg" alt="whatever">, it will display fine in a browser pointed at file://M:/pages/page1.html or http://<my_url>/pages/page1.html, but KompoZer won't load the image when editing page1.html.

If, however, page1.html contains <img src="../assets/image1.jpg" alt="whatever">, it will display fine in browser and KompoZer, but the code is not now relocatable because it requires image1.jpg to be located at a particular place relative to the current file.

My first thoughts were that if I could work out why KompoZer isn't finding the image file (it takes a while before it gives up), I might be able to adapt my disk structure to accommodate it. Therefore I was looking for a debugging aid.

I'm now thinking that if I were to move the KompoZer executable to M:\, that might solve the problem (can't try it right now). What KompoZer needs is a means to set the disk location of "/", either as a setting or as a command line parameter or system variable, then my page hierarchy could be located anywhere, not just as root in a virtual drive letter.
 

prpr

Well-Known Member
I'm now thinking that if I were to move the KompoZer executable to M:\, that might solve the problem (can't try it right now). What KompoZer needs is a means to set the disk location of "/", either as a setting or as a command line parameter or system variable, then my page hierarchy could be located anywhere, not just as root in a virtual drive letter.
How does it know that its root is M:\ at the moment then? You must have to tell it somewhere, surely?
I would suggest using M:\something for the root folder (in case it's trying to access M:\\assets\image1.jpg)
It's weird how it appears not to apply the same rules for .htm files as .jpg files though.

I can't see how moving the executable will help, given that it appears to be somewhere else which has no association with M:\
 
OP
Black Hole

Black Hole

May contain traces of nut
How does it know that its root is M:\ at the moment then?
Because the current file is on M: and M:\ is what you would get if you did "dir \"

I can't see how moving the executable will help
Because there's a chance it is looking at the root of the drive it's executing from. As soon as my PC has stopped thrashing from a rash decision I took to update* Windows lunchtime, when I was going out for a couple of hours, I'll give it a whirl.

* I usually avoid it because of the loss of productivity!
 

EEPhil

Number 28
Now that I have acquired an old version of KompoZer (for Win XP :eek: ), and given your sample layout, let me have a look and compare with [an old] Dreamweaver and see if I can replicate the problem. Then it might be possible to make some suggestions - unless prpr gets there first. It might take a while as I'm struggling to do one thing at a time, let alone half-a-dozen.
Edit: Probably should have written, I will look at it when I get a round tuit.
 
Last edited:

EEPhil

Number 28
I can't see how moving the executable will help, given that it appears to be somewhere else which has no association with M:\
If someone hasn't coded KompoZer properly it could make a difference. But it doesn't matter now:
Yeah, well, it was worth a try (but no dice).
I tried to package one of my Java applications with PortableApps portable Java runtime and it complained because something was in the wrong place relative to the program. My guess is that I've cocked up (and not by using Java either ;) ).
 

prpr

Well-Known Member
Another idea is to examine the source code - if it's well enough commented I might be able to spot the area of code that does it
And then what? You need to be able to build it. I don't know how easily it builds, but usually it's a nightmare.
You didn't say which version you were using either.
 

EEPhil

Number 28
Okay. I'm using an old version of KompoZer (and I find it a bit cack-handed to use).
To get this to work the source html file needs to contain the full path as in file://M:/assets/image1.jpg. I had trouble saving this file - but when I did, it saved with that link there. When published the link changed to .../assets/image1.jpg. When I re-opened the source file (which I found to be a pain, I kept re-opening the web page for editing) the link was the full path and the image showed up as expected .
Not sure if I've made that clear, or whether it answers your problem. And I forgot to check whether the source file worked properly in the browser (I can't check at the moment as the USB port is in use for my internet dongle and I put the source files on an empty USB drive :roflmao: )
 
OP
Black Hole

Black Hole

May contain traces of nut
Thanks for your effort, but I don't need input on what to use - I'm trying to find out why root-relative doesn't work (it should) and whether there's any work-around (without changing the .html) I can use to persuade it to work on the KompoZer WYSIWYG editor.

Like I said, root-relative works fine on the server, but to accommodate KompoZer (or BlueGriffon) I have had to adapt the pages to page-relative (which is annoying because if I reorganise the structure the links have to be altered - not so bad with Notepad++ doing substitutions across multiple files). The website is quite small at the moment, but if it gets bigger things like this will become unwieldy.

You didn't say which version you were using either.
If it matters: kompozer-0.7.10-win32. That's the latest, I believe (except for a beta). However, as BlueGriffon does the same thing, it's a fair bet every version has the bug since NVu.
 

EEPhil

Number 28
Thanks for your effort, but I don't need input on what to use - I'm trying to find out why root-relative doesn't work (it should)
Fair enough. I only chipped in because no one else was answering.
Therein lies the problem. I've had a look with DreamWeaver and root relative which it states should work, doesn't. I'll clarify that. <img src="/assets/image1.jpg"> works within DW but not for the local version of the site within Mozilla browsers (well, the versions I've got). It works in IE8. It exports to the website as a document relative ("../assets/image1.jpg"). If I correct it so that Mozilla browsers work on the local copy, DW can't display the image. This is very similar to your problem. In fact, I'm fairly certain this is the problem I had years ago...
I have had to adapt the pages to page-relative (which is annoying because if I reorganise the structure the links have to be altered
... and that was my solution, along with manually editing the html! When you're dealing with four sites each of 50+ pages, it's a right PITA.
I don't think you can persuade the various WYSIWYG's to do what you want (unless someone knows better). You may have to accept that root-relative doesn't work as advertised.
A final thought, I just wonder if KompoZer is having trouble with how Windows handles files. Have you tried using KompoZer for linux?
 
Top