Thanks for testing.

This is probably caused by a manual installation (meaning not using the composer) where some misplaced dependencies on either the Validator or Data Values packages is causing the error. Let's see what Jeroen has for suggestions to resolve this issue.

mitchell_neill wrote:

Thanks for your quick reply.

FYI, the rest of the install is the latest SMW 1.8.5 Bundle.

As you say, I guess there is some new dependency that should be easy to fix and then can be documented. Also need to add Data Values to the dependency list in the doc.

Thanks.

mitchell_neill wrote:

I have the latest revision of DataValues installed - 100fd4a.

Cheers.

I got tired of MW's inability to handle extension dependencies therefore nowadays I pull the SMW master from git and run "composer install" or "composer update" which handles all the necessary dependencies.

mitchell_neill wrote:

Hi.

I also pulled SMW master from git, but I can't see those scripts. Where do I get them from? I guess this needs documenting.

Thanks.

After installing the composer (see [1]), the only thing left is:

• git clone https://github.com/SemanticMediaWiki/SemanticMediaWiki/ or (git clone https://git.wikimedia.org/git/mediawiki/extensions/SemanticMediaWiki.git)

• cd SemanticMediaWiki

• composer install

That's it.

[1] http://getcomposer.org/

(In reply to comment #6)

• git clone https://github.com/SemanticMediaWiki/SemanticMediaWiki/ or (git

clone
https://git.wikimedia.org/git/mediawiki/extensions/SemanticMediaWiki.git)

• cd SemanticMediaWiki

• composer install

The same procedure is used by the Travis-CI unit test environment, meaning that any issue with dependencies is visible during testing therefore I strongly suggest to install dependencies via the composer otherwise the likelihood that one does install a non-compatible extensions (or out-of-date) is increased.

mitchell_neill wrote:

That's pretty neat :)

However, still getting the same error. So I guess I now have the latest versions, but there is an actual bug somewhere with these revisions.

Thanks.

Re. composer. How would people without console access to their servers do this?

We provide tarballs for releases that include all the dependencies. This will be done as soon as we hit the first RC.

Can you check if DataValues is actually loaded (by checking Special:Version)? The class the error says is missing definitely exists...

mitchell_neill wrote:

Hi.

Yes, DataValues is definitely loaded as is DataValuesCommon and DataValuesInterfaces.

I've run grep and the class is defined in DataValues/DataValuesCommon/src/ValueValidators/RangeValidator.php

An erroneous path definition somewhere perhaps?

mitchell_neill wrote:

Okay I think I've been running more tests.

I did a clean bare SMW 1.9 beta1 install. It all works.

I did a clean bare SMW 1.8 bundle install. It fires up fine.

I then upgrade the 1.8 instance to 1.9 beta1 by copying the all the SMW extensions from the working 1.9 beta1 instance. Special:Version shows the same versions of these components as the working 1.9 beta1 instance.

SMW_setup.php runs okay. Then as before, SMW_refreshData.php and the site itself throws the error.

This would seem to indicate that there is either something about the bundle environment that causes the break, or a component that does not upgrade cleanly.

Perhaps another extension (SF, Maps etc) is calling RangeValidator?

mitchell_neill wrote:

Okay, further tests.

I took the working clean SMW 1.9 beta1 install and added the SMW 1.8.0.5 bundle components. All the SMW 1.9 beta1 components were left as is.

The wiki then fails in the same way, but this is the interesting bit. It only failed after I started adding some pages with properties via a SF form/template.

mitchell_neill wrote:

Oh dear, this looks like it might be more serious than an install issue.

I thought that if I the problem is upgrading a 1.8.0.5 instance to 1.9 beta1, perhaps we'll try it the other way round.

I re-instated the bare SMW 1.9 beta1 MW 1.21.2 instance. It all works fine.

I then exported pages, properties, forms and template from the 1.8.0.5 instance via Special:Export

I import into the bare 1.9 beta1 instance via Special:Import. After a number of seconds the import fails with the same error:
Fatal error: Class '\ValueValidators\RangeValidator' not found in /var/www/webapps/smw_19_testing/extensions/Validator/includes/ParamProcessor/ParamDefinitionFactory.php on line 181

Some properties and forms have imported. I try importing a smaller number of pages. Get the same error.

Something not right here guys.

Change 94176 had a related patch set uploaded by Mwjames:
(Bug 56663) Add PageAnnotationImportIntegrationTest

https://gerrit.wikimedia.org/r/94176

(In reply to comment #14)

Change 94176 had a related patch set uploaded by Mwjames:
(Bug 56663) Add PageAnnotationImportIntegrationTest

https://gerrit.wikimedia.org/r/94176

This change is not linked to the 'ValueValidators\RangeValidator' issue but since you mentioned the XML import, the above test adds a simple sanity check by running an XML import during unit testing to verify that the Import. The test deploys its own XML import file which will be checked each time a test is executed.

For the current master the test could not find any issue with importing an XML.

mitchell_neill wrote:

Hi.

I'm was simply using the import to populate the instance for testing. I am not suggesting there is a problem with the XML import itself. Sorry if I was not clear on this.

Good to see another test case being added to the suite though. This can only be useful going forward.

Going back to a clean 1.9 beta1 instance, the error starts occurring as soon as I populate the site, be that manually or via importing properties, forms and templates from another instance.

So to sum up the position we are currently at. I get this error with a cleanly installed SMW 1.9 beta1 instance once pages that add property values are added to it. This is the crux of this bug report now.

As for my part, I can't replicate the error (I tried MW 1.19 and MW 1.23, no bundle but with SF). Looking at [1] and [2] both running the most recent version and have not reported any issue as described in this bug therefore right now I can't offer any additional advice.

[1] http://translatewiki.net/wiki/Special:Version

[2] http://wikiapiary.com/wiki/Special:Version

Change 94176 merged by jenkins-bot:
(Bug 56663) Add PageAnnotationImportSystemTest

https://gerrit.wikimedia.org/r/94176

mitchell_neill wrote:

Those sites are running different versions of either MW or SMW. You also don't have my test case data.

I am testing the 1.9 beta1 version as asked on the mailing list against the latest production version of MW.

This issue can be easily replicated. I can provide an XML import file that demonstrates this error every single time if these versions are used. I can also provide access to an instance that demonstrates this problem.

(In reply to comment #19)

This issue can be easily replicated. I can provide an XML import file that
demonstrates this error every single time if these versions are used. I can
also provide access to an instance that demonstrates this problem.

Maybe I would be a good I idea to attach the XML in question to this bug.

mitchell_neill wrote:

XML export demonstrating the problem

Import into an instance running the following versions:

MW 1.21.2
SMW 1.9 beta1 rev 0a8b911
Validator rev 0983f53
DataValues rev b4674ef

git revisions as of 7th Nov 2013

Attached:

mitchell_neill wrote:

Installation details:

Ubuntu server 12.04.3 LTS running on dedicated HP ProLiant DL380.

Installation steps I have been taking:

Completely wipe any previous instance and database.
tar -xvzf mediawiki-1.21.2.tar.bz

Run through MW installation process via browser.

cd extensions
git clone https://git.wikimedia.org/git/mediawiki/extensions/SemanticMediaWiki.git
git clone https://git.wikimedia.org/git/mediawiki/extensions/Validator
git clone https://git.wikimedia.org/git/mediawiki/extensions/DataValues

cd maintenance
php SMW_setup.php - no errors

Login to wiki.
Special:Import file. Get error.

I've also tried:

Wipe instance and database
tar -xvzf mediawiki-1.21.2.tar.bz

Run through MW installation process via browser.

cd extensions
git clone https://git.wikimedia.org/git/mediawiki/extensions/SemanticMediaWiki.git
composer install

cd maintenance
php SMW_setup.php - no errors

Login to wiki.
Special:Import file. Get error.

Also tried https://github.com/SemanticMediaWiki/SemanticMediaWiki/archive/1.9beta1.tar.gz tarball in Jeroen's beta testing request email.

Not doing anything fancy here. Unless I am missing some step.

(In reply to comment #21)

Created attachment 13732 [details]
XML export demonstrating the problem

The issue could not be detected while importing on:

MediaWiki 1.19.7, PHP 5.4.7
Semantic MediaWiki (Version 1.9 beta-1)
Validator (ParamProcessor) (Version 1.0 beta)
DataValues (Version 0.1 alpha)

MediaWiki 1.23alpha (cb8823c) PHP 5.4.7
Semantic Forms (Version 2.5.3) (e0016f5)
Semantic MediaWiki (Version 1.9 beta-1) (0a8b911)
Semantic Result Formats (Version 1.9 alpha) (10b2bb7)
DataValues (Version 0.1 alpha) (f90675f)
Validator (ParamProcessor) (Version 1.0 alpha) (3ae0a87)

All imports do finish with "Import finished!"

If the XML is added to the PageAnnotationImportSystemTest, the import works as expected. (for demonstration purpose only [1]).

[1] https://gerrit.wikimedia.org/r/#/c/94333/

Attached:

mitchell_neill wrote:

Hi.

Thanks for testing. Good progress :) I think we can now safely say that this is some kind of installation or environment issue.

Were these clean bare installs or pre-populated running instances? We need to rule out any dependency that is being fulfilled by instances that are already running correctly.

I'll try this on a server running PHP 5.4.7 to rule out that difference. I'll then try MW 1.19.7 to rule that out.

Let's also go back to first principles. What are the possible reasons the class is not being found? Is there extra debugging we can turn on to narrow this down?

mitchell_neill wrote:

Okay. I have found the problem.

I zipped up the failing instance and ran it up on a machine running PHP 5.4.6 and it works.

The server where this is not working is running the LTS PHP version 5.3.2, which is also the min spec for MW 1.21.2. SMW 1.9 release notes also state that 5.3.2 is min spec.

So we need to figure out what is causing the break and what can be done as 5.3.2 is still very widely used. Hopefully this is some kind of simple path definition issue.

Demonstrates the value of regression testing :)

Our CI is running the tests with PHP 5.3.26.

Neill: could you run the SMW tests on the box where you encounter problems and see if they pass? If they do not, please provide the error output.

TravisCI does not support running it against 5.3.2.

I just verified the problematic line is hit by the tests, and it is, so output of the tests on an actual 5.3.2 box would be very helpful.

mitchell_neill wrote:

Sure, no problem. How do I run the tests?

cd your-mw-install/tests/phpunit
php phpunit.php --group SMWExtension

mitchell_neill wrote:

HI.

It doesn't run. Throws the error:

Fatal error: require_once(): Failed opening required 'PHPUnit/Runner/Version.php' (include_path='.:/usr/share/php:/usr/share/pear') in /var/www/webapps/SMW_Testing/tests/phpunit/phpunit.php on line 101

mitchell_neill wrote:

Oh of course. The version of phpunit that is required is not supported on the LTS box due to Pear version dependencies.

Okay, setup a VMWare testing instance with php 5.3.2 and phpunit 3.6.10. Test now runs. Here is the output:

PHP Fatal error: Class '\ValueValidators\RangeValidator' not found in /var/www/webapps/SMW_Testing/extensions/Validator/includes/ParamProcessor/ParamDefinitionFactory.php on line 181

Fatal error: Class '\ValueValidators\RangeValidator' not found in /var/www/webapps/SMW_Testing/extensions/Validator/includes/ParamProcessor/ParamDefinitionFactory.php on line 181

Can you run with the --log-tap /some/file.name option and attach the file here?

To late now I guess, but you can "install" PHPUnit quite easily: https://github.com/sebastianbergmann/phpunit/#installation

mitchell_neill wrote:

Hi.

Okay, I ran php phpunit.php --log-tap /home/mitchelln/SMW_test.out --group SMWExtension

But no log file was produced :(

If I run php phpunit.php --tap --group SMWExtension it produces:
TAP version 13
PHP Fatal error: Class '\ValueValidators\RangeValidator' not found in /var/www/webapps/celestialwiki/extensions/Validator/includes/ParamProcessor/ParamDefinitionFactory.php on line 181

Fatal error: Class '\ValueValidators\RangeValidator' not found in /var/www/webapps/celestialwiki/extensions/Validator/includes/ParamProcessor/ParamDefinitionFactory.php on line 181

php phpunit.php --version

Can you also verity you are actually running master of Validator? Line 181 does not make sense on master.

mitchell_neill wrote:

phpunit is version 3.6.10. I also tried it on the php 5.4.6 box it doesn't produce a log file there either, just console output.

It was definitely the master as of a week ago. We are always going to be aiming at a moving target here is we are not careful. I just did a git pull to revision 4a7ef92 and the error is now on line 154.

Fatal error: Class '\ValueValidators\RangeValidator' not found in /var/www/webapps/SMW_Testing/extensions/Validator/includes/ParamProcessor/ParamDefinitionFactory.php on line 154

The code around there looks like a match for the error:

if ( $validator !== '\ValueValidators\NullValidator' ) {
$definition->setValueValidator( new $validator() );
}

Yeah, that indeed looks like a line relevant to this issue. If it is wrong for PHP 5.3.2, then I don't know how. I suspect the issue actually lies with how the classes are loaded, where PHP 5.3.2 is behaving different in such a way that this code breaks.

In light of the environmental issue uncovered here, maybe we should only support versions that are officially covered by our CI environment otherwise tracking/supporting versions without automatic test runs will eventually cause maintainability issues that are beyond our capacity to handle.

TravisCI uses PHP 5.3.26 (cli) for the 5.3 environment which should be the min. requirement and as for tests PHPUnit 3.7.21.

[1] allows for a broad range of test runs which should be used as litmus test in order to guarantee that the software and its dependencies can be installed with the least amount of interruptions expected.

[1] https://travis-ci.org/SemanticMediaWiki/SemanticMediaWiki

James, I disagree with that. Supporting 5.3.2 makes a lot of sense, and the fact that TravisCI does not support running 5.3.2 is really a problem of our testing infrastructure.

Holding this limitation in mind we can of course specify this version has not been explicitly tested by developers. Then again, I suspect this kind of issues arising by differences in minor PHP versions ought to be rather rare.

I suspect the issue has been fixed by https://gerrit.wikimedia.org/r/#/c/95608/

Neill, can you give it another spin?

mitchell_neill wrote:

Yay! It works :)

Good job. Thanks for the fix. I can now continue regression testing SMW 1.9 and Maps 3.

Fantastic. Thanks for all the testing and your patience in having this resolved.