MCBBS Wiki欢迎您共同参与编辑！在参与编辑之前请先阅读Wiki方针。
如果在编辑的过程中遇到了什么问题，可以去讨论板提问。
为了您能够无阻碍地参与编辑 未验证/绑定过邮箱的用户，请尽快绑定/验证。
MCBBS Wiki GitHub群组已上线！
您可以在回声洞中发表吐槽！
服务器状态监控。点击进入
本站由MCBBS用户自行搭建，与MCBBS及东银河系漫游指南（北京）科技有限公司没有从属关系。点此了解 MCBBS Wiki 不是什么>>
讨论:讨论板
| 欢迎来到 MCBBS Wiki 讨论板！ 您现在所在讨论板分区。下列列出了本站讨论板的所有分区。 如果您想发表的问题没有符合的分区，欢迎发表在讨论板分区。 | ||||||||
| 💭讨论板 | 🔨综合申请 | 👤申请职位 | 📜需求页面 | |||||
| 讨论 Wiki 问题 | 申请改名，页面删除，举报页面等 | 用户申请职务之处 | 收录用户需要的页面 | |||||
| 发表 | 监视 | 存档 | 监视 | 存档 | 监视 | 存档 | 发表 | 监视 | |||||
| 📝编辑请求 | 🔌技术讨论 | 🖼梗图收录 | MCBBS Wiki talkboard | |||||
| 申请编辑某个高权限页面 | 报告技术问题，提出功能请求 | 提交梗图 API 的图片收录申请 | License: CC BY-NC-SA 4.0 | |||||
| 发表 | 监视 | 发表 | 监视 | 监视 | ||||||
| 其他页面：Wiki方针 • 公告 • 沙盒 • 最近更改 • 封禁列表 | QQ群 • Discord群组 • Github | |||||||
讨论板（Talk Board）是用户可以向wiki社区讨论的平台。虽然用户也可以直接联系特定的管理员（尤其是活跃的管理员），但是在此处贴出跟更能保证有管理员会注意到并快速回应。请记得留言后签名（在末尾添加：“--~~~~”），未签名的讨论串将会被删除！
先别急着帖出问题，请先仔细斟酌以下几条：
- 此页面仅用于报告Wiki问题。
- 用户间的调解请求只有在双方无论如何都不能达成共识的情况下才可发表。
- 明确你的请求有一定意义。
建议删除模板 eee
建议删除：{{eee}}。
- 咏e 是一种违规行为，不值得提倡。
- 完全不值得四处宣扬——这模板就好像你把泥巴丢到别人的身上，还四处宣扬以此为荣。
- 咏e 的梗没有传播广泛到到值得单开一个模板。
- 这种模板会给人一种错觉——“咏e了就能像xxx一样出名了”。
- 不少用户曾被 咏e 骚扰，将这种违规行为拿出来摆到台面......未免也太无聊了。
- 考虑到可能会有人说“啊，照你这么说，那么其他幽默模板也没有存在的必要了嘛！”，我这里先提一句：
- {{混乱凝视}}：混乱是MCBBS管理员中较为出名的一位，且其已成为MCBBS用户间传播的一个符号；与 咏e 不同，这种符号的传播并不会鼓励违规行为——理由是 咏e 传播开之后，很快出现了变本加厉的破坏者，而混乱相关的梗火起来了并不会给其他用户造成麻烦。
- {{机翻有理}}：机翻已经是翻译圈子里绕不过去的梗，这个圈子门槛较高，一般不会混进为了出风头而故意到处搞事的小鬼——确实有，不过这种行为因为有门槛且对普通用户影响较小，没有限制收录机翻相关内容的必要。
- 作为比对，当用户使用50w个无意义字符污染版面的时候，所有点击进去的用户都会注意到浏览器未响应，而一个用户发布机翻内容的时候，只会骂一句然后退出。
- 与机翻相比， 咏e 门槛低，影响范围大，防不胜防（机翻搞事一般是发主题帖，好发现好处理，咏e 可以发生在回帖和评分中），且这个“咏”奇葩的称呼总是会招致不知哪里冒出来的效仿者。
- {{一本道}}：这个模板本身并不鼓励四处胡说八道，所有抖机灵的页面都需要挂上这个模板提醒阅读者“这个页面有开玩笑的内容”——以娱乐为目的的侃大山时，抖机灵可以带来笑容，正经说事的时候就麻烦正经一些。
- 我注意到最近新出了一个条目“咏士”，咏士本意是诗人，褒义；这里却指代 咏e 的人，且谐音“勇士”，且不提是否是“褒义贬用”，我个人很是疑虑其会不会引出新的破坏者。
—— Salt lovely「敢竭鄙怀，恭疏短引」 2020年8月30日 (日) 20:36 (CST)
(－)反对eee模板没有提倡这种行为，反而说“务必遵守论坛规章制度”，这已经是一个不提倡的信号。至于“咏士”，个人认为有反话捧黑嫌疑。--洞穴夜莺（讨论） 2020年8月30日 (日) 23:03 (CST)
- (：)回应 ？
- 这种模板带来的影响不是一句“务必遵守论坛规章制度”就能盖过去的，更何况——这个模板表达的“咏e”的行为在这个模板的表现力远远超过了这句话。
本条目经过e 道 阳 光认可，适合热衷作死eee的用户阅读。在eee前，请您eee切勿eee过度，过度eee可能会招致别人eee乃至91.35W个e。
这几句话的重点集中在“咏e”上，或者说，整个模板的重点都在“咏e”上，与之相对，“务必遵守论坛规章制度”这句话显得有些无力。
举个现实一些的例子，想象一下有个喜欢把泥巴扔到别人身上的讨厌鬼，照理来说大家都会自动疏远ta，但是现在有几个人，把其扔泥巴的事情到处宣扬。
“这不是什么值得提倡的事情吧？”“我们讲完了这件事之后会加一句‘你可不要这样哦’。”
？ - “咏士”这个词我知道你们的想法是是褒义贬用，我上文提到了，请仔细看。
首先要主义，任何褒义贬用、贬义煲用的语言表达，都是要结合上下文的——空口一句“咏士”，不知道来龙去脉的人怎么知道这是贬义？
书接上文，所谓的褒义贬用本身需要结合上下文，“咏e”这个用法直接来源于一道阳光的帖子标题——若往人身上丢泥土的人将这种行为称为“菲尼术”，然后大家口口相传，将往人身上丢泥巴的行为称为“菲尼术”，又把这么做的人称为“菲尼士”，到处玩梗。
“这种行为不值得提倡吧？”“我们这是在反话捧黑呀。”
？ - 最近“咏e”这种低级破坏行为越来越多，或者说，效仿者越来越多，这个梗的传播恐怕是诱因之一。
一个离得比较近的例子：钴版事件中的“咏e”者，都是BBSWiki的编辑者且都知道“咏e”这个梗，其中至少一人编辑过“咏e”这个条目。 - 你可以翻看“一道阳光”和“咏e”的历史记录，几个月前的编辑者在这两个页面里大量使用“褒义贬用”和“反话捧黑”，但是整体观感就是在给这种行为招魂。
“咏士”条目里，只有一个页顶模板和“定义”中明确提到了这是违规行为；就好比一个法制节目，全程介绍犯罪者和作案手段，但是只在节目开头和中间提了一句这是违法行为——同时起了一个好听的名字（劫富济贫、梁上君子之流）描述这种违法行为，“这是反话捧黑”。
- —— Salt lovely「敢竭鄙怀，恭疏短引」 2020年8月30日 (日) 23:54 (CST)
(＋)同意我也一直这么想，只是暂时还没说的。我也一样觉得wiki在咏e的增多方面起到了不小的作用，我还曾经想过把一道阳光删了解决问题（但后来打消了这个念头），但如此这些页面语调明显不当。应该作出整改。--
自由李代数 讨 贡 狗娃安慰噶喔。 2020年8月31日 (一) 06:39 (CST)
还有，最近出现了较为明显的滥用{{违规文化相关内容}}模板现象，会不会和这个有关？-- 自由李代数 讨 贡 狗娃安慰噶喔。 2020年8月31日 (一) 06:40 (CST)
(＋)同意。补充一点，目前10个页面包含了{{eee}}。--
QWERTY_52_38讨 贡 2020年8月31日 (一) 12:33 (CST)
(－)反对。任何有认知能力的用户都能很轻易的看出咏e是违规行为，如果仅仅是因为这种原因就停止收录此类内容，那末地人才名录也应该被删除。不过可以修改一下模板内容，强化对咏e是违规行为这一事实的表述和警告。--Xiang xge（讨论） 2020年8月31日 (一) 14:22 (CST)
- 的确，论坛内有相当一部分缺少对坛规版规有正确认知能力的用户，但他们进行违规行为更多应归咎于他们自身的素质，而不是简单的几个梗的流传。事实上，我认为“咏e”这个梗所做的仅仅是让更多本就不把坛规放在眼里的用户集中选择了“咏e”这一方式，即使没有这个梗他们也早晚会进行违规行为。而曾经遵守规章，因为看到“咏e”这个梗就去违规的，绝对是极少数。
- 关于“最近‘咏e’这种低级破坏行为越来越多”这种说法，除了515钴版事件以及零零星星的几个用户后几乎找不到所谓“大规模咏e”的情况了。515钴版事件发生于一道阳光事件前后，一道阳光对这一事件以“咏e”的方式发生的确有带动作用，但我认为这仅仅是对这一事件以“咏e”的方式发生有带动作用，在当时的情况下即使没有“咏e”这个梗这一事件也会以其他的方式展现。
- 删除此类内容是一个不好的开端，很可能导致以后更多的页面因为此类原因被删除。比如末地人才名录，以上面的方法来解释我完全可以说“空口一句“末地人才”，怎么知道这是贬义？”更别说的确也有在末地大肆违规还叫嚣着要自己被收入人才名录的情况发生那么，这个页面是否也该被删除？而混乱凝视这类模板，这可以被说成是对管理员的不尊敬（毕竟也的确有在茶馆说yys不好被警告的）。---- xiang_xge·讨论/贡献 2020年9月9日 (三) 12:43 (CST)
(－)反对既然已经说了一般心智不成熟的才会模仿，正常的用户并没有可能这样做。但是，我觉得应该是所有有eee的模版都应该有个敏感内容的标牌，或者从首页的梗文化栏删除。 顺便告诉你们一下，我昨天刚咏了630000个e。--用户:沙漠之鹰xzy（讨论） 2020年10月8日 (四) 14:46:33 (CST)
- (：)回应你的反对不仅没有好好表达你的观点，反而坚定了我要删除这个模板的意志。—— Salt lovely「敢竭鄙怀，恭疏短引」 2020年10月19日 (一) 11:21 (CST)
(－)反对每个梗都有每个梗的文化，有这个模板只是为了记录有这种事情。正常用户应该不会干这种事 ps:本人所指的正常用户是“拥有正常智商并且能正常思考的现代人” --Gear? - 论 / 献 2020年10月11日 (日) 15:51 (CST)
- (：)回应 请不要把人看得太理智了，谁都是从愚昧无知中走来的……
- (＆)建议 个人见解：既然你已经是“拥有正常智商并且能正常思考的”人，那么你要做的就不应该是对那些心智尚不健全的人展示可怜的优越感，而是引导其免于误入歧途。—— Salt lovely「敢竭鄙怀，恭疏短引」 2020年10月19日 (一) 11:21 (CST)
- (：)回应齿轮-gear：我之前表达过一次，我还要再说一次：我们需要考虑的不是正常用户，而是目前“不能完全正常思考的人”。混乱主要是他们造成的。
- (：)回应容我说句不是那么好听的话，MCBBSwiki建站的初衷之一便是收录MCBBS相关的梗文化，而不是引导用户规范言行。如果你们真把wiki当做论坛新手引导网站了，那我们干脆只收录版主们和版规算了。我不是说应该提倡违规，在条目里加入引导用户遵守坛规版规的语句也是必须的，但仅仅是因为极少数破坏分子而删除一些被论坛用户广泛认同是“重大事件/梗”的内容我认为是欠妥当的。我依然还是那个观点，心智不成熟、漠视坛规版规的人早晚会去违规的，根本不需要什么“咏e”来带动。前面有人说咏e梗的流传使得大量用户去咏e，但实际上根据我的观察，515钴版事件之后几乎没有用户大规模咏e的现象发生了。除了wwz这样的零星破坏分子，515之后的咏e几乎都是一道阳光的行为。我们当然谴责一道阳光，但不能，也没必要就此认为其他用户还会效仿。---- xiang_xge·讨论/贡献 2020年10月22日 (四) 14:18 (CST)
- (：)回应
- 的确，Wiki的初衷并非引导用户遵循论坛规章制度，但Wiki至少不能在这方面起到负面作用。
- 请审题，我们不在讨论“删除重大事件条目”，而只是在讨论“删除模板”，而模板并没有很多的实质内容。所以你后面的讨论都并非在针对话题。
- 我就认为其他用户还会效仿。心智不成熟的人永远是少不了的。“ 顺便告诉你们一下，我昨天刚咏了630000个e。”这句话就在这页里出现了，你认为这是不是属于恶劣影响呢？
- --< 自由李代数 讨 贡 狗娃安慰噶喔。> 2020年10月22日 (四) 19:11 (CST)
- （主要原因）提一句你们可能见都没见过的一个大型（指面积大）模板“一道阳光”，我意识到这个社区里已经出现了将破坏行为当谈资和娱乐的风气——没必要什么事都带着批判的目光，我只要求别整这种烂活（任何圈子的玩梗都应该圈地子萌，打着反对的旗号做宣传是在作甚）。
- （次要原因）作为处理Wiki破坏事件的管理员，我从个人情感上厌恶这种行为——“咏e”行为作为一种破坏行为，就应该限定在其页面内（除非必要情况，比如介绍某人时提到其“咏e”过），就像“机翻”相关内容不应该在没必要的情况下跑去其他条目，假如你是处理机翻行为的管理员，我相信你会去玩“暴徒产卵”的梗（甚至于玩得很开心），但你肯定不希望看见“机翻”梗在Wiki本不想干的条目到处出现，以至于有人为了被收录而故意机翻——为了被收录而故意去末地搞事的人已经出现了，删除人才名录肯定不合适，只能在页面内容和引导上操作。
- （次要原因）删除这个长相奇怪的模板（啥，你们不觉得这个配色很奇怪吗）。
- 没必要考虑如果真的删了这个模板会发生什么，我的目的是告诉各位别拿破坏行为当谈资，这个长长的讨论串某种意义上是作为一个警告留在这里的；只要这个讨论串还留在这里，下一个整这类活的就不会出现（要是真有人这么搞了估计轮不到我动手）；这个Wiki是个娱乐Wiki，整活是其生命力的重要来源，我作为最早的一批编辑者兼管理者，总不至于有摧毁这个社区的想法。
- —— Salt lovely「敢竭鄙怀，恭疏短引」 2020年10月24日 (六) 13:52 (CST)
- (＋)同意e道阳光来到隔壁咏e了（235856个e），这种行为十分恶劣，烂梗不提倡不值得玩下去。我不觉得强调咏e是违规行为有什么意义可言，搞破坏不需要理由，封禁用户才需要理由。--Lxazl5770（讨论） 2020年10月12日 (一) 10:22 (CST)
- (－)反对这事和{{eee}}有啥关系吗？e道阳光本来就会咏e啊？--洞穴夜莺 2020年10月23日 (五) 22:45 (CST)
- (：)回应那个事好像和阳光无关，最近Ta在哪里都没有活跃记录，IP也不重合 --用户:沙漠之鹰xzy（Talk） 2020年11月7日 (四) 12:28:47 (CST)
(－)反对(个人认为)创造这个模板的意义是记录这件事情，并引以为戒。把这个模板保留下来又有何不妥呢？ --Gear? - 论 / 献 2020年10月29日 (四) 21:51 (CST)
- (：)回应我现在来想，觉得吧，这个估计是阳光之前破坏wiki时设的模版，记录的是Ta的劣迹；我觉得如果不犯了也就没必要不断的炒冷饭了@永远的友人 --用户:沙漠之鹰xzy（Talk） 2020年11月7日 (四) 12:25:34 (CST)
(－)反对 咏e这类极其明显的违规行为，更像是友善的玩梗，只需在有关页面加入警示，而非全部否决。--天涯小金 2020年11月13日 (五) 21:40 (CST)
- (：)回应友善？你管随意嘲笑他人叫做友善？既然咏e看出是严重的问题，用户都不大喜欢，这种属于违规，不应该随意传播；上个月Minecraft Wiki被咏e还不够惨烈？ --用户:沙漠之鹰xzy（Talk） 2020年11月14日 (六) 18:35:04 (CST)
- (：)回应哪里看出来嘲笑了？--洞穴夜莺 2020年11月21日 (六) 00:31 (CST)
- (：)回应这种行为不过是像穹妹之前说的假定善意，实际上都在讽刺；既然没人是支持阳光这样的行为，相反，一次次这样的咏唱也一次次把阳光引回来了，前几天还看见帽子发的一个；这种实际上就是明摆着的哗众取宠，真正的解决方案我觉得还是不要这样继续下去了，这个严格来说不是梗，至少是个令人反感的。 --用户:沙漠之鹰xzy（Talk） 2020年12月9日 (三) 19:50 (CST)
- (：)回应哪里看出来嘲笑了？--洞穴夜莺 2020年11月21日 (六) 00:31 (CST)
(☩)意见：我认为这个话题，可以到此为止了。
这个话题，发起已经有四个月了，除了李代数、盐酱、斯乌几个明白人之外，其他的差不多，都是反对的。
而且纵观整个讨论串，许多人都抱着吃瓜心态，更像是一群门外汉在吵，盐酱等人客观分析了这个模板的危害。至于移除这个模板？不过是制造几个红色链接，手动移除即可。但是持反对态度的人，却是对阳光抱有近乎病态的“假定善意”，而且某些人还对所有观点都加以理由不明的驳斥，显然就是想继续玩烂梗而已。“民主”在这一方面，很像米国，不是么。
这个讨论串，如果接下来几天没有回复，我就封存了。
--
MashKJo-{（用户页）/（讨论页）/（贡献）}-61 2020年12月2日 (三) 18:19 (CST)
- (：)回应问题不大，从一开始我就不对移除这个模板抱期望，如果这个模板受多数人反对，我会直接删除而不是开一个讨论串。不过即使如此，我的态度依旧是这个模板应该删除。
- 这个讨论串的意义，与其说是要求删除，不如说是一个广义上的警告。这是一个娱乐玩梗Wiki，但是任何事都得有个限度，我不希望玩梗玩到搞错了玩梗的目的，玩梗是为了娱乐，玩违禁行为的梗则应该在娱乐的同时提醒自己不要犯一样的错误，而这个模板已经开始在试探这条线了——我希望大家不要搞错了“令人不悦”的线和“错误”的线；再加上之前介绍违禁行为的页面中时不时发现的不当用词，我发觉这里出现了模糊玩梗界限的势头；出于遏止这种势头的目的，我发起了这个讨论串。只要这个讨论串存在（无论是讨论版还是存档区），就不会继续出现这种模板（当然要是出了更过线的，那当我没说）。
- -- Salt lovely「非谢家之宝树，接孟氏之芳邻」 2020年12月2日 (三) 18:40 (CST)
(＝)中立有一说一，就算是删除了eee的模板，咏e、一道阳光等页面还是在的，单纯删除一个模板起到的作用不大。 --用户:居仕 2020年12月6日 (七) 17:24(CST)
- (：)回应实际上，除此以外，我觉得阳光黑历史我觉得还是开一个页面记载好，至少不再会有人不停地卡死循环。 --用户:沙漠之鹰xzy（Talk） 2020年12月9日 (三) 19:53 (CST)
且不论内容，模板的样式看着就很违和。我的态度还是和之前一样，支持删除。--< 自由李代数 讨 贡 狗娃安慰噶喔。> 2020年12月6日 (日) 20:08 (CST)
关于收录范围扩展
为了Wiki转正常化我提议扩展收录范围。
不知各位是否同意bbswiki扩展收录范围。
如果同意，请推荐要的收录范围并说明理由。
不同意，请说出理由。
例:
- (＋)同意建议添加收录范围[原创皮肤|材质资源],因最近有人(某Elen)反馈为什么不收录皮肤等资源。
- (－)反对太操之过急，应一步步来。
Eicy（讨论） 2020年8月30日 (日) 21:55 (CST)
(：)回应建议移除形式限制，允许任何知名度高的作品。--洞穴夜莺（讨论） 2020年8月30日 (日) 22:55 (CST)
(：)回应我认为mcbbs内的一切有质量作品都可以，且应当收录。-- 自由李代数 讨 贡 狗娃安慰噶喔。 2020年8月31日 (一) 06:42 (CST)
(：)回应像“水楼”“卤蛋神教”等我都认为是符合Wiki大方向且值得收录的，但都不在（目前的）收录范围内。梗是算不上的，别的更说不上。那么我觉得是需要扩展范围的。只是想不出来具体扩展到什么样的范围。--< 自由李代数 讨 贡 狗娃安慰噶喔。> 2020年10月19日 (一) 21:58 (CST)
- (☩)意见：“水楼”大可算作论坛优秀/著名主题贴，可以添加相关分类/模板进行收录。“卤蛋神教”其实还是属于梗的。
- 另外，我其实有收录QQ群的意向（之前计划在项目页面撰写wiki相关QQ群信息，由此想到）。-- MashKJo-{（用户页）/（讨论页）/（贡献）}- 2020年10月19日 (一) 23:09 (CST)
- (＋)同意建议拓宽收录形式，如果可以，建议直接取消掉形式限制。--Gear? - 论 / 献 2020年10月29日 (四) 21:48 (CST)
(＆)建议我认为那种原创数据包、模组、材质、皮肤等那种都要收录，只要不是那种低俗的的，就可以收录，不然别人怎么看？只会觉得这是个只是玩梗的一个片面wiki。 --用户:沙漠之鹰xzy（Talk） 2020年11月7日 (四) 12:25:34 (CST)
- ?
- wiki建站初衷就是玩梗，现在虽然有很多正经条目，核心仍然是沙雕。我倒不希望bbswiki变成萌百那样——从AGC百科变成萌娘版wp大杂烩。-- MashKJo-{（用户页）/（讨论页）/（贡献）}- 2020年11月7日 (六) 17:12 (CST)
- (：)回应好吧，那么我觉得至少在用户页放一些作品链接和简单介绍应该可以吧，不要专门开页面 --用户:沙漠之鹰xzy（Talk Contribution） 2020年11月8日 (四) 19:12:18 (CST)
(：)回应wiki建站初衷就是穹妹想玩梗，不正经的东西反而才是你wiki的核心，范围我感觉除了服务器和纯水讨论不行。但是总归泥潭的作品质量参差不齐，有的作品确实放到wiki上非常的违和。但是最主要的还是放开了以后就水起来了，巡查工作+234%虽然现在也还好，不是很多，再一个呢就是救一个编辑失败的页面比你自己写累得多，不过仍可以接受。范围的话，本来就有人写梗进来，放不放开好像对水怪区别不太大，最主要的还是那些正经的作品,感觉可以适当要求合并同类项，把同系列的东西丢一起，防止页面虚多。--又名文章生成器（讨论） 2020年11月22日 (日) 08:32 (CST)
(＝)中立隔壁萌百的收录范围从最开始的ACG（动画漫画游戏）到现在ACG沾点边就能找得到，也算是百科类网站发展的趋势；不过MCBBSWiki只是一个娱乐百科，虽说理论上这里需要收录的是MCBBS的内容，但不代表MCBBS以外的不能收录，也不代表是MCBBS的就要收录；综上，中立态度。-- Salt lovely「非谢家之宝树，接孟氏之芳邻」 2020年11月25日 (三) 19:26 (CST)
- (＋)同意 建议收录更多的用户与小组
WikiEditor编辑器修改插件
我在隔壁BWIKI编辑的时候，为了提高搬砖效率，写了一份JS，用于给WikiEditor添加新的功能（之前有在群里提到过）。
我写了一个Addon（插件），放在了MediaWiki:Addon-WikiEditorModify.js，调用代码见下：
$(document).ready(function(){ // 文档准备完毕后执行
//编辑器更改
loadAddon('WikiEditorModify')
})
//加载Addon-XXX.js
function loadAddon(s) {
mw.loader.load("//mcbbs-wiki.cn/index.php?title=MediaWiki:Addon-" + s + ".js&action=raw&ctype=text/javascript"
, "text/javascript");
}
loadAddon('WikiEditorModify')不一定要放进$(document).ready里面，详见我的JS。
用起来感觉不错（毕竟调整了一晚上+一下午），我添加了系统变量和解析器函数功能。小编辑继续用wikiplus，写页面就用wikiEditor（点击编辑之后跳转的页面）（效果和页面底部的editTools是一样的）。
不过这个东西本来是写给隔壁BWIKI用的，所以很多功能并不适配，希望各位出出主意。
已知的不适配功能：
- 快速插入 -> 常用模板
- 图标和多图标
- 同级子页面和多同级子页面
- 折叠
- 参数
- 魔术字 -> 解析器函数
- CSS样式表
- 获取页面和获取页面+
—— Salt lovely「敢竭鄙怀，恭疏短引」 2020年11月7日 (六) 16:12 (CST)
(＝)中立刚才试了试，个人看法：我觉得没啥用其实我觉得页面底端的EditTools更没啥用，因为对我来讲点个按钮比输入代码要慢。但这对新人要友好一些（原来的编辑器真的啥也没有），所以中立。--< 自由李代数 讨 贡 狗娃安慰噶喔。> 2020年11月7日 (六) 16:34 (CST)
关于Wiki编辑等级
这个想法是很不错的。不过目前我有几点建议：
- Lv40，Lv50和Lv60的颜色差距稍微大一点（因为Wiki几个活跃用户都在40-60级，颜色区分度太小了难以快速分清）。
- Lv1-Lv20的间隔太小了，用户刚编辑几次就十几级了，不太好。
- 或许可以加一个模板参数控制是否对每项积分生成扇形图？（类似{{MCBBS积分分析}}）
--QWERTY770 61 讨 贡 2020年11月17日 (二) 19:54 (CST)
这东西最开始是绵羊设计的，我重写了代码+移植到这个Wiki，等级数值什么的都没改，所以看起来哪里都有问题..
- 积分，我建议的公式：等级=最小值(总积分^0.5, 100)。
- 颜色：我懒得配色，让绵羊上。
- 扇形图：完全可以，不过可能代码要重写一半。
—— Salt lovely「敢竭鄙怀，恭疏短引」 2020年11月17日 (二) 20:07 (CST)
颜色其实没必要那么复杂，直接用彩虹色（论坛那种）不就行了。--QWERTY770 61 讨 贡 2020年11月17日 (二) 21:27 (CST)
我个人觉得这东西更适合用户页，而非条目页。-- MashKJo-{（用户页）/（讨论页）/（贡献）}- 2020年11月17日 (二) 23:09 (CST)
这个配色其实就是B站0~9级的等级配色，因为我懒。还有就是这个积分等级参考了MCWiki，起步阶段就是冲冲冲，然后升级速度就会越来越慢。--
Sheep-realms（讨论） 2020年11月17日 (二) 23:25 (CST)
我同意MashKJo的观点，看了一下放在条目页不太和谐，上下不搭。至于等级积分吗，我倒觉得问题不大；但颜色是需要改改，61、59、58、56、53级后面跟着就是40、38级什么的，是应该区分一下--< 自由李代数 讨 贡 狗娃安慰噶喔。> 2020年11月18日 (三) 13:14 (CST)
可以在{{PersonInfoBox}}里加入一个Wiki积分等级参数。毕竟爱发电（外站）账号都可以写入模板了，本站的内容不是更应该写进去吗。--QWERTY770 61 讨 贡 2020年11月18日 (三) 17:45 (CST)
啥玩意儿？编辑等级？我试试： --用户:沙漠之鹰xzy/签名（Talk）2020年12月13日 14:37:10 (CST)
建议实装免责声明
如题，免责声明草稿已经在我的用户页放了近4个月了，都开始长蘑菇了，建议实装。
—— Salt lovely「敢竭鄙怀，恭疏短引」 2020年11月24日 (二) 13:43 (CST)
- (＋)支持--QWERTY_52_38 讨 贡 2020年11月24日 (二) 19:24 (CST)
- (✓)通过 管理组没有异议。 -- Salt lovely「非谢家之宝树，接孟氏之芳邻」 2020年12月16日 (三) 11:44 (CST)
语法高亮插件做好了
用的是Prism语法高亮，调用方法：
// 在 $(document).ready 中调用
$(document).ready(function(){
loadAddon('loadprism')
})
// 这个函数封装了 mw.loader
function loadAddon(s) {
mw.loader.load("//mcbbs-wiki.cn/index.php?title=MediaWiki:Addon-" + s + ".js&action=raw&ctype=text/javascript"
, "text/javascript");
}
注：不建议直接调用 Addon-prism.js ，因为这个语法高亮JS需要指明语言，所以我写了 Addon-loadprism.js 用于预处理页面中的 pre 元素。
目前我写了3种方法猜测 pre 中语言类型。
- 如果给pre套一层父元素（比如套一层div），在父元素的
class里面可以指定语言。- 比如
<div class="cpp"> <pre> *** 代码 *** </pre> </div>可以指定 pre 里面是C++。
- 比如
- 会根据页面名来猜测语言。
- 比如
XXX/common.js会猜测是 JavaScript，XXX/e.vb会猜测是 VisualBasic。
- 比如
- 会根据内容来推测语言。
- 比如
#include会猜测是 C，[/color]会猜测是 BBCode。
- 比如
- 默认是Wiki语言。
-- Salt lovely「非谢家之宝树，接孟氏之芳邻」 2020年11月26日 (四) 00:59 (CST)
- (：)回应第一行行首和后面的行首没有对齐，此外Java似乎没有高亮。https://i.loli.net/2020/11/28/sWpeFzKbSdcZ2U6.png" --洞穴夜莺 2020年11月28日 (六) 10:59 (CST)
- (：)回应 第一行对不齐是CSS的问题，目前除了取消padding以外没发现好的解决方法（我好菜啊.jpg）；java语法高亮已实装。-- Salt lovely「非谢家之宝树，接孟氏之芳邻」 2020年11月28日 (六) 23:26 (CST)
$(function(){
// 挂在GitHub，用CDN获取
mw.loader.load('https://cdn.jsdelivr.net/gh/Salt-lovely/MCBBSWikiPrismLoader/load.js')
})我把这个插件挂在了GitHub上，利用CDN获取。-- Salt lovely「非谢家之宝树，接孟氏之芳邻」 2020年12月16日 (三) 16:22 (CST)
现在更进一步，做成了小工具，可以在参数设置中直接勾选启用。-- Salt lovely「非谢家之宝树，接孟氏之芳邻」 2020年12月16日 (三) 16:55 (CST)
- (：)回应 不過其實為甚麼不直接使用 SyntaxHighlight 插件？這個插件 2013 年起已經內置在 MediaWiki 了……--<JasonHK /> 2020年12月20日 (日) 21:19 (CST)
- (：)原因很多，主要是两点，一方面是这里没有使用这个标签的习惯，另一方面是不太方便定制（放在Github仓库，用CDN获取的话，我可以很方便地增减功能，修改CSS，跟随Prism更新，一切修改完毕后发布一个release即可）。 -- Salt lovely「非谢家之宝树，接孟氏之芳邻」 2020年12月20日 (日) 21:36 (CST)
重要讨论：关于Mod收录
三个问题：
- “在MCBBS几乎没有知名度且非MCBBS坛友原创的作品禁止收录”。如果两个条件满足一个是否收录？
- Mod应该收录哪些内容？是全面介绍功能，还是偏向收录相关梗？如果一个Mod内容较多，是全部详细介绍完还是选择仅是列出大概功能，不详细介绍（假设该Mod并没有自己的官方Wiki）？
- 如果一个Mod把某些论坛用户写进去了，是否允许在对应用户页面写类似“该用户已被XXX模组收录为YYY方块，作用是ZZZ”这种句子？
--QWERTY_52_38 讨 贡 2020年12月1日 (二) 21:37 (CST)
回答：
- 这是相当于not((not a) and (not b))，等价于 a or b，所以按照这句话推断是可以的。
- 我个人偏向认为能写多少就写多少。
- 看模组知名度吧。如果知名度较高那么我觉得可以。
--< 自由李代数 讨 贡 狗娃安慰噶喔。> 2020年12月1日 (二) 22:38 (CST)
(：)回应
- 且，这个只要语文好一点都可以理解吧？= = 只满足其中一个的允许收录，但不支持。
- 关于这点，没有硬性要求和限制。至于梗，主要只有加速火把有吧？有就写，没有就不写。至于详细介绍还是算了，毕竟MCBBS Wiki不是大杂烩。
- 顺便说一下，一个MC MOD的wiki一般都会在Fandom建站，少部分大型MOD（AoA、Aether）才在Gamepedia建站。
- 可以，方针不禁止则可为。但要注意不要使其显得突兀。
-- MashKJo-{（用户页）/（讨论页）/（贡献）}-61 2020年12月1日 (二) 22:52 (CST)
关于链接“被锁”
最近，我看到一些MCBBS帖子链接被标注了“被锁”二字（如页面燃雪听风#Ta的教程），但我觉得这完全不需要，应该把所有的这类字眼去掉。理由如下：
- 我们有挖掘卡来查看被锁帖子。
- 被锁帖子除了用挖掘卡，还有一大堆办法查看（如
?action=printable，Discuz archive，百度快照）。 - （最重要的一点）帖子的状态是会变化的。或许会被锁上，或许会被打开。我们不可能每天都去查看Wiki每一个帖子链接并更新页面。而如果不能及时更新状态，“被锁”二字就几乎没有意义（甚至还有副作用），因此还不如全部删掉。
- 同时，Wiki有那么多链接，其中实际被锁的不计其数，但只有一部分加上了“被锁”。与其把其余所有被锁的链接都加上“被锁”，不如把现有的这部分去掉，统一格式。--QWERTY_52_38 讨 贡 2020年12月7日 (一) 20:28 (CST)
- 同时，Wiki有那么多链接，其中实际被锁的不计其数，但只有一部分加上了“被锁”。与其把其余所有被锁的链接都加上“被锁”，不如把现有的这部分去掉，统一格式。--
- (＋)同意，确实没有必要去添加这个标记，要加也得用自动化的方案。-- Salt lovely「非谢家之宝树，接孟氏之芳邻」 2020年12月7日 (一) 23:01 (CST)
泥潭发生了什么
今天去茶馆，提示我“本站已关闭发帖功能”。
全论坛翻了一遍，发现12.13日（今天）只有1个帖子，在mod教程版，还是版主的。
泥潭是又要维护了，还是怎么的？有人知道吗？
--< 自由李代数 讨 贡 狗娃安慰噶喔。> 2020年12月13日 (日) 08:21 (CST)
- 和今年4月4日那次理由相同。--QWERTY_52_38 讨 贡 2020年12月13日 (日) 08:51 (CST)
刚才突然反应过来了，之前没想起来今天是什么日子。--< 自由李代数 讨 贡 狗娃安慰噶喔。> 2020年12月13日 (日) 09:08 (CST)
防止手贱点到回退按钮
// ------------------
// 防止手贱回退页面
// ------------------
$(function () {
for (let a of Array.from(document.querySelectorAll('.mw-rollback-link a'))) {
a.addEventListener('click', function (ev) {
if (!confirm('确定要回退吗？')) { ev.preventDefault() }
})
}
})
由于MediaWiki的JS压缩器只支持“ES2015”中“ES”和“5”的部分，因此即使这段代码能在任一主流浏览器上运行，也只会在你的用户JS页面报错。
请使用mw.loader.load来加载，或者：
eval("$(function(){for(let a of Array.from(document.querySelectorAll('.mw-rollback-link a'))){a.addEventListener('click',function(ev){if(!confirm('确定要回退吗？')){ev.preventDefault()}})}})")
当然，这里我也推荐李代数的方案，不会导致MW的报错，同时也更好看。
// 取自 https://minecraft-zh.gamepedia.com/User:Ff98sha/common.js，仅供学习研究用
mw.loader.using(['oojs-ui-windows', 'oojs-ui-core'],
function() {
$('.mw-rollback-link a').each(function() {
var href = $(this).attr('href');
$(this).click(function(e) {
e.preventDefault();
OO.ui.confirm('你确定要回退此页面吗？').done(function(confirmed) {
if (confirmed) { location.href = href; }
});
});
});
});
思路：阻止锚点的默认动作 -> 用户确认是否继续 -> 执行默认动作/什么都不发生
-- Salt lovely「非谢家之宝树，接孟氏之芳邻」 2020年12月16日 (三) 16:08 (CST)
(☩)意见：
- 不是我的方案，只是在mcwiki上看到ff98sha的用户js，拿来试用的。
- 我认为以上方法是可行的。
- 前几天我有一个想法，缺点在于可能有些麻烦，有点在于方便自定义，可以考虑一下：
- 去除所有锚点
- 定义一下确认的代码及UI
- 添加锚点并附上上述代码
--< 自由李代数 讨 贡 狗娃安慰噶喔。> 2020年12月16日 (三) 17:56 (CST)
- (：)回应，那几个锚点本身没有什么特殊点，所以没有必要劫持，不过自定义UI倒是可以写：
$(function () {
for (let a of Array.from(document.querySelectorAll('.mw-rollback-link a'))) {
if (!a.hasAttribute('href')) { continue }
a.addEventListener('click', (ev) => {
ev.preventDefault()
confirmUI('确定要回退此页面吗？', (confirmed) => {
if (confirmed) { window.location.href = a.href }
})
})
}
/**
* 显示一个自定义确认框
* @param {string} text
* @param {(confirmed:boolean)=>void} callback
*/
function confirmUI(text = '', callback) {
// 安全锁，防止用户多次点击
let safe = true
// 容器
let container = document.createElement('div')
container.className = 'confirmUIcontainer'
container.innerHTML = `<center>${text}</center>`
// 确定按钮
let yesBtn = document.createElement('div')
yesBtn.className = 'btn'
yesBtn.style.setProperty('--hover-color', '#FDF6E6')
yesBtn.textContent = '确定'
yesBtn.addEventListener('click', () => {
if (safe) {
safe = false // 安全锁
callback(true)
selfRemove() // 移除确认框
}
})
container.appendChild(yesBtn)
// 取消按钮
let noBtn = document.createElement('div')
noBtn.className = 'btn'
noBtn.style.setProperty('--hover-color', '#FDF6E6')
noBtn.textContent = '取消'
noBtn.addEventListener('click', () => {
if (safe) {
safe = false
callback(false)
selfRemove()
}
})
container.appendChild(noBtn)
// 关闭按钮
let closeBtn = document.createElement('div')
closeBtn.className = 'close'
closeBtn.textContent = '×'
closeBtn.addEventListener('click', () => {
if (safe) {
safe = false
selfRemove()
}
})
container.appendChild(closeBtn)
// 显示UI
container.style.opacity = '0'
container.style.top = '20%'
container.style.transitionTimingFunction = 'ease-out'
document.body.appendChild(container)
// 调整位置
container.style.marginLeft = (container.offsetWidth * -0.5) + 'px'
container.style.marginTop = (container.offsetHeight * -0.5) + 'px'
container.style.transitionDuration = '.3s'
container.style.opacity = '1'
container.style.top = '50%'
setTimeout(() => { container.style.transitionTimingFunction = 'ease-in' }, 400)
/**移除自己 */
function selfRemove() {
container.style.top = '20%'
container.style.opacity = '0'
setTimeout(() => { container.remove() }, 400)
}
}
// CSS
let s = document.createElement('style')
s.textContent = `
.confirmUIcontainer{
position: fixed;
border: 8px solid #0003;
border-radius: 8px;
overflow: hidden;
padding: 0;
top: 50%;
left: 50%;
min-width: 20vw;
background: #fbf2dc;
user-select: none;
}
.confirmUIcontainer > center{
padding: 1.2rem .6rem 1.2rem .6rem;
font-size: 1.05rem;
}
.confirmUIcontainer .btn{
width: 50%;
border: 1px solid #ccc;
padding: 1rem;
box-sizing: border-box;
font-size: 1.15rem;
line-height: 1.15rem;
float: left;
background-color: transparent;
text-align: center;
transition: .3s ease;
cursor: pointer;
}
.confirmUIcontainer .btn:hover{
background-color: var(--hover-color,transparent);
}
.confirmUIcontainer .close{
position: absolute;
width: 2rem;
height: 2rem;
top: 0;
right: 0;
font-size: 2rem;
line-height: 2rem;
text-align: center;
}
`
document.head.appendChild(s)
})
- -- Salt lovely「非谢家之宝树，接孟氏之芳邻」 2020年12月16日 (三) 19:30 (CST)
建議啟用雙重驗證功能
如題，我想應該不必多作解釋。——<JasonHK /> 2020年12月19日 (六) 00:00 (CST)
- 这不给登录制造困难？而且MCBBS Wiki帐号并不涉及秘密、财产等敏感内容，谁这么闲来盗你号？--洞穴夜莺 2020年12月19日 (六) 10:35 (CST)
- (：)回应 雙重驗證是個選用功能，你覺得麻煩可以不啟用的。你認為沒有價值的資料在其他人的眼中可能像黃金一樣，在不同網站蒐集您的一點點資料已經足以對你發動社交工程攻擊。--<JasonHK /> 2020年12月19日 (六) 22:44 (CST)
- (？)疑问 最近发生什么特别的事了吗？ -- Salt lovely「非谢家之宝树，接孟氏之芳邻」 2020年12月19日 (六) 10:38 (CST)
- (：)回应 其實沒有什麼特別，雙重驗證是我使用網站的一個基本要求，只要網站支援我便會啟用。既然 MediaWiki 支援雙重驗證，網站管理員便有責任開啟這個功能，讓有需要的人自行啟用。--<JasonHK /> 2020年12月19日 (六) 22:44 (CST)
- (－)反对 MediaWiki没有原生的两步验证机制。 -- Sheep-realms（讨论） 2020年12月20日 (日) 11:58 (CST)
- ( i )注意 @Sheep-realms MediaWiki 官方已提供雙重驗證插件 OATHAuth，並且自 MediaWiki 1.31 （即這個維基目前所使用的版本）起已內置這個插件。 --<JasonHK /> 2020年12月20日 (日) 15:06 (CST)
- (：)回应 我查阅了OATHAuth扩展的文档与特殊:版本，我觉得使用了 MediaWiki 1.13.7 的本Wiki并没有安装这个扩展；即使文档里写着“此扩展已绑定在MediaWiki 1.31及以上版本 因此您不需要再次下载。”。-- Salt lovely「非谢家之宝树，接孟氏之芳邻」 2020年12月20日 (日) 18:31 (CST)
- ( i )注意 @Sheep-realms MediaWiki 官方已提供雙重驗證插件 OATHAuth，並且自 MediaWiki 1.31 （即這個維基目前所使用的版本）起已內置這個插件。 --<JasonHK /> 2020年12月20日 (日) 15:06 (CST)
- (：)回应 你看錯了，這個維基的版本是 1.31.7，不是 1.13.7。——<JasonHK /> 2020年12月20日 (日) 19:28 (CST)
- (：)回应 是笔误——根据上下文可以判断；言归正传，我确实没有在这个 Wiki 找到本应捆绑安装的双重验证扩展。 -- Salt lovely「非谢家之宝树，接孟氏之芳邻」 2020年12月20日 (日) 19:37 (CST)
- (：)回应 應該是沒有啟用吧……
- 「This extension comes with MediaWiki 1.31 and above. Thus you do not have to download it again. However, you still need to follow the other instructions provided.」
wfLoadExtension( 'OATHAuth' );
- 沒有用這段代碼啟用的話應該不會在 Special:Version 顯示吧。——<JasonHK /> 2020年12月20日 (日) 20:19 (CST)
- ( i )注意无效@、不一定可以安装成功-
坑触可 2020年12月20日 (日) 16:32 (CST)
- ( i )注意无效@、不一定可以安装成功-
- (：)回应 這是官方提供的插件，依照官方的指示安裝的話一般不會出錯。——<JasonHK /> 2020年12月20日 (日) 21:07 (CST)
- 根据说明文档的指示，本Wiki的拓展目录中并未内置OATHAuth插件。因为某一次网站迁移的原因，部分文件和数据已经遗失。 -- Sheep-realms（讨论） 2020年12月20日 (日) 21:38 (CST)
- 補充：這個討論串的。——<JasonHK /> 2020年12月20日 (日) 22:04 (CST)
- 未來有機會加入嗎？——<JasonHK /> 2020年12月20日 (日) 22:10 (CST)
- 不過我覺得很少中國用戶會有對 TOTP 2FA 或者 FIDO U2F 的需求，畢竟大部份中國網站還停留在密碼保護問題或者 SMS 這些容易受社交工程攻擊或者已知有漏洞的雙重驗證方法……——<JasonHK /> 2020年12月20日 (日) 22:37 (CST)
- 社工攻击一直挺要命的，仅仅是双重验证是拦不住社工库的，除非所有网络账户都这么设置——考虑到“雙重驗證是我使用網站的一個基本要求”，你的方案，在所有网站给账号设置双重验证不失为一种好方法。
- 说个题外话，我的方案更加简单直接，随机生成 西文字母+阿拉伯数字(+如果可以使用符号的话) 的组合作为密码，让chrome帮我记忆，需要密码时找回即可，唯一需要记忆的复杂密码是我的邮箱密码——每个都不一样，且有双重验证。-- Salt lovely「非谢家之宝树，接孟氏之芳邻」 2020年12月20日 (日) 23:15 (CST)
- 雖然我的目標是每個網站都啟用雙重驗證，但可惜我使用的網站只有少於四分之一支援 TOTP 2FA，支援 FIDO U2F 的更是少之又少。不過我其實自 2017 年 9 月起已經用密碼管理器來儲存每個網站的密碼，因此每個網站的密碼也是不同的（至少那天之後建立或更改過密碼的是）。而且自幾個月前起我開始為每個網站的帳號使用不同的電郵地址，這些電郵地址會將電郵轉寄到我正式的電郵地址，這樣既能夠保護個人私隱又能夠阻止垃圾郵件。不過繼續好像開始離題了，假如你有興趣繼續討論這個話題可以在其他渠道找我。比較容易找到我的是我的中文維基百科用戶討論頁、電郵、Telegram 和部分社交網站。MCBBS 和這個維基我只會間中上來看看，因此比較難找到我。——<JasonHK /> 2020年12月21日 (一) 00:43 (CST)
關於你們的電郵
請問 [email protected] 是你們用來傳送電郵的電郵地址嗎？假如是的話，我是來告訴你用這個電郵地址傳送的電郵被過濾了。建議你們不要用 .ml 那些免費域名，並且設定 SPF、DKIM 及 DMARC。——<JasonHK /> 2020年12月22日 (二) 22:55 (CST)