You need to log in before you can comment on or make changes to this bug.
All widgets that set a language resource ($this->mszLanguageResource =...) can only set it relative to the chameleon installation. Chameleon automatically appends a "/ms4w/apps/chameleon/htdocs/widgets/" (varies depending on installation) to the value specified by $this->mszLanguageResource. If a user creates their own widgets and decides to place them in a subdirectory in their application as opposed to the regular widget folder (which is possible by supplying an optional array of paths to the "$oApp->CWCExecute" command), then the language resource needs to be an absolute path.
this is definitely an issue that should be addressed for 1.99 beta. Any proposals on how to handle this would be appreciated.
Language files could be in the same dir as the widget code ? This bring an important point that should (in my opinion) be fixed really soon. "Directories structure of widgets". If widgets have to be self contain I think we should change the way directories are structured for widgets. For instance, language files are seperated from widget, and there's no easy way to guess where that directory reside. Also, some widget shouldn't be web visible, and some should. Not sure how to solve that.
updated version to 1.99
I think this is very important. I agree with Sacha that we should move the language resource files into the widget directories. Objections to unanimous consent???
Working on it
Ok. I've moved all .dbf language file to widget directory and changed the way Widgets are loading the language file ( $this->mszLanguageResource = dirname(__FILE__)."/widget.dbf";)
Ths fix required that all the popup widgets (and widgets that use extra windows) adjust the paths to the lanaguage files. i.e. $szLanguageResource = "../../data/language/LayerInfo.dbf"; $szCommonLanguageResource = "../../data/language/common.dbf"; became $szLanguageResource = "./LayerInfo.dbf"; $szCommonLanguageResource = "./common.dbf"; I searched for "../../data/language" and manually updated all the files found. This should cover all of them, but we will need to verify that we have them all.
I checked all file and some didn't have the change. Also I've moved the commonlaguage load for PHTML to session.inc.php. Also change all "./" path to __FILE__ and make sure the windows path is translated all \ to /. Oh, And I moved CWC2.dbf and common.dbf to /htdocs since they are mainly used by chameleon.php
The htdocs directory is only for HTML files and PHP scripts that need to be visible via the web, DBF files, data files and config files shouldn't be under htdocs without a very very very good reason. Oh... I see that this was suggested by Paul in comment #4 above, and I didn't "object to unanimous consent" at the time... so it may be too late to report the issue... um...
um ... it is a little late as the change has already been made. I understand the desire to expose the minimum number of files to the web from a security point of view. Is there a way that we can exclude files from being web accessible even if they are in a web-accessible directory?
In apache this can be done easily. Not sure about IIS.
I don't think we should complicate the install by requiring some file-based rules to be added to the server.
Paul, from the comments I am not sure it his has been fixed or if it created other issues. I am not even sure how to verify this bug. (Paul, or Zak? any thoughts?)
change target to beta 2 for verification
You can look at the widget directories to see that the resource (dbf) files have been moved into each widget rather than being maintained in a separate folder
Thanks, Paul. As mentioned above the data files can be found in the widget directories. verified using beta 2 2004-06-25.
