Hi,
when I use Mobile Frontend under Android then all headers are collapsed.
If I use a desktop browser and switch to "mobile view" no header is
collapsed. I tried to set '$wgMFCollapseSectionsByDefault = true;' in my
LocalSettings.php, but it does not work.
Exist a possibility to make all header collapsed in the mobile view on a
desktop browser? Or even better: everything collapsed except the first
header?
Thanks Sigbert
--
https://hu.berlin/skhttps://hu.berlin/mmstat3
Admittedly, I never learned how to properly set up and configure
CentralAuth.
I have installed two fresh wikis, called en.localhost and meta.localhost
and you can see the LocalSettings.php file that I am using at
https://phabricator.wikimedia.org/P7808
What I am trying to achieve is this: when you go to en.localhost and log
in, this should log you into both wikis.
When I try logging in via en.localhost, I get this message:No active login
attempt is in progress for your session.
And I am not logged into either wiki. :(
Can you please tell me what I need to change in the configurations to make
this work?
Thanks,
Huji
Say you are the owner of example.com with a wiki at www.example.com/wiki Say
you decide to move the wiki to it's own subdomain: wiki.example.com/wiki.
Would there necessarily be any "hit" on SEO assuming you implement
permanent redirects at the www site?
Or, in your experience, is it best to proxy [0] the subdomain from the www
site so that to users, it still appears that the content and wiki service
is located in the original path.
One example I found for a blog [1] tells a story of adverse SEO experience,
but doesn't exactly pin down the cause. The 'Moz' guide advice on this
[2] is 10 years old -- so "conventional wisdom" but I'm not sure that it
holds today.
[0]
location ^~ /wiki/ {
proxy_pass https://wiki.example.com/wiki/;
proxy_intercept_errors on;
# serve custom 404 page from corp site instead of wiki 404
error_page 404 /errors/404.html;
# allow the wiki to pass caching headers instead of using nginX
expires off;
}
[1]
https://iwantmyname.com/blog/seo-penalties-of-moving-our-blog-to-a-subdomain
[2] https://moz.com/blog/seo-guide-how-to-properly-move-domains
Thanks,
Greg Rundlett
https://eQuality-Tech.comhttps://freephile.org
Hi,
We now have a tentative date and location for EMWCon Spring 2019, or the
Enterprise MediaWiki Conference: per the subject line, the plan is to have
it on Wednesday to Friday, April 3-5, 2019, in San Francisco, California -
or, more precisely, in neighboring Daly City, CA, at the Genesys
headquarters. There's no registration for it yet, or even a page at all; I
just wanted to let people know already, and also to make sure that there
are no major conflicts with the date. If anyone would like to attend but
can't make it for those specific dates, please let me know. (The location
of Daly City is more locked in.)
-Yaron
Hi,
There's a new episode out of the MediaWiki podcast Between the Brackets,
this one featuring a talk with Håkon Wium Lie. Some of you may recognize
the name, because he is, among other things, the inventor of CSS. I talked
to him because he is currently one of the administrators, and the public
face, of the MediaWiki-based wiki Rettspraksis.no, which publishes the
rulings of the Norwegian Supreme Court. They got sued a few months ago for
putting this information online for free, by the people who were charging
money for it, and the lawsuit became a cause for open-data advocates in
Norway and elsewhere. I talked with Håkon about all these things and more -
it was an interesting interview. You can listen to the episode here:
http://betweenthebrackets.libsyn.com/episode-21-hkon-wium-lie
-Yaron
Hello everyone,
Sorry for my silly Question. But I want to know that
MediaWiki's javascript has Hooks functionality like PHP has $wgHooks[
'PageContentSaveComplete'].
I want to run my code when the user submits their edit.
Thanks in Advance :)
Has there been any work done to integrate GitLab with MediaWiki,
specifically the issues and boards features? We've been looking at
different ways to file issues, tag them with categories and assignees, and
track them through workflows. GitLab (and GitHub) has all these features
and to me it makes more sense to integrate a product that already does it
well.
Daren
--
__________________
https://www.mediawiki.org/wiki/User:Darenwelshhttp://mixcloud.com/darenwelsh
Perhaps of interest to others. The use cases for partial blocks with which
I'm most familiar are on ENWP, which is why I'm including the ENWP and
Wikipedia mailing lists in this forward.
Pine
( https://meta.wikimedia.org/wiki/User:Pine )
---------- Forwarded message ---------
From: Alex Ezell <aezell(a)wikimedia.org>
Date: Fri, Nov 2, 2018 at 7:58 PM
Subject: [Wikitech-l] Changes to User Blocking
To: <wikitech-l(a)lists.wikimedia.org>
Hi all,
I'm Alex Ezell and I'm the Engineering Manager for the Anti-Harassment
Tools team at the WMF. I have some details about user blocking that I'd
like to share.
*tl:dr;*
On a wiki with the new Partial Blocks enabled (currently only testwiki), if
the code is checking User::isBlocked() to determine edit rights, it should
instead check User::isBlockedFrom( Title ). The code could also check
isBlocked()
&& $block->isSitewide(). If it doesn’t, the code may block users that
shouldn’t be blocked.
*More details:*
Recently, the Anti-Harassment Tools team merged code to enable a new
feature called Partial Blocks. This feature lets admins block users from
editing particular pages instead of only being able to block users from the
entire site. It is currently enabled on testwiki.
This means that there are now multiple types of blocks (and more to come in
the future, ie namespace blocks). The specific new types are “partial” as
opposed to “sitewide” and some non-editing types of blocks (send email,
edit talk page, etc.) Previously, a developer could assume that if a user
was “blocked” that meant the user couldn’t do much of anything because that
was a “sitewide” block and the only kind of block. Now, there are more
cases to be concerned about.
Specifically, we’ve seen some extensions using User::isBlocked() and then
assuming that a user can’t edit the particular page that the extension
might be concerned with. User::isBlockedFrom( Title ) with a Title object
will be the more correct way to check because of the possibility that a
user might not be blocked from that particular page. If the code isn’t
concerned with editing, it would be appropriate to use User::isAllowed()
which will determine blocked status by way of User::getRights().
There is also a new method Block::isSitewide() which can help a developer
determine if the block is “sitewide” or some other type. This is useful if
the code doesn’t care about anything but the “sitewide” block type.
We believe that keeping User::isBlocked() in its current state is the safer
way to proceed because in cases where it’s being used incorrectly it would
result in over-enforcing blocks rather than under-enforcing them. A user
who is partially blocked might be treated like a sitewide block by an
extension. That seems safer to us than potentially allowing a user more
freedom than an admin intended with a partial block.
We found at least one extension using User::getRights() in a way that would
over-enforce on a partially blocked user. We created a patch to change how
User::getRights() works
<https://gerrit.wikimedia.org/r/c/mediawiki/core/+/471210>. In addition to
checking that a block exists, it will also ensure that the block is a
sitewide block. This will spare the partially blocked user from being
blocked in these cases.
In summary, all MediaWiki code (especially extension code) that is
concerned with checking user blocks should be aware of the distinction
between User::isBlocked() and User::isBlockedFrom( Title ) and use the
appropriate method for the kind of blocking the code is concerned with.
Additionally, using the helper method Block::isSitewide() is handy for
certain usages.
Alex Ezell
Engineering Manager, Anti-Harassment Tools Team (WMF)
_______________________________________________
Wikitech-l mailing list
Wikitech-l(a)lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Dear Group,
When I look at this web page: https://www.mediawiki.org/wiki/Manual:$wgEnableWriteAPI, it seems to indicate to
me that MediaWiki will no longer have an internal API available after version 1.31.0.
Am I understanding that correctly ? At that point, what would you do if you had some pages that you wanted to edit
automatically via an API ??
thanks,
Lori