Hello everyone,
We are happy to announce the immediate availability of the second stable
release in the Semantic MediaWiki 2.x series.
Semantic MediaWiki 2.1 is a minor release that adds several new features,
many enhancements, addresses numerous issues and adds support for
additional platforms. It does not contain any breaking changes.
## Highlights ##
### Support for semantic queries in Special:Search ###
This release adds support for semantic queries run directly from
MediaWiki's standard search. You can enable this feature by setting
$wgSearchType to "SMWSearch". The related configuration parameter
$smwgFallbackSearchType allows specifying which search engine to fall back
to in case "SMWSearch" returns no results. (#450, #496, #505)
### SPARQLStore improvements ###
The SPARQLStore now supports concept queries (#696) and regex like queries
([[Url::~http://*query=*]] OR [[Url::~*ccc*]]) for Page and URL values
(#679).
Notable performance improvements and many other fixes (can be found in the
bug fix list) have been made to broaden the SPARQLStore support.
### Enhanced platform support ###
* SMW has partially supported PostgreSQL for a long time. This new release
brings SMW's PostgreSQL support to the same level as MySQL and SQLite,
making it the third fully supported relational database.
* HHVM (HipHop Virtual Machine) 3.3 or above is now supported along with
all previously supported PHP versions.
* Although earlier versions of SMW probably work with MediaWiki 1.24, this
new release officially supports it.
You can find a full overview in our compatibility matrix [0]. This matrix
now also includes planned compatibility for future releases, to the extend
this is known.
## Other new features ##
* Concepts can now be nested (bug 15316)
* Modernized Special:SearchByProperty interface
* Added subobject parameter to the BrowseBySubject API module and imporved
resolving of circular redirects
* Added --page as export option to the dumpRDF.php maintenance script
* Made ouput decoding for uri's human readable (bug 35452)
* Added --runtime option to rebuildData.php. It allows you to see how much
time was spend and how much memory was used.
* Added $smwgEnabledEditPageHelp option that enables showing a contextual
help text on the edit page
* Enabled semicolon escaping for record-type values (\;) (bug T17732)
* Added Special:Log support for events enabled in smwgLogEventTypes
## Bug fixes ##
* Fixed the SPAPRQLStore to return a FalseCondition instead of an exception
for not supported data types (e.g Geo)
* Fixed the SPAPRQLStore query selection for subobjects used with a
namespace condition
* Removes invalid category value links to SearchByProperty on
Special:Browse (bug 33449)
* Fixed parameter encoding in Special:SearchByProperty for hyphens and
spaces (bug 16150)
* Enhanced concept pages to provide time and date of the last update
* Fixed the SPARQLStore query result display for moved pages (a.k.a. "gost"
pages)
* Fixed movability for predefined property pages
* Fixed data display inconsistency for pre-existing redirects
* Fixed circular UpdateJob caused by redirects
* Fixed exception in dumpRDF.php caused by resolving a subobject for a
redirect
* Fixed cache id mismatch for redirects in SQLStore
* Fixed exception for when a null is returned by
ExportController::getSemanticData
* Enhanced SPARQLStore XML result parser to support Virtuoso singelton
response
* Fixed subobject disjunctive/conjunctive subquery handling
* Fixed named subobject encoding in the Exporter to support accented
characters
* Fixed browse link generation for wikipages in Special:Browse
* Fixed the hard-coded upper bound for the offset option of an inline query
by replacing it with configuration parameter $smwgQUpperbound
* Fixed postgres temporary table generation issue (bug 34855, #455, #462)
* Fixed QueryProcessor to allow query conditions to contain = (bug 32955)
* Removes service info links from the Factbox
* Fixed broken field detection in record-type caused by html encoded
strings (bug T23926)
* Fixed #REDIRECT detection in MW 1.24+
* Fixed regex search (~/!) for page-type property values (bug T36665,
T49073, T33151, T35854)
* Fixed regex search support for uri-type property values
* Fixed invalid :smw-redi marker when #REDIRECT is removed manually
* Fixed probable race condition for SQLStore(postgres) when creating
temporary tables
* Fixed http header in SPARQLStore to be Sesame complaint
The full list can also be viewed at [2]. The installation procedure [3] has
not changed since 1.9.0. To upgrade, you will need to get the new version
of SMW, run MediaWikis update.php, and run SMWs refresh data script [4].
- The SMW development team
[0]
https://github.com/SemanticMediaWiki/SemanticMediaWiki/blob/master/docs/COM…
[2] https://semantic-mediawiki.org/wiki/SMW_2.1
[3] https://semantic-mediawiki.org/wiki/Help:Installation
[4] https://semantic-mediawiki.org/wiki/Help:Installation#Upgrading
Hello all,
I just applied MW 1.24.1 patch, and got a few SQL errors which prevent a
page edit from applying. I had no issues apart from some minor extensions
stuff when upgrading from 1.23.x to 1.24.0.
System is RHEL 6.5 with Postgresql 9.2 (via RH Software Collections).
The PostgreSQL log shows:
ERROR: column "pl_from_namespace" of relation "pagelinks" does not
exist at character 75
STATEMENT: INSERT /* LinksUpdate::incrTableUpdate Dwc62 */ INTO
"pagelinks" (pl_from,pl_from_namespace,pl_namespace,pl_title) VALUES
('105','0','0','OS_Upgrades')
Any hints on how to fix this?
Thanks,
Dave
--
David Chin, Ph.D.
david.chin(a)drexel.edu Sr. Systems Administrator, URCF, Drexel U.
http://www.drexel.edu/research/urcf/https://linuxfollies.blogspot.com/
215.221.4747 (mobile)
https://github.com/prehensilecode
Trying to get rid of this error.; all Mediawiki is completely updated to
1.24.1: no wiki issues; Just Lua: i tried to download the newest Modules
from Wikipedia since I use most of my templates from there; Still
cropping up as below
Any Tips please;
Lua error in Module:In_the_news/image at line 19: attempt to index field
'file' (a nil value).
Backtrace:
1. *(tail call)*: ?
2. *Module:In_the_news/image:19
<http://beast.physicswiki.net/index.php?title=Module:In_the_news/image&actio…>*:
?
3. *(tail call)*: ?
4. *mw.lua:497*: ?
5. *(tail call)*: ?
6. *[C]*: in function "xpcall"
7. *MWServer.lua:87*: in function "handleCall"
8. *MWServer.lua:301*: in function "dispatch"
9. *MWServer.lua:40*: in function "execute"
10. *mw_main.lua:7*: in main chunk
11. *[C]*: ?
Below is the source of actual module in question:Line 19 is highlighted in red:
-- This module implements [[Template:In the news/image]], which displays
-- the news image on the Main Page.
local mFileLink = require('Module:File link')
local p = {}
function p._main(args)
if not args.image then
return nil
end
if not args.title then
error('no title specified', 2)
end
local imageTitle = mw.title.new(args.image, 6) -- NS_FILE
if not imageTitle then
error('invalid image title (check for bad characters): ' .. args.image, 2)
elseif not imageTitle.file.exists then
return string.format(
'<span class="error">No file exists at [[:%s]]</span>',
imageTitle.prefixedText
)
end
local link
if args.link then
local linkTitle = mw.title.new(args.link, 6) -- NS_FILE
if not linkTitle then
error('invalid link (check for bad characters): ' .. args.link, 2)
elseif linkTitle ~= imageTitle then
if not linkTitle.file.exists then
return string.format(
'<span class="error">No file exists at [[:%s]]</span>',
linkTitle.prefixedText
)
end
link = linkTitle.prefixedText
end
end
return string.format(
'<div style="float:right;margin-left:0.5em;">\n%s</div>',
mFileLink._main{
file = imageTitle.text,
link = link,
size = args.size or '100x100px',
border = args.border,
caption = args.title,
alt = args.alt or args.title
}
)
end
function p.main(frame)
return p._main(require('Module:Arguments').getArgs(frame, {
wrappers = 'Template:In the news/image'
}))
end
return p
--
John Foster
JW Foster & Associates
Hi,
I've been trying to upgrade from 1.22 to 1.24 however, it seems that the
new version is trying to do a "fresh" install?
I have followed the "official" guide:
http://www.mediawiki.org/wiki/Manual:Upgrading
and also in the meantime upgraded from php 5.3 to 5.6, base is on Nginx.
If I try to run the php update script I get these errors:
PHP Warning: PHP Startup: Unable to load dynamic library
'/usr/local/lib/php/20131226-zts/apc.so' - Cannot open
"/usr/local/lib/php/20131226-zts/apc.so" in Unknown on line 0
PHP Warning: PHP Startup: Unable to load dynamic library
'/usr/local/lib/php/20131226-zts/sqlite3.so' - Cannot open
"/usr/local/lib/php/20131226-zts/sqlite3.so" in Unknown on line 0
PHP Warning: PHP Startup: Unable to load dynamic library
'/usr/local/lib/php/20131226-zts/sqlite.so' - Cannot open
"/usr/local/lib/php/20131226-zts/sqlite.so" in Unknown on line 0
PHP Warning: Module 'mysql' already loaded in Unknown on line 0
PHP Warning: Module 'pdo_mysql' already loaded in Unknown on line 0
PHP Warning: Module 'pdo_pgsql' already loaded in Unknown on line 0
PHP Warning: Module 'pgsql' already loaded in Unknown on line 0
PHP Warning: Module 'gettext' already loaded in Unknown on line 0
PHP Warning: Module 'curl' already loaded in Unknown on line 0
PHP Warning: Module 'exif' already loaded in Unknown on line 0
PHP Warning: Module 'gd' already loaded in Unknown on line 0
PHP Warning: Module 'imap' already loaded in Unknown on line 0
PHP Warning: Module 'openssl' already loaded in Unknown on line 0
PHP Warning: Module 'intl' already loaded in Unknown on line 0
PHP Notice: Use of undefined constant NS_MediaWiki - assumed
'NS_MediaWiki' in /usr/local/www/www/LocalSettings.php on line 162
Set $wgShowExceptionDetails = true; in LocalSettings.php to show
detailed debugging information.
I should be able to sort out the sqlite issues but apc.so doesn't work
with php version 5.5 or 5.6 and so I'm not entirely sure what needs
them.. then there's the NS_Mediawiki issue too.
Any help or suggestions would be highly appreciated.
Many thanks.
Kaya
After 18 months of MediaWiki release management handled externally by
Markus Glaser and Mark Hershberger, we have agreed to bring the
MediaWiki release work back to the Wikimedia Foundation. From now on,
the Release Engineering team coordinated by Greg Grossmeier, which is
responsible for the WMF weekly releases, will be also in charge of the
MediaWiki releases for third parties. This will be a hit on the WMF
Release Engineering team initially, but we plan to make future
announcements related to that.
About two years ago we explored the outsourcing of MediaWiki releases
under the assumption that an external team not conditioned to the
Wikimedia priorities would be in a better spot to satisfy the needs of
third party MediaWiki users. Over time, this assumption has been
overshadowed by the overhead required to keep both release teams in
sync, and the difficulties that Mark y Markus have run into when trying
to follow the weekly release train. We believe that the situation would
be similar with any other external team, so we have decided to go back
to in-house releases.
Another lesson learned by all of us is that managing MediaWiki releases
and promoting a MediaWiki ecosystem are very different specialized
tasks, and it is hard to be the individuals in charge of both. Both Mark
and Markus were active in the MediaWiki community well before managing
MediaWiki releases, and will continue to be active now in the context of
the MediaWiki Stakeholders Group, as volunteers and with their own
stakeholders' hats. The Engineering Community team, coordinated by Quim
Gil, will offer their help in consolidating the Group and aligning their
interests with the WMF plans.
The Wikimedia Foundation thanks Mark, Markus, and Alexis for the work
done releasing MediaWiki and coordinating several community activities
in the context of the MediaWiki Stakeholders Group. While we are aware
of the disruption that this change of strategy might bring, we believe
that the new situation puts us all in a better position to support the
needs of the MediaWiki community.
This change of course is also a good chance to discuss what is the best
mid-term scenario for MediaWiki outside of Wikimedia, and what should we
all do in order to get there. The MediaWiki Developer Summit in San
Francisco next week is a good place to have this conversation, in
addition of our usual online channels, of course.
Markus Glaser, Mark Hershberger, Alexis T. Hershberger, Greg Grossmeier,
Quim Gil
Hello,
(I posted this in a similar form a few days ago)
I was wondering if anyone here could help.
I just upgraded a "staging" wiki running 1.23.8 to 1.24.1 and get no
output (blank) and I see the log says it is due to a skin error. I do
not know much PHP. which is a source of the problem I have. Looking
through the release notes, I see the problem will be down to the skin
"auto-discovery" changes.
I am running a custom skin "zeddocs" based on Vector. I "authored" this
but without a proper understanding and with lots of help from
mediawiki-l
(http://thread.gmane.org/gmane.org.wikimedia.mediawiki/43017/focus=43019).
Looking at this help page about migrating skins to 1.24, I have tried to
adjust my custom skin files but without success.
In 1.24.1 skins/ I have :
* CologneBlue/
* Modern/
* MonoBook/
* Vector/
* ZedDocs/
ZedDocs is the custom skin based on Vector.
The Apache error I was getting is :
Tue Jan 13 15:43:10 2015] [error] [client 192.168.0.124]
PHP Warning:
require_once(/home/user/mediawiki-1.24.1/skins/zeddocs/../Vector.php):
failed to open stream:
No such file or directory in
/home/user/mediawiki-1.24.1/skins/zeddocs/ZedDocs.skin.php on line 9,
referer: http://wpdev/w/index.php?title=Main_Page
On line 9 of zeddocs/ZedDocs.skin.php I had :
require_once( dirname( __FILE__ ) . '/../Vector.php' );
If I remove this line as per Daniel Friesen on last mediawiki-l thread,
I get error :
[Tue Jan 13 16:38:50 2015] [error] [client 192.168.0.124]
PHP Catchable fatal error: Argument 1 passed to
SkinVector::__construct() must implement interface Config, string given,
called in /home/user/mediawiki-1.24.1/includes/Setup.php on line 285 and
defined in /home/user/mediawiki-1.24.1/skins/Vector/SkinVector.php on
line 38, referer: http://wpdev/w/index.php?title=Main_Page
Unfortunately, I don't follow what to do from Daniel's suggestion about
the way Vector now works. I have tried to set up my skin files (and
renamed) as per the Skin_autodiscovery manual page.
skins/ZedDocs/
- css
- images
- ZedDocs.i18n.php
- ZedDocs.php
- ZedDocs.skin.php
I have made changes to files ZedDocs.php and ZedDocs.Skin.php but they
are not working.
Can anyone see what's wrong or what I need to add? The files are here
(added .txt extension) :
* http://www.sherringham.net/tmp/ZedDocs.php.txt
* http://www.sherringham.net/tmp/ZedDocs.skin.php.txt
* http://www.sherringham.net/tmp/ZedDocs.i18n.php.txt
Obviously, if this is not a small or basic job, I'll need to reconsider
how I do things. Either stick with 1.23.8 for now or switch back to pure
Vector skin in future. The only reason I modified it was to add a page
"banner" and tweak a bit of CSS etc. I kike what I have but prefer being
able to upgrade.
Many Thanks,
Alastair
--
Alastair Sherringham
http://www.sherringham.net
-------- Messaggio inoltrato --------
Oggetto: [Wikimedia-l] Congratulations to MediaWiki Farmers User Group
for being approved as a Wikimedia User Group
Data: Sat, 17 Jan 2015 18:54:37 -0500
Mittente: Gregory Varnum
Greetings,
Please join the Affiliations Committee in congratulating the MediaWiki
Farmers User Group on their official approval as a Wikimedia User Group:
https://meta.wikimedia.org/wiki/Affiliations_Committee/Resolutions/MediaWik…
The MediaWiki Farmers User Group is "A user group of third-party developers
who work on wiki farms. Our mission is to improve and standardize the way
MediaWiki wiki farms are setup and run."
Anyone interested in more information about the group can visit:
https://www.mediawiki.org/wiki/Project:MediaWiki_Farmers_user_group
Again - congratulations on the recognition and best wishes for the group's
future work!
-greg aka varnent
Vice Chair, Wikimedia Affiliations Committee
_______________________________________________
Wikimedia-l mailing list, guidelines at:
https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines
Wikimedia-l(a)lists.wikimedia.org
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l,
<mailto:wikimedia-l-request@lists.wikimedia.org?subject=unsubscribe>
Hello,
I have a problem with an extension. There is a some
$parser->setFunctionHook defined.
The function of the hook uses fake named parameters, meaning that the
parameters are caught by "func_get_args()", and the only parameter in
the function is &$parser.
My problem with this is now, that I want to use
"$parser->recursiveTagParse" in that function to expand a template, but
when I dump the params I get the param string as "[[:template]]" instead
of "{{:template}}, and of course recursiveTagParse don't give the needed
result.
The second topic is, that I maybe need $frame to expand variables, but I
did not get it working with fake named parameters.
Greetings
Frank Baxmann
Maybe I am being stupid, or missing something - but I can't seem to add
a discussion "topic" to a Mediawiki talk page.
I am trying to "Add Topic" to page :
https://www.mediawiki.org/wiki/Manual_talk:Skin_autodiscovery
I add a subject and text of the topic - "preview" is OK.
But when I press "Save page" it only ever brings me back to "preview"
mode again.
I only created an account yesterday in order to ask for help with my
"custom skin auto-discovery" problem I wrote about here a couple of days
ago (" MW 1.24 upgrade issue wirh custom skin" on the 13th). Is it
something to do with being a new user?
What am I doing wrong?
Cheers,
--
Alastair Sherringham
http://www.sherringham.net