tl;dr: Is it possible to enforce an order on callback functions that are attached to the same hook?
Detailed question:
I've written a custom extension that modifies Category pages. It creates a subclass of CategoryPage and inserts it using the hook "ArticleFromTitle." It works great on its own, but unfortunately, another popular extension we use, CategoryTree, does exactly the same thing, and it overrides my extension's modifications.
I can write my extension to check for the presence of CategoryTree and compensate for it. Unfortunately, MediaWiki 1.28.0 always runs CategoryTree's callback after mine, so no matter what I do, CategoryTree wins. (Strangely, in 1.27, my extension always won.)
Is there a way to ensure that my extensions ArticleFromTitle callback runs *after* CategoryTree's callback?
Thank you very much.
DanB
Hi!
We tried to use the lastest maps plugin (former Semantic Maps) to display some
KML tracks. But unfortunately it doesn't seem to work.
Can anyone confirm if KML does work again? According to the changelog it should
work, but it seems we have two different kind of KML but none of them works.
Or is it possible to display any other track format like GPX, etc?
Regards
Martin
Hi,
I already migrated other times from an old server to a new server, but
always from MySQL to MySQL, after format and configure a new machine/OS.
Today, I installed CentOS7 that comes with MariaDB5.5.
I typed my wiki URL (that other times I migrated appeared the page to
initiate installation), but it showed me this error:
A database error has occurred. Did you forget to run
maintenance/update.php after upgrading? See:
https://www.mediawiki.org/wiki/Manual:Upgrading#Run_the_update_script
Query: SELECT lc_value FROM `l10n_cache` WHERE lc_lang = 'pt-br' AND
lc_key = 'deps' LIMIT 1
Function: LCStore_DB::get
Error: 1146 Table 'wiki.l10n_cache' doesn't exist (localhost)
I have all the database files in /var/lib/mysql/wiki subdir, with right
user permissions:
[root@websaf edilmar]# cd /var/lib/mysql/wiki
[root@websaf wiki]# l
total 2816
drwx------ 2 mysql mysql 4096 Mar 3 2014 .
drwxr-xr-x 10 mysql mysql 4096 Dez 19 20:06 ..
-rw-rw---- 1 mysql mysql 9188 Mar 3 2014 archive.frm
-rw-rw---- 1 mysql mysql 8770 Mar 3 2014 category.frm
-rw-rw---- 1 mysql mysql 8843 Mar 3 2014 categorylinks.frm
-rw-rw---- 1 mysql mysql 8722 Mar 3 2014 change_tag.frm
-rw-rw---- 1 mysql mysql 65 Fev 28 2014 db.opt
-rw-rw---- 1 mysql mysql 8636 Mar 3 2014 externallinks.frm
-rw-rw---- 1 mysql mysql 8624 Mar 3 2014 external_user.frm
-rw-rw---- 1 mysql mysql 9678 Mar 3 2014 filearchive.frm
-rw-rw---- 1 mysql mysql 8562 Mar 3 2014 hitcounter.frm
-rw-rw---- 1 mysql mysql 9294 Mar 3 2014 image.frm
-rw-rw---- 1 mysql mysql 8598 Mar 3 2014 imagelinks.frm
-rw-rw---- 1 mysql mysql 8754 Mar 3 2014 interwiki.frm
-rw-rw---- 1 mysql mysql 9316 Mar 3 2014 ipblocks.frm
-rw-rw---- 1 mysql mysql 8650 Mar 3 2014 iwlinks.frm
-rw-rw---- 1 mysql mysql 8778 Mar 3 2014 job.frm
-rw-rw---- 1 mysql mysql 8638 Mar 3 2014 l10n_cache.frm
-rw-rw---- 1 mysql mysql 8640 Mar 3 2014 langlinks.frm
-rw-rw---- 1 mysql mysql 9034 Mar 3 2014 logging.frm
-rw-rw---- 1 mysql mysql 8646 Mar 3 2014 log_search.frm
-rw-rw---- 1 mysql mysql 8642 Mar 3 2014 module_deps.frm
-rw-rw---- 1 mysql mysql 8692 Mar 3 2014 msg_resource.frm
-rw-rw---- 1 mysql mysql 8620 Mar 3 2014 msg_resource_links.frm
-rw-rw---- 1 mysql mysql 8634 Mar 3 2014 objectcache.frm
-rw-rw---- 1 mysql mysql 9360 Mar 3 2014 oldimage.frm
-rw-rw---- 1 mysql mysql 9030 Mar 3 2014 page.frm
-rw-rw---- 1 mysql mysql 8650 Mar 3 2014 pagelinks.frm
-rw-rw---- 1 mysql mysql 8648 Mar 3 2014 page_props.frm
-rw-rw---- 1 mysql mysql 8790 Mar 3 2014 page_restrictions.frm
-rw-rw---- 1 mysql mysql 8826 Mar 3 2014 protected_titles.frm
-rw-rw---- 1 mysql mysql 8688 Mar 3 2014 querycache.frm
-rw-rw---- 1 mysql mysql 8616 Mar 3 2014 querycache_info.frm
-rw-rw---- 1 mysql mysql 8796 Mar 3 2014 querycachetwo.frm
-rw-rw---- 1 mysql mysql 13762 Mar 3 2014 recentchanges.frm
-rw-rw---- 1 mysql mysql 8740 Mar 3 2014 redirect.frm
-rw-rw---- 1 mysql mysql 9040 Mar 3 2014 revision.frm
-rw-rw---- 1 mysql mysql 8640 Mar 3 2014 searchindex.frm
-rw-rw---- 1 mysql mysql 1336796 Nov 17 19:53 searchindex.MYD
-rw-rw---- 1 mysql mysql 924672 Nov 17 19:56 searchindex.MYI
-rw-rw---- 1 mysql mysql 8944 Mar 3 2014 site_stats.frm
-rw-rw---- 1 mysql mysql 8684 Mar 3 2014 tag_summary.frm
-rw-rw---- 1 mysql mysql 8650 Mar 3 2014 templatelinks.frm
-rw-rw---- 1 mysql mysql 8642 Mar 3 2014 text.frm
-rw-rw---- 1 mysql mysql 8644 Mar 3 2014 transcache.frm
-rw-rw---- 1 mysql mysql 8602 Mar 3 2014 updatelog.frm
-rw-rw---- 1 mysql mysql 9281 Mar 3 2014 uploadstash.frm
-rw-rw---- 1 mysql mysql 8608 Mar 3 2014 user_former_groups.frm
-rw-rw---- 1 mysql mysql 9244 Mar 3 2014 user.frm
-rw-rw---- 1 mysql mysql 8604 Mar 3 2014 user_groups.frm
-rw-rw---- 1 mysql mysql 8662 Mar 3 2014 user_newtalk.frm
-rw-rw---- 1 mysql mysql 8648 Mar 3 2014 user_properties.frm
-rw-rw---- 1 mysql mysql 8564 Mar 3 2014 valid_tag.frm
-rw-rw---- 1 mysql mysql 8720 Mar 3 2014 watchlist.frm
If I try to connect directly in my wiki database:
Welcome to the MariaDB monitor. Commands end with ; or \g.
Your MariaDB connection id is 187
Server version: 5.5.52-MariaDB MariaDB Server
Copyright (c) 2000, 2016, Oracle, MariaDB Corporation Ab and others.
Type 'help;' or '\h' for help. Type '\c' to clear the current input
statement.
MariaDB [(none)]> use wiki
Reading table information for completion of table and column names
You can turn off this feature to get a quicker startup with -A
Database changed
MariaDB [wiki]> show tables;
+--------------------+
| Tables_in_wiki |
+--------------------+
| archive |
| category |
| categorylinks |
| change_tag |
| external_user |
| externallinks |
| filearchive |
| hitcounter |
| image |
| imagelinks |
| interwiki |
| ipblocks |
| iwlinks |
| job |
| l10n_cache |
| langlinks |
| log_search |
| logging |
| module_deps |
| msg_resource |
| msg_resource_links |
| objectcache |
| oldimage |
| page |
| page_props |
| page_restrictions |
| pagelinks |
| protected_titles |
| querycache |
| querycache_info |
| querycachetwo |
| recentchanges |
| redirect |
| revision |
| searchindex |
| site_stats |
| tag_summary |
| templatelinks |
| text |
| transcache |
| updatelog |
| uploadstash |
| user |
| user_former_groups |
| user_groups |
| user_newtalk |
| user_properties |
| valid_tag |
| watchlist |
+--------------------+
49 rows in set (0.00 sec)
MariaDB [wiki]> select * from user;
ERROR 1146 (42S02): Table 'wiki.user' doesn't exist
I think the real problem is this...
Hello,
I will be out of the office until Monday, January 2nd, without access to voicemail or email. I will respond to all messages upon my return.
Have a happy Holiday season, and a wonderful New Year!
Warmest Regards,
Jennifer Belmont
Software Solutions Project Manager
EMERgency24
847-789-5846
Hi,
In cases like https://gerrit.wikimedia.org/r/#/c/326371 where the tests
fail for arbitrary reasons (i.e. there is no issue with the patch set), any
user with code review permissions (+1 or +2) can run "recheck" to let the
tests run again and pass.
If I understand the (very scarce) documentations on Openstack Jenkins,
there are then two options to re-initiate the merging process by Zuul. One
option is for a person with +2 permission to reapply their +2 code review.
The other option is to run "reverify". I tried it on the patch set linked
above but nothing happened. I am not sure if it is because I did it wrong,
because only those with +2 rights can run it, or because we don't support
it at all. So I thought I should ask.
Please advise.
Huji
Thank you, Brian. That was indeed the missing piece. We set $wgArticlePath,
so that explains the format of the URL.
Cindy
Date: Mon, 19 Dec 2016 19:48:05 +0000
> From: Brian Wolff <bawolff(a)gmail.com>
>
> Its not CGI support so much as if MW detects it can properly use
> $_SERVER['PATH_INFO']. Generally speaking, this is true provided your
> PHP sapi is not cgi, apache2filter, or isapi. Of course, if you have
> set $wgArticlePath yourself, then this auto-detection stuff is
> overridden.
>
> --
> Brian
>
> On Mon, Dec 19, 2016 at 7:04 PM, Cindy Cicalese <cindom(a)gmail.com> wrote:
> > Scott,
> >
> > I double checked the Short URL manual page [0], because you mentioned
> that
> > you planned to switch to short URLs due to this issue. We do not use
> short
> > URLs, so there must be something else going on. What struck me on the
> > manual page, was the following:
> >
> > MediaWiki's default page addresses looks like these examples:
> > http://example.org/w/index.php/Page_title *(recent versions of
> MediaWiki,
> > without CGI
> > <https://en.wikipedia.org/wiki/Common_Gateway_Interface> support)*
> > http://example.org/w/index.php?title=Page_title *(recent versions of
> > MediaWiki, with CGI support)*
> >
> >
> > Our URLs are consistent with the first case and yours are consistent with
> > the second. However, we do have CGI enabled. Maybe somebody on the list
> can
> > elaborate on why the format of the URLs might be different?
>
>
Hi all,
Ever since my recent upgrades to MediaWiki 1.27, which included upgrading the operating system and changing from Apache + mod_php to Apache + PHP-FPM, a few times I've seen PHP-FPM processes hanging on a certain kind of old page revision (often these revisions are years old). Specifically, it appears to be old page revisions where there was a huge change to the page size, e.g. a 64k page having 61k added to it. Here's an example excerpt from the FPM status page with the pool info and one of the hung processes:
pool: www
process manager: dynamic
start time: 08/Dec/2016:07:59:44 -0800
start since: 1041140
accepted conn: 10654252
listen queue: 0
max listen queue: 0
listen queue len: 0
idle processes: 7
active processes: 12
total processes: 19
max active processes: 40
max children reached: 8
slow requests: 0
pid: 7087
state: Running
start time: 20/Dec/2016:08:36:30 -0800
start since: 2134
requests: 38
request duration: 2088600826
request method: GET
request URI: /index.php?title=Chef&oldid=363770
content length: 0
user: -
script: /var/www/sites/gw2w-en/index.php
last request cpu: 0.00
last request memory: 0
Currently php.ini has max_execution_time set to 60s. I realize I could also try setting the pool's request_terminate_timeout value to ensure processes don't stay hung like this, but that's basically kill -9 and I'd rather try to resolve the underlying issue and improve the performance so these old revisions can actually load in a reasonable amount of time.
This is on up-to-date Ubuntu 16.04.3 servers, with MediaWiki 1.27.1, Apache 2.4.18, and PHP 7.0.8. Also for what it's worth, the referrers for these page requests have pretty much always been http://www.bing.com/bingbot.htm, but since this is easily reproducible, I'd rather fix the problem so actual users aren't forced to wait several minutes for old revision page loads.
Any suggestions?
Thanks,
Justin
Heiya Mark,
it's cool that you like this mailing list. :) Indeed this is not the
appropriate one. So I will forward my answer to the general MediaWiki
list so the people over there may have a look at your question, too.
However, I thought the point of the MsUpload extension [0] was to drag
and drop uploads within the text area of a wiki page during editing. So
having it somehow in the sidebar does not really sound like it is within
the scope of it. Still this is a wild assessment. I never installed or
used this one.
Cheers Karsten
[0] https://www.mediawiki.org/wiki/Extension:MsUpload
Am 20.12.2016 um 20:57 schrieb Mark Gallagher:
> Hi,
>
> I appreciate this is not really the appropriate forum but I am just looking
> for some direction as I got nowhere on the MSUpload extension discussion
> talk page.
>
> Has anyone got any ideas which support forum could answer how do I get
> MSUPLOAD onto a side-bar? Or even how to do it?
>
> Regards,
> Mark
>
この予定はキャンセルされ、カレンダーから削除されました。
タイトル: MediaWiki-l Digest, Vol 158, Issue 11
Send MediaWiki-l mailing list submissions to
mediawiki-l(a)lists.wikimedia.orgTo subscribe or unsubscribe via the World
Wide Web, visit https://lists.wikimedia.org/mailman/listinfo/mediawiki-lor,
via email, send a message with subject or body 'help' to
mediawiki-l-request(a)lists.wikimedia.orgYou can reach the person managing
the list at mediawiki-l-owner(a)lists.wikimedia.orgWhen replying, please edit
your Subject line so it is more specificthan "Re: Contents of MediaWiki-l
digest..."Today's Topics: 1. Re: MediaWiki Timezone
(John)_______________________________________________MediaWiki-l mailing
listMediaWiki-l@lists.wikimedia.orghttps://lists.wikimedia.org/mailman/listinfo/mediawiki-l
日時: 毎日 午後1時～午後2時 GMT (夏時間なし)
カレンダー: mediawiki-l(a)lists.wikimedia.org
参加者:
* 優希船越- 主催者
* mediawiki-l(a)lists.wikimedia.org
* Wikipedia
Google カレンダーからの招待状: https://www.google.com/calendar/
予定の参加者になっているため、本メールを mediawiki-l(a)lists.wikimedia.org に
お送りしています。
今後この予定の更新を受け取らないようにするには、この予定を拒否してください。
あるいは、https://www.google.com/calendar/ で Google カレンダーのアカウント
を登録すると、カレンダー全体の通知機能を設定できます。
この招待状を転送すると、他の受信者によってあなたの出欠状況が変更される可能性
があります。詳細については
https://support.google.com/calendar/answer/37135#forwarding をご覧ください