Relative path vs full path for images and PDF links

[Thomas Helzle]

Thanks Carlos.

I personally am totally fine with such workarounds, I only have problems giving such solutions to customers. I will soon create my first commercial site with GS, and me and the customer will both have a local installation as well as a hidden online site for testing in some subfolder, plus the live site.

A dynamic URL would work no matter what, but all search and replace solutions will always need some fiddling.
So I still hope this can be solved at the root one day.

ModX uses a "base URL" in the page header like this:
<base href="http://www.Sitename.com/MaybeSomeSubfolder/" />
And then all URLs are relative to that. Dead simple.
The only thing needed would be a modification to the filebrowser so it writes relative URLs or a plugin that strips the base URL from everything the browser delivers right at the moment it's written, so it's transparent to the user. And the Content Editor would have to be aware of that.
Since it's not relative to the page but relative to this base URL, no tracking of changes in hierarchy is needed.
The Base URL is what's entered in the Settings page of GS, so each installation can simply have an individual base.

I don't know what the hurdles are for such a solution or if there are any drawbacks.
I never had any issues in ModX.

Cheers,

Tom

[Carlos]

I personally am totally fine with such workarounds, I only have problems giving such solutions to customers.

This script was not meant for use by customers or end-users, of course.
It's for designers/developers with the typical setup: one development/test site (local or temporary server) and one final site.
(though it could also be used 2 times for 3 steps, e.g. local/dev -> test/draft version -> final site.)

This is something like a replacement for the other solution of doing the batch find/replace with an editor like Notepad++

[Thomas Helzle]

Hey Carlos, my reply was more targeted towards the general discussion of the problem as towards your script. I highly appreciate anything that helps me to make things easier.
I just feel that this should be solved in GS at the base level in the hopefully not too distant future to make GS the ultimate in site portability which it has the potential to be.

Cheers,

Tom

[shawn_a]

I already posted the solution in the other thread, it needs to be tested thoroughly, obviously carlos' solution is to fix what is already broken not to permanently fix it.

http://get-simple.info/forums/showthread...8#pid24238

[Carlos]

In my opinion there's nothing broken. GS currently works just like many other CMSes or blogging platforms: content is -by default- raw html, URLs in the content (links, img's) are absolute ones. If you migrate a site you have to find/replace old URLs in some way, just like with WordPress.

If you change GS to use dynamic URLs, tokens for URLs or whatever, then obviously the content will not be pure html, the editor will have to support them, etc.

[Thomas Helzle]

Well, it doesn't work for me (or I'm too stupid to understand it).
I did these modifications to fileprowser.php as suggested on the other thread:

$sitepath = suggest_site_path(true);
$fullPath = $sitepath . "/data/uploads/";

This gives me a truncated path that is not relative to the GS installation but still includes the subfolder where GS is installed on my local system (which will not work when the site is moved to the production site). It looks like:

/localSubfolder/data/uploads/

So instead I could set:

$fullPath = "/data/uploads/";

to get a site-relative path and add something like:

<base href="<?php get_site_url(); ?>" />

to the head of all my templates (this is how ModX solves the problem).

The only remaining problem is, that the Editor doesn't show the images if I use this kind of link and I don't fully understand why, otherwise I would maybe be able to solve it myself. If the Editor could be made to use site-relative paths too, all would be working I think.

I don't follow the "there is nothing broken" argument, since I think GS has the opportunity to offer something that most other CMS don't: perfect Site portability. Since it uses no database, it already is superior in this area, and only this one bit is missing to make it totally perfect: A drag and drop Website that works after one initial quick setup between multiple sites, something I'm sure not only I would love.

If I miss something, I'm really sorry and would love to learn what that is.
The solution above keeps the content free of tokens and works perfect in ModX.

Cheers and thanks for any further hints,

Tom

[shawn_a]

by broken i mean links that are broken after a move, and are already saved in full path
You obviously should not be moving sites to a different structure entirely, if you are using subfolders then handle them in your rewrites.

as i mentioned in that other thread base href is probably a good solution , but there are some other pieces that probably need to adjust to it, like ckeditor etc.

