MediaWiki Diskussion:Gadget-old-movepage.js

Fehler, falls Zielseite vorhanden

Hallo, soeben hatte ich den Fall, dass ich eine Seite verschieben wollte, wobei es die Zielseite schon gibt. Dadurch kommt ein erweitertes Formular zurück, in dem gefragt wird, ob die Zielseite gelöscht werden soll. Im simulierten alten Formular wird aber das Feld für den Zielseitenname mit dem Quellseitenname überschrieben statt dem bereits vorher eingegebenen Zielseitenname. Da ich darauf nicht geachtet habe, war bisher auch nicht nötig, ging die Verschiebung in die Hose: Alte Seite war gelöscht, aber keine neue angelegt. Kannst du das bitte mal prüfen? Danke. — Raymond ^Disk. 17:29, 19. Mär. 2012 (CET)

Nachvollziehbar. Ich habe es mal so geändert, das jetzt aus den Scroll-Down und dem input der Titel zusammengebaut wird. Das die Seite aber gelöscht wird, obwohl die Seitennamen gleich sind, hört sich aber auch nach einem Fehler an. Das müsstes du dir anschauen ;-) Der Umherirrende 18:33, 19. Mär. 2012 (CET)

erledigtErledigt – Der Umherirrende 11:26, 18. Mai 2012 (CEST)

mediawiki.special.movePage

Zu welchem Zweck wartet der Code auf mediawiki.special.movePage? Ich muss zugeben, dass ich gerade zu faul bin, nachzudenken, aber so auf Anhieb sehe ich eigentlich keinen Grund. Wenn man die Abhängigkeit entfernt, sollte das Gadget auch trotz -1-Bug funktionieren. --Schnark 09:29, 1. Mai 2012 (CEST)

Ich hatte das eingebaut, weil sonst der -1-Bug (im Opera) ausgelöst wurde, als Bug 35294 noch nicht gefixed war, so zumindestens meine Beobachtungen. Ich habe es mal entfernt. Vielleicht hilft es. Der Umherirrende 19:35, 2. Mai 2012 (CEST)

Der Fehler im FireFox ist jetzt bei mir weg (Opera hab ich gerade nicht), aber er ist nicht durch das Gadget entstanden. Dadurch das während der Ausführung von mediawiki.special.movePage ein Fehler auftrat wurde das abhängige Modul nicht ausgeführt, da jetzt die Abhängigkeit weg ist, wird das ausgeführt und der Fehler ist nur noch in der Fehlerkonsole sichtbar. Der Umherirrende 20:27, 2. Mai 2012 (CEST)

Krinkle hat den Grund in Bug 36310 gut erklärt. Seit 1.20 ist #wpReason eine Textarea und die darf kein maxlength haben, daher gibt $.prop -1 (als nicht definiert) zurück. Unter HTML5 sieht das ganze dann wohl anders aus. Der Umherirrende 18:25, 3. Mai 2012 (CEST)

Label

<label for="wpNewTitleMain">Ziel:</label>

zeigt weiterhin auf id="wpNewTitleMain". Entweder hier wird auch auf wpNewTitle umgestellt, oder das neue Einfabefeld heißt auch wpNewTitleMain bzw. es bleibt das gleiche Eingabefeld und nur der Inhalt wird geändert. --Fomafix (Diskussion) 13:24, 5. Mai 2012 (CEST)

Wenn man dem Eingabefeld den gleichen Namen gibt, dann wird wohl MediaWiki durcheinander kommen und du hast schöne Seitennamen mit zwei Namensräume. Geht nachfolgendes noch einfacher?

$( 'label[for="wpNewTitleMain"]' ).attr( 'for', 'wpNewTitle' );

Der Umherirrende 21:45, 6. Mai 2012 (CEST)

Müsste passen. --Fomafix (Diskussion) 22:10, 6. Mai 2012 (CEST)

Änderung scheint zu funktionieren. Der Umherirrende 16:54, 7. Mai 2012 (CEST)

erledigtErledigt – Der Umherirrende 16:54, 7. Mai 2012 (CEST)

Verschiebefunktion ohne Kommentierungsmöglichkeit

Siehe bitte Wikipedia:Fragen_zur_Wikipedia#Verschiebefunktion ohne Kommentierungsmöglichkeit. Viele Grüße --Saibo (Δ∇) 14:53, 9. Mai 2012 (CEST)

