It's question of time, not technology. I use extensions, which complicate this upgrade and I have not time be solving problems extensions of another maintainers for now. My wikis is more complexity then another, and extension development is secondary product, because using orphaned extensions too which I must solved alone.
I am sorry, but for now I can't do any test for versions >1.39.x because all my wikis use MediaWiki 1.39.x
I want do upgrade, but it's complicated because new version OS (Debian Bookworm) use PHP 8.2, unsupported by MediaWiki 1.41. I am waiting for next version branch (LTS), which be created probably in summer.
Hallo boys, you are very actively for me, because I use on my wikis only 1.39.x versions and for now have not time for testing code by virtal machine. But change see as ok by my mind.
I ran into the same problem. I don't know if this can be considered a solution, because these steps have to be done on the server side, but I solved my problem:
Ha! I'm not very proficient in working with gerrit, so I didn't think to click on Reviewers, and set the necessary parameters to display the submit option.
It may be not access problem, but procedure. I pushed initial code (link above), but repository is empty, because it wait - for Verify(?) I don't know what is need do for submit into master branch.
I have problem with merge initial patch. May be is it my problem, because I do push before set rights for merge repository. Now is patch in state, where wait for Verify but for now not another member in the group, which can do it. I don't know, if abandon this review, , and try push with new review. This is link to review:
2016 year problem is obsolete.
Unfortunately, I have not been able to simulate your problem. In my opinion, the template page was not created correctly. What was its content? It's important. Isn't this template generated through Scribunto?
Wantadded a hashtag to
MediaWiki-extensions-AccessControl:
#accesscontrol.
Wantadded a watcher for
MediaWiki-DjVu:
Want.
I not meet similary problem in years. It first bug report by me, I am sorry.
I integrated into code new global variable $wgAccessControlMeta, which can change redirect target to page from $wgSitename (default), to use $wgMetaNamespace, if value 'true'. (commit d8bc0e0f11fe22f21e80986f20b3e9822a155310)
Into master branch was merged (2023-03-01 00:43:26) from form-support branch new version AccessControl 6.0, which use hook getUserPermissionsErrors.
Gerrit. AccessControl (maintained by me) has repo in Gerrit too. At least I will work with it more often and reduce the likelihood of forgetting how to do what again. ;-) For it my request, create new project EImage, because it's condition for repository request ( https://www.mediawiki.org/wiki/Gerrit/New_repositories/Requests )
Hi @Want, thanks for taking the time to report this! https://www.mediawiki.org/wiki/Extension:EImage currently says it's archived. https://www.mediawiki.org/w/index.php?oldid=4058612 points to https://github.com/Robpol86/EImage/ being read-only. Where to find the current code URL? :)
Its project based on orphaned Extension:EImage, which I use on my wiki with combination ImageSizeInfoFunctions extension. I have repaired code for use with MW 1.39 LTS, and my plan is merge both.
It's simple. I do administration for two instances MediaWiki. Both use stable MediaWiki 1.35 MediaWiki on Thewoodcraft.org is more complicated or any Wikimedia project. It's realy multilanguage wiki and for it is upgrade very complexity changes – every problem must be solved before I can say „it as done”.
My work isn't developing MediaWiki extension. MediaWiki is only tool for me and solving want a time, which is very shortlu. If anybody want remove hook used by me, must give adequatelly alternative first. And who which used my work, must be wait or try rewrite code for it.
It's simple. Do redirect to info page early, than is blocked access by rights. The parser do redirect, without continue in processing of the content of the protected page.
Hi, I use very intensive on my wiki thewoodcraft.org extensions as Variable, Loop, or ParserFunctions. I don't use Scribunto. By me, is using Lua to work with variables and conditions is perversion. Native PHP code is more effectively for it. I prefer extensions what use native PHP for it.
Ah, sorry, I overlooked ticket of version. But it's same. Version 3.0.1 support old syntax too, but it no support user names or mediawiki groups in tag accesscontrol. Only access lists. In czech manual 'skupina uživatelů' is equivalent for access list (page with list of users) and 'seznam uživatelů', defined by parameter 'editAllowedUsers' (or 'readOnlyAllowedUsers') is list of users. Array of users with access to page is generated from raw content of target page with users list.
Version 2.x in MediaWiki is deprecate. More before year was extension completly reworked. But this using groups is invalid for both versions. AccessControl not use MediaWiki groups, but access lists (normal mediawiki page), wíth list of usernames. If you use only 'user', try find page 'user' in main namespace. If not exist, list is empty.
The problem was solved during Hackaton 2019.
Have you tried logging in with both capital letter (Want) and want?
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4