Page MenuHomePhabricator

On SVN trunk 1.17alpha (r67274) Collection fails
Closed, InvalidPublic

Description

While single page creation works, the book collection process fails. Book collection can be started, but fails to add pages to the collection. Book page count in tool remains at 1, but even that goes away if the book is accessed (Show book).

In addition, with debug enabled, the following error lines will be shown on top of each page:

Notice: Undefined variable: wgJsMimeType in /usr/share/mediawikistaging/extensions/Collection/Collection.body.php on line 333
Notice: Undefined variable: wgJsMimeType in /usr/share/mediawikistaging/extensions/Collection/Collection.body.php on line 335
Notice: Undefined variable: wgJsMimeType in /usr/share/mediawikistaging/extensions/Collection/Collection.body.php on line 337
Notice: Undefined index: wsCollection in /usr/share/mediawikistaging/extensions/Collection/Collection.session.php on line 110
Notice: Undefined variable: wgJsMimeType in /usr/share/mediawikistaging/extensions/Collection/Collection.body.php on line 345
Notice: Undefined index: enabled in /usr/share/mediawikistaging/extensions/Collection/Collection.hooks.php on line 208


Version: unspecified
Severity: critical

Details

Reference
bz23790

Event Timeline

bzimport raised the priority of this task from to Medium.Nov 21 2014, 11:06 PM
bzimport added a project: Collection.
bzimport set Reference to bz23790.

"While single page creation works" = "While single page _PDF_ creation works"

heiko wrote:

I can not reproduce this error. At which wiki site did you encounter this and which browser were you using?

heiko wrote:

Closing as this problem is special to your setup/configuration. For assistance to get this resolved please write to the mailinglist:
http://groups.google.com/group/mwlib

Notices related to $wgJsMimeType fixed in r67351.

And the remaining part in r67353. Reproduction isn't needed in such obvious cases.

Thanks Max!

Perhaps one issue remains, with r67353 a remaining error debug message appears:

Undefined index: wsCollection in /usr/share/mediawikistaging/extensions/Collection/Collection.session.php on line 110

and the book collection now does not start at all (no special area on top when navigating to pages). The aforementioned testwiki is presently running r67353.

johannes.beigel wrote:

Thanks Gregor, this should be fixed in r67604.(In reply to comment #7)

Perhaps one issue remains, with r67353 a remaining error debug message appears:

Undefined index: wsCollection in
/usr/share/mediawikistaging/extensions/Collection/Collection.session.php on
line 110

Thanks Gregor, this should be fixed in r67604.

johannes.beigel wrote:

Make that r67605...

Testing r67607: next error 13 lines down:

Notice: Undefined variable: _SESSION in /usr/share/mediawikistaging/extensions/Collection/Collection.session.php on line 133

Incidentially: why is it that the session cannot be established? I just reviewed all settings and installation instructions do confirm the collections settings. These are used for two versions on a wiki farm:

a) r59858 on http://biowikifarm.net/meta/Special:Version
b) r67607 on http://biowikifarm.net/test/Special:Version

When book collection is started on testwiki (using FF 3.6.3, signed in as user to the wiki, cookies and js all enabled), the error message shown above appears. Testing collection on metawiki to confirm the settings, all works well (collecting and PDF creating). Going BACK to testwiki, no error message appears any longer, as if a session is now re-used? However, book collection, without any error messages, does not work. The collection portlet on top is present, but no pages can be added.

When trying again with IE8 on testwiki, same message appears - since no session had been initiated. This may explain why some were unable to reproduce the error - reproducing probably needs cookies to be deleted.

thank you for you help!

G.

johannes.beigel wrote:

(In reply to comment #10)

Testing r67607: next error 13 lines down:

Notice: Undefined variable: _SESSION in
/usr/share/mediawikistaging/extensions/Collection/Collection.session.php on
line 133

OK, thanks, should be fixed in r67613.

Incidentially: [...]

I don't really know what's going on there. But I guess it's better to ask these questions somewhere e=kse where more people are able to help you, e.g. on IRC (MediaWiki-General if it's a general MediaWiki question) or on some mailing list. If the problems are specific to the Collection extension, you could join our mailing list at http://groups.google.com/group/mwlib

Sorry, did not work, with r67613 I get:

Notice: Undefined index: wsCollection in /usr/share/mediawikistaging/extensions/Collection/Collection.session.php on line 134

URL is http://biowikifarm.net/testwiki/index.php?title=Special:Book&bookcmd=book_creator&referer=Main+Page

Gregor

johannes.beigel wrote:

