A few issues in Authentic Theme

Hi Ilia,

Here is a few thing I found Authentic Theme.

  • In Webmin/Others/Upload & Download and tab "Download from server". If I select a file or a folder and do the download the progress-bar never finishes, leaving the download button "disabled". To download another file I have to click Upload and Download again in the left menu.

  • When using English US(EN), or maybe other non UTF-8 languages the hyphen In the browser tab gets messed up, it shows three strange characters. I have seen this from many programs, the are "translated" into a strange hyphen. If I copy text from some other and paste it into UltraEdit as unformated text and then paste it to a HTML page the hyphen is messed up/wrong, but if I delete and rewrites the hyphen in UltraEdit (it looks just the same) and then paste it to a HTML page its OK.

  • In File Manager, when extracting a compressed file all files and folders gets root-root. I often uploads big zip-files that includes many files and folders, sometimes hundreds. Then I have to change owner manually! In Java File Manager setting you can select the default user as "same as the directory". Or if you want to change you can do it in the upload dialog. And you also can select "Upload, Extract and Delete file" in one action - Really nice! I manage all our customers virtual servers and pages from our root login.

  • The right frame sometimes has a scrollable window/frame in the right frame making the scrolling really hard, especially when on a smaller screen. You then get the right frame scroll, and also the window/frame inside get a vertical and sometime also a horizontal scroll, and with three scrollbars the moving around gets really time consuming and hard. Why cant the content be displayed directly in the right frame?

OK, enough this time.

BTW, I really think the Authentic Theme is very nice, good looking, fresh and "up to date", but I have to say, I liked to use the Framed Theme better, very clean, easy and fast to work with. I know Virtualmin soon will drop the old themes, so I'm trying to take the step from the old and passed into your nice looking Authentic Theme.

Using Virtualmin Pro, CentOs 7 ,Windows 10 Pro 64-bit Swedish, Firefox 52.1.0 ESR 32-bit Swedish.

Thanks! Regards, Leffe

Status: 
Closed (fixed)

Comments

Joe's picture
Submitted by Joe on Sun, 04/30/2017 - 01:10 Pro Licensee

Hey Leffe,

Thanks for filing tickets!

On the encoding issue, can we approach the problem from the angle of "How do we make UTF-8 work for you?" rather than "How do we fix non-Unicode encodings?" I seem to recall you said you weren't using UTF-8 because you had problems with the UTF-8 encodings, where Swedish characters didn't work. Can you help me and Ilia reproduce that problem? In my testing, I was able to enter the Swedish characters you talked about using either English (UTF-8) or Swedish (UTF-8), and they displayed correctly everywhere (editor, file manager, etc.). Can you switch one of your systems to UTF-8 and tell us where things are going wrong?

I'll let Ilia comment on other issues, as I think most of them are in his wheelhouse.

Hi Joe,

Unfortunately I have to stick with my selected encoding, For example, UTF-8 encoded text don't work in our SMS service, if we send UTF encoded text to our SMS service provider the messages are junk when arriving in the phone. And we do have hundreds of thousands files encoded in Latin 1 and I don't wont edit them all. And in several systems the UTF then has to be translated to Latin 1 before it gets published anyways, so there is no point of switching to UTF for me.

To reproduce the problem you need to have a Latin 1 encoded file first, and with Swedish characters and not coded like & a u m l ; online.

Authentic Theme with language set to UTF-8 in Virtualmin/Webmin: When I open the file in file manager - All Swedish characters is now unreadable/rubbish. If I save the file now all characters are changed to UTF-8 and breaking stuff. And if I download the file the Swedish text is now rubbish when I open the file in my computer.

Authentic theme with language NOT set to UTF-8 in Virtualmin/Webmin: When I open the file in file manager - All Swedish characters is fine and readable. If I save the file now all characters are changed to UTF-8 and breaking stuff. And if I download the file the Swedish text is now rubbish when I open the file in my computer.