Es ist richtig, was man den Workaround auch in die Common.js schreiben kann, weil er auch die Opt-out-Benutzer betrifft, aber Common.js bedeutet, es wird auch für unangemeldete geladen, was unnötig wäre. Ansonsten sei gesagt, das die Kommentierungsmöglichkeit ohne das Helferlein auch kaputt ist. Es wird also nichts verschlimmert. Mit dem Workaround wollte ich nur versuchen, ob es dann wieder funktioniert. Falls es immer noch nicht funktioniert, bitte erst testen ob es ohne das Helferlein funktioniert, wenn ja, dann mit Browser melden, ansonsten ist es der MediaWiki Bug. Der Umherirrende 17:28, 9. Mai 2012 (CEST)

Jein. Ohne das Gadget geht die Kommentierungsmöglichkeit in Firefox 12. In Opera 11.6 ist sie kaputt. ;-) Viele Grüße --Saibo (Δ∇) 19:07, 9. Mai 2012 (CEST)

Ja, weil Opera ein maxlength mit -1 setzt, was sehr hinderlich bei der Eingabe ist. Aber mit Helferlein funktioniert es in beiden, oder? Das wäre das wichtige (von meiner Seite her). Der Umherirrende 20:09, 9. Mai 2012 (CEST)

Ja, wie in FZW geschrieben: mit Gadget geht es nun in FF 12 und Opera 11.6. Was anderes habe ich nicht zum Testen. --Saibo (Δ∇) 20:25, 9. Mai 2012 (CEST)

Im IE8 hat alles vom Anfang an (auch ohne Gadget) funktioniert. Der Umherirrende 20:39, 9. Mai 2012 (CEST)

erledigtErledigt – Saibo (Δ∇) 20:25, 9. Mai 2012 (CEST)

Fehlerhaftes Verhalten bei Verwendung der Zurückfunktion in Opera

Opera 11.6. Passiert so nicht in Firefox 12.

1. Mit aktiviertem Gadget https://de.wikipedia.org/wiki/Spezial:Verschieben/Benutzer:Saibo aufrufen
2. Irgendeinen Link (beispielsweise Benutzer:Saibo) dort anklicken
3. Zurück (Browserbutton) gehen

• Falsches Resultat: Benutzer:Benutzer:Saibo
• Korrekt wäre: Benutzer:Saibo

Dies lässt sich auch wiederholen: Nach vier mal vor und zurück steht dann Benutzer:Benutzer:Benutzer:Benutzer:Benutzer:Saibo im Feld. Wollte es nur angemerkt haben - falls dieses Gadget dauerhaft bestehen soll und nicht in MediaWiki die Dropdown-Box entfernt wird, dann wäre es vielleicht schön, wenn das vermeidbar wäre. Mir ist es aber egal. --Saibo (Δ∇) 19:33, 9. Mai 2012 (CEST)

Kann ich gerade nicht nachvollziehen, habe hier Opera 11.62. Dürfte auch eigentlich nicht passieren/Ich kann es mir gerade nicht vorstellen, da kein Feld der ursprünglichen Maske verändert wird, sondern ein neues Feld mit dem Inhalt der ursprünglichen Maske gebaut wird. Der Umherirrende 20:05, 9. Mai 2012 (CEST)

Komisch. Meine ist 11.61 mit Pinguinbetriebssystem. Habe es gerade nochmal wie oben beschreiben mit selbigem Ergebnis getestet. --Saibo (Δ∇) 20:34, 9. Mai 2012 (CEST)

Ich habe Windows XP. Vielleicht ließt noch jemand mit, der sich da besser auskennt. Der Umherirrende 20:38, 9. Mai 2012 (CEST)

Chrome und Feld Grund

Laut WP:FzW#Bug (?) beim Verschieben führt das Gadget dazu, das man im Chrome keine Eingabe mehr im Feld "Grund" machen kann. Hat jemand eine Idee, das man Opera repariert, aber Chrome nicht stört? Der Umherirrende 19:43, 22. Mai 2012 (CEST)

Danke für den Fix. Ich glaube, ich hatte mich für .removeProp entschieden, weil MediaWiki in jquery.bytelimit auch .prop verwendet. Vermutlich legt Chrome das richtig aus und man müsste jquery.bytelimit noch ändern, keine Ahnung. Der Umherirrende 17:54, 23. Mai 2012 (CEST)

