Re: [Wikitech-l] Add modules=site.styles inline
It loads the link even though the content is blank :/ Regards, Nischay Nahata On Fri, Jul 20, 2018 at 11:25 AM Nischay Nahata wrote: > Thanks for the reply. > > I do use the file cache and yes, there could be performance issues with > purging too many problems at once. But again there's a situation where I > can avoid using Common.css altogether so I think there should be a way to > turn the module off. I don't know what happens if the common.css is empty, > I will try that out. > > Regards, > Nischay Nahata > > > On Fri, Jul 20, 2018 at 12:04 AM Bartosz Dziewoński > wrote: > >> There is one important reason why we use instead of >> …: when the rendered page HTML is cached, e.g. using a >> caching proxy like Varnish [1] or MediaWiki file cache [2], then if we >> used …, you would have to purge every page on the wiki >> before changes to MediaWiki:Common.css would actually take effect, >> because the CSS would be embedded in the cached HTML. >> >> Using means that it only takes as long as it takes the cached >> resource to expire in the users' browsers. (By default, they are set to >> expire after 5 minutes.) >> >> If you don't have caching enabled, then of course that wouldn't matter – >> but also, if you don't have caching enabled, then that is probably a >> much worse performance problem than not embedding the styles :) >> >> [1] https://www.mediawiki.org/wiki/Manual:Varnish_caching >> [2] https://www.mediawiki.org/wiki/Manual:File_cache >> >> -- >> Bartosz Dziewoński >> >> ___ >> Wikitech-l mailing list >> Wikitech-l@lists.wikimedia.org >> https://lists.wikimedia.org/mailman/listinfo/wikitech-l > > ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Add modules=site.styles inline
Thanks for the reply. I do use the file cache and yes, there could be performance issues with purging too many problems at once. But again there's a situation where I can avoid using Common.css altogether so I think there should be a way to turn the module off. I don't know what happens if the common.css is empty, I will try that out. Regards, Nischay Nahata On Fri, Jul 20, 2018 at 12:04 AM Bartosz Dziewoński wrote: > There is one important reason why we use instead of > …: when the rendered page HTML is cached, e.g. using a > caching proxy like Varnish [1] or MediaWiki file cache [2], then if we > used …, you would have to purge every page on the wiki > before changes to MediaWiki:Common.css would actually take effect, > because the CSS would be embedded in the cached HTML. > > Using means that it only takes as long as it takes the cached > resource to expire in the users' browsers. (By default, they are set to > expire after 5 minutes.) > > If you don't have caching enabled, then of course that wouldn't matter – > but also, if you don't have caching enabled, then that is probably a > much worse performance problem than not embedding the styles :) > > [1] https://www.mediawiki.org/wiki/Manual:Varnish_caching > [2] https://www.mediawiki.org/wiki/Manual:File_cache > > -- > Bartosz Dziewoński > > ___ > Wikitech-l mailing list > Wikitech-l@lists.wikimedia.org > https://lists.wikimedia.org/mailman/listinfo/wikitech-l ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
[Wikitech-l] hewiki dump to be added to 'big wikis' and run with multiple processes
Good morning! The pages-meta-history dumps for hewiki take 70 hours these days, the longest of any wiki not already running with parallel jobs. I plan to add it to the list of 'big wikis' starting August 1st, meaning that 6 jobs will run in parallel producing the usual numbered file output; look at e.g. frwiki dumps for an example. Please adjust any download/processing scripts accordingly. Thanks! Ariel ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] CI jobs using npm might suffer from a 10 minutes delay
On 28/06/2018 23:28, Antoine Musso wrote: >> npm ERR! registry error parsing json > >> Our task: https://phabricator.wikimedia.org/T198348 > Npmjs seems to have implemented a fix although we are still hitting the > issue: https://status.npmjs.org/incidents/51c7q80zsj9f > > > A few minutes ago, I have bumped the default timeout from 30 minutes to > 45 minutes. So jobs will still be slow, but at least they should > succeed (when they should). > > https://gerrit.wikimedia.org/r/#/c/integration/config/+/442988/ Hello, The issue from June 28th has been resolved but appeared again today. CI jobs using npm once again are showing the delay issue. Same symptom: npm ERR! registry error parsing json I have bumped the job timeout again from 30 minutes to 45 minutes and reopen the task https://phabricator.wikimedia.org/T198348 -- Antoine "hashar" Musso ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
[Wikitech-l] Patchsets by new Gerrit contributors waiting for code review and/or merge
CR0: Please review and provide guidance if you are familiar with the code, and decide (CR±1 or CR±2): * https://gerrit.wikimedia.org/r/#/c/mediawiki/core/+/164049/ ** Add Tatar LanguageConverter ** 2018-May-24 (though commented by Thiemo on 2018-Jul-05) ** Maintainers/Stewards: Contributors > Parsing team * https://gerrit.wikimedia.org/r/#/c/mediawiki/extensions/Drafts/+/443128/ ** Adding code standards configuration for phpcs to drafts. ** 2018-Jul-09 ** Maintainers/Stewards: ? CR+1: Please help make a decision (CR±1, CR±2) on these CR+1 patches: * https://gerrit.wikimedia.org/r/#/c/mediawiki/extensions/ApprovedRevs/+/434052/ ** Add support for custom content types other than WikitextContent ** 2018-Jun-17 ** Maintainers/Stewards: ? Read https://www.mediawiki.org/wiki/Gerrit/Code_review#By_project how you can get notified of new patches in your code areas of interest. Thanks in advance for your reviews! Of last edition's 4 listed patches, 2 got merged. Thanks to Fisch and Mholloway! Maintainers/Stewards data taken from https://www.mediawiki.org/wiki/Developers/Maintainers CR0 source: https://gerrit.wikimedia.org/r/#/q/ownerin:newcomers+status:open+label:Verified%253D1+label:Code-Review%253D0 CR+1 source: https://gerrit.wikimedia.org/r/#/q/ownerin:newcomers+status:open+label:Verified%253E%253D1+label:Code-Review%253E%253D%252B1+-label:Code-Review%253C%253D0 -- Andre Klapper | Bugwrangler / Developer Advocate https://blogs.gnome.org/aklapper/ ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Add modules=site.styles inline
There is one important reason why we use instead of …: when the rendered page HTML is cached, e.g. using a caching proxy like Varnish [1] or MediaWiki file cache [2], then if we used …, you would have to purge every page on the wiki before changes to MediaWiki:Common.css would actually take effect, because the CSS would be embedded in the cached HTML. Using means that it only takes as long as it takes the cached resource to expire in the users' browsers. (By default, they are set to expire after 5 minutes.) If you don't have caching enabled, then of course that wouldn't matter – but also, if you don't have caching enabled, then that is probably a much worse performance problem than not embedding the styles :) [1] https://www.mediawiki.org/wiki/Manual:Varnish_caching [2] https://www.mediawiki.org/wiki/Manual:File_cache -- Bartosz Dziewoński ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
[Wikitech-l] 2018-07-18 Scrum of Scrums meeting notes
https://www.mediawiki.org/wiki/Scrum_of_scrums/2018-07-18 = 2018-07-18= == Callouts == * Fundraising campaigns https://meta.wikimedia.org/wiki/CentralNotice/Calendar * [Perf] Seeking input on wmf-config variables that appear to be unused, and which we'd like to remove: https://wikitech.wikimedia.org/wiki/User:Krinkle/Unused_config == Audiences == === Readers === iOS native app (Natalia H) * Blocked by: Question for Analytics: can we return an error code if event logging validation fails? Right now we have to test menually using https://wikitech.wikimedia.org/wiki/Analytics/Systems/EventLogging/TestingOnBetaCluster#How_to_verify_events ** With the current system, no, because the endpoint you're sending to is a fire-and-forget Varnish server. This is a good thing to bring up in the Modern Event Platform Context. ^ thanks, that makes sense 👍 (let me know if you want to brainbounce the problem that this causes milimetric) * Blocking: * Updates: **User testing of feed redesign and navigation changes in progress ( https://phabricator.wikimedia.org/T198932) **6.0.0 ( https://phabricator.wikimedia.org/tag/ios-app-v6.0-walrus-on-a-unicycle/) feature-complete by the end of this week **Product at Wikimedia Android native app (Natalia H) * Blocked by: * Blocking: * Updates: **Finishing up prototypes of navigation updates: https://phabricator.wikimedia.org/project/view/3367/ **Maintenance release this week to address minor analytics issues and audio playback. https://phabricator.wikimedia.org/T198504 Readers Web (Stephen N) * Blocked by: ** New service request: chromium-render/deploy https://phabricator.wikimedia.org/T186748 *** We're not blocked but we're ready to help as needed on: https://gerrit.wikimedia.org/r/#/c/mediawiki/services/chromium-render/+/443465/ (+1d but needs review by Petr when available!) https://phabricator.wikimedia.org/T199264 (not sure what the status is) * Blocking: * Updates: ** RFC: Add a language agnostic build step to skins/extensions to our deploy process https://phabricator.wikimedia.org/T199004 ** Mobile website (MinervaNeue / MobileFrontend): *** Page issues UI and instrumentation T191532 T191528 T197932 T197931 T199005 *** Special pages preferences T186760 *** Document existing JavaScript code coverage T197637 *** Other fixes and hygiene T193172 T197133 T198930 ** WikidataPageBanner *** Banners should display the same in RTL or LTR T198818 ** PDF rendering (Proton): *** Font configuration T199264 ** Desktop website (Popups): *** Identify aborted HTTP requests logged T199482 *** Some JSDoc improvements and other fixes T198663 ** Wikipedia.org (Portals) *** Extra spacing on article counts T199337 ** Product and design at Wikimania ** Design finishing navigation prototypes for advanced contributors Readers Infrastructure * Blocked by: n/a * Blocking: n/a * Updates: ** Working on updating maps dependencies to use a more recent Mapnik version (https://phabricator.wikimedia.org/T188674) ** Building a Docker Compose setup for maps stack ( https://phabricator.wikimedia.org/T193232) ** content-html endpoint: *** new name tbd T199491 *** working on splitting up CollapseTable in wikimedia-page-library into client and server portions ** Working on respecting the accept-language header in MCS ( https://phabricator.wikimedia.org/T197009) Multimedia * Blocked by: * Blocking: * Updates: ** Half the team is incommunicado for Wikimania; progress is minimal this week I think ** Search prototype is progressing ** Designs coming through soon for other work === Contributors === Community Tech * Blocked by: *Security*: Need security review for TemplateWizard extension https://phabricator.wikimedia.org/T198666 * Blocking: * Updates: ** GlobalPreferences API is out on beta. There's a breaking change that fixes a 'bug' that was introduced with blacklist notifications. Should not affect anyone. ** Anti-Harassment Tools * Blocked by: * Blocking: * Updates: ** Editing * Blocked by: * Blocking: ** Updates: ** Parsing * Blocked by: * Blocking: * Updates: ** Completed migration from Tidy to Remex, no major issues reported Growth * Blocked by: * Blocking: * Updates: ** Language * Blocked by: https://phabricator.wikimedia.org/T199011 -> VE: https://phabricator.wikimedia.org/T196521 * Blocking: * Updates: ** Progress on 'Progress Calculation' for CX2. ** Some annoying bug fixes for CX1. ** Fixed issues with cxserver and maintainance updates. === Audiences Design === UI Standardization * Blocked by: * Blocking: * Updates: ** OOUI v0.27.5 released last week with accessible tabs, and standard buttons in dialogs. No release this week ** Continuous work on Special:Preferences connected tasks and minor support for Special:Log to OOUI preparation ** Design Style Guide: Color section/palette visual refresh, mobile friendly: https://design.wikimedia.org/style-guide/vi
Re: [Wikitech-l] Announcing TechCom’s Newest Members
Congratulations Niklas and Dan, and thanks for your continued contributions! On Thu, Jul 19, 2018 at 12:22 PM, Victoria Coleman wrote: > Adding my congratulations to Niklas and Dan. You will bring a lot of > wisdom, expertise and POVs to the committee. As we transform its mission > and expand its scope, your contributions will be invaluable. > > Welcome! > > Victoria > > > On Jul 18, 2018, at 2:06 PM, Deb Tankersley > wrote: > > > > Congratulations Niklas and Dan — we're happy to have you on the committee > > and we're looking forward to adding your experiences, expertise and > > strengths as well as your unique perspectives during our discussions! :) > > > > Cheers, > > > > Deb > > > > -- > > > > deb tankersley > > > > Program Manager, Engineering > > > > Wikimedia Foundation > > > > > > On Tue, Jul 17, 2018 at 10:06 PM Daniel Kinzler < > daniel.kinz...@wikimedia.de> > > wrote: > > > >> Dear All, > >> > >> back in June the Wikimedia Technical Committee (TechCom) began a > process to > >> recruit two new members to broaden the committee’s area of expertise[1]. > >> After > >> some deliberation, we have now concluded our process and would like to > >> welcome > >> Niklas Laxström and Dan Andreescu to TechCom. Congratulations, we are > >> looking > >> forward to you bringing your expertise to the committee! > >> > >> For those who wonder what this is about: TechCom is the guardian of the > >> integrity, consistency, stability, and performance of all software > >> supporting > >> the Wikimedia projects. It acts as the senior advisor and the > convergence > >> point > >> of all decisions related to technical work that is strategic, > >> cross-cutting, > >> and/or hard to undo. You can find more information in the TechCom > >> Charter[2]. > >> > >> To those who applied or were nominated, but were not selected, I want to > >> say: > >> thank you for offering your time and brain power! It was a difficult > >> decision to > >> make. We evaluated all candidates based on the following criteria: > >> - Activity on RFCs and other Phabricator tickets > >> - Area(s) of expertise > >> - Having a unique engineering perspective > >> - Experience working in and with the Wikimedia movement and community > >> > >> It was a challenge to balance these criteria, especially with candidates > >> who > >> have a lot of experience, but whose expertise and perspective is similar > >> to that > >> of existing members. In such cases, we aimed to improve the diversity > of > >> perspective and knowledge on the committee by picking candidates that > >> would help > >> us cover any blind spots. > >> > >> We plan to do another round of nominations again soon, and hope to have > >> continued interested from others in joining TechCom. > >> > >> Thank you all, > >> > >> [1] https://lists.wikimedia.org/pipermail/wikitech-l/2018- > June/090068.html > >> [2] https://www.mediawiki.org/wiki/Wikimedia_Technical_ > Committee/Charter > >> > >> ___ > >> Wikitech-l mailing list > >> Wikitech-l@lists.wikimedia.org > >> https://lists.wikimedia.org/mailman/listinfo/wikitech-l > > ___ > > Wikitech-l mailing list > > Wikitech-l@lists.wikimedia.org > > https://lists.wikimedia.org/mailman/listinfo/wikitech-l > > > ___ > Wikitech-l mailing list > Wikitech-l@lists.wikimedia.org > https://lists.wikimedia.org/mailman/listinfo/wikitech-l > -- Katherine Maher Executive Director Wikimedia Foundation 1 Montgomery Street, Suite 1600 San Francisco, CA 94104 +1 (415) 839-6885 ext. 6635 +1 (415) 712 4873 kma...@wikimedia.org https://annual.wikimedia.org ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Announcing TechCom’s Newest Members
Adding my congratulations to Niklas and Dan. You will bring a lot of wisdom, expertise and POVs to the committee. As we transform its mission and expand its scope, your contributions will be invaluable. Welcome! Victoria > On Jul 18, 2018, at 2:06 PM, Deb Tankersley wrote: > > Congratulations Niklas and Dan — we're happy to have you on the committee > and we're looking forward to adding your experiences, expertise and > strengths as well as your unique perspectives during our discussions! :) > > Cheers, > > Deb > > -- > > deb tankersley > > Program Manager, Engineering > > Wikimedia Foundation > > > On Tue, Jul 17, 2018 at 10:06 PM Daniel Kinzler > wrote: > >> Dear All, >> >> back in June the Wikimedia Technical Committee (TechCom) began a process to >> recruit two new members to broaden the committee’s area of expertise[1]. >> After >> some deliberation, we have now concluded our process and would like to >> welcome >> Niklas Laxström and Dan Andreescu to TechCom. Congratulations, we are >> looking >> forward to you bringing your expertise to the committee! >> >> For those who wonder what this is about: TechCom is the guardian of the >> integrity, consistency, stability, and performance of all software >> supporting >> the Wikimedia projects. It acts as the senior advisor and the convergence >> point >> of all decisions related to technical work that is strategic, >> cross-cutting, >> and/or hard to undo. You can find more information in the TechCom >> Charter[2]. >> >> To those who applied or were nominated, but were not selected, I want to >> say: >> thank you for offering your time and brain power! It was a difficult >> decision to >> make. We evaluated all candidates based on the following criteria: >> - Activity on RFCs and other Phabricator tickets >> - Area(s) of expertise >> - Having a unique engineering perspective >> - Experience working in and with the Wikimedia movement and community >> >> It was a challenge to balance these criteria, especially with candidates >> who >> have a lot of experience, but whose expertise and perspective is similar >> to that >> of existing members. In such cases, we aimed to improve the diversity of >> perspective and knowledge on the committee by picking candidates that >> would help >> us cover any blind spots. >> >> We plan to do another round of nominations again soon, and hope to have >> continued interested from others in joining TechCom. >> >> Thank you all, >> >> [1] https://lists.wikimedia.org/pipermail/wikitech-l/2018-June/090068.html >> [2] https://www.mediawiki.org/wiki/Wikimedia_Technical_Committee/Charter >> >> ___ >> Wikitech-l mailing list >> Wikitech-l@lists.wikimedia.org >> https://lists.wikimedia.org/mailman/listinfo/wikitech-l > ___ > Wikitech-l mailing list > Wikitech-l@lists.wikimedia.org > https://lists.wikimedia.org/mailman/listinfo/wikitech-l ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
[Wikitech-l] Add modules=site.styles inline
Hi all, It seems the Common.css on my website is pretty small but Resource Loader loads it using a tag in the head. I have read that it will be better to instead inline the styles or even load them later. What is the right way to go about this? Any suggestions are welcome. Also see https://developers.google.com/speed/docs/insights/OptimizeCSSDelivery Regards, Nischay Nahata ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