And again, it is not a option to use UTF-8 for me. If I do the same thing in Virtualmin Framed Theme, everything is fine, the File Manager DON'T change the encoding on save. And the file is still fine when downloaded.

As I said before, I use UltraEdit Texteditor as my work tool, and I have "Auto detect UTF-8 files" disabled, and it must be like that, otherwise I don't know the file encoding, and publishing a UTF encoded file may break or mess things up real good.

Do you need screen shots on how it looks?

//Leffe

Ilia's picture
Submitted by Ilia on Sun, 04/30/2017 - 10:35

Can you attach one or two files please?

StatusFileSize
new114.22 KB
new112.64 KB
new94.47 KB

Screen dump 1 is how the file looks when open for edit with non UTF language in Webmin

Screen dump 2 is how the file looks when open for edit with UTF language in Webmin

Screen dump 3 is how the file looks after download and opened in UltraEdit in my computer

//Leffe

Ilia's picture
Submitted by Ilia on Sun, 04/30/2017 - 11:32

Not the screenshot, the actual .txt file, please.

StatusFileSize
new3.05 KB

Sorry, here are a small part of a file. //Leffe

Ilia's picture
Submitted by Ilia on Mon, 05/01/2017 - 12:39

I have made possible to save files properly for non UTF-8 users. However, it's not recommended. There is explicit warning upon first usage, against non-unicode charsets.

There will be bugs other than what you have already.

There could be reasonable to add an ability to set encoding right in the File Editor window. You could use UTF-8 then and chose encoding for your files when needed. Do we need that? Joe, Jamie what do you think?

Ilia's picture
Submitted by Ilia on Mon, 05/01/2017 - 12:40

About File Manager extraction and permissions - added to the list of improvements. Thanks.

Ilia's picture
Submitted by Ilia on Mon, 05/01/2017 - 12:58

Status: Active » Closed (fixed)
Joe's picture
Submitted by Joe on Mon, 05/01/2017 - 14:27 Pro Licensee

Status: Closed (fixed) » Needs work
Joe's picture
Submitted by Joe on Mon, 05/01/2017 - 14:29 Pro Licensee

Hey Ilia,

I think there are still outstanding issues in this ticket; there were multiple problems listed above.

I think one outstanding one is ownership of files extracted from archives. Leffe mentioned he was able to set ownership when extracting them in the old file manager.

Hi Ilia,

Thanks for looking at the issues!

I have made possible to save files properly for non UTF-8 users. However, it's not recommended. There is explicit warning upon first usage, against non-unicode charsets.

There will be bugs other than what you have already.

I have seen a warning already, when switching to non unicode English , and what other bugs are you referring to, there is a option to select non UTF-8 languages, why should using one of them give me more bugs. I don't see any advantage of using unicode/UTF characters, believe me I have tried! We update around 400 000 db posts containing citizen data every day from different municipalitys in Sweden and all data in non unicode charset. Latin-1 / ISO-8859-1 is legit charsets and do work without problem, UTF-8 do bring problems everywhere!

//Leffe

Ilia's picture
Submitted by Ilia on Mon, 05/01/2017 - 15:42

Then I will have to do more improvement in this regard. No everything displayed smoothly yet in non-UTF mode.

Ilia's picture
Submitted by Ilia on Mon, 05/01/2017 - 15:45

Not using unicode is only because of the editor? What if you could preserve file's encoding and/or select one directly from the editor? Would that help?

I really think non Unicode is a problem. Chromium in latest releases even removed the option to choose encoding.

Yes, you are correct, the reason for the non unicode is that some file contents gets unreadable when opened in the editor. I don't mind if encoding is unicode in Webmin and Authentic Theme as long as it don't mess with me smile. If I open non unicode files I have to be able to see the characters correctly, and even more important is that file encoding are kept on save, unless you can and want to choose other encoding.