Also any solution has to work with permalink structures as well,or rather permalink changes.

I honestly have not sat down and thought through this, feel free to offer the solution.

[Thomas Helzle]

hehehe, slight confusion again ;-)
With "broken" I refereed to Carlos who wrote "In my opinion there's nothing broken."
Which is correct in principle, GS works great as it is.

I'm too new to GS to be fully able to think through all possible problems.

The one remaining problem ATM is the path that the ckeditor uses to show images in the content.
It seems to use server-root relative paths instead of GS-installation-relative paths (as I showed above).
Maybe there is a configuration option to make it behave like we want.
If I find the time, I can try again to find something in the docs, although my last search through it didn't come up with anything usable.
Would you know where ckeditor is getting it's base URL from?

Cheers,

Tom

[shawn_a]

edit.php
baseHref : '<?php echo $SITEURL; ?>',

you can override this using $EDOPTIONS global or the gsconfig constant GSEDITOROPTIONS or something

[Thomas Helzle]

Thanks a lot shawn! I'll give it try and let you know how it goes.

Cheers,

Tom

[Thomas Helzle]

Ok, so ATM I found the following solution, I have to test it more thoroughly tomorrow:

Line 30 in filebrowser.php:

$fullPath = "data/uploads/";

No leading slash! This way it works in the Editor - images are visible.

And in the header of my templates:

<base href="<?php get_site_url(); ?>" />

Which includes the full installation path, so it works in subfolders as well as on the rootlevel.

I didn't have to change anything else, the important difference here was the removal of the leading slash in the fullpath variable, which originally wasn't there, but in shawns example it was, which threw me off. ;-)

It would be great if you guys with more GS experience could come up with some problem-scenarios that could break this.

Since absolute links still work as well, I guess it's rather failsafe?

One problem I found already is, that all plugins seem to have their own version of the browser, therefore it would have to be changed in each plugin too (after that it works there as well, I tried i18n custom fields).
I read somewhere that there are plans to solve this at the root, so that plugins don't have to rebuild the browser?

In that case, the changes to GS would be trivial. There could be an option in gsconfig which would change the $fullpath to GS-Installation relative as above and include the base href in the headers.

Plugin authors could mirror that until it can be solved at the root.

Would be great if it were so simple in the end :-)

Cheers,

Tom

[Carlos]

There's a problem with making the filebrowser use relative paths if you use fancy url's (or a custom permalink having the %parent% placeholder) and

- you insert some image in a top level page
- you then select a parent to make it subpage of another one
(or viceversa)

Image links broken.

[Carlos]

If the site is going to be in the root of a domain, another possible solution (tip by Ed at ISI) would be:

- install test/dev sites in the root, not in a subfolder (use subdomains)
- change the WebSite URL setting to /

