Mar 29 2021
Pls move the page to become a subpage of my MediaWiki-Userpage, ty.
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.
Jun 14 2020
@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.
Dec 13 2019
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.
Dec 12 2019
(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.
Dec 11 2019
@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.
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.
Dec 10 2019
Here's our setup:
Nov 20 2019
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.
Nov 10 2019
Oct 27 2019
@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
Oct 25 2019
Jul 7 2019
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).
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).
Nov 26 2018
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.
Jun 15 2018
@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.
May 16 2018
Mar 23 2018
@Aklapper André, can you or anyone else confirm my observation? It looks to be a regression which nobody noticed before.
Jan 10 2018
Can someone of you (please!) confirm my observation? This helps me.
Jan 6 2018
May 4 2017
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.)
Dec 18 2016
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.
Nov 11 2016
Sep 8 2016
Sep 7 2016
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
Jul 26 2016
@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.
Jul 21 2016
Jul 15 2016
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.
Jul 14 2016
Nov 7 2015
Nov 6 2015
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.
Nov 5 2015
Oct 27 2015
A decision to drop this patch is not a good decision. I explained that already in the commit comment:
These setting should be reviewed now and then.