(In reply to comment #12)

Sorry, did not work, with r67613 I get:

Notice: Undefined index: wsCollection in
/usr/share/mediawikistaging/extensions/Collection/Collection.session.php on
line 134

Could very well be fixed with demon's change in r67617.

URL is
http://biowikifarm.net/testwiki/index.php?title=Special:Book&bookcmd=book_creator&referer=Main+Page

I get

Notice: Undefined variable: _SESSION in /usr/share/mediawikistaging/extensions/Collection/Collection.session.php on line 134

when viewing this page, but I guess this should be fixed in r67617, too.

Can you confirm? This time, I'll leave the ticket REOPENED :)

OK, no more code error messages for r67693 now. However, the title of the bug still applies: Collection fails, i.e. to collect any pages. The toolbox on top appears, but adding a page does not change it. Going to Show book always displays an empty book.

It seems clear from the code fixes above, that the session is no longer successfully established. However a mediawiki session exist: the user is signed in and the login is stable. Tested with both FF 3.6.3 and IE8, both with cookies enabled (verified through other cookie-dependent software as well). The full Collection extension settings are given at the end.

Again, as described above, with these settings the Collection session works fine with an earlier version of mediawiki, r59858 as testable on http://biowikifarm.net/meta/Special:Version -

  • Something must have CHANGED in SESSION management BREAKING the Collection Session ***

What else is using similar sessions?

We will gladly provide any support to get this working again.

What is going on?


LocalSettings for Collection:

require_once("$IP/extensions/Collection/Collection.php");
$wgCollectionMWServeURL = 'http://tools.pediapress.com/mw-serve/';
// Allow collecting Help pages (default is no!) and custom namespaces
$wgCollectionArticleNamespaces = array(
NS_MAIN,
NS_TALK,
NS_USER,
NS_USER_TALK,
NS_HELP,
NS_HELP,
NS_PROJECT,
NS_PROJECT_TALK,
NS_MEDIAWIKI,
NS_MEDIAWIKI_TALK,
NS_PRIVATE,
NS_PRIVATE_TALK,
NS_PORTAL,
NS_PORTAL_TALK,
NS_BIBLIO,
NS_BIBLIO_TALK,
NS_SUBMISSION,
NS_SUBMISSION_TALK,
NS_REVIEWED,
NS_REVIEWED_TALK,
100,
101,
102,
103,
);

// Where to save community collections? MediaWiki namespace is not a good default
$wgCommunityCollectionNamespace = NS_PROJECT;

// who can save collections where?
$wgGroupPermissions['user']['collectionsaveasuserpage'] = true;
$wgGroupPermissions['autoconfirmed']['collectionsaveascommunitypage'] = true;

Sidebar cache doesn't play nice with this
$wgEnableSidebarCache = false;
$wgCollectionFormats = array(
'rl' => 'PDF',
'odf' => 'OpenDocument Text',
);
Formats (keys in $wgCollectionFormats) to be displayed as "Download as XYZ" links in the "Print/export" portlet
$wgCollectionPortletFormats = array( 'rl' );


development wrote:

Hm. Can someone reproduce this behavior? Can you (Gregor) reproduce it on another MW installation (preferably on another host)?

As everything is working fine on WMF wikis like the Wikipedias which have the Collection extension enabled (and which are usually quite up-to-date MediaWiki installations) and on our test wikis (current SVN revision of MediaWiki), I'm a bit puzzled and can't really rule out the possibility that this is a problem with sessions/PHP config/cookies/domains etc. on your side.

The settings you posted don't affect session handling in any way. In fact, there are no Collection-specific settings at all that affect the session handling.

Code-wise: In addition to the global function wfSetupSession() which is provided by MediaWiki, we're using PHP core-functionality only – $_SESSION and (lately) session_id(). There's nothing specific and I somehow doubt that this is something that can get broken by a MediaWiki update.

BTW: If this is really specific to the Collection extension, discussion on our mailing list (http://groups.google.com/group/mwlib) might be better suited.

We only have a duplicate server with a very similar setup. However, the different mediawiki installations:

a) r59858 on http://biowikifarm.net/meta/Special:Version
b) r67607 on http://biowikifarm.net/test/Special:Version

run on the same server, sharing all software (same apache, php etc.) and even the mediawiki settings, the only difference being that they use a different SVN checkout. Since collection works fine on meta, we can rule out that the debian installation or php version in itself is the culprit - it must be some INTERACTION between this and session management changes that happened between 59858 and 67607, either in core or Collection.

Can someone remember WHICH CHANGES were made with respect to session handling? This is my biggest hope...


By the way: Wikimedia has stopped running the mediawiki trunk, creating a wmf branch and running an older version: 1.16wmf4 (r66620) (see e.g. en.wikipedia). Thus wmf testing is not as up-to-date as one may wish. r66620 is not usable on our site, since several non-wmf-extensions fail to run under this revision, which have been updated since.

We have identified the root cause, as one of the first reported suggested, it was indeed an interaction with a bug in a self-written extension. I close it as invalid.

I apologize to and thank everyone who has helped in studying this bug

Gregor