Last modified: 2006-10-30 02:53:31 UTC
It is difficult to specify alternative namespaces when submitting new articles. It would be beneficial to have manual overrides of namespaces with a namespace=NNN in the index.php? arguments. Ideally, I imagine this would properly go in includes/Title.php:1408 /* private */ function secureAndSplit() { But would require access to $wgRequest by side-effect. The cleaner but lengthier alternative is changing: -includes/Title.php:165 function newFromURL( $url ) { +includes/Title.php:165 function newFromURL( $url, $namespace_override = null ) { global $wgLegalTitleChars; $t = new Title(); # For compatibility with old buggy URLs. "+" is usually not valid in titles, # but some URLs used it as a space replacement and they still come # from some external search tools. if ( strpos( $wgLegalTitleChars, '+' ) === false ) { $url = str_replace( '+', ' ', $url ); } $t->mDbkeyform = str_replace( ' ', '_', $url ); if( $t->secureAndSplit() ) { + if ($namespace_override) { $t->setNamespace($namespace_override); } return $t; } else { return NULL; } } + ## [TODO] assertions should be done to make sure this is a number. + # alternatively, if it isn't a number, check to see if it $wgContLang->getNsText($namespace) + # returns something valid. + function setNamespace( $namespace ) { + if ( is_int($namespace) ) { + $this->mNamespace = $namespace; + # TODO test: is this a valid namespace? if not, throw error + } else { + $this->mNamespace = $wgContLang->getNsText($namespace); + if (!$this->mNamespace) { + # TODO throw some canonical error? + } + } + } and then, change -includes/Wiki.php:79 $ret = Title::newFromURL( $title ); +includes/Wiki.php:79 $ret = Title::newFromURL( $title, $request->getVal('namespace') ); Thus a URL of: index.php?action=edit&title=New+article&create=Create+article&namespace=100 will give an article {100}:New_Article, where {100} is the name for namespace 100. This cleans up a lot of headaches. Sorry it's not in a patch.
Why can't you use the namespace name in the title parameter?
See an example of this problem's convoluted non-portable javascript as an alternative solution: http://meta.wikimedia.org/wiki/Help_talk:Inputbox#define_namespace_.28type.3Dcreate.29 The problem is, for e.g. Inputbox, a user types a title into a form element. They do not type into the box "Wikinews:Hello world", they type "Hello world", which goes to the wrong namespace (NS_MAIN, not Wikinews). They're orthogonal anyway, so there should be a diametric reference. title=Namespace:Title is a combined qualifier, useful as a convenience, but not for portability or mutability. Who knows what other advantages we are precluding, particularly in extensions, by not using good programming practices for this instance.
Inputbox could get an option added to automatically prefix an arbitrary string to the inputted text. That would be more useful in any case (e.g., automatically prefixing the string with "Wikipedia:Requests for adminship/"). Other applications could similarly specify the namespace. I thus don't see this as being worth the effort. Your patch, by the way, allows access to ?title=Wikipedia:_An_Awesome_Website&ns=0, which is a no-no. You need to handle that by referring to the namespace and interwiki prefix lists to see whether the combined ns:title is allowed, and then display an error message if it's not. I'm not going to make myself responsible for this in case I forgot some other corner case, so I won't volunteer to commit your patch, but maybe some other dev will.
How would one go about adding a prefix in inputbox? The $title variable is being typed in by the user in an HTML form element in a web browser, and there is no mechanism to prefix it with a namespace thereafter. [It's my understanding that the very impossibility of inputbox adding an ex ante prefix (i.e. extensions/inputbox.php), by definition requires orthogonal treatment of the currently codependent variables ex post (i.e. index.php et al.)] It certainly hasn't yet been resolved, in any case, but a solution you've suggested seems ideal, though other suggestions would be welcome. The more specific solution would still require changing index.php: index.php:15 $title = $wgRequest->getVal( 'title' ); +index.php:16 $title_prefix = $wgRequest->('title_prefix'); +index.php:17 if ($title_prefix) { $title = $title_prefix . $title; } This shouldn't change any access. and where it does change access it should be nonsensical. Alternatively, a wgHook for changing the title would be a more generic solution: index.php:15 $title = $wgRequest->getVal( 'title' ); +index.php:16 wfRunHooks( 'InitialQueryTitle', array(&$title) ); and users could do what they want to the title. This opens the door for quite a few interesting hooks that change the title based on some predetermined mechanism (picture canonizing dates). Yet it doesn't interfere with the mainstream code, aside from a little pollution of the hook namespace. I'm presuming that 'InitialQueryTitle' doesn't have to be initially referenced elsewhere; the other hooks appear to have single-instance references as well.
(In reply to comment #4) > How would one go about adding a prefix in inputbox? The $title variable is being > typed in by the user in an HTML form element in a web browser, and there is no > mechanism to prefix it with a namespace thereafter. [It's my understanding that > the very impossibility of inputbox adding an ex ante prefix (i.e. > extensions/inputbox.php), by definition requires orthogonal treatment of the > currently codependent variables ex post (i.e. index.php et al.)] I see. Yes, it would be difficult to get that to work, with the current state of HTML forms. You could, of course, construct some kind of complicated system that calls a special page which then looks up the form's entry in a special table in the database and figures out a URL to redirect to based on arbitrary parameters, but I see why you'd prefer to just have a dedicated GET parameter. Nevertheless, unless there are substantially more applications than a single extension, I'm not willing to do this myself. > It certainly > hasn't yet been resolved, in any case, but a solution you've suggested seems > ideal, though other suggestions would be welcome. I didn't resolve it, Brion Vibber (lead developer) did. Check "View Bug Activity" at the bottom of the page. He resolved it as INVALID, i.e., not a bug, not as FIXED.
Yes, I hate re-opening bugs. It usually means I've missed something important. :-) But in this case, I think there is a valid reason to consider addressing this. I can see a number of potentially benefits, such as variations of inputbox. I imagine wikinews or similarly contribution-heavy sites could benefit from having a variable namespace from an inputbox. As you say, the forms element workaround is complex. The wfHook() solution seems to be the most appropriate, with an intervening page as a less desirable alternative. I would simply add the hook to index.php on my own rather than go the intervening page route. It's a trivial change, for anyone who has a similar problem down the road, too.
