No proton is the renderer, it doesn't determine what gets rendered. That is mostly a Collection extension problem + infra.
small note.. seems that hhvm is out of date with php7 here and doesn't support webp with its getimagesize.. possibly this should therefor wait for our complete php7 switch ? or wrap in HHVM conditional...
This is because we reuse ids.. and render the new player in detached mode, before removing the old player.. But video.js keeps global dom state, which is only removed when you use the .dispose() function on the player.. And since we don't, the 'new player' reuses context from the 'old' player...
T228250: PHP Notice: Undefined property: stdClass::$module in OATHAuth/src/OATHUserRepository.php on line 193 could be a potential blocker ?
but.. have those db changes run on WMF production already then ? I only see a note of them having been deployed to beta.wmflabs
Note that getimagesize and getimagesizefromstring are part of standardlib not GD, even though they are documented on the GD page (were they originally part of GD?)
Tue, Jul 16
because i already did so ;)
Mon, Jul 15
Pretty sure this is: T129546: Support preserving external links in pasted HTML content
Sat, Jul 13
Note that this thing isn't really meant to be used in the first place ;)
It's more a test page for the tiles renderer, and people tend to embed the maps directly in their own copies of openlayers and leaflet
Note that this thing isn't really meant to be used in the first place ;)
It's more a test page for the tiles renderer, and people tend to embed the maps directly
right, i was still in the process of swithing this thing to leaflet
Fixed, this was lost at some point probably due to switching from .OSM to .XYZ layers, which caused it to loose the automatic attribution.
The original is upside down, with a 180degree rotation file annotation. Apparently at some point the transcodes for that recognized this and fixed it.
Fri, Jul 12
Thu, Jul 11
While perhaps not perfect, this should get us by for now. Further issues can be filed separately.
Wed, Jul 10
the version check for php won't help you in giving useful feedback as you will receive a syntax error.
Ah, so this broke the version check?
User is using MariaDb. Another user just reported:
I've updated the description a little bit, to more accurately reflect the current status.
I note that this introduced php 7 syntax into the update.php script.
This means that if you use php56 and try to run update.php and accidentally you use php56 as a command line default etc. the version check for php won't help you in giving useful feedback...
Maybe an update to the class documentation to make it easier to distinguish between proper use and inproper uses ?
Tue, Jul 9
i've long since said we should just provide both and allow users to switch between them, like we now do for normal diff and VE diff.
Mon, Jul 8
@Jnanaranjan_sahu This ticket is about sorting the results retrieved from their search terms, in order of certain date fields instead of 'relevance'. It is not about making the dates themselves search terms.
I don't think this is related to CSP. The server now doesn't respond at all for me, not even via curl. I get a 502 bad gateway after about 10 seconds or something.
Fri, Jul 5
Thu, Jul 4
Just wondering if there has been progress here since the hackathon.. ?
We got kinda bogged down back then in tool forge
- I see no community discussion approving this change across multiple wikis in the task description. I only see a (partial) technical discussion above
Was there a community discussion for introducing the not BCP 47 conform language codes sr-ec and sr-el instead of the BCP 47 conform language codes sr-cyrl and sr-latn? The standard BCP 47 is not made by the community.
@Aklapper's results are strange.. All video elements are hinted not to preload.. All JS instantiations on pages with more than 10 videos are also hinted NOT to preload. As such entire downloads really shouldn't be possible.. Maybe Chrome is being too smart for it's own good.
Chromium has a --window-size option, that Proton might be able to use for making viewport consistent ? Downside of that would probably be that very wide images and tables might get cut off of course.
Wed, Jul 3
So to be accurate. The original files are generated in a way that accurate length calculation is 'difficult', esp for short clips. The video.js player is less sensitive to this so yes would fix this. For the old player, it's possible to download the original ogg file and 'remux' it with VLC media player or something and then upload again. In that case the old player also works (i've done this for quite some files throughout the years).
I've looked at these disabled tests a little bit yesterday..
Those are currently full-blown integration tests that are depending the job queue and the live database..
@Nardog true.. assuming it's only en.wp and assuming someone exports the list of those files before running the 1st script ;)
This change has one glaring problem. Most projects have edit notices for people trying to create new pages. This text displays fine in standard wikitext editor, but in any visual editor (we should have a better name for them) it gets shoved away into a small box which usually ends up not fitting the screen.
I'm not sure if this will also kick off transcodejobs... We might have to do another run of T226713: Run cleanupTranscodes.php for current midi files for this files to start transcoding ? Would you know that @brion ?
So next step here is to figure out how we can make Score use the Transcode pipeline.
So I think this requires running
Yes this is expected. The old player was always in block mode, while the newer player allows inline positioning (just like normal images do). That might require Score+TMH to have an additional CSS line to force it to the next line. Not sure if this should be in Score or in TMH...
@Jdforrester-WMF T226371: Beta player slow at loading many videos in Firefox might require us to dive back into one of these proposed solutions, but for basic playback I do not consider this a blocker at this point.
Mon, Jul 1
I'll take a look at this, as we now no longer support on MwEmbedSupport
Sun, Jun 30
There are 3 options I think.
Sat, Jun 29
nice work @Isarra
Fri, Jun 28
I have this too.
Just happened to me again as well. Unfortunately i didn't have the inspector open when loading the page, so i couldn't find by any of the HTTP headers. Next call was just fine. This occurred around: 28 Jun 2019 12:17:11 GMT
For Commons yes. We have a few more wikis with midi however.. esp. en.wp has quite a few midi files.
Wo maybe we can run a database maintenance script instead...
Thu, Jun 27
Notes to self
No, see it like this.. when there are 25000 icons locations, you can only focus on 2000 or so (regardless of how little or stupid they are). But this is getting a bit off topic. let's shut this discussion down.
This is not a company, it's a highly underfunded development department of an NGO with a couple of extra volunteers on the side, topped off with a customer base that is gigantic and will burn the place down if they don't like something ;)
what would be the difference between "no full support" and "no support".
The versions of those plugins have wildly diverged since 2012 ('ish?).
Hmm, for this to work, someone needs to purge all the mid page uploads, and then initiate the transcode for the newly listed derivatives...