redactor returns wrong url when adding image
Permalink
Anyone else experiencing this?
redactor returns wrong url when adding image
Running 574
when I click on the insert image in filemanager it returns
http://domain.tv/index.php/download_file/view_inline/104,... which returns a 404
but when I view in file manager I get
http://domain.tv/application/files/4114/3848/5198/MissionImpossible...
which works
the ID of the image is indeed 104, but the url does not work
tested on another site running 575rc with same results
redactor returns wrong url when adding image
Running 574
when I click on the insert image in filemanager it returns
http://domain.tv/index.php/download_file/view_inline/104,... which returns a 404
but when I view in file manager I get
http://domain.tv/application/files/4114/3848/5198/MissionImpossible...
which works
the ID of the image is indeed 104, but the url does not work
tested on another site running 575rc with same results
I have not sorted it out. I am getting around this by doing a "view" from the file manager then right clicking and choosing "copy location" and then pasting that when I need to link to an image. Like you, if I use the integrated option of selecting from the FM the links works fine.
I assume this is a bug that will eventually get fixed... someday.
If you and I are have the exact same problem, I assume everyone else is, yet there are no messages about that, which is very odd
I assume this is a bug that will eventually get fixed... someday.
If you and I are have the exact same problem, I assume everyone else is, yet there are no messages about that, which is very odd
Yes, that's a cumbersome work around especially for clients to have to do.
My images are working ok, the only thing that isn't is when you load an image through FM it shows as a broken image in the Content Block window, but once saved the images show in the FM list and fine on the website.
Loading files is my main problem. Would be good to know if others are having this issue.
My images are working ok, the only thing that isn't is when you load an image through FM it shows as a broken image in the Content Block window, but once saved the images show in the FM list and fine on the website.
Loading files is my main problem. Would be good to know if others are having this issue.
@anete
@ntisithoj
Have you updated to the current 5.7.5.2 release?
If not, I recommend updating to see if the issue is resolved.
Have you checked the bug tracker to see if others are experiencing this issue? If no one has reported this issue, I recommend reporting it and including the steps required to repeat the error.
concrete5 bug tracker
https://www.concrete5.org/developers/bugs...
@ntisithoj
Have you updated to the current 5.7.5.2 release?
If not, I recommend updating to see if the issue is resolved.
Have you checked the bug tracker to see if others are experiencing this issue? If no one has reported this issue, I recommend reporting it and including the steps required to repeat the error.
concrete5 bug tracker
https://www.concrete5.org/developers/bugs...
I just upgraded for 5.7.5a1 to 5.7.5 and same problem.
It is easy to reproduce. Just attempt to insert an image from the file manager in a content block.
I have submitted a bug report here ->https://www.concrete5.org/index.php?cID=769708...
thanks
It is easy to reproduce. Just attempt to insert an image from the file manager in a content block.
I have submitted a bug report here ->https://www.concrete5.org/index.php?cID=769708...
thanks
@ntisithoj
"It is easy to reproduce. Just attempt to insert an image from the file manager in a content block."
I tried to reproduce this without success when you first posted. I continue to be unable to reproduce it on the current version of concrete5.
Image and file linking has worked as expected across multiple browsers, operating systems, and environments. This makes me think there is something install specific to the problem or it involves another issue.
"It is easy to reproduce. Just attempt to insert an image from the file manager in a content block."
I tried to reproduce this without success when you first posted. I continue to be unable to reproduce it on the current version of concrete5.
Image and file linking has worked as expected across multiple browsers, operating systems, and environments. This makes me think there is something install specific to the problem or it involves another issue.
One thing I did not mention before is I have Advanced Permissions=ON. This may be a factor according tohttps://www.concrete5.org/community/forums/chat/help-file-permission...
so, in your test case you are able to load a file with the URL that looks like
/download_file/view_inline/45
yes?
so, in your test case you are able to load a file with the URL that looks like
/download_file/view_inline/45
yes?
@ntisithoj
I am using advanced permissions.
Example:
- after adding image
- after saving Redactor (and replacement with <picture> element):
I am using advanced permissions.
Example:
- after adding image
<p data-redactor-inserted-image="true"><img id="image-marker" src="http://localhost/concrete5/index.php/download_file/view_inline/98"> </p>
- after saving Redactor (and replacement with <picture> element):
<p data-redactor-inserted-image="true"> <picture> <!--[if IE 9]><video style='display: none;'><![endif]--> <source srcset="http://localhost/concrete5/application/files/thumbnails/large/6114/3907/6528/cupcake.jpg" media="(min-width: 900px)"> <source srcset="http://localhost/concrete5/application/files/thumbnails/medium/6114/3907/6528/cupcake.jpg" media="(min-width: 768px)"> <source srcset="http://localhost/concrete5/application/files/thumbnails/small/6114/3907/6528/cupcake.jpg"> <!--[if IE 9]></video><![endif]--> <img src="http://localhost/concrete5/application/files/thumbnails/large/6114/3907/6528/cupcake.jpg" alt="#" id="image-marker" style="" width="1140"> </picture> </p>
OK, you've blown my mind, but not in a good way :/ Your post implied that in edit mode the image is represented by a broken link, but when I save it is converts the broken link to an actually correct link.
It seemed completely ridiculous that this would be the case, but when I tested, indeed, that is true! I can see the image only AFTER I save the redactor.
How is this not a bug (or rather a design flaw, as it was meant to be like that)? Obviously there is a perfectly good URL that points to the image, yet redactor uses some other URL that is broken then chooses to replace it on save.
What am I missing here?
So, even though I can see the image after I save, the fact that I can not see, edit, resize, etc the image in edit mode still makes redactor's image insertion broken.
So I guess the immediate question is why is my view_inline() not working? Is that even the place to look?
I assume this is the code in question, in concrete/controllers/single_page/download_file.php
It seemed completely ridiculous that this would be the case, but when I tested, indeed, that is true! I can see the image only AFTER I save the redactor.
How is this not a bug (or rather a design flaw, as it was meant to be like that)? Obviously there is a perfectly good URL that points to the image, yet redactor uses some other URL that is broken then chooses to replace it on save.
What am I missing here?
So, even though I can see the image after I save, the fact that I can not see, edit, resize, etc the image in edit mode still makes redactor's image insertion broken.
So I guess the immediate question is why is my view_inline() not working? Is that even the place to look?
I assume this is the code in question, in concrete/controllers/single_page/download_file.php
public function view_inline($fID = 0) { if ($fID > 0 && Loader::helper('validation/numbers')->integer($fID)) { $file = File::getByID($fID); $fp = new Permissions($file); if (!$fp->canViewFile()) { return false; } $fre = $file->getFileResource(); $fsl = $file->getFileStorageLocationObject()->getFileSystemObject(); $mimeType = $file->getMimeType(); header("Content-type: $mimeType"); print $file->getFileContents(); exit; } }
@ntisithoj
This is an issue specific to your install.
When adding an image, it should be viewable and editable before saving. The link replacement is part of the responsive image support.
"So I guess the immediate question is why is my view_inline() not working? Is that even the place to look?"
If I remember correctly, you are using a fair amount of custom code on your concrete5 install. This may be involved in not being able to view/edit images.
I recommend creating an additional install of concrete5 without any code modifications. I would then check to see if you still experience the issue.
This is an issue specific to your install.
When adding an image, it should be viewable and editable before saving. The link replacement is part of the responsive image support.
"So I guess the immediate question is why is my view_inline() not working? Is that even the place to look?"
If I remember correctly, you are using a fair amount of custom code on your concrete5 install. This may be involved in not being able to view/edit images.
I recommend creating an additional install of concrete5 without any code modifications. I would then check to see if you still experience the issue.
This could also simply be a web server permissions problem.
Saw something similar on a fresh 5.7.5.2 install. Had to chmod -R o+rwx application/files/
Saw something similar on a fresh 5.7.5.2 install. Had to chmod -R o+rwx application/files/
I am impressed with your memory! And yes you are correct that the site I have been spending most of my time with is massively customized. However, this site has zero customizations... just a standard theme (fundamental) and two addons, Problog and Vivid Simple Accordion, and the only customization I made was to change a template to support one OpenGraph tag in the header, and nothing else. So, it's pretty virgin. But your message made me wonder if I had the same problem with the complex site, and it does have exactly the same problem.
I attempted to test on a virgin install when I was remined of an old problem that I (or any one else) ever figured out which might be related.
what I do a "composer install" I always get
As I absolutely DO have gd and php-gd installed
(but still get the message
???
the only way I can install C5 is to delete that line in the composer.json. But I can't imaging that dapph/secureimage could have anything to do with redactor.
I attempted to test on a virgin install when I was remined of an old problem that I (or any one else) ever figured out which might be related.
what I do a "composer install" I always get
dapphp/securimage 3.5.4 requires ext-gd * -> the requested PHP extension gd is missing from your system.
As I absolutely DO have gd and php-gd installed
(but still get the message
imagine/imagine suggests installing ext-gd (to use the GD implementation)
???
extra/gd 2.1.1-2 [installed] extra/php-gd 5.6.13-1 [installed] and extension=gd.so
the only way I can install C5 is to delete that line in the composer.json. But I can't imaging that dapph/secureimage could have anything to do with redactor.
As I have a few sites under development, I got a bit mixed up with the problem that I referred to on this thread. It's not actually a 5.7 site that I'm having the problem with but 5.6! Sorry! I think it's just a permissions thing as it had happened once before. My 5.7 sites are working fine.
ok, I just installed the latest from github and tested it DOES work... so I have to assume it is problog or my theme that is break redactor? That seems a bit crazy... is that possible?
@ntisithoj
It is very easy for an add-on or theme to break something.
Have you tried installing the add-ons in steps until Redactor image display breaks?
It is very easy for an add-on or theme to break something.
Have you tried installing the add-ons in steps until Redactor image display breaks?
well, it does not break on the virgin install with the add-ons installed, so, I am completely clueless at this point what the problem is :/
In any case, thank you for your feedback.
In any case, thank you for your feedback.
one more question... I have completely replaced the concrete directory in the broken site with the contents of the virgin's concrete directory, and still the same problem.
Should I be looking in another place?
Should I be looking in another place?
Not sure if you got this problem sorted, but I have the same issue, except with uploading and linking to files.
When I upload a pdf file through the File Manager and link to it on the page, it comes up with a 404 page.
In the File Manager properties for the uploaded pdf the URL paths are as follows:
URL To File: domainname/files/3614/4176/1420/SBSSeptember2015.pdf (works)
Download URL: domainname/index.php/download_file/112/ (doesn't work - 404 page)
However, the url that the actual link in the page points to is
domainname/index.php/download_file/view/112/321/ (doesn't work - 404 page)
Any ideas on this?