618 KiB
618 KiB
id,task_title,comment_text,comment_type,TaskPHID,cleaned_sentences,focal_sentence,human_label
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.. \n\nScreenshot\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.', '--------------------------\n**Version**: unspecified\n**Severity**: normal\n\n**Attached**: {F11430}']","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.",OBSERVED BUG BEHAVIOR
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.. \n\nScreenshot\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.', '--------------------------\n**Version**: unspecified\n**Severity**: normal\n\n**Attached**: {F11430}']","Even when the window is closed, this persists for all subsequent loadings of the references tool on that page.",OBSERVED BUG BEHAVIOR
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.. \n\nScreenshot\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.', '--------------------------\n**Version**: unspecified\n**Severity**: normal\n\n**Attached**: {F11430}']","Windows 7, Firefox 22.",BUG REPRODUCTION
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.. \n\nScreenshot\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.', '--------------------------\n**Version**: unspecified\n**Severity**: normal\n\n**Attached**: {F11430}']","--------------------------
**Version**: unspecified
**Severity**: normal
**Attached**: {F11430}",MOTIVATION
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.'],This has been fixed since July; sorry for slow update.,TASK PROGRESS
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.', '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.', '--------------------------\n**Version**: unspecified\n**Severity**: enhancement']",VisualEditor: Expose build number.,OBSERVED BUG BEHAVIOR
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.', '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.', '--------------------------\n**Version**: unspecified\n**Severity**: enhancement']",Quite often we get bug reports for issues that have been recently fixed but not deployed to the smaller wikis.,MOTIVATION
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.', '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.', '--------------------------\n**Version**: unspecified\n**Severity**: enhancement']",It would be very useful if we had build numbers that we could access (e.g.,MOTIVATION
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.', '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.', '--------------------------\n**Version**: unspecified\n**Severity**: enhancement']",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.,EXPECTED BEHAVIOR
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.', '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.', '--------------------------\n**Version**: unspecified\n**Severity**: enhancement']","--------------------------
**Version**: unspecified
**Severity**: enhancement",MOTIVATION
569455,VisualEditor: Expose build number,FYI - This might be removed in {T119750},task_subcomment,PHID-TASK-p4b2w3x4lqa7c5xyypgv,['FYI - This might be removed in {T119750}'],FYI - This might be removed in {T119750},SOLUTION DISCUSSION
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'],"Change 84334 merged by jenkins-bot:
Hide version info if not available
GERRIT_URL",TASK PROGRESS
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'],"Change 84334 had a related patch set uploaded by Esanders:
Hide version info if not available
GERRIT_URL",TASK PROGRESS
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.""]","Yes, there's an issue with our deployment process which prevents it from working ATM.",SOLUTION DISCUSSION
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.""]",We're working on a fix.,CONTRIBUTION AND COMMITMENT
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).']",This isn't working.,SOLUTION DISCUSSION
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).']","When I click on ""Beta"" to see this, it says ""Version false"", with a link to URL (from userspace) or URL (from article space).",OBSERVED BUG BEHAVIOR
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'],"Change 81877 merged by jenkins-bot:
Expose version information in the client
GERRIT_URL",TASK PROGRESS
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'],"Change 81877 had a related patch set uploaded by Esanders:
Expose version information in the client
GERRIT_URL",TASK PROGRESS
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."", 'Given 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.]"", '--------------------------\n**Version**: unspecified\n**Severity**: normal']",VisualEditor: Autocompletion for template names doesn't work in RTL.,OBSERVED BUG BEHAVIOR
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."", 'Given 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.]"", '--------------------------\n**Version**: unspecified\n**Severity**: normal']","Given that I'm editing an article in an RTL wiki: URL
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.",EXPECTED BEHAVIOR
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."", 'Given 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.]"", '--------------------------\n**Version**: unspecified\n**Severity**: normal']",This bug is quite similar to Bug 51490.,OBSERVED BUG BEHAVIOR
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."", 'Given 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.]"", '--------------------------\n**Version**: unspecified\n**Severity**: normal']",[This was an experiment with writing bug reports as Cucumber-style test scenarios.,ISSUE CONTENT MANAGEMENT
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."", 'Given 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.]"", '--------------------------\n**Version**: unspecified\n**Severity**: normal']",Let me know if you don't like it.],SOCIAL CONVERSATION
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."", 'Given 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.]"", '--------------------------\n**Version**: unspecified\n**Severity**: normal']","--------------------------
**Version**: unspecified
**Severity**: normal",MOTIVATION
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!']",Done and will be deployed tomorrow.,TASK PROGRESS
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!']","Thanks, Moriel!",SOCIAL CONVERSATION
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'],"This bug will be fixed with this patchset: URL
See also URL",ACTION ON ISSUE
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.', 'In this case, URL - oh dear.', '--------------------------\n**Version**: unspecified\n**Severity**: major']",VisualEditor: broken <table> syntax causes VE to inject additional <table> html.,OBSERVED BUG BEHAVIOR
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.', 'In this case, URL - oh dear.', '--------------------------\n**Version**: unspecified\n**Severity**: major']","In this case, URL - oh dear.",BUG REPRODUCTION
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.', 'In this case, URL - oh dear.', '--------------------------\n**Version**: unspecified\n**Severity**: major']","--------------------------
**Version**: unspecified
**Severity**: major",MOTIVATION
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 ***'],"
*** This bug has been marked as a duplicate of bug 51217 ***",ACTION ON ISSUE
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']","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.",OBSERVED BUG BEHAVIOR
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']",Upping priority/importance as it should at least ignore elements it doesnt properly understand.,ACTION ON ISSUE
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']",The <table> was not so broken that the wikitext up to the </table> should have been ignored.,INVESTIGATION AND EXPLORATION
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']","I am able to reproduce the '<tr' being added [[testwiki:User:John_Vandenberg/Table_test]], but in my test the table wasnt copied.",BUG REPRODUCTION
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']","After fixing the syntax on enwp, the problem goes away.",SOLUTION USAGE
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']",URL,BUG REPRODUCTION
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.', ""It's a no-op, and is confusing."", '(But is it more confusing to list it?)', '--------------------------\n**Version**: unspecified\n**Severity**: enhancement']","VisualEditor: ""Move this category here"" should not appear for the last category.",EXPECTED BEHAVIOR
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.', ""It's a no-op, and is confusing."", '(But is it more confusing to list it?)', '--------------------------\n**Version**: unspecified\n**Severity**: enhancement']","It's a no-op, and is confusing.",EXPECTED BEHAVIOR
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.', ""It's a no-op, and is confusing."", '(But is it more confusing to list it?)', '--------------------------\n**Version**: unspecified\n**Severity**: enhancement']",(But is it more confusing to list it?),SOCIAL CONVERSATION
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.', ""It's a no-op, and is confusing."", '(But is it more confusing to list it?)', '--------------------------\n**Version**: unspecified\n**Severity**: enhancement']","--------------------------
**Version**: unspecified
**Severity**: enhancement",MOTIVATION
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]'],GERRIT_URL (Gerrit Change If48e001b92c217bee0a35b6da41d1c1ff0e3271c) | change APPROVED and MERGED [by jenkins-bot],TASK PROGRESS
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)'],Related URL: GERRIT_URL (Gerrit Change If48e001b92c217bee0a35b6da41d1c1ff0e3271c),SOLUTION DISCUSSION
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)'],Related URL: GERRIT_URL (Gerrit Change If48e001b92c217bee0a35b6da41d1c1ff0e3271c),SOLUTION DISCUSSION
230738,"VisualEditor: ""Move this category here"" should not appear for the last category",Now merged.,task_subcomment,PHID-TASK-isog5p3qki3pp25ezf63,['Now merged.'],Now merged.,ACTION ON ISSUE
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)'],Related URL: GERRIT_URL (Gerrit Change I93ce05f7cbb28313a3f0827539f0528c366aeb7e),SOLUTION DISCUSSION
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.', 'Go 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--------------------------\n**Version**: unspecified\n**Severity**: normal']","VisualEditor: Enter 2 times, Backspace 2 times -> not deleted in Firefox.",OBSERVED BUG BEHAVIOR
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.', 'Go 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--------------------------\n**Version**: unspecified\n**Severity**: normal']","Go to URL
Put the cursor somewhere in the text.",BUG REPRODUCTION
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.', 'Go 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--------------------------\n**Version**: unspecified\n**Severity**: normal']","Type ""Enter"" 2 times.",BUG REPRODUCTION
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.', 'Go 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--------------------------\n**Version**: unspecified\n**Severity**: normal']","Type ""Backspace"" 2 times.",BUG REPRODUCTION
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.', 'Go 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--------------------------\n**Version**: unspecified\n**Severity**: normal']","Expected: as original
Actually: The newlines remain
--------------------------
**Version**: unspecified
**Severity**: normal",EXPECTED BEHAVIOR
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.'],This is now fixed in live.,TASK PROGRESS
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.'],"Just reproduced on Firefox 21.0 / fresh install of Ubuntu Linux 2013.04
Nothing special appears in the web console.",BUG REPRODUCTION
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.']",Browser information highly welcome.,INVESTIGATION AND EXPLORATION
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.']",Reopening for the time being.,ACTION ON ISSUE
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...']",When will the master fixes be deployed?,TASK PROGRESS
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...']","The situation is now horrible in production, with so many bugs that I am wondering whether it is even worth reporting them...",OBSERVED BUG BEHAVIOR
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.']","I just tried, it is a worse problem now, text is lost.",OBSERVED BUG BEHAVIOR
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.""]","**orbit** wrote:
I'm not able to reproduce this one either.",BUG REPRODUCTION
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.""]",I experience other problems relating to Enter and Backspace on Firefox (fixed in Master) but not what you've described.,INVESTIGATION AND EXPLORATION
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.""]","I'm going to close this ticket, but please reopen if you have additional information.",ACTION ON ISSUE
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.', 'Reporting 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.', '--------------------------\n**Version**: unspecified\n**Severity**: normal']",VisualEditor: trouble with Template:Hlist.,OBSERVED BUG BEHAVIOR
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.', 'Reporting 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.', '--------------------------\n**Version**: unspecified\n**Severity**: normal']","Reporting user comment, some formatting is mine:
<<I made this URL as a demonstration.",ISSUE CONTENT MANAGEMENT
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.', 'Reporting 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.', '--------------------------\n**Version**: unspecified\n**Severity**: normal']","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.",BUG REPRODUCTION
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.', 'Reporting 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.', '--------------------------\n**Version**: unspecified\n**Severity**: normal']","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).",OBSERVED BUG BEHAVIOR
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.', 'Reporting 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.', '--------------------------\n**Version**: unspecified\n**Severity**: normal']","FF 23.0.1 Win7--Atethnekos 19:33, 25 August 2013 (UTC) >>
I edited his sandbox a couple of times.",BUG REPRODUCTION
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.', 'Reporting 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.', '--------------------------\n**Version**: unspecified\n**Severity**: normal']","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.",OBSERVED BUG BEHAVIOR
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.', 'Reporting 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.', '--------------------------\n**Version**: unspecified\n**Severity**: normal']",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.,INVESTIGATION AND EXPLORATION
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.', 'Reporting 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.', '--------------------------\n**Version**: unspecified\n**Severity**: normal']",Thanks.,SOCIAL CONVERSATION
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.', 'Reporting 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.', '--------------------------\n**Version**: unspecified\n**Severity**: normal']","--------------------------
**Version**: unspecified
**Severity**: normal",MOTIVATION
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``']","The previous comments don't explain what/who exactly this task is //stalled// on ([""If a report is waiting for further input (e.g.",ISSUE CONTENT MANAGEMENT
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``']","from its reporter or a third party) and can currently not be acted on""](URL
QUOTE
Does not seem to happen anymore:
{F31846960}
QUOTE
Cannot reproduce in Firefox 76.",INVESTIGATION AND EXPLORATION
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``']","QUOTE
If I understand correctly then I cannot reproduce:
{F31846963}
{F31846962}
If this still happens then please follow URL (clear steps to reproduce; what's expected; what happens instead; in separate sections) and reopen this ticket.",INVESTIGATION AND EXPLORATION
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``']","For the records, wiki text test case here is
``CODE``",BUG REPRODUCTION
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.', ""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\n\n--------------------------\n**Version**: unspecified\n**Severity**: normal']","VisualEditor: Using up-arrow to scroll lets you put the cursor under the toolbar in Firefox, Internet Explorer.",OBSERVED BUG BEHAVIOR
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.', ""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\n\n--------------------------\n**Version**: unspecified\n**Severity**: normal']","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.",BUG REPRODUCTION
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.', ""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\n\n--------------------------\n**Version**: unspecified\n**Severity**: normal']",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.,OBSERVED BUG BEHAVIOR
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.', ""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\n\n--------------------------\n**Version**: unspecified\n**Severity**: normal']","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",BUG REPRODUCTION
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.']","IE9, Firefox 16.0.2, Chrome 26.0.1410.64 not supported anymore.",WORKAROUND
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.']","IE9, Firefox 16.0.2, Chrome 26.0.1410.64 now supported anymore.",WORKAROUND
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).'],Apparently IE is affected too (see bug 63778).,INVESTIGATION AND EXPLORATION
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.']","Go to some long article, scroll all the way down, click to make the blinking cursor visible.",BUG REPRODUCTION
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.']",Now press and hold the cursor-up key to go all the way back to the top.,BUG REPRODUCTION
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.']","Upon release of the cursor-up key, the cursor will be invisibly placed behind the toolbar.",OBSERVED BUG BEHAVIOR
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.']",Another press/release of the cursor-up key is necessary to make it visible again.,WORKAROUND
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.'],I believe that this was fixed some time ago as part of the toolbar fixes - please re-open if not.,TASK PROGRESS
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.']","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.",OBSERVED BUG BEHAVIOR
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.']",I have to release and repress CursorUp to see that line.,BUG REPRODUCTION
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.'],This is now merged and will go out later today.,TASK PROGRESS
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']","Change 73015 merged by jenkins-bot:
Bind listener to keyup to capture arrows & better math for scrolling.",TASK PROGRESS
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']",GERRIT_URL,TASK PROGRESS
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']","Change 73015 had a related patch set uploaded by Robmoen:
Bind listener to keyup to capture arrows & better math for scrolling.",TASK PROGRESS
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']",GERRIT_URL,TASK PROGRESS
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.']","(In reply to comment #0)
QUOTE
QUOTE
QUOTE
QUOTE
QUOTE
I can't reproduce this as written (for wmf6 or wmf7 on Mac or Linux, don't have Windows to test on).",BUG REPRODUCTION
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.']","We did change the behaviour of the toolbar a little in wmf5, which may explain.",INVESTIGATION AND EXPLORATION
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.']","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.",WORKAROUND
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.']","Will change this bug to reflect that, but feel free to revert if you can reproduce.",ACTION ON ISSUE
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"").', '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 ).', '--------------------------\n**Version**: master\n**Severity**: enhancement']","[GUI] Correct the button message text when converting OpenID (must be ""converting"" or ""adding"", not ""Login"").",EXPECTED BEHAVIOR
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"").', '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 ).', '--------------------------\n**Version**: master\n**Severity**: enhancement']","Correct the button message text when converting OpenID (must be ""converting"" or ""adding"", not ""Login"").",EXPECTED BEHAVIOR
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"").', '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 ).', '--------------------------\n**Version**: master\n**Severity**: enhancement']",A few more changes may be needed than to simply adapt the text above the button on the provider selection page ( Special:OpenIDConvert ).,SOLUTION DISCUSSION
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"").', '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 ).', '--------------------------\n**Version**: master\n**Severity**: enhancement']","--------------------------
**Version**: master
**Severity**: enhancement",MOTIVATION
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'],"solved by merging v4.01
GERRIT_URL",TASK PROGRESS
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'],"Change 97202 merged by Wikinaut:
Bug 45304: show correct button texts for login/create account/convert OpenID
GERRIT_URL",TASK PROGRESS
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'],"Change 97202 had a related patch set (by Wikinaut) published:
Bug 45304: show correct button texts for login/create account/convert OpenID
GERRIT_URL",TASK PROGRESS
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.', '**Author:** CODE\n\n**Description:**\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--------------------------\n**Version**: unspecified\n**Severity**: enhancement']",Http::get should accept user-agent option.,EXPECTED BEHAVIOR
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.', '**Author:** CODE\n\n**Description:**\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--------------------------\n**Version**: unspecified\n**Severity**: enhancement']","**Author:** CODE
**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.",OBSERVED BUG BEHAVIOR
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.', '**Author:** CODE\n\n**Description:**\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--------------------------\n**Version**: unspecified\n**Severity**: enhancement']","Really $options should include the user-agent string
--------------------------
**Version**: unspecified
**Severity**: enhancement",EXPECTED BEHAVIOR
153419,Http::get should accept user-agent option,Patch applied in r103765,task_subcomment,PHID-TASK-ssphbusktrpppqnyzrp6,['Patch applied in r103765'],Patch applied in r103765,TASK PROGRESS
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}']","Created attachment 9087
Implement UA at Http::request() level
I'm not so sure it's that hard or that hacky.",SOLUTION DISCUSSION
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}']",**Attached**: {F8321},SOLUTION DISCUSSION
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.""]",...reviving that would be a bit of a hack though.,SOLUTION DISCUSSION
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.""]",CURL isn't the only thing we support.,SOLUTION DISCUSSION
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']","**olivier.beaton** wrote:
Doing some compat testing and I found out that this is actually lost functionality.",INVESTIGATION AND EXPLORATION
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']","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",INVESTIGATION AND EXPLORATION
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);""]",Most sensible thing may be to just accept a 'headers' key with a map of HTTP headers to set.,SOLUTION DISCUSSION
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);""]","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',
)
);",SOLUTION DISCUSSION
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.', 'alpha login page\n\nSee image.', 'The language links should be centered (or maybe hidden?).', 'Now they look out of place.', '--------------------------\n**Version**: unspecified\n**Severity**: minor\n\n**Attached**: {F15220}']",Language selectors looks out of place in alpha login page.,OBSERVED BUG BEHAVIOR
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.', 'alpha login page\n\nSee image.', 'The language links should be centered (or maybe hidden?).', 'Now they look out of place.', '--------------------------\n**Version**: unspecified\n**Severity**: minor\n\n**Attached**: {F15220}']","alpha login page
See image.",OBSERVED BUG BEHAVIOR
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.', 'alpha login page\n\nSee image.', 'The language links should be centered (or maybe hidden?).', 'Now they look out of place.', '--------------------------\n**Version**: unspecified\n**Severity**: minor\n\n**Attached**: {F15220}']",The language links should be centered (or maybe hidden?).,EXPECTED BEHAVIOR
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.', 'alpha login page\n\nSee image.', 'The language links should be centered (or maybe hidden?).', 'Now they look out of place.', '--------------------------\n**Version**: unspecified\n**Severity**: minor\n\n**Attached**: {F15220}']",Now they look out of place.,OBSERVED BUG BEHAVIOR
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.', 'alpha login page\n\nSee image.', 'The language links should be centered (or maybe hidden?).', 'Now they look out of place.', '--------------------------\n**Version**: unspecified\n**Severity**: minor\n\n**Attached**: {F15220}']","--------------------------
**Version**: unspecified
**Severity**: minor
**Attached**: {F15220}",MOTIVATION
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""]",Yeh this is a result of trying to repurpose the desktop login form in alpha.,INVESTIGATION AND EXPLORATION
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""]",I've added this to acceptance criteria in URL,CONTRIBUTION AND COMMITMENT
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'],"**bingle-admin** wrote:
Prioritization and scheduling of this bug is tracked on Trello card URL",ACTION ON ISSUE
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.', ""URL 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."", '--------------------------\n**Version**: unspecified\n**Severity**: normal']",REST API page on Gerrit loads prettify.js and .css over HTTP.,OBSERVED BUG BEHAVIOR
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.', ""URL 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."", '--------------------------\n**Version**: unspecified\n**Severity**: normal']","URL loads:
* URL
* URL
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.",OBSERVED BUG BEHAVIOR
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.', ""URL 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."", '--------------------------\n**Version**: unspecified\n**Severity**: normal']","--------------------------
**Version**: unspecified
**Severity**: normal",MOTIVATION
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.', '**Author:** CODE\n\n**Description:**\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."", '--------------------------\n**Version**: wmf-deployment\n**Severity**: major']",Payment processor website uses RC4 for https encryption.,OBSERVED BUG BEHAVIOR
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.', '**Author:** CODE\n\n**Description:**\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."", '--------------------------\n**Version**: wmf-deployment\n**Severity**: major']","**Author:** CODE
**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.",BUG REPRODUCTION
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.', '**Author:** CODE\n\n**Description:**\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."", '--------------------------\n**Version**: wmf-deployment\n**Severity**: major']","From what I can tell, it's a WorldPay.ca (payment processor) server.",OBSERVED BUG BEHAVIOR
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.', '**Author:** CODE\n\n**Description:**\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."", '--------------------------\n**Version**: wmf-deployment\n**Severity**: major']","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).",BUG REPRODUCTION
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.', '**Author:** CODE\n\n**Description:**\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."", '--------------------------\n**Version**: wmf-deployment\n**Severity**: major']","An SSL test for the domain shows that it indeed offers RC4 (and nothing else):
URL
This is bad.",OBSERVED BUG BEHAVIOR
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.', '**Author:** CODE\n\n**Description:**\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."", '--------------------------\n**Version**: wmf-deployment\n**Severity**: major']",RC4-encrypted traffic has been likened by some infosec researchers to “no encryption” and the NSA can allegedly break it in real-time.,MOTIVATION
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.', '**Author:** CODE\n\n**Description:**\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."", '--------------------------\n**Version**: wmf-deployment\n**Severity**: major']","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.",OBSERVED BUG BEHAVIOR
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.', '**Author:** CODE\n\n**Description:**\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."", '--------------------------\n**Version**: wmf-deployment\n**Severity**: major']","15360 bits RSA) FS 128
Furthermore, the server is still offering SSLv3.",OBSERVED BUG BEHAVIOR
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.', '**Author:** CODE\n\n**Description:**\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."", '--------------------------\n**Version**: wmf-deployment\n**Severity**: major']","That should also be disabled, following the POODLE vulnerability published about a month ago.",EXPECTED BEHAVIOR
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.', '**Author:** CODE\n\n**Description:**\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."", '--------------------------\n**Version**: wmf-deployment\n**Severity**: major']","The server should be offering modern encryption (forward secrecy, no SSL, strong non-deprecated ciphers).",EXPECTED BEHAVIOR
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.', '**Author:** CODE\n\n**Description:**\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."", '--------------------------\n**Version**: wmf-deployment\n**Severity**: major']","Here is a good guide on how to do it on Apache2:
URL
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.",MOTIVATION
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.', '**Author:** CODE\n\n**Description:**\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."", '--------------------------\n**Version**: wmf-deployment\n**Severity**: major']","--------------------------
**Version**: wmf-deployment
**Severity**: major",MOTIVATION
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']",It seems they have fixed the issue.,TASK PROGRESS
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']",They have enabled some cipher suites besides RC4.,SOLUTION DISCUSSION
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']",SSL 3.0 has been disabled.,TASK PROGRESS
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']",URL,TASK PROGRESS
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.']",Fair enough.,SOCIAL CONVERSATION
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.']","Marking as stalled, as we are still waiting for the third party to resolve this issue.",ACTION ON ISSUE
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).']",Thanks for filing this issue.,SOCIAL CONVERSATION
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).']","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).",ACTION ON ISSUE
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.']","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.",MOTIVATION
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.']","Browsers have to support RC4 to make these websites, such as Worldpay, ""just work"".",INVESTIGATION AND EXPLORATION
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.']","According to SSL Pulse, 1.4% of sites require RC4, and 27.3% of sites use RC4 with modern browsers.",INVESTIGATION AND EXPLORATION
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.']","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.",INVESTIGATION AND EXPLORATION
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.']","However, now **these 1.4% of websites, including Worldpay, make 27.3% of websites in the world vulnerable to RC4 attacks**.",INVESTIGATION AND EXPLORATION
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.']",You may argue that the 27.3% websites are also wrong in that they support and prioritize RC4 ciphers.,INVESTIGATION AND EXPLORATION
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.']",That's right.,SOCIAL CONVERSATION
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.']","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.",MOTIVATION
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.']","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.",MOTIVATION
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.']",I hope Worldpay can fix this issue as soon as possible.,SOLUTION AND DISCUSSION
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.']",Thank you for raising this issue.,SOCIAL CONVERSATION
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.']","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.",INVESTIGATION AND EXPLORATION
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.']","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.",INVESTIGATION AND EXPLORATION
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.']","While RC4 is less than ideal, it presents very little risk in this context.",INVESTIGATION AND EXPLORATION
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.']","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.",FUTURE PLAN
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.', '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.', 'URL\n\nExample error output:\nURL\n\nOriginal bug:\nURL\n\n--------------------------\n**Version**: 1.23.5\n**Severity**: major\n**See Also**:\nURL']",Not loading site CSS on Special:UserLogin/Preferences breaks wikis which use it to create a skin/theme.,OBSERVED BUG BEHAVIOR
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.', '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.', 'URL\n\nExample error output:\nURL\n\nOriginal bug:\nURL\n\n--------------------------\n**Version**: 1.23.5\n**Severity**: major\n**See Also**:\nURL']",Bug 70672 (T72672) fixes the security hole of allowing Javascript in CSS in the Mediawiki namespace.,INVESTIGATION AND EXPLORATION
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.', '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.', 'URL\n\nExample error output:\nURL\n\nOriginal bug:\nURL\n\n--------------------------\n**Version**: 1.23.5\n**Severity**: major\n**See Also**:\nURL']",It does this by breaking the functionality of loading CSS when on the Special:UserLogin and Special:Preferences pages.,INVESTIGATION AND EXPLORATION
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.', '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.', 'URL\n\nExample error output:\nURL\n\nOriginal bug:\nURL\n\n--------------------------\n**Version**: 1.23.5\n**Severity**: major\n**See Also**:\nURL']",Unfortunately this means that any custom styles are not loaded.,OBSERVED BUG BEHAVIOR
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.', '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.', 'URL\n\nExample error output:\nURL\n\nOriginal bug:\nURL\n\n--------------------------\n**Version**: 1.23.5\n**Severity**: major\n**See Also**:\nURL']",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.,OBSERVED BUG BEHAVIOR
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.', '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.', 'URL\n\nExample error output:\nURL\n\nOriginal bug:\nURL\n\n--------------------------\n**Version**: 1.23.5\n**Severity**: major\n**See Also**:\nURL']",This is an undesirable side effect for the user interface.,MOTIVATION
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.', '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.', 'URL\n\nExample error output:\nURL\n\nOriginal bug:\nURL\n\n--------------------------\n**Version**: 1.23.5\n**Severity**: major\n**See Also**:\nURL']",I have created an example extension that will prevent saving any custom CSS that contains Javascript imports.,CONTRIBUTION AND COMMITMENT
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.', '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.', 'URL\n\nExample error output:\nURL\n\nOriginal bug:\nURL\n\n--------------------------\n**Version**: 1.23.5\n**Severity**: major\n**See Also**:\nURL']","URL
Example error output:
URL
Original bug:
URL
--------------------------
**Version**: 1.23.5
**Severity**: major
**See Also**:
URL",BUG REPRODUCTION
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!'],"QUOTE
QUOTE
Yes!",SOCIAL CONVERSATION
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?'],I assume this can be closed as fixed now?,ACTION ON ISSUE
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]]'],"Change 175671 merged by jenkins-bot:
Make allowing site-wide styles on restricted special pages a config option
[[GERRIT_URL]]",TASK PROGRESS
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]]'],"Change 174018 merged by Mglaser:
Make allowing site-wide styles on restricted special pages a config option
[[GERRIT_URL]]",TASK PROGRESS
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]]'],"Change 174014 merged by Mglaser:
Make allowing site-wide styles on restricted special pages a config option
[[GERRIT_URL]]",TASK PROGRESS
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'],"Change 175671 had a related patch set uploaded (by Mglaser):
Make allowing site-wide styles on restricted special pages a config option
[[GERRIT_URL]]
#patch-for-review",TASK PROGRESS
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.""]","I uploaded patches for REL1_24, REL1_23, and REL1_22.",TASK PROGRESS
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.""]",I started on REL1_19 and then it got all scary so I stopped.,TASK PROGRESS
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.""]","I'm not sure what to do aboutSCREEN_NAME 1.25 tags, so I left them as they are.",TASK PROGRESS
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'],"**gerritadmin** wrote:
Change 174018 had a related patch set uploaded by Legoktm:
Make allowing site-wide styles on restricted special pages a config option
GERRIT_URL",TASK PROGRESS
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'],"**gerritadmin** wrote:
Change 174014 had a related patch set uploaded by Legoktm:
Make allowing site-wide styles on restricted special pages a config option
GERRIT_URL",TASK PROGRESS
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'],"**gerritadmin** wrote:
Change 174012 had a related patch set uploaded by Legoktm:
Make allowing site-wide styles on restricted special pages a config option
GERRIT_URL",TASK PROGRESS
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']",I believe that this is great news and having a configuration setting for this [1] is great and very much acceptable.,SOCIAL CONVERSATION
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']",Thanks a ton for making this possible!,SOCIAL CONVERSATION
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']","Since this went to master I think this change should be backported to the 1.19, 1.23 and 1.24 branches.",FUTURE PLAN
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']",[1] URL,TASK PROGRESS
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'],"**gerritadmin** wrote:
Change 165979 merged by jenkins-bot:
Make allowing site-wide styles on restricted special pages a config option
GERRIT_URL",TASK PROGRESS
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.""]",Kunal's fix here makes sense to me.,SOLUTION DISCUSSION
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.""]","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.",SOLUTION USAGE
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.""]",Restricting that ability causes problems for end users.,SOLUTION USAGE
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.""]","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.",SOLUTION DISCUSSION
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.""]","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.",FUTURE PLAN
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...']",Is there no really easier way to suppress disasbling MediaWiki NS CSS when Special:Preferences is loaded?,SOLUTION DISCUSSION
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...']",Only I can edit the MW NS.,SOLUTION USAGE
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...']",I see no risk...,INVESTIGATION AND EXPLORATION
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.""]","For the record, these last few comments were mostly to provide more context, data and factor of influence.",ACTION ON ISSUE
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.""]",I don't feel it's appropriate for me to make a decision about this.,CONTRIBUTION AND COMMITMENT
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).']","(In reply to Krinkle from comment #9)
QUOTE
QUOTE
QUOTE
QUOTE
QUOTE
QUOTE
QUOTE
QUOTE
QUOTE
QUOTE
QUOTE
QUOTE
QUOTE
QUOTE
QUOTE
QUOTE
QUOTE
QUOTE
For the 'site' module you are absolutely right of course.",INVESTIGATION AND EXPLORATION
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).']",In general a module is either executed regularly (addModules/mw.loader.load) or styles only (e.g.,INVESTIGATION AND EXPLORATION
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).']",Vector skin; addModuleStyles/load.php only=styles).,INVESTIGATION AND EXPLORATION
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).']","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.",INVESTIGATION AND EXPLORATION
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).']","infobox, or fallback styles for collapsible elements).",INVESTIGATION AND EXPLORATION
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.']",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.,SOLUTION DISCUSSION
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.']",Then dragging along not issuing a recall on the patch or providing a corrected patch is also not acceptable.,SOLUTION DISCUSSION
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).""]","(In reply to Kunal Mehta (Legoktm) from comment #7)
QUOTE
QUOTE
QUOTE
QUOTE
QUOTE
QUOTE
QUOTE
No we don't.",SOCIAL CONVERSATION
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).""]","Only for exceptional modules that are designed specifically to be a base module without javascript, loaded explicitly via addModuleStyles, thus bypassing ResourceLoader.",INVESTIGATION AND EXPLORATION
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).""]","If you're loading a regular module containing javascript files via addModuleStyles, you're doing it wrong.",SOLUTION DISCUSSION
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).""]","It doesn't throw an exception for that right now, but we should if that helps.",FUTURE PLANS
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).""]",When writing css rules in a stylesheet loaded by ResourceLoader one should be able to assume javascript execution alongside of it.,EXPECTED BEHAVIOR
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).""]","(In reply to Kunal Mehta (Legoktm) from comment #7)
QUOTE
QUOTE
QUOTE
I agree.",SOCIAL CONVERSATION
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).""]",But on the other hand one could also argue we never supported this in the first place.,INVESTIGATION AND EXPLORATION
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).""]",The community never asked to make usability and design decisions for the software interface.,SOLUTION DISCUSSION
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).""]","And contrary to the usual case, it's actually smaller wikis that do this, not the larger language editions of Wikipedia.",INVESTIGATION AND EXPLORATION
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).""]",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.,INVESTIGATION AND EXPLORATION
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).""]",I'm not arguing that though.,SOCIAL CONVERSATION
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).""]",It's been too years since Common.css was added and these wikis started doing it to take it back now.,INVESTIGATION AND EXPLORATION
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).""]",Should the community ask for a feature if there's an existing exploit they can use to emulate a requested feature?,WORKAROUND
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).""]",(e.g.,SOCIAL CONVERSATION
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).""]","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.",SOLUTION DISCUSSION
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).""]","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).",SOLUTION DISCUSSION
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.']",So what's next?,FUTURE PLAN
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.']",How do we get all the affected wikis out of their current misery?,MOTIVATION
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.']",This bug should not be a back-burner thing as it looks like at the moment.,ACTION ON ISSUE
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.']",I think the MW software should allow wikis to adapt the overall appearance without having to use a custom skin.,MOTIVATION
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.']",So far the easiest way was to use Common.css/js etc.,SOLUTION DISCUSSION
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.']",which is no longer working for integral pages such as the login and preferences.,OBSERVED BUG BEHAVIOR
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.']",I think the proposed change tries to address this issue.,SOLUTION DISCUSSION
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.']",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.,SOLUTION DISCUSSION
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.']",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.,SOLUTION DISCUSSION
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.']",Perhaps there are other ways.,SOCIAL CONVERSATION
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.""]","(In reply to Krinkle from comment #5)
QUOTE
QUOTE
We already serve only the CSS of the module to no-JS users, so it's not totally against expectations.",SOLUTION DISCUSSION
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.""]","QUOTE
QUOTE
QUOTE
QUOTE
QUOTE
QUOTE
QUOTE
QUOTE
QUOTE
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.",SOLUTION USAGE
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.""]","QUOTE
QUOTE
QUOTE
QUOTE
QUOTE
QUOTE
QUOTE
QUOTE
QUOTE
QUOTE
QUOTE
QUOTE
QUOTE
QUOTE
QUOTE
QUOTE
QUOTE
QUOTE
QUOTE
QUOTE
QUOTE
QUOTE
QUOTE
QUOTE
QUOTE
QUOTE
QUOTE
QUOTE
QUOTE
QUOTE
QUOTE
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.",SOLUTION USAGE
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.']","(In reply to Krinkle from comment #5)
QUOTE
QUOTE
QUOTE
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.",WORKAROUND
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.']","For a single site that you're running yourself, making or installing a custom skin is good.",SOLUTION USAGE
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.']","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.",SOLUTION USAGE
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.""]","This would result in loading only part of a module, which is in my opinion against expectations.",SOLUTION DISCUSSION
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.""]","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.",SOLUTION USAGE
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.""]",Maybe we should discourage people from theming their wiki to this extreme via this method?,SOLUTION USAGE
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.""]",Third parties should add a stylesheet via LocalSettings instead of Common.css.,WORKAROUND
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.""]",This should be done by a developer instead (especially for third parties).,SOLUTION DISCUSSION
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.""]","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.",EXPECTED BEHAVIOR
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.""]",Users should not be able to notice a difference outside the content area when the styles are not loaded.,EXPECTED BEHAVIOR
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.""]","That thing about people thinking it's a different site, that goes both ways.",EXPECTED BEHAVIOR
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.""]","When they visit that different language edition, should that be allowed to look like a completely different website?",INVESTIGATION AND EXPLORATION
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.""]",Main reason being that the software interface is provided by MediaWiki core.,INVESTIGATION AND EXPLORATION
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.""]","If there are problems there, they should be reported to the software and addressed accordingly.",INVESTIGATION AND EXPLORATION
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.""]","Things can be iterated and tried in gadgets, but for something so central to the software, it either shouldn't be done (e.g.",MOTIVATION
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.""]","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).",MOTIVATION
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.""]","Something as fundamental as the site font, for example.",EXPECTED BEHAVIOR
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.""]","That's either a personal preference one could question whether it's responsible for users to override, or there's a technical reason (eg.",MOTIVATION
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.""]",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.,POTENTIAL NEW ISSUES AND REQUESTS
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.""]",By all means that is a high priority problem for the foundation and MediaWiki software to address.,POTENTIAL NEW ISSUES AND REQUESTS
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.""]","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.",POTENTIAL NEW ISSUES AND REQUESTS
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.""]",And I'm also not convinced that that'd be a good thing.,SOCIAL CONVERSATION
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.""]","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.",INVESTIGATION AND EXPLORATION
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'],"**gerritadmin** wrote:
Change 165979 had a related patch set uploaded by Legoktm:
Re-enable site-wide styles on Special:Preferences/UserLogin
GERRIT_URL",TASK PROGRESS
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.']","Yes, this is needed on fa, ckb, arz, glk, mzn, ps, pnb.",SOLUTION USAGE
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.']",Why?,SOCIAL CONVERSATION
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.']",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.,MOTIVATION
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.']",Many scripts/styles run on a site level; it does not make sense that they do not work on two pages.,INVESTIGATION AND EXPLORATION
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.']",CSS is used e.g.,INVESTIGATION AND EXPLORATION
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.']",in Arabic Wikipedia to adjust general font size and fix a bunch of directionality issues.,INVESTIGATION AND EXPLORATION
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""]",Also bawolff's email: URL,SOCIAL CONVERSATION
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.', '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.', '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']",PHP Fatal error: include(): Cannot redeclare class psr\log\loggerinterface in /vendor/composer/ClassLoader.php:412.,OBSERVED BUG BEHAVIOR
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.', '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.', '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']","After update from 1.24 series to 1.25, I started having this error on certain pages.",OBSERVED BUG BEHAVIOR
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.', '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.', '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']","Currently the error shows up when I click Upload at the File Upload page (which is Dosya Yükle in Turkish translation), among others.",OBSERVED BUG BEHAVIOR
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.', '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.', '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']","I did follow documentation on the release notes; MediaWiki was first installed from tarball, then I tried the git-compose install/update method.",BUG REPRODUCTION
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.', '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.', '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']",The psr directory exists in $IP/vendor.,BUG REPRODUCTION
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.', '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.', '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']","QUOTE
I can reproduce the error.",BUG REPRODUCTION
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.', '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.', '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']","Mediawiki error report:
QUOTE
QUOTE
QUOTE
QUOTE
QUOTE
QUOTE
QUOTE
QUOTE
QUOTE
QUOTE
QUOTE
QUOTE
QUOTE
QUOTE
QUOTE
QUOTE
QUOTE
QUOTE
QUOTE
QUOTE
QUOTE
QUOTE
QUOTE
QUOTE
QUOTE
QUOTE
QUOTE
QUOTE
QUOTE
QUOTE
QUOTE
QUOTE
QUOTE
QUOTE
QUOTE
QUOTE
QUOTE
QUOTE
QUOTE
QUOTE
QUOTE
QUOTE
QUOTE
QUOTE
QUOTE
QUOTE
QUOTE
QUOTE
QUOTE
QUOTE
QUOTE
QUOTE
QUOTE
QUOTE
QUOTE
QUOTE
QUOTE
QUOTE
QUOTE
QUOTE
QUOTE
QUOTE
QUOTE
And Apache error when I try/refresh the relevant page(s):
QUOTE
QUOTE
QUOTE
QUOTE
QUOTE
QUOTE
QUOTE
QUOTE
QUOTE
QUOTE
QUOTE
QUOTE
QUOTE
QUOTE
QUOTE
QUOTE
QUOTE
QUOTE
QUOTE
QUOTE
QUOTE
QUOTE
QUOTE
QUOTE
QUOTE
QUOTE
QUOTE
QUOTE
QUOTE
QUOTE
QUOTE
QUOTE
QUOTE
QUOTE
QUOTE
QUOTE
QUOTE
QUOTE
QUOTE
QUOTE
QUOTE
QUOTE
QUOTE
QUOTE
QUOTE
QUOTE
QUOTE
QUOTE
QUOTE
QUOTE",OBSERVED BUG BEHAVIOR
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'],Declining... Nobody cared to reply and MW1.25 is no longer supported,ACTION ON ISSUE
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?']","QUOTE
QUOTE
SCREEN_NAME: Can you answer this?",SOCIAL CONVERSATION
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?']",Is this still an issue?,SOCIAL CONVERSATION
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?']","QUOTE
QUOTE
SCREEN_NAME: Can you answer this?",SOCIAL CONVERSATION
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?']",Is this still an issue?,SOCIAL CONVERSATION
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?']",The error you reported does not mean PSR-3 is not installed.,INVESTIGATION AND EXPLORATION
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?']","In fact, it means the opposite.",INVESTIGATION AND EXPLORATION
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?']",The error shows that the CODE directory exists and contains the PSR-3 class.,INVESTIGATION AND EXPLORATION
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?']","However when it loads it, it claims it is a redeclaration.",INVESTIGATION AND EXPLORATION
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?']","In other words, it has been defined by something else.",INVESTIGATION AND EXPLORATION
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?']","And then when MediaWiki tries to load its own, it ends up loading a second time.",INVESTIGATION AND EXPLORATION
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?']",Loading the same class twice is not possible and as such the engine aborts with a fatal error.,INVESTIGATION AND EXPLORATION
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?']",Perhaps you have an older extension installed that also ships a PSR-3 interface?,POTENTIAL NEW ISSUES AND REQUESTS
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.']",Update.,SOCIAL CONVERSATION
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.']",I think I narrowed it down to the images directory.,INVESTIGATION AND EXPLORATION
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.']","When I move the images directory (which holds images as well as PDFs, PPTs) from the installation directory, the issue seems to be solved.",WORKAROUND
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.']","When I move the directory back, the error starts again.",INVESTIGATION AND EXPLORATION
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.']",I also tried the maintenance/importImages.php script for importing the images from the old installation directory (instead of simply copying).,INVESTIGATION AND EXPLORATION
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.']",No luck.,SOCIAL CONVERSATION
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)'],(Sorry lcawte; mid-air collision when editing),SOCIAL CONVERSATION