Specify namespace in args to index.php
Closed, InvalidPublic
Actions

Assigned To

None

Authored By

	• bzimport
	Oct 26 2006, 6:02 PM

Description

Author: bnospam

Description:
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.

Version: unspecified
Severity: enhancement

Details

Reference: bz7718

Event Timeline

• bzimport raised the priority of this task from to Medium.Nov 21 2014, 9:22 PM

• bzimport added a project: MediaWiki-Page-editing.

• bzimport set Reference to bz7718.

• bzimport added a subscriber: Unknown Object (MLST).

• bzimport created this task.Oct 26 2006, 6:02 PM

ayg wrote:

Why can't you use the namespace name in the title parameter?

bnospam wrote:

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.

ayg wrote:

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.

bnospam wrote:

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.

ayg wrote:

(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.

bnospam wrote:

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.

Specify namespace in args to index.phpClosed, InvalidPublicActions

Description

Details

Event Timeline

Specify namespace in args to index.php
Closed, InvalidPublic
Actions