You beat me to it Yannick. It's indeed not the system paths which are
an issue, we've been handling those with realpath() for as long as I can
remember. Discussed the issue with Sven yesterday too and the
$_SERVER-variable also came up. At the veyr least we're going to look
into the matter.
Hans
On 26/09/2010 15:16, Yannick Warnier wrote:
Well, it is not *that* simple. We use realpath(__FILE__) as well for a
series of cases.
In particular, FCKEditor and those kind of JavaScript libraries
generally need a little bit of tuning to cut the full files URLs to the
relative ones when adding resources based on a web URL.
realpath(__FILE__) only works for system paths (i.e. /var/www/chamilo/)
but not for web paths (i.e. http://my.chamilo.net/).
You can use other mechanisms (using $_SERVER[] elements), but there has
to be a mechanism to avoid the problem, in any case.
Be aware that the $_SERVER[] array is generally filled by the web
server, and IIS doesn't fill all the elements Apache does (and we also
want to be able to run with other web servers).
Yannick
Le samedi 25 septembre 2010 à 11:50 +0200, Tim Brouckaert - Como a
écrit :
Hi all,
in Zend Framework this is nicely fixed using a realpath(__FILE__) in the index,
and working from there on.
Tim Brouckaert - Como
t...@comoweb.be
Op 25-sep-2010, om 11:29 heeft Hans De Bisschop het volgende geschreven:
Yannick,
Thanks for the note ... it's something we really, REALLY need to fix for 2.0.
The limitation has been causing me a lot of grief (to say the least) when
trying to (in an uncomplicated way) make the platform available via both HTTP
and HTTPS. (Which is kind of a problem if all URLs are rendered as HTTP by
default)
So again: thanks for bringing this to our attention again.
Best regards,
Hans
On 25/09/2010 4:59, Yannick Warnier wrote:
Hi all,
Just now I was having another problem related to this long-term
structural mistake somebody did at the beginning of Claroline (probably
because he was too lazy to do it correctly).
Anyway, in Chamilo 1.*, we have a root_url parameter set in the
configuration file, that basically forces the portal to answer on one
specific URL only.
This was probably added as a way to avoid the necessary work of making
all URLs in the application relative to the root directory. However,
this has a series of bad consequences (most of which we have fought to
fix over time).
The most important and negative consequence is that you can't use it
with
http://192.168.1.45 *and* http://my.chamilo.net
at the same time,
although these two names go to the same computer.
This prevents the possibility to quickly deploy an existing demo portal
in a classroom, for example, because you would have to have the same IP
or you would have to define the name on each computer of the classroom.
So this note is just to say: please avoid it in 2.0! (make it the drupal
way).
Rgds,
Yannick
_______________________________________________
Dev mailing list
Dev@lists.chamilo.org
http://lists.chamilo.org/listinfo/dev
_______________________________________________
Dev mailing list
Dev@lists.chamilo.org
http://lists.chamilo.org/listinfo/dev
_______________________________________________
Dev mailing list
Dev@lists.chamilo.org
http://lists.chamilo.org/listinfo/dev
_______________________________________________
Dev mailing list
Dev@lists.chamilo.org
http://lists.chamilo.org/listinfo/dev
