mw-lifecycle-analysis/091625_human_conversation_sample.csv at bb67fea96b3db77b91ba0a308c2993a33ac4a79d

mgaughan bb67fea96b hopefully last update to human sampling

2025-09-16 12:16:10 -05:00

142 KiB

Raw Blame History

1	id	task_title	comment_text	comment_type	TaskPHID	cleaned_sentences
2	53531	Visual Editor: Adding text after a link includes that text in the link	If you place the cursor after the last character of a link and start typing then your text becomes part of the displayed text for that link: [[Fish]] → [[Fish\|Fish and chips]] rather than the inte.nded [[Fish]] and chips or [[Fish and chips]] which would be expected from a WYSIWYG editor (even if it isn't what is wanted). There is no way to edit part of a link at all, the only way around it is to unlink the whole phrase and relink the part you want linked. This is not usually a problem, as you can work around by starting from after the space after the link. However, this is counter intuitive if you want to add punctuation after the link (add it after the space, delete the space, add space after the punctuation). It also means it is impossible to add unlinked text when the link ends the line, as happens often on disambiguation pages. For example try adding context to the links at Mandi#People. Apparently a workaround is to insert a line break, add the text and then delete the line break. I've not tested this myself though It is possible this is the same as bug 50945 but I don't think it is. -------------------------- Version: unspecified Severity: normal	task_description	PHID-TASK-jo6lx3im2dnf4fgrh2cy	["Visual Editor: Adding text after a link includes that text in the link\n\nIf you place the cursor after the last character of a link and start typing then your text becomes part of the displayed text for that link: [[Fish]] → [[Fish\|Fish and chips]] rather than the inte.nded [[Fish]] and chips or [[Fish and chips]] which would be expected from a WYSIWYG editor (even if it isn't what is wanted).", 'There is no way to edit part of a link at all, the only way around it is to unlink the whole phrase and relink the part you want linked.', 'This is not usually a problem, as you can work around by starting from after the space after the link.', 'However, this is counter intuitive if you want to add punctuation after the link (add it after the space, delete the space, add space after the punctuation).', 'It also means it is impossible to add unlinked text when the link ends the line, as happens often on disambiguation pages.', 'For example try adding context to the links at Mandi#People.', 'Apparently a workaround is to insert a line break, add the text and then delete the line break.', "I've not tested this myself though\n\nIt is possible this is the same as bug 50945 but I don't think it is.", '--------------------------\nVersion: unspecified\nSeverity: normal']
3	253720	Visual Editor: Adding text after a link includes that text in the link	This is actually the same as bug 51463 which we just fixed and are deploying now. Sorry for the inconvenience. * This bug has been marked as a duplicate of bug 51463 *	task_subcomment	PHID-TASK-jo6lx3im2dnf4fgrh2cy	['This is actually the same as bug 51463 which we just fixed and are deploying now.', 'Sorry for the inconvenience.', '* This bug has been marked as a duplicate of bug 51463 *']
4	253712	Visual Editor: Adding text after a link includes that text in the link	JohnCD67 wrote: This is quite a serious problem because a user who tries to set up a link at the right hand end of a line, i.e. without having first typed at least one space beyond it, becomes trapped in a mode where all further typing goes inside the link, and there is no easy way out. I think this is what is causing peculiar links, e.g. a link to "Chendo" piped to "Chendo, " and one to "Manolo Sanchís" piped to "Manolo Sanchís and ". See report at [[:en:WP:VisualEditor/Feedback#You have to type something after a word before attempting to wikilink it]]	task_subcomment	PHID-TASK-jo6lx3im2dnf4fgrh2cy	['JohnCD67 wrote:\n\nThis is quite a serious problem because a user who tries to set up a link at the right hand end of a line, i.e.', 'without having first typed at least one space beyond it, becomes trapped in a mode where all further typing goes inside the link, and there is no easy way out.', 'I think this is what is causing peculiar links, e.g.', 'a link to "Chendo" piped to "Chendo, " and one to "Manolo Sanchís" piped to "Manolo Sanchís and ".', 'See report at\n\n[[:en:WP:VisualEditor/Feedback#You have to type something after a word before attempting to wikilink it]]']
5	53341	VisualEditor: double-clicking "create reference" generates a quasi-broken ref form.	Screenshot If you double-click "create reference", having clicked "insert new reference", it generates...well, see the screenshot. Even when the window is closed, this persists for all subsequent loadings of the references tool on that page. Windows 7, Firefox 22. -------------------------- Version: unspecified Severity: normal Attached: {F11430}	task_description	PHID-TASK-vlaiyo2akniolmqe5tq6	['VisualEditor: double-clicking "create reference" generates a quasi-broken ref form.', 'Screenshot\n\nIf you double-click "create reference", having clicked "insert new reference", it generates...well, see the screenshot.', 'Even when the window is closed, this persists for all subsequent loadings of the references tool on that page.', 'Windows 7, Firefox 22.', '--------------------------\nVersion: unspecified\nSeverity: normal\n\nAttached: {F11430}']
6	242434	VisualEditor: double-clicking "create reference" generates a quasi-broken ref form.	This has been fixed since July; sorry for slow update.	task_subcomment	PHID-TASK-vlaiyo2akniolmqe5tq6	['This has been fixed since July; sorry for slow update.']
7	51701	Edit with VisualEditor duplicates content with subst'd version of the content	A user reported this edit <https://pt.wikipedia.org/w/index.php?title=CMM_-_Canal_Meninos_e_Meninas&diff=36129698&oldid=36129686>, where he just meant to delete a sentence. However the content was duplicated and templates were substituted in this duplicated version. -------------------------- Version: unspecified Severity: normal	task_description	PHID-TASK-amav3irppf34v275xo4q	["Edit with VisualEditor duplicates content with subst'd version of the content\n\nA user reported this edit\n<URL where he just meant to delete a sentence.", 'However the content was duplicated and templates were substituted in this duplicated version.', '--------------------------\nVersion: unspecified\nSeverity: normal']
8	245092	Edit with VisualEditor duplicates content with subst'd version of the content	[Parsoid component reorg by merging JS/General and General. See bug 50685 for more information. Filter bugmail on this comment. parsoidreorg20130704]	task_subcomment	PHID-TASK-amav3irppf34v275xo4q	['[Parsoid component reorg by merging JS/General and General.', 'See bug 50685 for more information.', 'Filter bugmail on this comment.', 'parsoidreorg20130704]']
9	245089	Edit with VisualEditor duplicates content with subst'd version of the content	This is now fixed in production - really sorry about this bug. If it happens again, please re-open this.	task_subcomment	PHID-TASK-amav3irppf34v275xo4q	['This is now fixed in production - really sorry about this bug.', 'If it happens again, please re-open this.']
10	55050	VisualEditor: Expose build number	Quite often we get bug reports for issues that have been recently fixed but not deployed to the smaller wikis. It would be very useful if we had build numbers that we could access (e.g. ve.version) in the client so we could tell quickly how out of date the deployed code is before we waste time debugging an issue someone else has already fixed. -------------------------- Version: unspecified Severity: enhancement	task_description	PHID-TASK-p4b2w3x4lqa7c5xyypgv	['VisualEditor: Expose build number\n\nQuite often we get bug reports for issues that have been recently fixed but not deployed to the smaller wikis.', 'It would be very useful if we had build numbers that we could access (e.g.', 've.version) in the client so we could tell quickly how out of date the deployed code is before we waste time debugging an issue someone else has already fixed.', '--------------------------\nVersion: unspecified\nSeverity: enhancement']
11	569455	VisualEditor: Expose build number	FYI - This might be removed in {T119750}	task_subcomment	PHID-TASK-p4b2w3x4lqa7c5xyypgv	['FYI - This might be removed in {T119750}']
12	245454	VisualEditor: Expose build number	Change 84334 merged by jenkins-bot: Hide version info if not available https://gerrit.wikimedia.org/r/84334	task_subcomment	PHID-TASK-p4b2w3x4lqa7c5xyypgv	['Change 84334 merged by jenkins-bot:\nHide version info if not available\n\nGERRIT_URL']
13	245447	VisualEditor: Expose build number	Change 84334 had a related patch set uploaded by Esanders: Hide version info if not available https://gerrit.wikimedia.org/r/84334	task_subcomment	PHID-TASK-p4b2w3x4lqa7c5xyypgv	['Change 84334 had a related patch set uploaded by Esanders:\nHide version info if not available\n\nGERRIT_URL']
14	245440	VisualEditor: Expose build number	Yes, there's an issue with our deployment process which prevents it from working ATM. We're working on a fix.	task_subcomment	PHID-TASK-p4b2w3x4lqa7c5xyypgv	["Yes, there's an issue with our deployment process which prevents it from working ATM.", "We're working on a fix."]
15	245433	VisualEditor: Expose build number	This isn't working. When I click on "Beta" to see this, it says "Version false", with a link to https://en.wikipedia.org/w/false (from userspace) or https://en.wikipedia.org/wiki/false (from article space).	task_subcomment	PHID-TASK-p4b2w3x4lqa7c5xyypgv	["This isn't working.", 'When I click on "Beta" to see this, it says "Version false", with a link to URL (from userspace) or URL (from article space).']
16	245427	VisualEditor: Expose build number	Change 81877 merged by jenkins-bot: Expose version information in the client https://gerrit.wikimedia.org/r/81877	task_subcomment	PHID-TASK-p4b2w3x4lqa7c5xyypgv	['Change 81877 merged by jenkins-bot:\nExpose version information in the client\n\nGERRIT_URL']
17	245419	VisualEditor: Expose build number	Change 81877 had a related patch set uploaded by Esanders: Expose version information in the client https://gerrit.wikimedia.org/r/81877	task_subcomment	PHID-TASK-p4b2w3x4lqa7c5xyypgv	['Change 81877 had a related patch set uploaded by Esanders:\nExpose version information in the client\n\nGERRIT_URL']
18	53828	VisualEditor: Autocompletion for template names doesn't work in RTL	Given that I'm editing an article in an RTL wiki: https://he.wikipedia.org/wiki/ASCII And I press the "Transclude" button in the toolbar (puzzle piece) And I type "A" Then I should see a list of autocompletions of templates that start with A Currently I don't see a list of autocompletions. This bug is quite similar to Bug 51490. [This was an experiment with writing bug reports as Cucumber-style test scenarios. Let me know if you don't like it.] -------------------------- Version: unspecified Severity: normal	task_description	PHID-TASK-lui5vpla74335t6r63nr	['VisualEditor: Autocompletion for template names doesn\'t work in RTL\n\nGiven that I\'m editing an article in an RTL wiki: URL\n And I press the "Transclude" button in the toolbar (puzzle piece)\n And I type "A"\nThen I should see a list of autocompletions of templates that start with A\n\nCurrently I don\'t see a list of autocompletions.', 'This bug is quite similar to Bug 51490.', '[This was an experiment with writing bug reports as Cucumber-style test scenarios.', "Let me know if you don't like it.]", '--------------------------\nVersion: unspecified\nSeverity: normal']
19	246135	VisualEditor: Autocompletion for template names doesn't work in RTL	Done and will be deployed tomorrow. Thanks, Moriel!	task_subcomment	PHID-TASK-lui5vpla74335t6r63nr	['Done and will be deployed tomorrow.', 'Thanks, Moriel!']
20	246130	VisualEditor: Autocompletion for template names doesn't work in RTL	This bug will be fixed with this patchset: https://gerrit.wikimedia.org/r/#/c/74835/ See also https://bugzilla.wikimedia.org/show_bug.cgi?id=51490	task_subcomment	PHID-TASK-lui5vpla74335t6r63nr	['This bug will be fixed with this patchset: URL\n\nSee also URL']
21	52754	VisualEditor: broken <table> syntax causes VE to inject additional <table> html	In this case, https://en.wikipedia.org/w/index.php?title=Long_Island&diff=562848384&oldid=562113547 - oh dear. -------------------------- Version: unspecified Severity: major	task_description	PHID-TASK-44thcl26amo7hsho63fi	['VisualEditor: broken <table> syntax causes VE to inject additional <table> html\n\nIn this case, URL - oh dear.', '--------------------------\nVersion: unspecified\nSeverity: major']
22	233093	VisualEditor: broken <table> syntax causes VE to inject additional <table> html	* This bug has been marked as a duplicate of bug 51217 *	task_subcomment	PHID-TASK-44thcl26amo7hsho63fi	['\n\n* This bug has been marked as a duplicate of bug 51217 *']
23	233087	VisualEditor: broken <table> syntax causes VE to inject additional <table> html	A minor change in a completely unrelated part of the article causes a copy of the broken table to be injected into the article, and a '<tr' (no closing >) is also included. Upping priority/importance as it should at least ignore elements it doesnt properly understand. The <table> was not so broken that the wikitext up to the </table> should have been ignored. I am able to reproduce the '<tr' being added [[testwiki:User:John_Vandenberg/Table_test]], but in my test the table wasnt copied. After fixing the syntax on enwp, the problem goes away. https://en.wikipedia.org/w/index.php?title=Long_Island&action=history&offset=201307180315&limit=3	task_subcomment	PHID-TASK-44thcl26amo7hsho63fi	["A minor change in a completely unrelated part of the article causes a copy of the broken table to be injected into the article, and a '<tr' (no closing >) is also included.", 'Upping priority/importance as it should at least ignore elements it doesnt properly understand.', 'The <table> was not so broken that the wikitext up to the </table> should have been ignored.', "I am able to reproduce the '<tr' being added [[testwiki:User:John_Vandenberg/Table_test]], but in my test the table wasnt copied.", 'After fixing the syntax on enwp, the problem goes away.', 'URL']
24	51873	VisualEditor: <span> annotations next to each other aren't necessarily the same	Two users have reported on this. See: http://en.wikipedia.org/w/index.php?title=User:AussieLegend/Vandals_etc&diff=prev&oldid=560719781 And: http://en.wikipedia.org/wiki/Wikipedia:VisualEditor/Feedback#Font_colors_in_signatures_changed I realize that this is probably tied into other behavior, but I lack code-fu to determine what. :) Maggie -------------------------- Version: unspecified Severity: normal See Also: https://bugzilla.wikimedia.org/show_bug.cgi?id=42803	task_description	PHID-TASK-fhtlyq5kho6tpsip3niy	["VisualEditor: <span> annotations next to each other aren't necessarily the same\n\nTwo users have reported on this.", 'See:\nURL\n\nAnd:\nURL\n\nI realize that this is probably tied into other behavior, but I lack code-fu to determine what.', ':)\n\nMaggie\n\n--------------------------\nVersion: unspecified\nSeverity: normal\nSee Also:\nURL']
25	230418	VisualEditor: <span> annotations next to each other aren't necessarily the same	Merged and will go out tomorrow.	task_subcomment	PHID-TASK-fhtlyq5kho6tpsip3niy	['Merged and will go out tomorrow.']
26	230413	VisualEditor: <span> annotations next to each other aren't necessarily the same	Change 73523 merged by jenkins-bot: HACK: Don't merge adjacent annotations from Parsoid https://gerrit.wikimedia.org/r/73523	task_subcomment	PHID-TASK-fhtlyq5kho6tpsip3niy	["Change 73523 merged by jenkins-bot:\nHACK: Don't merge adjacent annotations from Parsoid\n\nGERRIT_URL"]
27	230408	VisualEditor: <span> annotations next to each other aren't necessarily the same	* Bug 51234 has been marked as a duplicate of this bug. *	task_subcomment	PHID-TASK-fhtlyq5kho6tpsip3niy	['* Bug 51234 has been marked as a duplicate of this bug.', '*']
28	230403	VisualEditor: <span> annotations next to each other aren't necessarily the same	Change 73523 had a related patch set uploaded by Esanders: HACK: Don't merge adjacent annotations from Parsoid https://gerrit.wikimedia.org/r/73523	task_subcomment	PHID-TASK-fhtlyq5kho6tpsip3niy	["Change 73523 had a related patch set uploaded by Esanders:\nHACK: Don't merge adjacent annotations from Parsoid\n\nGERRIT_URL"]
29	230397	VisualEditor: <span> annotations next to each other aren't necessarily the same	Adding Parsoid bug 42803 as a dependency. We do add nowiki between most cases of adjacent quotes to ensure at least correctness, but the markup will indeed not be optimal.	task_subcomment	PHID-TASK-fhtlyq5kho6tpsip3niy	['Adding Parsoid bug 42803 as a dependency.', 'We do add nowiki between most cases of adjacent quotes to ensure at least correctness, but the markup will indeed not be optimal.']
30	230390	VisualEditor: <span> annotations next to each other aren't necessarily the same	* Bug 50291 has been marked as a duplicate of this bug. *	task_subcomment	PHID-TASK-fhtlyq5kho6tpsip3niy	['* Bug 50291 has been marked as a duplicate of this bug.', '*']
31	230381	VisualEditor: <span> annotations next to each other aren't necessarily the same	All we need to do is turn off similar annotation comparisons in VE completely, but Parsoid is not ready for that yet, for example adding new bold text next to Parsoid-generated bold text would create: <b data=parsoid="">Old bold text</b><b>New bold text from VE</b> which Parsoid should obviously merge to: '''Old bold textNew bold text from VE''' but doesn't yet. Once this is all handled correctly, we can turn off similar annotation comparisons and the two bolds in <b>Foo</b><b>Bar</b> will no longer be merged (as they have will have different data-parsoid's). Of course Parsoid will not want to merge them either so that will factor into their logic.	task_subcomment	PHID-TASK-fhtlyq5kho6tpsip3niy	['All we need to do is turn off similar annotation comparisons in VE completely, but Parsoid is not ready for that yet, for example adding new bold text next to Parsoid-generated bold text would create:\n\n<b data=parsoid="">Old bold text</b><b>New bold text from VE</b>\n\nwhich Parsoid should obviously merge to:\n\n\'\'\'Old bold textNew bold text from VE\'\'\'\n\nbut doesn\'t yet.', "Once this is all handled correctly, we can turn off similar annotation comparisons and the two bolds in <b>Foo</b><b>Bar</b> will no longer be merged (as they have will have different data-parsoid's).", 'Of course Parsoid will not want to merge them either so that will factor into their logic.']
32	230374	VisualEditor: <span> annotations next to each other aren't necessarily the same	(In reply to comment #6) > I still see annotation merging on this test case: > > http://www.mediawiki.org/wiki/User:GWicke/TestDoubleFormatting?veaction=edit > > Steps to reproduce: > > * append a char to 'baz' > * preview the change > > Result: The bold ranges are merged, leading to a dirty diff > Expected result: no merging and no dirty diff That should be the only remaining annotation merging issue. I've been meaning to file a bug about it but I keep forgetting. Ed, we need to preserve the difference between <b>Foo</b><b>Bar</b> and <b>FooBar</b> somehow. Feel free to hit me up on IRC if you want to talk about how we should do that.	task_subcomment	PHID-TASK-fhtlyq5kho6tpsip3niy	['(In reply to comment #6)\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nThat should be the only remaining annotation merging issue.', "I've been meaning to file a bug about it but I keep forgetting.", 'Ed, we need to preserve the difference between <b>Foo</b><b>Bar</b> and <b>FooBar</b> somehow.', 'Feel free to hit me up on IRC if you want to talk about how we should do that.']
33	230368	VisualEditor: <span> annotations next to each other aren't necessarily the same	I still see annotation merging on this test case: http://www.mediawiki.org/wiki/User:GWicke/TestDoubleFormatting?veaction=edit Steps to reproduce: * append a char to 'baz' * preview the change Result: The bold ranges are merged, leading to a dirty diff Expected result: no merging and no dirty diff	task_subcomment	PHID-TASK-fhtlyq5kho6tpsip3niy	["I still see annotation merging on this test case:\n\nURL\n\nSteps to reproduce:\n\n* append a char to 'baz'\n* preview the change\n\nResult: The bold ranges are merged, leading to a dirty diff\nExpected result: no merging and no dirty diff"]
34	230361	VisualEditor: <span> annotations next to each other aren't necessarily the same	Several of these issues are actually on the VE side, so reopening.	task_subcomment	PHID-TASK-fhtlyq5kho6tpsip3niy	['Several of these issues are actually on the VE side, so reopening.']
35	230352	VisualEditor: <span> annotations next to each other aren't necessarily the same	* This bug has been marked as a duplicate of bug 48194 *	task_subcomment	PHID-TASK-fhtlyq5kho6tpsip3niy	['\n\n* This bug has been marked as a duplicate of bug 48194 *']
36	230345	VisualEditor: <span> annotations next to each other aren't necessarily the same	* This bug has been marked as a duplicate of bug 42803 *	task_subcomment	PHID-TASK-fhtlyq5kho6tpsip3niy	['\n\n* This bug has been marked as a duplicate of bug 42803 *']
37	230338	VisualEditor: <span> annotations next to each other aren't necessarily the same	This is the same as bug 49478. We are dependent on it being in Parsoid first, otherwise we would reintroduce bug 48110.	task_subcomment	PHID-TASK-fhtlyq5kho6tpsip3niy	['This is the same as bug 49478.', 'We are dependent on it being in Parsoid first, otherwise we would reintroduce bug 48110.']
38	230334	VisualEditor: <span> annotations next to each other aren't necessarily the same	In this case: <span style="color:green;">Aussie</span><span style="color:gold;">Legend</span> … is being simplified by DM into: <span style="color:green;">AussieLegend</span> … which, unsurprisingly, Parsoid assumes means we wanted to combine them. :-)	task_subcomment	PHID-TASK-fhtlyq5kho6tpsip3niy	['In this case:\n\n <span style="color:green;">Aussie</span><span style="color:gold;">Legend</span>\n\n… is being simplified by DM into:\n\n <span style="color:green;">AussieLegend</span>\n\n… which, unsurprisingly, Parsoid assumes means we wanted to combine them.', ':-)']
39	55665	VisualEditor: Table rows with no defined cells rendered as an empty line	At https://en.wikipedia.org/w/index.php?title=Flight_endurance_record&oldid=571122193#Free_Balloon.2C_Manned the table begins with an empty row where there would normally be a header: {\|class="wikitable" \|- \|- \|content In view mode this empty line is not shown, but it does appear in VE. Testing at https://en.wikipedia.org/w/index.php?title=User:Thryduulf/sandbox&oldid=571124234#Tables_with_empty_rows shows that the same thing happens, wherever the blank line is in the table. Oddly though the line is shown at full height when its in last position but ~half height elsewhere. In itself this isn't a problem, it's just different to what happens in view mode where the second \|- is ignored. -------------------------- Version: unspecified Severity: minor	task_description	PHID-TASK-c6mjvz42mmi6bswdw56d	['VisualEditor: Table rows with no defined cells rendered as an empty line\n\nAt URL the table begins with an empty row where there would normally be a header:\n{\|class="wikitable"\n\|-\n\|-\n\|content\n\nIn view mode this empty line is not shown, but it does appear in VE.', 'Testing at URL shows that the same thing happens, wherever the blank line is in the table.', 'Oddly though the line is shown at full height when its in last position but ~half height elsewhere.', "In itself this isn't a problem, it's just different to what happens in view mode where the second \|- is ignored.", '--------------------------\nVersion: unspecified\nSeverity: minor']
40	256481	VisualEditor: Table rows with no defined cells rendered as an empty line	This was fixed a while ago by the Parsoid team.	task_subcomment	PHID-TASK-c6mjvz42mmi6bswdw56d	['This was fixed a while ago by the Parsoid team.']
41	50556	VisualEditor: "Move this category here" should not appear for the last category	It's a no-op, and is confusing. (But is it more confusing to list it?) -------------------------- Version: unspecified Severity: enhancement	task_description	PHID-TASK-isog5p3qki3pp25ezf63	['VisualEditor: "Move this category here" should not appear for the last category\n\nIt\'s a no-op, and is confusing.', '(But is it more confusing to list it?)', '--------------------------\nVersion: unspecified\nSeverity: enhancement']
42	230763	VisualEditor: "Move this category here" should not appear for the last category	https://gerrit.wikimedia.org/r/68130 (Gerrit Change If48e001b92c217bee0a35b6da41d1c1ff0e3271c) \| change APPROVED and MERGED [by jenkins-bot]	task_subcomment	PHID-TASK-isog5p3qki3pp25ezf63	['GERRIT_URL (Gerrit Change If48e001b92c217bee0a35b6da41d1c1ff0e3271c) \| change APPROVED and MERGED [by jenkins-bot]']
43	230757	VisualEditor: "Move this category here" should not appear for the last category	Related URL: https://gerrit.wikimedia.org/r/68130 (Gerrit Change If48e001b92c217bee0a35b6da41d1c1ff0e3271c)	task_subcomment	PHID-TASK-isog5p3qki3pp25ezf63	['Related URL: GERRIT_URL (Gerrit Change If48e001b92c217bee0a35b6da41d1c1ff0e3271c)']
44	230748	VisualEditor: "Move this category here" should not appear for the last category	Related URL: https://gerrit.wikimedia.org/r/68130 (Gerrit Change If48e001b92c217bee0a35b6da41d1c1ff0e3271c)	task_subcomment	PHID-TASK-isog5p3qki3pp25ezf63	['Related URL: GERRIT_URL (Gerrit Change If48e001b92c217bee0a35b6da41d1c1ff0e3271c)']
45	230738	VisualEditor: "Move this category here" should not appear for the last category	Now merged.	task_subcomment	PHID-TASK-isog5p3qki3pp25ezf63	['Now merged.']
46	230729	VisualEditor: "Move this category here" should not appear for the last category	Related URL: https://gerrit.wikimedia.org/r/67922 (Gerrit Change I93ce05f7cbb28313a3f0827539f0528c366aeb7e)	task_subcomment	PHID-TASK-isog5p3qki3pp25ezf63	['Related URL: GERRIT_URL (Gerrit Change I93ce05f7cbb28313a3f0827539f0528c366aeb7e)']
47	50284	VisualEditor: Enter 2 times, Backspace 2 times -> not deleted in Firefox	Go to http://en.wikipedia.org/wiki/Content_Management_Interoperability_Services Put the cursor somewhere in the text. Type "Enter" 2 times. Type "Backspace" 2 times. Expected: as original Actually: The newlines remain -------------------------- Version: unspecified Severity: normal	task_description	PHID-TASK-2f2dgqt54eqesg4exgwo	['VisualEditor: Enter 2 times, Backspace 2 times -> not deleted in Firefox\n\nGo to URL\nPut the cursor somewhere in the text.', 'Type "Enter" 2 times.', 'Type "Backspace" 2 times.', 'Expected: as original\nActually: The newlines remain\n\n--------------------------\nVersion: unspecified\nSeverity: normal']
48	214285	VisualEditor: Enter 2 times, Backspace 2 times -> not deleted in Firefox	This is now fixed in live.	task_subcomment	PHID-TASK-2f2dgqt54eqesg4exgwo	['This is now fixed in live.']
49	214280	VisualEditor: Enter 2 times, Backspace 2 times -> not deleted in Firefox	Just reproduced on Firefox 21.0 / fresh install of Ubuntu Linux 2013.04 Nothing special appears in the web console.	task_subcomment	PHID-TASK-2f2dgqt54eqesg4exgwo	['Just reproduced on Firefox 21.0 / fresh install of Ubuntu Linux 2013.04\nNothing special appears in the web console.']
50	214275	VisualEditor: Enter 2 times, Backspace 2 times -> not deleted in Firefox	Browser information highly welcome. Reopening for the time being.	task_subcomment	PHID-TASK-2f2dgqt54eqesg4exgwo	['Browser information highly welcome.', 'Reopening for the time being.']
51	214270	VisualEditor: Enter 2 times, Backspace 2 times -> not deleted in Firefox	When will the master fixes be deployed? The situation is now horrible in production, with so many bugs that I am wondering whether it is even worth reporting them...	task_subcomment	PHID-TASK-2f2dgqt54eqesg4exgwo	['When will the master fixes be deployed?', 'The situation is now horrible in production, with so many bugs that I am wondering whether it is even worth reporting them...']
52	214264	VisualEditor: Enter 2 times, Backspace 2 times -> not deleted in Firefox	I just tried, it is a worse problem now, text is lost.	task_subcomment	PHID-TASK-2f2dgqt54eqesg4exgwo	['I just tried, it is a worse problem now, text is lost.']
53	214256	VisualEditor: Enter 2 times, Backspace 2 times -> not deleted in Firefox	orbit wrote: I'm not able to reproduce this one either. I experience other problems relating to Enter and Backspace on Firefox (fixed in Master) but not what you've described. I'm going to close this ticket, but please reopen if you have additional information.	task_subcomment	PHID-TASK-2f2dgqt54eqesg4exgwo	["orbit wrote:\n\nI'm not able to reproduce this one either.", "I experience other problems relating to Enter and Backspace on Firefox (fixed in Master) but not what you've described.", "I'm going to close this ticket, but please reopen if you have additional information."]
54	45104	Parsoid: Second column heading missing of table with template-generated header	Screenshot showing the regular view, visualeditor view and wikitext Steps to reproduce problem: * Open VisualEditor on https://en.wikipedia.org/wiki/Buri_Ram_Airport Expected result: Table has header on both columns. Actual result: Header of second column is missing. -------------------------- Version: unspecified Severity: normal Attached: {F9595}	task_description	PHID-TASK-woqw5jwyjb5eshocsjdw	['Parsoid: Second column heading missing of table with template-generated header\n\nScreenshot showing the regular view, visualeditor view and wikitext\n\nSteps to reproduce problem:\n* Open VisualEditor on URL\n\nExpected result:\nTable has header on both columns.', 'Actual result:\nHeader of second column is missing.', '--------------------------\nVersion: unspecified\nSeverity: normal\n\nAttached: {F9595}']
55	182240	Parsoid: Second column heading missing of table with template-generated header	[Parsoid component reorg by merging JS/General and General. See bug 50685 for more information. Filter bugmail on this comment. parsoidreorg20130704]	task_subcomment	PHID-TASK-woqw5jwyjb5eshocsjdw	['[Parsoid component reorg by merging JS/General and General.', 'See bug 50685 for more information.', 'Filter bugmail on this comment.', 'parsoidreorg20130704]']
56	182236	Parsoid: Second column heading missing of table with template-generated header	Patch committed for review in https://gerrit.wikimedia.org/r/46465.	task_subcomment	PHID-TASK-woqw5jwyjb5eshocsjdw	['Patch committed for review in GERRIT_URL.']
57	182232	Parsoid: Second column heading missing of table with template-generated header	Appears to be a failed template expansion, so probably a Parsoid bug - Gabriel, thoughts?	task_subcomment	PHID-TASK-woqw5jwyjb5eshocsjdw	['Appears to be a failed template expansion, so probably a Parsoid bug - Gabriel, thoughts?']
58	56490	Flow: misleading exception is thrown if the parsoid service is down	If the parsoid service is down (`sudo service parsoid stop`, or update extension/Parsoid and forget/fail `npm install`), then viewing flow pages fails with exception Parser only supports wikitext to HTML conversion Backtrace: #0 /srv/mediawiki/extensions/Flow/includes/ParsoidUtils.php(24): Flow\ParsoidUtils::parser('html', 'wikitext', '<p>It's a long ...') This is true, but it masks the real problem that parsoid has to work, and didn't. ParsoidUtils::convert has a try-catch block around using parsoid, and if that fails it will fall back to using parser. It would be helpful for wiki operators if the exception message included the parsoid failure, e.g. Parser only supports wikitext to HTML conversion (and parsoid earlier failed with exception "VisualEditor is unavailable") Now that I've figured out what's going on, this has become a low-priority bug :-) -------------------------- Version: master Severity: minor	task_description	PHID-TASK-vpzdercihud4opsstlu6	["Flow: misleading exception is thrown if the parsoid service is down\n\nIf the parsoid service is down (CODE, or update extension/Parsoid and forget/fail CODE), then viewing flow pages fails with exception\n\n Parser only supports wikitext to HTML conversion\n\n Backtrace:\n\n #0 /srv/mediawiki/extensions/Flow/includes/ParsoidUtils.php(24): Flow\\ParsoidUtils::parser('html', 'wikitext', '<p>It's a long ...')\n\nThis is true, but it masks the real problem that parsoid has to work, and didn't.", 'ParsoidUtils::convert has a try-catch block around using parsoid, and if that fails it will fall back to using parser.', 'It would be helpful for wiki operators if the exception message included the parsoid failure, e.g.', 'Parser only supports wikitext to HTML conversion (and parsoid earlier failed with exception "VisualEditor is unavailable")\n\nNow that I\'ve figured out what\'s going on, this has become a low-priority bug :-)\n\n--------------------------\nVersion: master\nSeverity: minor']
59	257321	Flow: misleading exception is thrown if the parsoid service is down	https://gerrit.wikimedia.org/r/#/c/92633/	task_subcomment	PHID-TASK-vpzdercihud4opsstlu6	['URL']
60	257316	Flow: misleading exception is thrown if the parsoid service is down	Prioritization and scheduling of this bug is tracked on Mingle card https://mingle.corp.wikimedia.org/projects/flow/cards/264	task_subcomment	PHID-TASK-vpzdercihud4opsstlu6	['Prioritization and scheduling of this bug is tracked on Mingle card URL']
61	55340	VisualEditor: trouble with Template:Hlist	Reporting user comment, some formatting is mine: <<I made this http://en.wikipedia.org/wiki/User:Atethnekos/sandbox4 as a demonstration. 1) If the hlist template is used in an infobox or a table like on the page, when I go to VE, the list will end up be extended far into the page. 2) If it's used with [[File:Image]] as on the page, the list will end up being cut off, and then some weird things will happen if I try to click on the hlist template (e.g., the page will be extended to right and my browser will give a horizontal scroll bar). FF 23.0.1 Win7--Atethnekos 19:33, 25 August 2013 (UTC) >> I edited his sandbox a couple of times. In this version http://en.wikipedia.org/w/index.php?title=User:Atethnekos/sandbox4&oldid=570256245&veaction=edit the pics of the masks are moved to the left: the caption of the first one is not cut out, but you can't edit the pics at all since VE will consider them as a non editable block. I can't reproduce the horizontal bar and I can correctly edit the hlist template inside the mask pic caption with both FF and Chrome. Thanks. -------------------------- Version: unspecified Severity: normal	task_description	PHID-TASK-l6w6nyonc7ci3mnehffx	['VisualEditor: trouble with Template:Hlist\n\nReporting user comment, some formatting is mine:\n<<I made this URL as a demonstration.', '1) If the hlist template is used in an infobox or a table like on the page, when I go to VE, the list will end up be extended far into the page.', "2) If it's used with [[File:Image]] as on the page, the list will end up being cut off, and then some weird things will happen if I try to click on the hlist template (e.g., the page will be extended to right and my browser will give a horizontal scroll bar).", 'FF 23.0.1 Win7--Atethnekos 19:33, 25 August 2013 (UTC) >>\n\nI edited his sandbox a couple of times.', "In this version URL the pics of the masks are moved to the left: the caption of the first one is not cut out, but you can't edit the pics at all since VE will consider them as a non editable block.", "I can't reproduce the horizontal bar and I can correctly edit the hlist template inside the mask pic caption with both FF and Chrome.", 'Thanks.', '--------------------------\nVersion: unspecified\nSeverity: normal']
62	1514071	VisualEditor: trouble with Template:Hlist	The previous comments don't explain what/who exactly this task is //stalled// on (["If a report is waiting for further input (e.g. from its reporter or a third party) and can currently not be acted on"](https://www.mediawiki.org/wiki/Bug_management/Bug_report_life_cycle)). > the list will end up be extended far into the page. Does not seem to happen anymore: {F31846960} > If it's used with [[File:Image]] as on the page, the list will end up being cut off, and then some weird things will happen if I try to click on the hlist template (e.g., the page will be extended to right and my browser will give a horizontal scroll bar). Cannot reproduce in Firefox 76. > but you can't edit the pics at all since VE will consider them as a non editable block. If I understand correctly then I cannot reproduce: {F31846963} {F31846962} If this still happens then please follow https://www.mediawiki.org/wiki/How_to_report_a_bug (clear steps to reproduce; what's expected; what happens instead; in separate sections) and reopen this ticket. For the records, wiki text test case here is ``` {{Infobox philosopher \|image = File:NAMA Masque esclave.jpg \|caption = Geloius: copy of portrait bust by [[Silanion]] \|name = Geloius \|birth_place = [[Athens]] \|main_interests = {{hlist \|nullus \|primus \|secundus \|tertius \|quartus \|quintus \|sextus \|septus \|octavus \|nonus \|decimus \|et ceterus }} }} ```	task_subcomment	PHID-TASK-l6w6nyonc7ci3mnehffx	['The previous comments don\'t explain what/who exactly this task is //stalled// on (["If a report is waiting for further input (e.g.', 'from its reporter or a third party) and can currently not be acted on"](URL\n\nQUOTE\nDoes not seem to happen anymore:\n\n{F31846960}\n\nQUOTE\n\nCannot reproduce in Firefox 76.', "QUOTE\n\nIf I understand correctly then I cannot reproduce:\n\n{F31846963}\n\n{F31846962}\n\nIf this still happens then please follow URL (clear steps to reproduce; what's expected; what happens instead; in separate sections) and reopen this ticket.", 'For the records, wiki text test case here is\n``CODE``']
63	50787	VisualEditor: Using up-arrow to scroll lets you put the cursor under the toolbar in Firefox, Internet Explorer	Go to some long article (so long that it won't fit on one screen in your browser), start the visual editor, scroll down, then use up-arrow to walk all the way back up to the top of the article. It's not possible: the first lines of the article remain obscured by the visual editor's menu bar; the only way to make them visible is using the scroll bar or with PageUp. This is Windows 7, Firefox 16.0.2, Chrome 26.0.1410.64 m, Mediawiki 1.22wmf4 (646544a), VisualEditor 0.1.0 -------------------------- Version: unspecified Severity: normal	task_description	PHID-TASK-4bokg6oohi7iw7rzhciv	["VisualEditor: Using up-arrow to scroll lets you put the cursor under the toolbar in Firefox, Internet Explorer\n\nGo to some long article (so long that it won't fit on one screen in your browser), start the visual editor, scroll down, then use up-arrow to walk all the way back up to the top of the article.", "It's not possible: the first lines of the article remain obscured by the visual editor's menu bar; the only way to make them visible is using the scroll bar or with PageUp.", 'This is Windows 7, Firefox 16.0.2, Chrome 26.0.1410.64 m, Mediawiki 1.22wmf4 (646544a), VisualEditor 0.1.0\n\n--------------------------\nVersion: unspecified\nSeverity: normal']
64	2102206	VisualEditor: Using up-arrow to scroll lets you put the cursor under the toolbar in Firefox, Internet Explorer	IE9, Firefox 16.0.2, Chrome 26.0.1410.64 not supported anymore.	task_subcomment	PHID-TASK-4bokg6oohi7iw7rzhciv	['IE9, Firefox 16.0.2, Chrome 26.0.1410.64 not supported anymore.']
65	2102205	VisualEditor: Using up-arrow to scroll lets you put the cursor under the toolbar in Firefox, Internet Explorer	IE9, Firefox 16.0.2, Chrome 26.0.1410.64 now supported anymore.	task_subcomment	PHID-TASK-4bokg6oohi7iw7rzhciv	['IE9, Firefox 16.0.2, Chrome 26.0.1410.64 now supported anymore.']
66	219382	VisualEditor: Using up-arrow to scroll lets you put the cursor under the toolbar in Firefox, Internet Explorer	Apparently IE is affected too (see bug 63778).	task_subcomment	PHID-TASK-4bokg6oohi7iw7rzhciv	['Apparently IE is affected too (see bug 63778).']
67	219376	VisualEditor: Using up-arrow to scroll lets you put the cursor under the toolbar in Firefox, Internet Explorer	Go to some long article, scroll all the way down, click to make the blinking cursor visible. Now press and hold the cursor-up key to go all the way back to the top. Upon release of the cursor-up key, the cursor will be invisibly placed behind the toolbar. Another press/release of the cursor-up key is necessary to make it visible again.	task_subcomment	PHID-TASK-4bokg6oohi7iw7rzhciv	['Go to some long article, scroll all the way down, click to make the blinking cursor visible.', 'Now press and hold the cursor-up key to go all the way back to the top.', 'Upon release of the cursor-up key, the cursor will be invisibly placed behind the toolbar.', 'Another press/release of the cursor-up key is necessary to make it visible again.']
68	219370	VisualEditor: Using up-arrow to scroll lets you put the cursor under the toolbar in Firefox, Internet Explorer	I believe that this was fixed some time ago as part of the toolbar fixes - please re-open if not.	task_subcomment	PHID-TASK-4bokg6oohi7iw7rzhciv	['I believe that this was fixed some time ago as part of the toolbar fixes - please re-open if not.']
69	219363	VisualEditor: Using up-arrow to scroll lets you put the cursor under the toolbar in Firefox, Internet Explorer	I am now seeing the following behavior on mediawiki.org, using both Firefox and Chrome: Editing a long article with the VisualEditor, scrolling down, and then pressing and holding CursorUp will scroll back to the top, but not quite: the very first line of the article remains obscured by the toolbar. I have to release and repress CursorUp to see that line.	task_subcomment	PHID-TASK-4bokg6oohi7iw7rzhciv	['I am now seeing the following behavior on mediawiki.org, using both Firefox and Chrome:\n\nEditing a long article with the VisualEditor, scrolling down, and then pressing and holding CursorUp will scroll back to the top, but not quite: the very first line of the article remains obscured by the toolbar.', 'I have to release and repress CursorUp to see that line.']
70	219356	VisualEditor: Using up-arrow to scroll lets you put the cursor under the toolbar in Firefox, Internet Explorer	This is now merged and will go out later today.	task_subcomment	PHID-TASK-4bokg6oohi7iw7rzhciv	['This is now merged and will go out later today.']
71	219350	VisualEditor: Using up-arrow to scroll lets you put the cursor under the toolbar in Firefox, Internet Explorer	Change 73015 merged by jenkins-bot: Bind listener to keyup to capture arrows & better math for scrolling. https://gerrit.wikimedia.org/r/73015	task_subcomment	PHID-TASK-4bokg6oohi7iw7rzhciv	['Change 73015 merged by jenkins-bot:\nBind listener to keyup to capture arrows & better math for scrolling.', 'GERRIT_URL']
72	219342	VisualEditor: Using up-arrow to scroll lets you put the cursor under the toolbar in Firefox, Internet Explorer	Change 73015 had a related patch set uploaded by Robmoen: Bind listener to keyup to capture arrows & better math for scrolling. https://gerrit.wikimedia.org/r/73015	task_subcomment	PHID-TASK-4bokg6oohi7iw7rzhciv	['Change 73015 had a related patch set uploaded by Robmoen:\nBind listener to keyup to capture arrows & better math for scrolling.', 'GERRIT_URL']
73	219337	VisualEditor: Using up-arrow to scroll lets you put the cursor under the toolbar in Firefox, Internet Explorer	(In reply to comment #0) > Go to some long article (so long that it won't fit on one screen in your > browser), start the visual editor, scroll down, then use up-arrow to walk all > the way back up to the top of the article. It's not possible: the first lines > of the article remain obscured by the visual editor's menu bar; the only way > to make them visible is using the scroll bar or with PageUp. I can't reproduce this as written (for wmf6 or wmf7 on Mac or Linux, don't have Windows to test on). We did change the behaviour of the toolbar a little in wmf5, which may explain. However, it /is/ possible using the cursor keys to put the cursor underneath the toolbar when scrolled down so that the user can't see where it is. Will change this bug to reflect that, but feel free to revert if you can reproduce.	task_subcomment	PHID-TASK-4bokg6oohi7iw7rzhciv	["(In reply to comment #0)\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\n\nI can't reproduce this as written (for wmf6 or wmf7 on Mac or Linux, don't have Windows to test on).", 'We did change the behaviour of the toolbar a little in wmf5, which may explain.', "However, it /is/ possible using the cursor keys to put the cursor underneath the toolbar when scrolled down so that the user can't see where it is.", 'Will change this bug to reflect that, but feel free to revert if you can reproduce.']
74	45120	Create a VisualEditor plugin tool to add/edit Poem blocks	<poem>....</poem> is unparsed but shown as plain wikitext: https://en.wikipedia.org/wiki/User:Raymond/poem -------------------------- Version: unspecified Severity: enhancement URL: https://en.wikipedia.org/wiki/User:Raymond/poem	task_description	PHID-TASK-j5lt672qs5xqtdfzq6de	['Create a VisualEditor plugin tool to add/edit Poem blocks\n\n<poem>....</poem> is unparsed but shown as plain wikitext:\nURL\n\n--------------------------\nVersion: unspecified\nSeverity: enhancement\nURL: URL']
75	183197	Create a VisualEditor plugin tool to add/edit Poem blocks	(In reply to comment #3) > (a) and (b), I guess. See bug 52061. I was going through a list of bugs in > the Poem component, since they will all need to be moved once the change > is merged (hoping it is merged, of course). Sorry if I'm getting too far > ahead of myself, but this bug did seem like an odd one out, so I moved it > out here. Moving back to Poem, then. The bug can be moved the MediaWiki/editing or whatever later, when bug 52061 is closed-fixed. > (In reply to comment #2) > > > so I'm punting back to VisualEditor. > > > > Why? It's not VisualEditor's problem that an extension hasn't been updated > > yet… > > Well, if Poem is to become a MediaWiki core feature, then it will turn into > something for the VE team to worry about. No, not really. It'll remain the responsibility of some code's maintainer, whoever that is (you?). In the absence of an obvious maintainer, that's the "Platform team", which sucks, but is rather outwith this bug report. The VE team build VE and some of the MW-specific VE tools. We're not going to make an editor for EasyTimeline, and we're not going to make one for Poem, for the same reason. :-) > Also, if I may point it out, the WikiHiero extension is seemingly supported > in VisualEditor core. The extension itself knows nothing about VE. is that > an anomaly? Yes; the code's yet to be moved into that repo. Give me a spare 10 minutes. :-)	task_subcomment	PHID-TASK-j5lt672qs5xqtdfzq6de	['(In reply to comment #3)\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\n\nMoving back to Poem, then.', 'The bug can be moved the MediaWiki/editing or whatever later, when bug 52061 is closed-fixed.', 'QUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\n\nNo, not really.', "It'll remain the responsibility of some code's maintainer, whoever that is (you?).", 'In the absence of an obvious maintainer, that\'s the "Platform team", which sucks, but is rather outwith this bug report.', 'The VE team build VE and some of the MW-specific VE tools.', "We're not going to make an editor for EasyTimeline, and we're not going to make one for Poem, for the same reason.", ":-)\n\nQUOTE\nQUOTE\nQUOTE\n\nYes; the code's yet to be moved into that repo.", 'Give me a spare 10 minutes.', ':-)']
76	183191	Create a VisualEditor plugin tool to add/edit Poem blocks	(a) and (b), I guess. See bug 52061. I was going through a list of bugs in the Poem component, since they will all need to be moved once the change is merged (hoping it is merged, of course). Sorry if I'm getting too far ahead of myself, but this bug did seem like an odd one out, so I moved it out here. (In reply to comment #2) > > so I'm punting back to VisualEditor. > > Why? It's not VisualEditor's problem that an extension hasn't been updated > yet… Well, if Poem is to become a MediaWiki core feature, then it will turn into something for the VE team to worry about. Also, if I may point it out, the WikiHiero extension is seemingly supported in VisualEditor core. The extension itself knows nothing about VE. is that an anomaly?	task_subcomment	PHID-TASK-j5lt672qs5xqtdfzq6de	['(a) and (b), I guess.', 'See bug 52061.', 'I was going through a list of bugs in the Poem component, since they will all need to be moved once the change is merged (hoping it is merged, of course).', "Sorry if I'm getting too far ahead of myself, but this bug did seem like an odd one out, so I moved it out here.", '(In reply to comment #2)\nQUOTE\nQUOTE\nQUOTE\nQUOTE\n\nWell, if Poem is to become a MediaWiki core feature, then it will turn into something for the VE team to worry about.', 'Also, if I may point it out, the WikiHiero extension is seemingly supported in VisualEditor core.', 'The extension itself knows nothing about VE.', 'is that an anomaly?']
77	183186	Create a VisualEditor plugin tool to add/edit Poem blocks	(In reply to comment #1) > This is not a bug/enhancement in the Poem extension itself, False. The Poem extension fails to register a VisualEditor enhanced editor for itself. This is a problem with that extension. See also bug 43115, bug 43118, bug 43127, etc. > so I'm punting back to VisualEditor. Why? It's not VisualEditor's problem that an extension hasn't been updated yet… > If I've got this wrong, please don't move the bug back to Poem, as this > component is hopefully going to be removed soon. Please justify this. All MW extensions that are deployed on the WMF cluster (and many that aren't) have a Bugzilla component, by policy. Are you saying that: (a) you want us to remove this extension from the cluster, (b) you want us to merge this extension into MW core, or (c) you want us to break our existing policy for this extension?	task_subcomment	PHID-TASK-j5lt672qs5xqtdfzq6de	['(In reply to comment #1)\nQUOTE\n\nFalse.', 'The Poem extension fails to register a VisualEditor enhanced editor for itself.', 'This is a problem with that extension.', 'See also bug 43115, bug 43118, bug 43127, etc.', 'QUOTE\n\nWhy?', "It's not VisualEditor's problem that an extension hasn't been updated yet…\n\nQUOTE\nQUOTE\n\nPlease justify this.", "All MW extensions that are deployed on the WMF cluster (and many that aren't) have a Bugzilla component, by policy.", 'Are you saying that:\n\n (a) you want us to remove this extension from the cluster,\n (b) you want us to merge this extension into MW core, or\n (c) you want us to break our existing policy for this extension?']
78	183180	Create a VisualEditor plugin tool to add/edit Poem blocks	This is not a bug/enhancement in the Poem extension itself, so I'm punting back to VisualEditor. If I've got this wrong, please don't move the bug back to Poem, as this component is hopefully going to be removed soon.	task_subcomment	PHID-TASK-j5lt672qs5xqtdfzq6de	["This is not a bug/enhancement in the Poem extension itself, so I'm punting back to VisualEditor.", "If I've got this wrong, please don't move the bug back to Poem, as this component is hopefully going to be removed soon."]
79	47304	[GUI] Correct the button message text when converting OpenID (must be "converting" or "adding", not "Login")	Correct the button message text when converting OpenID (must be "converting" or "adding", not "Login"). A few more changes may be needed than to simply adapt the text above the button on the provider selection page ( Special:OpenIDConvert ). -------------------------- Version: master Severity: enhancement	task_description	PHID-TASK-wkyshzo5cqaylrvqgeso	['[GUI] Correct the button message text when converting OpenID (must be "converting" or "adding", not "Login")\n\nCorrect the button message text when converting OpenID (must be "converting" or "adding", not "Login").', 'A few more changes may be needed than to simply adapt the text above the button on the provider selection page ( Special:OpenIDConvert ).', '--------------------------\nVersion: master\nSeverity: enhancement']
80	210866	[GUI] Correct the button message text when converting OpenID (must be "converting" or "adding", not "Login")	solved by merging v4.01 https://gerrit.wikimedia.org/r/97202	task_subcomment	PHID-TASK-wkyshzo5cqaylrvqgeso	['solved by merging v4.01\nGERRIT_URL']
81	210861	[GUI] Correct the button message text when converting OpenID (must be "converting" or "adding", not "Login")	Change 97202 merged by Wikinaut: Bug 45304: show correct button texts for login/create account/convert OpenID https://gerrit.wikimedia.org/r/97202	task_subcomment	PHID-TASK-wkyshzo5cqaylrvqgeso	['Change 97202 merged by Wikinaut:\nBug 45304: show correct button texts for login/create account/convert OpenID\n\nGERRIT_URL']
82	210856	[GUI] Correct the button message text when converting OpenID (must be "converting" or "adding", not "Login")	Change 97202 had a related patch set (by Wikinaut) published: Bug 45304: show correct button texts for login/create account/convert OpenID https://gerrit.wikimedia.org/r/97202	task_subcomment	PHID-TASK-wkyshzo5cqaylrvqgeso	['Change 97202 had a related patch set (by Wikinaut) published:\nBug 45304: show correct button texts for login/create account/convert OpenID\n\nGERRIT_URL']
83	33072	Http::get should accept user-agent option	Author: `olivier.beaton` Description: for any extension that uses Http::get a common task is setting the user-agent, which means they have to use the request object instead. Really $options should include the user-agent string -------------------------- Version: unspecified Severity: enhancement	task_description	PHID-TASK-ssphbusktrpppqnyzrp6	['Http::get should accept user-agent option\n\nAuthor: CODE\n\nDescription:\nfor any extension that uses Http::get a common task is setting the user-agent, which means they have to use the request object instead.', 'Really $options should include the user-agent string\n\n--------------------------\nVersion: unspecified\nSeverity: enhancement']
84	153419	Http::get should accept user-agent option	Patch applied in r103765	task_subcomment	PHID-TASK-ssphbusktrpppqnyzrp6	['Patch applied in r103765']
85	153410	Http::get should accept user-agent option	Created attachment 9087 Implement UA at Http::request() level I'm not so sure it's that hard or that hacky. Attached: {F8321}	task_subcomment	PHID-TASK-ssphbusktrpppqnyzrp6	["Created attachment 9087\nImplement UA at Http::request() level\n\nI'm not so sure it's that hard or that hacky.", 'Attached: {F8321}']
86	153403	Http::get should accept user-agent option	...reviving that would be a bit of a hack though. CURL isn't the only thing we support.	task_subcomment	PHID-TASK-ssphbusktrpppqnyzrp6	['...reviving that would be a bit of a hack though.', "CURL isn't the only thing we support."]
87	153395	Http::get should accept user-agent option	olivier.beaton wrote: Doing some compat testing and I found out that this is actually lost functionality. Here's what Http::get looked like in 1.15 public static function get( $url, $timeout = 'default', $opts = array() ) { return Http::request( "GET", $url, $timeout, $opts ); public static function request( $method, $url, $timeout = 'default', $curlOptions = array() ) { and $curlOptions can accept CURLOPT_USERAGENT	task_subcomment	PHID-TASK-ssphbusktrpppqnyzrp6	['olivier.beaton wrote:\n\nDoing some compat testing and I found out that this is actually lost functionality.', 'Here\'s what Http::get looked like in 1.15\n\npublic static function get( $url, $timeout = \'default\', $opts = array() ) {\n return Http::request( "GET", $url, $timeout, $opts );\n\npublic static function request( $method, $url, $timeout = \'default\', $curlOptions = array() ) {\n\n\nand $curlOptions can accept CURLOPT_USERAGENT']
88	153388	Http::get should accept user-agent option	Most sensible thing may be to just accept a 'headers' key with a map of HTTP headers to set. Thus: $foo = Http::get($url, array( 'followRedirects' => false, 'postData' => array( 'foo' => 'bar', 'baz' => 'quux', ), 'headers' => array( 'User-Agent': 'my special extension', 'Accept': 'application/x-something', ) );	task_subcomment	PHID-TASK-ssphbusktrpppqnyzrp6	["Most sensible thing may be to just accept a 'headers' key with a map of HTTP headers to set.", "Thus:\n\n$foo = Http::get($url, array(\n 'followRedirects' => false,\n 'postData' => array(\n 'foo' => 'bar',\n 'baz' => 'quux',\n ),\n 'headers' => array(\n 'User-Agent': 'my special extension',\n 'Accept': 'application/x-something',\n )\n);"]
89	38166	HTTP 500 error when generating 6000px wide thumbnail of a 6912px wide and 12.5MB JPEG file	For https://commons.wikimedia.org/wiki/File:Carbon_River_pano_01A.jpg http://upload.wikimedia.org/wikipedia/commons/thumb/f/f6/Carbon_River_pano_01A.jpg/6565px-Carbon_River_pano_01A.jpg Some sort of Guru meditation. -------------------------- Version: wmf-deployment Severity: normal	task_description	PHID-TASK-2sndzb2ydzwochmrxplf	['HTTP 500 error when generating 6000px wide thumbnail of a 6912px wide and 12.5MB JPEG file\n\nFor URL\n\nURL\n\nSome sort of Guru meditation.', '--------------------------\nVersion: wmf-deployment\nSeverity: normal']
90	1361244	HTTP 500 error when generating 6000px wide thumbnail of a 6912px wide and 12.5MB JPEG file	This is same as T200313, closing as duplicate.	task_subcomment	PHID-TASK-2sndzb2ydzwochmrxplf	['This is same as T200313, closing as duplicate.']
91	462234	HTTP 500 error when generating 6000px wide thumbnail of a 6912px wide and 12.5MB JPEG file	https://upload.wikimedia.org/wikipedia/commons/thumb/8/84/Logiz_de_la_Lune_Rousse-Affiche1900.jpg/120px-Logiz_de_la_Lune_Rousse-Affiche1900.jpg ``` Error generating thumbnail There have been too many recent failed attempts (4 or more) to render this thumbnail. Please try again later. ```	task_subcomment	PHID-TASK-2sndzb2ydzwochmrxplf	['URL\n\n``CODE``']
92	172172	HTTP 500 error when generating 6000px wide thumbnail of a 6912px wide and 12.5MB JPEG file	Error code 137 = out of memory. (In reply to Jasper Deng from comment #0) > http://upload.wikimedia.org/wikipedia/commons/thumb/f/f6/ > Carbon_River_pano_01A.jpg/6565px-Carbon_River_pano_01A.jpg > > Some sort of Guru meditation. What's the use case for generating a 6000px wide thumbnail? (In reply to earthsound from comment #10) > I determined that I'd hit bug 17645, saved the file as a baseline optimized > JPEG rather than progressive and now the thumbnails work. Sorry for the > noise. > > Perhaps the images reported in this bug are saved similarly (progressive)? Yep, that would do it. Progressive images are much more memory intensive to scale. ---- Note: the Carbon river file is a baseline jpeg. Honestly I don't find it that surprising that it runs out of memory when you try to make a 66 megapixel thumbnail. I feel like this bug should be wontfixed unless people have a compelling reason to need such huge thumbnails.	task_subcomment	PHID-TASK-2sndzb2ydzwochmrxplf	['Error code 137 = out of memory.', "(In reply to Jasper Deng from comment #0)\nQUOTE\nQUOTE\nQUOTE\nQUOTE\n\nWhat's the use case for generating a 6000px wide thumbnail?", '(In reply to earthsound from comment #10)\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\n\nYep, that would do it.', 'Progressive images are much more memory intensive to scale.', '----\nNote: the Carbon river file is a baseline jpeg.', "Honestly I don't find it that surprising that it runs out of memory when you try to make a 66 megapixel thumbnail.", 'I feel like this bug should be wontfixed unless people have a compelling reason to need such huge thumbnails.']
93	172164	HTTP 500 error when generating 6000px wide thumbnail of a 6912px wide and 12.5MB JPEG file	(In reply to earthsound from comment #10) > Perhaps the images reported in this bug are saved similarly (progressive)? Ouch. We have lists of progressive images, attachment 11220 and attachment 11500, and you can easily test the cases above with exiftools or whatever. I think we've replaced by bot (most) of the bigger ones, but there may be other factors beyond size that make them fail: in that case, it would be nice to determine what they are, to fix them by bot. It's also possible that whatever you did (a null "convert" run?) fixed other things.	task_subcomment	PHID-TASK-2sndzb2ydzwochmrxplf	['(In reply to earthsound from comment #10)\nQUOTE\n\nOuch.', 'We have lists of progressive images, attachment 11220 and attachment 11500, and you can easily test the cases above with exiftools or whatever.', "I think we've replaced by bot (most) of the bigger ones, but there may be other factors beyond size that make them fail: in that case, it would be nice to determine what they are, to fix them by bot.", 'It\'s also possible that whatever you did (a null "convert" run?)', 'fixed other things.']
94	172155	HTTP 500 error when generating 6000px wide thumbnail of a 6912px wide and 12.5MB JPEG file	earthsound wrote: I determined that I'd hit bug 17645, saved the file as a baseline optimized JPEG rather than progressive and now the thumbnails work. Sorry for the noise. Perhaps the images reported in this bug are saved similarly (progressive)?	task_subcomment	PHID-TASK-2sndzb2ydzwochmrxplf	["earthsound wrote:\n\nI determined that I'd hit bug 17645, saved the file as a baseline optimized JPEG rather than progressive and now the thumbnails work.", 'Sorry for the noise.', 'Perhaps the images reported in this bug are saved similarly (progressive)?']
95	172146	HTTP 500 error when generating 6000px wide thumbnail of a 6912px wide and 12.5MB JPEG file	earthsound wrote: I have been seeing this error (as mentioned in comment 8, it's generating "Error code:137" now) for this particular image: https://commons.wikimedia.org/wiki/File:Aerial_drawing,_1885,_of_Birmingham,_Alabama.jpg The preview on that page (1280px width) is broken: https://upload.wikimedia.org/wikipedia/commons/thumb/6/66/Aerial_drawing%2C_1885%2C_of_Birmingham%2C_Alabama.jpg/1280px-Aerial_drawing%2C_1885%2C_of_Birmingham%2C_Alabama.jpg After a few failed attempts, it will generate this error: "Error generating thumbnail - There have been too many recent failed attempts (5 or more) to render this thumbnail. Please try again later." I have found that any size thumbnail up to a width of 1234px will generate OK, but anything 1235px width or larger fails 100% of the time, even though the full resolution image is OK.	task_subcomment	PHID-TASK-2sndzb2ydzwochmrxplf	['earthsound wrote:\n\nI have been seeing this error (as mentioned in comment 8, it\'s generating "Error code:137" now) for this particular image: \n\nURL\n\nThe preview on that page (1280px width) is broken:\n\nURL\n\nAfter a few failed attempts, it will generate this error: "Error generating thumbnail - There have been too many recent failed attempts (5 or more) to render this thumbnail.', 'Please try again later."', 'I have found that any size thumbnail up to a width of 1234px will generate OK, but anything 1235px width or larger fails 100% of the time, even though the full resolution image is OK.']
96	172140	HTTP 500 error when generating 6000px wide thumbnail of a 6912px wide and 12.5MB JPEG file	I get "Error code: 137" nowadays.	task_subcomment	PHID-TASK-2sndzb2ydzwochmrxplf	['I get "Error code: 137" nowadays.']
97	172137	HTTP 500 error when generating 6000px wide thumbnail of a 6912px wide and 12.5MB JPEG file	(In reply to comment #6) > I am getting a similar error when trying to download van Gogh: That's covered in bug 44071 instead.	task_subcomment	PHID-TASK-2sndzb2ydzwochmrxplf	["(In reply to comment #6)\nQUOTE\n\nThat's covered in bug 44071 instead."]
98	172134	HTTP 500 error when generating 6000px wide thumbnail of a 6912px wide and 12.5MB JPEG file	DIA.Keyser wrote: I am getting a similar error when trying to download any size larger than 2048px for this van Gogh: http://commons.wikimedia.org/wiki/File:Vincent_van_Gogh_-_De_slaapkamer_-_Google_Art_Project.jpg#file	task_subcomment	PHID-TASK-2sndzb2ydzwochmrxplf	['DIA.Keyser wrote:\n\nI am getting a similar error when trying to download any size larger than 2048px for this van Gogh:\n\nURL']
99	172132	HTTP 500 error when generating 6000px wide thumbnail of a 6912px wide and 12.5MB JPEG file	sumanah wrote: Still reproducible at http://upload.wikimedia.org/wikipedia/commons/thumb/f/f6/Carbon_River_pano_01A.jpg/6565px-Carbon_River_pano_01A.jpg When I change the width: https://upload.wikimedia.org/wikipedia/commons/thumb/f/f6/Carbon_River_pano_01A.jpg/72px-Carbon_River_pano_01A.jpg then it's fine. This may be related to bug 13493 ("Can't create thumbnail of images with a peculiar aspect ratio") and bug 20312 ("Error creating thumbnail: Image was not scaled, is the requested width bigger than the source?").	task_subcomment	PHID-TASK-2sndzb2ydzwochmrxplf	["sumanah wrote:\n\nStill reproducible at\n\nURL\n\nWhen I change the width:\n\nURL\n\nthen it's fine.", 'This may be related to bug 13493 ("Can\'t create thumbnail of images with a peculiar aspect ratio") and bug 20312 ("Error creating thumbnail: Image was not scaled, is the requested width bigger than the source?', '").']
100	172130	HTTP 500 error when generating 6000px wide thumbnail of a 6912px wide and 12.5MB JPEG file	(In reply to comment #3) > my guess is that it's failing to resize to a thumbnail that is 6565 pixels > wide. It works for smaller images. Is it a Wikimedia or a MediaWiki issue then? (Still happening.)	task_subcomment	PHID-TASK-2sndzb2ydzwochmrxplf	['(In reply to comment #3)\nQUOTE\nQUOTE\n\nIs it a Wikimedia or a MediaWiki issue then?', '(Still happening.)']
101	172127	HTTP 500 error when generating 6000px wide thumbnail of a 6912px wide and 12.5MB JPEG file	bhartshorne wrote: my guess is that it's failing to resize to a thumbnail that is 6565 pixels wide. It works for smaller images. fwiw, convert is failing with exit code 153.	task_subcomment	PHID-TASK-2sndzb2ydzwochmrxplf	["bhartshorne wrote:\n\nmy guess is that it's failing to resize to a thumbnail that is 6565 pixels wide.", 'It works for smaller images.', 'fwiw, convert is failing with exit code 153.']
102	172124	HTTP 500 error when generating 6000px wide thumbnail of a 6912px wide and 12.5MB JPEG file	(In reply to comment #1) > XID: 1391948384 This XID value seems to change on page refresh, by the way.	task_subcomment	PHID-TASK-2sndzb2ydzwochmrxplf	['(In reply to comment #1)\nQUOTE\n\nThis XID value seems to change on page refresh, by the way.']
103	172117	HTTP 500 error when generating 6000px wide thumbnail of a 6912px wide and 12.5MB JPEG file	XID: 1391948384	task_subcomment	PHID-TASK-2sndzb2ydzwochmrxplf	['XID: 1391948384']
104	74597	Language selectors looks out of place in alpha login page	alpha login page See image. The language links should be centered (or maybe hidden?). Now they look out of place. -------------------------- Version: unspecified Severity: minor Attached: {F15220}	task_description	PHID-TASK-y6acjoulwnqpli2yepse	['Language selectors looks out of place in alpha login page\n\nalpha login page\n\nSee image.', 'The language links should be centered (or maybe hidden?).', 'Now they look out of place.', '--------------------------\nVersion: unspecified\nSeverity: minor\n\nAttached: {F15220}']
105	329420	Language selectors looks out of place in alpha login page	Yeh this is a result of trying to repurpose the desktop login form in alpha. I've added this to acceptance criteria in https://trello.com/c/jt1O10K2/16-use-desktop-login-account-creation-pages	task_subcomment	PHID-TASK-y6acjoulwnqpli2yepse	['Yeh this is a result of trying to repurpose the desktop login form in alpha.', "I've added this to acceptance criteria in URL"]
106	329415	Language selectors looks out of place in alpha login page	bingle-admin wrote: Prioritization and scheduling of this bug is tracked on Trello card https://trello.com/c/MymsQ4Ns	task_subcomment	PHID-TASK-y6acjoulwnqpli2yepse	['bingle-admin wrote:\n\nPrioritization and scheduling of this bug is tracked on Trello card URL']
107	69667	REST API page on Gerrit loads prettify.js and .css over HTTP	https://gerrit.wikimedia.org/r/Documentation/rest-api.html loads: * http://cdnjs.cloudflare.com/ajax/libs/prettify/r298/prettify.min.js * http://cdnjs.cloudflare.com/ajax/libs/prettify/r298/prettify.min.css cdnjs.cloudflare.com supports HTTPS, so I think we should change the protocol to HTTPS, or remove them entirely because I don't see any visual difference between loading them or not. -------------------------- Version: unspecified Severity: normal	task_description	PHID-TASK-4u7i6vh2ffs42epbda7c	["REST API page on Gerrit loads prettify.js and .css over HTTP\n\nURL loads:\n\n* URL\n* URL\n\ncdnjs.cloudflare.com supports HTTPS, so I think we should change the protocol to HTTPS, or remove them entirely because I don't see any visual difference between loading them or not.", '--------------------------\nVersion: unspecified\nSeverity: normal']
108	75644	Payment processor website uses RC4 for https encryption	Author: `axel+wikimedia` Description: Hi, When trying to make a donation, after entering the amount I wanted to donate I was redirected to a server, ott9.wpstn.com. From what I can tell, it's a WorldPay.ca (payment processor) server. Having configured Firefox to refuse all connections using the RC4 cipher for SSL/TLS (as RC4 is deprecated and considered insecure), I was not able to establish a connection to the server (Firefox shows the “no cipher overlap” error). An SSL test for the domain shows that it indeed offers RC4 (and nothing else): https://www.ssllabs.com/ssltest/analyze.html?d=ott9.wpstn.com This is bad. RC4-encrypted traffic has been likened by some infosec researchers to “no encryption” and the NSA can allegedly break it in real-time. Here is the (very poor) list of ciphers offered by the server: TLS_RSA_WITH_RC4_128_MD5 (0x4) 128 TLS_RSA_WITH_RC4_128_SHA (0x5) 128 TLS_ECDHE_RSA_WITH_RC4_128_SHA (0xc011) ECDH 571 bits (eq. 15360 bits RSA) FS 128 Furthermore, the server is still offering SSLv3. That should also be disabled, following the POODLE vulnerability published about a month ago. The server should be offering modern encryption (forward secrecy, no SSL, strong non-deprecated ciphers). Here is a good guide on how to do it on Apache2: https://raymii.org/s/tutorials/Strong_SSL_Security_On_Apache2.html I hope this can be resolved quickly as the Wikipedia fundraising campaign is ongoing and I don't feel comfortable giving in such conditions nor recommending others do so, even if I believe it is really important they do support Wikipedia, when the payment processor's security is in such a sad state. -------------------------- Version: wmf-deployment Severity: major	task_description	PHID-TASK-rztl5jtgoompxnmhf4iv	['Payment processor website uses RC4 for https encryption\n\nAuthor: CODE\n\nDescription:\nHi,\nWhen trying to make a donation, after entering the amount I wanted to donate I was redirected to a server, ott9.wpstn.com.', "From what I can tell, it's a WorldPay.ca (payment processor) server.", 'Having configured Firefox to refuse all connections using the RC4 cipher for SSL/TLS (as RC4 is deprecated and considered insecure), I was not able to establish a connection to the server (Firefox shows the “no cipher overlap” error).', 'An SSL test for the domain shows that it indeed offers RC4 (and nothing else):\nURL\n\nThis is bad.', 'RC4-encrypted traffic has been likened by some infosec researchers to “no encryption” and the NSA can allegedly break it in real-time.', 'Here is the (very poor) list of ciphers offered by the server:\nTLS_RSA_WITH_RC4_128_MD5 (0x4) \t128\nTLS_RSA_WITH_RC4_128_SHA (0x5) \t128\nTLS_ECDHE_RSA_WITH_RC4_128_SHA (0xc011) ECDH 571 bits (eq.', '15360 bits RSA) FS\t\t128\n\nFurthermore, the server is still offering SSLv3.', 'That should also be disabled, following the POODLE\xa0vulnerability published about a month ago.', 'The server should be offering modern encryption (forward secrecy, no SSL, strong non-deprecated ciphers).', "Here is a good guide on how to do it on Apache2:\nURL\n\nI hope this can be resolved quickly as the Wikipedia fundraising campaign is ongoing and I don't feel comfortable giving in such conditions nor recommending others do so, even if I believe it is really important they do support Wikipedia, when the payment processor's security is in such a sad state.", '--------------------------\nVersion: wmf-deployment\nSeverity: major']
109	341864	Payment processor website uses RC4 for https encryption	It seems they have fixed the issue. They have enabled some cipher suites besides RC4. SSL 3.0 has been disabled. https://www.ssllabs.com/ssltest/analyze.html?d=ott9.wpstn.com	task_subcomment	PHID-TASK-rztl5jtgoompxnmhf4iv	['It seems they have fixed the issue.', 'They have enabled some cipher suites besides RC4.', 'SSL 3.0 has been disabled.', 'URL']
110	339907	Payment processor website uses RC4 for https encryption	Fair enough. Marking as stalled, as we are still waiting for the third party to resolve this issue.	task_subcomment	PHID-TASK-rztl5jtgoompxnmhf4iv	['Fair enough.', 'Marking as stalled, as we are still waiting for the third party to resolve this issue.']
111	339810	Payment processor website uses RC4 for https encryption	Thanks for filing this issue. We don't usually close a bug just because a fix is planned; "Open, stalled" would be a more standard status (I just checked and the issue wasn't resolved yet).	task_subcomment	PHID-TASK-rztl5jtgoompxnmhf4iv	['Thanks for filing this issue.', 'We don\'t usually close a bug just because a fix is planned; "Open, stalled" would be a more standard status (I just checked and the issue wasn\'t resolved yet).']
112	332801	Payment processor website uses RC4 for https encryption	While you may say "it presents very little risk in this context", the real issue here is that the existence of RC4-only servers prevents the clients from disabling RC4 ciphers entirely. Browsers have to support RC4 to make these websites, such as Worldpay, "just work". According to SSL Pulse, 1.4% of sites require RC4, and 27.3% of sites use RC4 with modern browsers. If there were no such 1.4% sites, browsers could have disabled RC4 ciphers by now so that users are immune to RC4 attacks no matter which websites they visit. However, now these 1.4% of websites, including Worldpay, make 27.3% of websites in the world vulnerable to RC4 attacks. You may argue that the 27.3% websites are also wrong in that they support and prioritize RC4 ciphers. That's right. But practically it's easier for RC4-only websites to add more cipher suites, because I see no servers use RC4 only as their default cipher suite list. Anyway, writing this post, I just want to point out that this is a big issue, regardless of whether "it presents very little risk in this context" or not. I hope Worldpay can fix this issue as soon as possible.	task_subcomment	PHID-TASK-rztl5jtgoompxnmhf4iv	['While you may say "it presents very little risk in this context", the real issue here is that the existence of RC4-only servers prevents the clients from disabling RC4 ciphers entirely.', 'Browsers have to support RC4 to make these websites, such as Worldpay, "just work".', 'According to SSL Pulse, 1.4% of sites require RC4, and 27.3% of sites use RC4 with modern browsers.', 'If there were no such 1.4% sites, browsers could have disabled RC4 ciphers by now so that users are immune to RC4 attacks no matter which websites they visit.', 'However, now these 1.4% of websites, including Worldpay, make 27.3% of websites in the world vulnerable to RC4 attacks.', 'You may argue that the 27.3% websites are also wrong in that they support and prioritize RC4 ciphers.', "That's right.", "But practically it's easier for RC4-only websites to add more cipher suites, because I see no servers use RC4 only as their default cipher suite list.", 'Anyway, writing this post, I just want to point out that this is a big issue, regardless of whether "it presents very little risk in this context" or not.', 'I hope Worldpay can fix this issue as soon as possible.']
113	332727	Payment processor website uses RC4 for https encryption	Thank you for raising this issue. While RC4 does have several well-documented vulnerabilities, the best rely on finding short tokens across high volumes of repeated requests, such as session identifiers, which our users don't have with the Worldpay endpoint. Additionally, our Worldpay workflow relies on two endpoints: The public one that you identified, and a private secure endpoint which is used at the beginning of the workflow to issue a one-time token. While RC4 is less than ideal, it presents very little risk in this context. Additionally, we have recently reached out to Worldpay and learned that they are currently in the process of scheduling a maintenance window in the near future, during which time they will be removing RC4 ciphers, adding TLS ciphers to the public endpoint, and disabling SSL 3.0.	task_subcomment	PHID-TASK-rztl5jtgoompxnmhf4iv	['Thank you for raising this issue.', "While RC4 does have several well-documented vulnerabilities, the best rely on finding short tokens across high volumes of repeated requests, such as session identifiers, which our users don't have with the Worldpay endpoint.", 'Additionally, our Worldpay workflow relies on two endpoints: The public one that you identified, and a private secure endpoint which is used at the beginning of the workflow to issue a one-time token.', 'While RC4 is less than ideal, it presents very little risk in this context.', 'Additionally, we have recently reached out to Worldpay and learned that they are currently in the process of scheduling a maintenance window in the near future, during which time they will be removing RC4 ciphers, adding TLS ciphers to the public endpoint, and disabling SSL 3.0.']
114	73621	Not loading site CSS on Special:UserLogin/Preferences breaks wikis which use it to create a skin/theme	Bug 70672 (T72672) fixes the security hole of allowing Javascript in CSS in the Mediawiki namespace. It does this by breaking the functionality of loading CSS when on the Special:UserLogin and Special:Preferences pages. Unfortunately this means that any custom styles are not loaded. To the end user it causes momentarily confusion that they may have been maliciously redirected to a different site to enter their username and password. This is an undesirable side effect for the user interface. I have created an example extension that will prevent saving any custom CSS that contains Javascript imports. https://github.com/Alexia/Bug70672 Example error output: http://imgur.com/a/TnsTY#0 Original bug: https://bugzilla.wikimedia.org/show_bug.cgi?id=70672 -------------------------- Version: 1.23.5 Severity: major See Also: https://bugzilla.wikimedia.org/show_bug.cgi?id=70672	task_description	PHID-TASK-o6thfwgsk54xnsmig6b5	['Not loading site CSS on Special:UserLogin/Preferences breaks wikis which use it to create a skin/theme\n\nBug 70672 (T72672) fixes the security hole of allowing Javascript in CSS in the Mediawiki namespace.', 'It does this by breaking the functionality of loading CSS when on the Special:UserLogin and Special:Preferences pages.', 'Unfortunately this means that any custom styles are not loaded.', 'To the end user it causes momentarily confusion that they may have been maliciously redirected to a different site to enter their username and password.', 'This is an undesirable side effect for the user interface.', 'I have created an example extension that will prevent saving any custom CSS that contains Javascript imports.', 'URL\n\nExample error output:\nURL\n\nOriginal bug:\nURL\n\n--------------------------\nVersion: 1.23.5\nSeverity: major\nSee Also:\nURL']
115	333918	Not loading site CSS on Special:UserLogin/Preferences breaks wikis which use it to create a skin/theme	>>! In T73621#790441, @Aklapper wrote: > I assume this can be closed as fixed now? Yes!	task_subcomment	PHID-TASK-o6thfwgsk54xnsmig6b5	['QUOTE\nQUOTE\n\nYes!']
116	333862	Not loading site CSS on Special:UserLogin/Preferences breaks wikis which use it to create a skin/theme	I assume this can be closed as fixed now?	task_subcomment	PHID-TASK-o6thfwgsk54xnsmig6b5	['I assume this can be closed as fixed now?']
117	333564	Not loading site CSS on Special:UserLogin/Preferences breaks wikis which use it to create a skin/theme	Change 175671 merged by jenkins-bot: Make allowing site-wide styles on restricted special pages a config option [[https://gerrit.wikimedia.org/r/175671]]	task_subcomment	PHID-TASK-o6thfwgsk54xnsmig6b5	['Change 175671 merged by jenkins-bot:\nMake allowing site-wide styles on restricted special pages a config option\n\n[[GERRIT_URL]]']
118	332921	Not loading site CSS on Special:UserLogin/Preferences breaks wikis which use it to create a skin/theme	Change 174018 merged by Mglaser: Make allowing site-wide styles on restricted special pages a config option [[https://gerrit.wikimedia.org/r/174018]]	task_subcomment	PHID-TASK-o6thfwgsk54xnsmig6b5	['Change 174018 merged by Mglaser:\nMake allowing site-wide styles on restricted special pages a config option\n\n[[GERRIT_URL]]']
119	332916	Not loading site CSS on Special:UserLogin/Preferences breaks wikis which use it to create a skin/theme	Change 174014 merged by Mglaser: Make allowing site-wide styles on restricted special pages a config option [[https://gerrit.wikimedia.org/r/174014]]	task_subcomment	PHID-TASK-o6thfwgsk54xnsmig6b5	['Change 174014 merged by Mglaser:\nMake allowing site-wide styles on restricted special pages a config option\n\n[[GERRIT_URL]]']
120	332912	Not loading site CSS on Special:UserLogin/Preferences breaks wikis which use it to create a skin/theme	Change 175671 had a related patch set uploaded (by Mglaser): Make allowing site-wide styles on restricted special pages a config option [[https://gerrit.wikimedia.org/r/175671]] #patch-for-review	task_subcomment	PHID-TASK-o6thfwgsk54xnsmig6b5	['Change 175671 had a related patch set uploaded (by Mglaser):\nMake allowing site-wide styles on restricted special pages a config option\n\n[[GERRIT_URL]]\n\n#patch-for-review']
121	321388	Not loading site CSS on Special:UserLogin/Preferences breaks wikis which use it to create a skin/theme	I uploaded patches for REL1_24, REL1_23, and REL1_22. I started on REL1_19 and then it got all scary so I stopped. I'm not sure what to do about @since 1.25 tags, so I left them as they are.	task_subcomment	PHID-TASK-o6thfwgsk54xnsmig6b5	['I uploaded patches for REL1_24, REL1_23, and REL1_22.', 'I started on REL1_19 and then it got all scary so I stopped.', "I'm not sure what to do aboutSCREEN_NAME 1.25 tags, so I left them as they are."]
122	321385	Not loading site CSS on Special:UserLogin/Preferences breaks wikis which use it to create a skin/theme	gerritadmin wrote: Change 174018 had a related patch set uploaded by Legoktm: Make allowing site-wide styles on restricted special pages a config option https://gerrit.wikimedia.org/r/174018	task_subcomment	PHID-TASK-o6thfwgsk54xnsmig6b5	['gerritadmin wrote:\n\nChange 174018 had a related patch set uploaded by Legoktm:\nMake allowing site-wide styles on restricted special pages a config option\n\nGERRIT_URL']
123	321382	Not loading site CSS on Special:UserLogin/Preferences breaks wikis which use it to create a skin/theme	gerritadmin wrote: Change 174014 had a related patch set uploaded by Legoktm: Make allowing site-wide styles on restricted special pages a config option https://gerrit.wikimedia.org/r/174014	task_subcomment	PHID-TASK-o6thfwgsk54xnsmig6b5	['gerritadmin wrote:\n\nChange 174014 had a related patch set uploaded by Legoktm:\nMake allowing site-wide styles on restricted special pages a config option\n\nGERRIT_URL']
124	321378	Not loading site CSS on Special:UserLogin/Preferences breaks wikis which use it to create a skin/theme	gerritadmin wrote: Change 174012 had a related patch set uploaded by Legoktm: Make allowing site-wide styles on restricted special pages a config option https://gerrit.wikimedia.org/r/174012	task_subcomment	PHID-TASK-o6thfwgsk54xnsmig6b5	['gerritadmin wrote:\n\nChange 174012 had a related patch set uploaded by Legoktm:\nMake allowing site-wide styles on restricted special pages a config option\n\nGERRIT_URL']
125	321374	Not loading site CSS on Special:UserLogin/Preferences breaks wikis which use it to create a skin/theme	I believe that this is great news and having a configuration setting for this [1] is great and very much acceptable. Thanks a ton for making this possible! Since this went to master I think this change should be backported to the 1.19, 1.23 and 1.24 branches. [1] https://www.mediawiki.org/wiki/Manual:$wgAllowSiteCSSOnRestrictedPages	task_subcomment	PHID-TASK-o6thfwgsk54xnsmig6b5	['I believe that this is great news and having a configuration setting for this [1] is great and very much acceptable.', 'Thanks a ton for making this possible!', 'Since this went to master I think this change should be backported to the 1.19, 1.23 and 1.24 branches.', '[1] URL']
126	321370	Not loading site CSS on Special:UserLogin/Preferences breaks wikis which use it to create a skin/theme	gerritadmin wrote: Change 165979 merged by jenkins-bot: Make allowing site-wide styles on restricted special pages a config option https://gerrit.wikimedia.org/r/165979	task_subcomment	PHID-TASK-o6thfwgsk54xnsmig6b5	['gerritadmin wrote:\n\nChange 165979 merged by jenkins-bot:\nMake allowing site-wide styles on restricted special pages a config option\n\nGERRIT_URL']
127	321366	Not loading site CSS on Special:UserLogin/Preferences breaks wikis which use it to create a skin/theme	Kunal's fix here makes sense to me. Perhaps the ideal would be that everyone who sets up a wiki has full time developers available to help style their site, but the fact is that CSS and JS are known and used by amateurs to produce the effects they want. Restricting that ability causes problems for end users. As far as security, it makes sense to keep user js/css off these pages, but MediaWiki: namespaced js/css should be available and is, by default, more tightly controlled. Since the problem that is solved here is visible on WikiApiary, I'm going to ask Jamie Thingelstad to test the patch there and merge it if it solves the problem.	task_subcomment	PHID-TASK-o6thfwgsk54xnsmig6b5	["Kunal's fix here makes sense to me.", 'Perhaps the ideal would be that everyone who sets up a wiki has full time developers available to help style their site, but the fact is that CSS and JS are known and used by amateurs to produce the effects they want.', 'Restricting that ability causes problems for end users.', 'As far as security, it makes sense to keep user js/css off these pages, but MediaWiki: namespaced js/css should be available and is, by default, more tightly controlled.', "Since the problem that is solved here is visible on WikiApiary, I'm going to ask Jamie Thingelstad to test the patch there and merge it if it solves the problem."]
128	321362	Not loading site CSS on Special:UserLogin/Preferences breaks wikis which use it to create a skin/theme	Is there no really easier way to suppress disasbling MediaWiki NS CSS when Special:Preferences is loaded? Only I can edit the MW NS. I see no risk...	task_subcomment	PHID-TASK-o6thfwgsk54xnsmig6b5	['Is there no really easier way to suppress disasbling MediaWiki NS CSS when Special:Preferences is loaded?', 'Only I can edit the MW NS.', 'I see no risk...']
129	321358	Not loading site CSS on Special:UserLogin/Preferences breaks wikis which use it to create a skin/theme	For the record, these last few comments were mostly to provide more context, data and factor of influence. I don't feel it's appropriate for me to make a decision about this.	task_subcomment	PHID-TASK-o6thfwgsk54xnsmig6b5	['For the record, these last few comments were mostly to provide more context, data and factor of influence.', "I don't feel it's appropriate for me to make a decision about this."]
130	321352	Not loading site CSS on Special:UserLogin/Preferences breaks wikis which use it to create a skin/theme	(In reply to Krinkle from comment #9) > (In reply to Kunal Mehta (Legoktm) from comment #7) > > (In reply to Krinkle from comment #5) > > > This would result in loading only part of a module, which is in my opinion > > > against expectations. > > > > We already serve only the CSS of the module to no-JS users, so it's not > > totally against expectations. > > > > No we don't. Only for exceptional modules that are designed specifically to > be a base module without javascript, loaded explicitly via addModuleStyles, > thus bypassing ResourceLoader. If you're loading a regular module containing > javascript files via addModuleStyles, you're doing it wrong. It doesn't > throw an exception for that right now, but we should if that helps. > > When writing css rules in a stylesheet loaded by ResourceLoader one should > be able to assume javascript execution alongside of it. > For the 'site' module you are absolutely right of course. In general a module is either executed regularly (addModules/mw.loader.load) or styles only (e.g. Vector skin; addModuleStyles/load.php only=styles). In case of the 'site' wiki-page module, it is loaded with both addModuleStyles and addModuleScripts separately because the scripts have to execute in the global javascript context for legacy reasons, and Common.css historically is both the companion of Common.js as well as the standalone stylesheet for wiki content (e.g. infobox, or fallback styles for collapsible elements).	task_subcomment	PHID-TASK-o6thfwgsk54xnsmig6b5	["(In reply to Krinkle from comment #9)\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\n\nFor the 'site' module you are absolutely right of course.", 'In general a module is either executed regularly (addModules/mw.loader.load) or styles only (e.g.', 'Vector skin; addModuleStyles/load.php only=styles).', "In case of the 'site' wiki-page module, it is loaded with both addModuleStyles and addModuleScripts separately because the scripts have to execute in the global javascript context for legacy reasons, and Common.css historically is both the companion of Common.js as well as the standalone stylesheet for wiki content (e.g.", 'infobox, or fallback styles for collapsible elements).']
131	321345	Not loading site CSS on Special:UserLogin/Preferences breaks wikis which use it to create a skin/theme	The main issue is that it is such a long standing feature that breaking it in security patch without notification to end users is not acceptable. Then dragging along not issuing a recall on the patch or providing a corrected patch is also not acceptable.	task_subcomment	PHID-TASK-o6thfwgsk54xnsmig6b5	['The main issue is that it is such a long standing feature that breaking it in security patch without notification to end users is not acceptable.', 'Then dragging along not issuing a recall on the patch or providing a corrected patch is also not acceptable.']
132	321341	Not loading site CSS on Special:UserLogin/Preferences breaks wikis which use it to create a skin/theme	(In reply to Kunal Mehta (Legoktm) from comment #7) > (In reply to Krinkle from comment #5) > > This would result in loading only part of a module, which is in my opinion > > against expectations. > > We already serve only the CSS of the module to no-JS users, so it's not > totally against expectations. > No we don't. Only for exceptional modules that are designed specifically to be a base module without javascript, loaded explicitly via addModuleStyles, thus bypassing ResourceLoader. If you're loading a regular module containing javascript files via addModuleStyles, you're doing it wrong. It doesn't throw an exception for that right now, but we should if that helps. When writing css rules in a stylesheet loaded by ResourceLoader one should be able to assume javascript execution alongside of it. (In reply to Kunal Mehta (Legoktm) from comment #7) > Those might be reasonable changes for the future, but I don't think it's > okay to do such a major change without proper notice/release notes, and > definitely not appropriate to do in a security patch. I agree. But on the other hand one could also argue we never supported this in the first place. The community never asked to make usability and design decisions for the software interface. And contrary to the usual case, it's actually smaller wikis that do this, not the larger language editions of Wikipedia. Which I suspect might be due to lack of peer review and a wider audience to notice the (possibly negative) impact of a such a change. I'm not arguing that though. It's been too years since Common.css was added and these wikis started doing it to take it back now. Should the community ask for a feature if there's an existing exploit they can use to emulate a requested feature? (e.g. if Common.css was limited to content area and content pages, this would never be possible and we'd have to consider it as an actual feature, which we probably wouldn't allow for good reasons on WMF. The intent to improve the interface is completely valid however and we'd actively help those wikis improve their interface from the software perspective instead, it's merely about the implementation details here, not about the actual visual changes to interface).	task_subcomment	PHID-TASK-o6thfwgsk54xnsmig6b5	["(In reply to Kunal Mehta (Legoktm) from comment #7)\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\n\nNo we don't.", 'Only for exceptional modules that are designed specifically to be a base module without javascript, loaded explicitly via addModuleStyles, thus bypassing ResourceLoader.', "If you're loading a regular module containing javascript files via addModuleStyles, you're doing it wrong.", "It doesn't throw an exception for that right now, but we should if that helps.", 'When writing css rules in a stylesheet loaded by ResourceLoader one should be able to assume javascript execution alongside of it.', '(In reply to Kunal Mehta (Legoktm) from comment #7)\nQUOTE\nQUOTE\nQUOTE\n\nI agree.', 'But on the other hand one could also argue we never supported this in the first place.', 'The community never asked to make usability and design decisions for the software interface.', "And contrary to the usual case, it's actually smaller wikis that do this, not the larger language editions of Wikipedia.", 'Which I suspect might be due to lack of peer review and a wider audience to notice the (possibly negative) impact of a such a change.', "I'm not arguing that though.", "It's been too years since Common.css was added and these wikis started doing it to take it back now.", "Should the community ask for a feature if there's an existing exploit they can use to emulate a requested feature?", '(e.g.', "if Common.css was limited to content area and content pages, this would never be possible and we'd have to consider it as an actual feature, which we probably wouldn't allow for good reasons on WMF.", "The intent to improve the interface is completely valid however and we'd actively help those wikis improve their interface from the software perspective instead, it's merely about the implementation details here, not about the actual visual changes to interface)."]
133	321334	Not loading site CSS on Special:UserLogin/Preferences breaks wikis which use it to create a skin/theme	So what's next? How do we get all the affected wikis out of their current misery? This bug should not be a back-burner thing as it looks like at the moment. I think the MW software should allow wikis to adapt the overall appearance without having to use a custom skin. So far the easiest way was to use Common.css/js etc. which is no longer working for integral pages such as the login and preferences. I think the proposed change tries to address this issue. Another possibility may probably be an extension that allows placing custom CSS- and/or JS-file(s) on the server which is then packed into a resource loader module loaded by the extension. This may perhaps also be a setting in MW core which allows to point to the respective file(s) and then does the same job. Perhaps there are other ways.	task_subcomment	PHID-TASK-o6thfwgsk54xnsmig6b5	["So what's next?", 'How do we get all the affected wikis out of their current misery?', 'This bug should not be a back-burner thing as it looks like at the moment.', 'I think the MW software should allow wikis to adapt the overall appearance without having to use a custom skin.', 'So far the easiest way was to use Common.css/js etc.', 'which is no longer working for integral pages such as the login and preferences.', 'I think the proposed change tries to address this issue.', 'Another possibility may probably be an extension that allows placing custom CSS- and/or JS-file(s) on the server which is then packed into a resource loader module loaded by the extension.', 'This may perhaps also be a setting in MW core which allows to point to the respective file(s) and then does the same job.', 'Perhaps there are other ways.']
134	321329	Not loading site CSS on Special:UserLogin/Preferences breaks wikis which use it to create a skin/theme	(In reply to Krinkle from comment #5) > This would result in loading only part of a module, which is in my opinion > against expectations. We already serve only the CSS of the module to no-JS users, so it's not totally against expectations. > > I don't like escalating a relatively simple bug into a social problem, but I > think this is one of those cases where that is appropriate. > > Maybe we should discourage people from theming their wiki to this extreme > via this method? Third parties should add a stylesheet via LocalSettings > instead of Common.css. > > This should be done by a developer instead (especially for third parties). Part of the problem is that AFAIK there is no good/easy way to do that outside of a) writing your own skin (overkill in most cases), b) directly editing the skin stylesheets, which we really don't want people to do. > > For Wikimedia sites, I'd like to think that, while it's kind of > undocumented, that people really should not significantly change the site > interface. Users should not be able to notice a difference outside the > content area when the styles are not loaded. > > That thing about people thinking it's a different site, that goes both ways. > When they visit that different language edition, should that be allowed to > look like a completely different website? > > Main reason being that the software interface is provided by MediaWiki core. > If there are problems there, they should be reported to the software and > addressed accordingly. Things can be iterated and tried in gadgets, but for > something so central to the software, it either shouldn't be done (e.g. bad > idea), or should be done (good idea) and done in the software itself so that > it may benefit a wider audience (and usually a higher quality result in > terms of browser support, user experience, performance and maintainability). > > Something as fundamental as the site font, for example. That's either a > personal preference one could question whether it's responsible for users to > override, or there's a technical reason (eg. their wiki's language doesn't > render well in the font we choose by default) - in which case we shouldn't > put that burden on them. By all means that is a high priority problem for > the foundation and MediaWiki software to address. > > There have also been proposals in the past to technically restrict the > ability of MediaWiki:Common.css to affect anything outside page content, but > that hasn't gotten anywhere. And I'm also not convinced that that'd be a > good thing. There's plenty of grey area where it's technically outside the > content area, but part of a larger customisation that doesn't interfere with > the software interface. Those might be reasonable changes for the future, but I don't think it's okay to do such a major change without proper notice/release notes, and definitely not appropriate to do in a security patch.	task_subcomment	PHID-TASK-o6thfwgsk54xnsmig6b5	["(In reply to Krinkle from comment #5)\nQUOTE\nQUOTE\n\nWe already serve only the CSS of the module to no-JS users, so it's not totally against expectations.", "QUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\n\nPart of the problem is that AFAIK there is no good/easy way to do that outside of a) writing your own skin (overkill in most cases), b) directly editing the skin stylesheets, which we really don't want people to do.", "QUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\n\nThose might be reasonable changes for the future, but I don't think it's okay to do such a major change without proper notice/release notes, and definitely not appropriate to do in a security patch."]
135	321323	Not loading site CSS on Special:UserLogin/Preferences breaks wikis which use it to create a skin/theme	(In reply to Krinkle from comment #5) > Maybe we should discourage people from theming their wiki to this extreme > via this method? Third parties should add a stylesheet via LocalSettings > instead of Common.css. People use Common.css and Skin.css to theme their wikis only because MediaWiki doesn't provide any proper way to do it on-wiki. For a single site that you're running yourself, making or installing a custom skin is good. But for wiki farms where individual communities run wikis where they do not have FTP access, they need the theme to be editable on-wiki.	task_subcomment	PHID-TASK-o6thfwgsk54xnsmig6b5	["(In reply to Krinkle from comment #5)\nQUOTE\nQUOTE\nQUOTE\n\nPeople use Common.css and Skin.css to theme their wikis only because MediaWiki doesn't provide any proper way to do it on-wiki.", "For a single site that you're running yourself, making or installing a custom skin is good.", 'But for wiki farms where individual communities run wikis where they do not have FTP access, they need the theme to be editable on-wiki.']
136	321316	Not loading site CSS on Special:UserLogin/Preferences breaks wikis which use it to create a skin/theme	This would result in loading only part of a module, which is in my opinion against expectations. I don't like escalating a relatively simple bug into a social problem, but I think this is one of those cases where that is appropriate. Maybe we should discourage people from theming their wiki to this extreme via this method? Third parties should add a stylesheet via LocalSettings instead of Common.css. This should be done by a developer instead (especially for third parties). For Wikimedia sites, I'd like to think that, while it's kind of undocumented, that people really should not significantly change the site interface. Users should not be able to notice a difference outside the content area when the styles are not loaded. That thing about people thinking it's a different site, that goes both ways. When they visit that different language edition, should that be allowed to look like a completely different website? Main reason being that the software interface is provided by MediaWiki core. If there are problems there, they should be reported to the software and addressed accordingly. Things can be iterated and tried in gadgets, but for something so central to the software, it either shouldn't be done (e.g. bad idea), or should be done (good idea) and done in the software itself so that it may benefit a wider audience (and usually a higher quality result in terms of browser support, user experience, performance and maintainability). Something as fundamental as the site font, for example. That's either a personal preference one could question whether it's responsible for users to override, or there's a technical reason (eg. their wiki's language doesn't render well in the font we choose by default) - in which case we shouldn't put that burden on them. By all means that is a high priority problem for the foundation and MediaWiki software to address. There have also been proposals in the past to technically restrict the ability of MediaWiki:Common.css to affect anything outside page content, but that hasn't gotten anywhere. And I'm also not convinced that that'd be a good thing. There's plenty of grey area where it's technically outside the content area, but part of a larger customisation that doesn't interfere with the software interface.	task_subcomment	PHID-TASK-o6thfwgsk54xnsmig6b5	['This would result in loading only part of a module, which is in my opinion against expectations.', "I don't like escalating a relatively simple bug into a social problem, but I think this is one of those cases where that is appropriate.", 'Maybe we should discourage people from theming their wiki to this extreme via this method?', 'Third parties should add a stylesheet via LocalSettings instead of Common.css.', 'This should be done by a developer instead (especially for third parties).', "For Wikimedia sites, I'd like to think that, while it's kind of undocumented, that people really should not significantly change the site interface.", 'Users should not be able to notice a difference outside the content area when the styles are not loaded.', "That thing about people thinking it's a different site, that goes both ways.", 'When they visit that different language edition, should that be allowed to look like a completely different website?', 'Main reason being that the software interface is provided by MediaWiki core.', 'If there are problems there, they should be reported to the software and addressed accordingly.', "Things can be iterated and tried in gadgets, but for something so central to the software, it either shouldn't be done (e.g.", 'bad idea), or should be done (good idea) and done in the software itself so that it may benefit a wider audience (and usually a higher quality result in terms of browser support, user experience, performance and maintainability).', 'Something as fundamental as the site font, for example.', "That's either a personal preference one could question whether it's responsible for users to override, or there's a technical reason (eg.", "their wiki's language doesn't render well in the font we choose by default) - in which case we shouldn't put that burden on them.", 'By all means that is a high priority problem for the foundation and MediaWiki software to address.', "There have also been proposals in the past to technically restrict the ability of MediaWiki:Common.css to affect anything outside page content, but that hasn't gotten anywhere.", "And I'm also not convinced that that'd be a good thing.", "There's plenty of grey area where it's technically outside the content area, but part of a larger customisation that doesn't interfere with the software interface."]
137	321312	Not loading site CSS on Special:UserLogin/Preferences breaks wikis which use it to create a skin/theme	gerritadmin wrote: Change 165979 had a related patch set uploaded by Legoktm: Re-enable site-wide styles on Special:Preferences/UserLogin https://gerrit.wikimedia.org/r/165979	task_subcomment	PHID-TASK-o6thfwgsk54xnsmig6b5	['gerritadmin wrote:\n\nChange 165979 had a related patch set uploaded by Legoktm:\nRe-enable site-wide styles on Special:Preferences/UserLogin\n\nGERRIT_URL']
138	321308	Not loading site CSS on Special:UserLogin/Preferences breaks wikis which use it to create a skin/theme	Yes, this is needed on fa, ckb, arz, glk, mzn, ps, pnb. Why? Because all of these wikis are overriding default browser defined sans-serif font on their Common.css and it is needed their UI would be consistent on preference and eventually login/logout also.	task_subcomment	PHID-TASK-o6thfwgsk54xnsmig6b5	['Yes, this is needed on fa, ckb, arz, glk, mzn, ps, pnb.', 'Why?', 'Because all of these wikis are overriding default browser defined sans-serif font on their Common.css and it is needed their UI would be consistent on preference and eventually login/logout also.']
139	321302	Not loading site CSS on Special:UserLogin/Preferences breaks wikis which use it to create a skin/theme	Many scripts/styles run on a site level; it does not make sense that they do not work on two pages. CSS is used e.g. in Arabic Wikipedia to adjust general font size and fix a bunch of directionality issues.	task_subcomment	PHID-TASK-o6thfwgsk54xnsmig6b5	['Many scripts/styles run on a site level; it does not make sense that they do not work on two pages.', 'CSS is used e.g.', 'in Arabic Wikipedia to adjust general font size and fix a bunch of directionality issues.']
140	321295	Not loading site CSS on Special:UserLogin/Preferences breaks wikis which use it to create a skin/theme	Also bawolff's email: https://lists.wikimedia.org/pipermail/wikitech-l/2014-October/078903.html	task_subcomment	PHID-TASK-o6thfwgsk54xnsmig6b5	["Also bawolff's email: URL"]
141	62315	Requests from ssl terminators not present in sampled-1000 tsvs, and mobile-sampled-1000 tsvs	Although requests from ssl terminators are visible in the udp2log stream when consuming directly, and also in the edit tsvs [1], none are visible in the sampled-1000 tsv [2] or the mobile-sampled-100 tsvs [3]. Due to the numbers exposed by the edit tsv we'd expect >1000 lines/day from ssl terminators in the sampled-1000 tsvs, and >500 lines/day in the mobile-sampled-100 tsvs due to the edit requests alone. Are those two streams suffering the same problem as edit tsvs suffered before 2014-01-14 (bug 60314)? Let's get the ssl requests into the sampled-1000 and mobile-sampled-100 tsvs! (I've been told sampled-1000 is collected independently on two different hosts. Is the one that does not get mirrored to stat1002 also affected? Not sure which those hosts are. The udp2log filters live in https://git.wikimedia.org/tree/operations%2Fpuppet/production/templates%2Fudp2log ) [1] ___________________________________________________________ qchris@stat1002 // 0 // 00:36:41 cwd: ~ zgrep -c '^ssl' /a/squid/archive/edits/edits.tsv.log-20140121.gz 1358968 [2] ___________________________________________________________ qchris@stat1002 // 0 // 22:14:02 cwd: ~ zgrep -c '^ssl' /a/squid/archive/sampled/sampled-1000.tsv.log-201401.gz /a/squid/archive/sampled/sampled-1000.tsv.log-20140101.gz:0 /a/squid/archive/sampled/sampled-1000.tsv.log-20140102.gz:0 [...] /a/squid/archive/sampled/sampled-1000.tsv.log-20140113.gz:0 /a/squid/archive/sampled/sampled-1000.tsv.log-20140114.gz:0 /a/squid/archive/sampled/sampled-1000.tsv.log-20140115.gz:0 /a/squid/archive/sampled/sampled-1000.tsv.log-20140116.gz:0 /a/squid/archive/sampled/sampled-1000.tsv.log-20140117.gz:0 /a/squid/archive/sampled/sampled-1000.tsv.log-20140118.gz:0 /a/squid/archive/sampled/sampled-1000.tsv.log-20140119.gz:0 /a/squid/archive/sampled/sampled-1000.tsv.log-20140120.gz:0 /a/squid/archive/sampled/sampled-1000.tsv.log-20140121.gz:0 [3] ___________________________________________________________ qchris@stat1002 // 0 // 22:47:06 cwd: ~ zgrep -c '^ssl' /a/squid/archive/mobile/mobile-sampled-100.tsv.log-201401.gz /a/squid/archive/mobile/mobile-sampled-100.tsv.log-20140101.gz:0 /a/squid/archive/mobile/mobile-sampled-100.tsv.log-20140102.gz:0 /a/squid/archive/mobile/mobile-sampled-100.tsv.log-20140103.gz:0 /a/squid/archive/mobile/mobile-sampled-100.tsv.log-20140104.gz:0 /a/squid/archive/mobile/mobile-sampled-100.tsv.log-20140105.gz:0 /a/squid/archive/mobile/mobile-sampled-100.tsv.log-20140107.gz:0 /a/squid/archive/mobile/mobile-sampled-100.tsv.log-20140108.gz:0 /a/squid/archive/mobile/mobile-sampled-100.tsv.log-20140109.gz:0 /a/squid/archive/mobile/mobile-sampled-100.tsv.log-20140110.gz:1 /a/squid/archive/mobile/mobile-sampled-100.tsv.log-20140111.gz:0 /a/squid/archive/mobile/mobile-sampled-100.tsv.log-20140112.gz:0 /a/squid/archive/mobile/mobile-sampled-100.tsv.log-20140113.gz:0 /a/squid/archive/mobile/mobile-sampled-100.tsv.log-20140114.gz:0 /a/squid/archive/mobile/mobile-sampled-100.tsv.log-20140115.gz:0 /a/squid/archive/mobile/mobile-sampled-100.tsv.log-20140116.gz:0 /a/squid/archive/mobile/mobile-sampled-100.tsv.log-20140117.gz:0 /a/squid/archive/mobile/mobile-sampled-100.tsv.log-20140118.gz:0 /a/squid/archive/mobile/mobile-sampled-100.tsv.log-20140119.gz:1 /a/squid/archive/mobile/mobile-sampled-100.tsv.log-20140120.gz:2 /a/squid/archive/mobile/mobile-sampled-100.tsv.log-20140121.gz:0 The four matches from the 201401{10,19,20} files are artifacts from an ssl terminator request line being too long and getting messed up with a subsequent mobile request line. -------------------------- Version: unspecified Severity: normal	task_description	PHID-TASK-2y2k45wukaju6uyrp23s	['Requests from ssl terminators not present in sampled-1000 tsvs, and mobile-sampled-1000 tsvs\n\nAlthough requests from ssl terminators are visible in the udp2log\nstream when consuming directly, and also in the edit tsvs [1], none\nare visible in the sampled-1000 tsv [2] or the mobile-sampled-100\ntsvs [3].', "Due to the numbers exposed by the edit tsv we'd expect >1000 lines/day\nfrom ssl terminators in the sampled-1000 tsvs, and >500 lines/day in\nthe mobile-sampled-100 tsvs due to the edit requests alone.", 'Are those two streams suffering the same problem as edit tsvs suffered\nbefore 2014-01-14 (bug 60314)?', "Let's get the ssl requests into the sampled-1000 and\nmobile-sampled-100 tsvs!", "(I've been told sampled-1000 is collected independently on two\ndifferent hosts.", 'Is the one that does not get mirrored to stat1002\nalso affected?', 'Not sure which those hosts are.', "The udp2log filters\nlive in\nURL\n)\n\n\n[1]\n___________________________________________________________\nqchris@stat1002 // 0 // 00:36:41 \ncwd: ~\nzgrep -c '^ssl' /a/squid/archive/edits/edits.tsv.log-20140121.gz\n1358968\n\n\n[2]\n___________________________________________________________\nqchris@stat1002 // 0 // 22:14:02 \ncwd: ~\nzgrep -c '^ssl' /a/squid/archive/sampled/sampled-1000.tsv.log-201401.gz\n/a/squid/archive/sampled/sampled-1000.tsv.log-20140101.gz:0\n/a/squid/archive/sampled/sampled-1000.tsv.log-20140102.gz:0\n[...]\n/a/squid/archive/sampled/sampled-1000.tsv.log-20140113.gz:0\n/a/squid/archive/sampled/sampled-1000.tsv.log-20140114.gz:0\n/a/squid/archive/sampled/sampled-1000.tsv.log-20140115.gz:0\n/a/squid/archive/sampled/sampled-1000.tsv.log-20140116.gz:0\n/a/squid/archive/sampled/sampled-1000.tsv.log-20140117.gz:0\n/a/squid/archive/sampled/sampled-1000.tsv.log-20140118.gz:0\n/a/squid/archive/sampled/sampled-1000.tsv.log-20140119.gz:0\n/a/squid/archive/sampled/sampled-1000.tsv.log-20140120.gz:0\n/a/squid/archive/sampled/sampled-1000.tsv.log-20140121.gz:0\n\n\n[3]\n___________________________________________________________\nqchris@stat1002 // 0 // 22:47:06 \ncwd: ~\nzgrep -c '^ssl' /a/squid/archive/mobile/mobile-sampled-100.tsv.log-201401.gz\n/a/squid/archive/mobile/mobile-sampled-100.tsv.log-20140101.gz:0\n/a/squid/archive/mobile/mobile-sampled-100.tsv.log-20140102.gz:0\n/a/squid/archive/mobile/mobile-sampled-100.tsv.log-20140103.gz:0\n/a/squid/archive/mobile/mobile-sampled-100.tsv.log-20140104.gz:0\n/a/squid/archive/mobile/mobile-sampled-100.tsv.log-20140105.gz:0\n/a/squid/archive/mobile/mobile-sampled-100.tsv.log-20140107.gz:0\n/a/squid/archive/mobile/mobile-sampled-100.tsv.log-20140108.gz:0\n/a/squid/archive/mobile/mobile-sampled-100.tsv.log-20140109.gz:0\n/a/squid/archive/mobile/mobile-sampled-100.tsv.log-20140110.gz:1\n/a/squid/archive/mobile/mobile-sampled-100.tsv.log-20140111.gz:0\n/a/squid/archive/mobile/mobile-sampled-100.tsv.log-20140112.gz:0\n/a/squid/archive/mobile/mobile-sampled-100.tsv.log-20140113.gz:0\n/a/squid/archive/mobile/mobile-sampled-100.tsv.log-20140114.gz:0\n/a/squid/archive/mobile/mobile-sampled-100.tsv.log-20140115.gz:0\n/a/squid/archive/mobile/mobile-sampled-100.tsv.log-20140116.gz:0\n/a/squid/archive/mobile/mobile-sampled-100.tsv.log-20140117.gz:0\n/a/squid/archive/mobile/mobile-sampled-100.tsv.log-20140118.gz:0\n/a/squid/archive/mobile/mobile-sampled-100.tsv.log-20140119.gz:1\n/a/squid/archive/mobile/mobile-sampled-100.tsv.log-20140120.gz:2\n/a/squid/archive/mobile/mobile-sampled-100.tsv.log-20140121.gz:0\n\n\nThe four matches from the 201401{10,19,20} files are artifacts from an\nssl terminator request line being too long and getting messed up with\na subsequent mobile request line.", '--------------------------\nVersion: unspecified\nSeverity: normal']
142	284243	Requests from ssl terminators not present in sampled-1000 tsvs, and mobile-sampled-1000 tsvs	bingle-admin wrote: Prioritization and scheduling of this bug is tracked on Mingle card https://wikimedia.mingle.thoughtworks.com/projects/analytics/cards/cards/1399	task_subcomment	PHID-TASK-2y2k45wukaju6uyrp23s	['bingle-admin wrote:\n\nPrioritization and scheduling of this bug is tracked on Mingle card URL']
143	284239	Requests from ssl terminators not present in sampled-1000 tsvs, and mobile-sampled-1000 tsvs	ottomata said that nginx might log only to gadolinium, while sampled-1000 gets written only on emery.	task_subcomment	PHID-TASK-2y2k45wukaju6uyrp23s	['ottomata said that nginx might log only to gadolinium, while\nsampled-1000 gets written only on emery.']
144	110411	login.py doesnt recognise * in config.usernames	With an entry like follows in `user-config.py` ``` usernames['wikipedia'][''] = 'JVbot-test' ``` `login.py` emits a error ``` $ python pwb.py login -all Logged in on wikipedia:test as JVbot-test. .wikipedia is not a valid site, please remove it from your config ```	task_description	PHID-TASK-xxhid5r4jxhawqqzajzb	['login.py doesnt recognise * in config.usernames\n\nWith an entry like follows in CODE\n``CODE`CODElogin.pyCODE`CODE``']
145	2490111	login.py doesnt recognise * in config.usernames	Change #1112370 had a related patch set uploaded (by Xqt; author: Xqt): %%%[pywikibot/core@master] login.py: Recognise * in config.usernames%%% https://gerrit.wikimedia.org/r/1112370	task_subcomment	PHID-TASK-xxhid5r4jxhawqqzajzb	['Change #1112370 had a related patch set uploaded (by Xqt; author: Xqt):\n%%%[pywikibot/core@master] login.py: Recognise * in config.usernames%%%\nGERRIT_URL']
146	845352	login.py doesnt recognise * in config.usernames	It can really be practical.	task_subcomment	PHID-TASK-xxhid5r4jxhawqqzajzb	['It can really be practical.']
147	815603	login.py doesnt recognise * in config.usernames	Change 339806 abandoned by Dalba: login.py: Recognise * in config.usernames Reason: May take a long time to login to all sites. Maybe we can take advantage of CentralAuth. Needs further investigation. [[https://gerrit.wikimedia.org/r/339806]]	task_subcomment	PHID-TASK-xxhid5r4jxhawqqzajzb	['Change 339806 abandoned by Dalba:\nlogin.py: Recognise * in config.usernames\n\nReason:\nMay take a long time to login to all sites.', 'Maybe we can take advantage of CentralAuth.', 'Needs further investigation.', '[[GERRIT_URL]]']
148	815594	login.py doesnt recognise * in config.usernames	Change 339806 had a related patch set uploaded (by Dalba): login.py: Recognise * in config.usernames [[https://gerrit.wikimedia.org/r/339806]]	task_subcomment	PHID-TASK-xxhid5r4jxhawqqzajzb	['Change 339806 had a related patch set uploaded (by Dalba):\nlogin.py: Recognise * in config.usernames\n\n[[GERRIT_URL]]']
149	815573	login.py doesnt recognise * in config.usernames	Currently I get: ``` $ python pwb.py login -all *.wikipedia is not a valid site, please remove it from your config Traceback (most recent call last): File "pwb.py", line 263, in <module> if not main(): File "pwb.py", line 257, in main run_python_file(filename, [filename] + args, argvu, file_package) File "pwb.py", line 121, in run_python_file main_mod.__dict__) File ".\scripts\login.py", line 193, in <module> main() File ".\scripts\login.py", line 166, in main for familyName in namedict: RuntimeError: dictionary changed size during iteration <class 'RuntimeError'> CRITICAL: Closing network session. ```	task_subcomment	PHID-TASK-xxhid5r4jxhawqqzajzb	['Currently I get:\n\n``CODE``']
150	101814	PHP Fatal error: include(): Cannot redeclare class psr\log\loggerinterface in /vendor/composer/ClassLoader.php:412	After update from 1.24 series to 1.25, I started having this error on certain pages. Currently the error shows up when I click Upload at the File Upload page (which is Dosya Yükle in Turkish translation), among others. I did follow documentation on the release notes; MediaWiki was first installed from tarball, then I tried the git-compose install/update method. The psr directory exists in $IP/vendor. > MediaWiki requires the PSR-3 logging library to be present. This library is not embedded directly in MediaWiki's git repository and must be installed separately by the end user. Please see mediawiki.org for help on installing the required components.MediaWiki requires the PSR-3 logging library to be present. This library is not embedded directly in MediaWiki's git repository and must be installed separately by the end user. Please see mediawiki.org for help on installing the required components. I can reproduce the error. Mediawiki error report: > ( ! ) Fatal error: include(): Cannot redeclare class psr\log\loggerinterface in > /srv/www/mywiki.mydomain.com/vendor/composer/ClassLoader.php on line 412 > Call Stack > # Time Memory Function Location > 1 0.0001 241112 {main}( ) ../index.php:0 > 2 2.9770 2424544 MediaWiki->run( ) ../index.php:41 > 3 2.9770 2425104 MediaWiki->main( ) ../MediaWiki.php:414 > 4 3.0107 3203232 MediaWiki->performRequest( ) ../MediaWiki.php:566 > 5 3.0343 3415968 SpecialPageFactory::executePath( ) ../MediaWiki.php:267 > 6 3.0433 3966400 SpecialPage->run( ) ../SpecialPageFactory.php:582 > 7 3.0434 3966496 SpecialUpload->execute( ) ../SpecialPage.php:384 > 8 3.1018 5433712 SpecialUpload->processUpload( ) ../SpecialUpload.php:195 > 9 4.3216 7132504 SpecialUpload->showUploadWarning( ) ../SpecialUpload.php:458 > 10 4.3406 7381440 SpecialUpload->getDupeWarning( ) ../SpecialUpload.php:368 > 11 4.3538 7501392 TraditionalImageGallery->toHTML( ) ../SpecialUpload.php:748 > 12 4.3599 7838880 Linker::processResponsiveImages( ) ../TraditionalImageGallery.php:136 > 13 4.3625 7842584 File->transform( ) ../Linker.php:895 > 14 4.3644 7858520 File->generateAndSaveThumb( ) ../File.php:1079 > 15 4.3647 7860640 TransformationalImageHandler->doTransform( ) ../File.php:1112 > 16 4.3658 7866960 BitmapHandler->transformImageMagick( ) ../TransformationalImageHandler.php:244 > 17 4.3658 7868760 TransformationalImageHandler->getMagickVersion( ) ../Bitmap.php:91 > 18 4.3659 7869648 wfDebug( ) ../TransformationalImageHandler.php:517 > 19 4.3659 7870024 MediaWiki\Logger\LoggerFactory::getInstance( ) ../GlobalFunctions.php:1055 > 20 4.3659 7870120 interface_exists ( ) ../LoggerFactory.php:97 > 21 4.3659 7870440 Composer\Autoload\ClassLoader->loadClass( ) ../LoggerFactory.php:0 > 22 4.3659 7870440 Composer\Autoload\includeFile( ) ../ClassLoader.php:301 > MediaWiki requires the PSR-3 logging library to be present. This library is not embedded directly in MediaWiki's git repository and must be installed separately by the end user. Please see mediawiki.org for help on installing the required components.MediaWiki requires the PSR-3 logging library to be present. This library is not embedded directly in MediaWiki's git repository and must be installed separately by the end user. Please see mediawiki.org for help on installing the required components. > ( ! ) Fatal error: MediaWiki requires the <a href="https://github.com/php-fig/log">PSR-3 logging library</a> to be present. This library is not embedded directly in MediaWiki's git repository and must be installed separately by the end user. Please see <a href="https://www.mediawiki.org/wiki/Download_from_Git#Fetch_external_libraries">mediawiki.org</a> for help on installing the required components. in /srv/www/mywiki.mydomain.com/includes/debug/logger/LoggerFactory.php on line 107 > Call Stack > # Time Memory Function Location > 1 0.0001 241112 {main}( ) ../index.php:0 > 2 2.9770 2424544 MediaWiki->run( ) ../index.php:41 > 3 2.9770 2425104 MediaWiki->main( ) ../MediaWiki.php:414 > 4 3.0107 3203232 MediaWiki->performRequest( ) ../MediaWiki.php:566 > 5 3.0343 3415968 SpecialPageFactory::executePath( ) ../MediaWiki.php:267 > 6 3.0433 3966400 SpecialPage->run( ) ../SpecialPageFactory.php:582 > 7 3.0434 3966496 SpecialUpload->execute( ) ../SpecialPage.php:384 > 8 3.1018 5433712 SpecialUpload->processUpload( ) ../SpecialUpload.php:195 > 9 4.3216 7132504 SpecialUpload->showUploadWarning( ) ../SpecialUpload.php:458 > 10 4.3406 7381440 SpecialUpload->getDupeWarning( ) ../SpecialUpload.php:368 > 11 4.3538 7501392 TraditionalImageGallery->toHTML( ) ../SpecialUpload.php:748 > 12 4.3599 7838880 Linker::processResponsiveImages( ) ../TraditionalImageGallery.php:136 > 13 4.3625 7842584 File->transform( ) ../Linker.php:895 > 14 4.3644 7858520 File->generateAndSaveThumb( ) ../File.php:1079 > 15 4.3647 7860640 TransformationalImageHandler->doTransform( ) ../File.php:1112 > 16 4.3658 7866960 BitmapHandler->transformImageMagick( ) ../TransformationalImageHandler.php:244 > 17 4.3658 7868760 TransformationalImageHandler->getMagickVersion( ) ../Bitmap.php:91 > 18 4.3659 7869648 wfDebug( ) ../TransformationalImageHandler.php:517 > 19 4.3659 7870024 MediaWiki\Logger\LoggerFactory::getInstance( ) ../GlobalFunctions.php:1055 > 20 4.3659 7870120 interface_exists ( ) ../LoggerFactory.php:97 > 21 4.3659 7870440 Composer\Autoload\ClassLoader->loadClass( ) ../LoggerFactory.php:0 > 22 4.3659 7870440 Composer\Autoload\includeFile( ) ../ClassLoader.php:301 > 23 4.3676 7880328 MWExceptionHandler::handleFatalError( ) ../MWExceptionHandler.php:0 > 24 4.3676 7866992 MWExceptionHandler::logError( ) ../MWExceptionHandler.php:265 > 25 4.3678 7869072 wfDebugLog( ) ../MWExceptionHandler.php:507 > 26 4.3678 7869608 MediaWiki\Logger\LoggerFactory::getInstance( ) ../GlobalFunctions.php:1155 > 27 4.3678 7870160 trigger_error ( ) ../LoggerFactory.php:107 > 28 4.3678 7871592 MWExceptionHandler::handleError( ) ../LoggerFactory.php:107 > 29 4.3679 7883192 MWExceptionHandler::logError( ) ../MWExceptionHandler.php:222 > 30 4.3680 7886192 wfDebugLog( ) ../MWExceptionHandler.php:507 > 31 4.3680 7887656 MediaWiki\Logger\LoggerFactory::getInstance( ) ../GlobalFunctions.php:1155 > 32 4.3680 7888208 trigger_error ( ) ../LoggerFactory.php:107 > And Apache error when I try/refresh the relevant page(s): > [Thu May 28 06:55:06 2015] [error] [client 192.168.1.1] PHP Fatal error: include(): Cannot redeclare class > psr\\log\\loggerinterface in /srv/www/mywiki.mydomain.com/vendor/composer/ClassLoader.php on line 412, referer: http://mywiki.mydomain.com/index.php/%C3%96zel:%C3%96zelSayfalar > [Thu May 28 06:55:06 2015] [error] [client 192.168.1.1] PHP Stack trace:, referer: http://mywiki.mydomain.com/index.php/%C3%96zel:%C3%96zelSayfalar > [Thu May 28 06:55:06 2015] [error] [client 192.168.1.1] PHP 1. {main}() /srv/www/mywiki.mydomain.com/index.php:0, referer: http://mywiki.mydomain.com/index.php/%C3%96zel:%C3%96zelSayfalar > [Thu May 28 06:55:06 2015] [error] [client 192.168.1.1] PHP 2. MediaWiki->run() /srv/www/mywiki.mydomain.com/index.php:41, referer: http://mywiki.mydomain.com/index.php/%C3%96zel:%C3%96zelSayfalar > [Thu May 28 06:55:06 2015] [error] [client 192.168.1.1] PHP 3. MediaWiki->main() /srv/www/mywiki.mydomain.com/includes/MediaWiki.php:414, referer: http://mywiki.mydomain.com/index.php/%C3%96zel:%C3%96zelSayfalar > [Thu May 28 06:55:06 2015] [error] [client 192.168.1.1] PHP 4. MediaWiki->performRequest() /srv/www/mywiki.mydomain.com/includes/MediaWiki.php:566, referer: http://mywiki.mydomain.com/index.php/%C3%96zel:%C3%96zelSayfalar > [Thu May 28 06:55:06 2015] [error] [client 192.168.1.1] PHP 5. SpecialPageFactory::executePath() /srv/www/mywiki.mydomain.com/includes/MediaWiki.php:267, referer: http://mywiki.mydomain.com/index.php/%C3%96zel:%C3%96zelSayfalar > [Thu May 28 06:55:06 2015] [error] [client 192.168.1.1] PHP 6. SpecialPage->run() /srv/www/mywiki.mydomain.com/includes/specialpage/SpecialPageFactory.php:582, referer: http://mywiki.mydomain.com/index.php/%C3%96zel:%C3%96zelSayfalar > [Thu May 28 06:55:06 2015] [error] [client 192.168.1.1] PHP 7. SpecialVersion->execute() /srv/www/mywiki.mydomain.com/includes/specialpage/SpecialPage.php:384, referer: http://mywiki.mydomain.com/index.php/%C3%96zel:%C3%96zelSayfalar > [Thu May 28 06:55:06 2015] [error] [client 192.168.1.1] PHP 8. SpecialVersion->getExtensionCredits() /srv/www/mywiki.mydomain.com/includes/specials/SpecialVersion.php:129, referer: http://mywiki.mydomain.com/index.php/%C3%96zel:%C3%96zelSayfalar > [Thu May 28 06:55:06 2015] [error] [client 192.168.1.1] PHP 9. SpecialVersion->getExtensionCategory() /srv/www/mywiki.mydomain.com/includes/specials/SpecialVersion.php:463, referer: http://mywiki.mydomain.com/index.php/%C3%96zel:%C3%96zelSayfalar > [Thu May 28 06:55:06 2015] [error] [client 192.168.1.1] PHP 10. SpecialVersion->getCreditsForExtension() /srv/www/mywiki.mydomain.com/includes/specials/SpecialVersion.php:637, referer: http://mywiki.mydomain.com/index.php/%C3%96zel:%C3%96zelSayfalar > [Thu May 28 06:55:06 2015] [error] [client 192.168.1.1] PHP 11. GitInfo->getHeadCommitDate() /srv/www/mywiki.mydomain.com/includes/specials/SpecialVersion.php:743, referer: http://mywiki.mydomain.com/index.php/%C3%96zel:%C3%96zelSayfalar > [Thu May 28 06:55:06 2015] [error] [client 192.168.1.1] PHP 12. wfShellExec() /srv/www/mywiki.mydomain.com/includes/GitInfo.php:218, referer: http://mywiki.mydomain.com/index.php/%C3%96zel:%C3%96zelSayfalar > [Thu May 28 06:55:06 2015] [error] [client 192.168.1.1] PHP 13. wfDebug() /srv/www/mywiki.mydomain.com/includes/GlobalFunctions.php:2802, referer: http://mywiki.mydomain.com/index.php/%C3%96zel:%C3%96zelSayfalar > [Thu May 28 06:55:06 2015] [error] [client 192.168.1.1] PHP 14. MediaWiki\\Logger\\LoggerFactory::getInstance() /srv/www/mywiki.mydomain.com/includes/GlobalFunctions.php:1055, referer: http://mywiki.mydomain.com/index.php/%C3%96zel:%C3%96zelSayfalar > [Thu May 28 06:55:06 2015] [error] [client 192.168.1.1] PHP 15. interface_exists() /srv/www/mywiki.mydomain.com/includes/debug/logger/LoggerFactory.php:97, referer: http://mywiki.mydomain.com/index.php/%C3%96zel:%C3%96zelSayfalar > [Thu May 28 06:55:06 2015] [error] [client 192.168.1.1] PHP 16. Composer\\Autoload\\ClassLoader->loadClass() /srv/www/mywiki.mydomain.com/includes/debug/logger/LoggerFactory.php:0, referer: http://mywiki.mydomain.com/index.php/%C3%96zel:%C3%96zelSayfalar > [Thu May 28 06:55:06 2015] [error] [client 192.168.1.1] PHP 17. Composer\\Autoload\\includeFile() /srv/www/mywiki.mydomain.com/vendor/composer/ClassLoader.php:301, referer: http://mywiki.mydomain.com/index.php/%C3%96zel:%C3%96zelSayfalar > [Thu May 28 06:55:06 2015] [error] [client 192.168.1.1] PHP Fatal error: MediaWiki requires the <a href="https://github.com/php-fig/log">PSR-3 logging library</a> to be present. This library is not embedded directly in MediaWiki's git repository and must be installed separately by the end user.\n\nPlease see <a href="https://www.mediawiki.org/wiki/Download_from_Git#Fetch_external_libraries">mediawiki.org</a> for help on installing the required components. in /srv/www/mywiki.mydomain.com/includes/debug/logger/LoggerFactory.php on line 107, referer: http://mywiki.mydomain.com/index.php/%C3%96zel:%C3%96zelSayfalar > [Thu May 28 06:55:06 2015] [error] [client 192.168.1.1] PHP Stack trace:, referer: http://mywiki.mydomain.com/index.php/%C3%96zel:%C3%96zelSayfalar > [Thu May 28 06:55:06 2015] [error] [client 192.168.1.1] PHP 1. {main}() /srv/www/mywiki.mydomain.com/index.php:0, referer: http://mywiki.mydomain.com/index.php/%C3%96zel:%C3%96zelSayfalar > [Thu May 28 06:55:06 2015] [error] [client 192.168.1.1] PHP 2. MediaWiki->run() /srv/www/mywiki.mydomain.com/index.php:41, referer: http://mywiki.mydomain.com/index.php/%C3%96zel:%C3%96zelSayfalar > [Thu May 28 06:55:06 2015] [error] [client 192.168.1.1] PHP 3. MediaWiki->main() /srv/www/mywiki.mydomain.com/includes/MediaWiki.php:414, referer: http://mywiki.mydomain.com/index.php/%C3%96zel:%C3%96zelSayfalar > [Thu May 28 06:55:06 2015] [error] [client 192.168.1.1] PHP 4. MediaWiki->performRequest() /srv/www/mywiki.mydomain.com/includes/MediaWiki.php:566, referer: http://mywiki.mydomain.com/index.php/%C3%96zel:%C3%96zelSayfalar > [Thu May 28 06:55:06 2015] [error] [client 192.168.1.1] PHP 5. SpecialPageFactory::executePath() /srv/www/mywiki.mydomain.com/includes/MediaWiki.php:267, referer: http://mywiki.mydomain.com/index.php/%C3%96zel:%C3%96zelSayfalar > [Thu May 28 06:55:06 2015] [error] [client 192.168.1.1] PHP 6. SpecialPage->run() /srv/www/mywiki.mydomain.com/includes/specialpage/SpecialPageFactory.php:582, referer: http://mywiki.mydomain.com/index.php/%C3%96zel:%C3%96zelSayfalar > [Thu May 28 06:55:06 2015] [error] [client 192.168.1.1] PHP 7. SpecialVersion->execute() /srv/www/mywiki.mydomain.com/includes/specialpage/SpecialPage.php:384, referer: http://mywiki.mydomain.com/index.php/%C3%96zel:%C3%96zelSayfalar > [Thu May 28 06:55:06 2015] [error] [client 192.168.1.1] PHP 8. SpecialVersion->getExtensionCredits() /srv/www/mywiki.mydomain.com/includes/specials/SpecialVersion.php:129, referer: http://mywiki.mydomain.com/index.php/%C3%96zel:%C3%96zelSayfalar > [Thu May 28 06:55:06 2015] [error] [client 192.168.1.1] PHP 9. SpecialVersion->getExtensionCategory() /srv/www/mywiki.mydomain.com/includes/specials/SpecialVersion.php:463, referer: http://mywiki.mydomain.com/index.php/%C3%96zel:%C3%96zelSayfalar > [Thu May 28 06:55:06 2015] [error] [client 192.168.1.1] PHP 10. SpecialVersion->getCreditsForExtension() /srv/www/mywiki.mydomain.com/includes/specials/SpecialVersion.php:637, referer: http://mywiki.mydomain.com/index.php/%C3%96zel:%C3%96zelSayfalar > [Thu May 28 06:55:06 2015] [error] [client 192.168.1.1] PHP 11. GitInfo->getHeadCommitDate() /srv/www/mywiki.mydomain.com/includes/specials/SpecialVersion.php:743, referer: http://mywiki.mydomain.com/index.php/%C3%96zel:%C3%96zelSayfalar > [Thu May 28 06:55:06 2015] [error] [client 192.168.1.1] PHP 12. wfShellExec() /srv/www/mywiki.mydomain.com/includes/GitInfo.php:218, referer: http://mywiki.mydomain.com/index.php/%C3%96zel:%C3%96zelSayfalar > [Thu May 28 06:55:06 2015] [error] [client 192.168.1.1] PHP 13. wfDebug() /srv/www/mywiki.mydomain.com/includes/GlobalFunctions.php:2802, referer: http://mywiki.mydomain.com/index.php/%C3%96zel:%C3%96zelSayfalar > [Thu May 28 06:55:06 2015] [error] [client 192.168.1.1] PHP 14. MediaWiki\\Logger\\LoggerFactory::getInstance() /srv/www/mywiki.mydomain.com/includes/GlobalFunctions.php:1055, referer: http://mywiki.mydomain.com/index.php/%C3%96zel:%C3%96zelSayfalar > [Thu May 28 06:55:06 2015] [error] [client 192.168.1.1] PHP 15. interface_exists() /srv/www/mywiki.mydomain.com/includes/debug/logger/LoggerFactory.php:97, referer: http://mywiki.mydomain.com/index.php/%C3%96zel:%C3%96zelSayfalar > [Thu May 28 06:55:06 2015] [error] [client 192.168.1.1] PHP 16. Composer\\Autoload\\ClassLoader->loadClass() /srv/www/mywiki.mydomain.com/includes/debug/logger/LoggerFactory.php:0, referer: http://mywiki.mydomain.com/index.php/%C3%96zel:%C3%96zelSayfalar > [Thu May 28 06:55:06 2015] [error] [client 192.168.1.1] PHP 17. Composer\\Autoload\\includeFile() /srv/www/mywiki.mydomain.com/vendor/composer/ClassLoader.php:301, referer: http://mywiki.mydomain.com/index.php/%C3%96zel:%C3%96zelSayfalar > [Thu May 28 06:55:06 2015] [error] [client 192.168.1.1] PHP 18. MWExceptionHandler::handleFatalError() /srv/www/mywiki.mydomain.com/includes/exception/MWExceptionHandler.php:0, referer: http://mywiki.mydomain.com/index.php/%C3%96zel:%C3%96zelSayfalar > [Thu May 28 06:55:06 2015] [error] [client 192.168.1.1] PHP 19. MWExceptionHandler::logError() /srv/www/mywiki.mydomain.com/includes/exception/MWExceptionHandler.php:265, referer: http://mywiki.mydomain.com/index.php/%C3%96zel:%C3%96zelSayfalar > [Thu May 28 06:55:06 2015] [error] [client 192.168.1.1] PHP 20. wfDebugLog() /srv/www/mywiki.mydomain.com/includes/exception/MWExceptionHandler.php:507, referer: http://mywiki.mydomain.com/index.php/%C3%96zel:%C3%96zelSayfalar > [Thu May 28 06:55:06 2015] [error] [client 192.168.1.1] PHP 21. MediaWiki\\Logger\\LoggerFactory::getInstance() /srv/www/mywiki.mydomain.com/includes/GlobalFunctions.php:1155, referer: http://mywiki.mydomain.com/index.php/%C3%96zel:%C3%96zelSayfalar > [Thu May 28 06:55:06 2015] [error] [client 192.168.1.1] PHP 22. trigger_error() /srv/www/mywiki.mydomain.com/includes/debug/logger/LoggerFactory.php:107, referer: http://mywiki.mydomain.com/index.php/%C3%96zel:%C3%96zelSayfalar > [Thu May 28 06:55:06 2015] [error] [client 192.168.1.1] PHP 23. MWExceptionHandler::handleError() /srv/www/mywiki.mydomain.com/includes/debug/logger/LoggerFactory.php:107, referer: http://mywiki.mydomain.com/index.php/%C3%96zel:%C3%96zelSayfalar > [Thu May 28 06:55:06 2015] [error] [client 192.168.1.1] PHP 24. MWExceptionHandler::logError() /srv/www/mywiki.mydomain.com/includes/exception/MWExceptionHandler.php:222, referer: http://mywiki.mydomain.com/index.php/%C3%96zel:%C3%96zelSayfalar > [Thu May 28 06:55:06 2015] [error] [client 192.168.1.1] PHP 25. wfDebugLog() /srv/www/mywiki.mydomain.com/includes/exception/MWExceptionHandler.php:507, referer: http://mywiki.mydomain.com/index.php/%C3%96zel:%C3%96zelSayfalar > [Thu May 28 06:55:06 2015] [error] [client 192.168.1.1] PHP 26. MediaWiki\\Logger\\LoggerFactory::getInstance() /srv/www/mywiki.mydomain.com/includes/GlobalFunctions.php:1155, referer: http://mywiki.mydomain.com/index.php/%C3%96zel:%C3%96zelSayfalar > [Thu May 28 06:55:06 2015] [error] [client 192.168.1.1] PHP 27. trigger_error() /srv/www/mywiki.mydomain.com/includes/debug/logger/LoggerFactory.php:107, referer: http://mywiki.mydomain.com/index.php/%C3%96zel:%C3%96zelSayfalar >	task_description	PHID-TASK-horp6gl436aa5in2kxna	['PHP Fatal error: include(): Cannot redeclare class psr\\log\\loggerinterface in /vendor/composer/ClassLoader.php:412\n\nAfter update from 1.24 series to 1.25, I started having this error on certain pages.', 'Currently the error shows up when I click Upload at the File Upload page (which is Dosya Yükle in Turkish translation), among others.', 'I did follow documentation on the release notes; MediaWiki was first installed from tarball, then I tried the git-compose install/update method.', 'The psr directory exists in $IP/vendor.', 'QUOTE\n\nI can reproduce the error.', 'Mediawiki error report: \n\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\n\n\nAnd Apache error when I try/refresh the relevant page(s): \n\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE']
151	901975	PHP Fatal error: include(): Cannot redeclare class psr\log\loggerinterface in /vendor/composer/ClassLoader.php:412	Declining... Nobody cared to reply and MW1.25 is no longer supported	task_subcomment	PHID-TASK-horp6gl436aa5in2kxna	['Declining... Nobody cared to reply and MW1.25 is no longer supported']
152	699501	PHP Fatal error: include(): Cannot redeclare class psr\log\loggerinterface in /vendor/composer/ClassLoader.php:412	>>! In T101814#1407843, @Krinkle wrote: > Perhaps you have an older extension installed that also ships a PSR-3 interface? @emirhan: Can you answer this? Is this still an issue?	task_subcomment	PHID-TASK-horp6gl436aa5in2kxna	['QUOTE\nQUOTE\nSCREEN_NAME: Can you answer this?', 'Is this still an issue?']
153	677081	PHP Fatal error: include(): Cannot redeclare class psr\log\loggerinterface in /vendor/composer/ClassLoader.php:412	>>! In T101814#1407843, @Krinkle wrote: > Perhaps you have an older extension installed that also ships a PSR-3 interface? @emirhan: Can you answer this? Is this still an issue?	task_subcomment	PHID-TASK-horp6gl436aa5in2kxna	['QUOTE\nQUOTE\nSCREEN_NAME: Can you answer this?', 'Is this still an issue?']
154	483075	PHP Fatal error: include(): Cannot redeclare class psr\log\loggerinterface in /vendor/composer/ClassLoader.php:412	The error you reported does not mean PSR-3 is not installed. In fact, it means the opposite. The error shows that the `vendor/` directory exists and contains the PSR-3 class. However when it loads it, it claims it is a redeclaration. In other words, it has been defined by something else. And then when MediaWiki tries to load its own, it ends up loading a second time. Loading the same class twice is not possible and as such the engine aborts with a fatal error. Perhaps you have an older extension installed that also ships a PSR-3 interface?	task_subcomment	PHID-TASK-horp6gl436aa5in2kxna	['The error you reported does not mean PSR-3 is not installed.', 'In fact, it means the opposite.', 'The error shows that the CODE directory exists and contains the PSR-3 class.', 'However when it loads it, it claims it is a redeclaration.', 'In other words, it has been defined by something else.', 'And then when MediaWiki tries to load its own, it ends up loading a second time.', 'Loading the same class twice is not possible and as such the engine aborts with a fatal error.', 'Perhaps you have an older extension installed that also ships a PSR-3 interface?']
155	480752	PHP Fatal error: include(): Cannot redeclare class psr\log\loggerinterface in /vendor/composer/ClassLoader.php:412	Update. I think I narrowed it down to the images directory. When I move the images directory (which holds images as well as PDFs, PPTs) from the installation directory, the issue seems to be solved. When I move the directory back, the error starts again. I also tried the maintenance/importImages.php script for importing the images from the old installation directory (instead of simply copying). No luck.	task_subcomment	PHID-TASK-horp6gl436aa5in2kxna	['Update.', 'I think I narrowed it down to the images directory.', 'When I move the images directory (which holds images as well as PDFs, PPTs) from the installation directory, the issue seems to be solved.', 'When I move the directory back, the error starts again.', 'I also tried the maintenance/importImages.php script for importing the images from the old installation directory (instead of simply copying).', 'No luck.']
156	471322	PHP Fatal error: include(): Cannot redeclare class psr\log\loggerinterface in /vendor/composer/ClassLoader.php:412	(Sorry lcawte; mid-air collision when editing)	task_subcomment	PHID-TASK-horp6gl436aa5in2kxna	['(Sorry lcawte; mid-air collision when editing)']

142 KiB Raw Blame History

142 KiB

Raw Blame History