FileSystem Encoding doesn't populate UTF-8

It's made like this "by design". Actually I have no way to know what is the default FS encoding. Take any UNIX as an example. On the same root, I can have CIFS/ISO-8859-15 mount, NFS/UTF-8 mount, etc, etc.. So in order to populate the right encoding I should be able to guess what is the FS encoding for the specified folder depending on which mount this folder is pointing... kind of tricky... If you have any standard php solution for this, it's easy for me to populate this fied.

I'm not a "pro" of the FS encoding, but i think its depends of the OS right ? UTF-8 for Unix, and ISO-8859-1 for Windows ?
And to answer to bredi, you (Yoran) can implement a «pre» completion of the field with the php function:

$node->folder_presentation->encoding = (php_uname('s') == 'Windows') ? "ISO-8859-1" : "UTF-8";

I think you can solve 99% of the FS encoding when creating a new dir_list with this.

Unfortunately this is not that simple. Linux have a mix of UTF8/ISO FS depending of versions, distributions, mounts, etc.. And I don't speak about a Linux FS mounting an CIFS/iso windows share :)

Perhaps the right way to solve this is allow this field not to be filled. When encoding is blank, we can use PHP standard handling. Else, when someone have specific problem (like this danish persons for whom I made this patch) he can fix it by explicitly specify encoding. What do you think ?

Perhaps the right way to solve this is allow this field not to be filled. When encoding is blank, we can use PHP standard handling. Else, when someone have specific problem (like this danish persons for whom I made this patch) he can fix it by explicitly specify encoding. What do you think ?

Ok. Let's talk a while about the form when the user submit a new dir_list:

• the fieldset "Folder Presentation" should be just below the title and the description. Because it's the one that handles the main essential options. (error message drupal if FileSystem encoding field is blank "FileSystem encoding field is required."). Should be not collapsed also.
• I am totally agree with you to let the FS encoding blank. Many of (my) users know nothing about that.
• To satisfy this thread #1176948: Filebrowser Defaults for example and/or to create a dir_list easier for users, why not make a page settings by default in drupal: example.com/admin/settings/filebrowser
  • Set the default FS encoding by the admin who knows the FS on his server.
  • Set the default options for Folder Upload.
  • The admin might set the controversial "download manager" ;-) Again it's not so simple for the standard user.
  • And the other options by default: Blacklist *.ion...

I just want back to the "download manager" and give you an example of a wrong end use from one of my user:
She set the directory path to sites/default and not sites/default/files !!!
And as you guess, the file settings.php was available to be downloaded !!!

That's why we should have 2 parts: the settings handle by the admin (blacklist some directory path, FS encoding, etc...); the option of presentation by the user.

* presentation going up => done in dev branch with a bit of cosmetic too
* ok for default "empty" file system encoding => done in dev
* about settings, that's a good idea. A real mess ton implement in AOP but a good idea :) It's in dev branch also.

About settings stuff. I can make kind of a pure separation between which settings are in node, and which are in drupal settings. I still need to be able to have one node with (as an example) UTF8 and an other with ISO. So now we can have default values, but this will not prevent your users to override such defaults.

If we want to prevent this, I see 3 options :
1/ add a permission for each panel to make it visible or not
2/ add a more global "advanced node settings" permission for which we can make a list of "advanced" fields.
3/ Make use of a module like form_filter or, better, a simple module implementing hook_form_alter, to hide critical fields.

Personally I would go for the third one. Not because it'll be obviously less work, but because after 2 years on this project, I know for sure there will be controversy for choices 1 or 2.

I rather like option 2: The admin can do what he wants and set defaults options (regep for directory path, FS encoding, Folder Rights, Folder Upload). If the user wants to create a specific node and changes the default settings, Only the admin can edit.

I don't get the option 3. I don't see what should be the difference with the 2nd.
And by the way, with the permission to "admin Filebrowser" only, you will decrease the number of the current permissions (13 permissions actually).

What will you put in "Admin filebrowser" ? Perhaps can you create a specific issue for that ? Now that I have the default system working (you didn't tell me if this is ok for you), is't just a question for everybody to agree with this new permission area.

What will you put in "Admin filebrowser" ?

The same as you implemented in the dev version ;-)
My point was how to do that (Comment #5). But i think the goal is definitively clear. A standard user might not be able to set up himself all the required fields for a new dir_list node. So it should be more "friendly user" to let the administrators set up by default some fields and have permissions to change them by the users.

Perhaps can you create a specific issue for that ?

Done: #1192768: Settings page for Filebrowser fields. So the debat is open.

you didn't tell me if this is ok for you

I had an bug on my PHP: #1192462: PHP(5) Fatal error that i solved. But so far, it's works!
So let's see what the users thinks about that and we can definitively close this ticket.