daniel.schneider wrote:

When I tried to use the Special:CreateForm to continue I get this.

[Wed Aug 28 12:38:33 2013] [error] [client 129.194.30.22] PHP Fatal error: Call to a member function getDBkey() on a non-object in /export/data/portails/mediawiki/extensions/SemanticMediaWiki/includes/BasePropertyAnnotator.php on line 106, referer: http://edutechwiki.unige.ch/en/Special:CreateForm

I'll code manually for now :)

Change 82437 had a related patch set uploaded by Himeshi:
Modify the input to SFForm::create() in the Special:CreateClass page

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

Change 82437 merged by jenkins-bot:
Modify the input to SFForm::create() in the Special:CreateClass page

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

Thanks for reporting these bugs. I think Himeshi fixed the main one, for the Special:CreateClass page, in the latest Git code. (Please let us know if it's still an issue.) For Special:CreateForm, my guess is that there's some unusual property type that's causing problems. Do you have any property in the template(s) that's not, say, Text, Number, Date or URL? Or does this problem happen regardless of which templates you try to create a form for?

daniel.schneider wrote:

• thanx for looking :)

Indeed the Special:CreateClass bug is now partly fixed, i.e. it will create the template and then return the "normal" feedback page with the "Properties, template, form and category will be created" message. But the wiki won't create any properties, forms or categories.

Special:CreateForm is still broken with the same error. The template is really simple, just a single field with a property of type type page, i.e. the unmodified output of CreateClass.

If this can't be reproduced, then I may also have a php problem. On both machines there are some annoying php start warnings (not errors) "unable to load library". However, they occur independently and PHP seems to find them anyhow.

For the Special:CreateClass issue, could it be that there were jobs created for these other pages that just haven't been run? What happens if you try running "php runJobs.php" in the /maintenance directory?

daniel.schneider wrote:

Yes ! php runJobs.php does create the missing forms, categories and properties. Bad fallout from an Ubuntu upgrade/install on our machines ?

Until Sunday I am on the road and ssh access is very difficult (in case I don't answer to any further suggestion). Also I can't investigate much myself. - thanx a lot again for now !

Okay, great! I confess that I still really don't know how the job process works, after all this time... sometime it just fails, for unknown reasons.

daniel.schneider wrote:

Found the problem. Actually, after the first bug fix it would have worked in my production wiki but I only tried the updated code in a test server....

In Localsettings.php make sure to have enough memory, for example

$wgMaxShellMemory = 512000;

If you use Batik (nothing to do with SMW), then make it much bigger:
$wgMaxShellMemory = 5000000;

As an alternative, you also could run this Jobs with a cron script. Advantage would be that you get it done faster (as opposed to wait for people to click).

https://www.mediawiki.org/wiki/Manual:Job_queue

thanx again :)

It seems like the underlying SF bug was fixed... I'm marking this as "fixed".