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]
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512
Hi,
I (with Reedy's help) recently started work on librarizing MediaWiki's
IP class into a separate composer package (wikimedia/ip-utils[1]). The
main motivation was so that the Parsoid PHP port could use it[2].
However, I ran into an unexpected hitch[3], as it seems we're using
the IP class before the composer autoloader is even intialized. Here's
the basic initialization in Setup.php:
- - AutoLoader.php (MediaWiki's)
- - Defines.php
- - …
[View More]DefaultSettings.php
- $wgServer = WebRequest::detectServer()
- Calls IP::splitHostAndPort()
- - GlobalFunctions.php
- - vendor/autoload.php (composer's)
My understanding is that composer's autoloader runs late so extensions
registering themselves using it can add their stuff to the necessary
globals.
And we call WebRequest::detectServer() in DefaultSettings.php so that
in LocalSettings.php people can use the value of $wgServer for other
stuff.
I see 3 main ways to move forward:
1. Move vendor/autoload.php earlier in Setup.php, potentially breaking
extensions that still rely on composer autoloading for initialization.
2. Set $wgServer = false or something in DefaultSettings.php, and then
fill it in later in Setup.php *after* the composer autoloader has been
loaded, potentially breaking anyone relying on the value of $wgServer
in LocalSettings.php.
3. (status quo) not librarize code that runs before composer
autoloader initialization. :(
Advice/input welcome.
[1] https://packagist.org/packages/wikimedia/ip-utils
[2]
https://gerrit.wikimedia.org/g/mediawiki/services/parsoid/+/77064cfff717
6493a2828bb4f95f397dfce7d659/src/Utils/Title.php#46
[3] https://gerrit.wikimedia.org/r/c/mediawiki/core/+/519089/
- -- Legoktm
-----BEGIN PGP SIGNATURE-----
iQIzBAEBCgAdFiEE2MtZ8F27ngU4xIGd8QX4EBsFJpsFAl0S1oQACgkQ8QX4EBsF
Jpufrg/+J9RUUxRAtgJLEkyACE6GREis0eyEIZnWmMr3s9YpFPoqtWocFrUk6Wsn
W7d9Oda/8CW0/d894gGMn8LWIj9oWq2gMPWzCVFpg8uu3r4967qxBp+ba29uMOJw
Qpw6DhXtPvVAeUCy8P38Y5vM7TGmV+J1T5jDY21zimT1dRrJsI1KD+u/Ue3nYy/y
B1ic3i7vJfhYErdhHgN98ETXfXOaDx4rgd2N7PLjVNx3IYCC8LNiR8wSLuydfdbk
PLTT1bA2qi0h2wgcEr7Qtq9YstVotq8899rgKLtGDBwQi3qGNcdOgQGEMFDVfjfO
CsiWocj6s4oc3ScVj+Eb9xtvIqhNx+oRbWE1vKd4TmtSdyzpv6xadV60tq5qNFEY
I0cBDOWU5UFNHbvbyjK4dqIDEVhJ6LiEgLVBOj81U27s8mR4Dv/yFB3eac0ROk7p
gaEeOjfhtVU558XfpEsmu1H05VJT3kXNxK8y0UQOjy11SErzsXv6vDzyzLDJM/W7
WF0I4nyjeqVsBjLBN9li+5AnU3cAKVOCfZ+/aRYyg89Du//nJRjm+4lxnuPrGlaG
ES/nVUnkDZ9Yc/xA1yacm3Ytx9hpoY1mIZgxxxveyeU1KsNXAZ2BOGA2T7kU4yUw
Uyg+byYwI+1uVOjAVd3BInGV2R2/GmeIn9FOpthBaw8wcz0Y/8c=
=tU4+
-----END PGP SIGNATURE-----
[View Less]
Hi Everyone,
It's time for Wikimedia Tech Talks 2019 Episode 6!
Next month's talk will take place July 10, 2019 at 4:00 PM UTC.
Topic: A Deployment Pipeline Overview
Speaker: Alexandros Kosiaris, Senior Operations Engineer
Summary: The deployment pipeline project has been ongoing for a while,
sometimes with more resources poured into it, sometimes less, but it's
finally in a state that is ready to be used (it's already being used!).
This tech talk is about a presentation to wider technical …
[View More]audiences,
discussing the goals of the project, the implementation decisions and
how it's meant to be used and adopted by the deployers of services
(and eventually MediaWiki) in the coming months.
YouTube stream for viewers: https://www.youtube.com/watch?v=i0FTcG7PxzI
During the live talk, you are invited to join the discussion on IRC
at #wikimedia-office
Those in the SF office can watch this in R124.
You can watch past Tech Talks here:
https://www.mediawiki.org/wiki/Tech_talks
If you are interested in giving your own tech talk, you can learn more here:
https://www.mediawiki.org/wiki/Project:Calendar/How_to_schedule_an_event#Te…
Subbu.
(Standing in for Sarah Rodlund who is currently away on sabbatical)
[View Less]
I'm getting a new error today that was not happening with the identical
config yesterday.
With MW 1.31.1 and 1.31.2 I'm getting errors after installing dependencies
and extensions with Composer. I have the following composer.local.json:
```
{
"require": {
"mediawiki/semantic-media-wiki": "3.0.0",
"mediawiki/semantic-result-formats": "3.0.0",
"mediawiki/semantic-compound-queries": "1.2.0",
"mediawiki/sub-page-list": "1.5.0",
"mediawiki/maps": "6.0.3",
"pear/net_smtp": …
[View More]"1.8.0" <-- remove this when using MW 1.31.2
},
"extra": {
"merge-plugin": {
"include": [
"extensions/SyntaxHighlight_GeSHi/composer.json",
"extensions/Elastica/composer.json"
]
}
}
}
```
SyntaxHighlight_GeSHi and Elastica are both tracking their REL1_31
branches, which haven't changed in about a year. Despite that, yesterday
running `composer update` caused no issues. Today I started getting the
following error:
```
[Wed Jun 26 16:16:18.364715 2019] [php7:warn] [pid 12304] [client
my.ip.add.ress:46156] PHP Warning:
require(/opt/htdocs/mediawiki/vendor/composer/../jetbrains/phpstorm-stubs/PhpStormStubsMap.php):
failed to open stream: No such file or directory in
/opt/htdocs/mediawiki/vendor/composer/autoload_real.php on line 70,
referer: https://example.com/
[Wed Jun 26 16:16:18.364896 2019] [php7:error] [pid 12304] [client
my.ip.add.ress:46156] PHP Fatal error: require(): Failed opening required
'/opt/htdocs/mediawiki/vendor/composer/../jetbrains/phpstorm-stubs/PhpStormStubsMap.php'
(include_path='/opt/htdocs/mediawiki/vendor/pear/console_getopt:/opt/htdocs/mediawiki/vendor/pear/mail:/opt/htdocs/mediawiki/vendor/pear/mail_mime:/opt/htdocs/mediawiki/vendor/pear/mail_mime-decode:/opt/htdocs/mediawiki/vendor/pear/net_smtp:/opt/htdocs/mediawiki/vendor/pear/net_socket:/opt/htdocs/mediawiki/vendor/pear/pear-core-minimal/src:/opt/htdocs/mediawiki/vendor/pear/pear_exception:.:/usr/share/pear:/usr/share/php')
in /opt/htdocs/mediawiki/vendor/composer/autoload_real.php on line 70,
referer: https://example.com/
```
Using MW 1.32.1 and 1.31.2 I did the following:
```
rm -f ./composer.lock && composer install && sudo systemctl reload httpd
# no mention of phpstorm-stubs in output
# page loads fail
rm -f ./composer.lock && composer install --no-dev && sudo systemctl reload
httpd
# output includes: Removing jetbrains/phpstorm-stubs (dev-master)
# page loads succeed (no phpstorm-stubs)
composer install && sudo systemctl reload httpd
# output includes: Installing jetbrains/phpstorm-stubs (dev-master
9d01ce3): Cloning 9d01ce3476
# page loads succeed (phpstorm-stubs @ 9d01ce3)
composer update && sudo systemctl reload httpd
# output includes: Updating jetbrains/phpstorm-stubs dev-master (9d01ce3 =>
1b99060): Checking out 1b9906084d
# page loads fail (phpstorm-stubs @ 1b99060)
```
I need the httpd reload to invalidate opcache in my config. Based upon the
above it seems that the phpstorm-stubs that is getting required from
non-dev dependencies doesn't have issues, but the one from dev dependencies
does. Or perhaps something to do with Composer or with the Composer merge
plugin is causing one version of phpstorm-stubs to be checked out but the
autoloader to be setup for the other version. Any thoughts?
Thanks,
James
[View Less]