Easier Way to Upload Images/Files?1 user found helpful
I've been building my site using Concrete5. I've got several pages, and now I need to upload all my images.
It appears that the only way to get multiple images uploaded to my site is to add them one at a time through the File Manager. But my site has hundreds of images, and I have plans for new galleries as time goes on. Uploading one image at a time is not a good way to go!
I tried to upload the images to the "/files" folder, but there is a sub-folder structure in there that makes it impossible to follow.
Please tell me there is an add-on that makes batch uploads possible!
This will allow you to select multiple files and upload them all at once, limited by your server capabilities and settings.
I don't know how I missed that!
Can this be done from the front end? From a form?
I've been using the "incoming" method for a few days now, trying to get used to it.
My assessment: it creats extra steps. I'm used to being able to simply FTP my files to a folder in my site, then they are available for use -- done. Why does Concrete5 use such a multi-layered solution to file uploads?
Here are my problems with the "incoming" folder method:
1. Essentially, you are uploading your files twice: once via FTP, and again in the file manager. You have to upload your files to the "incoming" folder, then go into the file manager, click "more" then request to bring the files into the Concrete5 system, then wait (and wait, and wait) for the files to actually get uploaded.
2. You have to remember to delete the files from "incoming" so they don't get mixed up with your next uoload.
3. You can't keep track of your files without going into the file manager, since Concrete5 creates a mysterious set of folders encrypted with (apparently) random numbers.
It would be great if the next version of Concrete5 could at least let the site owner choose whether to use the "encrypted" folder method.
I'm in the process of creating a Web site using Concrete5 and Jommla, to do a direct comparison of the benefits and weaknesses of each one. The system employed by Concrete5 for file uploads is a big weakness in my opinion.
I still follow Concrete5 developments, and I really like Concrete5 for many reasons.
However, the file-upload system has made it impossible for me to use for any significant projects. Therefore, I can only consider it for small sites with very simple structure.
If there is a new solution to the file-upload system, I'd be happy to hear about it. That might make me reconsider Concrete5 for some of my bigger projects.
Apparently, there's no response from the Concrete5 developers on this issue. One of the strengths of Concrete5 is the direct way you can relate to your material. So I'm totally amazed that leave such a convoluted file-upload system in place.
When I first posted in this discussion, I thought for sure it was something they would fix in future releases (or at least in a bug fix). But the issue remains.
Anyway, I really like Concrete5 for many projects. I wish they would fix this so it could be useful for bigger projects.
As for your question on the incoming folder, it does not upload them twice. all it does is move the files then extract and create information for them.
Like a lot of things, this is obviously an opinion.
(1) Name my files locally
(2) Upload photos into folders that I created
(3) Grab the photos from my folders inside my articles
(1) Name my files locally
(2) Upload photos into folders specified by the CMS
(3) Transfer files again inside the CMS
(4) Deal with encrypted file names the CMS creates
For my work, the most efficient way is scenario 1. It's faster, more direct, gives me more control over my files, allows my local files to match my server files exactly, helps me organize files into logical folders when I have hundreds of files, and makes more sense when I'm replacing files and folders with updated ones.
Give me concrete reasons why scenario 2 is better than scenario 1.
I do believe Concrete5 is a great CMS in many ways. I've used it for many simple sites. But lately, I'm finding the file manager too much of a hassle, even for simple sites. A lot of the time I save with the great front-end editing elements is lost in managing files.
(1) No difference
(2) If you want them to manageable by a file manager it has to be able to index them, so you can use permissions and such.
(4) Use the api its really simple, or just use file sets!
But even assuming it was ideal for most people to choose their own directory structure for file storage -- you would *still* need step 3 above, because one of the "concrete" benefits that concrete5 provides is the File Manager, which is really freaking amazing when compared to other CMS's I've used. It is so much easier for people to add a block and click a button that says "Choose Image" and then find the image in the list that is sorted via date and shows thumbnails than it would be to have to search through a folder browser like the default TinyMCE toolbar button makes you.
Another benefit of this approach is that it facilitates much easier editing interfaces for custom blocks that people create. For example, I build a lot of image galleries for both clients and for the marketplace. Sometimes if I just want a quick and dirty solution I can put a simple dropdown list in the block edit dialog that asks users to choose a file set. Because there is a whole system for managing file sets in the File Manager already, this represents a ton of work that I as a developer do not have to do. But sometimes I do need to implement a more complex interface -- the File Manager wins out here as well because I can have them choose one image at a time, or they can check a bunch of boxes in the File Manager and then pick "Choose" from the little action menu at the top of the list (the one that has "**" in it) -- voila, all of their selections are now in my block. See how the built-in slideshow block handles this for an example of what I'm talking about.
So, in summary, the current system is geared towards making the user interface of concrete5 easier for the majority of people who use the site -- and most people do not find FTP and file systems to be a desirable user interface. I understand that you do, and I'm not saying you're wrong or anything, just wanted to highlight what the benefits were and explain why it's probably never going to be changed or addressed by the core team.
I have similar needs as you. My "workaround" is:
1. Upload (via FTP) the files I need, to a folder i named 'images' on my website.
2. Write my article (using the normal Concrete5 way)
3. Insert the images I want in my article by using 'insert/edit image' and provide a full URL (e.g. 'http://www.yourdomain.com/images/image.jpg')
Perhaps what would help in the interim is an explanation of the current strategy and why. At first glance, it doesn't seem to follow a pattern for the folders it sets up to store files. And perhaps there is no pattern, and there just needs to be a better front end to the storage of files.
We have a growing number of images on our site, and my business partner and wife manages that most of the time. It is either difficult and she's figured it out, and stopped complaining... or it isn't as bad as we think! I'll have to ask her, at the risk of opening a can of worms!
You can use c5's api to interact with the files, if you want to, but if you don't want the files in the filemanager, just stick them in a folder in your theme and use $this->getThemePath();.
Remember, this is for the average user, not some techie person.
But first... Joomla has two ways of working with pictures an uploads. You can both create folders in your backend admin and also in FTP. This is great for clients and for developers. This should not be so hard to fix for Concrete Developers.
But I can survise with the way Concrete 5 works with the uploading but what I tink is realy a big problem for me as a webbdesigner is that everytime I change a picture I have to upload it again since it seems that the pictures goes in those nested folders.
This maybe good for security but everytime I rezise the logo and testing my way I have to upload it again !!!
Please tell me that there is a workaround for this issue.
...where "1" is the file ID of the image in the database. That's the URL you get if you add an image in a Content block using the "Add Image" link. If you edit the image, just replace it in the file manager using the "Replace" option. Granted, uploading via the file manager is not as convenient as uploading via FTP, but at least the image URL remains the same.
I do agree that images used as design elements should be kept separate from images used as site "content" (which users are allowed to change); and the best place for design elements is in the theme's directory.
But right now I am working with a slider and think I need to adjust the images a little bit. Make them darker and also 3 px smaler... If it Concrete could work via FTP all I have to do is to upload them once in the image directory. But from what I can understand frpm this thread is that Concrete choose this way of working because of security reasons.
BTW... I put the main logo, background, styles etc in the ftp and call them from styles.css (working with boilerplate theme)
But no – you have to log in to the dashboard, use the file manager, delete the old picture, upload the new picture, … What an overkill.
I agree: most people have never heard of FTP or something like FileZilla. For them the file manager might be a great tool. But on the other hand: those customers forget how to handle the file manager anyway, and ask us web designers for help.
Yes, I am one of those persons who would love to have more control about how and where to store files. At least it would be a nice feature if you could create more sub folders, like /files/gallery1, /files/gallery2 etc.
So if you have a lot of images to replace, a quicker workflow for you would be:
1) Upload all of your images via FTP to the "SITEROOT/files/incoming" directory
2) Find each image in the file manager, click on it, choose "Replace", and choose the replacement image from the dropdown list under the "Add from Incoming Directory" section.
I understand this is still more steps than you're wanting, but hopefully it saves you some time.
I would like to ftp-upload all those images directly into an image-folder. First I uploaded this image-folder into the roots directory. This seemed to work: after editing and publishing the images were shown perfectly. But if I return to the page after visiting another one, the links seem to be broken. The images have vanished until I go back into Edit-mode.
I have tried putting the image-folder into my theme directory but to no effect. I copied this line into default php:
<img src="<?php echo $this->getThemePath()?>/images/your_image.jpg" alt=""> ...
Could anyone help me please?
But please notice that in most cases, duplicate JavasSript libraries, per example jQuery, will conflict with each other. That means, if you upload your own jQuery files and libraries, something might not work correctly.
I have tried uploading a picture by adding a block image with no luck and the file manager has no place for me to upload either.
Since FTP does not have the ability to manage multiple file versions, permissions for concrete5 users, file sets, arbitrary file attributes, or file indexing for listing and sorting files in the user interface, the features offered by the File Manager on the front end become virtually impossible. Yes, the File Manager features "could" be created using other methods, but there are pitfalls that would make those alternatives far less reliable and potentially more complicated for developers.
First of all, file versioning would require a separate location for other versions of a file, and if a file was moved or renamed via FTP for organizational purposes, concrete5 would have no feasible way of reassociating a file's versions with the new filename; they would be orphaned. All file sets, attributes, image thumbnails, ownership information, and permissions would also become completely useless, and any page with the original file(s) on it would have to be manually updated, because concrete5 wouldn't know what changed via FTP.
In addition to these changes, concrete5 would have to implement one of two things to process file changes: either check for changes every time a file is accessed (leads to a performance sink), or have a job that checks for changes and updates the concrete5 index (leads to database inconsistencies). Neither of these solutions are very attractive compared to the existing concrete5 model, which keeps all managed files completely up-to-date and efficiently accessible.
Regardless of how well this alternative is built, the issue of orphaned data would continue to be a problem, because the complexity of finding files once they are moved/renamed involves working through file hashes and recursive file comparisons, which can be very processing intensive--too much so for some basic hosting plans or for servers anywhere near their performance limits.
For a solution that maintains the current feature set but allows unchanging files to be easily added via FTP, an additional "Static File" feature could be implemented that simply selects files from some static files tree(s) with an interactive interface. This feature would not be able to manage data/permissions associated with the files or provide thumbnail generation for images, but it would allow some files to be accessed easily through the content editor without having to know the file paths.
That being said, I don't see any real advantages of creating such a feature, because you would lose the current file management features for those static files, and it would ultimately add complexity for editors and developers without any real benefit except easily uploading large batches of files that are never going to change (if those files really do exist; I'm always changing things I never expected to).
As an experienced developer and IT professional, the advantages of concrete5's File Manager seem to far outweigh the ability to upload files via FTP in fewer steps. Some things are simply trade-offs that we can't have both sides of, and I believe the concrete5 team chose the best option for the features they wanted. It could be improved slightly, but there will always be limitations to a CMS unless it has its own service running on the server (not feasible in most setups).
@pigment: If you ever do need to repeatedly edit images that are in the File Manager, use the "Replace" option in the File Manager, which will simply create a new version of the file that automatically gets used in place of the old one. Presumably, you're only editing one image at a time anyway; so, there's no real issue there. If you're already aware of this by now, let this serve as help to any new users unaware of the option.
There are a variety of ways to transfer files between machines, each with its own conveniences. One should not be limited to just one way.
To say that this is the ideal solution for 99.9% of the people is quite ... - Claiming you know what everyone needs and that everyone lacks simple knowledge such as ftp and even concept of hierarchies
I see two separate requested features here:
1) Allow people to upload the files to a server (not using Concrete5) and then have Concrete5 pick it up from the local file system instead of the editor's machine.
2) Allow people to control their file hierarchy.
I think #2 is nice to have, but #1 is essential (sort of supported through 'Add Incoming').
Side note: In 18.104.22.168, to use 'Add Incoming', you need to select "Upload Multiple" In the file manager and then click the 'Add Incoming' tab.
I don't know why that feature is hidden under many layers. It certainly does not belong under "Upload Multiple".
Size limit has nothing to do with Concrete5. That is controlled by the PHP settings on your server. I can't explain how and where to change this on your server, but normally it is in a server file (outside the concrete5 root folder) called php.ini where you have to change these values:
upload_max_filesize = 10M
post_max_size = 10M
- Because it's not for techie persons, it's for housewives who don't know what it is!
- Yeah and they need file versions, sets, attributes, permissions and indexing!
So, ~5 years and still no easy way to manage images? If I need to resize 50 images, what should I do? Upload to ftp, import to file manager and make (open menu-"replace"-open incoming files list-(find file)choose file-"replace") 250 clicks. And then add them to file sets. Instead of ~5 clicks with ftp :-/
And why keep folders(for thumbnails too) after deleting image?