Page MenuHomePhabricator

Undefined index: value in "ExtensionProcessor.php" on line 504 (due to specific extension.json file)
Closed, InvalidPublic

Description

Setup

  • MediaWiki | 1.33.0 (62dc614)08:13, 24. Jul. 2019
  • PHP | 7.2.19-0ubuntu0.18.04.1 (apache2handler)
  • MariaDB | 10.1.40-MariaDB-0ubuntu0.18.04.1

Issue
Not sure which extension is causing this:

PHP Notice:  Undefined index: value in /../w/includes/registration/ExtensionProcessor.php on line 504
Notice: Undefined index: value in /../w/includes/registration/ExtensionProcessor.php on line 504

Originally reported here. Perhaps similar to T141289

Anyways I dunno how to get a cool stack trace like in the linked task for better work on this issue.

"LocalSettings.php":

error_reporting( -1 );
ini_set( 'display_errors', 1 );
$wgShowExceptionDetails = true;

Event Timeline

Kghbln created this task.Aug 5 2019, 3:37 PM
Restricted Application added a subscriber: Aklapper. · View Herald TranscriptAug 5 2019, 3:37 PM
Kghbln added a subscriber: Legoktm.

@Legoktm FYI Since you are concerned with extension registration ...

Kghbln updated the task description. (Show Details)Aug 5 2019, 3:39 PM
Krinkle added a subscriber: Krinkle.Aug 5 2019, 3:40 PM

Does it happen when there are no extensions installed? Or is it triggered by a specific extension only? Which one? And what does its extension.json file look like?

Florian added a subscriber: Florian.Aug 5 2019, 3:41 PM
Kghbln added a comment.Aug 5 2019, 3:44 PM

Does it happen when there are no extensions installed?

I'd say no since MW dates to 2019-07-24 and this only started on 2019-08-03

Or is it triggered by a specific extension only? Which one? And what does its extension.json file look like?

Not sure which extension is causing this. I only get the notice.

Can you "unsinstall" the extensions one by one until the error disappears? Then you probably have the extension which causes the error :)

Kghbln added a comment.EditedAug 5 2019, 4:35 PM

Can you "unsinstall" the extensions one by one until the error disappears? Then you probably have the extension which causes the error :)

