Uploads field - folder config - integration

You cannot use placeholders in path with approach we had chosen for Cobalt. It is simply impossible to implement.

one of examples. You created USER_ID in path. Then you deleted those but there are already some files. How you link them for new path?

Path have to be reusable.

This is not so important. When you will be in situation and you will need this, you will understand ans say "Here is what you have meant!"

Anyway, the answer is: NO WE WILL NOT ADD PLACEHOLDERS TO FILE SAVE PATH.

Why do you restrict the selection to those three "date" related schemes?

Because every filr saved with timestamp attached to the name and I always know date file was saved on. I can use name of file to build path.

If a file has already a complete timestamp, why this extra folder categorization? I mean, you talk about flexibility, but those date folder options are a fixed limitation?!

This is to reduce amount of files per folder. If there is more than 2 000 it may start work slower.

Sackgesicht has more than 200 000 files.

more than 311K files (266GB) in my upload folder and i am quite happy with the system/structure. It allows me to monitor developments per day through the YYYY-MM-DD folder setting.

An improvement would be an additional setting per year or month. It would make external synchronisation even easier -- but only cases with daily uploads would benefit of it . Maybe it could be considered for the next version.

I like the way it is stored now much better, than it was under Mighty Resources with the user_id in the path. Now it is really organized by field. I reorganized several times the files and just renamed the subfolder parameter in the field settings.

As said, the different "date options" are just there to reduce the number of files per folder to avoid performance issues with the file system when browsing it and is helpful in monitoring it.

Following Cobalts philosophy to make it as simple as possible for users, they even don't need to know how and where files are stored.

The same with the database structure. It does not follow normal conventions and users don't need to know how it is stored. They just define fields under types and assign types to sections. If someone looks deeper into it, they could also complain, that a digit value is stored in a string field etc. but everything comes with a price.

Just simple homepages that need a CCK for a product catalog or a small gallery, portfolio etc.

Stored files belongs to a field and a record. You can access them always based on the field and record values and it does not matter how it is stored. The user_id is stored with the record as well.

Everything can be queried.

From a sitebuilders point of view it looks like a really strange combination: Fixed date options + path parameters in field + URL in field !?

From a "site builders view" you should even not care about the structure behind. Simply use what the system (Cobalt, Joomla) provides to you.

Lets look at the upload field. The process is to upload files and retrieve them back. Cobalt provides this.

Gallery field: Upload fields and display them in different ways (including thumbnails).

If you store 1 or thousands of files, no difference. Cobalt provides it.

From a "programmers view", he needs to know how it is structured and how to access them to provide additional solutions/enhancements. All needed info is provided, either through the records "fields" column or even through the records_value table.

Now the crucial question:

**Do YOU face a real case scenario, where you got into problems and are not being able to solve it with the existing setup?

**

I'm not talking about hypothetical case scenarios.

I am sure, if you face a problem, a solution could and will be found for it in this forum.... :D

Now, if you want to dig deeper into it, it does not end with the folder, it goes to the filename. See a partial list of files from one folder below. Does it really help the site builder to access the folder? I presume not.

This is going to be my favourite topic ;-)

I think we are already in a loop here...

Maybe you should read the topic from the start again, especially the explanations given above ... :D :D

Then again,** if you face a real problem in an existing project of yours**, i am more than willing to help solving your issues (even though I'm not a programmer ... :D ) and I'm sure MintJoomla will even provide better assistance than myself.

I would let the user upload a file/picture in the Cobalt structure... should not care about the real physical location. If the user wants to "manage" or "select one of his files or images...

Ok, to your "file repository" project, you might describe it a little more in detail. There are so many ways to solve this. Depending how you want to display them , you might need to customize an output template for it.

I believe "managing" means uploading, editing and deleting. The "uploads" field will provide you with this functionality. You can also change the original filename and add a description to it.

Then depending on your output template, you can display it anyway you want.

Make your section and type settings. You can even use user defined categories to organize your records.

If this is too limiting, then allow only 1 file per record. Add as many other fields as you need in your type definition to store additional information about your file. You can sort your personal file repository by whatever fields you add to it, filter it in any way you want ... You can download them or (depending on the file type) display them. All depending on your output, list and article templates.

Do you need to know or specify the file structure for it, No !!!

Then again, please see my file screenshot. This is how Cobalt stores the files ... Will you be able to identify immediately out of the filename what is behind it? No, i dont think so.

Example:

1363917600_7b499531861f4a83dbe8b2b7e80e8880.pdf, 1363917600_7d13e698b28d6cac68ea54c249402f40.pdf ....

Therefore, what help would it be to "influence" the path and directly access those files...?

Just start your "personal file repository", you will see it is not this complicated. If you run into a problem, just ask and i am sure you will get the needed help ... :D

And extensions like Cobalt and systems like Joomla allows to solve many tasks without "hardcore" coding and real custom development

Precisely the point here. You dont need to do "hardcore" coding and even dont need to know about the procedures and structures behind. Just use it ... like the upload field. :D

Therefore, what help would it be to "influence" the path and directly access those files...?

Just start your "personal file repository", you will see it is not this complicated. If you run into a problem, just ask and i am sure you will get the needed help ...

Yep, as long as the whole management does happen on a section it is very clear and the templates are the most crucial part. But that is only 1 view on a possible use-case. I always think about integration and re-use of data and files... So, here is my second step and thought:

How to access and re-use the files/images in that repository from another type or section? You might remember the topic "how to use the same image without re-uploading...". Actually, an easy task and typical demand.

The relation field is the only way by "configuration" and "templating. Although it is not optimal. Uploading has to be done in parent article VIEW, not on submission. So, the user has to leave the actual context and workflow. For new uploads, it turns out to be 2 separated tasks: Upload & Linking/Relating

That's why I thought to combine J! core features (mediamanager) + Cobalt. But this would require to access a physical folder structure...

Conclusions:

A) it has to be a Cobalt only solution (extra Cobalt file-manager, access repository in modal window?)

