eZ Community » Forums » Suggestions » Absolute relativity
expandshrink

Absolute relativity

Absolute relativity

Wednesday 30 June 2010 5:16:52 pm - 9 replies

This is something that had really surprised me when I started using eZ Publish: A CMS as complex and advanced as this uses absolute paths and URLs? I could not believe it initially.

The paths/URLs I am talking about are things like the SiteURL setting, or AdditionalLoginFormActionURL, but also paths to for example images in an extension. eZ Publish is the first CMS I encounter that I can not move around freely.

Usually, a CMS would internally use relative paths, like "../img/header.jpg" instead of for example "/img/header.jpg", which expects the folder "img" in the web root. With paths relative to the CMS root folder or maybe also an extension's root folder, it would not matter whether I install eZ in the web root, in the folder "/CMS" or in "/sites/ezp".

With current shared hosting solutions it is very common to map a folder to a subdomain in DNS and install a site inside that folder. the CMS inside that folder should usually not need to know what domain it is serving, as long as everything it does is based on its own root directory.

I could map the installation folder to "my.example.com", but it would not matter, because the CMS would only add "/eng/Hello" for the welcome page to whatever URL I use to access it, be it "my.example.com" or "example.com/sites/ezp". I could map it to "your.example.com" and the URL would become "your.example.com/eng/Hello" - or still "example.com/sites/ezp/eng/Hello", depending on how I access it.

I admit that this could perhaps cause trouble for multisite setups - I don't know, I never did that, I only think it might. But even if things like SiteURL can (for whatever reason) not be changed, would it perhaps be possible to establish guidelines for extension authors to use relative paths instead of absolute ones?

Wednesday 30 June 2010 5:32:51 pm

Hi Olaf,

SiteURL is not that important. It is usually only domain name. AFAIK it is used mainly for building links when going outside the context (like email notifications, RSS, etc). It is probably used elsewhere also but it is practically one & only absolute URL you should set on simple installation. And it does not make sense as an relative URL either.

AdditionalLoginFormActionURL does not need to be absolute.

To use images from extension in templates use ezimage operator. You don't need to use absolute paths surely. To use images from CSS you can use ../images/foo.png path.

So I don't get why would do you think that eZ uses absolute links?

Wednesday 30 June 2010 8:41:05 pm

First the extensions: It is not me who wants to use images from an extension, the extension itself uses its images with absolute paths. That's why I assume that there are no guidelines in that direction...?

SiteURL... I wish it was that simple. I read the same statement in the forums, but I found SiteURL causing huge trouble when it is set in any language site.ini, because the system will use it for site access. (And the installer seems to set it...) Plus, there is also one that is set in the frontend. (Required? Can't remember...) Maybe I need to explore this a bit further, but relying on documentation and the example configuration (as often suggested) created by the installer, this is the impression I get.

The installer does create absolute paths/URLs (worst if host access is selected) and the docs say nothing in the way that these can be relative - at least I did not find such hint. So, apologies if I should be wrong, but the impression I get from the information available to me is that there are absolute settings...

Thursday 01 July 2010 11:26:43 am

If the extension use absolute path then it is sure bad practice. You should inform authors of this to change it.

About SiteURL, it is a special field. So special attention is needed, but I didn't have any problems with it till now. Maybe I was not in your situation either.

Regarding installer, it set some default values of course, but you can change everything later on. If you know what are you doing of course happy.gif Emoticon

Thursday 01 July 2010 5:51:29 pm

Hello Ivo,

Yes, I mentioned it to the extension author. Not sure if it will change though...

The forums contain many suggestions to study the demo content installations, and I did that in addition to the available docs. Unfortunately, some areas seem not covered well. SiteURL is one. Even in a URI access install, which itself worked nicely (Luckily, because had it not, I might have moved on to the next CMS.), SiteURL and login form action were set (absolutely...), but I really started to doubt about these settings when I tried a host access install.

Then the installer created a "SiteURL=eng.1" in the English site access site.ini - and switching to English resulted in "http://eng.1/eng/something" and an error message. So, this setting is a bit more troublesome than the docs pretend. And as someone who is new to this system, it can be pretty frustrating when one of the suggested sources of information (demo installs) gives wrong directions.

If it is indeed as you say, then I guess I will try to make some more experiments and then see who is responsible for documentation, maybe they accept a helping hand...

Thursday 01 July 2010 6:00:30 pm

Could also be that you encountered some installer bug. This "eng.1" surely looks like that happy.gif Emoticon

Saturday 03 July 2010 5:30:52 pm

Sorry, again me. Ivo, you said relative paths can be used for AdditionalLoginFormActionURL. I can not find any information regarding relative paths here, everything I find is absolute. (Info about this is pretty scarce generally.) I made a few tests, but I can not come up with anything that works, so: If you know how to form a relative path for this parameter, could you please post it here?

Otherwise this really seems to be pretty absolute - including FQDN...

Wednesday 07 July 2010 10:03:39 am

Hm,

Default value should be like this:

AdditionalLoginFormActionURL=http://your.domain/administration/user/login

But I tried it without domain on demo site and it worked:

AdditionalLoginFormActionURL=/administration/user/login

Modified on Wednesday 07 July 2010 10:04:17 am by Ivo Luka─Ź

Wednesday 07 July 2010 6:55:48 pm

Ah, very nice, thanks! I had tried a few combinations, but not that one... You know, the two posts you made regarding relative paths with login form action seem to be the only source of information for this. I hope people will find this thread if they encounter this problem...

Monday 12 July 2010 6:06:08 pm

That's why we have community forums blunk.gif Emoticon

expandshrink

You must be logged in to post messages in this topic!

36 542 Users on board!

Forums menu

Proudly Developed with from