Lis ton message de Nganguem Victor avant qu'il ne soit effacé!
Pour lire ton message, suis simplement ce lien:
http://eu1.badoo.com/chatnoirxx/in/p4hxwt052ok/?lang_id=6
D'autres personnes sont aussi présentes:
Oded (Tel Aviv, Israël)
Priya (Udaipur, Inde)
RajaYogi BK (Udaipur, Inde)
Karuna (Udaipur, Inde)
Chika Reginald Onyia (Pnompen', Cambodge)
...Qui d'autre?
http://eu1.badoo.com/chatnoirxx/in/p4hxwt052ok/?lang_id=6
Les liens ne fonctionnent pas dans ce message? Copie les dans la barre d'adresse de ton navigateur.
Tu as reçu cet email suite à un message envoyé par Nganguem Victor de notre système. S'il s'agit d'une erreur, ignore simplement cet email. La requête sera alors effacée du système.
Amuse-toi bien !
L'équipe Badoo
Courrier automatique de Badoo suite à l'envoi d'un message à ton attention sur Badoo. Les réponses ne sont ni stockées, ni traitées. Si tu ne veux plus recevoir de message de Badoo, fais-le nous savoir:
http://eu1.badoo.com/impersonation.phtml?lang_id=6&mail_code=65&email=media…
My current setup, under which MW is running swimmingly:
Fedora 27
Apache 2.4.33
MariaDB 10.2.14
MediaWiki 1.30.0
I am attempting to upgrade to MW 1.31.0. I unzipped the tarball into a
fresh directory, copied over my LocalSettings.php file, and changed the
symlink that I use with Apache to point to the new location. I then
attempted to run maintenance/update.php and it cryptically ended with a
whimper:
====================
MediaWiki 1.31.0 Updater
Your composer.lock file is up to date with current dependencies!
Going to run database updates for wikidb
Depending on the size of your database this may take a while!
Abort with control-c in the next five seconds (skip this countdown with
--quick) ... 0
Turning off Content Handler DB fields for this part of upgrade.
Adding ipb_id field to table ipblocks ...Set $wgShowExceptionDetails =
true; and $wgShowDBErrorBacktrace = true; at the bottom of
LocalSettings.php to show detailed debugging information.
====================
I added the suggested flags to LocalSettings and got the following in my
browser:
====================
[WyJ-joCjti3zg1lzHPXHqQAAAAM] /wiki/Main_Page Wikimedia\Rdbms\DBQueryError
from line 1457 of
/var/www/gpf/mediawiki-1.31.0/includes/libs/rdbms/database/Database.php: A
database query error has occurred. Did you forget to run your application's
database schema updater after upgrading?
Query: SELECT
user_id,user_name,user_real_name,user_email,user_touched,user_token,user_email_authenticated,user_email_token,user_email_token_expires,user_registration,user_editcount
FROM `mediawiki`.`user` WHERE user_id = '1' LIMIT 1
Function: User::loadFromDatabase
Error: 1142 SELECT command denied to user 'wikiuser'@'localhost' for table
'user' (localhost)
Backtrace:
#0
/var/www/gpf/mediawiki-1.31.0/includes/libs/rdbms/database/Database.php(1427):
Wikimedia\Rdbms\Database->makeQueryException(string, integer, string,
string)
#1
/var/www/gpf/mediawiki-1.31.0/includes/libs/rdbms/database/Database.php(1200):
Wikimedia\Rdbms\Database->reportQueryError(string, integer, string, string,
boolean)
#2
/var/www/gpf/mediawiki-1.31.0/includes/libs/rdbms/database/Database.php(1653):
Wikimedia\Rdbms\Database->query(string, string)
#3
/var/www/gpf/mediawiki-1.31.0/includes/libs/rdbms/database/Database.php(1730):
Wikimedia\Rdbms\Database->select(array, array, array, string, array, array)
#4 /var/www/gpf/mediawiki-1.31.0/includes/user/User.php(1407):
Wikimedia\Rdbms\Database->selectRow(array, array, array, string, array,
array)
#5 /var/www/gpf/mediawiki-1.31.0/includes/user/User.php(537):
User->loadFromDatabase(integer)
#6
/var/www/gpf/mediawiki-1.31.0/includes/libs/objectcache/WANObjectCache.php(1240):
User->{closure}(boolean, integer, array, NULL)
#7
/var/www/gpf/mediawiki-1.31.0/includes/libs/objectcache/WANObjectCache.php(1110):
WANObjectCache->doGetWithSetCallback(string, integer, Closure, array)
#8 /var/www/gpf/mediawiki-1.31.0/includes/user/User.php(561):
WANObjectCache->getWithSetCallback(string, integer, Closure, array)
#9 /var/www/gpf/mediawiki-1.31.0/includes/user/User.php(482):
User->loadFromCache()
#10 /var/www/gpf/mediawiki-1.31.0/includes/user/User.php(420):
User->loadFromId(integer)
#11 /var/www/gpf/mediawiki-1.31.0/includes/session/UserInfo.php(88):
User->load()
#12
/var/www/gpf/mediawiki-1.31.0/includes/session/CookieSessionProvider.php(119):
MediaWiki\Session\UserInfo::newFromId(string)
#13 /var/www/gpf/mediawiki-1.31.0/includes/session/SessionManager.php(488):
MediaWiki\Session\CookieSessionProvider->provideSessionInfo(WebRequest)
#14 /var/www/gpf/mediawiki-1.31.0/includes/session/SessionManager.php(191):
MediaWiki\Session\SessionManager->getSessionInfoForRequest(WebRequest)
#15 /var/www/gpf/mediawiki-1.31.0/includes/WebRequest.php(736):
MediaWiki\Session\SessionManager->getSessionForRequest(WebRequest)
#16 /var/www/gpf/mediawiki-1.31.0/includes/session/SessionManager.php(130):
WebRequest->getSession()
#17 /var/www/gpf/mediawiki-1.31.0/includes/Setup.php(847):
MediaWiki\Session\SessionManager::getGlobalSession()
#18 /var/www/gpf/mediawiki-1.31.0/includes/WebStart.php(88):
require_once(string)
#19 /var/www/gpf/mediawiki-1.31.0/index.php(39): require(string)
#20 {main}
====================
Needless to say, I'm pretty confused here. Nothing has changed to my
configuration (and probably to the wiki's contents) since I successfully
upgraded to 1.30.0. If I switch my symlink back to point to my MW 1.30.0
install, the site loads just fine. So it appears the updater is bombing
when it tries to add the field "ipb_id" to table "ipblocks".
What confuses me is the "SELECT command denied to user 'wikiuser'@'localhost'"
error. My wiki has two MariaDB users: "wikuser" (the standard user set in
$wgDBuser) and an admin user set with $wgDBadminuser. Neither user account
has changed, either in the DB or in LocalSettings.
It *almost* looks like the updater is trying to use the standard user to do
admin functions, but even that doesn't make much sense. "wikiuser" has
SELECT access to all tables in the DB, while the admin user has all
permissions to the entire DB. So I don't see why that specific error would
crop up; even "wikiuser" should be able to perform a simple SELECT.
Fortunately, I can switch back to MW 1.30.0 pretty easily, but I thought I
ought to report the problem.
ADDENDUM: I just noticed the following in the 1.31 release notes:
====================
Important pre-upgrade notes for 1.31
- If you're using MySQL, SQLite, or MSSQL, are not using update.php to
apply schema changes, and cannot have downtime to run
migrateArchiveText.php and apply patch-drop-ar_text.sql manually, you'll
have to apply a default value to the ar_text and ar_flags columns of the
archive table or make those columns nullable before upgrading to MediaWiki
1.31. maintenance/archives/patch-nullable-ar_text.sql shows how to do this
for MySQL.
====================
Based on this, I think there's something screwy with update.php. I *am*
using update.php to apply schema changes, but I'm guessing it's not working
correctly. I have *not* tried this manual fix (and would prefer not to
unless absolutely necessary).
Jeffrey T. Darlington
General Protection Fault
https://www.gpf-comics.com/
Hello,
I have mass imported over 50 pages. This have categories which exist
and were defined before. But this new imported pages are not shown in
the lists of the categories.
I run runJobs.php (and set $wgJobRunRate = 1) and run the
rebuildall.php script and other scripts (like refreshLinks.php) but
nothing changed.
Any ideas what i can do?
Otherwise i have to click in all 50 pages on the edit button and save
it. Another changes and more pages for the import are yet to come
Many Greetings,
Adalbert Wrona
Hello,
Is there any documentation or a link i could visit to
understand the concept of how the formatter URL works in wikibase for
external identifiers and what extensions or configuration needs to be
done to enable it. On wikidata we see that any external identifier with
a value on click redirects to the corresponding external domain page and
this functionality is missing from our local installation of mediawiki
with wikibase. Any assistance would be of help.
Thanks & Regards,
Srinivas
Hello,
I'm using Auth_RemoteUser as an immutable session provider in the following environment:
* MediaWiki 1.30.0 (830bb58)
* Auth_remoteuser 2.0.1 (0af2823) 16:22, 24 April 2018
* Page Forms 4.3 (c35e352) 13:50, 14 March 2018
* Immutable Session Provider - CA Policy Agent for Apache
I have recently patched Auth_remoteuser to solve the "First-Save" bug that was fixed recently [2] , but a remaining problem that was not resolved by that patch is as follows:
When a user's session times-out before they SAVE during form page edit (ala 'action=formedit'), the page form loses the user's edits in the process of having a new session created. This does not happen (loss of edits) with a normal edit (action=edit), only with form edits. [0]
There has been talk about this problem in the past [1] and I'm wondering if the fix has been verified for users using AuthRemoteUser with an immutable session provider configuration.
Can anyone help me identify if this is indeed a problem with Auth_RemoteUser or (unlikely) with Page Forms.
[0] https://www.mediawiki.org/wiki/Extension_talk:Auth_remoteuser#page_forms_lo…
[1] https://www.mediawiki.org/wiki/Extension_talk:Page_Forms/Archive_January_20…
[2] https://www.mediawiki.org/wiki/Extension_talk:Auth_remoteuser#%22First_Save…
-Rich
Hello everyone,
it is my pleasure to announce the launch of the beta version of BlueSpice 3 [1].
For those who don't know the project yet: BlueSpice is a MediaWiki distribution for companies and organizations. There is a widely used free version, often used by NGOs and non-profit associations.
We would like to invite everyone who is interested to test the beta. For the MediaWiki community, the most exciting point is probably to check our approaches to issues like quality assurance or on-site communication, which might be different for organisational wikis. Our experience with that type of wikis nurtured the development of version 3.
What's new? A lot. Most notably:
* we now use VisualEditor and ElasticSearch. Search can be filtered and supports semantic properties.
* there's a responsive skin and a redesigned interaction concept involving two navigation columns. You might like the neat preview images for recent changes.
* in the discussions try to break new ground. We want to facilitate discussions about articles and make them more traceable. To this end, we have introduced a timeline function and are gaining practical experience.
* we introduced a right navigation bar for quality assurance and for power users, with the goal of making the software more comfortable not only for readers, but also for authors.
More changes for BlueSpice 3 can be found out at the Notable Changes list. [2]
Being a beta version, BlueSpice 3 is certainly not (yet) perfect. That's why we are interested in feedback from wiki authors, maintainers and developers. We collect insights directly in our beta test environment on a feedback page.
If you want to become a beta tester: Please apply for edit access to the test environment. We'll send you an account. [3]
For all participants of our beta test we offer two info webinars [4], where we present BlueSpice 3, but also will be answering questions and share experiences.
* Tuesday, 31 July 2018 at 8 am UTC (in German)
* Thursday, August 2, 2018 at 1 pm UTC (in English)
Happy to hear from you all, and
best regards,
Markus (mglaser)
[1] https://beta.bluespice.com/
[2] https://beta.bluespice.com/bluespice/index.php/Notable_Changes
[3] https://bluespice.com/request-for-a-beta-test-account/
[4] https://bluespice.com/webinar/
Hello,
I am currently hosting a wiki through the provider Miraheze. One of the configuration changes that I made to my wiki is that I grandfathered oversight and checkuser rights into the “steward” group, which is what Miraheze uses for its “staff” group, and then I unset the oversight and checkuser groups to remove them in the config.
The oversight group was removed, however the checkuser group still exists, despite
unset( $wgGroupPermissions[‘checkuser’] );
being in the configuration. Does anyone know how to fix this? Even the sysadmins at Miraheze appear to be a little confused/unsure.
Thanks,Amanda
Hi everyone,
Episode #13 of the MediaWiki podcast "Between the Brackets" has been
released; this one is an interview with Remco de Boer of the Dutch
consulting company ArchiXL, which makes significant use of MediaWiki in its
projects. You can find and listen to the episode here:
http://betweenthebrackets.libsyn.com/episode-13-remco-de-boer
-Yaron
Hi There,
I'm searching for some efficient way to convert the WikiText of the
downloaded data dumps(in XML) to plain text. I basically need plain text of
each and every revision of Wikipedia articles.
Therefore, it would be very helpful if you can tell me about some library
or some piece of code(bunch of regex) to convert WikiText to Plain Text.
BTW, I write my code in Python!
Thanks.
I'm setting up 2 localhost-only wikis for development purposes and
trying out new ideas. One called 'wiki-drugfacts' and the other called
'wiki-tgmeds'. They both share the same mariadb database although
'wiki-tgmeds' does have a prefix of 'tg-' first in the database.
whilst endeavouring to set up 'common.css' like I already have on my
main 'DrugFacts' website, it is working on 'wiki-drugfacts' but not on
'wiki-tgmeds'. It seems very likely that I have set up
'http://localhost/wiki-tgmeds/index.php/Common.css' but now I can't
delete it. So how can I securely delete it please?
I've looked at these pages [1], [2], and [3] and they all seem to imply
that I need to be in the 'administrator' or 'sysop' user groups. so I've
looked at all possible variations of user/root setup of wiki-tgmeds to
see if I can change the user permission for myself, but without any
success at all.
I'm now coming to the belief that it possibly relates to how I set up
wiki-tgmeds. I set up wiki-drugfacts and got it working as I wanted, and
then I created the wiki-tgmeds directory at /var/www/html/wiki-tgmeds
and then proceeded to manually populate the directory with an install of
the mediawiki files, from when I expanded and extracted
'mediawiki-1.31.0.tar.gz'. I found the site on localhost in my browser
and then just proceeded to create a new 'LocalSettings.php'. And once
the site was up and running I created one article but wasn't able to get
the text to wrap around the TOC, which started me off on my quest to get
'Common.css' working properly.
So to recap, how can I delete the erroneous 'Commons.css' file on wiki-tgmeds' please
Thanks
Sharon.
[1] https://www.mediawiki.org/wiki/Help:Contents
[2] https://www.mediawiki.org/wiki/Help:Deletion_and_undeletion
[3] https://www.mediawiki.org/wiki/Manual:Administrators#Deletion
--
A taste of linux = http://www.sharons.org.uk
DrugFacts = https://www.drugfacts.org.uk
Debian 9.4, fluxbox 1.3.7, emacs 25.3.2, org 9.1.13