Thanks Ilia, and sorry for being a "pain", but this is really important to me!

//Leffe

Ilia's picture
Submitted by Ilia on Tue, 05/02/2017 - 04:14

Yes, you are correct, the reason for the non unicode is that some file contents gets unreadable when opened in the editor. .. If I open non unicode files I have to be able to see the characters correctly, and even more important is that file encoding are kept on save ..

I have achieved that. I will provided a patch to File Manager very soon and will send you the link to test.

No more need for non-unicode charsets!! ;)

Hi,

Updated Authentic Theme to 18.47 and added the patches 543 and 544.

If I have set Webmin to English US (EN-UTF8). - The Latin 1 encoded file is still not readable in File Manager. - Save now changes the file to UTF-8 again. - Cant use Java File Manager in the unicode mode, characters not readable and save changes encoding to UTF-8.

If the Java File Manager don't work with Webmin set to unicode charset then I have to use Webmin in non unicode - English US (EN). I must be able to have Java File Manager working correctly until the File Manager get things working and the important features from the Java version.

Regards Leffe

Ilia's picture
Submitted by Ilia on Wed, 05/03/2017 - 01:49

It's not what should be happening.

Did you install 18.47 from releases or latest commit from Git?

Ilia's picture
Submitted by Ilia on Wed, 05/03/2017 - 04:11

Leffe, latest theme update is doing it right.

Not sure what you're saying about Java File Manager?

Can you update the theme using theme-update.sh and try again with applied patches for Webmin?

It will preserver your encoding in case UTF8 is set.

I will talk to Jamie to completely remove non unicode charsets. It's 2017 and it's high time to do it, in my humble opinion.

As file editor respects encoding for both reading and writing I see no practical reason for keeping it.

Hi, I updated the theme using the "update button".

I get a error when running update from command line, "TERM environment variable not set".

I really hope they don't remove the non unicode charsets in the near future!!! And regarding the Java File Manager, I use it on daily basis, it's my main work tool. The new File Manager is still missing for me basic and very important features. I'm using the Java File Manager for many hours every day. And removing the non unicode charset will break most of my files and also the services we provide, and some of them is connected to other web services, for example our SMS-notification service that do send lots of notifications every day.

We have bought a new dedi server about a month ago because our old box runs CentOs 5.1, the new is running latest CentOs 7 and I have not yet dared to start moving our cutomers to the new box due to many things, mostly due to not knowing if things gonna break our services! For example not be able to work online with our updates and code in non unicode format. Everything is now very uncertain for me, we can NOT have many minutes of downtime or errors in our services. If things go wrong a day it can lead to us having to send information by regular letters to thousands of citizens, imagine the costs for "stamp fee" for a couple of thousands letters, and that is just for that day. We have not yet, for more than 5 years had any faults in these services that was caused by us, and we like to keep it that way ;)

Virtualmin Pro is a very important work tool for me, but if it no longer provides the important features and work tool it has had for over 12 years is really sad. I must somehow try to get the new server in production and shut down the old one. we also have double costs as long as they both are running.

