Lucas,
I don't know how I missed that!
Thanks,
Matthew

Hi Lucas
Can this be done from the front end? From a form?

thank you

just saw this thread... so there is no way to ftp images directly? you have to go through the file manager? For instance, I'm migrating to C5 and have over a hundred mp3 files to use with SimpleCast... I can't ftp them? (they're like 25mb a piece)

you can add a folder to your /root/files directory called 'incoming' and then ftp files to it. then through the file manager click the 'more' button next to the 'upload' button. the middle tab reads 'add incoming' when you click this it will detect that you have added files to the /root/files/incoming folder and add them to your library. You can assign file sets etc... from there.

Hello,
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.

Thanks,
Matthew

Hi, I agree with you. If I would have know it is so awkward to upload images and other files to Concrete5 I would have chosen a different CMS. I have a huge site and structured all my images into neat folders. Now it seems I cannot recreate those folders as the "sets" I have to create only seem to have one layer, so a folder structure seems to be out of the question or have I missed an update somewhere? I also don't like encrypted files. I need to see my folder structures. Or is there any new plugin which let's you create folder structures for images? Anyone please?

Hello,
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.

Thanks,
Matthew

Maybe this is a solution.....though it certainly does not "answer" the question. It seems to me that C5 could keep the system they use to index images for the functionality it needs, however, could those files not be "dumped" into one large folder for images so we could use ftp to interact with that folder. It could be coded so that all the files in the files folder would sync with the files in the images folder created. If this is ridiculous and makes no sense I apologize. I am new to all of this and I am learning more every day.

To Sully: what you're saying is totally reasonable. There absolutely should be a way to upload images into a large site folder than can then be used for 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.

It's puzzling.

Anyway, I really like Concrete5 for many projects. I wish they would fix this so it could be useful for bigger projects.

Thanks,
Matthew

I find the way concrete5 manages files is a lot better than most cms's, sets is actually much more efficient for larger sites then just plain folders.

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.

Mike

Then there is also the fact that most people don't know how to use ftp.most people don't even know what it is!

Mnkras,
Like a lot of things, this is obviously an opinion.

Scenario 1:
(1) Name my files locally
(2) Upload photos into folders that I created
(3) Grab the photos from my folders inside my articles

Scenario 2:
(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.

Thanks,
Matthew

well in response to your senario 2,

(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.
(3) What?
(4) Use the api its really simple, or just use file sets!

I totally understand that the way C5 handles files is not ideal for you and your particular way of doing things. But for 99.9% of people using the system, it is *much* better because, as Mnkras pointed out, most people don't know what FTP is. Most people don't understand hierarchical file systems (or hierarchies of any kind). Most people don't understand how to find a picture they uploaded because it's named 948039852034.jpg. And most importantly, most people are uploading one or two or maybe a dozen at most images at a time.

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.

-Jordan

Hi Matthew

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')

This is allright for a single picture, and I do it exactly this way. But all those slideshow and gallery add-ons need the file manager.

That sounds alright with images. How do you get around it with swf files

I will add my voice to the list of folks who would like to see a much cleaner file upload, and storage solution.

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!

The folders are randomly generated, its for security, lets say you have an ecommerce site for music, having all of your files in 1 folder is unsecure, as someone could guess where the files are. where if the files is like /files/2345/7345/4573/file.mp3 there is almost no change of them being able to find that even with bruteforce.

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.

Mike

i would also love to add my voice for the creation of a simple FTP/file linking option in the c5 interface. i'd love to be able to edit the hierarchy, names metadata just like the Sitemap, and sync w. services like dropbox would be really useful too, and if any of these features were available as add ons i could imagine people here would support it ya?

Long thread and many good answers ... but I am suprised no one has talked about the design issue. So I give my voice for the designers here.

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.

Best regards/Micke

When you're designing a site, you shouldn't be putting logos and other assets that are not user-editable into the file manager -- those should be in your theme directory instead where you have complete control over naming, renaming, editing, FTP'ing, etc.

... The logos, pics and illustrations goes into articles, sliders and scrollers in my case to. And it would be nice if the image links back to the place where I place with FTP. That´s my point.

Perhaps I'm misunderstanding the issue, but it sounds like some folks are wanting to store images in the file manager AND be able to reference them without the URL of the image changing if they edit or resize the image. The only way I know to do that is to use a URL of the form...

/index.php/download_file/view_inline/1/

...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.

-Steve

Thanks. I found my ways to do this as simple as it can get.
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)

:)

/Micke

This is exactly what I think about it. Sometimes you need to make changes to pictures; in my case: pictures in a gallery for a customer. It would be so easy to upload the pics via FTP, just a matter of seconds.

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.

This is not a perfect solution, but it will save you a few clicks -- there is actually a "replace" option for files that you can access from the file manager (or from the image chooser that you'll find in a lot of blocks). In recent versions of Concrete5 (I'm looking at a 5.6 system now... not sure about 5.5), you can choose an image that's in the /files/incoming directory to replace existing files.

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.

Nice tip, thank you, Jordanlev!

Hi, I have a site with a lot of interactive maps and image swaps. I do create the java-script-code in dreamweaver, create an html-block on my page and copy the dreamweaver-code into it. Until now I uploaded the image-files into the file manager and for each image copied the path from properties into the html-code. A maddening approach, but it worked.
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 why don’t you create a subfolder in /files, like /files/images/mypics or something, and then put an image link into an HTML block, like ?

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.

How about this... I have no upload option at all.
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.
http://www.aboutsteam.com

You don´t see anything in the upper right corner in the filemanager? Check my attached file? ... I would re-intsall C5 is that´s the case.

Good luck
/Micke

I realize this thread is getting older, but I thought I would give some explanations for the way the File Manager works, because I don't think everyone on this thread realizes the complexity of the system behind it and why it doesn't work with simply an FTP upload.

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.

I am quite new to Concrete5. After creating a few personal sites with it, I became a great fan. Today, I tried to upload a video and I got a size-limit error. Of course there are a lot of solutions to change the upload limit, but one should not have to mess with that.

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 5.6.2.1, 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".

Just to mention...
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

Best luck...

- Why I can't add my files via ftp?
- Because it's not for techie persons, it's for housewives who don't know what it is!
- Hmm..
- 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?