Uploads field - folder config - integration

For image based modules and scripts, I think a common folder for images would be the simplest way.... I guess, this could be a much simpler approach than special Gallery-field or Article templates. I mean, an alternative.

It simply will not work this way.

Other scripts/modules/plugins are not so simple as well, that they just need an image in a specific folder. There is much more information to the image with these 3rd party scripts. Think of an image description (even with HTML formatting), thumbnails, naming conventions, author, date of upload, rating, voting, comments etc etc ...

The way to integrate it with these type of scripts is by the original provider in adapting the Cobalt upload information into their options. Similar to what Rockettheme wants to do with Roksprocket. Roksprocket can get the needed info through their individual adaptors for different sources like Zoo, K2, Seblod etc.

I would prefer the way it is now (clearly defined) and to create adaptors for these other scripts if needed. But with the gallery field you have already the basis for everything.

Agree. I think it is almost impossible to make it universal and suitable to every extension just by setting parameters. It is much more complex especially when we talk about images.

But that is why we made a registry on all uploaded files. So you can easily feed any extension by selecting needed files and providing hm in a format that extension require,

Please, look at the first screenshot. I mean, this is a limitation. Cobalt is so flexible in all areas, but this important configuration is not.

I would like to hear some comments on my suggestions in the initial post... seems, there are no changes in Cobalt8 base configuration, nor in Uploads field.

Uploaded fiel in cobalt is abstract. Even it's name is MD5. Cobalt 8 have file storage in it's own format.

I do not think there is way to change it. Because this is most effective way to work with files. And has only one (single) disadvantage that it does not work with extensions that works with folder as source of information. And that is bearable compare to disadvantages to relay on the file structure as on to the information source.

"...easily feed any extension by selecting needed files ..." Though this topic was more intended to improve the uploads location and folder, I am interested what you mean?!

This is still possible even to create personal file manager. Since we know all files uploaded by any user, their names and fields that uploaded it, we can create file manager to simply pik up any uploaded file.

What i want to say that current method does not limit us to do that.

Regarding uploads field: What means "abstract".

Since we store all that information about file in DB it does not matter where file is really stored. We can export it to any file structure you want w/ w/o user id or record ID or what ever. This is the most flexible way. Any developer will have much more options with current way of storing files.

It is like on HDD. You see c:/windows/... but in fact where is the file on the disk? It may be even in different part of the disk but single file. This is what i cal abstract. The path like c:/windows/syslem/calc.exe is abstract. But in fact this file is stored in HDD file table, just like cobalt files are stored in cobalt file table.

I am sorry this time you just have to believe me that the way we go now is the best because I do not have good english enough to explain.

Why not extend the base folder configuration?

Why not extend the base folder configuration?

Either way, why not add a selectable folder location ?

For this you can define an individual folder per field or organize the files better (not necessary, but optional)

Why not extend the base folder configuration?

Either way, why not add a selectable folder location ?

Not optimal for sitebuilders and easy configuration.

Actually it is easy for sitebuilders. They dont need to know anything they can just upload without any configuration. But if they want to organize it, they can set individual folders. I believe that is "easy" enough.

Why not extend the base folder configuration?

Either way, why not add a selectable folder location ?

Not optimal for sitebuilders and easy configuration.

I would like to hear some comments on my suggestions in the initial post.

Why not extend the base folder configuration?

Either way, why not add a selectable folder location ?

Not optimal for sitebuilders and easy configuration.

I would like to hear some comments on my suggestions in the initial post.

set independent BASE folder, allows to target specific 3rd-Party folders. Not located in global uploads

I dont see a use to "penetrate" 3rd party folders. Just look at the extensions. Almost all of them using their own tables to store image related info (author, creation time/upload time, statistics, dimensions, caption/text etc etc), so uploading the image to this folder alone would not make any sense for the other extension. Manipulating their data tables would be an overkill. You could just use the extensions own upload and management tools.

Why not extend the base folder configuration?

Either way, why not add a selectable folder location ?

Not optimal for sitebuilders and easy configuration.

I would like to hear some comments on my suggestions in the initial post.

set independent BASE folder, allows to target specific 3rd-Party folders. Not located in global uploads

set naming scheme on files... so files are sequentially numbered or they will get a specific filename, that another Script might need

See my comment before.. There are so many ways to store filenames, why complicate things and not use the extension which will later display them? Why try to use the Cobalt upload, where the own extension upload would be in most cases much much better suited to the task?

Why not extend the base folder configuration?

Either way, why not add a selectable folder location ?