Can someone please tell me what is in the future, when is the non unicode charset removed, how long can I use the Java File Manager (if the new don't get the features of course). This is really important for me to know, I'll have to find solutions because we have 1, 3 or 5 years contracts with our municipals.

Best regards, Leffe

Ilia's picture
Submitted by Ilia on Wed, 05/03/2017 - 10:34

OK, if we're going to keep non Unicode, I will have to fix my pull requests for Jamie to work not only with Unicode.

What features are missing in HTML FM from your point of view?

First, I do understand that Virtualmin can't keep or implement things suitable for me!

The most important things are:

  • Upload-extract-reomve zip (would be nice to have a option to do this in one action) with owner set to folder owner and/or a option to select owner.
  • Read, edit and save non unicode files without changing encoding
  • Can add a new file in non unicode charset

These are the most important things for me, and the JFM do all this if Webmin is set to non unicode.

But there are many other things that the JFM has and makes it much more easy and fast to work with. Look here, I think most of them is on your list: https://virtualmin.com/comment/774859#comment-774859

//Leffe

Ilia's picture
Submitted by Ilia on Wed, 05/03/2017 - 11:53

I do understand that Virtualmin can't keep or implement things suitable for me!

Actually, we can! This is the whole point of the user-friendly software, that work for users not visa-versa.

About the features:

  1. Upload/extract/remove uploaded file - I will start working on File Manager features prior to mail right after next release (look at number 11 here #629)

  2. ALREADY available, with the latest version of the theme (not release but latest Git version, it will be in release 18.48+). However, I didn't count on non-unicode setups, meaning to make this feature work you would need not only update to the latest patches BUT also switch to UTF8 charset in Webmin.

  3. I will add this to 18.48 and where you see the label for the charset (link with screenshot above), there will be the select for the charset.

These are the most important things for me, and the JFM do all this if Webmin is set to non unicode.

I think JFM would be able to do number 1 even not in unicode.

I ask you please to make sure that what I said in number 2 is working for you. I tested it on two different systems and it was fine! It READ files and it SAVED files without changing the encoding.

Ilia's picture
Submitted by Ilia on Wed, 05/03/2017 - 12:10

I get a error when running update from command line, "TERM environment variable not set".

You're getting this error because you're trying to run it using Command Line or drop down terminal from the theme. It wants you to say yes by typing Y.

Try running this:

yes | theme-update.sh -no-restart

Even though technically it'll work fine, you will not see the colors but bunch of funny charters.

[49;1;34;182mPulling in latest changes for[0m [49;1;37;182mAuthentic Theme[0m (https://github.com/qooob/authentic-theme)...
Cloning into '/usr/libexec/webmin/.~authentic-theme'...
[49;32;5;82mUpdating to Authentic Theme 18.47-git-201705021416, done.[0m

"Actually, we can!..." That is one of the main reasons we have been sticking with Virtualmin, It's contributors, and community, they/you have always been there to help if we have hade any problems! And there has been just a few smaller and non critical hick-ups during our 12 years with Virtualmin Pro.

When will 18.48+ be available as a normal release? As I said, i got an error when trying command line update of theme "TERM environment variable not set", I don't know what it means... I'm no Linux guy :( And yes, I changed charset to unicode prior testing the FM, as I said in #21.

I'll try to confirm if JFM can do 1 in unicode.

// Leffe

Ilia's picture
Submitted by Ilia on Wed, 05/03/2017 - 12:34

You probably skipped my previous post, just run:

yes | theme-update.sh -no-restart

Ilia's picture
Submitted by Ilia on Wed, 05/03/2017 - 12:35

I'm sorry, I meant to say

yes | ./theme-update.sh -no-restart in case you are in authentic-theme directory

Hi again, I have now done the update on my local test server, I don't use git on our production server.

Webmin locale is set to unicode - English US (EN-UTF8).

It does not work all the way! If I upload a UNIX 1252 (ANSI - Latin 1) with Swedish characters they look fine viewing them in FM editor, but when I save the file and open it again it now says it's Windows-1255 and the characters are now even more messed up and unreadable. But... if I download the file directly from FM or Upload and Download I can see that the file actually still is UNIX 1252 (ANSI - Latin 1) with correct characters.

//Leffe

Ilia's picture
Submitted by Ilia on Thu, 05/04/2017 - 00:04

Can you upload the file your talking about, please?

Hi Ilia,

Actually you can use the testfile.txt already uploaded, or copy some swedish lang file and put that in a new php or txt file.

The FM has really strange behavior, if I use the already uploaded testfile, removes all the lines except the remark (3 lines) at the top and hit save it actually changes the encoding to UTF-8.

It seems like the FMs behavior on open after a edit and save depends on whats in the file?! Sometimes when I open a file again it can say it is 1251, or 1255 and displaying the wrong characters even that it still is 1252.

The FM behavior also varies of the combination between "Webmin/Webmin configuration/Language" and the "Webmin/Change language and theme" language settings.

Maybe its better for me to stick with the non unicode, JFM and the Framed theme as long as it's possible, because I really need to get the server in production. The things that worries me is not knowing the time frame until the Framed Theme (not that important) and JFM no longer work. Firefox has announced that version 52 ESR, that still supports java plugins will receive security updates for about a year longer (second quarter 2018). I really wold appreciate if I could get a timeline in Virtualmin Pro way towards dropping the framed themes and JFMs support.

I can still test things to see if the new FM finally can do the work with locale set to unicode.

Best regards, Leffe

Ilia's picture
Submitted by Ilia on Thu, 05/04/2017 - 05:43

You don't need to stick to old stuff!.!.?

I just finished better detection and added select to editor window, to select/change encodings on the fly.

I will update theme's repo it in 30 minutes, so please test.

It does magic in my opinion. It not only let's you preserve encoding, but also convert data safly and reliably.

When testing it, make sure to set Webmin to UTF-8. To double check that encoding is set right, just open source and search for data-charset and make sure that it's set to UTF-8.

Example screenshot for Encoding Select

ok... don't know what to say... ok, ill go step by step.

  1. Updated the theme to 18.47-git-201705041727 Patch 11

  2. Edited the two files, 564 and 547.

  3. Checked that locale us set to EN UTF-8 and restarted everything.

  4. Did a new php testfile with just a couple of lines and with swedish characters. I saved the file as ISO 8859-1 (Latin 1).

  5. Uploaded the file to server with FM, the file is now detected as 1252 (Latin 1) if I click it and open it directly with UltraEdit.

  6. I now open the file in FM editor, file is detected as cp1255 and all swedish characters are unreadable.

  7. Added a line with a few swedish characters and clicked save.

  8. I now click on it and open it directly with UltraEdit, still as 1252 (Latin 1) and the original text is readable but the line added before save is now unreadable.

  9. Did open the file in FM editor again, still detected as cp1255 and all lines are unreadable, added a new line and selected 1252(iso-8859-1) as encoding and clicked save.

  10. I now click on it and open it directly with UltraEdit, still as 1252 (Latin 1) and all text is now unreadable.

  11. Open the file in FM editor again, still detected as cp1255 and all lines are unreadable, added a new line and selected iso-8859-1(1252) as encoding and clicked save.

  12. Did open the file in FM editor again, now detected as UTF-8 and all lines are unreadable.

  13. I now click on it and open it directly with UltraEdit, still as 1252 (Latin 1) and all text is now unreadable, all swedish character is now question marks (?).

I have done this several times and the result is always the same, although the coding can be detected as 1251 instead of 1255 after save sometimes, it feels like it depends on what characters I add before save. I have only used a-z upper and lower, slash (/), and our swedish å ä ö Å Ä Ö.

Do you have any ideas? This is unfortunately time consuming for me and also for you, and I hope you know how much I appreciate your help and time!

regarding "You don't need to stick to old stuff", I have no problem moving forward in evolution ;) but I don't see it like that, I see it as "I need to stick with stuff working"!

Can you please check with Joe and/or Jamie about this "I really wold appreciate if I could get a timeline in Virtualmin Pro's way towards dropping the framed themes and JFMs support.", see post #34.

Thanks! //Leffe

Ilia's picture
Submitted by Ilia on Thu, 05/04/2017 - 13:57

I think you're making one mistake. The problem with testing files like that is that you must close/open it each time you change encoding. In other words, if you keep file.php opened in UltraEdit and edit it at the same time, using server, you would need to open/close it before its encoding is applied.

I can assure you, that it works properly with your Swedish file and my Atom editor. I also tested in other listers. All is saved and applied properly.

ISO-8859-1 practically equals to windows-1252.

The other possible problem, that I noticed, that Perl treats mentioned above encodings as the same. Please read this link.

When the file editor is opened is encoding detected correctly? Did you try opening/editings/saving/closing/opening again the say file? How do you mount your file systems? Are you sure it's not local problem? How do you upload/download a file? Maybe trying archiving it first could change anything? What browser version are you using? Probably browser detects your page's encoding incorrectly?

All we're talking about now is the reason why world is switching to unicode. If I were you, I would spent some time and made a script to batch-convert all of your files to utf-8. It's not that hard actually.

I don't know overall. I used your file and found many other files in different encodings. I played with them so much. I managed to convert all Russian encodings back and forth. Swedish didn't work that way, but converting to utf-8 and back was fine.

Jamie and Joe, I bet are testing it now and they will come back to us soon.

Let me know more after checking mentioned solutions above.

Ilia's picture
Submitted by Ilia on Thu, 05/04/2017 - 14:10

One more, I expect that you have packages installed:

For RHEL: perl-Encode-Detect For Debian: libencode-detect-perl

Do you have them installed?

Hi,

Yes of course, I download, open and close it each time, I actually close UltraEdit fully every time. I up and download both with FM and "Upload and Download" in "Others". I also has set my UltraEdit to auto detect encoding, and that has never failed before.

I'm working on a Windows 10 pro computers and my browser is Firefox 52.1.0 ESR, fully up to date. The file on the server that I open in FM and shows the wrong encoding and should not have anything to do with my desktop.

The strange thing is that its not consistent, have uploaded many different files, all have been checked that they are 1252/iso8859-1/Latin-1 prior upload, and the most of them got detected correctly but some got detected as UTF-8 by FM.

When do your latest updates and patches hit the official updates? Maybe the strange behavior is caused by our local linux test server in the office. If the updates do take a while to be official Ill set up a new CentOs 7 server here at the office with the same config as our production server.

There are a few more hurdles than just converting our code to unicode, and I will eventually get there. But in the mean time I must be sure that I still can edit and work online through Virtualmin/Webmin without braking thing during my work due to the coding thing. Hopefully the new FM can do the work eventually, but if the "non unicode" and JFM are removed before features hit the new FM, then I'm in real trouble! :( Therefore I'm very curious in when non unicode, and JFM are removed. And the features I'm referring to is the coding thing, that hopefully is fixed now (sorry for being suspicious, but I personally need to see that it working). and the other thing is upload files and archives that gets the right user on extract - you know what I mean, these are a must have for me.

I'll try to find out if the problems i'm seeing now is due to our local server.

Thanks Ilia! //Leffe

yes, it's installed. :)

Another thing... Jamie and Joe, I bet are testing it now and they will come back to us soon. Do you mean that they are about to remove non unicode or are they testing your work for release?

Ilia's picture
Submitted by Ilia on Thu, 05/04/2017 - 15:30

Wait, wait. My Atom fails all the time to autodetect encoding. Set it manually.

That was the whole point. To make sure that things work on the server and don't break anything. I made things shine to work on both my debug servers and production. I can't understand why it's not working on your side.

Try latest Chrome, please.

I don't know, you need to make sure that Webmin is reading new/patched files. I suppose you restarted it.

Tell me, when you open the file that you sent here, then edit it. Close it and open it again, does it look OK for you afterwards? What encoding is detected before safe and after?

Sure, I'll add those features, it's not that hard, just time consuming.

Ilia's picture
Submitted by Ilia on Thu, 05/04/2017 - 15:32

I don't feel that Jamie is going to do it right this time.

I normally has UltraEdit to locked encoding, I did set it to auto during testing.

No thanks, no Chrome for me!!! ;)

  • I Downloaded the testfile, did check it in UltraEdit, 1252 (Latin 1) and everything is ok!

  • Uploaded the file with FM, checked the file by click and open in UE, still 1252 and OK.

  • I now open file for edit in FM, iso-8859-1 (cp1252), everything OK, added a new comment beneath row 4 with swedish word Skål, it's cheers in english, save and closed editor.

  • Checked the file by click and open in UE, still 1252 and OK, even the new comment.

  • Open file for edit again in FM, still 1252 and OK. Deleted everything except the comment rows in top and php tags. Save and close the editor.

  • When I open the file it's detected by FM as UTF-8. the swedish character å is now a diamond wit a question mark. (but file still are 1252).

  • Now to the fun part, remove the swedish word Skål and replace it with äää and save it as a iso-8859-1 (cp1252) and close edit. Now open the file for edit again, it's now detected as 1255. Next change what wasäää to ååå and save it as a iso-8859-1 (cp1252) and close edit. When you open the file edit again, it's now detected as 1251. And of course, the swedish characters are not readable. And the detection has nothing to do with the browser.

But all the time the file actually are 1252 (Latin 1), it just crashes the swedish characters.

Can you please try this.

Ilia's picture
Submitted by Ilia on Fri, 05/05/2017 - 00:12

Good morning,

I will try that in a bit.

Thank you for detailed instructions.

Ilia's picture
Submitted by Ilia on Fri, 05/05/2017 - 02:39

I can confirm that the server fails to detect encoding properly with too little data in it. Saving function works correctly and file encoding is what we specify.

Example of a file where it fails:

<?php
//=========================================================================================
// This is a small part of a PHP-file encoded as Latin-1
// The Swedish characters are ok and also working against SMS service providers web service
//=========================================================================================
var $test = "Skål";

?>

I'll think what I can do. The best thought I have at the moment is to force encoding manually, re-reading file's content.

Hi, Thanks for confirming!

This actually happens on larger files to, seems to depends on its contents, I normally code swedish characters as &auml; and so on, but sometimes we have to use them "as is".

Actually, in my opinion the auto dectect seems unnecessary if we could be able to set preferred encoding in FM config. This would be fantastic, in that case FM encoding is not dependent on Webmins locale! :) I actually have missed this in JFM also! This is the reason I have used non unicode locale in Webmin! And also having you great feature to be able to change encoding on save is really nice!

Thanks again Ilia!

// Leffe

Ilia's picture
Submitted by Ilia on Fri, 05/05/2017 - 10:46

I'm actually finishing this. There will be both - autodetect and manualy selection. Both will be intelegent enough to make you happy. I'll come back to you with the fix to check in one hour. Doing final testing.

You are a star Ilia!!! :)

I would like to do a donation for your dedication and time and excellent work you do, how do I do that? I have don't have Yandex, Bitcoin or... hmmm maybe Paypal actually... I'll check!

Thanks!

Ilia's picture
Submitted by Ilia on Fri, 05/05/2017 - 11:34

:) Thank you, Blueforce.

Back to the commit and what has been done?

  1. File encoding is still guessed on the server;
  2. When file is opened with incorrectly detected encoding, the default will be set to UTF-8 (at first);
  3. When user changes encoding for files on which auto-detection failed, the script will remember user preference and on the next failed file, will enforce user's previous choice;
  4. Encoding can not be changed on edited files, thus a warning will be produced when such attempt happens, asking to save first;
  5. If by any chance, an edited file is going to have encoding that is not listed on the file-editor's select (probability of 0,01%), it will be prepended to it, so the actual file edit can be done correctly.

I think this is finally IT and the end of our problems with encodings and non unicode languages. (Which I believe can be removed now, or at least hidden)

It's checked @4b5a0d3741384272cacb36132a21b307358a9e17, please update

P.S. To convert a file from one encoding to another: a) copy readable and non-broken text to clipboard; 2. change file encoding to desired; 3. save file and then reopen it to see if encoding is working correctly on supplied text.

Wait...

Regarding 1 and 2, the decoding must be set prior opening the file, because if the autodetect fails and selects the wrong encoding all characters already are wrong in the edit window! If Before i can save in correct encoding I have to re-enter ALL wrong encoded characters in the whole file! The encoding really have to be set before opening a file.

//Leffe

Ilia's picture
Submitted by Ilia on Fri, 05/05/2017 - 11:53

Take a look and you will see you stay happy.

It's changes it on the fly by user request without need to close/open window or to save a file first to see applied encoding.

It's intelligent. ;)

Hehe... Sorry, I forgot to actually click on the selected encoding!!

I told you that you are a star! This is really nice! Excellent work!

I'll probably use both FM and JFM for a while, I'll try to get more comfortable with the new FM. But when editing and working on several files across many domains at the same time it's really much, much more work doing it the new FM compared to JFM.

I have another question though... In many places in the right frame, the window don't expand to the whole available area, for example when viewing log files.

//Leffe

Ilia's picture
Submitted by Ilia on Fri, 05/05/2017 - 12:47

You mean placing edit windows next to each other with different sizes?

Don't expand fully? Can you make a screenshot?

No sorry, my question regarding the window not using all space was not about FM, I was looking att "System/System Logs" just before I answered you and thought about why the View Logfile window not used all space available in the right frame.

//Leffe

Hi Ilia,

I just sent a small donation your way as a small appreciation for your excellent support, time and work - More are coming your way later on! :)

//Leffe

Ilia's picture
Submitted by Ilia on Sat, 05/06/2017 - 02:07

"System/System Logs" just before I answered you and thought about why the View Logfile window not used all space available in the right frame.

Ohh. I understand! Yes it would make more sense to have it with no borders even on large screens.

I will add this to 18.48 release today.

I'm not sure if we are talking about the same thing, I mean that the right window has a static size, it don't use the whole right frame. And that should actually apply to all right frames, not locking the window to a fixed size.

// Leffe

Ilia's picture
Submitted by Ilia on Sat, 05/06/2017 - 07:38

Can you install latest from GitHub and go to View Log? Is that what you're talking about?

Yes, right on the spot! Thanks! :)

// Leffe

Ilia's picture
Submitted by Ilia on Sat, 05/06/2017 - 07:49

In case you want this on all pages you can add the following to your theme extension (script.js):

setTimeout(function(){ 
$('.container-fluid.col-lg-10.col-lg-offset-1').removeClass('col-lg-10 col-lg-offset-1').addClass('margined-top-15')
}, 1);

Ok, nice, I'll try it later today. Thanks again!

Ilia's picture
Submitted by Ilia on Sat, 05/06/2017 - 08:11

Status: Needs work » Closed (fixed)
Ilia's picture
Submitted by Ilia on Sun, 05/07/2017 - 07:55

I've been thinking for root users for File Manager just provide ability to switch to certain users, where after doing so, all operations would run as such. For uploading, extracting, creating files and directories..

I don't like the idea of doing it for uploads or extracting archives ONLY.

Better, if you hit a button and descend into user1 shell. Then all that you run would be "marked" as this user.

What you think, guys?

Hi Ilia,

I don't like that solution, If I'm about to update code for 10 users/domain then I must switch user every time I do a upload. Why cant we have the function/setting that The Java File manager has "Default user for upload" or at least have the default user to be "Same as directory", but also the ability to change user on upload dialog. Maybe this should only be available for root user.

//Leffe

I have been thinking about it some more, in your solution, can you switch user from the FM, or is it done before you start it? and would it be easy to switch user?

Ilia's picture
Submitted by Ilia on Mon, 05/08/2017 - 01:35

It would be one click switch, right from File Manager, no reload/signin-signout would be required.

You choose it and any other (following) operations would be run as that user. All file's permissions would be set to that user.