I can't even log to my session or on Shoutwiki.com.
Can't use my wiki, and add pages, since the Mediawiki software update.
- Queries
- All Stories
- Search
- Advanced Search
- Transactions
- Transaction Logs
All Stories
Jan 14 2017
Jan 12 2017
Not able to connect my account on shoutwiki.com, I can't be anything else than "anonymous user".
Same message than on my wiki, but in English: "There seems to be a problem with your login session; this action has been canceled as a precaution against session hijacking. Go back to the previous page, reload that page and then try again."
Jan 11 2017
Same for my wiki: http://immobilienbewertung.shoutwiki.com
Browser: Chrome 55.0.2883.87 m (64-bit)
Windows 10pro
The message box displays: "Votre session de connexion semble avoir des problèmes ; cette action a été annulée en prévention d'un piratage de session. Veuillez cliquer sur « Précédent », rechargez la page d'où vous venez, puis réessayez."
Jan 8 2017
Jan 7 2017
This is now working, feel free to link your accounts!
Dec 29 2016
Dec 28 2016
Wiki: http://pelaorolanga.shoutwiki.com
Browsers: Chrome, FF
Operative system: linux mint 14, windows 10pro
Dec 27 2016
I'm not sure this is something we want to allow or encourage. I don't think we've ever had a definitive discussion on this, but it does raise questions when we think about privacy and data collection.
Dec 26 2016
It was only on one of my computers, now it's on both. I can only use my phone, and I guess once I log off, I won't be able to connect again.
Some 1.27 change to LocalisationCache... fixed.
Dec 24 2016
It's an experimental extension not updated since February. I don't think this'll be getting fixed any time soon.
rSHWK4061
@Saftzie's talk page provides some useful insight on what's happening. MediaWiki is, for some reason, expiring ShoutWiki_session and ShoutWikiUserID.
Resolved by jack in rSHWK4047 and has been deployed
Dec 23 2016
Possibly related to T144
Dec 22 2016
I'll throw in my favorite solution, which Skizzerz proposed the last time I spoke to him about this: Let's Encrypt SSL certificates for <lang code>.*.shoutwiki.com, i.e. fi.*.shoutwiki.com (possibly relevant: this StackOverflow question). Looking at /trunk/languages/i18n/, there are currently 371 files in there so it would mean about the same amount of SSL certificates, which admittedly is somewhat of an ops nightmare, but the renewal of Let's Encrypt certificates can be automated and I'm sure someone already made a script for that.
I would imagine that this is a solution that'll be painful to implement initially but which wouldn't need too much maintenance after that and it would allow us to keep the current URL structure.
Dec 21 2016
The ISBN does now work on all pages, but the tracking category does only show 2 pages, althought I have the ISBN on several hundred pages.
http://roses.shoutwiki.com/wiki/Kategorie:Pages_using_ISBN_magic_links
In T152#2194, @bergmann.lat wrote:http://roses.shoutwiki.com/wiki/Baron_J._B._Gonella#Literatur_.E2.80.A2_Literature_.E2.80.A2_Litt.C3.A9rature
Here it works but shows in red: "Pages using ISBN magic links". That should not be there!
Actually, as per the official release notes I quoted previously, that's intentional: Their usage is discouraged, but if they are manually enabled, a tracking category will be added to help identify usage and make it easier to migrate away from.
Here it doesn't work:
http://roses.shoutwiki.com/wiki/Bourbon_Queen#Literatur_.E2.80.A2_Literature_.E2.80.A2_Litt.C3.A9rature
Yep, seems that what the MediaWiki.org manual page forgot to mention that caches need to be cleared after changing the value of the setting. I've manually flushed the cache for Rose-Biblio's main namespace, so now this issue should be properly resolved. :)
Dec 20 2016
I do not need PMID and/or RFC magic linking.
But ISBN is still not working as before.
http://roses.shoutwiki.com/wiki/Baron_J._B._Gonella#Literatur_.E2.80.A2_Literature_.E2.80.A2_Litt.C3.A9rature
Here it works but shows in red: "Pages using ISBN magic links". That should not be there!
Here it doesn't work:
http://roses.shoutwiki.com/wiki/Bourbon_Queen#Literatur_.E2.80.A2_Literature_.E2.80.A2_Litt.C3.A9rature
This is an intentional behavior change in MediaWiki 1.28. To quote the official release notes:
If you enter in your Wiki:
Name of Book, ISBN 123456..., ISBN 123456..., should be blue and work as a Link to a choice of book stores.
e.g
http://roses.shoutwiki.com/wiki/Alba_%27Semiplena%27#Literatur_.E2.80.A2_Literature_.E2.80.A2_Litt.C3.A9rature
What exactly do you mean? In order for someone to help you, you may need to be more specific.
Dec 19 2016
Done in rADMP26, tweaked in rADMP27, rADMP28. Further changes may be needed in the future but please place in thier own ticket
This is important for wiki creators/founders
Bug report
Bug report
Dec 18 2016
Can you provide further details on what wiki, browser and operating system you were using? It's also worth noting that there's an issue with sessions (T144) so can you try this again, ensuring it's not just because you are being logged out?
Okay - so upon not very extensive, further testing. My current conclusion is that:
Dec 17 2016
So I've been able to reproduce this after downloading an additional browser and using my bot account on Firefox.
In T144#2129, @lewiscawte wrote:
It seems I'm not alone.
Sorry about this! We turned Scribunto off temporarily during the upgrade as it was causing issues, and we had issues with harder solutions to debug as a more urgent priority.
FWIW, I just verified T146. Viewing a global Help: page logged me out, too, although the Help: page did display.
I delete all my cookies every time I close my browser, so every session is a fresh session. It's not a cookie issue.
Screenshots:
Long story short, SpamRegex is intentionally very restricted because unlike AbuseFilter and whatnot, it is a global tool. If it were administrator-viewable (let alone editable!), that probably wouldn't go so well because all you need is a valid email address to create a new wiki.
Dec 16 2016
Besides that, as far as I've seen, global help: pages have worked as intended, save for that redlink issue, which should be now fixed.
Fair point, assigning to Jack who is far more knowledgeable on this particular extension for input.
So it would appear that somewhere in the upgrade, AbuseFilter rights got unassigned (presumably by default upstream) and therefore resulting in sysops not having them. This, by way of array_merge, means staff also do not have.
Not really related to T145 - two different extensions. Should be fixed by rSHWK4043.