I am currently trying to implement a feature in a web-application that allows the user to upload an image and display it on the website.
I'm using SpringBoot with Vue 3 (TypeScript) and for production I build it into a single jar using the frontend-maven-plugin dependency.
I tried using the MvcConfigurer to expose a directory (In which I would save the uploaded images) of the server but that started to conflict with the vue-router.
A lot of the solutions I found required to image to be uploaded to the database and to my knowledge this isn't actually recommended.
I also tried using absolute paths but the images wouldn't load at all then.
Some of my friends recommended to use a cloud server but as I am doing this for school I think that's a bit overkill.
Anyone know a satisfying solution to this or has a recommendation?
Related
Next.js documentation says:
"Only assets that are in the public directory at build time will be served by Next.js. Files added at runtime won't be available. We recommend using a third party service like AWS S3 for persistent file storage."
I have issue to understand how would you work with a site with dynamic content. I mean, let say i operate a merchant site, do i have to rebuild the site each time i add a product? or must i use a cdn for my images.
Sounds it should have a more easy way no?
I am new with OctoberCMS. There are few tutorials in the internet. May I ask what is the best setup may I use or possible setup may I use with this web tech stacks?
We have a project and the requirement is we need to use octobercms so that's why we have to used this octobercms.
Possible Setup:
Micro Service Setup?
Two seperate folder for OctoberCMS and Vue.js. The communication would be an API Request calls.
Then for the deployment part for the production, we will use the dist folder from Vue.js Folder. I'm not 100% sure but I think this will be my initial thought that will be possible.
May I ask for any suggestions or clarifications on what will I use project setup. Thank you.
While it would be entirely possible to have two separate web properties with October providing the API, you can also just use Vue within an October CMS theme itself. See https://github.com/scottbedard/vuetober for more information on doing that.
If your project is more of a traditional CMS requirement then I would recommend at least trying the Vuetober approach. If it's a lot more complex and is mostly utilizing October for its powerful backend features, then the API-only approach could work fine too.
The main reason you'd want to go with running vuetober is if you were going to be utilizing the AJAX framework provided by October. You can still technically use it even when October is being run as a headless CMS just providing an API, but it gets more complicated with CORS and some other stuff you have to setup to make sure it works properly.
Hi I'm working with create-react-app, i've setup a file upload that allows images to be sent to the backend and saved locally (to the projects build directory). I'm able to dynamically reference images via localhost:4000/image.png so that already works (ie: i have a blog that lets me upload images that I later access via a blogList).
However i figured this probably isn't the best place to dynamically upload images to. I've read the docs on create-react-app and both the locations that mention images dont seem to work for my use case, i feel like im definitely doing something wrong but im not sure what.
docs im referring to:
Says use "import" however im loading dynamically so i cant see how this would work?
https://github.com/facebook/create-react-app/blob/master/packages/react-scripts/template/README.md#adding-images-fonts-and-files
says use public, however wouldnt that require a rebuild? since im loading dynamically that isnt possible: https://github.com/facebook/create-react-app/blob/master/packages/react-scripts/template/README.md#when-to-use-the-public-folder
NOTE: i have a image uploader and backend working fine it works already using the /build directory. i can upload and dynamically reference images. I'm just looking for best practices for doing something like this. Thanks!
(if you mention "just use nginx" could you please elaborate on the implementation a little)
As a learner I struggled with this problem and tried different approaches once a while ago. For rarely used assets, using /public for client could be useful but I have an app where clients upload images and manage them. Like you, I did not like those approaches and ended up with this setup.
Create a /public directory on backend and upload images to /public/images
Serve /public directory with Express statically.
Use dynamic path variable (via a config setup) for image paths. http://localhost:backend_port/public/images for development and /public/images for production.
I don't know this is the best approach but it worked for me. Beside being best approach when I upload images before that setup CRA was refreshing (hot reloading) my app after each image upload.
I am trying to create a portfolio site and am stuck finding a good approach to deal with images. I have integrated the SonataAdmin Bundle and have setup Admin classes for "Projects" and "Images". My goal is to go into a Project and add images to it and select one of these images as the Project thumbnail.
Ideally I would like to integrate an AJAX multi-uploader. I am not sure the best approach for this and am looking for any suggestions / thoughts.
I have looked at the Sonata Media Bundle, though it seems more robust than I actually need and the learning curve to customize it seems a bit steep. I have already setup an image entity (symfony2 cookbook for uploading documents) I imagine I can create a many-to-one on images and projects rather than using the MediaBundle, though I am still at a loss of how to integrate an AJAX script for this.
Thanks in advance for any advice!
Shawn
I suggest you to look at https://github.com/punkave/symfony2-file-uploader-bundle
This bundle is based on the excellent blueimp jQuery-File-Upload package and provides multiple file uploads.
Edit 28/04/14: There is now also OneupUploaderBundle which supports a variety of uploaders and seems to be under more active development.
checkout https://github.com/ruian/RuianUploadifyBundle its support multiupload but only with flash plugin.
Also this bundle is worth a shot. Not really mentioning AJAX, but seems really strong in basic uploading features. Once you get that done, you can ajaxify by yourself. I'm planning to try this bundle in few days, I may update this answer later.
So I endedup using Valumns Ajax multi uploader: http://valums.com/ajax-upload/
I tried to customize the Sonata Admin Page but this proved a bit difficult, Instead I simply created a route / controller / view specifically for uploading batch images. It seems to be working great!
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