This Bugzilla instance is a read-only archive of historic NetBeans bug reports. To report a bug in NetBeans please follow the project's instructions for reporting issues.
1. running in ja locale on solaris or windows. 2. php project has multibyte in its name, which means also in its path to it since project name becomes a directory - and its legal in netbeans to have projects with mulitibyte in name and path. 3. regardless of if project encoding is utf-8 or for example, the encoding of the locale user is in, ie euc-jp for solaris or win31j for windows, when running the file or project, the browser does not find it and gives error message page ie 404 error, web page not found. a. for solaris and firefox, there are some known issues where some projects cannot be found due to having non ascii in the path to it - this might be one of them b. but for IE, the problem has not been seen with other projects, but is seen with php project, so the case of a. might be something that is fixable if fixed for windows. 4. this might be related to assumption of project encoding and feq or not. 5. even with web browser set to preferred language of ja, the problem is seen, but user should not need to set this value for this situation.
> 2. php project has multibyte in its name, which means also in its path to it since > project name becomes a directory That's true. > 3. regardless of if project encoding is utf-8 or for example, the encoding of the locale > user is in, ie euc-jp for solaris or win31j for windows, > when running the file or project, the browser does not find it and gives error message > page ie 404 error, web page not found. Not really - in fact there wouldn't have to be direct relation between the project name and its URL. The problem you are talking about can happen only in one case - if user creates his/her PHP project underneath Apache's document root. The problem (comparing to e.g. Web project) is that there's no way how to avoid using "dangerous" characters in pathname (in Web project we have context path) - for example if one creates PHP project in "C:\Apache\htdocs\<some-dangerous-characters>", there's no possibility to convert these characters because web server serves exactly what on the harddrive is (files & directories). So the URL then will be "http://localhost/<some-dangerous-characters>/". Solution for this scenario is pretty easy - create PHP project in e.g. "C:\<some-dangerous-characters>" and then copy source files to be visible to your web server (using new project wizard or project properties). Then only source files are copied, not the whole project directory. Of course, if one creates "<some-dangerous-characters>.php" file then there can be problems. But I wouldn't forbit user to do so (maybe just some warning in new PHP file wizard) and I definitely wouldn't forbid to create project with "dangerous" characters in its name (so I agree with you Ken, point 2.) From the description above, I can't see any issue here - of course, we can improve user experience by adding some warnings/hints. Any comments/opinions? Thanks.
No response for a long time, closing as INVALID (I can't see any issue here). Feel free to reopen and comment. Thanks.
yes I did not comment on it for long time; sorry about that. am reopening since in this case, if its expected that user might not be able to use characters of the locale they are running in or of the project they are doing, then seems that warnings and not allowing wizard to proceed are needed, since other nb projects do allow such characters to be used. I didn't think I originally created project under doc root, but not sure, since that is mentioned below as the one case the problem can happen; I will recheck with the new php soon. As to needing to move files to doc root after creation, as mentioned below, is that needed for other user experience using php modules ? But I think its valid to be reopened as to the user experience aspect of it and if not allowing non ascii or mbyte is solution, then the warnings and other things could be done to solve it. ken.frank@sun.com
So I suggest to add warning about "dangerous characters" in the name of file/project in the new PHP file/project wizard (for the project only if the project folder is known to be under the document root of a web server). Any comments/ideas/objections? Adding Leon to CC as well.
shouldn't target milestone be 6.5 M1 instead of 6.1M1 since 6.1 is past ? and about warning, should it prohibit the wizard from proceeding instead if the dangerous characters are used ? also, since from what I've read, php5.3 (I think thats correct version of what we are using for nb 6.5) does not have the full utf-8 support yet, what other kinds of restrictions on use of mbyte or other dangerous characters are there - ie in php files themselves, and any other place or path besides doc root already mentioned in this issue ? this will help us doing testing to focus on legal and logical cases in that context. ken.frank@sun.com
> and about warning, should it prohibit the wizard from proceeding instead > if the dangerous characters are used ? No, it is up to user to decide whether it is ok or not. > also, since from what I've read, php5.3 (I think thats correct version of what we > are using for nb 6.5) FYI PHP 5.3 is not released yet; NB focuses generally on PHP 5.x. > does not have the full utf-8 support yet, what other kinds > of restrictions on use of mbyte or other dangerous characters are there - ie in php files > themselves, and any other place or path besides doc root already mentioned in this issue ? > this will help us doing testing to focus on legal and logical cases in that context. No restrictions, missing UTF-8 support has impact only on PHP developers if they use e.g. 'strlen' function in their scripts (for such cases mb extension exists which provides several functions, 'mb_strlen' for example).
I'm not sure if it's necessary to create a warning for this use case, since most developers should know that these characters are not good to use in URLs. Can we address this in the documentation somehow (e.g. FAQ) instead?
> I'm not sure if it's necessary to create a warning for this use case, since most developers should know that these > characters are not good to use in URLs. Can we address this in the documentation somehow (e.g. FAQ) instead? +1 It is not related to PHP but to Web development in general - if you have e.g. "čřžý.html" or "čřžý.py" then you can have problems with displaying such pages in browser. And I don't think that we check this situation somewhere else in the IDE (I can be wrong of course). I suggest WONTFIX or INVALID. Any objections?
web app projects do allow mulitubyte or non ascii in project name or path. since context root is based on project name, they strip off the mbyte and replace with underscore characters. thats one reason had filed issue for php about this and had asked about warning vs prohibiting mbyte characters. also for web apps projects most other filetypes can have mbyte as part of name or path, but if for php if html or py files cannot, then can warning happen also ? I do realize restrictions on use of mbyte in other programming languages might need to happen compared to java - in nb ruby for example there are some restrictions based on some limitations of the ruby version being supported, for example. ken.frank@sun.com
lbarnard, I do think at least warning is needed since we have such warnings in the few places in nb where its not allowed for project names/paths and that nb users are used to it being allowed in most cases, and also that new developers to php or those trying it out might not know and since also it has such broader implications as to browser and/or web server where if encoding handling is not done ok, then the py or html pages can't be found -- thus seems at least a warning could help avoid the problem from starting. ken.frank@sun.com
Do we have any data from users indicating this is a real world problem that people get confused about?
dont have any reports from customers yet but wanting to be proactive based on past experiences where there have been such problems in other modules; we could look at web apps converting of non ascii in project name to underscores for context root name as one example of solving such a situation. I do think the warning and other documentation will be ok if decide not to disallow such naming, but do advocate at least for the warning. ken.frank@sun.com
OK, let's add this information to docs and warn user if "dangerous" URL can be created. That means: - for new PHP project wizard and project properties - just check URL and the name of index file, - for new PHP file wizard - check the name of the file. If there are no objections, I will implement it this week I hope.
> - for new PHP file wizard - check the name of the file. Very likely not doable.
Because of too many complications (see my last comment, ProjectCustomizer does not support warnings, only errors), changing TM.
*** Issue 127085 has been marked as a duplicate of this issue. ***
Integrated into 'main-golden', available in NB_Trunk_Production #278 build Changeset: http://hg.netbeans.org/main/rev/4455755e7fb2 User: Tomas Mysik <tmysik@netbeans.org> Log: Some changes for #127088: I18N - php project with multibyte name in it or path to it not run ok
what is the fix behavior ? I created php application with mbyte in path and in project name and also new php file and web page with same; but there is not a warning as is mentioned in below or in changeset notes. but also since this is still in reopened state, perhaps there is more of the fix coming ? am using recent 6.5 trunk builds. ken.frank@sun.com
> what is the fix behavior ? Fix? Where do you see any fix? > I created php application with mbyte in path and in project name > and also new php file and web page with same; but there is not a warning > as is mentioned in below or in changeset notes. Yes, see my comments in description nr. 15 and 16. > but also since this is still in reopened state, perhaps there is more of the fix > coming ? As I wrote, not easily doable, see my comment in description 16. Neither the common IDE new file wizard nor project customizer are prepared for such things and I'm strongly against some hacking or work arounding. I will probably file an issue (more likely issues) against Project UI API.
the reason I mentioned about a fix is that below it says: Integrated into 'main-golden', available in NB_Trunk_Production #278 build Changeset: http://hg.netbeans.org/main/rev/4455755e7fb2 User: Tomas Mysik <tmysik@netbeans.org> Log: Some changes for #127088: I18N - php project with multibyte name in it or path to it not run ok and the changeset seems to mention about warnings if use of non ascii. ken.frank@sun.com
Log says "Some changes for #127088" and that's true :) I just added method to detect printable ASCII characters but later I realized the problems I mentioned earlier.
Very like not doable for NB 6.5 because: > - for new PHP project wizard and project properties - just check URL and the name of index file, There's no possibility to add warning to the project properties (it supports only errors). > - for new PHP file wizard - check the name of the file. Problem already described earlier - there's no possibility to verify the name of the script "on the fly". Because of these issues which cannot be solved in PHP project, lowering priority to P3 and setting TM to future.
1. am raising proirity back to p2 - it does seem a p2 issue and think it better if it stays at p2 and be waived if needed. 2. you mention these things below - here are some comments/questions: >Very like not doable for NB 6.5 because: > - for new PHP project wizard and project properties - just check URL and the name of index file, question - who needs to check url and name of index file ? what does user need to do ? what are the situations when they need to do this ? >There's no possibility to add warning to the project properties (it supports only errors). comment - warnings would be to new project/file wizards, not to properties - this is done for some other projects, like ruby. can this be done for 6.5 in the wizard itself ? > - for new PHP file wizard - check the name of the file. >Problem already described earlier - there's no possibility to verify the name of the script "on the fly". 3. what is plan for documentation to explain about these limitations, esp if no warning to users in new project/file wizards ? I see it mentioned below about adding to docs and thus wanted to get more specifif info on that. ken.frank@sun.com
> 1. am raising proirity back to p2 - it does seem a p2 issue and think it better if it stays at p2 and be waived > if needed. Ken, I don't agree that it's "real" P2 - just because of missing warnings? Moreover, I don't think that any web (not only PHP) developer would ever use any non-ascii characters in file names or file paths - or have you ever seen such URL in real life? Probably not. Another thing is, that user is IMHO not blocked by this issue - he _always_ gets a message what is wrong (e.g. File not found in browser or web server log, both pretty easy to investigate). So that's why I don't agree with P2 priority. > - for new PHP project wizard and project properties - just check URL and the name of index file, > question - who needs to check url and name of index file ? what does user need to do ? what are the situations > when they need to do this ? Sorry, now I'm really confused, I really don't understand your questions - this whole issue is about "dangerous" characters in project URL - or not?? > comment - warnings would be to new project/file wizards, not to properties - this is done for some other projects, > like ruby. can this be done for 6.5 in the wizard itself ? For NB 6.5 only warning in new PHP project wizard (but not new file wizard) can be added. I filed issue #141884 and issue #141886 to be able to fix the other warnings. > 3. what is plan for documentation to explain about these limitations, esp if no warning to users > in new project/file wizards ? I see it mentioned below about adding to docs and thus wanted to get > more specifif info on that. I don't know exactly, I'm not a doc writer; I will contact them and let them know if they can add some kind of warning in the proper tutorials/articles.
Update from docs team (Barbara Mityashina): I have added your recommendation to the FAQ (http://wiki.netbeans.org/WhichEncodingDoIUseForNamingPHPSourceFilesAndFolders). I hope that my presentation has not changed the meaning. I will add this instruction to some of the tutorials, I just cannot decide right now which place is the best.
here is summary of comments from Tomas from some questions I had - these are about providing warnings to user if use non ascii: for new PHP project wizard and project properties - check project URL and the name of index file as it is part of URL (wizard is doable now, project properties not) - for new PHP file wizard - check the name of the file (not possible now) I think these solutions, combined with the additions to documentation which is mentioned below, will be sufficient and reasonable and is all that is needed. ken.frank@sun.com
Partially fixed - new PHP project wizard fixed. http://hg.netbeans.org/main?cmd=changeset;node=3f8dd44071ec
Integrated into 'main-golden', available in build *200807310201* on http://bits.netbeans.org/dev/nightly/ Changeset: http://hg.netbeans.org/main/rev/3f8dd44071ec User: Tomas Mysik <tmysik@netbeans.org> Log: #127088: I18N - php project with multibyte name in it or path to it not run ok (1/3) New PHP project wizard fixed.
According the mail from Masaki Katakai on nb-tech mailing list, changing priority to P3. ---------- %< ---------- Re: I18N bug priority guidelines - change proposal From: Masaki Katakai <Masaki.Katakai@sun.com> To: Jan Becicka <Jan.Becicka@sun.com>, nb-tech <nb-tech@sun.com> Date: Today 09:51:26 > As I'm working in globalization team and usually communicating > with many local users in Japan, I have the same feeling. > I think it's because there are cases when there are easy > workarounds and it's not realistic usage. > > For example, if there is a problem that happens when project > name is multibyte, but usually real users are using ascii as > project name, also there is an easy workaround so they do not > care about it. I know using just ascii in the project name is > not a painful at all in their development. Of course, > I understand such issue is a valid i18n issue from testing > point of view and I hope it will be fixed if possible, > but if other serious bugs are remaining, those serious bugs > should be fixed first. > > So, even if the bug is i18n issue, if the bug is about > functionality, I think the bug priority should be decided > very carefully so that development team can focus to the > real serious issues first. > > > All engineers in g11n team are working with local community > very closely, especially in Japan and China, so we can help > for gathering such realistic scenarios from real users. > > Regards, > Masaki
of course you can change proiority if you wish, but note that the poster of that mail does not speak for all users at all, and that they have made some incorrect statements and that we are in touch with their team to educate them about all of this. ken.frank@sun.com
No complains from our users => P4.
batch reassigning
Closing as FIXED since warning were added and there are no complains from our users.