Pls move the page to become a subpage of my MediaWiki-Userpage, ty.

tl;dr
want always to have the possiblity to create a single page (pdf or long html or odt) from a well-defined (list) set of pages - which may not necessarily subpages of a page or of pages.

I would like to keep that collection (of collections) at least somewhere else. The fact, that the Book Creator is not working since years is something which I regard as one of the worst things which happened in the last years, so I gave up to fight for re-upping that brillant and useful service.

@Krinkle I just wish to drop in. In more than one decade, I had quite a lot of installations of MediaWiki in hosting environments, i.e. virtual servers, where my above patch fully solved the issue (shown in the very first posting). I cannot go into technical details, I just wanted to say this again.

So I think it could be an issue related to the specific php version we have or with the fact that some namespaces we use were defined as constants in the LocalSettings.

@matmarex Hi, even why I must admit, that I knew this both. the extension was not working for non-NS_MAIN namespaces.
I suggest that I will scrutizine the problem (or non-problem) again and report here.

Someone else should verify/confirm this, I cannot now. At least there are two issues, this is my view. The present issue is the most important one and can be solved independently.

https://phabricator.wikimedia.org/T240391 is valid, as then - when you have also NewUserNotif active - the namespace restriction of EditNotify is not respected.

(I already did so, see here https://www.mediawiki.org/wiki/Topic:Vct1uox3qprm3eak )

@Aklapper: Additional question: is there a simple way or trick to programmatically add all namesspaces?

I will change the description page

It appears to be an issue of the correct syntax.
I changed to

Reopened, because at least one issue remains.

It's not correctly working:

I had to deactivate the delete command in order to get that mechanism working for NS_MAIN - which I added in LocalSettings.php. I will try that again and report here whether it worked or not in the second trial.

@Aklapper: because of

$wgExtraSignatureNamespace is not used anymore for the WikiEditor extension, as far as I see.

And regarding the missing editbuttons, I ask the MW gurus here https://www.mediawiki.org/wiki/Topic:Vcqdm74c4a1ltzg5

Result: negative: the reversing of the invocation sequence does not fix the issue.

regarding your idea with reversing: I had this idea, too, but did not try that, because I really wanted to upgrade to 1.33.1, so I took the issue here as "reason" to upgrade first. Will do try reversing the invoke sequence now.

Yaron: we would like to have both extensions, or, when you can "enhance" the newer "EditNotify" so that it also can be used when a new User Account is created (not: Userpage), that would be great.

Yep! Bingo

Yaron, yes, good point, as we have the NewUserNotif.php working...! I will disable that and report here, if there is an interference.

Something different: the editbuttons are gone after the upgrade, any idea, why? Perhaps a cache issue... must wait

Negative. Notifs come for any creations, regardless of the Namespace.
BTW, I upgraded core to 1.33.1 and also the EditNotify extension.
Strange. Let me know, if you have something what I could test.

Yaron, it is *not* sensitive to the Namespace:

Will try. Just a remark: I installed the extension for the 1.31 release tag, to match the core extension.

wfLoadExtension() wasn't mentioned in the Description, that's why I didn't use the modern method.

1.31.3 see https://events.ccc.de/congress/2019/wiki/index.php/Special:Version

Here's our setup:

In T237859#5679074, @Mholloway wrote:

As a workaround, I believe that performing a purge or null edit of the article will trigger a PCS update that will pull in changes to transcluded content.

As reported by me in https://phabricator.wikimedia.org/T237859 , the update of the wikidata content of the dewiki "Briar (Instant Messenger)" page recetnly had a delay of more than 8 days which is not acceptable.

@Aklapper yes, please (first patch since a long time... be patient with me, pls.) : https://gerrit.wikimedia.org/r/#/c/mediawiki/core/+/546370/1/includes/GlobalFunctions.php

In T172060#4773293, @Wikinaut wrote:

Hi, I recently came back to MediaWiki development, since a long time. I discovered PHP Notice: Undefined index: SERVER_NAME in /includes/GlobalFunctions.php on line 1432.

In my view this could be fixed by additional checking in the last condition path

} elseif ( isset ( $_SERVER['SERVER_NAME'] ) ) {
        # This may be a virtual server.
        $host = $_SERVER['SERVER_NAME'];
} else {
        global $wgServerName;
        $host = $wgServerName;
}

whether $wgServerName has been set in LocalSettings.php and then use this $wgServerName value here.

