Paths with WYSIWYG generated content

[eluser]ralf57[/eluser]
Sorry for not being clear at best.
I'll try to explain the problem again.
First of all let me say that the issue is relevant mainly in two cases:

1) you need to pre-load some content (html) in a development installation which doesn't match the production structure.

2) for some reason, in a production environement, you have to move your installation to another directory.

Provided the following paths (relative to the web server root) already stored in the DB:

/dev/ci/files/images/img.jpg
/dev/ci/files/images/nature/img2.gif
/dev/ci/files/pdf/report.pdf
and so on...

If you copy your content to the production DB and the filesystem structure doesn't match (for example your installation lies in the web site root) you get broken paths/links

/files/images/img.jpg
/files/images/nature/img2.gif
/files/pdf/report.pdf
and so on...

It's quite easy to understand that in the DB you have
/dev/ci/files/images/img.jpg
while the real path on the production environement is
/files/images/img.jpg

The same applies in the second case.

[eluser]Phil Sturgeon[/eluser]
You missed my point in the PyroCMS thread. For this you need to set document base to contain your base_url.

In tinyMCE for example, I will set my base as:

http://localhost/dev/ci/
or
http://www.mysite.com/[quote]

Then I can store relative URI's in the WYSIWYG content like so:

[quote]files/images/img.jpg

Through correct configuration TinyMCE can remove the host name and convert your URL's to be relative to this path so even if somebody puts a URL in as http://localhost/dev/ci/files/images/img.jpg it will automatically convert to files/images/img.jpg.

So, it IS all down to the TinyMCE configuration as I tried to tell you in the PyroCMS thread.

[eluser]ralf57[/eluser]
I know the title of this thread can lead to misunderstanding,
but the problem I've tried to discuss is NOT how the WYSIWYG editors handle the paths/urls but
how these paths, saved in the DB, in some circumstances can result into broken links when the content is displayed.
So far no definitive solution.Period.

[eluser]jedd[/eluser]
[quote author="ralf57" date="1253045015"]
I know the title of this thread can lead to misunderstanding,
[/quote]

I don't know if we can lay it all on just the title.

but the problem I've tried to discuss is NOT how the WYSIWYG editors handle the paths/urls

It seems to me that this is the causal factor of your problem.

So far, this is what I've worked out (correct me if I'm wrong on any of these)

You believe that a WYSIWYG editor necessarily requires absolute pathnames to embedded images be kept, verbatim, within the mark-up that your editor generates.

Carrying that belief forward, you believe that the generated HTML must be stored, again verbatim, in your database. To be clear, at this point the img links now refer to a protocol, a hostname, and a full path name.

You want to know how you can relocate the site (including the database) and you've put an arbitrary constraint on the problem : you are not allowed to fix the root cause, only the symptoms.

So far no definitive solution.Period

I think the definitive solution has already been hinted at, alluded to, and spelled out. Don't store full paths.

[eluser]ralf57[/eluser]
[quote author="jedd" date="1253045905"]
You believe that a WYSIWYG editor necessarily requires absolute pathnames to embedded images be kept, verbatim, within the mark-up that your editor generates.
[/quote]

It's exactly the opposite.
In the first post I've clearly stated that absolute paths/urls must be avoided

You want to know how you can relocate the site (including the database) and you've put an arbitrary constraint on the problem : you are not allowed to fix the root cause, only the symptoms.

I know that it's better to prevent the problems, but there are situations where paths/urls
mismatching may occur

I think the definitive solution has already been hinted at, alluded to, and spelled out. Don't store full paths.

This is ok, but will not fix the problem by itself.

P.S: Martin has been the one to catch the problem and propose a solution.If he has understood what i've written then the problem is not on my side

[eluser]jedd[/eluser]
Okay .. these are the things I'm confused about.

a) I don't know who Martin is, and what he proposed

