I have a lot of markdown files that I've imported into Contentful with images linked inside of them. The images link to external websites like Imgur for the source.
I'm trying to get the images to scale up and lazy load like you can do using the Gatsby Image API. The problem is that the images are all within the one html node due to how the markdown is processed.
The markdown is being set on the page using:
dangerouslySetInnerHTML={{ __html: body.childMarkdownRemark.html }}
Is what I'm trying to do possible? I feel like there is some way to chain Gatsby plugins to download the images locally from the html and then create nodes in GraphQL to handle this but I'm not sure. Ideally I don't want to have to change the markdown files to point to Contentful assets due to it not being easy to migrate to other solutions in the future.
Any help would be appreciated! Thanks
Related
I'm trying to build a E-commerce site with a admin page where the administrator can upload images of certain products.
I'd like Meteor to upload those images to a folder and then display those images in the product page of that product.
I know that normally the image files that the client will be using should be inside the 'public' folder, but I'd like to know more about what other options I might have.
Also, if I upload a new file to the 'public' folder or if I delete a file in the 'public' folder, the website refreshes itself...and this is good and bad at the same time depending on what effect you are after....
Here are my questions:
What if I create a 'uploads' folder in the server and upload the images to that folder. Would it be possible to display the images inside the 'uploads' folder in the client browser??? How??
Is there a way to use the browser to access the contents of the 'public' folder???
Is there a way to stop the 'reactivity' of the site if changes happen in the 'uploads' folder created?
Is uploading the images to the 'public' folder the best solution available to this problem?
Thank you very much for the help
When dealing with what will likely be a large number of images I like to offload not only the storage but also the processing to a third party.
My go-to app in this situation would be Cloudinary. Here's why:
Storage - I can store the original images outside of my application. A huge benefit to keep images in sync from dev to prod.
CDN - I get the extra benefits of images being quickly loaded from the Cloudinary CDN.
Off-load Processing - All of the processing of images is handled by Cloudinary which doesn't slow down my app as a whole.
Image Manipulation - I can make calls to the original image, calls to just get a thumbnail, and calls to change manipulate, ie :effect => grayscale. So if a 1000x1000px image was uploaded, I can request a 50x50px from Cloudinary that will return the image cropped to that exact size rather than using CSS to shrink a huge image.
Flexibility - I can change the size of images and return that exact size to the app without having to re-upload images. For example, if my product page pulled in thumbs at 40px, I could easily make a call to grab the same image at 50px.
Hope this helps.
http://cloudinary.com/
You can do all of this using the meteor package collectionFS. The package is well documented and you have a variety of options that you can uses for storing the uploaded files. CollectionFS also gives the ability for image manipulation on the upload, such as creating a resized thumbnail.
I realized this question is a bit old.
I had the same problem, one of the solution that works for me is using meteor-upload https://github.com/tomitrescak/meteor-tomi-upload-jquery
Definitely don't store stuff in the public directory - it will slow down starting up the app, and hot code refreshes on image upload could easily cause it to crash once there are a decent number of images in there.
Any of the above solutions with storing images elsewhere would work. One other option is using the peerlibrary:aws-sdk package to upload stuff to S3, which is what I use for several apps and have found to be very clean.
Storing the image as a base64 string in MongoDB is also a method. Useful for posting to APIs and save the worry of having to handle other 3rd Parties.
I've two different images of every user, think of it as a two images uploaded by the users.
I'm uploading those images to the s3 and I have the links
I want to cache those two different images for different users.
I saw the meteor appcache package looks like that is for static content only.
How to do that?
ANy ideas appreciated.
We are using the excellent wkhtmltopdf to render PDFs from HTML web pages on our website. We need to render and store about 10,000 PDFs in a single batch job. This poses a problem.
Gathering the JS, CSS and image assets required for every PDF via HTTP is going to be very slow - is there a way to cache the files like a browser does across each request ? wkhtmltopdf doesn't seem to have any options to do this when batch creating PDFs.
I'm coming from a php/mysql background. I'm most familiar with the Kohana PHP framework and I'm trying to learn Docpad. I have a loose understand at this point and I've built out my first website and blog. Static content makes a lot of sense to me on Docpad.
I'm working on my photography site where I want to be able to upload new images to a portfolio. The backend needs to handle an uploaded high-resolution image and create several different copies at different resolutions of the image. My biggest question is how do I keep track of the image meta data that I want to display? Do I generate a physical file for each image that has all the particulars I want to track and use those files as my searchable database, much like how blog posts are setup?
Or should I go the route of using something like MongoDB to store image data there where it can be queried and plugged into a layout?
Regarding handling POST or GET data, should I be reading up on the express.js docs? I'm not really sure where to turn for that.
Wordpress uses TimThumb to re-size it's images: How does WordPress.com resize images dynamically?
Then there is this re-sizing library for node: node package for file attachments and image resizing
If you wanted to created like 3 different image sizes and use the backbone collection in DocPad, then you'd add your different re-sized images to those three different collections/folders. For access the images you might just be able to do it via it's file name. So when you copy, re-size and rename the image, in the rename step, concat the image size at the end, like: coolPhoto-med.jpg and then you could just do hard links to get to the image like /spring-collection/med/coolPhoto-med.jpg or you could use query engine to access them.
The file model has a meta attribute: https://github.com/bevry/docpad/blob/master/src/lib/models/file.coffee#L17
I've yet to learn how to use it yet though.
I know we chatted yesterday on #docpad IRC but I just wanted to answer you here too. If you do code something that re-sizes images for DocPad, please do consider putting it up on Github to share with the community.
I have a requirement of bulk uploading images. More precisely, I want to upload all the images for a web site (static images like back ground, logo, corner images , images required by css etc..)
As I think uploading these images one after another is not looks like quite practical (As it might have 60-70 images). So my questions are..
What is the standard way of doing these kind of a staff ?
Is it possible to let users to upload a .zip (images) file and
extract it from the server side.
If 2 is possible, can i do it with Rails3 and standard shared host
thanks in advance
cheers
sameera
1) Assuming you are talking about allowing bulk uploads from the website not as a rake task the typical way for handling multiple uploads is to use Uploadify / SWFUpload for the frontend along with a gem such as Paperclip to handle the images on the Rails side.
A google search for "paperclip uploadify" or "paperclip swfupload" should give you some good reference material.
2) It is certainly possible to do this, I've mostly worked with it the other way around to offer zipped archives of files for download but processing zips and working with the included files is definitely do-able
3) The suggested methods I gave for (1) above work just fine on Rails 3 and I can't see any reason they wouldn't work on shared hosting. That approach will however need some additional work for environments such as Heroku which have no or transient direct storage