• Welcome to the Chevereto User Community!

    Here, users from all over the world come together to learn, share, and collaborate on everything related to Chevereto. It's a place to exchange ideas, ask questions, and help improve the software.

    Please keep in mind:

    • This community is user-driven. Always be polite and respectful to others.
    • Support development by purchasing a Chevereto license, which also gives you priority support.
    • Go further by joining the Community Subscription for even faster response times and to help sustain this space
  • Chevereto Support CLST

    Support response

    Support checklist

    • Got a Something went wrong message? Read this guide and provide the actual error. Do not skip this.
    • Confirm that the server meets the System Requirements
    • Check for any available Hotfix - your issue could be already reported/fixed
    • Read documentation - It will be required to Debug and understand Errors for a faster support response

Rename + multibyte causes Admin panel error

Status
Not open for further replies.
M

Majen

Chevereto Member
I just wanted to check something in the AdminPanel demo, but the thumbnails of the images are not loaded due to the following JavaScript error:

Code: 
Timestamp: 12-09-02 9:29:32 PM
Error: TypeError: value.image_name is null
Source File: http://demo.chevereto.com/admin/content/system/js/admin.js
Line: 558

The result is simular to the screenshot shown in http://chevereto.com/community/threads/admin-panel-pictures-wont-load.2783/. This thread was closed with "fixed it", but without any comment how it was fixed.

Is this error only a configuration error at the demo site or is it a bug?
 
Is a encoding problem and a backend problem. The encoding problem is because jQuery isn't handling the encoding because of this:
Code: 
arguments = "rename_name="+$li.find("input.rename").val();

Since that argument is entered in the $.ajax call like this:
Code: 
$.ajax({data: "action="+action+"&id="+fileID+"&"+arguments,

jQuery just shouts anything to the server, then the backend problem is that this string is valid, the ID gets populated with the name but the problem is that when jQuery parse the file list object it became null.

I will add this fix on 2.4
 
Ok, the problem is way more complex that what I though. It seems that PHP has issues with the rename function and multibyte characters. This means that in some systems (even in Linux) PHP doesn't understand rename("a.jpg", "á.jpg");. As you may guess... I can't tell until you rename a file if your system can or can't rename the file.

I will look around for a universal solution for this, at least what you can do if you have this issues.
 
The workaround for Unix systems is quite easy and it was a client error (js) because unix support multi-byte on the filenames so the fix was just tweak the ajax a little bit. Problem comes (as usual) with Windows systems, where the rename function doesn't work as expected when you rename a image (or any file).

On windows, when you do this (php):
PHP: 
rename("oldfile.ext", "néwfílé.ext");
The output is that the file gets named to néwfÃlé.ext (it seems that is not what you actually want in the name...)

Now, one of the suggested fix for this is actually rename the file with urlencode so the file has a valid filename (always) and when you fetch this file the URL will change to the decoded representation. Brilliant but in Windows this decoding makes that windows try to fetch néwfílé.ext instead of néwfÃlé.ext and since néwfílé.ext is just a representation the file isn't there. Is there for PHP or any backend script but the direct image url won't work which also means that the viewers don't work.

So, what's the deal? Simple: Windows systems will be always limited on this so we will just enable this full feature on Unix. If the system detects that you are in Windows and that you are issuing a multi-byte rename it will deny the rename. Some may say that the script should replace the multibytes... That is ok for languages like Spanish where "á" can be replaced by "a" but in the Chinese language or the Russian language we don't have a non multi-byte representation of their words, or for all their words.

PHP on Unix is able to rename oldfile.ext to néwfílé.ext but here comes the funny part: When you use any file related function like file_exists or getimagesize, in some enviroments, PHP can't find the néwfílé.ext even running on Unix, this is because unicode support in PHP is (for a lack of a better name) rubbish.

This fix will be bundled on 2.4 with all this considerations, this post is just to leave a record about the issue and the solution. Note that the function could be tweaked along if we can build a list of filesystems+workarounds.
 
Status
Not open for further replies.
Back
Top