I don't think this is something we actively want to support. In this instance, I'd suggest using one of the various webfont services, as it'll provide better support for the various browser/system combos and probably better load times.
- Queries
- All Stories
- Search
- Advanced Search
- Transactions
- Transaction Logs
Advanced Search
Jul 29 2023
May 1 2023
Apr 18 2023
(To be filed upstream?)
Jan 1 2023
Closing due to a lack of further info from the reporter.
Aug 28 2022
Is this problem still occurring? I just tested logging in on ShoutWiki Hub and I had no issues with logging in/logging out/logging back in.
Aug 11 2022
This was fixed on the same day by @lewiscawte (kudos!). The mistake was mine, sorry about that; I was trying to stop some cross-wiki spam originating from a certain IP range and as the spam edits (but not account creations) stopped, I figured the code snippet worked as expected, but I didn't test it. Again, apologies for this!
Jul 29 2019
Okay, this rather harsh and unfriendly communication from a staff member already painted a bad picture. Now, we have this, which is totally unacceptable and amounts to global users with "superpowers" overriding a local community/admin action. That's two strikes. One more and I leave. This is not the behavior that I expect from the staff team from a service like this.
But... while all RevDel leaves a trace, there are two levels of RevDel. The "lower level" can be restored by anyone with the deletionrevision right, which by default is assigned to the sysop group (as on Wikipedia). The "second level" can only be restored or viewed by users with the suppressrevision right, which is what the WP:OS is.
No. Oversight is the group that remains at Wikipedia assigned the RevDel permissions. Oversight was an extension that used to leave no trace that was replaced by RevDel. All RevDel now leaves a trace and can be restored, all this information is on the WP:OS page you linked - however, this does not matter as we are not granting that right to users.
I'm sorry, but they are not the same thing.
They're the same thing. They use the same feature. We're not giving out rights to them, and we won't be "cleaning up" logs and history in future, unless there's a leak of personal information or libel as stated in the system message for RevisionDelete.
@jack thanks for the response.
ShoutWiki is indeed not consensus-operated and individual wikis' settings generally speaking need consensus only from the existing community (if any); "global consensus" just isn't something that's a thing over here.
Jul 27 2019
@jack bump!
Jul 15 2019
Jul 14 2019
Fine.
Except that I'm not asking for revision suppression. I'm asking for revision deletion. There are two different things.
I think it needs consensus from all ShoutWiki users to have the supressrevision right on Independent wikis.
I don't know who or what "Miraheze" is/was or what that has to do with this request.
I am a former Miraheze user, I do not think that it is possible. Maybe it could be restricted to SW staff.
Jul 13 2019
Apr 21 2019
Hi @Brianna82 and apologies for the late reply!
Apr 11 2019
In T248#3826, @Brianna82 wrote:@jack Bump!
Mar 24 2019
Mar 16 2019
One thing I'd like to ask you right away: are these requests for all of ShoutWiki or for a single wiki? (If the latter, can you provide its URL/subdomain?)
Hi @Brianna82, thanks for filing this request! One thing I'd like to ask you right away: are these requests for all of ShoutWiki or for a single wiki? (If the latter, can you provide its URL/subdomain?)
This was done ages ago.
LookupContribs v. 2.0 fixed this for LookupContribs, but as discussed on IRC, we'll need that schema change to the lookupcontribs table to be able to make MultiLookup use LC's dataset.
Mar 8 2019
Sep 19 2018
Can I atleast get an explanation?
Almost everything on this list is not set the way you're requesting on purpose.
Sep 16 2018
Jan 31 2017
Dec 19 2016
Dec 17 2016
Dec 16 2016
Dec 8 2016
Nov 14 2016
Nov 11 2016
Sep 26 2016
Sep 21 2016
Sep 20 2016
Aug 15 2016
Upgraded for REL1_27, in rSHWK3967.
Jul 23 2016
Jul 12 2016
Jul 11 2016
I agree with the idea of merging both extensions. However, this isn't exactly a straightforward thing, because of the following:
- Usually users have the choice between a wiki user page and a social user profile, i.e. social profiles aren't enforced (SocialProfile's $wgUserPageChoice config var), so we need to take these into account...
- ...and even if social profiles were enforced, user boards and traditional user talk pages will coexist, because to my knowledge, it just isn't possible to get rid of user talk pages without significant core hacks. Generally speaking most users tend to prefer user boards over talk pages -- I guess it's easier to use those than to go to the desired user's talk page, click "edit", make changes, preview and finally save.
I'm in favour of either of these options - if we want to test the patch to HAWelcome and merge that it could be a great solution until a merge is completed.
Jul 9 2016
It would detect ad block users and put a nice little message asking them to consider unblocking us - nothing big or obtrusive or anything. But it hasn't really been thought about much besides a small, untested prototype I wrote a while ago.