[00:09:58] Not really unsafe considering that's how wikis work in general lol [00:10:06] Older users are used to it and newer users just don't use talk pages [00:14:16] it's unsafe without a ton of additional security [00:14:21] Or does the base install revert vandalism [00:42:59] Users revert vandalism 🙃 [00:42:59] And there is edit history [00:51:30] so no [00:51:47] As I said before, the default and design of wikis is that people can do things themselves [00:55:49] Sure, but there's options to alter thta [00:55:53] Which is what I'm trying to figure out [00:56:02] I kind of don't need to know 50 ways of how not to do it [00:58:13] The thing is that there isn't really a way to allow only particular kind of edits [00:58:13] You would either need to create a new way to submit them or make an interface [01:04:26] So far I've been able to create a user group that only allows that group to create pages [01:04:30] or edit pages [01:04:47] Now I need a way to stop users from being able to delete entire Discussion pages but still be able to comment [01:04:50] It's about 80% there [01:05:00] The only remaining thing I need to be able to remove is users being able to edit source of the discussion page [01:20:06] Partial blocks for specific pages. Extension:AbuseFilter for things that fit definable patterns. [01:21:02] But the better idea is to just live with it. Most users are respectful of not editing what others say short of fixing typos. If they do something dumb, warn or block them [01:22:27] Chances are those people won’t be good editors elsewhere either [01:31:44] The real chances are that a bunch of dipshits will flock and deface [01:31:47] That's the reality [02:53:17] you're trying to do something MediaWiki isn't designed for; you might want to set up a forum install and direct discussion there instead [03:34:47] nah [03:34:54] It does exactly what we need it to [03:35:04] We just want to restrict users from defacing it or ruining finished pages [03:39:43] But make comments on discussion pages without deleting the entire thing if they decided to [03:39:49] Pretty simple really, not simple to implement annoyingly [03:54:14] If it were simple, it might already have been implemented 😉 [03:59:03] there's already ways of doing it, I just don't fully understand it [03:59:05] hence asking here [03:59:19] But so far I've just been told 10 reasons not to even try [04:00:55] which usually means either what you're doing is really just not worth it/not a good idea, or there isn't something "easy" that will get you what you want. [04:01:00] ok [04:01:58] Any idea why this https://www.mediawiki.org/wiki/Extension:StopForumSpam [04:01:59] causes this [04:02:05] [Y84GnkZTL0p-0If_PNUiRgAAzzY] 2023-01-23 04:01:35: Fatal exception of type "Error" [05:29:02] even if you figured out how to prevent people from blanking pages, they could still do stuff like using CSS to force a full-window display of whatever they wanted (Wikipedia templates have occasionally been vandalized in this way) [05:30:08] anyways, unless you know for a fact that your wiki would be an immediate and major target for this type of shenanigans (e.g. if you're trying to run some chan or booru thing), you're worrying way too much about this hypothetical [05:31:13] honestly you'll probably have more instances of undirected spambot talk page creations than you ever will with users intentionally blanking or vandalizing talk pages [06:06:43] How do you make visual editor paste copied text with hyperlinks [06:06:50] instead of dropping the hyperlinks and making it all plaintext [06:20:22] i had to use like 3 converters [08:38:27] what's the best antispam/security extensions? [08:38:51] ConfirmEdit just breaks the entire site [08:43:54] never mind i just fixed it [08:44:03] ok so if something breaks i just try to fix it for hours then ask here and it works instantly [08:44:05] kool [08:48:41] that happens more often than you can imagine :D [09:45:15] ok so I have the confirmedit installed [09:45:23] i use visual editor which breaks most of the captcha options [09:45:50] im using wfLoadExtensions([ 'ConfirmEdit', 'ConfirmEdit/QuestyCaptcha' ]); [09:45:55] the question appears when you try to post on discussion page [09:46:01] you enter the answer, hit submit [09:46:02] and nothing happens [09:48:06] what do [10:00:09] nothing happens means the form isn't submitted, you're returned to the same edit form...? [10:02:36] yes [10:02:44] the form isn't submitted [10:02:46] but the answer is correct [10:02:52] it just goes back to the same page [10:02:54] do you want to test? [10:03:24] https://tinyurl.com/5bjpabfd [10:03:32] I have everything setup as it should be [10:03:44] It isn't throwing any kind of error though it just doesn't enter the comment [10:08:02] ok [10:08:05] i think i figured it out [10:08:33] it was a missing ' [10:08:35] ffs [10:11:13] i got dc'd in case someone spoke. but yes it was a missing character [10:11:44] In normal fashoin i figured it out right at the end and after talking in here [10:18:37] :) [10:19:27] none of the decent captchas work with visual editor [10:24:13] Interesting. Captcha works on Wikipedia Visual Editor at least. I'm not sure if the one they use can qualify as decent, though [10:26:42] Most of the options listed on the ConfirmEdit page say they dont work with VE [10:26:49] or they're something stupid like 1+1 [10:27:01] i assume wikipedia coded in a captcha another way [10:27:20] but they have a lot of other security also, which i do not [10:27:21] yet [10:39:54] they all work with VE, and we use ConfirmEdit's FancyCaptcha on Wikimedia wikis [10:40:06] 🤷‍♂️ [10:41:16] The extension page states which ones do and dont work with VE [10:41:27] I tried the others already and they didn't work [10:41:34] !e ConfirmEdit [10:41:34] https://www.mediawiki.org/wiki/Extension:ConfirmEdit [10:41:35] Etymology: http://www.etymonline.com/index.php?allowed_in_frame=0&search=ConfirmEdit&searchmode=none [10:42:17] fancycaptcha looks a whole lot harder to install [10:42:36] the only mention to VisualEditor I see is "ReCaptcha will not work with the VisualEditor." [10:42:56] hcatpcha [10:42:58] recaptcha [10:43:09] basically any that aren't bot smashed already because its some lame math equation [10:43:25] which makes those options worthless as antibot/spam [10:43:45] (the ones that bots have already owned) [10:44:15] recaptcha has been largely bot owned already [10:44:23] QuestyCaptcha isn't [12:03:24] i think ReCaptcha should work as well. i remember someone working on that recently [14:08:59] Hcaptcha is also broken [14:09:29] Any of my sites that use it are getting tons of bot accounts [14:09:59] Those on questy are fine [16:01:08] Our documentation for new developers is really terrible [16:01:13] Like really terrible [16:01:23] I'm actually shocked anyone makes it through [17:53:25] So literally none of the mainstream ones [17:54:55] It's going to get even harder with ai these days. Even questy will be easily broken [18:02:59] As soon as it gets popular enough you will get "1000 captchas for 1$" service [18:57:20] hCaptcha works with VE since 1.35 [18:57:55] But yes the hCaptcha on create account got bypassed a few years ago [18:57:56] I'm not entirely sure how [19:05:02] Be useful to know why it's broken... [19:51:29] at one point the most common hCaptcha bypasses were through the a11y system, don't know if they fixed that [21:50:27] Honestly no idea, we tried disabling create account in Action API but it didn't help, so I suppose it is going through the page [21:51:09] We just decided to fallback to Questy for now until there is a better alternative [22:16:09] Questy's the only major antispam measure we've used on Yugipedia [22:16:49] it's not perfect by any means but we've gotten less than one spam page/edit per month on average, across the whole 7-ish years the wiki's been running, with ~1 million pageviews a month [22:44:20] Dinoguy10003726[ how complex are your questy Q's? [22:44:28] I have 1 that only community members should know [22:44:34] All the other captcha options are useless/don't work [22:45:08] they aren't, it's an incredibly basic fact about Yu-Gi-Oh! [22:45:13] and just a single question [22:45:23] and questy might be broken because of chatgpt at some point [22:45:27] (though we have some others in reserve in case that one ever gets widely broken) [22:45:54] if that happens, anti-spam will probably pretty much be dead anyways [22:55:00] mine is a question like what is X short for? [22:55:14] Only community would know the rest since it's a basic ass prefix [22:55:26] hopefully that'll stop bots [22:56:00] now [22:56:16] Still trying to figure out how to stop users from making/editing pages and editing source on discussion but they can make comments/topics on discussion [22:56:19] Then I can launch [22:56:32] questycaptcha works well as long as the generic mediawiki spambots don't have a reason to care about your wiki specifically [23:10:57] this is impossible [23:11:16] both are editing pages, you can't restrict one without the other because they're functionally the same action [23:11:53] the closest you can get is restricting page creation, which I think you've already been instructed on [23:13:13] if "stop users from making/editing pages" is one of your goals, MediaWiki may not be the best software for your use case [23:14:23] I pointed out yesterday that what they really want is some forum software instead [23:18:10] it should be doable if your discussion lives in a different namespace [23:18:35] you can get MediaWiki to do almost anything. Whether you should is a different question [23:21:04] oh I know. I wear the scars of attempts at ACLs. I stick to the namespace boundaries because preventing users editing the MediaWiki: namespace is a well-defined mechanism that's easily re-appropriated. [23:22:07] I've been trying to fathom the namespace guide [23:22:16] I can also remove links to 'edit source' using css [23:22:22] the average user won't try to circumvent it