Not optimal for sitebuilders and easy configuration.

I would like to hear some comments on my suggestions in the initial post.

set independent BASE folder, allows to target specific 3rd-Party folders. Not located in global uploads

set naming scheme on files... so files are sequentially numbered or they will get a specific filename, that another Script might need

Dynamic foldernames like paths in JCE Editor i.e.:

Again, you will just display them later, so why choose other settings when the extension (like Cobalt)

takes care of it? With the cobalt upload you will link the images to the field/type/section for whatever purpose. If other scripts want to fetch them, they can easily do it (Slider script), since the Cobalt field structure provides everything they will need. That should be the right direction.

Why not extend the base folder configuration?

Either way, why not add a selectable folder location ?

Not optimal for sitebuilders and easy configuration.

I would like to hear some comments on my suggestions in the initial post.

set independent BASE folder, allows to target specific 3rd-Party folders. Not located in global uploads

set naming scheme on files... so files are sequentially numbered or they will get a specific filename, that another Script might need

Dynamic foldernames like paths in JCE Editor i.e.:

An option to set NO specific subfolder

Just ignore the subfolder parameter ...

Anyway, i was also thinking of another structure before, but then after looking deeper into it, i completely agree now with the way it is. (My only request was to add a daily folder to it. This system became very maintenance friendly. I work every day with this structure and i am very happy with the outcome so far.

I just checked our system here -- we are controlling 240,859 Pdf files as of the moment and the way they are stored (database and folder structure - using symlinks) makes it a joy to work with.

If you have a real case scenario, lets just make a case study. I believe we will find an easy way with the existing structure and/or the 3rd party extension to achieve any goal. ;-)

For this you can define an individual folder per field or organize the files better (not necessary, but optional)

Totally missed it, sorry! (due to J!3 backend appearance)

Maybe a good parameter to add something like placeholders to create the folder name?!

Like in SQL param. i.e. [USERID], [FIELDID], [AUTHORID], [TYPEID], or maybe [USERNAME] etc.

BTW, I am not complaining about the way Cobalt stores and organize files. I just see it through the eyes of a sitebuilder/designer. I know, "Sackgesicht" is a SQL guru, and "Sergey" knows his way around in PHP and Cobalt variables etc. That is not the case for most site-builders.

For this you can define an individual folder per field or organize the files better (not necessary, but optional)

why complicate things and not use the extension which will later display them? Why try to use the Cobalt upload, where the own extension upload would be in most cases much much better suited to the task?

Actually, I am thinking about using misc standalone scripts (sliders etc.). Not ready-made J! extensions or modules.

Why Cobalt for upload? Because it works in frontend! Almost no other script or module has frontend capabilities! So, a very cool application, IMHO.

For this you can define an individual folder per field or organize the files better (not necessary, but optional)

why complicate things and not use the extension which will later display them? Why try to use the Cobalt upload, where the own extension upload would be in most cases much much better suited to the task?

If you have a real case scenario, lets just make a case study. I believe we will find an easy way with the existing structure and/or the 3rd party extension to achieve any goal.

I will be back and bother you ;-)

BTW, I am not complaining about the way Cobalt stores and organize files

I dont see it as complaining, actually i thought the same way before, but being forced to live with the way Cobalt stores the files (since resources), i realized the huge benefits.

BTW, I am not complaining about the way Cobalt stores and organize files

Totally missed it, sorry! (due to J!3 backend appearance)

This parameter was there also before in C7.. :D

BTW, I am not complaining about the way Cobalt stores and organize files

Totally missed it, sorry! (due to J!3 backend appearance)

I know, "Sackgesicht" is a SQL guru

Hahaha, not really .. If you would only know how many "hours" it takes me to tinker around with SQL queries .. It is always a trail and error experience and learning daily new things ... but I believe that every sitebuilder should have a basic knowledge of it. A good example would be self created maintenance queries to ensure data integrity etc. Having said that, a cool project for Cobalt would be a frontend dashboard to better monitor data within TYPES and SECTIONS. But this is a very individual case depending on the use of relation fields etc. Because of the closed environment of Cobalt, it could be done to match most installations.

BTW, I am not complaining about the way Cobalt stores and organize files

Totally missed it, sorry! (due to J!3 backend appearance)

I know, "Sackgesicht" is a SQL guru

Actually, I am thinking about using misc standalone scripts (sliders etc.). Not ready-made J! extensions or modules.

Then you are talking already of customized development .. and especially for this, the way cobalt stores the files is a big help for integrators, it can bring them even to a higher level (by using the stored field info), than just using a specific folder.

