Hello,
can one suggest a (mediawiki?) tool for analyzing turn around times of a
wiki request?
Internet connection in general is sufficient, our database is idling,
separate web server for mediawiki scripts too - response time is
unacceptable anyway. No suspicious 3rd party extensions...
So we have to slice in parts response time to find reason...
Mit freundlichen Grüßen / Regards
Uwe (Baumbach)
Verein für Computergenealogie e.V.
--
Sie interessieren sich für Familienforschung?
Dann schauen Sie doch mal hier vorbei:
http://genealogienetz.dehttp://GenWiki.genealogy.net
Folks I really need to be able to display the history and such in the
local timezone.
I've been all through this page:
http://www.mediawiki.org/wiki/Manual:Timezone
and tried all the methods; nothing works. My times are stubbornly set in
UTC.
My users are screaming; they want the revision times in their local timezone.
How do I get mediawiki to display the date and time in the local timezone?
Begin doorgestuurd bericht:
> Van: Jean-Marc Libs <jyhem(a)tiki.org>
> Datum: 3 februari 2014 23:58:31 CET
> Aan: wikis-devroom <wikis-devroom(a)lists.fosdem.org>, devroom-managers(a)lists.fosdem.org
> Onderwerp: [wikis-devroom] Thanks everybody - note that speakers can still go on pentabarf and add the slides of your presentation
>
> Hi everybody,
>
> I would like to thank everybody involved, the Fosdem organisers, my co-devroom administrators for a successful devroom, all the speakers for their interesting talks and for letting our devroom keep on schedule through the whole day. And also the video volunteers and the various unnamed persons who stepped up and gave a hand at various moments.
>
>
> Having 3 co-admins was very helpful as we were not unavailable due to our other activities at the same time during the Fosdem preparations, so everything could be answered.
> The 5 minutes gap between presentations and the "2 minutes left" reminders worked fine for keeping things on track.
> The AW1.120 room was about adequate: There was always attendance. We had to help people find room about 3 times, and refuse a couple of people only once in the day. Which was quite good compared to the situation in some other rooms.
>
> I feel this wikis devroom was a success thanks to all. Also, I am glad we managed to have nice speaker bios and presentation drafts which made the booklet much nicer and more useful than last year's.
> The only problem of note was that the video did not start from the beginning of the day. I am still unsure if it was due to lack of volunteers or poor communication (maybe we, the devroom admins were supposed to fetch the video volunteers at the beginning?). I hope this is not too much of a disappointment to those not filmed (which includes myself).
>
> I would like to remind everybody that you can still go on pentabarf and add the slides of your presentation as an attachment to the "description" tab of the presentation's event. That would certainly be appreciated by the people who atteded and those who could not.
>
> Thanks again, and see you next year I hope,
> Jean-Marc Libs
>
> --
> co-admin of wikis devroom
> _______________________________________________
> wikis-devroom mailing list
> wikis-devroom(a)lists.fosdem.org
> https://lists.fosdem.org/listinfo/wikis-devroom
Nemo writes:
> We still have 18 open reports marked as needing backports to old stable
> branches, marked 3 as major and 1 (for 1.21.x) as critical. What to do?
What you did earlier today was appropriate -- merge available patches to the relevant branches. Also appropriate: bug Markus or I about these backports. As I posted earlier today, we'll be making point releases for supported versions on the 27th of this month, so there is plenty of time to nag us before the next scheduled point release.
As Siebrand noted it would be good to update the REL NOTES when you do that, but if you don't then we will update them when a release is made.
(Note that I'm not committing to making releasing fixes for the issues that you mentioned since I haven't looked at them yet. They are in queue, though.)
HTH,
Mark.
My remote server supplier just decided & did migrate my Mediawiki site
at
http://www.physicswiki.net
to a much faster more stable piece of hardware. I was fine with this,
however after I got all (I think) of the glitches fixed from the move
and now have the system up again: I have a crap load of formatting
issues with the site. I looks like the system is displaying everything
as plain html code rather that wiki code. The menus are all gone from
the sidebar etc. I have never been through a migration like this & I
have only shell access to the base Debian 6 linux that the site is
running on. I need opinions, tips, virtually any help to clean this up.
This site is under HEAVY construction & development & I want to keep it
going properly.
Thanks
John
Subject: Monthly point releases
Based on the issues raised during a meeting we had at the Architecture Summit a couple of weeks ago, those of us involved in MediaWiki release management have decided to introduce a monthly point-release cycle. On the last Thursday of every month we'll collect fixes that have been made and release them for download.
We plan to continue to use the "Known Issues" subpage[1] to drive the issues that are incorporated into the release. This means that if you have an issue that you think should be addressed before the next major release, you can add it to the "Known Issues" page. We'll review it and, if we agree that it is an appropriate issue for a point release, then we'll try to get it resolved.
Of course, this is a community-driven effort, so issues that have working code attached are more likely to be resolved in a point release than requests without code. If you cannot provide patches, that doesn't mean that your issue won't be fixed. Instead, you can help us find someone to fix it and further help by testing any fixes provided.
We hope that this will mean a more usable MediaWiki.
Thanks,
Mark.
[1] https://www.mediawiki.org/wiki/MediaWiki_1.22/Known_issues
Hi lists,
If you haven't patched with the last security release, or know of a wiki
that hasn't patched yet, please do so immediately. An exploit was released
on the full disclosure mailing list over the weekend[1] that targets the
vulnerability in the PdfHandler extension.
If you're not able to patch for some reason, you may be able to work around
the issue:
* If you have never allowed .djvu files to be uploaded, but you do allow
pdf files, you can simply disable the PdfHandler extension (typically by
remove the include in your LocalSettings.php).
* If you have any .djvu files saved on your wiki, then there is no
workaround-- you need to apply the security patch to MediaWiki core.
If anyone is running an unsupported branch of MediaWiki (1.20 was recently
EOL'ed), and needs help creating a patch for their instance, I'm happy to
try and work with you to get the vulnerability closed. Contact me off list,
or on irc.
[1] - http://seclists.org/fulldisclosure/2014/Feb/6