your server host is definitely doing something..

changing encoding, shouldn't make a 500 error

it is possible your webhost may have upgraded and is possibly using suexec or something, in which case, if you have any htaccess with php_flags in, you will get an error 500.

there already is

language/<language>/theme.php or even global.php

having 2 language folders is counter productive.

the point is, there's already a language folder, so why create another new language folder?

if the point is to add custom language defines for themes, then create a custom language folder that is actually located in the language folder. that way you keep everything together..and a newbie doesn't have to scour through multiple directories in order to find a language define that he might want to change.. if they're all in 1 place, then all he needs to do is look in the logical place (the folder named languages)

why add language files to a theme? they aren't actually part of a theme, they are language files, that's what the language folder is for. so now you have 2 places where you upload languages? 2 places with class files, and so on. nice and confusing for the newbies. what next? 2 includes and 2 kernel folders aswell?

should do.. in the preferences, set the limit for post count, then they can't upload.. can't remember if it also has for viewing though.. but either way, it's pretty darn easy to add the capability to any module, it's only 2 or 3 lines of code max..

WFDownloads 3.2 has that ability, but i don't know of any other modules.

you can get it over at Smartfactory, but i'm not sure if it works with XOOPS 2.3.x

use CSS property max-width



altho some older browsers don't support it, firefox does, not sure about IE though. javascript was need to replicate it for IE.. although i have never tested with later versions of IE.

sorry someone, i know this question has been unanswered for a few days, and it really is a simple request which a core team developer could easily have answered.

but your method is not secure and not the best method. please don't take this the wrong way.

by altering uploader class like this, you are not just affecting the image uploader, but you are affecting any other module and core function that uses the uploader class.

random file names are there for a security reason because if your script allows executable files etc, and the path becomes known and the file is not stored outside of webroot, the filename would be known because a user has uploaded it. he can then gain complete access to the server by uploading a malicious script and then calling it from his browser.

if you want the image manager to not use a random prefix, then edit the image manager file directly not the uploader class.

in htdocs/imagemanager.php

around line 217:

remove this line >



now that will let the uploader class not set random prefix for image files, but will still allow other modules to have random prefixes should they want to use the setPrefix() function.


regards

vaughan