On May 30, 2013, at 5:00 AM, mediawiki-l-request(a)lists.wikimedia.org wrote:
> https://www.mediawiki.org/wiki/Manual:%24wgUsersNotifiedOnAllChanges
The above doesn't work. Added it to LocalSettings.php then restarted browser,
revisited Wiki, modified, deleted and added pages randomly and got ZERO
email notifications. Not good.
If you've ever set up a fresh MediaWiki and tried to leave it open to editing, you'll know about the problem of wiki spam. There's various well documented tricks to tackle the problem on your own wiki (although it seems to me that some of these are becoming less effective over time. Particularly reCaptcha)
But wiki spammers are behaving in a staggeringly inconsiderate and anti-social way, and I've often thought we should explore stronger ways of delivering some fight back.
Looking at spam across many wikis e.g. by googling "mediawiki ugg boots" we could do more internet-wide spam cleanup somehow.
But recently I came across something, actually by looking at one the spam links. Take a look at this: sickseo.co.uk/off-page-seo.html This video shows the use of a tool called 'SENuke Xcr' and another one called 'Ultimate Demon' to perform "Off site SEO" ...that's "spamming" to you and me.
I've always known spammers used tools like this, but seeing this instructional video gives me new insights into what we're up against. Also see the discussion taking place on forum.edwinsoft.com I find it amazing how oblivious these people seem to be, to how annoying their activities are for people running websites. Never do they mention the word spam, or have an inkling that they may be doing something ethically questionable.
Do you think we should try to contact them and explain that they are behaving badly? Maybe on these forums. Maybe we'd have to spam them back repeatedly with such messages as they get removed by the admins. And on youtube do you think we can get videos like this removed? We can at least comment on them and vote them down (Youtube finds quite a lot of similar videos) How about unleashing a bit of "ethical hacking" e.g. DDOS attacks on people distributing this software? Really I'm amazed at how they're getting away with this spamming out in the open these days.
Halz
http://www.mediawiki.org/wiki/User:Halz
Cheers MW developers -- simple question:
I am working on my first bug-fix (see https://bugzilla.wikimedia.org/show_bug.cgi?id=43571) and have submitted a patch (see https://gerrit.wikimedia.org/r/#/c/65301/.) I would like to address the issues brought up by Hashar, who has been kind enough to review and comment on the patch.
What is the correct way to submit a new patchset to Gerrit?
I am new to Git and am slightly overwhelmed by the copious documentation on MW.org (not a bad thing.) Should I 'git pull origin master' and then 'git rebase'? Or do just just run 'git review -R' again to send my patch?
--User:AlephNull (a.k.a. Daniel Renfro)
While reading and cleaning I saw that the default message for
[[mw:MediaWiki:Accesskey-n-sitesupport]] has become a redlink. I was
unable to find documentation to see that it had been deprecated or
accidentally omitted, and searching the wiki itself was a dead loss.
Can someone please
1) enlighten me on the specific case, so I can delete relevant links; and
2) instruct me on how and where I should have looked to find this out for
myself.
If nothing else, I would have thought that we could have a list of
deprecated or removed components at MW to help the less skilled. Thanks.
Regards, Billinghurst
Hallo,
I would like to announce the release of MediaWiki language extension
bundle 2013.05
* https://translatewiki.net/mleb/MediaWikiLanguageExtensionBundle-2013.05.tar…
* sha256sum: 9aea5b1dac2b38e44284373c849241fc694c78caff1d3ca3b4e6e72d66f2ab12
Quick links:
* Installation instructions are at https://www.mediawiki.org/wiki/MLEB
* Announcements of new releases will be posted to a mailing list:
https://lists.wikimedia.org/mailman/listinfo/mediawiki-i18n
* Report bugs to https://bugzilla.wikimedia.org
* Talk with us at #mediawiki-i18n @ freenode
Release notes for each extension are below.
Amir E. Aharoni
== Babel ==
Only localization updates.
== cldr ==
CLDR was updated to version 23.1.
== CleanChanges ==
Only localization updates.
== LocalisationUpdate ==
No changes.
== Translate ==
The new translation editor in Translate is now considered stable. The
last month saw mostly polishing and bug fixes, changes in internals of
the extension and terminology was made more consistent.
Other notable bug fixes:
* Warnings are loaded for outdated messages before user starts typing,
because being outdated is an issue in itself.
* Statsbar at the bottom floating bar of Special:Translate is updated
when changing group.
* Links of tabs at the top of Special:Translate are now kept in sync
when changing message group or language
* Custom icon (x) for clearing the searchboxsearch box clear icon was
removed. Some browsers add this icon automatically, while others do
not.
* The tooltips for message groups in the group selector were removed.
They contained unparsed wiki markup, which could be confusing.
* Message documentation can be added even if the translations are
restricted to only certain languages.
* Icons for status markers and review actions for right-to-left
languages were added.
* In some rare cases the language name could be incorrectly displayed
when selected from the language selector at Special:Translate, because
the text direction attribute was not updated properly.
== UniversalLanguageSelector ==
The last month saw significant changes in the Universal Language
Selector extension: many bugs were fixed and some design changes were
introduced.
The default location of the language selectors is in the personal
toolbar. For projects like Wikipedia, with interlanguage links,
separating interwiki links from user interface language could cause
confusion for users. It is now also possible to use a cog icon in the
area for interlanguage links using $wgULSPosition = 'interlanguage' in
LocalSettings.php, though this feature is still experimental.
Notable bug fixes:
* Major bugs in the input methods functionality for Microsoft Internet
Explorer 8, 9 and 10 were fixed.
* IME selector positioning is now more consistent: always under the
input box, and matching the direction.
* Anonymous users cannot change the user interface language if
$wgULSAnonCanChangeLanguage is set to false. This may help avoid cache
pollution in certain MediaWiki setups, while input methods and web
fonts still remain available.
* A link to open the ULS was added near the language selector on
Special:Preferences.
* The positioning of the ULS windows was cleaned up so that the appear
in more predictable places on the screen.
* ULS triggers are not displayed to users who disabled JavaScript or
if the site has fatal JavaScript errors.
* The checkbox that enables and disables webfonts was removed. The
feature is now always on.
* Any untranslatable elements have been made translatable. Please
contribute to translations at
https://translatewiki.net/wiki/Special:Translate/ext-jquery-uls and
https://translatewiki.net/wiki/Special:Translate/ext-universallanguageselec….
* Fonts for the Syriac alphabet and support for the 'syc' language
code were added.
* Completely disabling input method tools and reenabling immediately
was made easier.
* The bubble for restoring the previous language is not displayed to
anonymous users if they can't change the language.
* jquery.i18n files can be loaded from the same domain to fix an issue
with old Microsoft Internet Explorer versions. This is only relevant
if resources are served from a different domain.
A known issue is bug 48898 - the "Apply settings" button doesn't close
the Input settings panel after enabling or disabling the settings. The
settings are saved, but the button doesn't work correctly.
Bugzilla link: https://bugzilla.wikimedia.org/show_bug.cgi?id=48898
Thank you,
--
Amir Elisha Aharoni · אָמִיר אֱלִישָׁע אַהֲרוֹנִי
http://aharoni.wordpress.com
“We're living in pieces,
I want to live in peace.” – T. Moore
Hi All:
I have a question: I don't want to use mediawiki's internal user management
system; instead, I want to login in as follows: I click a button in the
wiki's mainpage, and it will redirect me to a external site. And after I
login in the external site, it will redirect to the wiki's page with some
user infomation in the URL returned. And I can get the user info by parsing
the URL. And I want use this user as my current wiki user. There will be no
other internal databases related with the user system.
My external site does't support OpenID or other systems.
So, my problem is: how I can achieve this? Do I need to modify the wiki's
user management system
Hi,
Is there a straightforward way to create a new sqlite database for
mediawiki, all ready for me to import data from an XML dump into? I
want this in order to easily populate fresh databases with data from
my mediawiki site, for easy testing of new stuff.
I expected a command like the following to work:
sqlite3 db.sqlite < maintenance/tables.sql
But there are lots of errors, starting with:
Error: near line 53: near "AUTO_INCREMENT": syntax error
Error: near line 130: no such table: main.user
Error: near line 131: no such table: main.user
Error: near line 132: near "(": syntax error
I know I can create a new database using the install.php script, but
that's overkill for me, and if possible I'd like to script the
creation of an appropriate table structure that I can then import a
database dump into.
Does anybody have any suggestions? Why doesn't the above command
work? Reading the code of how the install.php script works implies
to me that it's roughly how the tables are set up. Is there some
step I'm missing?
Or should I go about this a different way entirely?
Thanks in advance,
Nick White
Hello,
I'd like to use custom dialogs and buttons in the WikiEditor (https://www.mediawiki.org/wiki/Extension:WikiEditor). The customization are done via code in the /index.php/MediaWiki:Common.js
I'm having trouble that sometimes my custom module is not added.
At the moment I use time-deferred check-function:
window.setTimeout(checkModule,500)
which than loads a function that checks if the module that defines the custom dialog has actually been loaded:
var checkModule = function(){
if(!$.wikiEditor.modules.dialogs.modules.mytool){
$( '#wpTextbox1' ).wikiEditor( 'addModule', mytool());
//console.log("postLoad of module was needed!")
}
}
This seems to work fairly well in the real world, but seems rather hacky code wise.
The first attempt to add the module is done in a function which is executed on the jQuery 'wikiEditor-toolbar-doneInitialSections' event. (build-in-event in the current 1.21 Version of Wikieditor):
$( '#wpTextbox1' ).on( 'wikiEditor-toolbar-doneInitialSections', customExtendEditor
in the customExtendEditor function, the module is defined, and the Module is added (not always sucessfully):
var mytool = function(){
return { dialogs:{
mytool:{
[etc.]
$( '#wpTextbox1' ).wikiEditor( 'addModule', mytool());
a button is added via ` $('#wpTextbox1').wikiEditor( 'addToToolbar', { … `
but that never caused me problems itself so far.
If you know a better, less hacky solution than the deferred check and re-addition, please let me know.
Kind Regards,
Jan
PS.: full code (from my wiki's /index.php/MediaWiki:Common.js): http://jsfiddle.net/RAHCg/