I just tested git fetch https://gerrit.wikimedia.org/r/mediawiki/extensions/CommentStreams refs/changes/93/1233393/9 && git checkout -b change-1233393 FETCH_HEAD

I just tested git fetch https://gerrit.wikimedia.org/r/mediawiki/extensions/CommentStreams refs/changes/93/1233393/9 && git checkout -b change-1233393 FETCH_HEAD

I just tested git fetch https://gerrit.wikimedia.org/r/mediawiki/extensions/CommentStreams refs/changes/93/1233393/9 && git checkout -b change-1233393 FETCH_HEAD

I just tested git fetch https://gerrit.wikimedia.org/r/mediawiki/extensions/CommentStreams refs/changes/93/1233393/9 && git checkout -b change-1233393 FETCH_HEAD

This patch worked for me as well.

Just checking in .. Does anyone know of any progress that has been made on this?

Ok. Thanks for reviewing this and pointing out the UrlGetParameters extension [1] as a way to accomplish this. I agree that that is a great solution to this use case. Hopefully this ticket will help someone else too.

Is there an example of the hook solution that I could review?

I'm glad to see some confirmation/recognition of the core security issue here. @Justin_C_Lloyd, do you think our two symptoms are related by the same underlying issue in PF_RunQuery? (i.e. where you are getting security flags and I am getting page errors due to haproxy blocking the request) .. do you think these are related?

This is the at-the-end-of-LocalSettings.php workaround that worked for me:

# To be added at the very bottom of /opt/meza/src/roles/mediawiki/templates/LocalSettings.php.j2 to allow VE to work in 35.x when meza_auth_type is "viewer-read" and apache is 100% localhost behind an SSL terminator/load-balancer/proxy front-end (like haproxy)

I noticed that this was a duplicate

It was recommended in one of the live channels that users of Variables should share their use cases with maintainers here on this phabricator thread. That said, that's what I'm hear to do.

PF Topic Ref 1: https://www.mediawiki.org/wiki/Extension_talk:Page_Forms/Archive_July_to_September_2020#Mapping_template_doesn't_work_when_multiple_values_in_tokens

last question for this topic .. Is it a goal of your to make the WMF OOUI icons usable in PF autoedit buttons?

Hmm.. Not sure what I'm doing wrong. This isn't working:

Cool. I'll test it out and let you know. Thanks!

Oh, wow.. those are great! Thank you for showing me this.

Ah. I see now how this capability was innately lost. Thanks for the background.

Please note that it does not support basic HTML character codes [1] either.

Yeah, I know there is another way to style it, but it would be nice if it still behaved that way it used to. That said, the non-explicit request was to restore said functionality, but if I understand correctly you're saying it's not a feature you ever intended and now that you know about it, you you're not inclined to make it a feature. Is that correct?

Thank 'You'! .. I'm happy to say that I'm now on PF 5.1 .. w00t!

Apparently my knowledge of git is not what it needs to be.

With VE being made part of MW core, it seems to me that Metrolook MUST become VE compatible. Can anyone provide an update to this task regarding Metrolook's compatebility with MW 1.35 and offer any advice for MW 1.34 users with VE installed? Thanks!

I fetched the latest version last night and checked out master and the problem still persists. I'll provide screenshots of all the relevant observables.

Hmm.. that is odd. I'll test it again tonight and report again. Maybe I did something wrong with the git checkout

just fyi, I tested the latest version of PF as of Jan. 24th 12:50am and this issue is not yet resolved.

Didn't see this action before I reported a similar issue here: https://phabricator.wikimedia.org/T271224

I think this is the same issue: https://phabricator.wikimedia.org/T262643

Is this commit from 1/12/2020 expected to be a fix for to this bug?
https://github.com/wikimedia/mediawiki-extensions-PageForms/commit/cbcc20bda8ad227220fb922f7b3aae9f1b673c81

comment deleted as it was for a different task.

I fetched and checked-out the latest from git on Dec 11, 2020 [1] and all our issues are resolved. Whatever you've done lately seems to have solved the issues. Legacy date formats are being handled by datepicker and the save button JS errors are gone. Thank you!

Is the fix mentioned above the solution? Is it pulled into PF master?

2020/12/08

bummer. good luck and thank you for your continued efforts.

Is there anyone who is willing give me some advice on how to debug/resolve this myself?

I don't know if this is a bug in Extension:Mermaid or in SKin:Metrolook, but I was able to solve this problem by adding some custom css to Mediawiki:Common.css. Ref: https://www.mediawiki.org/wiki/Topic:Vm95wz4fb17an7rw

Is there anyone who is willing give me some advice on how to debug/resolve this myself?

Is there anyone who is willing give me some advice on how to debug/resolve this myself?

I understand. Do you have any thoughts on how I might debug it? Any idea what could cause a page to scroll to the top no matter where you click it? Any insights or things to try would be greatly appreciated. I'd hate to have to disable Metrolook due to something so (presumably) simple for someone versed in responsive design.

I just thought that is was appropriate to assign them. My apologies if that was bad protocol. I thought it was the right thing to do. Was it?

Hi. Is there any workaround for this error?

I believe I was having the same issue that this person is reporting and I fixed it with: https://www.mediawiki.org/wiki/Topic:Vk4b9hbr6drvjysg

I believe I have isolated the behavior to the following JS code in Metrolook:

Even if it is the determination of the Metrolook developers that this is a Page Forms issue, I would be grateful for any simple ways to halt this behavior, even if it is kinda hackish. Thanks!