Wikimedia Bugzilla is closed!

I suspect your path config is incorrect. Have a look at your $wgServer, $wgScriptPath and $wgStylePath settings.

You can also try running without SRF. At least one error seems specific to SRF, and likely caused by using SRF 1.8 with SMW 1.9, which will not work.

(In reply to comment #0)
> Catchable fatal error: Argument 3 passed to
> SMW\SubobjectParserFunction::__construct() must be an instance of
> SMW\MessageFormatter, none given, called in
> C:
> \xampp\htdocs\wiki\eva\extensions\SemanticInternalObjects\SIO_SubobjectAlias.
> php
> on line 63 and defined in
> C:
> \xampp\htdocs\wiki\eva\extensions\SemanticMediawiki\includes\parserhooks\Subo
> bjectParserFunction.php
> on line 40
> 

When using additional extensions like SemanticInternalObjects, please make sure to use the latests available version (preferably from git master) because the above error indicates an out-of-date SIO.

Updating SIO didn't seem to work, and I didn't see any issues with $wgServer, $wgScriptPath or $wgStylePath...so I decided to start from scratch. I created a new install of MW 1.22.0rc3 and ran through the installer. I got one notice after install, before login. See https://bugzilla.wikimedia.org/show_bug.cgi?id=56269#c16 for more info on that. Once I logged in I didn't see any issues.

I ran "php composer.phar require mediawiki/semantic-mediawiki dev-master" which worked without any issues. 

On Main Page I get the following three console errors:

[1]   GET http://localhost/wiki/extensions/SemanticMediaWiki/resources/images/smw_button.png 404 (Not Found) Main_Page:177
[2]   GET http://localhost/wiki/extensions/SemanticMediaWiki/resources/images/smw_button.png 404 (Not Found) Main_Page:177
[3]   event.returnValue is deprecated. Please use the standard event.preventDefault() instead.   load.php?debug=false&lang=en&modules=jquery%2Cmediawiki&only=scripts&skin=vector&version=20131130T1…:48

[1] and [2] are the same. On Special:Version I get it a third time.

At this point I realized I hadn't initialized SMW yet, so I did that. Now the smw_button error only happens once on both Main Page and Special:Version. Error [3] still occurs. The SMW logo at the bottom right of the page is not showing.

Later tonight or tomorrow I'll continue by adding more extensions one-by-one and seeing if the original errors come back.

(In reply to comment #3)
> [1]   GET
> http://localhost/wiki/extensions/SemanticMediaWiki/resources/images/
> smw_button.png
> 404 (Not Found) Main_Page:177
> [2]   GET
> http://localhost/wiki/extensions/SemanticMediaWiki/resources/images/
> smw_button.png
> 404 (Not Found) Main_Page:177
> [3]   event.returnValue is deprecated. Please use the standard
> event.preventDefault() instead.  
> load.
> php?debug=false&lang=en&modules=jquery%2Cmediawiki&only=scripts&skin=vector&v
> ersion=20131130T1…:48

This is a non-related SMW issue, please see [1] which is probably caused by using MW 1.22.0rc3. I think it would be best to use MW 1.21 until 1.22 is officially released in order to avoid correlating issues. 

[1] http://bugs.jquery.com/ticket/14282 and http://bugs.jquery.com/ticket/14320

Agreed that [3] is a MW problem. I'm not so sure about [1]. I've yet to get SMW 1.9 up and running on MW 1.21 because Composer isn't built in and ExtensionInstaller is giving me some problems. But I've tried it on MW 1.22 and master at this point. 

Is it possible that in SemanticMediaWiki.settings.php on line 33 where $GLOBALS['smwgScriptPath'] is set based on $wgScriptPath, that it get the wrong value for $wgScriptPath? It appears that my $GLOBALS['smwgScriptPath'] is getting set based on the default value of $wgScriptPath instead of the value I have specified in LocalSettings.php.

The smwgScriptPath code looks correct. Do note that you need to include the ExtensionInstaller before you set any extension settings in your LocalSettings file.

INSTALL.md [1] says that ExtensionInstaller needs to be installed for MW 1.21 and lower. Is it required for 1.22 and 1.23 as well?

[1] https://github.com/SemanticMediaWiki/SemanticMediaWiki/blob/master/docs/INSTALL.md#download-and-installation

Created yet another wiki starting from scratch, but checking out tags/1.21.3 in git. Here are my notes:

Went to Special:Version, verified no console errors. Verified MW 1.21.3 (54f7112).

git clone https://github.com/JeroenDeDauw/ExtensionInstaller.git

Edit LocalSettings.php, add at the end:
require_once( "$IP/extensions/ExtensionInstaller/ExtensionInstaller.php" );

Refresh Special:Version, verified ExtensionInstaller installed.

It's not clear to me at this point whether for 1.21 I'm supposed to put composer.phar in MW install directory or in ExtensionInstaller directory. From the ExtensionInstaller README.md I believe it's supposed to go in the ExtensionInstaller directory, so that's what I did.

Put composer.phar in ExtensionInstaller directory

Renamed example.json to composer.json, and added the following line within the require object:
"mediawiki/semantic-mediawiki": "dev-master"

cd to ExtensionInstaller directory, run "php composer.phar install"

Refresh Special:Version. Verified SMW 1.9 installed, along with 7 DataValues extensions, ExtensionInstaller, and Validator. Still have the following error: 
GET http://localhost/wiki/oso/extensions/SemanticMediaWiki/resources/images/smw_button.png 404 (Not Found) Special:Version:272

This error is very slightly different from before. Now it is properly using the correct $wgScriptPath, whereas with MW 1.22+ it was leaving out the directory following "wiki" (in this case "oso"). However, it appears that with ExtensionInstaller SMW isn't installed within extensions/SemanticMediaWiki, but instead within ExtensionInstaller/extensions/SemanticMediaWiki, so smw_button can be found at http://localhost/wiki/oso/extensions/ExtensionInstaller/extensions/SemanticMediaWiki/resources/images/smw_button.png

> INSTALL.md [1] says that ExtensionInstaller needs to be installed for MW 1.21
> and lower. Is it required for 1.22 and 1.23 as well?

no

> with ExtensionInstaller SMW isn't installed within extensions/SemanticMediaWiki, but
> instead within ExtensionInstaller/extensions/SemanticMediaWiki

Indeed, I can confirm this. Will try to find a fix for that.

I guess you can still fix this now by setting smwgScriptPath to the appropriate value.

I modified the ExtensionInsaller to install the extensions and libraries on the same location as they would be via MW 1.22 installation.

Add the "config" and "extra" sections that are now in the example.json file to your composer.json file and run composer update.

https://github.com/JeroenDeDauw/ExtensionInstaller/blob/master/example.json

(In reply to comment #10)
> I guess you can still fix this now by setting smwgScriptPath to the
> appropriate
> value.

So to make SMW work with MW1.22+ (and therefore without ExtensionInstaller), if I have a value of $wgScriptPath other than the default "/wiki", then I also have to set $smwgScriptPath to something like "$wgScriptPath/extensions/SemanticMediaWiki" in LocalSettings.php?

I feel like SMW should be able to determine $smwgScriptPath from $wgScriptPath without additional setup.

Does MW1.22+ load extensions with Composer before it loads LocalSettings.php?

> I feel like SMW should be able to determine $smwgScriptPath from $wgScriptPath
without additional setup.

It does. And now it does so correctly when using ExtensionInstaller and when not using it. So my earlier suggestion is now void.

This morning I tested it on MW 1.19.9, 1.20.8, 1.21.3 with success. 1.22.0rc3 and 1.23alpha (8165ecd) are still giving me the smw_button.png error. Each test was installed identically using the setup script, and only deviated when I got to Composer. For 1.19, 1.20, and 1.21 I did the following:

(1) In /extensions do: 
    git clone https://github.com/JeroenDeDauw/ExtensionInstaller.git
(2) Add to the bottom of LocalSettings.php:
    require_once( "$IP/extensions/ExtensionInstaller/ExtensionInstaller.php" ); 
(3) Copy "composer.phar" into /extensions/ExtensionInstaller 
(4) Rename "example.json" to "composer.json"
(5) Add to "composer.json": 
    "mediawiki/semantic-mediawiki" : "dev-master"
(6) In ExtensionInstaller directory, run "php composer.phar install"

For 1.22 and 1.23 I did:
(7) Add "composer.phar" into MW install directory
(8) From MW install directory, run:
    "php composer.phar require mediawiki/semantic-mediawiki dev-master"

With 1.19, 1.20, and 1.21 I'm not getting any console messages in Chrome, so the ExtensionInstaller fix appears to have worked. I have not actually run anything from Special:SMWAdmin yet, so I can't comment on full functionality, but this bug appears to be gone.

With 1.22 and 1.23 I'm still getting the "smw_button.png 404 (Not Found)" Chrome console message, so I believe $smwgScriptPath is still not being set properly.

It is possible that for 1.22 something went wrong with my SMW install because I see that on packagist.org SMW was updated at 2013-12-02 15:31 UTC, and I may have been running composer around that time. For 1.23 I'm sure I ran composer after that time. Composer does get files from packagist, right?

Regarding my previous comment about which version of SMW got installed:

Special:Version shows that on MW 1.20 and 1.21 I got 24c2b59 and on 1.22 and 1.23 I got c4801eb. MW 1.19 doesn't show it in Special:Version.

c4801eb corresponds to what is currently on Packagist and Github.

There was another issue causing resources not to be loaded. I ran into this when updating SMW wiki to use the ExtensionInstaller.

To fix, update the package name in composer.json to semantic-media-wiki (note the extra dash) and run composer update.

Apologies for all the hassle, and thanks for the feedback!

The problem for MW 1.22 is that in previous versions $wgScriptPath was already set with the customized path which allowed [1] to be set correctly. Apparently in 1.22 this not the case $wgScriptPath contains the standard "/wiki" at the time [0] is loaded resulting $smwgScriptPath containing "/wiki" rather than the expected path from $wgScriptPath.

[0] SemanticMediaWiki.settings.php

[1] $GLOBALS['smwgScriptPath'] = ( $GLOBALS['wgExtensionAssetsPath'] === false ? $GLOBALS['wgScriptPath'] . '/extensions' : $GLOBALS['wgExtensionAssetsPath'] ) . '/SemanticMediaWiki';

@Jeroen: In my MW 1.23 installation I changed composer.json as you said, then ran "php composer.json update". I got:

Your requirements could not be resolved to an installable set of packages.

Problem 1
- Installation request for mediawiki/semantic-media-wiki dev-master -> satisfiable by mediawiki/semantic-media-wiki[dev-master].
- Removal request for mediawiki/semantic-mediawiki == 9999999-dev

No worries about the hassle. I was trying to install SMW 1.9 for the purpose of helping out...I just didn't expect to get stuck at install.


@MWJames: Is this because the integrated Composer support in 1.22+ causes extensions to be loaded prior to LocalSettings.php? I added "echo 'SMW';" to SemanticMediaWiki.settings.php and "echo 'MW';" to LocalSettings.php and when I refresh I get "SMW MW" in the top right of the page...

In order to verify if the Composer install on MW 1.22 distorts the smwgScriptPath setting, I added an additional system test to [1].

I would help us if you could run the unit tests from [1] on MW 1.19, 1.20 and MW 1.22 and report possible issues.

[1] https://github.com/SemanticMediaWiki/SemanticMediaWiki/tree/tests

Regarding making the "semantic-mediawiki" to "semantic-media-wiki" change, to get around the "Your requirements could not be resolved..." message I had to:

(1) delete composer.lock
(2) delete the "Validator" and "SemanticMediaWiki" directories from extensions
(3) make the change to composer.json
(4) run "php composer.phar install"

(In reply to comment #17)
> The problem for MW 1.22 is that in previous versions $wgScriptPath was
> already
> set with the customized path which allowed [1] to be set correctly.
> Apparently
> in 1.22 this not the case $wgScriptPath contains the standard "/wiki" at the
> time [0] is loaded resulting $smwgScriptPath containing "/wiki" rather than
> the
> expected path from $wgScriptPath.
> 
> [0] SemanticMediaWiki.settings.php
> 
> [1] $GLOBALS['smwgScriptPath'] = ( $GLOBALS['wgExtensionAssetsPath'] ===
> false
> ? $GLOBALS['wgScriptPath'] . '/extensions' :
> $GLOBALS['wgExtensionAssetsPath']
> ) . '/SemanticMediaWiki';

Travis-CI [1] shows a failing unit test [2] only when MW (master/1.23) is installed via Composer.

testSemanticMediaWikiScriptPath tests above smwgScriptPath/wgScriptPath setting which is causing [3] due to wrongful assignment of /wiki as part of the $smwgScriptPath.

[1] https://github.com/SemanticMediaWiki/SemanticMediaWiki/pull/39

[2] https://github.com/SemanticMediaWiki/SemanticMediaWiki/blob/42d45ed81f3c554740124b6be5dd7cc488e55e3d/tests/phpunit/system/InstallationSettingsTest.php

[3] http://localhost/wiki/extensions/SemanticMediaWiki/resources/images/smw_button.png

James, are you sure the issue is with SMW, and now with how we have TravisCI set up the wiki? I set up a wiki with the same commands as TravisCI a few times, and LocalSettings.php ended with with "wiki" as path while I was installing under "mw".

Based on the current setup, I can only conclude that tests running via git install are passed where [0] fails when using the Composer.

One can easily check the output in [1] with var_dump(  $GLOBALS['wgScriptPath'] ) which returns "/wiki" which should in fact hold "/TravisWiki".

The reason why the test do pass for the manual install is that when [1] is loaded $GLOBALS['wgScriptPath'] contains /TravisWiki but when using the Composer install $GLOBALS['wgScriptPath'] contains /wiki and only at the later point is set correctly which is to late because [1] has already invoked $GLOBALS['smwgScriptPath'].

[0] is testing the invoked value of $GLOBALS['smwgScriptPath'] against the available $GLOBALS['wgScriptPath'].

The issue is that when [1] is loaded $GLOBALS['wgScriptPath'] contains the default "/wiki" and not the expected "/TravisWiki" value which is the reason why images can't be found ($GLOBALS['smwgScriptPath'] is pointing to /wiki instead of the expected value). Resources as well rely on $GLOBALS['smwgScriptPath'] to be set correctly.

[0] InstallationSettingsTest.php

[1] SemanticMediaWiki.settings.php

Ok, great analysis. Just checked the code in WebStart.php, and indeed, LS is getting loaded after the Composer autoloader. This means we cannot use config yet at the time of entry point inclusion and have to wait till a later point. Putting the smwgScriptPath assignment in a handler to the wfExtensionsFunctions thing will probably work.

*** Bug 57923 has been marked as a duplicate of this bug. ***

Also reported by Niklas Laxström (see 57923)

* $smwgNamespaceIndex defined in my LocalSettings.php ignored
* $wgExtensionAssetsPath variable is inspected even before
LocalSettings.php is executed

Sorry, didn't notice you already have a bug for this.

I'm kind of stuck at translatewiki.net on this issue, as I cannot update some extensions because they now require composer, but installing them from composer doesn't currently work.

Workaround for SMW for now if you're having problems due to non-default $wgScriptPath is to explicitly set $smwgScriptPath in LocalSettings.php. So I added the following prior to loading any extensions in LocalSettings.php, but after I set $wgScriptPath:

$smwgScriptPath = $wgScriptPath.'/extensions/SemanticMediaWiki';

(In reply to comment #24)
> Ok, great analysis. Just checked the code in WebStart.php, and indeed, LS is
> getting loaded after the Composer autoloader. This means we cannot use config
> yet at the time of entry point inclusion and have to wait till a later point.
> Putting the smwgScriptPath assignment in a handler to the
> wfExtensionsFunctions
> thing will probably work.

Question:

LocalSettings requires [1] to be set, is [2] necessary in the composer.json because of the autoload option SemanticMediaWiki.php is loaded before LocalSettings.php

[1] include_once("$IP/extensions/SemanticMediaWiki/SemanticMediaWiki.php");
 
[2] 	"autoload": {
		"files" : [
			"SemanticMediaWiki.php"
		]
	}

James: [1] is not needed, and in fact not supported as far as I'm concerned. The user should not have to care where which entry point is and for which components they should be included. Perhaps we should move it to make this more explicit.

Ok, the $smwgNamespaceIndex stuff cannot be fixed easily. Looks like we will need to break compatibility is some way.

$smwgNamespacesWithSemanticLinks is initialized in the settings file, and is expected to be there after loading SMW, so people can add to it in LocalSettings. It initialization depends on our namespace consonants though, which in turn depend on $smwgNamespaceIndex. In other words, the current behaviour supports setting things before and after the inclusion of SMW in LocalSettings. That can no longer happen as inclusion now happens outside of LocalSettings, and thus either needs to happen before or after. Now it is before as otherwise extension settings would not be fined in time for the user to alter them.

For $smwgNamespaceIndex I just submitted a commit that fixes the behaviour at the cost of smwgNamespacesWithSemanticLinks compatibility. https://github.com/SemanticMediaWiki/SemanticMediaWiki/pull/40

The PR now also includes a fix for smwgScriptPath.

Merged my PR into the one adding the extra test. Think the issue has now been resolved.

https://github.com/SemanticMediaWiki/SemanticMediaWiki/pull/39

Right now I'm unable to provide a false/positive test on Travis-CI (testExtraNamespacesOnTravisNamespace [1]) because I can't get Travis to behave as it is does locally but with the above change and the proposed solution [1] the unit test fails and doing a on-wiki hand-to-hand test fails equally because:

When the Composer is autoloading SemanticMediaWiki.php it is registering a $GLOBALS['wgExtensionFunctions'][] = function() {  SMW\Setup ... } which is executed before the LocalSettings [2] which means that by the time LocalSettings adjusts the values of $smwgNamespacesWithSemanticLinks, values have been already invoked in SMW\Setup. This means that any behavioral change in LocalSettings that is put into a function() {  ... } is executed after SMW\setup is run and therefore is not recognised by SMW.

[1] https://github.com/SemanticMediaWiki/SemanticMediaWiki/tree/tests

[2] $GLOBALS['wgExtensionFunctions'][] = function() {
	$GLOBALS['smwgNamespacesWithSemanticLinks'] = array( ... )
}

> any behavioral change in LocalSettings that is put into a
> function() {  ... } is executed after SMW\setup is run

Yeah, that is the expected behaviour.

> therefore is not recognised by SMW.

Why not? This is still before any SMW logic uses the globals or initializes something with them no?

(In reply to comment #36)
> > therefore is not recognised by SMW.
> 
> Why not? This is still before any SMW logic uses the globals or initializes
> something with them no?

No, the LocalSettings function { ... } is called after the SMW initialization causing a deviation, this is what the test case [1] is for. Because the values initialized by LocalSettings function { ... } and that known to SMW are different. [1] was wrote with the objective in mind to verify that at moment SMW\Setup initializes it has the default and the adopted values from LocalSettings available to execute SMW\Setup.

The whole Settings stuff (default vs custom) is becoming really tricky now due to a different loading priority (because of when defaults are loaded) therefore extra care needs to be put forward to those edge cases and [2] didn't solve the problem as [1] failed.

For example, you need to run smwfInitNamespaces() within SMW's function { ... } because needs $smwgNamespaceIndex to be known but that can only happen after after the LocalSettings initialization otherwise SMW_NS_PROPERTY can be defined and only than $smwgNamespacesWithSemanticLinks can contain default values including SMW_NS_PROPERTY.

[1] https://github.com/SemanticMediaWiki/SemanticMediaWiki/pull/45

[2] https://github.com/SemanticMediaWiki/SemanticMediaWiki/pull/40

[0] was merged and should resolve reaming issues due to the use of the Composer install.

Further more, [0] introduces additional tests [1] to verify settings behaviour for a Composer and non-Composer install.

Against earlier suggestions, no changes are required in how to maintain [2] but namespaces like (SMW_NS_PROPERTY, SMW_NS_TYPE, SF_NS_FORM, SMW_NS_CONCEPT etc.) are banned from being defined in LocalSettings due to late assignment that happens when [3] is executed, all other namespace properties (standard and custom NS) can be assigned freely in LocalSettings using [2]. 

Travis simulates a MW related Composer install with the following example data [4].

[0] https://github.com/SemanticMediaWiki/SemanticMediaWiki/pull/46

[1] https://github.com/SemanticMediaWiki/SemanticMediaWiki/blob/master/tests/phpunit/system/InstallationSettingsTest.php

[2] $GLOBALS['smwgNamespacesWithSemanticLinks'] = array( ... )

[3] https://github.com/SemanticMediaWiki/SemanticMediaWiki/blob/master/includes/NamespaceCustomizer.php

[4] https://github.com/SemanticMediaWiki/SemanticMediaWiki/blob/master/build/travis/before_script.sh#L67

James, modification of things using the namespace consonants still needs to be delayed. I updated SMW wiki to SMW master just now, and things broke because localSettings was using these constants immediately.

I had to do this to address the issue, and presumably there are quite a few more settings in which those constants might be used, and that thus need to be modified at a later point.

$wgExtensionFunctions[] = function() {
        global $wgContentNamespaces;
        $wgContentNamespaces = array( NS_MAIN, NS_HELP, NS_CATEGORY, SMW_NS_PROPERTY, SMW_NS_TYPE, SMW_NS_CONCEPT );

        // setup namespace search
        global $wgNamespacesToBeSearchedDefault;
        $wgNamespacesToBeSearchedDefault[NS_HELP] = true;
        $wgNamespacesToBeSearchedDefault[SMW_NS_TYPE] = true;
        $wgNamespacesToBeSearchedDefault[SMW_NS_PROPERTY] = true;

        // setup namespace protection for documentation
        global $wgNamespaceProtection;
        $wgNamespaceProtection[NS_HELP] = array('docu');
        $wgNamespaceProtection[SMW_NS_TYPE] = array('docu');
        $wgNamespaceProtection[NS_PROJECT] = array('docu');

        return true;
};

In case those settings are SMW specific, I'm guessing we run into the earlier issue again, where SMW starts using the config before the delayed modification in LS happens.

I created a fresh bug for this, else this one will turn into "all things related to Composer somehow". https://bugzilla.wikimedia.org/show_bug.cgi?id=58182

(In reply to comment #39)
> James, modification of things using the namespace consonants still needs to
> be
> delayed. I updated SMW wiki to SMW master just now, and things broke because
> localSettings was using these constants immediately.

Good catch, needs proper documentation since the SNW-NS constants [0] are delayed due to $smwgNamespaceIndex being a prerequisite and its initialization has to happen first before [1] can be processed.

Configurations like [2] related to [0] should be delayed using [3].
 
$smwgNamespacesWithSemanticLinks should not be delayed and should not hold a [0] reference otherwise [4] will be displayed.

[0] SMW_NS_PROPERTY, SMW_NS_TYPE, SMW_NS_CONCEPT 

[1] SMW\NamespaceCustomizer 

[2] Known configuration that can hold a SMW NS reference $wgContentNamespaces, $wgNamespacesToBeSearchedDefault and $wgNamespaceProtection

[3] $GLOBALS['wgExtensionFunctions'][] = function() {

	// Add settings relevant for after SMW intialization

	$GLOBALS['wgNamespacesToBeSearchedDefault'] = array(
		SMW_NS_PROPERTY => true,
	);

}

[4] Notice: Use of undefined constant SMW_NS_PROPERTY

See [1] for further instructions on how to avoid issues in LocalSettings when using SMW-NS related configurations.

[1] https://bugzilla.wikimedia.org/show_bug.cgi?id=58182#c4

[2] http://semantic-mediawiki.org/wiki/Thread:Help_talk:Installation/MW_1.22_and_SMW_1.9beta_install/upgrade