BTW, I am not complaining about the way Cobalt stores and organize files

Totally missed it, sorry! (due to J!3 backend appearance)

I know, "Sackgesicht" is a SQL guru

Actually, I am thinking about using misc standalone scripts (sliders etc.). Not ready-made J! extensions or modules.

Maybe a good parameter to add something like placeholders to create the folder name?!

Like in SQL param. i.e. [USERID], [FIELDID], [AUTHORID], [TYPEID], or maybe [USERNAME] etc.

These and much more parameter are there through the field properties -> table columns, no need to create individual folders, you can access them all when you integrate your scripts. We did similar things before with Rokstories and other commercial sliders and it was working quite well.. ;-)

BTW, I am not complaining about the way Cobalt stores and organize files

Totally missed it, sorry! (due to J!3 backend appearance)

I know, "Sackgesicht" is a SQL guru

Actually, I am thinking about using misc standalone scripts (sliders etc.). Not ready-made J! extensions or modules.

Maybe a good parameter to add something like placeholders to create the folder name?!

Like in SQL param. i.e. [USERID], [FIELDID], [AUTHORID], [TYPEID], or maybe [USERNAME] etc.

I will be back and bother you

Anytime ... ;-)

To make it easier, an additional option for "Folder Format" --> "No Format" might help you already. So you dont have to worry about the automated folder structure under your defined subfolder.

Global uploads folder

An option to set NO specific subfolder. Just the root. (allows to set the target folder in field parameters)

found it ;-)

Not sure, what happens exactly, if I change the uploads folder in field parameter? It creates the same basic default structure which is set in global config?! Than, this should definitely have an option "none".

Can I go outside the global "uploads" folder ?

Since you said it stores all paths and locations...

Maybe i have to be more precise. It stores under the table column "fullpath" the "folder format" but not the "general upload directory" or the field subdirectory.

If you change these parameters along the way, you will break the linkage to the already uploaded files.

I believe the full path should store "general upload directory"/"field sub folder"/"folder format". No need for the additional filename since it is already available under column "filename".

The nice side effect would be a substantially smaller record size, since the filename usually covers ~ 56 characters.

If you change these parameters along the way, you will break the linkage to the already uploaded files.

If you change folder or subfolder just rename them accordingly. Everything will be fine.

If you change these parameters along the way, you will break the linkage to the already uploaded files.

I believe the full path should store "general upload directory"/"field sub folder"/"folder format" But if we go this way, then you rename subfolder or uploads folder and everything breaks. You need to update whole DB to make it work again.

thanks.

your explanation why you structured cobalt this way.

its quit easy to modify the gallery plugins to adapt to individual files instead of a folder. so we better modify the little extensions than alter the structure of the (nearly) almighty cobalt.

I thought, it would take/use the global configuration option. I mean, use the selected pattern and replace it accordingly. In other words, Cobalt stores just a kind of a "placeholder" with the path. Not the real names.

Unfortunately, this important discussion fizzled out. :( :S

This recent C8 topic remind me on this issue.

"How to use same image in different article without uploading again?"

In other words, how to upload and select images again...

and how to have private image folders per user or usergroup etc.

e cannot change structure. It will not work.

Placeholders are bonded to context. And context we call imaged from is not always the same. We will have to same also environment snapshot to hold context of saved image. This makes things more complicated without adding any advantage.

Placeholders are bonded to context. And context we call imaged from is not always the same. We will have to same also environment snapshot to hold context of saved image. This makes things more complicated without adding any advantage.

???

Related to this topic: Use the same image in different articles without uploading again

Most wanted feature and some ideas:

1.)

a.) PRIVATE folder for uploads and image field. Allow [PLACEHOLDERS] for path parameter. See example of JCE in initial topic description.

b.) J! MediaManager improvement? Set initial folder to images/[PLACEHOLDER]? Retrict or even hide the selectbox for going-up. So, user stays in his own folder.

2.) Global/Base folder structure by date is a limitation, IMHO.

a.) Add an option "none" or "root". Otherwise PRIVATE folders are not working beyond a certain time-frame! i.e. Month has changed, and user can't see the older images/uploads anymore

This is still possible even to create personal file manager. Since we know all files uploaded by any user, their names and fields that uploaded it, we can create file manager to simply pik up any uploaded file...

3.) Your suggestion - No physical private folders

a.) Extend image/uploads field with modal window to select own files

b.) Access Cobalt mini-filemanager for each field? Or special option in section/user-homepage?

(Would like to know more about this approach! How to integrate it )