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!

Is it true that these issues will likely go away when I upgrade to 1.31?

The script doesn't give me any way to identify which files are producing this warning or how to fix them. Are there any better diagnostics I can run?

Sounds like an issue that might gain traction in the WMF group. What are the odds someone will make the message I care about a localized message in a reasonable timeframe?

Unfortunately it seems that 3 is not a system message and is hard-coded by VE as raw text

matmarex .. understood .. testing

Gotcha. Yes, your "watch" star comparison is exactly right.. and I think you are 100% correct on all additional counts as well. I think this means that the solution to my scenario would need to be two-fold: A) Yes, there is a a CORS policy issue, but also B) even when the CORS Policy is lifted there is an further error handling situation that would be revealed next.

Thanks, Tgr.. how do this kind of things get prioritized? Is this feature request in the dead-letter office?

In T19577#4303752, @Ciencia_Al_Poder wrote:

I use a custom-made extension that adds the file timestamp to the URLs (thumbnails and original file). If anyone is interested, the code is here and can be seen on wikidex.net

Normally, with simpleSAMLphp SSO integration, when the client's session expires, the very next request the client makes from the browser (to a resource on the server) is redirected (by the simpleSAMLphp auth plugin on the server) to the designated SSO site. After the client works through whatever steps are necessary to re-authenticate, the remote SSO returns the client to the application resource that was originally requested. This all works perfectly for the normal mediawiki edit process. The problem with VE seems to be that the request the client is making to the server is done via AJAX in the browser which (from the perspective of the remote SSO) is deemed "cross-domain" and violates the server's CORS policy. If the session is secure, VE has no problems. The problem is when the session needs to be re-established and the user is messing with VE.

The issue seems to always occur when <in /> is called from a template and no specific named counter has been defined.

@Jamesmontalvo3 , I'm running Meza 31.8.2 and I'm still seeing this PHP Warning from certain pages when I run the refreshLinks maintenance script. It might be triggered by certain pages where the {{counter:}} function is being used, but it doesn't report which pages that is.