Discuss Installation
- [View source↑]
- [History↑]
Contents
Thread title | Replies | Last modified |
---|---|---|
Where is that upgrade section? | 5 | 18:01, 24 April 2019 |
Why shouldn't tests be run on a production server? | 1 | 02:30, 16 March 2019 |
Upgrading MW 1.30 SMW 2.5.5 Causing issues with SPARQL queries | 2 | 04:28, 20 January 2018 |
Upgrading from MW 1.24.1 to 1.25.2 cause error | 1 | 21:55, 17 August 2015 |
Upgrade seems to work - but the old version is still running | 1 | 03:07, 18 August 2014 |
Uninstalling SMW | 1 | 06:11, 31 January 2014 |
Obsolete composer.json in MW 1.22 RC0 and earlier | 1 | 17:28, 17 January 2014 |
Re: Warning: Class '…' not found in … | 10 | 12:51, 10 January 2014 |
Use composer on comandline | 2 | 21:21, 8 January 2014 |
Upgrading from 1.8.x without Shell Access | 3 | 16:40, 7 January 2014 |
MW 1.22 and SMW 1.9beta install/upgrade | 7 | 16:35, 6 January 2014 |
How to migrate to SMWSQLStore3 without shell access? | 13 | 17:27, 1 May 2013 |
Instructions tell to see the "upgrading" section first but there is no longer such a section. What do I need to know?
Wow, yeah, all references to the upgrade section are broken since January 2015. You are the first one to note this. I believe that this is what you are looking for. Cheers
Hmm, or probably this page. The docu appears to be a bit chaotic right now. :| Will have to redo all of this from scratch.
So the general setup of instructions seems to be sorted out now. However, will have a look into the pages to see if fluff is needed.
That one doesn't seem to say anything about updating the composer.local.json file with a newer version before running update. Would that actually update anything? I have been using mediawiki/semantic-media-wiki": "*",
to just get the newest available, but I feel kind of reckless about that, and besides, the earlier part of the page doesn't actually suggest that. Let me know if I should just add it - I would have done the edit if I was sure.
Hmm, the docu links to Help:Upgrade and there you have a list of pages depending from where you start your update/upgrade like e.g. Help:Upgrade/Upgrade_from_SMW_2.5_or_later_and_MW_1.25_or_later
Is it just because of performance concerns? Because then you can still run them when setting up the wiki.
It is an established practice that you run tests (unit or integration) not on a production cluster unless you have a specific task you'd like to verify.
Aside from the mentioned best practice, tests try not to leak any setup information (meaning any data required for the tests) into a test/production database by cloning all tables into a different namespace (prefix) but it may happen (happened in the past as we rely on MW's `CloneDatabase` but I haven't seen it happen as of late).
Product Version MediaWiki 1.30.0 PHP 7.1.8 (apache2handler) MySQL 5.6.34-log Semantic MediaWiki 2.5.5 Apache Jena Fuseki 2.5.0
I used to get results and now nothing is displaying
I was using Product Version MediaWiki 1.28.2 PHP 5.6.25 (apache2handler) MySQL 5.6.34-log Semantic MediaWiki 2.5.5 Apache Jena Fuseki 2.5.0
SPARQL Query Interface gives me an error: [WmDHqtKcgwqPmABhkD@9CwAAAAY] 2018-01-18 16:13:30: Fatal exception of type "Exception"
> SPARQL Query Interface gives me an error: [WmDHqtKcgwqPmABhkD@9CwAAAAY] 2018-01-18 16:13:30: Fatal exception of type "Exception"
"SPARQL Query Interface" is not part of SMW and [0] indicates it to relate to the LinkedWiki extension. As per [0], the issue seems to be solved and you should report back to this site if an issue has been solved to avoid unnecessary volunteer time on issues no longer relevant.
As for the `Fatal exception of type "Exception"`, please review [1] of how to report issues regarding information required for those that involve an "Exception".
[0] https://www.mediawiki.org/wiki/Topic:U5xpncae582kd51l [1] https://www.semantic-mediawiki.org/wiki/Help:Reporting_bugs
Call to undefined function enableSemantics()
to upgrade i had to remove the semantic extensions from the localsettings.php. the update program (MW-config) wouldn't get past "enableSemantics( 'repopnation.com' );" and let me upgrade. So i remove that and the extensions under it to update. Got thru update. Placed the text back into localsettings.php and bamn i get the "Call to undefined function enableSemantics()" on the front page aiming me at that line again.
so for the time being i removed Semantic from the php so my people could at least use part of the wiki.
Did i do something wrong? should i not had bothered to upgrade MW? I couldnt see any steps of how to do the upgrade differently if i used SMW.
please help... thanks!
I've got composer running OK. It was a bit of a battle as I have to run it as a cronjob. Still it seems happy:
- Installing mediawiki/semantic-media-wiki (1.9.1.1) Downloading: connection... Downloading: 100% Extracting archive - Installing mediawiki/semantic-result-formats (1.9.0.1) Downloading: connection... Downloading: 100% Extracting archive Writing lock file Generating autoload files X-Powered-By: PHP/5.3.27 Content-type: text/html
However, when I got to to Special:Version
This is what it says:
Semantic MediaWiki (Version 1.8.0.5)
This is the run-string:
cd www/wiki;php -c etc extensions/Composer/bin/composer update --verbose ;php -c etc extensions/SemanticMediaWiki/maintenance/SMW_refreshData.php -d 50 -v
Hmm ..., do we need instructions on how to uninstall SMW. If yes it should probably go to an extra help page. I think this is a valid question and wonder why this has never been asked before, at least to my knowledge. Cheers
Not really related to SMW therefore went into Remove packages.
Probably not worth to be mentioned on the installation page but MW 1.22 RC0 and earlier versions were shipped (respecticely 1.21.x is still shipped) with a composer.json file in the wiki directory. In case this file still exists when trying to install SMW and other extensions with composer it can cause issues that make using composer impossible.
Yeah, right since it is a MW problem and not a SMW problem it should not be added to the instructions. Additionally it only affects alphas, betas and rcs of MW 1.22. However it is good to have it on the talk page here for others to see. The only thing I wonder about is that you need to create a "composer.json" in that very spot for MW 1.22 anyway? I will not be working with MW 1.22 before probably May or June so I currently cannot check for myself.
I got the same error message with an older version of Validator, but the latest ?stable version produces something like "Fatal error: Validator depends on the ParamProcessor library" (see also mediawiki.org). Commenting out Validator in localsettings.php helps at least to get past the error message, but new ones immediately present themselves at the bottom of the page (internal errors and some messages concerning header information). So should Validator be explicitly evoked or not in this case? What about DataValues?
MW 1.19.7 / SMW 1.9 / SF 1.5.2 / MySQL 5.1.72-2, Php 5.3.3-7
You should not get those dependencies (ie Validator and DataValues) yourself. If you use Composer, they will be installed for you, and you will not have to load them. In case you use the 1.9 tarball, they are included in SMW in the tarball, and loaded by SMW, so again you do not need to load them yourself.
Thanks. As I don't have shell access, I'm using the tarball. Maps and Semantic Maps, on the other hand, require Validator, right? Anyway, commenting out both Validator and DataValues works, except for a couple of errors:
- The web page appears twice, except that the content for the second one contains the message "Invalid job command `SMWUpdateJob`", followed by a backtrace pointing for instance to " .../includes/job/JobQueue.php(189): Job::factory('SMWUpdateJob', Object(Title), false, '5379311')". Perhaps this will sort itself out once a data refresh process is finalised, but it will take some time to find out.
- Secondly, there is an error report at the bottom of the page saying "Warning: Cannot modify header information" - headers already sent by (output started at .../includes/OutputPage.php:1987) in .../includes/WebResponse.php on line 38"
- Thirdly, Semantic Forms no longer works, due to issues concerning "'Serialization of 'Closure'".
Before I make any Bugzilla reports, though, I'll focus first on upgrading to MW 1.22.
I'm not really sure what happens on your site but the issue reported with `SMWUpdateJob` can't happen because we explicitly test this case with [1]. If you have a correct setup then [2] will make sure that both ('SMW\UpdateJob', 'SMWUpdateJob') are available.
[2] https://github.com/SemanticMediaWiki/SemanticMediaWiki/blob/master/SemanticMediaWiki.php#L61
Well, shouldn't but it happens anyway. I've now tried an installation of SMW 1.9.0.1 on MW 1.19.7 (PHP 5.3.3-7+squeeze18 (cgi-fcgi) + MySQL 5.1.72-2), with most of the extensions commented out. (FWIW: This time "Initialize or upgrade tables" fails altogether on the first attempt, but succeeds on the second one.) Just for the sake of comprehensiveness, here's the full error message:
Invalid job command `SMWUpdateJob` Backtrace: #0 [...]/includes/job/JobQueue.php(189): Job::factory('SMWUpdateJob', Object(Title), false, '5392980') #1 [...]/includes/Wiki.php(432): Job::pop() #2 [...]/includes/Wiki.php(409): MediaWiki->doJobs() #3 [...]/includes/Wiki.php(594): MediaWiki->finalCleanup() #4 [...]/includes/Wiki.php(503): MediaWiki->main() #5 [...]/index.php(58): MediaWiki->run() #6 {main}
As for lagacy jobs, see [1].
[1] https://github.com/SemanticMediaWiki/SemanticMediaWiki/pull/86
This is related to Installation. On my WINDOWS 2003 Server using
C:\MYPATH\maintenance>php composer.phar require mediawiki/semantic-media-wiki "1.9.*,>=1.9.0.1" Could not open input file: composer.phar C:\MYPATH\maintenance>
did not work. But
composer require mediawiki/semantic-media-wiki "1.9.*,>=1.9.0.1"
did the job. Composer was installed the INSTALLER way as told here. http://getcomposer.org/doc/00-intro.md#installation-windows
Either one can only install Composer on Windows globally (most likely as it looks in this case) or you installed Composer on Windows globally. Yeah, in this case you must drop the php
and .phar
particles from the command. It is possible to install Composer on e.g. on Linux globally too but the installation manual is indended too which is probably the best way if you have more than one wiki on your machine. The docu is indended to be as basic as possible. That's why I did not want to confuse people with even more steps.
Good anyway that you pointed this out for others.
Since Validator is somehow integrated in SMW 1.9.x ("$IP/extensions/SemanticMediawiki/extensions/Validator/") isn't it recommended or even required to remove the Validator line ("require_once "$IP/extensions/Validator/Validator.php";") that should exist in LS.php from the previous SMW 1.8 installation?
Disclaimer: I ain't any of sysadmin, MW, or SMW expert. This is why I didn't dare creating a new page. On the other hand it seems to work on my test server and production wikis.
After mid-november 2013, you should learn how to use composer, a PHP dependency manager.
Prerequisites
- PHP 5.3.2+
- MySQL 5.0.2+
- CURL (you should have that)
- MediaWiki 1.22 (nov 2013)
Install composer
If you run several wikis, it's probably best to install composer on system level:
cd /some/src curl -sS https://getcomposer.org/installer | php mv composer.phar /usr/local/bin/composer
Prepare for updating SMW
- Go to your MediaWiki installation (NOT the extension directory)
cd /your-mediawiki-install
- If you already got SMW installed, kill it
rm -r extensions/SemanticMediaWiki rm -r extensions/Validator rm -r extensions/DataValues
Changes to Localsettings.php
(1) kill all the lines that load SMW and required extensions. You really have to start clean, for example kill
require_once( "$IP/extensions/DataValues/DataValues.php" ); require_once( "$IP/extensions/Validator/Validator.php" ); include_once("$IP/extensions/SemanticMediaWiki/SemanticMediaWiki.php")
(2) Keep the following:
$smwgNamespaceIndex = 108; // In case other custom extensions were use before. Not necessary for fresh mediawiki installs enableSemantics('edutechwiki.unige.ch'); // adjust to yours
- Make damn sure that
$smwgNamespaceIndex = 108;
is the very first line of code that deals with SMW. E.g. if PHP sees the lineenableSemantics(...)
first, it will start numbering SMW extensions at 104 or something and you won't see your properties, forms, etc. defined in your existing wiki. You then may panic and do weird stuff that won't help your wiki very much.
(3) Comment out all other MediaWiki extensions
(Re)install SMW
- Now get and install SemanticMediaWiki 1.9beta, plus its dependencies with composer
composer require mediawiki/semantic-media-wiki "dev-master"
- In your MediaWiki installations you now will have:
- A vendor directory
- Additions to the extensions directory
- There is no need to edit LocalSetting.php. All extensions will auto-load, i.e. MW 1.22 provides direct support for composer !! However, you later can edit LocalSettings.php to change settings.
(Re)configure SMW
php maintenance/update.php
Kill older SMW extensions
- Kill the following old versions (As of dec 12 2013, other extensions like SemanticForms have to be installed manually)
rm -r extensions/Maps/ rm -r extensions/SemanticMaps/ rm -r extensions/SemanticResultFormats
Install (some) SMW extensions using the composer
composer require mediawiki/maps "dev-master" composer require mediawiki/semantic-maps "dev-master" composer require mediawiki/semantic-result-formats "dev-master"
- LocalSettings.php
- Again, do not add any includes. These files are loaded (I believe) trough vendor/autoload.php
Add other SMW extension through GIT
cd extensions
git clone https://gerrit.wikimedia.org/r/p/mediawiki/extensions/SemanticForms.git
git clone https://gerrit.wikimedia.org/r/p/mediawiki/extensions/SemanticFormsInputs.git
git clone https://gerrit.wikimedia.org/r/p/mediawiki/extensions/SemanticDrilldown.git
git clone https://gerrit.wikimedia.org/r/p/mediawiki/extensions/AdminLinks.git
Of course, you then have to edit LocalSettings.php to include these files, for example it could look like this:
$smwgNamespaceIndex = 108;
enableSemantics('edutechwiki.unige.ch'); // adjust to yours
$smwgShowFactbox = SMW_FACTBOX_NONEMPTY;
// $smwgShowFactbox = SMW_FACTBOX_HIDDEN;
include_once("$IP/extensions/SemanticForms/SemanticForms.php");
# If one or more of your fields can contain internal links entered by users (e.g., "This is a [[cat]]")
$smwgLinksInValues = true;
# Semantic Drilldown. Needs yet another namespace
$sdgNamespaceIndex = 118;
include_once("$IP/extensions/SemanticDrilldown/SemanticDrilldown.php");
# Semantic Forms Inputs
require_once("$IP/extensions/SemanticFormsInputs/SemanticFormsInputs.php");
# AdminLinks
include_once("$IP/extensions/AdminLinks/AdminLinks.php");
Finally, consider refreshing the whole database. You likely messed up something, somwhere:
php SMW_refreshData.php -f -d 50 -v
Looks good to me. I will give it a shot. Just to emphasize: One really needs to use MW 1.22+ since using Composer is frankly imho not an option for earlier versions of MediaWiki. The Extension Installer extension sadly moves all the code into a subdirectory "extensions" of its own directory which will definitively create even more confusion on top of this already very big habitual change. I works but the next upgrade always dreads. :|
Hello Daniel, I used the text in your post to start writing a more complete installation instruction for SMW 1.9 with Composer. It is not ready yet. Regards.
Yeah, these instructions inspired me to create the new page on installing and updating SWM. It is pretty difficult to do since you have to decide with reality to take into account here, e.g. Windows or Linux, shell access / no shell access, the user level etc., etc. So and educated guess what to cater for will always have to be done. You are using a Windows server for your SMW?
Hello. Yes, we are using Windows Server 2008 to run our Wiki's. The coming weeks I want to update MW & SMW and all other extensions. I am almost finished checking what needs to be done so that it works in one go and "nothing" goes wrong :). It is true that there are a lot of ways how to tackle an update but either Windows or Linux when you are using composer it works the same on both, well almost.
Is there a way to migrate to the new store SMWSQLStore3 without using command line / shell?
Up2now I'm still on a shared hosting and don't have command line access...
Thanks.
Hi, and sorry for the delay. Actually, I think you have to ask the good people for this, like Markus Krötzsch, Jeroen De Dauw or Karsten Hoffmeyer. Using SMW 1.7.1, I don't actually have this issue.
Hi Stefahn,
Did you find any solution to your problem ? (I have the same)
Thanks
Nicolas NALLET (Sémantiki)
Hmm, what happens if you generate the new tables via Special:SMW-Admin and trigger a data refresh via the same special page afterwards? Lucky me that I have shell access I guess.
Thanks for the suggestion kgh, but I think it doesn't work.
When I generate new tables it says:
Setting up standard database configuration for SMW ... Selected storage engine is "SMWSQLStore2" (or an extension thereof)
So this doesn't update the SQLStore format it seems.
Any other suggestions?
Probably you added $smwgDefaultStore = 'SMWSQLStore2';
to your LocalSettings.php before doing this.
This worked for me:
- Back up you installation and database
- Set
$wgReadOnly = 'site maintenance';
in your LocalSettings.php - Move the new files for SMW and Validator into the extensions directory
- Go to Special:SMW-Admin and hit "Initialise and upgrade tables"
- Return to Special:SWM-Admin and hit "Start updating data"
- Add
$smwgDefaultStore = 'SMWSQLStore2';
to your LocalSettings.php below the enableSemantics line - Comment out
$wgReadOnly = 'site maintenance';
- After the data refresh is done you do step 2) again
- Comment out
$smwgDefaultStore = 'SMWSQLStore2';
in your LocalSettings.php - Do step 5) again
- Do step 6) again
- Remove
$wgReadOnly = 'site maintenance';
from your LocalSettings.php - After the second data refresh is done you remove
$smwgDefaultStore = 'SMWSQLStore2';
from your LocalSettings.php - Voilà, your are on SMWSQLStore3. Paradise regained. :)
I also posted this to the mailing list.
Finally took the time to check your suggested procedure (thanks for it!).
On my test wiki the procedure worked.
On my "real" wiki it fails - as soon as I uncomment $smwgDefaultStore = 'SMWSQLStore2';
I get the following error message on all pages:
MediaWiki internal error. Original exception: exception 'DBQueryError' with message 'A database error has occurred. Did you forget to run maintenance/update.php after upgrading? See: https://www.mediawiki.org/wiki/Manual:Upgrading#Run_the_update_script Query: SELECT smw_id,smw_sortkey FROM `smw_object_ids` WHERE smw_title = 'Hauptseite' AND smw_namespace = '0' AND smw_iw = '' AND smw_subobject = '' LIMIT 1 Function: SMWSql3SmwIds::getDatabaseIdAndSort Error: 1146 Table 'usr_xy_9.smw_object_ids' doesn't exist (localhost) ' in /var/www/xy/html/secret_wiki/mediawiki/includes/db/Database.php:918 Stack trace: #0 /var/www/xy/html/secret_wiki/mediawiki/includes/db/Database.php(885): DatabaseBase->reportQueryError('Table 'usr_web1...', 1146, 'SELECT smw_id,...', 'SMWSql3SmwIds::...', false) #1 /var/www/xy/html/secret_wiki/me... ... ...
I tried to run the update script (via webinstaller) but it gives me a white screen after the first step.
On my test wiki there was also an error message (at least on the front page) when I uncommented $smwgDefaultStore = 'SMWSQLStore2';
(between steps 3 and 4 if you like).
But this error was only shown in the content area and said something like: "MySQL error - couldn't access table smw_objects_id..."
Any help? Thanks!