This is about an hour and more work since we are talking about 80 extensions. :( I'd rather get a decent stack trace which enables me to see this. I am sure this is possible.

This is about an hour work since we are talking about 80 extensions. :( I'd rather get a decent stack trace which enables me to see this.

See https://www.mediawiki.org/wiki/Manual:How_to_debug. Specifically, $wgDebugLogGroups['error'] will contain stack traces for errors, warnings and notices from PHP.

Kghbln added a comment.Aug 5 2019, 4:38 PM

See https://www.mediawiki.org/wiki/Manual:How_to_debug. Specifically, $wgDebugLogGroups['error'] will contain stack traces for errors, warnings and notices from PHP.

Cool, which group do I have to set if I would like to debug extension registration? I do not know the respective group name?

See https://www.mediawiki.org/wiki/Manual:How_to_debug. Specifically, $wgDebugLogGroups['error'] will contain stack traces for errors, warnings and notices from PHP.

Cool, which group do I have to set if I would like to debug extension registration? I do not know the respective group name?

None other than the error group, which handles all PHP notices.

The other groups are for custom messages from specific features and extensions. But this issue is not logged by ExtensionRegistry, it is logged by PHP itself, which we log to group error.

Krinkle added a comment.EditedAug 5 2019, 4:49 PM

This is about an hour work since we are talking about 80 extensions.

It should take far less than that if you use a strategy similar to binary search. In its simplest form: Disable half of the extensions, check for the issue, if it's there, disable half of that half etc. If the issue goes away, it's in the other half, and go again etc. Should only take 6 or 7 steps at most.

Kghbln added a comment.Aug 5 2019, 4:49 PM

None other than the error group, which handles all PHP notices.

So all my hopes have died. :( I am doing this specific logging group for months and this error does not show in the file. All I get are these notices via cron - nothing more. This is why I stated that I cannot provide a stack trace.

Is there anything else I can do to get a stack trace.

Kghbln added a comment.EditedAug 5 2019, 4:53 PM

It should take far less than that if you use a strategy similar to binary search. In its simplest form: Disable half of the extensions, check for the issue, if it's there, disable half of that half etc. If the issue goes away, it's in the other half, and go again etc. Should only take 6 or 7 steps at most.

In case only one extension is causing the issue. Last time I did this MobileFontend, and two other extension were causing the same issue at the same time. It was a horror trip.

I'd really appreciate the ability to log extension registration issues. Anyways there seems to be no other way to debug extension registration. :(

If you run the following code from LocalSettings.php (after your INI setting and log group configuration), and then view your wiki's main page, you should get an error with stack trace in the file for the error log group.

LocalSettings.php
error_reporting( -1 );
ini_set( 'display_errors', 1 );
$wgShowExceptionDetails = true;

$wgDebugLogFile = '/tmp/mw-debug.log';
$wgDebugLogGroups['error'] = "/tmp/mw-error.log";

function testMyErrors() {
  $data = [];
  return $data['mymissingkey']; # PHP Notice:  Undefined index: mymissingkey 
}
testMyErrors();

If the above does not result in the error with function trace in mw-error.log, then your web server is likely broken or misconfigured in ways that are not related to MediaWiki. I would then recommend asking on StackOverflow for general support on how to configure Apache or PHP. If MediaWiki is not getting any information from PHP, then it cannot show you to access it, because the underlying source is missing.

Krinkle added a comment.EditedAug 5 2019, 5:00 PM

It should take far less than that if you use a strategy similar to binary search. [..] only take 6 or 7 steps at most.

In case only one extension is causing the issue. Last time I did this MobileFrontend, and two other extension [..]

It does not matter if multiple extensions cause the issue. You should narrow it down to one extension that exhibits the problem, which we can then inspect to find the cause and solve it.

Kghbln added a comment.Aug 5 2019, 5:32 PM

Thanks for the tip which regrettably leads to nowhere. I have now 3 MB logging but not byte of error logging for this specific issue.

Error reporting does work on this server since issues from other extensions are indeed being logged. It is that it just does not record anything regarding this specific issue. By now I have spent over an hour on this and probably it would have been best to do the disabling approach. I no longer have time for this at the moment. I will try to do the extension disable approach latter this week or on the weekend.

Try the following patch:

diff --git a/includes/registration/ExtensionProcessor.php b/includes/registration/ExtensionProcessor.php
index 6182d5fdc4..1bff9efbf5 100644
--- a/includes/registration/ExtensionProcessor.php
+++ b/includes/registration/ExtensionProcessor.php
@@ -575,6 +575,9 @@ class ExtensionProcessor implements Processor {
                $prefix = $info['config_prefix'] ?? 'wg';
                if ( isset( $info['config'] ) ) {
                        foreach ( $info['config'] as $key => $data ) {
+                               if ( !isset( $data['value'] ) ) {
+                                       throw new \Exception("Missing 'value' for $key from {$info['name']}");
+                               }
                                $value = $data['value'];
                                if ( isset( $data['merge_strategy'] ) ) {
                                        $value[ExtensionRegistry::MERGE_STRATEGY] = $data['merge_strategy'];

That should help us track down the extension.

Alternatively, running https://www.mediawiki.org/wiki/Manual:ValidateRegistrationFile.php against all extensions you have installed (extensions/*/extension.json) should also identify the issue.

Krinkle removed a subscriber: Krinkle.Aug 6 2019, 11:26 AM

@Kghbln: Did you find time to try the patch in the last comment?

Kghbln added a comment.EditedTue, Sep 17, 3:19 PM

I am still getting this every third minute. Now I know what is causing this: an exension.json file specifying the following:

	"requires": {
		"MediaWiki": ">= 1.31",
		"extensions": {
			"SemanticMediaWiki": ">= 3.0"
		}
	},

This format follows documentation and we are on manifest 2. Not sure what is going on.

Aklapper renamed this task from Undefined index: value in "ExtensionProcessor.php" on line 504 to Undefined index: value in "ExtensionProcessor.php" on line 504 (due to specific extension.json file).Tue, Sep 17, 3:39 PM

That looks completely unrelated from what I see. Can you post the full extension.json file, so we can reproduce the error locally? Is the error still occuring?

This is the pull causing pain. Without adding the dependency everything is ok, as soon as in add SMW everything goes south.

Ok, then this is your actual problem: Adding the requires section is perfectly fine, however, for this to work you need to bump the manifest version from 1 to 2. However, your remaining extension.json is still version 1 of the manifest (the schema verification, if you run it, will most likely fail). E.g. the config section was massively overhauled in version 2 of the manifest, see the docs:

https://www.mediawiki.org/wiki/Manual:Extension_registration#Configs_(Your_extension/skins_settings)

You've:

     "config": {
		"_prefix": "stg",
		"PropertyAssignedTo": "Assigned to",
		"PropertyCarbonCopy": "Carbon copy",
		"PropertyTargetDate": "Target date",
		"PropertyReminderAt": "Reminder at",
		"PropertyStatus": "Status",
		"PropertyAssignedToGroup": "Assigned to group",
		"PropertyHasAssignee": "Has assignee"
	}

Which should look more like:

     "config_prefix": "stg",
     "config": {
		"PropertyAssignedTo": {
                  "value": "Assigned to"
                 },
		"PropertyCarbonCopy": {
                  "value": "Carbon copy"
                },
                // ....
	}

There's a maintenance script, that assists in upgrading the manifest_version: updateExtensionJsonSchema.php :)

Florian closed this task as Invalid.Sat, Sep 21, 2:29 PM

There's a maintenance script, that assists in upgrading the manifest_version: updateExtensionJsonSchema.php :)

Thanks a lot. I guess we bumped into undocumented territory here. The docu tells that you can more complex stuff but it does not tell that the formats incompatible. Moreover there is no note about the script, which is also not documented. Ok I will try to dig into this. Thanks for your help.

Kghbln reopened this task as Open.EditedSun, Sep 22, 8:38 AM

Sad to say. This turns into an even bigger disaster. Conveting to manifest 2 results into an armada of follow up errors, e.g.

Deprecated: Use of SemanticTasks's extension.json or skin.json does not have manifest_version was deprecated in MediaWiki 1.29. [Called from ExtensionRegistry::loadFromQueue in /home/travis/build/SemanticMediaWiki/mw/includes/registration/ExtensionRegistry.php at line 158] in /home/travis/build/SemanticMediaWiki/mw/includes/debug/MWDebug.php on line 309

I have no idea what this is trying to tell me. Manifest 2 is in the file, so I do not know why the error appears. Moreover manifest 2 was not deprecated in 1.29 as far as I know.

In the end this all ended up fatally for the software. There is no documentation on how to migrate. I have no idea how to use the update script which is also undocumented.

Kghbln closed this task as Invalid.Sun, Sep 22, 8:40 AM

Second thoughts. I back down from trying to convert to manifest 2. I see advantages in manifest 2 however conversion and implementation suggest that it is not worth the effort yet.