And what happens if Joomla is installed in a subdirectory?

@addondev your fix is incorrect, as @brianteeman mentioned, your changes will break images for the sites located in subdirectory ... and there no need any changes at all, "System plugin SEF" will replace it to the right path ...
I think you did something wrong in your extension

Closing

"System plugin SEF" will replace it to the right path ...

No, it will not. And all the relative links are interpreted as relative ones.

I think the SEF plugin does not work if you do the following:

$image = $this->params->get("image_src");
JFactory::getDocument()->addScriptDeclaration("
    var image = new Image();
    image.src = '$image';
");

@addondev true, here SEF plugin do not work,
but as it the part of your extension, then I see no problem to attach the right image path,
eg: JUri::root(true) . '/' . $image

but your extension will still break if it is used with joomla in a
subdirectory

On 20 July 2015 at 12:47, Fedir Zinchuk notifications@github.com wrote:

@addondev https://github.com/addondev true, here SEF plugin do not
work,
but as it the part of your extension, then I see no problem to attach the
right image path,
eg: JUri::root(true) . '/' . $image [image: ]

—
Reply to this email directly or view it on GitHub
#7478 (comment).

Brian Teeman
Co-founder Joomla! and OpenSourceMatters Inc.
http://brian.teeman.net/

but as it the part of your extension, then I see no problem to attach the right image path,
eg: JUri::root(true) . '/' . $image

@Fedik, yes, this would be a solution if a user could not directly enter a link in a field. Imagine, a user enters a link http://mysite.com/image.jpg. The output will be the following:

$image = "http://mysite.com/image.jpg";
$path = JUri::root(true) . '/' . $image;
echo $path; 

Output: subdir/http://mysite.com/image.jpg

@brianteeman
I see this point. Therefore, I think we should find a different solution. I have reported a bug, you can think how to fix it.

Sorry for any inconvenience.
Yours faithfully,
Philip Sorokin.

Sorry but thats not how it works.

On 20 July 2015 at 15:07, Philip Sorokin notifications@github.com wrote:

but as it the part of your extension, then I see no problem to attach the
right image path,
eg: JUri::root(true) . '/' . $image [image: ]

@Fedik https://github.com/Fedik, yes, this would be a solution if a
user could not directly enter a link in a field. Imagine, a user enters a
link http://mysite.com/image.jpg. The output will be the following:

$image = http://mysite.com/image.jpg;
$path = JUri::root(true) . '/' . $image;
echo $path;

Output: subdir/http://mysite.com/image.jpg

[image: -1]
https://cloud.githubusercontent.com/assets/11632367/8777448/b450cc7c-2f00-11e5-8f3c-f58f4e5ab763.jpg

@brianteeman https://github.com/brianteeman
I see this point. Therefore, I think we should find a different solution.
I have reported a bug, you can think how to fix it.

Sorry for any inconvenience.
Yours faithfully,
Philip Sorokin.

—
Reply to this email directly or view it on GitHub
#7478 (comment).

Brian Teeman
Co-founder Joomla! and OpenSourceMatters Inc.
http://brian.teeman.net/

@brianteeman, could you, please, recommend me a solution? Can I ask you to explain what you mean saying that it works in a different way, because I can directly enter any URL in the field.

Imagine, a user enters a link http://mysite.com/image.jpg.

difficult to imagine the reason for this, if it not the external image

Note:
When work with images in Joomla, keep in mind that all paths is relative to the root, this will save you a lot of time

upd: in your case just add check for external resource before call JUri::root(true) . '/' . $image;

Note:
When work with images in Joomla, keep in mind that all paths is relative to the root, this will save you a lot of time

I keep in mind that, but I am not sure a user does. A user can enter any url with or without a protocol and hostname. Indeed, I had to add in my script a regular expression operation to parse the incoming URL, but I think it is not clear and looks like a hack.

Why are you parsing the URL at all

Why are you parsing the URL at all

Because I need to be sure that the incoming URL is not a relative one. JavaScript will add to the relative path a protocol, host and subdirectory:

echo "relative/path/image.jpg";

JavaScript will interpret the URL like this:

http://mysite.com/current/directory/current/subdirectory/relative/path/image.jpg

instead of

http://mysite.com/relative/path/image.jpg

Then thats a problem in your javascript and not the core.

Everytime you store a url in the database with an absolute path like that
you make it impossible for user to move the site to another domain or
location (just like wordpress does).

This really is not a core problem - sorry.

On 20 July 2015 at 17:09, Philip Sorokin notifications@github.com wrote:

Why are you parsing the URL at all

Because I need to be sure that the incoming URL is not a relative one.
JavaScript will add to the relative path a protocol, host and subdirectory:

echo "relative/path/image.jpg";

JavaScript will interpret the URL like this:

http://mysite.com/current/directory/current/subdirectory/relative/path/image.jpg

instead of

http://mysite.com/relative/path/image.jpg

—
Reply to this email directly or view it on GitHub
#7478 (comment).

Brian Teeman
Co-founder Joomla! and OpenSourceMatters Inc.
http://brian.teeman.net/

Then thats a problem in your javascript and not the core.

OK. I understand your point, but I think there is a proplem in JavaScript, not in my JavaScript. Because I cannot prevent it from adding a protocol and a host to a relative path.

I understand your point and apologize for disturbing you.

Dear participants,
I think, I have found another solution. Can I make a new pull request to discuss this issue?

of course

On 21 July 2015 at 12:22, Philip Sorokin notifications@github.com wrote:

Dear participants,
I think, I have found another solution. Can I make a new pull request to
discuss this issue?

—
Reply to this email directly or view it on GitHub
#7478 (comment).

Brian Teeman
Co-founder Joomla! and OpenSourceMatters Inc.
http://brian.teeman.net/