Page MenuHomePhabricator

SF no longer being invoked with Composer
Closed, ResolvedPublic

Description

After todays update of SF it no longer seems to be invokable if using Composer as installation method, i.e. it is no longer loaded automativally and adding

require_once "extensions/SemanticForms/SemanticForms.php";

does not help either.

Event Timeline

Kghbln raised the priority of this task from to Needs Triage.
Kghbln updated the task description. (Show Details)
Kghbln subscribed.

I'm assuming that it was this change last week that changed the behavior:

https://git.wikimedia.org/commitdiff/mediawiki%2Fextensions%2FSemanticForms.git/423f94f3c1dbfb42c522870363d33e960e440a09

Can you verify if adding those lines back in to composer.json fixes the problem?

No, this does not change the issue. Still puzzled why I cannot even invoke manually.

Oh. The only other recent change to composer.json was this one, done yesterday:

https://git.wikimedia.org/commitdiff/mediawiki%2Fextensions%2FSemanticForms.git/7fa04fd4d6d7c4ca74d98e7c4f7ea4c48aceefef

SMW was removed as a requirement. Could that be the issue?

No, this does not help either. This started after moving in the code changes which happened yesterday, so something that happened yesterday must have caused this, since the day before was ok.

Ah. Well, the major change that happened yesterday is that extension.json is now used to load SF's settings, if MediaWiki is of version 1.26 or higher. If you comment out lines 46-59 of SemanticForms.php, where this new loading happens, does the problem go away?

No, unfortunately no luck either.

No idea, then - sorry. It must be one of the other recent changes, but I don't know which.

Never mind. Thank you for looking at it. As long as the standard cloning and/or tarball stuff works. :) Perhaps another person with insight on this in particular comes by and helps the cause.

Well, do you know what happened now? Just wanted to switch to regular and removed the sf-line from my "composer.local.json" and found that it is still being installed and loaded. So there must be another semantic extension doing this via a dependency requirement. Now I have to investigate which one this may be.

In my particular case it was Semantic Forms Select since Semantic Signup was not installed on the instances in question. These are the only dependents. Let's see how this may be sorted out. Stay tuned.

Hi does this still happen.

What errors do you or if any.

Also if your trying to load repos through composer and you use extension.json you have to set a config in extension.json to load it autoload.php.

Yaron_Koren renamed this task from SF no longer being invoked to SF no longer being invoked with Composer.Jan 25 2016, 3:26 AM
Yaron_Koren set Security to None.

Thanks @Paladox for joining the issue.

I should have checked via the API if SF is installed or not. Most probably I would have found that SF is actually being invoked. The issue seems to be that extensions depending on SF do not longer properly recognize SF as being installed. The error came from the SFS extension: "Error: This version of SemanticFormsSelect is only compatible with Semantic Forms 2.8 or above. You need to upgrade Semantic Forms first."

This does no longer work as of current SF master:

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

Removing SF from the json-file results in a working wiki including SF since SFS pulls SF as its dependency and then somehow recognizes SF properly:

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

Now that we have yet another method of installing extensions at hand one must take dependency chains into consideration when creating composer.json files at least when it comes to Composer. To cut it short: Documenting this behaviour change on the SFS page etc. seems to be the solution for this issue. I sought for confirmation on this but did not get it so far.

I think that problem may be because semantic forms now uses extension.json and since that extension is using sf_version to detect the extension is installed it isent working. so I suggest using the semanticforms class to use as the detector.

But could also be because it isent load the autoload.php file in semanticformsselect which you would need to do.

Kghbln claimed this task.

now uses extension.json

Yep, this was the breaking change. So back to fixing dependency detection.

Re opening to see weather we can add full composer support to SemanticForms.

No. :( Still getting "Error: This version of SemanticFormsSelect is only compatible with Semantic Forms 2.8 or above. You need to upgrade Semantic Forms first." I wonder why it is not possible for an extension to tell other extensions about its version via extension.json. Before it was just one line of PHP if I am not mistaken. However, I am not a coder so I have no idea. :(

Oh. I will have another look. But I moved the define up so it should not be the problem with semanticforms.

@Paladox Keeping fingers crossed. Will not be around for testing till start of February.

Oh dear. I just unistalled Semantic Forms Select. Now Semantic Rating triggers the wiki to be down: "Error: SemanticRating is a Semantic Forms extension so must be included after Semantic Forms." The extension.json system seems to be as inherently broken as the composer system when it comes to installing extensions. :(

@Kghbln I have done some digging it was very hard to install semantic forms select through composer kept complaining that there was no version defined so I just used GitHub. When I used composer update it installed semantic forms into extensions folder within the extension but never added the extension to the autoload file.
Missing config in composer for semantic forms is

		"files" : [
			"SemanticForms.php"
		],

@Kghbln is now autoloaded in composer. Some extensions may have problems if they use MediaWiki 1.27 because it uses extension registrations. But those extensions will need to be updated to fix the problem of support.

@Paladox Great to hear. I actually have this now running on a MW 1.24 and MW 1.25 without the observed issue. So this issue is cool to be closed?

What kind of fix will have to be done for MW 1.27? Probably an issue should be opended on the respective extensions to have an action item for it.

@Kghbln I'm not sure what you mean by fixing mediawiki 1.27 support since it should work.

@Paladox I was referring to this:

Some extensions may have problems if they use MediaWiki 1.27 because it uses extension registrations. But those extensions will need to be updated to fix the problem of support.

If these extensions need to be updated/fixed there should be an issue indicating what has to be updated/fixed. I may however have misunderstood this.

@Kghbln oh ok. It should now work for all extensions. SemanticFormsSelect should work when SemanticForms 3.4.3 is released. Ive done some testing and master branch works for that extension but release 3.4.2 dosent.

@Paladox Well, this is great news, I suppose. :) Thanks a ton for your involvement in tackling this issue. I guess you very much deserve to do the honours. :)

Can this issue be closed now? Is Composer support fully working again?

Ah, I thought that @Paladox closed this already. For MW 1.25 it is now working. Accidentally I checked out MW 1.27 yesterday on a wiki and saw the issue reappear. However, I am to scared to give it another shot now. First I have to upgrade the server anyway to have a realistic environment. To cut it short: Closing for now.