Hello,
I have been a WP editor since 2006. I hope you can help me. For some reason
I no longer have Section Heading titles showing in the Articles. This is
true of all Headings including the one that carries the Article subject's
name. When there is a Table of Contents, it appears fine and, when I click
on a particular Section, it goes to that Section, but all that is there is a
straight line separating the Sections. There is also no button to edit a
Section. If I edit the page and remove the "…
[View More]== ==" markers from the Section
Titles, the Title then shows up, but not as a Section Heading. Also, I don't
have any Date separators on my Want List. This started 2 days ago. Any
thoughts?
Thanks,
Marc Riddell
[[User:Michael David]]
[View Less]
I know it has been annoying a couple of people other than me, so now that I've learned how to make it work I'll share the knowledge here.
tl;dr: Star the repositories. No, seriously. (And yes, you need to star each extension repo separately.)
(Is there a place on mw.org to put this tidbit on?)
------- Forwarded message -------
From: "Brian Levine" <support(a)github.com> (GitHub Staff)
To: matma.rex(a)gmail.com
Cc:
Subject: Re: Commits in mirrored repositories not showing up on my …
[View More]profile
Date: Tue, 09 Jul 2013 06:47:19 +0200
Hi Bartosz
In order to link your commits to your GitHub account, you need to have some association with the repository other than authoring the commit. Usually, having push access gives you that connection. In this case, you don't have push permission, so we don't link you to the commit.
The easy solution here is for you to star the repository. If you star it - along with the other repositories that are giving you this problem - we'll see that you're connected to the repository and you'll get contribution credit for those commits.
Cheers
Brian
--
Matma Rex
[View Less]
Hi,
On Tue, Mar 1, 2016 at 3:36 PM, David Strine <dstrine(a)wikimedia.org> wrote:
> We will be holding this brownbag in 25 minutes. The Bluejeans link has
> changed:
>
> https://bluejeans.com/396234560
I'm not familiar with bluejeans and maybe have missed a transition
because I wasn't paying enough attention. is this some kind of
experiment? have all meetings transitioned to this service?
anyway, my immediate question at the moment is how …
[View More]do you join without
sharing your microphone and camera?
am I correct thinking that this is an entirely proprietary stack
that's neither gratis nor libre and has no on-premise (not cloud)
hosting option? are we paying for this?
-Jeremy
[View Less]
Hello,
can someone to update list https://phabricator.wikimedia.org/P10500 which
contains repositories which haven't mediawiki/mediawiki-codesniffer.
I found in list that much repositories are empty, and repositories which
aren't available on Gerrit.
So, can someone please update this list of repositories (in
mediawiki/extensions) which haven't mediawiki/mediawiki-codesniffer, but at
least, contains one PHP file. or to provide me command with which I can
…
[View More]update list when I want, so I don't need to request it every time.
Best regards,
Zoran.
P. S.: Happy weekend! :)
[View Less]
Hi there,
I am investigating a breakage in my extension that has occurred in MW 1.34
but which didn't seem to be a problem on MW 1.29. (I have not tested
interim versions to see where the issue first arises.)
One of the parser hooks in the extension needs to perform variable
expansion. What is happening is a lot more complicated than this example,
but effectively
<my_hook Foo="What the foo!">{{{Foo}}}</my_hook>
should end up generating the following output, using …
[View More]variable expansion:
What the foo!
The semantics of variable handling need to follow the MW semantics,
including default values (possibly nested), parser functions, etc. therefore
it needs to use the MW parser to perform the expansion.
Assuming the arguments that MW passes into the parser hook are named $Text,
$Vars, $Parser and $Frame, the relevant code looks something like this
(again, a bit more complicated in practice):
$NewFrame = new PPTemplateFrame_DOM($Frame->preprocessor, $Frame,
array(), $Vars, $Frame->title);
return $Parser->replaceVariables($Text, $NewFrame);
(I have included a more detailed listing of the code that I am using for
doing the parse at the end of this message.)
My code was working fine on MW 1.29 and earlier, but when I upgrade to 1.34
I am finding that I get a fatal exception thrown when my tag is encountered:
/index.php?title=Main_Page MWException
from line 373 of ~\includes\parser\PPFrame_DOM.php:
PPFrame_DOM::expand: Invalid parameter type
I have generated a backtrace and the top of the stack is as follows:
#0 ~\includes\parser\Parser.php(3330): PPFrame_DOM->expand(PPNode_Hash_Tree,
integer)
#1 MyExtension.php (434): Parser->replaceVariables(string,
PPTemplateFrame_DOM)
#2 ~\includes\parser\Parser.php(4293): MyExtensionParserHook(string, array,
Parser, PPTemplateFrame_Hash)
(The subsequent call stack entries are the parent functions you would expect
to see in that situation.)
Can anyone see why the above code would no longer work as it did on previous
versions? What is the current recommended method for manually expanding
template variables from within a parser hook?
Kind regards,
- Mark Clements (HappyDog)
----------------------------------
Full example (with extension-specific code omitted):
----------------------------------
function MyExtensionParserHook($Text, $Vars, $Parser, $Frame) {
// 1) Manipulate $Text and $Vars
// (omitted)
// 2) Expand variables in the resulting text.
// Set up a new frame which mirrors the existing one but which also has
the
// field values as arguments.
// If we are already in a template frame, merge the field arguments with
the
// existing template arguments first.
if ($Frame instanceof PPTemplateFrame_DOM) {
$NumberedArgs = $Frame->numberedArgs;
$NamedArgs = array_merge($Frame->namedArgs, $Vars);
}
else {
$NumberedArgs = array();
$NamedArgs = $Vars;
}
$NewFrame = new PPTemplateFrame_DOM($Frame->preprocessor, $Frame,
$NumberedArgs, $NamedArgs,
$Frame->title);
// Perform a recursive parse on the input, using our newly created
frame.
return $Parser->replaceVariables($Text, $NewFrame);
}
[View Less]
/ sorry for cross-posting
Hi,
On a few first wikis[1], you can now highlight pairs of brackets in
wikitext. For this to work, you need to turn on the syntax highlighting
feature, which is part of the 2010 and 2017 wikitext editors. By placing
your cursor next to or within a set of brackets, you can then match round,
square and curly brackets. For more information about this feature please
visit its project page.[2]
Deployment to other wikis is planned for later this year. If your wiki
…
[View More]community wants to get bracket matching now, please contact me.
This change has been implemented by the Technical Wishes team who is
currently working on several projects within the focus area "Make working
with templates easier"[3]. Other projects in this focus area, including
those for the Visual Editor, are in the making.
Many thanks to all who have contributed to the realization of this project
through comments, interviews and more. Feedback is, as always, welcome on
the project's talk page.[4]
Thanks,
Johanna for the Technical Wishes team
[1] dewiki, cawiki and trwiki
[2] https://meta.wikimedia.org/wiki/WMDE_Technical_Wishes/Bracket_Matching
[3] https://meta.wikimedia.org/wiki/WMDE_Technical_Wishes/Templates
[4]
https://meta.wikimedia.org/wiki/Talk:WMDE_Technical_Wishes/Bracket_Matching
[View Less]
Hi,
I would like to uhhh... start the discussion? ask for opinions? about the
future of UploadWizard.
It is a rather special extension, that was from the start made mostly for
Commons' very specific needs and getting it to work anywhere else presents
some challenges (some of which I attempt to tackle here
<https://phabricator.wikimedia.org/T256616>). Interestingly, it still is
used by many third-party wikis
<https://linproxy.fan.workers.dev:443/…
[View More]https/wikiapiary.com/wiki/Extension:Upload_Wizard> and although some of
them don't need its full set of capabilities related to describing
licenses, authors and sources, there are wikis that do need that. The wiki
I maintain, Nonsensopedia, has a Commons-like file description system based
on Semantic MediaWiki (see example here
<https://nonsa.pl/wiki/Plik:Creative_Commons_evolution.jpg>) and
UploadWizard has been a *blessing* for us, greatly simplifying the task of
file moderation.
Opinion time: Wikis should be *encouraged* to properly describe the
authorship of files that they use, to meet the licensing requirements. IMO
Wikimedia Foundation as the maintainer of MediaWiki and a foundation
dedicated to dissemination of free culture should provide a usable tool for
properly describing free multimedia. UploadWizard could be just that.
At the same time, the extension has been basically unmaintained
<https://phabricator.wikimedia.org/T261589#6674315> since the Multimedia
team was dissolved and I've been rather surprised to discover that patches
improving third-party support were met with uhm... very limited enthusiasm?
<https://phabricator.wikimedia.org/T256616#6264584> There are a few obvious
features lacking like mobile support (seriously, try opening
https://commons.wikimedia.org/wiki/Special:UploadWizard on a narrow screen
device, it's been like this since.. always) and configurability (you have
to jump through some serious hoops
<https://www.mediawiki.org/wiki/Topic:V2at02b7oxy5pkwl> to just add a
license; customizing the tutorial is similarly hard).
I've been thinking of what to do with the above and I really wouldn't want
to embark on something that will be rendered redundant or obsolete in a
year, so my question is: are there any plans for UploadWizard? What makes
me suspect that things may change is primarily Structured Data on Wikimedia
Commons, which in the future will maybe (?) supersede the description
system around the {{Information}} template. Are there any rough roadmaps or
outlines of anything resembling a plan for that? If Commons was to
implement full, structured file descriptions in the upload tool, that code
would be probably hardly usable outside Commons, given that Wikibase is not
something easy to install or maintain, it is also awfully overkill for the
vast majority of applications. In such a situation, would it make sense to
consider completely separating the "Wikimedia Commons Shiny Upload Tool"
from a more general extension that would be usable for third
parties, stripped of any Commons-specific code? A lot of things could be
much simplified if the extension was to target just the needs of third
parties and not Commons.
I ask about this because I really don't see any sort of interest of the
extension's *de facto* owner (and that is WMF) in developing it, there are
also no public plans for it, as far as I know. Yes, I can make a fork
anytime, but first I'd prefer to know if I'm not missing something. Well,
actually, I already did make a fork of UW
<https://gitlab.com/nonsensopedia/extension-forks/uploadwizard-nonsa> over
a year ago, but this particular version of it is tailored for a wiki I
manage, making it useless for others. At the time that was the only
reasonable way we could get a good upload tool that was capable of properly
describing licensing information. I probably don't have to tell seasoned
open-source developers why this type of approach is not optimal for the
future of the project. :)
Any opinions on the topic are very welcome.
--
Ostrzyciel (he/him)
[View Less]
Hello all,
I’m pleased to announce that the Technical Decision Making Process[0]
proposed as an evolution of the Wikimedia Technical Committee[1]
(TechCom) process has been approved by the Wikimedia Foundation, and
will begin operation on 22nd of January. Back in October[2] and
November[3] I sought input into a proposed process and in December I
incorporated that feedback into the approved process.
This process is designed to be more inclusive by shifting the
representations. It has clear …
[View More]timelines for when decisions will be
made and to develop a clear lifecycle of a decision. The process is
designed to be clear about how and which stakeholders will be engaged.
It also introduces a Technical Decision Forum and Templates for the
process.
Currently a group from the Wikimedia Technology and Product
Departments are in the process of forming the initial Decision Forum.
The initial forum will include representatives from Wikimedia
Foundation teams, Wikimedia Deutschland, and independent +2
contributors. Please see the proposal for community representation on
the Decision Forum[4] and provide input by 2021-02-15. We know we will
need to adjust the representation in the forum over time. If you
believe you are from a group that is not represented and should be,
please contact us (tech-decision-forum-support(a)wikimedia.org).
If you currently have an RFC in process with TechCom that is not on
Last Call, it may need to be moved into this process. If you have
filed an RFC that is no longer relevant please close it. The group
setting up the process will be inquiring about the RFC status on the
individual Phabricator tickets.
To get started with this new process you just need to open a
Phabricator Ticket on the Technical Decision Making Process board[5].
If you need help getting started or have further questions please
reach out at tech-decision-forum-support(a)wikimedia.org or reply on
this thread.
[0] https://www.mediawiki.org/wiki/Technical_Decision_Making_Process
[1] https://www.mediawiki.org/wiki/Wikimedia_Technical_Committee
[2] https://lists.wikimedia.org/pipermail/wikitech-l/2020-October/093968.html
[3] https://lists.wikimedia.org/pipermail/wikitech-l/2020-November/094037.html
[4] https://www.mediawiki.org/wiki/Technical_Decision_Making_Process/Draft_Prop…
[5] https://phabricator.wikimedia.org/project/board/5179/
Thanks,
Kate
--
Kate Chapman (she/her/hers)
Director of Architecture, Architecture Team
Wikimedia Foundation
kchapman(a)wikimedia.org
[View Less]
