Skip to content
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

Closed
kghbln opened this issue Jan 11, 2016 · 41 comments
Closed

No longer checks properly for SF version #5

kghbln opened this issue Jan 11, 2016 · 41 comments
Labels
Milestone

Comments

@kghbln
Copy link
Member

kghbln commented Jan 11, 2016

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.

@kghbln
Copy link
Member Author

kghbln commented Jan 11, 2016

Noop, SF is no longer automatically loaded

@kghbln kghbln added the invalid label Jan 11, 2016
@kghbln
Copy link
Member Author

kghbln commented Jan 11, 2016

Invoking does not work either thus T123308

@kghbln kghbln closed this as completed Jan 11, 2016
@kghbln
Copy link
Member Author

kghbln commented Jan 13, 2016

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.

@JeroenDeDauw

@kghbln kghbln added bug and removed invalid labels Jan 25, 2016
@kghbln
Copy link
Member Author

kghbln commented Jan 25, 2016

Noop, SF is no longer automatically loaded

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

{
        "require": {
                "mediawiki/semantic-media-wiki": "@dev",
                "mediawiki/semantic-forms-select": "@dev"
        }
}

instead of

{
        "require": {
                "mediawiki/semantic-media-wiki": "@dev",
                "mediawiki/semantic-forms": "@dev",
                "mediawiki/semantic-forms-select": "@dev"
        }
}

@kghbln kghbln reopened this Jan 25, 2016
@mwjames
Copy link
Contributor

mwjames commented Jan 25, 2016

uses the "extension.json" method to invoke. This somehow broke the dependency detection this extension uses.

My position on this topic is outlined in SemanticMediaWiki/SemanticMediaWiki#1367. (somehow I knew this would happen)

@kghbln
Copy link
Member Author

kghbln commented Jan 25, 2016

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.

@paladox
Copy link
Contributor

paladox commented Jan 25, 2016

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.

@paladox
Copy link
Contributor

paladox commented Jan 25, 2016

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.

@paladox
Copy link
Contributor

paladox commented Jan 25, 2016

Please see #8 which will temporarily fix the problem here.

@paladox
Copy link
Contributor

paladox commented Jan 25, 2016

We could add classmap to composer in semanticforms

@mwjames
Copy link
Contributor

mwjames commented Jan 26, 2016

This somehow broke the dependency detection this extension uses. So this one here should probably be updated.

@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+.

@paladox
Copy link
Contributor

paladox commented Jan 26, 2016

@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.

@paladox
Copy link
Contributor

paladox commented Jan 26, 2016

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.

@mwjames
Copy link
Contributor

mwjames commented Jan 26, 2016

because loading an extension through php entry point will be removed,

Well, SMW will not use extension.json that's for sure after what I have seen so far.

@paladox
Copy link
Contributor

paladox commented Jan 26, 2016

@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.

@paladox
Copy link
Contributor

paladox commented Jan 26, 2016

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/

@mwjames
Copy link
Contributor

mwjames commented Jan 26, 2016

#16 passes the tests for the given constraint (SF 3.4.*).

@mwjames
Copy link
Contributor

mwjames commented Jan 26, 2016

@kghbln Do you want to make a 1.3.1 release to make the constraint on 3.4.* visible?

@kghbln
Copy link
Member Author

kghbln commented Jan 27, 2016

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?

@kghbln
Copy link
Member Author

kghbln commented Jan 27, 2016

I am confused. Now my workaround #5 (comment) does no longer seem to work.

@kghbln
Copy link
Member Author

kghbln commented Jan 27, 2016

Do you want to make a 1.3.1 release to make the constraint on 3.4.* visible?

Should be 3.4.1 in the meantime. No, since composer takes care of this and should not update.

@paladox
Copy link
Contributor

paladox commented Jan 27, 2016

@kghbln Could you try doing

Add this to the main php file above everything.

if ( is_readable( DIR . '/vendor/autoload.php' ) ) {
require_once 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.

@paladox
Copy link
Contributor

paladox commented Jan 27, 2016

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.

@kghbln
Copy link
Member Author

kghbln commented Jan 27, 2016

1.24 is now broken also. It is save to say that we lost this extension for now. :(

@JeroenDeDauw
Copy link
Member

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

@paladox
Copy link
Contributor

paladox commented Jan 27, 2016

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.

@paladox
Copy link
Contributor

paladox commented Jan 27, 2016

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';
}

@kghbln
Copy link
Member Author

kghbln commented Jan 27, 2016

Hi could I ask what errors are you getting

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

@paladox
Copy link
Contributor

paladox commented Jan 27, 2016

Oh. Ok I will move define up in SemanticForms now hoping that helps.

@paladox
Copy link
Contributor

paladox commented Jan 27, 2016

Hi ive uploaded a patch here https://gerrit.wikimedia.org/r/#/c/266926/ that may fix the problem.

@paladox
Copy link
Contributor

paladox commented Jan 28, 2016

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.

@paladox
Copy link
Contributor

paladox commented Jan 28, 2016

Filed bug at https://phabricator.wikimedia.org/T125091

@paladox
Copy link
Contributor

paladox commented Jan 28, 2016

There will also need to be something added in this extension. But I will do that later once I fix all the problems.

@paladox
Copy link
Contributor

paladox commented Jan 28, 2016

@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.

@paladox
Copy link
Contributor

paladox commented Jan 29, 2016

@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.

@paladox
Copy link
Contributor

paladox commented Jan 29, 2016

Ok I have fixed it in #25

@paladox
Copy link
Contributor

paladox commented Feb 14, 2016

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.

@paladox
Copy link
Contributor

paladox commented Feb 14, 2016

@paladox
Copy link
Contributor

paladox commented Feb 25, 2016

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.

@kghbln
Copy link
Member Author

kghbln commented Nov 28, 2016

I believe that SFS 1.3 and SF 3.4.1+ are beyond repair. However SFS master has been fixed and PF is out; Thus I have just installed master of SFS together with master of PF on sandbox and the issue no longer appears.

What we need is some field testing @Rudloff, @paladox and we are cool.

@kghbln kghbln mentioned this issue Nov 28, 2016
9 tasks
@kghbln kghbln added this to the 2.0.0 milestone Dec 1, 2016
@mwjames
Copy link
Contributor

mwjames commented Dec 3, 2016

I believe that SFS 1.3 and SF 3.4.1+ are beyond repair. However SFS master has been fixed and PF is out;

Expected to be fixed by #38 and #42.

@mwjames mwjames closed this as completed Dec 3, 2016
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

4 participants