b) you write:
[quote author="ralf57" date="1253062851"]
In the first post I've clearly stated that absolute paths/urls must be avoided
[/quote]

.. yet earlier you write:

/dev/ci/files/images/img.jpg is already in the database

So, I can't work out if you're saying that your database is broken as it stands, or if you have to work with that extant data but future data you put in won't have those absolute paths, or if you want to know how to stop those absolute paths being inserted in the first place, or if you think that isn't an example of an absolute path, or if you want a way of changing existing absolute paths to match a new/different environment.

[eluser]ralf57[/eluser]
[quote author="jedd" date="1253063447"]Okay .. these are the things I'm confused about.

a) I don't know who Martin is, and what he proposed

[/quote]

it's Thomas Hunter, i made a typo

/dev/ci/files/images/img.jpg is already in the database

this is not an absolute path, it's relative to the web server root

or if you want a way of changing existing absolute paths to match a new/different environment.

You've almost got it, in the end.
I'm looking for a proper way changing existing relative paths to match a new/different environment

[eluser]jedd[/eluser]
[quote author="ralf57" date="1253065329"]

/dev/ci/files/images/img.jpg is already in the database

this is not an absolute path, it's relative to the web server root
[/quote]

Ahh .. okay, this is where the confusion stems from. Well, one of the places.

I think you'll find that you're at odds with world+dog on this one, as most people would call anything that starts with a / (denoting the root of the file system) as being an absolute path.

Even the [url="http://en.wikipedia.org/wiki/Path_(computing)"]folk over at Wikipedia[/url] reckon so:
[quote author="wikipedia" date="1253065355"]
A full path or absolute path is a path that points to the same location on one file system regardless of the working directory or combined paths. It is usually written in reference to a root directory.
[/quote]

So .. now that I know what you actually mean .. can you clarify something else. I asked about this earlier, but I think the question just got lost somewhere.

How are you storing data in your DB - is this part of one big fat text / blob field that now contains img src="/..." information, or are you storing the paths in a separate column somewhere, specifically for images/files, and using some hashing reference back to the location in the text/blob field containing the 'wysiwyg' mark-up stuff?

I had assumed the former - but you've been only describing the path components all along, so it might be the latter.

If it's the former, then you just store relative paths (and use the img() function, as I suggested just after the earth cooled), and if it's the latter then you just do a search and replace whenever you relocate (but of course there are neater ways of doing that .. such as not storing absolute (in the common usage definition of that word) paths in the first place).

[eluser]ralf57[/eluser]
[quote author="jedd" date="1253066163"]
most people would call anything that starts with a / (denoting the root of the file system) as being an absolute path.
Even the [url="http://en.wikipedia.org/wiki/Path_(computing)"]folk over at Wikipedia[/url] reckon so:
[/quote]

You're right,
I've learnt something new ;-)

How are you storing data in your DB - is this part of one big fat text / blob field that now contains img src="/..." information, ...

Yes,this is the case I'm trying to address

just do a search and replace whenever you relocate

This is what I ended up with and the preferred solution that the Drupal CMS adopts

I'm glad that we've worked it out, in the end ;-)

[eluser]jedd[/eluser]

just do a search and replace whenever you relocate

This is what I ended up with and the preferred solution that the Drupal CMS adopts

I'm unconvinced that this is the best way of doing this.

Perhaps you could actually spell out what you mean by this:

How are you storing data in your DB - is this part of one big fat text / blob field that now contains img src="/..." information, ...

Yes,this is the case I'm trying to address

I already know this is the case you're trying to address.

What I really want to know is what you're storing, or what you want to store, in the database - and that's why I keep on asking.

Is it the full protocol/host/port/path combo, or just the filesystem path?

I don't see why any of that has to be in there in the first place, since a token could be used instead to mark an impending relative path - and this could be parsed on the way out of the db with a simple regex.

It means the database content is fully portable (which aids scalability and DR too, of course).