Paths with WYSIWYG generated content

[eluser]ralf57[/eluser]
[quote author="jedd" date="1253117138"]
Is it the full protocol/host/port/path combo, or just the filesystem path?
[/quote]

I will be storing just the filesystem path, with markup like this:

Code:

<a href="/dev/ci/files/docs/file.ext">My link text</a>
or
<img src="/dev/ci/files/images/file.ext" alt="alt text" />

[quote author="jedd" date="1253117138"]
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).[/quote]

I agree to the token/placeholder implementation.
For example, the code to store could be like this:

Code:

<img src="token:images/file.ext" alt="alt text" />

then, a filter would replace "token:" with /dev/ci/files/

Is this the way to go?

[eluser]Phil Sturgeon[/eluser]
Why the hell would you do that?

If this is in WYSIWYG then the WYSIWYG can handle it. If it is for values outside of WYSIWYG then HTML can handle it anyway.

Just because one other person understands what you are trying to do, does not mean you are being clear. This seems like a lot of conversation and a lot of confusion for something that should not EVER be a problem in the first place.

There is no reason to store the domain and no reason to store the root path either. Your application should know the URL and it should also know the root path to which it is installed. Everything else in your application should be relative from this base point. That can be done with PHP adding the URL & root dir the same as adding <?=base_url().'/somefile.img';?> or it can be done with pure HTML like the link above.

[eluser]jedd[/eluser]
[quote author="ralf57" date="1253119881"]
Is this the way to go?
[/quote]

I'm not in a position to say for sure, so hopefully someone else will pop up with their experiences on doing this.

But, certainly, storing some unique token so you can do this on the fly is going to be much better.

I'm actually approaching this same problem from a different angle - images (in fact, any type of file that can be used as an attachment) are stored in my file system, but I refer to them consistently via a UUID that I track in the db. So I'll probably end with a token arrangement that links to the UUID. I haven't worked out the best way of providing supplemental information - such as your example alt= tag, or things like whether it's a thumbnail, and if so what size to present it as. Information that is tied to the image itself (who uploaded it, and when, and so on) are easy - they can be pulled out as needed, during rendering, from the database. But it's possible that I want different alt tags at render time, depending on context, and I certainly want different rendering size options.

I think you should look at what definitely needs to be stored as part of the 'immutable' attributes for the embedded image (maybe alt, for example) and what can be adjusted by the user at edit-time .. if it's just one or the other type of meta data then it's a bit easier I reckon.

My gut feel is that going with the <img > tags within your markup isn't necessarily a good thing. Something a bit more abstracted - like the [ tags ] that this forum uses might be do-able? I guess your options depend on what comes out of your editor, how easy it is to change that, and/or how much work you want to put into the post-edit/pre-store-in-database process.

[eluser]ralf57[/eluser]
[quote author="Phil Sturgeon" date="1253120438"]Why the hell would you do that?

If this is in WYSIWYG then the WYSIWYG can handle it. If it is for values outside of WYSIWYG then HTML can handle it anyway.
[/quote]

I don't think that using the &lt;base&gt; element is really smart.
For example it prevents you from using paths generated with &lt;?=base_url().'/somefile.img';?&gt;
[/quote]

[eluser]n0xie[/eluser]
I've been skipping through the thread so you might have answered this already, but since there is a lot of confusion, I'm just going to be stupid and ask a silly question: Why exactly don't you want your paths to be relative to the site root?

[eluser]Phil Sturgeon[/eluser]
&lt;base&gt; just changes where relative paths will be relative from. If you give it a full URL then it will still work fine.

[eluser]ralf57[/eluser]
[quote author="Phil Sturgeon" date="1253126336"]&lt;base&gt; just changes where relative paths will be relative from. If you give it a full URL then it will still work fine.[/quote]

You're right,
the full URI's are correctly resolved as well

[eluser]Phil Sturgeon[/eluser]
Solved the problem?

As a general rule, you should always let the application decide where the application is, then let the content be relative within it.

[eluser]ralf57[/eluser]
[quote author="Phil Sturgeon" date="1253128705"]Solved the problem?
[/quote]

Yes, thanks for your patience ;-)