erledigtErledigt – Der Umherirrende 17:54, 23. Mai 2012 (CEST)

Gadget funktioniert nicht

Das Gadget funktioniert derzeit nicht. Ich habe unter phab:T162667 und phab:T162663 zwei Tickets aufgemacht. --Fomafix (Diskussion) 13:55, 11. Apr. 2017 (CEST)

phab:T162667 ist ein Fehler in MediaWiki. Die verursachende Quellcodeänderung habe ich im Ticket verlinkt.

phab:T162663 ist ein lokales Problem, das durch das Gadget entsteht. Es wird das Modul mediawiki.special.movePage geladen, obwohl die Elemente nicht vorhanden sind. Ich habe hier den Code überarbeitet:

/* This scripts replaced the new scrolldown/input field ([[rev:110209]]) on the movepage with the old one */

( function ( $, mw ) {
	if ( mw.config.get( 'wgCanonicalSpecialPageName' ) !== 'Movepage' ) {
		return;
	}
	$( function () {
		var wpNewTitleMain = $( '#wpNewTitleMain input' );
		var wpNewTitleNs = $( '#wpNewTitleNs select' );
		if ( !wpNewTitleMain.length || !wpNewTitleNs.length ) {
			return;
		}
		mw.loader.using( 'mediawiki.special.movePage' )
		.done( function () {
			// build the title from the scrolldown
			var namespaceText = mw.config.get( 'wgFormattedNamespaces' )[ wpNewTitleNs.val() ];
			var titleText = wpNewTitleMain.val();
			var preloadTitle = namespaceText !== '' ? namespaceText + ':' + titleText : titleText;
			var input = $( '<input name="wpNewTitle" size="60" type="text" id="wpNewTitle" />' );
			input.val( preloadTitle ); // preload input with a title
			input.get( 0 ).attributes = wpNewTitleMain.get( 0 ).attributes; // DOM copy of attributes
			wpNewTitleMain.replaceWith( input ); // replace the new input with the old
			wpNewTitleNs.parent().remove(); // the scroll down box
			$( '#new-movepage-hint' ).remove(); // remove hint to new function in [[MediaWiki:Movepagetext-noredirectfixer]]
			$( 'label[for="wpNewTitleMain"]' ).attr( 'for', 'wpNewTitle' ); // correct label for to new input
		} );
	} );
}( jQuery, mediaWiki ) );

Bitte diese Version übernehmen. --Fomafix (Diskussion) 18:50, 11. Apr. 2017 (CEST)

phab:T162667 ist behoben und per Hotfix sofort deployt worden. Das Gadget funktioniert nun auch wieder.

phab:T162663 wird durch das Gadget verursacht und ist kein Fehler in MediaWiki. Daher habe ich das Ticket geschlossen. Der oben aufgeführte Code behebt dieses Problem im Gadget. --Fomafix (Diskussion) 10:47, 13. Apr. 2017 (CEST)

Auch bei der Submit-Seite tritt der Fehler Error: Widget not found: wpNewTitle in der JavaScript-Konsole auf, wie bei phab:T162663. Aus das müsste der obige Code beheben, da das Modul nur geladen wird, wenn die Elemente auch vorhanden sind. --Fomafix (Diskussion) 10:32, 24. Apr. 2017 (CEST)

erledigtErledigt Ist korrigiert. Der Umherirrende 21:15, 1. Mai 2017 (CEST)

Hmm, es ist nun wohl ein Race Condition entstanden, denn es kommt ab und zu mal TypeError: item is undefined beim laden. Vermutlich muss die jQuery-Selektion innerhalb des asynchronen using-Blocks erneut ausgeführt werden. --Fomafix (Diskussion) 21:59, 1. Mai 2017 (CEST)

Bei mir sieht es so aus, das es in OOUI passiert, da das Menü schneller weg ist, als OOUI fertig ist mit seiner Initialisierung (passiert in onMenuSelect - getData on undefined). Habe aber keine Idee, auf was man hier noch warten sollte, da mw.loader ja vermutlich fertig meldet, sobald alles angestoßen ist, aber OOUI länger braucht. Oder hilft 'mediawiki.widgets' hier? Aber sollten die Callbacks nicht erst angestoßen werden, wenn die Childs des angeforderten Modules auch fertig sind? Bekommt mw.loader überhaupt mit, das die Callbacks durch sind? Der Umherirrende 20:35, 2. Mai 2017 (CEST)

