-
Notifications
You must be signed in to change notification settings - Fork 7
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
External image files not processed #1
Comments
Hi @withindale are you using the filepicker (in the Grav Admin panel) to select your image? That is the way the plugin is intended to work, which I believe means you would need to store the image within the same directory as your *.md file. Please let me know if that is not the case or if I'm misunderstanding the issue. Thanks. |
Hi Matt
Some of our images (and movies) are stored in the page directory as you
described. However they become hard to reference elsewhere when there are
hundreds of pages. The solution was to put media in a separate directory.
This also helped to keep storage within the limit of the "unlimited" quota
provided by the ISP. At present the media directory is 7GB which would
double if kept in the pages directories of our development and live sites,
not to mention backups.
Ian Russell
…On Sun, 9 Feb 2020 at 05:32, matt-j-m ***@***.***> wrote:
Hi @withindale <https://github.com/withindale> are you using the
filepicker (in the Grav Admin panel) to select your image? That is the way
the plugin is intended to work, which I believe means you would need to
store the image within the same directory as your *.md file. Please let me
know if that is not the case or if I'm misunderstanding the issue. Thanks.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#1?email_source=notifications&email_token=AEBZD4PO3OUI5T3ELEMG4MLRB6IPBA5CNFSM4IY5XFRKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOELGC57Y#issuecomment-583806719>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AEBZD4MFYBASJM34NRLUVDLRB6IPBANCNFSM4IY5XFRA>
.
|
Hi again Ian Going by your example fix I'm guessing you are providing the full URL to the image, is that correct? Enabling this would allow users to input URLs outside of their Grav installation, which is not necessarily bad, but it does increase the risk that the image may be changed, moved etc. without the user's knowledge. getimagesize will return unexpected results unless the image can first be verified to exist, and the file_exists function doesn't work well with URLs, apparently. Having said that, if you are linking to images within a user defined media directory within the same website, you could provide a relative path to the file (e.g. '/images/file.png'), then the file_exists and getimagesize functions would be safe to use. Updated code would be something like:
Would that work for you? |
Hi Matt
Many thanks. I will have a look at what we can do when we do some
restructuring of the website, probably at the end of March.
Currently we have a live site in one subdirectory (root/en) and a
development site in another (root/dev). Media is in its own subdiirectory
(root/media) so accessible to both.
This is not ideal but for some reason our IT manager and ISP agreed we
should use a subdirectory for GRAV when we changed from another CMS in the
root.
So the answer to your question is yes or no !
Thank you for Aura
Ian
…On Sat, 29 Feb 2020 at 03:51, matt-j-m ***@***.***> wrote:
Hi again Ian
Going by your example fix I'm guessing you are providing the full URL to
the image, is that correct? Enabling this would allow users to input URLs
outside of their Grav installation, which is not necessarily bad, but it
does increase the risk that the image may be changed, moved etc. without
the user's knowledge. getimagesize will return unexpected results unless
the image can first be verified to exist, and the file_exists function
doesn't work well with URLs, apparently.
Having said that, if you are linking to images within a user defined media
directory within the same website, you could provide a relative path to the
file (e.g. '/images/file.png'), then the file_exists and getimagesize
functions would be safe to use. Updated code would be something like:
if ($filename) {
$imagePath = false;
// Test existence of image at page level
$imagePathPageLevel = $page->path() . '/' . $filename;
if (file_exists($imagePathPageLevel)) {
$imagePath = $imagePathPageLevel;
$imageUrl = $page->url(true) . '/' . $filename;
} else {
// Test existence of image at root level
$imagePathSiteLevel = ROOT_DIR . $filename;
if (file_exists($imagePathSiteLevel)) {
$imagePath = $imagePathSiteLevel;
$imageUrl = $this->grav['base_url_absolute'] . $filename;
}
}
if ($imagePath) {
$size = getimagesize($imagePath);
$this->webpage->image = new Image();
$this->webpage->image->url = $imageUrl;
$this->webpage->image->id = $this->webpage->url . '#primaryimage';
$this->webpage->image->width = $size[0];
$this->webpage->image->height = $size[1];
$this->webpage->image->caption = $this->webpage->title;
$this->webpage->image->type = $size['mime'];
}
}
Would that work for you?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#1?email_source=notifications&email_token=AEBZD4MVGSKFKILHV4SLY43RFCC3VA5CNFSM4IY5XFRKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOENLDFYA#issuecomment-592851680>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AEBZD4J22VDKNMK6NJ6VIHTRFCC3VANCNFSM4IY5XFRA>
.
|
Thank you for the Aura plug-in.
Our GRAV website is at url/en but some images are in url/images and Aura does not output them.
This appends a quick fix:
The text was updated successfully, but these errors were encountered: