File browser responses when wrong _FileBrowserLanguage is set and some general thoughts

[Wiktor Walc]

I know that people should read docs etc. but let's see how some of users test software before actually deciding about using it. They download file, unpack, then see _samples dir and simply run examples. Since there is no README in _samples dir, it's not obvious that to run examples divieded into separate dirs for each language, user must do some additional config changes (that's how examples usually work).

So, because we can't split FCKeditor into separate distibutions for each server language (which would give us real statistics of using each distribution btw.) I think it's important to give at least the most appropiate and descriptive error responses to the user to that specific error (and generally everywhere).

Very good example is problem with wrong _FileBrowserLanguage and _QuickUploadLanguage. In error message we are displaying contents of a whole file and "The server didn't send back a proper XML response." (see #227) - it says nothing to the user and it's not so easy to close that message on a small screen.

I suppose that some people wouldn't consider it as a configuration error but as a shortcoming and would be wondering whether they encounter more strange problems in the future.

My suggestion is that we could add in each connector.ext file some special tag in a comment section e.g.

do not remove this line: #FCK_WRONG_LANGUAGE_ASP#

And then if XML response is wrong, we could check before displaying error message whether such special tag exists and display more friendly information, for example:

Your server didn't execute ASP file. 
Please check whether ASP is available or change your default server language in fckconfig.js (...) 
You can find more information here:...

[Alfonso Martínez de Lizarrondo]

That looks like an interesting idea, it's easy to implement and it can give a more detailed message than showing the full page in those cases.

There are other details about how to improve the experience of first use:

1. The server implementations could take care to redefine the connector language automatically. This is delicate because people might find that the settings in fckconfig aren't used, but maybe we could remove (leave them commented with an explanation) the settings from that file. After all to use the connectors they will have to use a server language, so we could assume that the server implementation will take care to set the path to the file browser.

2. The _documentation file could include some basic links, like _samples/default and a few steps: What's FCKeditor, Installation, Configuration, Advanced reading (all links to the respective sections on the Wiki). Maybe rename it to Readme.html ?

3. Move the _upgrade.html info (link) to _documentation

4. Remark in _documentation the importance of reading What's new, (we can just link it).

5. With those changes, after opening the Readme.html the user can move through all the documentation and the samples.

6. Review the Wiki documentation from the point of view of a new user. There are some request about this like providing a full document in the package instead of using only the wiki.

7. Add some explanation in the server samples about the need to configure the connector (and a link to the wiki)

[Wiktor Walc]

FCKeditor is no longer actively maintained, the file browser is not distributed with V3/V4.