See https://www.mediawiki.org/wiki/Manual:$wgServerName/

Dear @Reedy we both came to the same conclusion: the MediaWiki code stops in the last second, when actually trying to perform the action, the action is not performed, when "edit" right is missing on which the action depends.
So my observation appears to a mere cosmetic problem when the User rights are listed on the SpecialPage. My issue should be reformulated as a documentation and SpecialPage improvement. Let me know, if you want me to formulate a new bug - or if you prefer to take over (what I prefer).

In T227399#5311400, @Reedy wrote:

Are you actually able to do those actions without the edit right? Or is it just how things appear on Special:ListGroupRights?

And, @Reedy, it can be that the documentation is right, that for (actually, for example) "moving" a page the "edit" right is required, but finally (when a user without "edit" right tries to "move") this action is blocked. But if this is the case, the documentation should be corrected, and the SpecialPage should be reformulated, if it shows "move" right but if the action is finally blocked at the last stage in the code.
(I don't expect that the code is written in that way).

Honestly, I have no hint, because in 2000ies, I always modified everything (including DefaultSettings), so I perhaps never noticed this "issue". In early 2010 I started to keep everything in LocalSettings and noticed the problem just right now.

So if admin removes USER EDIT right in LocalSettings, all dependend rights should be unset as well.

See above. Documentation says that for createpage, createtalk, move etc, EDIT right is required, too. Please test for yourself, pls. I am pretty sure, there is an overlooked bug in the user rights logic and documentation.

@Reedy for "User" (as mentioned in the issue title).

Hi, I recently came back to MediaWiki development, since a long time. I discovered PHP Notice: Undefined index: SERVER_NAME in /includes/GlobalFunctions.php on line 1432.

@Aklapper If at least someone confirms my observation, then I will try to fix this. It is as simple as to set $wgMaxCredits .

What the heck does this cryptic string mean?

@Aklapper What does this "comment" (date 20180615 10:04 AM) mean?

@Aklapper André, can you or anyone else please confirm my observation? It looks to be a regression which nobody noticed before.

@Aklapper André, can you or anyone else confirm my observation? It looks to be a regression which nobody noticed before.

Can someone of you (please!) confirm my observation? This helps me.

Hmmm, are you really sure that it is not a simple (and real) "bug"? Adding another column would make the whole code, and database scheme, even more complicated. (I need to check the issue in a reference wiki implementation. Later.)

RSS feeds are coming in a "zoo" of variants - please feel free to submit a pull request if you have a working fix for your problem. I can only tell you that image and image tags are not only difficult but can be dangerous for the page where these rendered.

(see also https://wikitech.wikimedia.org/wiki/Incident_documentation/20160907-Android )

If I may ask, which portions of the Main Page do you find the most useful? (i.e. what do you find missing from the feed?)

@bearND Thanks for swift answer.
By the way, as I don't like the new app start page - I wish to start with my last seen page, or with the current Main Page:

Ah, so this is a new issue ? Please update then the App as soon as possible, thanks.

Server issue ?

App version 2.3.152-r-2016-08-18

@Aklapper I don't understand your comment.

I found, that when I use the "preview" of the PediaPress rendering process, the table are correctly shown. However, as reported, the PDF rendering of Wikipedia stills fails to render tables.

@Aklapper thanks.

Tables _were_ rendered formerly, see https://upload.wikimedia.org/wikipedia/commons/thumb/1/18/MediaWiki_Developer's_Guide_-_photos_of_a_printed_book.png/500px-MediaWiki_Developer's_Guide_-_photos_of_a_printed_book.png but are not currently.

I find it ridiculuous - if it is really true - that Extension Collection is not supporting the rendering of simple tables.

Reedy: thanks.

@Dbrant yes, thanks for the idea for doing it in a fork in parallel to my other projects https://github.com/Wikinaut/wikipedia-app .

ad #1.1 I will fix this, too.
ad #1.2 A mix of incognito and standard was unwanted - I coded that: initially one could decide not to remember search history and article history with separate settings - but as said, it was unwanted.
ad #1.3 I think that saving pages is an intended action of a user, and should be available, but could technically of course be disabled as well.

In T96546#1789838, @Niedzielski wrote:

@Wikinaut, I tried the latest patchset and I think it should stay on hold. I really like the idea but we need 1) new UI and UX for a real incognito mode and 2) true privacy.