CMSimple_XH 1.6 RC

[svasti]

You may have already answered you own question in another thread:

Already a question. metaxx.php localizes only certain names of variables in the administration.
However we find ourselves with too many variables to be translated and without interest for those of the file language for example.

If I understand correctly, metaxx.php is a possibility, not a must. Only translate the variable names, where you think it will make things easier for your users. Don't translate metade.php into French, you have to create a metafr.php new. It can have different items as the German one.

I like it, because you can keep it small.

svasti

[bastingse]

My suggestion for 1.6 is that you can fill in backgroundcolor for the editor in the config.

[bastingse]

Right now i'm busy with re-write the dutch manual for cmsimple and i wonder if i should let it print already or better wait till version 1.6.
When will 1.6 be release???

[cmb]

My suggestion for 1.6 is that you can fill in backgroundcolor for the editor in the config.

Well, personally, I don't like config options to set CSS properties. IMHO it's better to do this styling in the template's stylesheet, if necessary. The following might already suffice:

Code: Select all

#xh_config_form .xh_field input,  #xh_config_form .xh_field select {
    background-color: red; /* or whatever color is desired */
}

When will 1.6 be release???

There is a pending issue related to the editor -- as soon as this is decided upon and implemented we will release 1.6. I'm hoping that we don't have to wait for the voting deadline, so we can release 1.6 next week.

[svasti]

Right now i'm busy with re-write the dutch manual for cmsimple and i wonder if i should let it print already or better wait till version 1.6.

even wachten, 1.6 is echt heel wat beter!

[bastingse]

Thanks folks, i think i'm gonna wait till 1.6 is born before i start re-write the small book in dutch.

[simpleSolutions.dk]

Hello Christoph

Sorry for the long response, but I was quite busy.

I looked at your source and as expected reads Filebrowser only the current folder information so there is no room for improvements in the most time-consuming part of the plugin. I did not get timeouts in some time so they could be coused by my provider. As I remember I have also moved some image folders from 2lang directory to userfiles/images folder so actually there were more images (and folders) in my cmsimple 1.6 version of the website than before.

Do you mean the filebrowser works fast when called from TinyMCE, but not when called from the admin menu?

Fortunately, there is no difference.

I have made some tests. 100 subfolders with 100 images

My image folder is a lot bigger than your test folder. But fortunately, most images are only used on 2lang site, a kind of archive of outdated information. This makes it reasonable to move unused images to 2lang folder. Those images are no longer available for Filebrowser (unless I make some hacks), but are still available for 2lang site. This solution is fine for my needs, and the only conclusion is that large number of imagess makes Filebrowser slow with the risk of timeouts and an efficient folder structure can be a part of the solution.

[cmb]

Hi Jerry,

I have made some tests. 100 subfolders with 100 images

My image folder is a lot bigger than your test folder.

Ah, I see. The built-in filebrowser is not suited for too many images; a solution might be to add a config option to disable the image tracking, and to restrict the subfolder traversal to a single level. However, I guess that most users don't have so many images.

an efficient folder structure can be a part of the solution.

At least a user may use this as workaround.

Christoph

[simpleSolutions.dk]

to add a config option to disable the image tracking, and to restrict the subfolder traversal to a single level

Filebrowser already only one folder at a time at each level , and it will reduce functionality not to track images, especially when there is a lot of pictures.

If somebody else runs into trouble there is nothing else to do than to either clean up the unused pictures, or to make a reasonable grouping of pictures in folders.

[cmb]

Filebrowser already only one folder at a time at each level

It seems to me that the filebrowser reads all entries in all subfolders recursively (Filebrowser_Controller::getFolders()).

it will reduce functionality not to track images, especially when there is a lot of pictures.

Seems reasonable.

I've put this issue on the roadmap to 1.6.1 to not further delay 1.6. After all, the current algorithm is the same as in 1.5.9, so there is no regression.