In einer zunehmend asynchronen JavaScript-Welt ist mw.loader.using nicht ausreichend. Es stellt nur sicher, dass das Modul mit allen Abhängigkeiten geladen ist, aber nicht, dass alle asynchronen Aktionen abgeschlossen sind. Ich kenne mich mit OOjs UI nicht aus, aber ich erwarte, dass es da bessere Möglichkeiten gibt. --Fomafix (Diskussion) 21:02, 2. Mai 2017 (CEST)

Ich vermute, dass ein explizites OO.ui.infuse( 'wpNewTitle' ); am Anfang das Problem behebt. Wenn ein Widget einmal infusioniert ist, dann erzeugt ein weiteres Infusionieren des gleichen Namens keine weitere Analyse des DOM-Baum mehr durch. Folgender Code müsste daher keine Probleme mehr verursachen:

/* This scripts replaced the new scrolldown/input field ([[rev:110209]]) on the movepage with the old one */

( function ( $, mw ) {
	if ( mw.config.get( 'wgCanonicalSpecialPageName' ) !== 'Movepage' ) {
		return;
	}
	$( function () {
		if ( !$( '#wpNewTitle' ).length ) {
			return;
		}
		mw.loader.using( 'mediawiki.widgets' )
		.done( function () {
			OO.ui.infuse( 'wpNewTitle' ); // Make sure that the widget is already infused before changing
			var wpNewTitleMain = $( '#wpNewTitleMain input' );
			var wpNewTitleNs = $( '#wpNewTitleNs select' );
			if ( !wpNewTitleMain.length || !wpNewTitleNs.length ) {
				return;
			}
			// build the title from the scrolldown
			var namespaceText = mw.config.get( 'wgFormattedNamespaces' )[ wpNewTitleNs.val() ];
			var titleText = wpNewTitleMain.val();
			var preloadTitle = namespaceText !== '' ? namespaceText + ':' + titleText : titleText;
			var input = $( '<input name="wpNewTitle" size="60" type="text" id="wpNewTitle" />' );
			input.val( preloadTitle ); // preload input with a title
			input.get( 0 ).attributes = wpNewTitleMain.get( 0 ).attributes; // DOM copy of attributes
			wpNewTitleMain.replaceWith( input ); // replace the new input with the old
			wpNewTitleNs.parent().remove(); // the scroll down box
			$( '#new-movepage-hint' ).remove(); // remove hint to new function in [[MediaWiki:Movepagetext-noredirectfixer]]
			$( 'label[for="wpNewTitleMain"]' ).attr( 'for', 'wpNewTitle' ); // correct label for to new input
		} );
	} );
}( jQuery, mediaWiki ) );

--Fomafix (Diskussion) 16:51, 3. Mai 2017 (CEST)

Habe das infuse noch nicht außerhalb von offiziellen JavaScript gesehen, aber mal eingebaut. Ganz wohl ist mir dabei nicht, aber ich kann den Fehler aktuell nicht mehr provozieren. Der Umherirrende 19:03, 4. Mai 2017 (CEST)

Gadget funktioniert nicht (Juli 2019)

Hallo, das Gadget scheint mit der aktuellen MediaWiki-Version nicht mehr zu funktionieren. @Umherirrender, Fomafix: könnt ihr Abhilfe schaffen? Gruß, -- hgzh 12:08, 26. Jul. 2019 (CEST)

Das Modul mediawiki.special.movePage wurde in gerrit:517109 mit anderen JavaScript-Dateien zum neuen Modul mediawiki.misc-authed-ooui zusammengelegt. Im Gadget muss das entsprechend angepasst werden. --Fomafix (Diskussion) 16:41, 26. Jul. 2019 (CEST)

Also reicht eine einfache Ersetzung des zu ladenden Moduls? -- hgzh 20:41, 26. Jul. 2019 (CEST)

Ja, das sollte reichen. Die Darstellung könnte noch etwas aufgehübscht bzw. angepasst werden. --Fomafix (Diskussion) 22:52, 26. Jul. 2019 (CEST)

Danke, habe an der entsprechenden Stelle eine Korrekturanfrage gestellt. -- hgzh 12:39, 27. Jul. 2019 (CEST)