-
-
Notifications
You must be signed in to change notification settings - Fork 14
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
No longer checks properly for SF version #5
Comments
Noop, SF is no longer automatically loaded |
Invoking does not work either thus T123308 |
This was a false assessment. Now I believe autoloading somehow defeats itself through the walk through dependency chain. With recent changes of 2015-01-11 in Semantic Forms probably the one to cater for this extension loading or so one has now to remove Semantic Forms from the "composer.local.json" file in order to keep the wiki running. Is there a way to a avoid this or should I just document this in the "README" file of this extension. |
Au contraire, SF is loaded and SFS just does not get detected. Well, my very first assessment seems to have been the right one. Current SF master uses the "extension.json" method to invoke. This somehow broke the dependency detection this extension uses. So this one here should probably be updated. So as a workaround one should use
instead of
|
My position on this topic is outlined in SemanticMediaWiki/SemanticMediaWiki#1367. (somehow I knew this would happen) |
And I hoped it would not happen. Often reality bites eagerly like in this case. At least we have a workaround for this extension. |
You can use if ( ExtensionRegistry::getInstance()->isLoaded( 'ExtensionB' ) ) { to use for extension.json. There is a patch is core that is hope full that adds the support for extension dependency's. |
Also since semanticforms has a composer file it doesent use psr which registers the path of the repo so SemanticForms would need to be converted to use psr. So for now you can probly add an if statement so that it registers SemanticForms through the vendor folder. add that to the very top of semanticformsselect. I suggest to open a task on phabricator requesting that semanticforms be converted to full composer support. |
Please see #8 which will temporarily fix the problem here. |
We could add classmap to composer in semanticforms |
@kghbln I expect an official statement from the SF maintainer as it is evident that recent changes where made deliberately with the consequence (and rather unfortunate) that SFS can no longer work with version SF 3.5+. |
@mwjames the reason why that was done was because it is being done on all extensions and skins because loading an extension through php entry point will be removed, Its currently deprecated. |
Any ways this extensions is using semanticforms 2.7 in composer so I doint know how you get the error. or how you are using the latest. |
Well, SMW will not use |
@mwjames I doint this ever worked because you never added autoload.php to the php file here. And maybe if we move define up a bit in SemanticForms it may work here but not sure. |
Hi I have installed this on my local machine I see that instead of it being installed in vendor the semanticforms extension. it is installed in the extensions folder in SemanticFormsSelect so it looks like SemanticFormsSelect/extensions/ |
#16 passes the tests for the given constraint (SF 3.4.*). |
@kghbln Do you want to make a 1.3.1 release to make the constraint on 3.4.* visible? |
You all lost me on this I'm afraid. According to my #5 (comment) the immediate solution is to remove SF from the composer.local.json and have it installed as a dependency. At least the wikis are not down this way. All the rest about extra classes in SF itself, adding autoload.php to LocalSettings.php is beyond my assessment. Also I suppose that this breakage does not just apply to SFS, but also to SES etc. etc. - all the extensions depending on SF? |
I am confused. Now my workaround #5 (comment) does no longer seem to work. |
Should be 3.4.1 in the meantime. No, since composer takes care of this and should not update. |
@kghbln Could you try doing Add this to the main php file above everything. if ( is_readable( DIR . '/vendor/autoload.php' ) ) { then do composer update and see if that works because it loads semanticforms for me meaning it downloads I haven't tested to see if it works. |
Please also could you try mediawiki 1.24 with semanticforms in composer set to dev-master since extension.json should not be used in that since its not supported in 1.24 so it should use the normal php file. If it works for you I will take a look in SemanticForms php file and move things in front of the function call. |
1.24 is now broken also. It is save to say that we lost this extension for now. :( |
Just saw this now. I do not understand how @yaronkoren's change is causing problems for sandbox. If you had a composer spec with just SF in it, and not SMW, then after yarons change, you'd end up with just SF if you ran composer update. However this extension explicitly requires SMW as well, as it should. #confuse |
Hi could I ask what errors are you getting. because you should not be getting any. Any ways another way is too load SemanticForms before this extension in LocalSettings.php. |
You should add to the top of this repos main php file. Since composer wont load automatically in php you need to request it in php. if ( is_readable( __DIR__ . '/vendor/autoload.php' ) ) {
require_once __DIR__ . '/vendor/autoload.php';
} |
SFS tells me to install SF 2.8 or higher. Apart from that I am getting a blanc page. 3 wikis were down and I downgraded them to SF 3.4.1 |
Oh. Ok I will move define up in SemanticForms now hoping that helps. |
Hi ive uploaded a patch here https://gerrit.wikimedia.org/r/#/c/266926/ that may fix the problem. |
Ok I have now tracked down the bug. It was todo with semanticforms removed the files bit so it didn't autoload SemanticForms. So semanticforms loads for me but one problem is that it now shows extension.json does not exist when it does. That is a bug in mediawiki core which I plan to file a bug for. |
Filed bug at https://phabricator.wikimedia.org/T125091 |
There will also need to be something added in this extension. But I will do that later once I fix all the problems. |
@kghbln I have now fixed all problems I have tested my self two patches waiting to be merged. https://gerrit.wikimedia.org/r/#/c/267155/ https://gerrit.wikimedia.org/r/#/c/267161/ I will then upload a patch here after those two and do the final changes for this too work. Ive tested already and already have the changes ready to be applied here. I hope all these changes fixes the problem for you. |
@mwjames or @JeroenDeDauw I've fixed the issue in SemanticForms not sure if I should move the config into an extension function but I keep getting an error todo with this code https://github.com/SemanticMediaWiki/SemanticFormsSelect/blob/master/SemanticFormsSelect.php#L63 in travis I could reproduce this problem before I fixed SemanticForms now I doint see this problem and all works why is this failing. |
Ok I have fixed it in #25 |
This is all fixed now when SemanticForms 3.4.3 is released this should start working with composer again. Ive done some testing and it deffitly does start working. |
SemanticForms 3.5 has been released. It includes a lot of fixes and fixes the problems we were having with composer. Also this problem here needs a patch here that puts that check in $GLOBALS['wgExtensionFunctions'][] = function() { Also the automatically loading part is todo with this extension since you need to add the vendor/autoload.php to the top of the extension. |
sandbox.smw.o is down now after the recent automatic update of composer extensions. There have been changes to SF today which may have caused this still I do not know why SFS fails to get version 3.4.1 properly.
The text was updated successfully, but these errors were encountered: