Hi all,
I am running MediaWiki 1.26, and trying to force it to be all-SSL, all the time, excepting a particular Special: page. To that end, I have code which makes the following method call from a 'BeforeInitialize' hook:
$this->output->redirect($https_url, 301);
However, by the time processing gets to OutputPage:output() method, the OutputPage::$mRedirect attribute is empty. I think this is because our wiki is also configured to require logins to read, and when accessing it as anonymous user on plaintext port, OutputPage::prepareErrorPage gets run AFTER we send the SSL redirect, but BEFORE the actual output rendering occurs.
My simple solution to this is to forcibly invoke OutputPage::Output on the spot, right there in the 'BeforeInitialize' hook:
$this->output->redirect($https_url, 301);
$this->output->output();
However, while it LOOKS safe (because OutputPage::output does a return after setting redirects, rather than continue on to process output), I still have a bad feeling about this. I don't like messing with order-of-execution in such a crude manner.
Can anyone either confirm that it's safe, or offer a superior alternative - a way of forcing a redirect safely, even if an ErrorPage would be rendered otherwise?
I know that I can use PHP's 'header' method directly, but that also skips MediaWiki housekeeping, so I don't particularly like that route either.
Thanks in advance!
Setting up a secure VisualEditor for private Wikis seems to have been a glaring omission, but the Parsoid docs claim Parsoid is always necessarily running over plaintext. So I added a section on setting up Parsoid over HTTPS<https://www.mediawiki.org/wiki/Extension:VisualEditor#Parsoid_over_HTTPS> (using STunnel) to the Extension:VisualEdtior page.
This should allow folks to have secure VisualEditor configuration for private Wikis. I hope it helps.
Hi,
Some of you may be familiar with http://commoncrawl.org ; they are
doing an excellent job of making large crawls of the web accessible to
everyone.
I've been working on an open search engine based on these crawls for a
while, and I would love to have your feedbacks on the project:
https://about.commonsearch.org/
Specifically, I would be curious to know what you would consider to be
the best possible integration of Wikipedia & Wikidata in a general
search engine?
As a first step, we have just started using the "official website"
property from Wikidata and we are considering importing the Wikipedia
abstracts next (https://github.com/commonsearch/cosr-back/issues/11).
I'm looking forward to your feedbacks... or contributions! :-)
Thanks in advance,
PS: A few wikimedians recommended me to post on wikitech-l to keep the
focus on the technical aspects of the project and hopefully avoid
linking this project in any way to the KE stuff, which it actually
predates by far (https://news.ycombinator.com/item?id=6209088).
--
Sylvain Zimmer
http://sylvinus.org
Hello,
My name is Yolande Amate from the University of Buea Cameroon. I am
proficient in C, C++, PHP and Python. I am new to open-source and I would
like to participate in the Google Summer of Code 2016 / Outreachy Round 12
with the Wikimedia Foundation.
I am interested in working on the project "Python library for quiz data,
with serialisation".
Thanks
Yolande
There will be a brown bag Tuesday, March 1st at 1pm Pacific time. We will
review some new changes to Phabricator. Many of these changes will be
relevant specifically to advanced users.
We will review:
- where Phabricator administration conversations are happening
- the custom forms feature
- the updates to projects, sub-projects and milestones
- other smaller changes
We should have plenty of time for Q&A
Blue jeans link [1]
The Blue Jeans video will be recorded. The recording and slide deck will be
posted to the Phabricator mediawiki pages [2].
[1]
https://bluejeans.com/105994346
[2]
https://www.mediawiki.org/wiki/Phabricator
Fallback is: cable up the old 1GB nic (Chris has done this and set up the
port), PXE install on that, move to 10gb NIC once we're back up. Gross but
it gets the job done.
Set for tomorrow (Friday) 1 to 4 pm UTC, this time should be much smoother.
Same caveats apply as before.
Ariel
On Wed, Mar 2, 2016 at 8:47 PM, Ariel Glenn WMF <ariel(a)wikimedia.org> wrote:
> PXE boot from non-embedded nic failed spectacularly despite our best
> efforts. This means we'll have to schedule another window once we have
> someting new to try. I apologize for the extra inconvenience. All services
> are back exactly the way they were.
>
> Ariel
>
> On Wed, Mar 2, 2016 at 6:01 PM, Ariel Glenn WMF <ariel(a)wikimedia.org>
> wrote:
>
>> Extending this downtime window because we ran into unexpected issues with
>> PXE boot.
>>
>> On Tue, Mar 1, 2016 at 3:53 PM, Ariel Glenn WMF <ariel(a)wikimedia.org>
>> wrote:
>>
>>> Dataset1001, the host which serves dumps and other datasets to the
>>> public, as well as providing access to various datasets directly on
>>> stats100x, will be unavailable tomorrow for an upgrade to jessie. While I
>>> don't expect to need nearly 3 hours for the upgrade, better safe than
>>> sorry. In the meantime all files will be accessible via
>>> ms1001.wikimedia.org via the web, and all dumps and page view files
>>> from our mirrors as well.
>>>
>>> Thanks for your understanding.
>>>
>>> Ariel Glenn
>>>
>>>
>>>
>>
>
As you know, one of the quickest ways of getting your fix backported to
production (from master) is to use a SWAT window:
https://wikitech.wikimedia.org/wiki/SWAT_deploys
And now, I ask for new volunteers!
Would you like to help make developers happy and be a part of the crew
of people who deploy during these windows? Of course you would!
These happen twice a day every work day (except Friday, naturally) at
8:00 SF (16:00 UTC currently) and 16:00 SF (00:00 UTC).
We're open to both those already familiar with deploying to Wikimedia
servers and those who are not; we're friendly and willing to teach :)
Requirements are:
* A shell account on production
** See: https://wikitech.wikimedia.org/wiki/Requesting_shell_access
* Availability during one of the two windows on a regular basis
* A willingness to learn and being comfortable with asking for
help/advice when you aren't sure, especially when you aren't sure what
a particular patch will actually do in production.
What you'll get:
* Fancy access to deploy to "A Top 10 Web Property"(TM)(C)
* Support from current SWATers to get started
* A t-shirt and/or sticker if you end up breaking, AND FIXING,
production
Let me know if you're interested!
Greg
--
| Greg Grossmeier GPG: B2FA 27B1 F7EB D327 6B8E |
| identi.ca: @greg A18D 1138 8E47 FAC8 1C7D |
Hi folks,
I've been working on the Upload to Commons Android app[1] for the past few
months as an Outreachy project (which was recently completed
successfully[2] :)). A few changes were made to the app to make
categorization of pictures easier, via suggestion of nearby categories and
more flexible category search. However, there are lots of improvements
(documented on our GitHub page[3]) that we couldn't fit into the scope of
the Outreachy project. I would love to be able to continue working on the
app to improve it further - hence an IEG proposal.
My IEG proposal for the app involves:
- Fixing long-standing bugs and looking into old crash reports to try and
prevent them from recurring, to provide a smoother user experience
- Making several enhancements to the app to make it more user-friendly and
newbie-friendly, new location-based features (e.g. a list of nearby
articles lacking pictures), and further enhancing categorization.
- Increasing awareness of non-Wikimedians about this app to grow the
contributor base
Several of the proposed features are based on previous suggestions by
users, and I would very much appreciate more feedback and suggestions! If
you are interested, please do take a look at the current proposal[4], feel
free to ask questions and make new suggestions on the Discussion page, and
review it as you see fit. If you would like to be part of the project,
volunteers and additional advisors are always welcome.
Thank you so much!
[1] https://play.google.com/store/apps/details?id=fr.free.nrw.commons
[2] https://phabricator.wikimedia.org/T126848
[3] https://github.com/nicolas-raoul/apps-android-commons/issues
[4]
https://meta.wikimedia.org/wiki/Grants:IEG/Improve_%27Upload_to_Commons%27_…
--
Regards,
Josephine