Note that since GS 3.1 you are not allowed to enter a non-URL path there, so you'll have to:
- edit your website.xml file to change it
or
- patch GS to make it allow to change it in the backend: edit admin/settings.php, find the string type="url" and change it to type="text"
(as I suggested here, but now it's line 217)

This way all your links, img tags, etc. will be relative to root and will work on all sites.

There's a small issue with this: canonical URLs will not be correct (complete). To fix it, you can either
- remove the canonical tag by changing get_header() to get_header(false) in your template
or
- in the final site, set the correct WebSite URL (e.g. http://www.example.com/) (if/when you've finished develoment)

----

This method could be also used for developing in a subfolder if all local/dev sites use the same folder name, e.g. testsite and you set /testsite/ as Website URL. When the site is ready to be public, you'd have to do the find/replace /testsite/ by http://www.example.com/ (if/when you've finished develoment)

[shawn_a]

Could always use subfolders with rewrite rules and/or a custom hosts file and use the actual domain on test machine.

What I was going for with my solution ( and it obviosusly doesn't work ) is to get rid of urls all togather, which is what the siteurl hack does, but do it internally for all the pieces.

Its probably better to come up with all the pieces.

Images, images are static and can always be referenced by absolute pathing relative to root /data/uploads etc.

Page links can be relative to page, probably a bad idea as pages can move if fancy urls and path is based on parent and permalink.

Page links can be absolute to site root / but is still dependant on their path, which can be modified by fancy urls and permalinks.

The alternative is to always use id syntax for page linking to slugs, but this might be bad for SEO.

[Thomas Helzle]

There's a problem with making the filebrowser use relative paths if you use fancy url's (or a custom permalink having the %parent% placeholder) and

- you insert some image in a top level page
- you then select a parent to make it subpage of another one
(or viceversa)

Image links broken.

Doesn't happen here.
I am using the default fancy URLs and everything seems to work just fine.
Since the links are site-relative, I don't think they will break, no matter from where in the hierarchy they are used?
The browser always delivers a data/upload... link, no matter where I am.

Not sure if my use of i18n changes anything in that regard?

Pages and all possible things that can be done with fancy URLs/rewrites are out of my scope - I simply don't know enough to voice an opinion there. But I guess it will always be possible to break things... ;-)

I'm still a bit scared by the more involved Fancy URL and rewrite stuff, but I guess Google will drive me there in the end - ATM only half of my pages are scanned say the webmaster tools...

I will use my solution for a while and see how it goes. If I find anything new, I'll post it here.

Cheers and thanks for all your feedback!

Tom

[shawn_a]

I think the point is there is NO way to do it besides the way it already is, if we continue allowing permalinks structures. of course we should keep at it and see if a basehref solution might work, that is the best options because it can be changed on the fly.

For most it will probably be fine, but to add something to core it needs to be elegant.

[Carlos]

Doesn't happen here.
I am using the default fancy URLs and everything seems to work just fine.
Since the links are site-relative, I don't think they will break, no matter from where in the hierarchy they are used?
The browser always delivers a data/upload... link, no matter where I am.

Ah yes, so with that patch links are site relative, and I suppose that you have a base href tag in your template header to make them work properly.

The base tag approach is interesting, but it seems there are some issues with it:
http://stackoverflow.com/questions/18890...98#1889898

[Thomas Helzle]

Doesn't happen here.
I am using the default fancy URLs and everything seems to work just fine.
Since the links are site-relative, I don't think they will break, no matter from where in the hierarchy they are used?
The browser always delivers a data/upload... link, no matter where I am.

Ah yes, so with that patch links are site relative, and I suppose that you have a base href tag in your template header to make them work properly.

The base tag approach is interesting, but it seems there are some issues with it:
http://stackoverflow.com/questions/18890...98#1889898

Yeah, in post 36 above I suggest this:
http://get-simple.info/forums/showthread...8#pid39008

Interesting discussion you link to.
As I said, ModX is using this as a solution for content links and I hadn't any problems there, even with anchors on the page. But I can't say if they have any additional provisions for such cases.
It may be an interesting CMS to study though.

The picture as I see it right now:
- Everything that is part of the template is no problem, since it mainly depends on the developer to create code that works with whatever structure is needed. Here, php placeholders can be used and therefore it's as dynamic as one wants it to be. Links can be relative or absolute since they can be constructed dynamically.

- The same is true for menus, since they can be created dynamically with code.

So in principle the "backend" is well covered as far as I can see.

- Then we have "static content" like images, audio or video. These can be used with absolute links with the GS default settings or maybe in the future with site relative links with a solution like mine above, which can either stay a hack or - if it proves stable and elegant enough - could become an option in gsconfig.

Like any other setting, it may need a page in the wiki to explain the possible pitfalls, but there is hardly anything in web-development that doesn't break in certain situations, so it depends mostly on how sever the problems really would be in real-live scenarios.

- And finally there are page links in the front-end-content.
I am not sure if anything changes in this regard between absolute and site relative links?
The problem that the hierarchy may change isn't really different between absolute and site-relative links. Isn't that more a question of how GS deals with tracking such changes?

Thanks for all the input! Good food for thought!

Cheers,

Tom

[shawn_a]

I use basehref in some sites of mine, and yes it does have some issues, I bet it is even more problematic with modern ajax frameworks also.