B) Relation-field needs an ADD NEW feature, WHILE submitting the Parent.

The more "importatnt" conclusion towards the topic "Uploads field - folder config - integration " is that based on the used file naming it does not make a difference if one can access directly a folder path or not. I think this is what the topic is about.

See here how to display a list of records for the current user (his own files). It will help you with your problem/project. :D

The relation field is the** only** way

I would disagree ...

There are so many ways, it just depends what you want to achieve and how you want to "reuse" your content.

It can be another field which gives you a selection of your already uploaded files, it can be a form template which gives you the selection, etc etc ...

Think the Cobalt way and forget about your traditional approach (file system, folder path) ... Cobalt knows where your files are, just tell what you want to see (make the right query or access the API) and Cobalt will deliver the files to you ... :D

Anyway, storing in the root "uploads" folder still makes sense to me.

That contradicts also your requests for user specific folders ... now if all files of all users would go into the root, would it really help you? And then most importantly, please take a look at the filenames again. What can you get from it?

Imagine just 100 files like

1363917600_7b499531861f4a83dbe8b2b7e80e8880.pdf, 1363917600_7d13e698b28d6cac68ea54c249402f40.pdf ....

in 1 folder. Any help to you?

Like in a database, do you need to know the physical location of a row of information? No, you just need to know how to access it ... In cobalt the folder structure is not relevant for accessing the data.

Lets assume you want to point a 3rd party to a specific folder and you are "irritated" by the "year or date" structure, what would you get out of it?

Just a selection of cryptic filenames. Helpful?

I dont think so.

If you want a sense full "integration" with another product, it has to be on a different level.

The 3rd party can easily access the needed info from Cobalt (as stated before, Api or query) and will even get much more out of it (filesize, real name, displayed name, description, size, hits etc etc .. even EXIF information of pictures without processing the files, and if you stored other information to it, the whole record... )

You want to integrate stored files with JCE?

An editor button might be a solution for you.

As I said, there are so many ways to solve your (non existing) problem, it just needs an analysis, what you really need. This need will only be defined by a REAL project, since there are so many parameters and related solutions along the way.

Lets not loose the focus here in discussing different folder structures. Try to rethink your approach. Does it really make sense? Get a real project and lets continue when you are there, facing a problem. I will be happy to show you a solution for it. :D

As I mentioned earlier, I was looking from another perspective

It always needs a deep analysis to grasp the whole concept. Approaching only 1 layer (folder structure) does not solve it.

Btw, other solutions like galleries, use a similar approach. You can upload files and add additional info (captions, descriptions, stored in a database) to it. They just use a limited number of files for their albums. But if you look at those solutions (Sliders, Galleries), they all use what they believe is best for them. Same with Cobalt. There is no universal or even Joomla standard for it. Therefore it will always be a one-to-one integration.

A specific field would be another solution for you. In this field you will follow the structure of a 3rd party solution. I think that is what you should have in mind. But then again, there are many ways to tackle it.

:D

I already mentioned the "Private file repository" as a very useful scenario. I would let the user upload a file/picture in the Cobalt structure... should not care about the real physical location. If the user wants to "manage" or "select one of his files or images... how and where should i do that?!

the fact we do not have user ID in the path does not tell that we cannot do that. Every uploaded file is registered in file registry (special DB table). This keeps user ID as a parameter. Thus we can create user personal; file manager where user may manage files by section, extensions, field or whatever. Mush more flexible.

(Stumbled upon this topic... while I was reading and retrieving my older topics and links to other posts... unfortunately, the move from AngelDesk destroyed all my internal cross links :( )

Although this topic has been "closed", I moved it to Cobalt 8 category.

Sergey Thus we can create user personal; file manager where user may manage files by section, extensions, field or whatever. Mush more flexible.

Personal filemanager sounds nice. But where and how? I assume you are talking of a general solution or media manager for all sorts of files i.e. uploads, images, video.

I understand/accept the Cobalt structure and logic for global uploads and file storage...

But how can it be used to mimic a private folder feature? For example to re-use my own uploads and images on record submission and edit? I think this typical usage does not need a complex mediamanger. i.e. in regards of images: a simple frontend feature to upload, select and see only my images.

BTW, there are other topics about "private image folder"... I am going to link them here as well.