|
2019-10-23 14:00:25
|
<wm-bot>
|
Technical Advice IRC meeting starting in 60 minutes in channel #wikimedia-tech, hosts: - all questions welcome, more infos: https://www.mediawiki.org/wiki/Technical_Advice_IRC_Meeting
|
|
2019-10-23 14:50:09
|
<wm-bot>
|
Technical Advice IRC meeting starting in 10 minutes in channel #wikimedia-tech, hosts: @Lucas_WMDE - all questions welcome, more infos: https://www.mediawiki.org/wiki/Technical_Advice_IRC_Meeting
|
|
2019-10-23 15:03:08
|
<Lucas_WMDE>
|
oops, I’m late!
|
|
2019-10-23 15:03:18
|
<Lucas_WMDE>
|
anyways, welcome to the Technical Advice IRC Meeting!
|
|
2019-10-23 15:03:34
|
<Lucas_WMDE>
|
ask away :)
|
|
2019-10-23 15:05:13
|
<mainframe98>
|
If you have component that uses caching, said caching can be problematic when attempting to develop around said component. How do you ensure that during development (in a MediaWiki context) the cache is an EmptyBagOStuff instead of whatever caching solution is active?
|
|
2019-10-23 15:06:01
|
<mainframe98>
|
Right now, I've varied on the value of $wgDevelopmentWarnings to know whether the component is running in a development environment, but that does not feel like the right solution
|
|
2019-10-23 15:07:03
|
<Lucas_WMDE>
|
I’m not sure if I understand the question correctly
|
|
2019-10-23 15:07:10
|
<Lucas_WMDE>
|
but right now I have this in my LocalSettings.php, for example
|
|
2019-10-23 15:07:16
|
<Lucas_WMDE>
|
$wgParserCacheType = CACHE_NONE; // 2019-10-18 – rapid iteration on WikibaseClient Lexeme access
|
|
2019-10-23 15:07:32
|
<Lucas_WMDE>
|
that should effectively disable the parser cache
|
|
2019-10-23 15:07:52
|
<Lucas_WMDE>
|
I assume most caches you encounter should also have a similar variable that you can set to CACHE_NONE
|
|
2019-10-23 15:08:28
|
<Lucas_WMDE>
|
but that would need to be set by the developer themselves
|
|
2019-10-23 15:08:42
|
<Lucas_WMDE>
|
I’m not sure if we have any component that auto-disables its caching when it detects some kind of development environment
|
|
2019-10-23 15:09:18
|
<xse>
|
Hi, may i ask you guys a quick question ?
|
|
2019-10-23 15:09:43
|
<mainframe98>
|
In my case I have a service that depends on a caching service (e.g. MainObjectStash/LocalServerCache), but those are managed by the same config variable as other caches, which I don't want to disable.
|
|
2019-10-23 15:10:16
|
<Lucas_WMDE>
|
hm
|
|
2019-10-23 15:10:50
|
<mainframe98>
|
I'd rather not change $wgObjectCaches, and risk breaking sessions, since the component I'm testing requires me being logged-in
|
|
2019-10-23 15:13:32
|
<Lucas_WMDE>
|
can you introduce an additional config variable to switch that service between MainObjectStash and EmptyBagOStuff?
|
|
2019-10-23 15:14:37
|
<mainframe98>
|
Sure, so far I just used $wgDevelopmentWarnings, so then the replacement would become $wgEXTENSIONNAMEDevelopmentMode. It would be neat to allow the extension to toggle its development mode independently of core
|
|
2019-10-23 15:15:31
|
<mainframe98>
|
Is that a good idea however? I recall scrapping that idea a year or so back, and I don't remember why...
|
|
2019-10-23 15:16:00
|
<Lucas_WMDE>
|
I wouldn’t call it “development mode”, but more something like “enable cache”
|
|
2019-10-23 15:16:05
|
<Lucas_WMDE>
|
but that seems like an okay idea to me
|
|
2019-10-23 15:16:43
|
<Lucas_WMDE>
|
if the caching is new, that also makes the rollout easier – you can deploy the code but keep the setting false, then set it to true on individual wikis first
|
|
2019-10-23 15:16:54
|
<Lucas_WMDE>
|
xse: feel free to post your question btw
|
|
2019-10-23 15:17:31
|
<mainframe98>
|
Calling it enable cache would be an even better idea; especially since the manual I wrote states that enabling caching in MediaWiki is beneficial to the extension. Thanks!
|
|
2019-10-23 15:17:48
|
<Lucas_WMDE>
|
sounds good :)
|
|
2019-10-23 15:18:25
|
<xse>
|
On http://iso-9899.info/ i get the navigation bar appearing under the actual content rather than it being just under the logo. I'm not logged in, the page doesn't seems to give me any cookie/storage of any kind either.
|
|
2019-10-23 15:18:55
|
<xse>
|
Yet this is not happening for everyone, this does not seem to be a browser specific issue as i've tried both chrome & opera
|
|
2019-10-23 15:19:15
|
<xse>
|
I've found similar bugs reported but those were like 8 years old and related to firefox
|
|
2019-10-23 15:19:38
|
<xse>
|
I'm just wondering where that could came from
|
|
2019-10-23 15:20:32
|
<xse>
|
Here is a screenshot: https://i.imgur.com/KDSsFS6.png
|
|
2019-10-23 15:20:48
|
<Lucas_WMDE>
|
here’s a screenshot on my end: https://i.imgur.com/mTbFj8s.png
|
|
2019-10-23 15:20:57
|
<Lucas_WMDE>
|
that looks like normal monobook to me (search input is slightly messed up)
|
|
2019-10-23 15:21:01
|
<Lucas_WMDE>
|
hm, your screenshot is odd
|
|
2019-10-23 15:21:31
|
<Lucas_WMDE>
|
aha, in Chromium I get the issue too
|
|
2019-10-23 15:21:55
|
<xse>
|
good to know i'm not the only one, i get it on opera too
|
|
2019-10-23 15:24:08
|
<Lucas_WMDE>
|
checks Special Version
|
|
2019-10-23 15:24:11
|
<Lucas_WMDE>
|
…wow
|
|
2019-10-23 15:25:06
|
<Lucas_WMDE>
|
I don’t even want to imagine how many unpatched security vulnerabilities this wiki has
|
|
2019-10-23 15:25:35
|
<Reedy>
|
rofl
|
|
2019-10-23 15:26:11
|
<Reedy>
|
It's not even the latest 1.11 patch
|
|
2019-10-23 15:26:51
|
<apergos>
|
wow
|
|
2019-10-23 15:27:42
|
<apergos>
|
any chance you can update? you really really should if you can for security fixes
|
|
2019-10-23 15:27:55
|
<Reedy>
|
xse: I would consider upgrading to something that's supported rather than chasing down browser bugs from an ancient version
|
|
2019-10-23 15:28:34
|
<xse>
|
hehe yeah i guess that make sense
|
|
2019-10-23 15:28:57
|
<Reedy>
|
1.18 is from 2011...
|
|
2019-10-23 15:29:03
|
<Reedy>
|
So 1.11 is god knows :P
|
|
2019-10-23 15:29:18
|
<WhitePhosphorus>
|
maybe copyright (C) 2001-2007 tells
|
|
2019-10-23 15:29:20
|
<Lucas_WMDE>
|
well, 2007, if the copyright notice is accurate
|
|
2019-10-23 15:29:33
|
<Lucas_WMDE>
|
(nowadays it inserts $currentyear but back then apparently it didn’t)
|
|
2019-10-23 15:29:33
|
<apergos>
|
I have a question: how was the decision made to embed the page id in the text blob of a mediainfo entity? what are people thinking now that it's known that the id for the page associated with a revision may change?
|
|
2019-10-23 15:29:44
|
<apergos>
|
September 10, 2007 according to https://www.mediawiki.org/wiki/Release_notes/1.11
|
|
2019-10-23 15:32:47
|
<Lucas_WMDE>
|
apergos: I don’t know that, sorry
|
|
2019-10-23 15:33:08
|
<Lucas_WMDE>
|
anyone online who does?
|
|
2019-10-23 15:33:19
|
<James_F>
|
I think it was Daniel's code.
|
|
2019-10-23 15:33:31
|
<James_F>
|
But he's not in-channel.
|
|
2019-10-23 15:33:59
|
<apergos>
|
I figured there was some discussion around the time that format was decided, and was curious about that and plans to revisit
|
|
2019-10-23 15:34:08
|
<marktraceur>
|
apergos: I think we had a discussion a while ago about how page moves disrupt the file <--> entity connection, I don't recall the outcome off the top of my head
|
|
2019-10-23 15:34:35
|
<apergos>
|
there's an open task about deletes changing the page id and breaking mediainfo edits, which is how I stumbled onto it
|
|
2019-10-23 15:34:36
|
<Lucas_WMDE>
|
though I’m not sure if embedding the page ID in the content was a conscious decision
|
|
2019-10-23 15:34:45
|
<marktraceur>
|
Right, that's the one
|
|
2019-10-23 15:35:00
|
<apergos>
|
no real outcome on that task
|
|
2019-10-23 15:35:10
|
<apergos>
|
but it's an interesting issue
|
|
2019-10-23 15:35:11
|
<Lucas_WMDE>
|
I wouldn’t be surprised if storing entity IDs in the blob was an old Wikibase decision, and then later it was decided to use the page ID for the MediaInfo entity ID, without realizing this would make it part of the serialization
|
|
2019-10-23 15:35:19
|
<Lucas_WMDE>
|
I think the task you’re talking about is https://phabricator.wikimedia.org/T231276 ?
|
|
2019-10-23 15:35:28
|
<Lucas_WMDE>
|
on a related one at least
|
|
2019-10-23 15:37:48
|
<apergos>
|
mm no it's uh https://phabricator.wikimedia.org/T232087
|
|
2019-10-23 15:39:05
|
<Lucas_WMDE>
|
ouch
|
|
2019-10-23 15:39:08
|
<Lucas_WMDE>
|
hadn’t seen that one
|
|
2019-10-23 15:39:47
|
<James_F>
|
Yeah, it's all stemming from the original Wikibase design, sadly.
|
|
2019-10-23 15:39:59
|
<James_F>
|
Where it makes sense, but post-MCR it doesn't.
|
|
2019-10-23 15:40:25
|
<Lucas_WMDE>
|
I still don’t understand this deletion/undeletion business
|
|
2019-10-23 15:40:31
|
<Lucas_WMDE>
|
is it a way to split the page history in two?
|
|
2019-10-23 15:40:47
|
<Lucas_WMDE>
|
you end up with two pages, and both of them have the revisions before the split, and separate histories since then?
|
|
2019-10-23 15:40:54
|
<Lucas_WMDE>
|
and one gets to reuse the old page ID, and the other does not?
|
|
2019-10-23 15:41:12
|
<Lucas_WMDE>
|
because the two files in https://phabricator.wikimedia.org/T232087#5475561 are clearly related
|
|
2019-10-23 15:42:16
|
<apergos>
|
yeah I dunno, it might be as you say
|
|
2019-10-23 15:43:14
|
<Lucas_WMDE>
|
not sure if I got it right
|
|
2019-10-23 15:43:18
|
<Lucas_WMDE>
|
but https://commons.wikimedia.org/wiki/Commons:History_merging_and_splitting has some more info
|
|
2019-10-23 15:43:28
|
<Lucas_WMDE>
|
looks like delete/undelete are being (ab)used for *some* history manipulation, definitely
|
|
2019-10-23 15:43:33
|
<Lucas_WMDE>
|
even if I don’t understand the details ^^
|
|
2019-10-23 15:46:02
|
<apergos>
|
if a feature can be used in some other way than the devs intended, it will be
|
|
2019-10-23 15:46:13
|
<apergos>
|
and that will soon become a primary usage...
|
|
2019-10-23 15:46:32
|
<Lucas_WMDE>
|
damn our resourceful and inventive users ;)
|
|
2019-10-23 15:47:02
|
<rlazarus>
|
https://www.hyrumslaw.com/ :)
|
|
2019-10-23 15:48:23
|
<apergos>
|
I'll take 'MediaWiki parser edge cases' for $400, Alex
|
|
2019-10-23 15:48:28
|
<Lucas_WMDE>
|
also known as the lament of the Parser team? :)
|
|
2019-10-23 15:48:32
|
<Lucas_WMDE>
|
damn, apergos beat me to the joke
|
|
2019-10-23 15:48:35
|
<apergos>
|
heh
|
|
2019-10-23 15:50:17
|
<AntiComposite>
|
https://xkcd.com/1172/
|
|
2019-10-23 15:52:37
|
<apergos>
|
it me
|
|
2019-10-23 16:00:24
|
<Lucas_WMDE>
|
ok, our time is up – that concludes the Technical Advice IRC Meeting! thanks everyone for participating :)
|
|
2019-10-23 16:00:38
|
<Lucas_WMDE>
|
and you can always leave questions over at Wikimedia Developer Support: If136928bda
|
|
2019-10-23 16:00:41
|
<Lucas_WMDE>
|
oops
|
|
2019-10-23 16:00:43
|
<Lucas_WMDE>
|
https://discourse-mediawiki.wmflabs.org/
|
|
2019-10-23 16:02:28
|
<apergos>
|
thanks for hosting another fun and informative session!
|
|
2019-10-23 16:06:56
|
<xse>
|
Have a good day!
|
|
2019-10-23 16:18:00
|
<Iluvatar_>
|
hello all. How i might send ajax request to toolforge from personal js? Request is blocks by content security policy.
|
|
2019-10-23 16:18:28
|
<Iluvatar_>
|
https://test.wikipedia.org/w/index.php?title=User:Iluvatar/vector.js
|
|
2019-10-23 16:29:53
|
<Lucas_WMDE>
|
hm, not sure to be honest
|
|
2019-10-23 16:29:57
|
<Lucas_WMDE>
|
there’s a task for opting out of CSP (https://phabricator.wikimedia.org/T208188)
|
|
2019-10-23 16:30:07
|
<Lucas_WMDE>
|
but it’s not implemented yet, as far as I can tell
|
|
2019-10-23 16:30:14
|
<Lucas_WMDE>
|
and anyways I’m not sure if Toolforge should require that opt-out
|
|
2019-10-23 16:30:30
|
<Lucas_WMDE>
|
I didn’t realize we already enabled the CSP on test wiki(s?), I thought it was still report-only
|
