Hi,
I'm running multiple language wikis and one pool wiki. The problem is
that no file descriptions are fetched in the language wikis although
$wgFetchCommonsDescriptions is set to true.
LocalSettings.php of the language wikis:
$wgUseSharedUploads = true;
$wgSharedUploadPath = 'http://pool.example.com/w/images';
$wgSharedUploadDirectory = '/path/to/pool/w/images/';
$wgHashedSharedUploadDirectory = true;
$wgFetchCommonsDescriptions = true;
$wgSharedUploadDBname = 'poolwiki'; # DB-Name of PoolWiki
#$wgSharedUploadDBprefix = 'wiki_'; # Table name prefix for PoolWiki
$wgRepositoryBaseUrl = "http://pool.example.com/wiki/Image:";
ForeignAPIRepo used to work fine before, but since I switched from
Apache to Nginx, no images show up anymore in the language wikis. This
is how my LocalSettings.php used to look like:
$wgForeignFileRepos[] = array(
'class' => 'ForeignAPIRepo',
'name' => 'pool',
'apibase' => 'http://pool.example.com/w/api.php',
'fetchDescription' => true, // Optional
'descriptionCacheExpiry' => 43200, // 12 hours, optional (values are
seconds)
'apiThumbCacheExpiry' => 0, // required for local thumb caching
);
I also tried to set 'name' => 'poolwiki', (name of the pool database)
but that doesn't work either.
I also re-started Memcached and I even deleted a file description page
from the CloudFlare cache, but still no file description can be seen :/
My software: MediaWiki: 1.22.0
PHP: 5.3.27 (fpm-fcgi)
MySQL: 5.1.70-log
Any help would be über-cool.
Thanks and cheers,
Till
Hi,
I want to log a user into our wiki if they are logged into our website.
I assume that I need to use the UserLoadFromSession hook, but at this
point in the code, the MW session is already active. Does it make sense
to close the MW session, configure & start my website session in order
to access the user ID, and then re-open the MW session using
wfSetupSession(), or is this not recommended?
I see that some people access their website username from another
cookie, but I'd like to avoid this if possible.
This is the rough idea that seems to be working, I think:
$wgHooks['UserLoadFromSession'][] = function($user, &$result) {
// Check if the user is already logged into MW.
// How do I do this???
// Close MW session.
session_write_close();
// Configure website session.
session_name('x');
session_save_path('x');
ini_set('session.cookie_domain', '.x');
session_start();
// Check if user is logged in to website.
if (isset($_SESSION['Zend_Auth'])) {
$userId = (int)$_SESSION['Zend_Auth']['storage'];
// Close website session.
session_write_close();
// temp, look up username in DB.
if ($userId == 123) {
$username = 'xyz';
}
$user = User::newFromName($username);
// Log user in.
$user->setToken();
$user->saveSettings();
wfSetupSession();
$user->setCookies();
} else {
wfSetupSession();
}
return true;
};
I'm not sure if this is the best option, and also how to bypass this
code if the user is already logged into the wiki.
I also need to auto-create an account for users without MW accounts, but
I think I can use $user->addToDatabase() for that.
Any help would be greatly appreciated.
Glen.
We've gotten some feedback already -- https://github.com/SemanticMediaWiki/SemanticMediaWiki/issues/212 -- about the RC for MediaWiki 1.23 that Markus made last week. Hopefully we can get this issue addressed in time for SMW users.
Are there any other issues that people have run into that we should know about before we do attempt to make a final release of 1.23?
If you've tried the RC and not run into any problems, that would be good to know, as well.
Thanks,
Mark.
Hello all,
I would like to announce the release of MediaWiki Language Extension
Bundle 2014.04. This bundle is compatible with MediaWiki 1.22.6 and
MediaWiki 1.21.9 releases.
* Download: https://translatewiki.net/mleb/MediaWikiLanguageExtensionBundle-2014.04.tar…
* sha256sum: f20631d2629e0cf80df8ca022e6eec4d6d784e0cd39799f9fd46f338f4a7381a
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.
-- Kartik Mistry
== Babel, CleanChanges and CLDR ==
* Only localisation updates.
== LocalisationUpdate ==
* Make sure that older MediaWiki versions also get updates for core messages.
== Translate ==
=== Noteworthy changes ===
* Added ElasticSearch support for translation memory and translation search.
* Set JSON message format as default for MediaWiki extensions.
* Add tracking (mw.track) for primary events: translation and proofread.
* Removed SingleFileBasedMessageGroup.
* Removed classes used for supporting the old MediaWiki core format
and updated related maintenance scripts.
* Localisation updates.
== UniversalLanguageSelector ==
=== Noteworthy changes ===
* Allow always logging tofu detection in EventLogging.
* Bug 62981: Fixed RTL positioning for compact interlanguage links.
* Localize the number in the "more languages" message in the compact
links feature.
* Bug 60815: Set Arabic as the writing system for Ottoman Turkish (ota).
* Bug 63718: Allow overriding the header styles from typography refresh.
* Add loading of messages using $wgMessagesDirs
=== Input Methods ===
* Added Batak input method.
* Fixed the Odia Lekhani method, as well as the InScript methods for
Hindi, Odia and Malayalam.
Thanks!
--
Kartik Mistry/કાર્તિક મિસ્ત્રી | IRC: kart_
{kartikm, 0x1f1f}.wordpress.com
Got another nginx / mediawiki issue for you brilliant minds. All help
appreciated!
I've got file uploads working, but after the upload is complete, the
File:filename page shows as a 404.
For example:
http://www.mattselznick.com/thehumanitycontinuum/wiki/File:Shure_55s_1951.p…
The section of my nginx conf file for the wiki looks like this:
# Location for the wiki's root
location /thehumanitycontinuum/wiki/ {
try_files $uri $uri/ @mediawiki;
# Do this inside of a location so it can be negated
location ~ \.php$ {
try_files $uri $uri/ =404; # Don't let php execute non-existent php files
include /etc/nginx/fastcgi_params;
fastcgi_pass unix:/var/run/php5-fpm.sock;
}
}
location /thehumanitycontinuum/wiki/images {
# Separate location for images/ so .php execution won't apply
location ~ ^/thehumanitycontinuum/wiki/images/thumb/(archive/)?[0-9a-f]/[0-9a-f][0-9a-f]/([^/]+)/([0-9]+)px-.*$
{
# Thumbnail handler for MediaWiki
# This location only matches on a thumbnail's url
# If the file does not exist we use @thumb to run the thumb.php script
try_files $uri $uri/ @thumb;
}
}
location /thehumanitycontinuum/wiki/images/deleted {
# Deny access to deleted images folder
deny all;
}
# Deny access to folders MediaWiki has a .htaccess deny in
location /thehumanitycontinuum/wiki/cache { deny all; }
location /thehumanitycontinuum/wiki/languages { deny all; }
location /thehumanitycontinuum/wiki/maintenance { deny all; }
location /thehumanitycontinuum/wiki/serialized { deny all; }
# Just in case, hide .svn and .git too
location ~ /.(svn|git)(/|$) { deny all; }
# Hide any .htaccess files
location ~ /.ht { deny all; }
# Uncomment the following code if you wish to hide the installer/updater
## Deny access to the installer
#location /thehumanitycontinuum/wiki/mw-config { deny all; }
# Handling for the article path
location @mediawiki {
include /etc/nginx/fastcgi_params;
# article path should always be passed to index.php
fastcgi_param SCRIPT_FILENAME
$document_root/thehumanitycontinuum/wiki/index.php;
fastcgi_pass unix:/var/run/php5-fpm.sock;
}
# Thumbnail 404 handler, only called by try_files when a thumbnail
does not exist
location @thumb {
# Do a rewrite here so that thumb.php gets the correct arguments
rewrite ^/thehumanitycontinuum/wiki/images/thumb/[0-9a-f]/[0-9a-f][0-9a-f]/([^/]+)/([0-9]+)px-.*$
/thehumanitycontinuum/wiki/thumb.php?f=$1&width=$2;
rewrite ^/thehumanitycontinuum/wiki/images/thumb/archive/[0-9a-f]/[0-9a-f][0-9a-f]/([^/]+)/([0-9]+)px-.*$
/thehumanitycontinuum/wiki/thumb.php?f=$1&width=$2&archived=1;
# Run the thumb.php script
include /etc/nginx/fastcgi_params;
fastcgi_param SCRIPT_FILENAME
$document_root/thehumanitycontinuum/wiki/thumb.php;
fastcgi_pass unix:/var/run/php5-fpm.sock;
}
--
Matthew Wayne Selznick
Author, Creator and Creative Services Provider
http://www.mattselznick.com
Get a Free Sampler of My Short Stories, Novels, and Non-Fiction:
http://www.mattselznick.com/free-ebook
Hi everyone,
We are holding about seven wikis on one linode serves. We used to
create symbolic link under different dir. Unfortunately due to different
wiki have different extension, database, and user habits. I can't set a
single commonsetting.php for all wikis. We would like to move all the
setting files to a common folder. However, nobody knows how to load
different localsettings_XXX.php depends on requesting URL. I do read page
https://www.mediawiki.org/wiki/Manual:Wiki_family but non of them work. I
don't know why.
zoglun
Hello,
my database is lost, the last backup is because of an error in the
backup software 6 months old (Sep 2013).
Is there a way to restore the wiki?
At the moment I have installed 1.22 and also try 1.19.
Categories are shown but no articles.
how can help?
Regards,
Basti
See idea at
<https://meta.wikimedia.org/wiki/Grants:IdeaLab/A_place_to_work_together>.
If you'd like to develop the Lockdown extension, you can get a few
thousands dollars to do it.
If you use the Lockdown extension, please document in bugzilla reports
what's missing for it to satisfy the requirements.
Nemo
I just started getting this message during my automated backup sessions
of all my mysql data bases. All except my mediawiki are fine.
mysqldump: Got error: 144: Table './mywiki/searchindex' is marked as
crashed and last (automatic?) repair failed when using LOCK TABLES
Any ideas of what to do.
thnaks
John
