Please indicate if this is the wrong forum for this, but I am looking for a very rough scope estimate for adding a bulk upload feature. Our site is in PHP and the functionality for the bulk upload is basically we want to allow users to enter text into CSV files that will populate posts with that text. We will also allow users to enter image file names into the CSV and upload a folder with the images (and their file names) so that the posts contain the images as well.
The site itself already supports the posts and their respective fields through a web form so this simply allows a bulk feature on top of already-built functionality.
I'm trying to see if something like this would be on the order of days, weeks or months to build. Thanks.
Related
I'm developing a web site with codeigniter + grocery crud.
I really like the upload file feature from grocery crud.
But I'm wondering if it's possible to pick a file from a server folder instead of uploading it. I mean just put the name of the file in the field.
I don't want to write more than what is needed.
Edit: I want the user to be able to do both: upload a file, or pick it from a server folder.
I've been asking myself the same question. I was thinking in doing it like this:
1 - Create a Media Library table (Wordpress style) and store all the file uploads in a table.
2 - Add a relation field to select images form this table.
http://www.grocerycrud.com/examples/set_a_relation
The basic relation field will generate a select that allows you to select images by name, id, description, etc.
This is not very user friendly, so I guess you'll have to write one or two callback functions to show the users the image they are selecting
this is the approach I'll be using on my next codeigniter+grocerycrud project :)
Good luck!
Suppose we have the web application which handle create, read, update and delete articles and each article should have gallery of images. I have to make one to one relation between Article and Gallery and one to many relation between Gallery and Media.
HTML5 gives a lot of features like multiupload, so I want to use this excellent http://blueimp.github.io/jQuery-File-Upload/ plugin for that. The problem is how to handle the file upload "in memory" like other form's data?
For example when we show the page for create new article we should be able to fill in article's data fields and select images to upload, next when we click the save button the images should start upload and after that the form should submit. When validation fails the images should be still displayed on the frontend, but on the server-side nothink should be saved.
One of the solutions is create somethink like "create entity session temporary id" before displaying the entire form and that id can be used to create temporary directory for save uploads, so after success saved form these images can be moved to appropriate directory, but how to make the "create entity session temporary id"?
The other solution I think is the "with the edit id" approach, because we can handle the uploads with previously saved gallery id, but sometimes I can't save new blank article with gallery, cause some of the fields should't be empty in db.
For the Rails I saw https://github.com/thoughtbot/paperclip gem which in the Readme says:
Paperclip is intended as an easy file attachment library for Active Record. The intent behind it was to keep setup as easy as possible and to treat files as much like other attributes as possible. This means they aren't saved to their final locations on disk, nor are they deleted if set to nil, until ActiveRecord::Base#save is called.
My question is how it works?
The problem with enabling file uploads on the create mask is that you eventually end up with orphaned files. This is because a user is able to trigger the upload without saving the actual entity. While creating a very own UploadBundle I thought about this problem for a while and came to the conclusion that there is no truly proper solution.
I ended up implementing it like this:
Given the fact that our problem arise from orphaned files, I created an Orphanage which is in charge of managing these files. Uploaded files will first be stored in a separate directory, along with the session_id. This helps distinguishing files across different users. After submitting the form to create the actual entity, you can retrieve the files from the orphanage by using only your session id. If the form was valid you can move the files from the temporary orphanage directory to the final destination of your files.
This method has some pitfalls:
The orphanage directory itself should be cleaned on a regular basis using a cron job or the like.
If a user will upload files and choose not to submit the form, but instead start over with a new form, the newly uploaded files are going to be moved in the same directory. Therefore you will get both the files uploaded the first time and the second time after getting the uploaded files.
This is not the ultimate solution to this problem but more of a workaround. It is in my opinion however cleaner than using temporary entities or session based storage systems.
The mentioned bundle is available on Github and supports both Orphanage and the jQuery File Uploader plugin.
1up-lab/OneupUploaderBundle
I haven't work with the case personaly, but my co-worker had similar conundrum. She used
punkave/symfony2-file-uploader-bundle
It's a bundle that wrapps jQuery File Upload plugin. It is in the early stages and a lot of things are missing, such as event, but we gave it a shot.
That's what we do: in newAction() we create entity, generate unique dir ID, and store the ID in entity (via regular setDirId()). Than we create the form, which contains hidden field dirId.
We are uploading the files to temp dir on server via ajax, not during the submit. Ajax request requires the ID. It stores files in temp_dir/prefix_ID
Than it's quite simple. Form is sent. If form is valid - move files from temp to dest dir. If not - we have the ID, and are able to show the images.
However, we do not save information about individual files in a separate table in the database. Every time we read the contents of the folder that corresponds to our dirId.
I know it's not the solution You are asking for. It's rather a workaround.
I am in the process of building a CMS using php, however I am struggling on how to handle the various different assets that a dynamic page could serve, typically an average page will contain pictures of various sizes(thumb, body, main, etc), inline images and various different assets(pdf, flv, mp4, doc, etc).
At the moment a user can upload assets and create a folder on the server, I just wanted some techniques and concepts on how to manage this in terms of deleting, editing and linking to my dynamic pages within the cms? I already have a content table which contains all the content(meta_stuff, title, friendly_url, content_text, etc).
On upload should a reference be stored somewhere in say a asset table?
Should all paths to assets(images, docs, videos,etc) be stored in one table? or separate for each asset?
Should multiple image sizes(small, medium, large, etc) be stored in different fields e.g(assetid, smallpath, mediumpath, largepath?
What technique to use to link assets to the dynamic page? should this be a joined table or single? how do I go about retrieving the different assets for a page several pdfs and several images?
How to handle deleting of assets as this could be referenced to another dynamic page?
and anything else you think would be beneficial?
Thanks for all your help
Here are some basic things to keep in mind when dealing with resources (videos, images, documents..) in a scenario similar to what you're describing.
You'd want is to know what's being uploaded, what kind of stuff are being uploaded and who's uploading. To do that, it's good to have the following tables:
Edit: Sorry about the mistake, asset_types.asset_type_id should be linked to assets.asset_type_id and NOT assesst.asset_id
(Note: This is just an outline, of course you'll have more fields)
This model makes it easy to do the following tasks
Upload: When something is uploaded, you store it somewhere (with the correct
.htaccess configurations) then store that path in the table.
Delete: When the user is trying to delete something, you check if he's the owner.
When you want to add a new type, you don't need to create a new table.
Hopefully this will put you in the right direction.
Update: Answering your comment, when a user wants to add an image to an article for example, you have two options here:
The user is presented with a button/select menu/whatever to choose the desired image, once clicked it will add <img src=LINK_TO_RESOURCE" /> to the body of the content (Make sure you protect yourself from XSS).
OR
You use your own simple markup, when the user clicks on an image this [[PREFIX_IMG:IMG_ID]] will be added to the body of the content, when the content is viewed you'll replace that "tag" with <img src="LINK_TO_RESOURCE" /> which you've acquired using IMG_ID.
2nd Update: Well you have a couple of options to handle resources that aren't directly embedded in the "articles" themselves.
You can have a field in the "articles" table you can call summary for example, and one more column to the assets table which you can call asset_sub_type and have different types like summary. Then when you want to view the summary you fetch the summary text/title from database and you add the resource to it.
(This is the technique I use) When fetching the summary from the database I see which image is the database that is related to that article and the resize it on the fly with PHP and append it to the summary.
I've got the PyroStreams module for PyroCMS and made a stream called portfolio. Everything is working as expected, however it only allows to upload just one image for my file field. That is obvious, but I'd like to know if there's a way to upload multiple images for one stream entry without adding x number of extra file fields. Or do I need to code an extra field type myself to support this? Maybe someone's got it already?
Thanks
According to me you have to create a separate database table that will hold all the images those are related to particular portfolio and the portfolio id by id by which you can fetch the images for particular record and then use any multiple image upload library like http://www.plupload.com/example_queuewidget.php to upload multiple images in the portfolio image table. Hopefully this will help you in achieving what you want.
There's a multi-upload files field type available on the pyrostore.
I'm trying to make my own framework for my own projects and I would want people to upload themes for their profiles to the database. Letting them theme the look and feel of their accounts.
I first thought of having the files on the server.
A user would log in and the PHP would pick up their user id and other misc details and route the urls to their particular folder and serve the files in that folder.
an example would be a real directory of
http://www.foo.bar/users/me/style.css
http://www.foo.bar/users/me/script.js
http://www.foo.bar/users/me/index.tpl
http://www.foo.bar/users/me/otherPage.tpl
then I was thinking wow, imagine if I have 100's of users? then I would have 100's of folders in my users directory on my server, not to mention duplicate files all over the place taking up space. So ok, while this may be the fasted way to fetch a file maybe loading the markup from the database won't be such a bad idea right?
My server looks cleaner but now my database will get queried a lot more than I would want.
Then comes the major issue i think, is having files that are particular to a user. For example stylesheets may have background url's with images, so now these images needed to be linked to their real path on the server. Which brings me back to having a dedicated folder for each user to house their theme specific files.
How can i securely and effectively find a way to let users upload themes and have all files images, pdf's, docs, etc. all saved without them potentially being accessed by another account holder or thru simple hacking techniques to pull a file from the server that belongs to another user.
One solution I thought of was to only let users who are logged in view files, append to the file a unique tag that will let the user view the file if the tag matches a session variable. But then what if a user wants to share that file with another person, then tagging the file would bring my back to square 1 with the security thing not letting view the file because they wouldn't be an authorized user.
Well in any case, what would be best practices to get some of my concerns on the right path to being delt with.
P.S.
I choose these tags because in my solutions I think they will touch upon some of these aspects.
You can store html or css in a table row but be sure to sanitize the data to avoid hacks, or injections. The easiest way would be to let the user paste the code into a text area or field. If you want to let them upload files, you will need to write a script that parses the data from the uploaded file. This is more complicated as you will have to manage all filtering and sanitizing along with making pulling the data from the file and saving it to the database.
We skin our CMS to work with multiple clients and their own users. But rather than giving them the possibility of changing ANY area or style of the page we allow certain areas such as:
upload your logo
set the colour of the banner bar behind your logo (using a smart colour picker and some 'figure out the contrast between the colours' functions)
set your text colour (using a colour picker)
and so on for the items you want them to change.
We then store those in the database and serve them up through dynamic stylesheets (I know these don't cache but it's better than having hundreds of files).
I know that MySpace used to let you upload a whole host of HTML and CSS (not sure if they still do) but it's a security nightmare as the potential for XSS is enourmous.
You may want to look at HTML Purifier if you're going to let them add their own custom HTML and full themes -> http://www.htmlpurifier.org