Jump to content

Skizzerz

Administrators
  • Content Count

    131
  • Joined

  • Last visited

Community Reputation

26 Excellent

About Skizzerz

  • Rank
    Veteran
  • Birthday October 10

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. There are no scripts that MediaWiki ships with to repair corruption in the text table caused by manual modifications, because that is not a supported scenario. However, modifying an existing table entry (compared to making a new one) should take effect right away. Try rebuilding your caches with the rebuildall.php script; it's possible the old version is simply being cached, and that will cause it to be re-parsed. You may run into exceptions when doing that, you'll need to clean that up manually if it occurs.
  2. Yes, this is possible. First you'll want the OpenID Connect extension: https://www.mediawiki.org/wiki/Extension:OpenID_Connect The OpenID Connect extension requires the PluggableAuth extension as a prerequisite: https://www.mediawiki.org/wiki/Extension:PluggableAuth One of the configurations for PluggableAuth (on the second link) allows for local logins in addition to OIDC. You'll want the following in your LocalSettings.php (after loading both extensions): $wgPluggableAuth_EnableLocalLogin = true;
  3. Skizzerz

    Debounce

    Version 1.2.0

    2 downloads

    The Debounce extension integrates with the debounce.io API to check whether email addresses are disposable or otherwise invalid for registration. Both the free disposable email API as well as the paid email validation API are available. By default, this uses the free API. Installation Download and place the file(s) in a directory called Debounce in your extensions/ folder. Add the following code at the bottom of your LocalSettings.php: wfLoadExtension( 'Debounce' ); Done – Navigate to Special:Version on your wiki to verify that the extension is successfully in
    Free
  4. While MediaWiki could be used for all of those things (although you'd need to likely create some custom extensions for your use cases), it is definitely not designed or intended to be any of those things. MediaWiki is best used for a collaborative environment where users can work together on creating pages/articles for some purpose. It has been used for encyclopedias, documentation, guides, how-tos, and knowledgebases. Others use it as a general-purpose content management system, although that sort of setup requires a lot of effort. See https://www.mediawiki.org/wiki/Manual:Deciding_
  5. Wiki pages are not files; they are not stored on a filesystem anywhere (which is what makes something a "file"). Pages are stored in the database, so filesystem concepts like extensions do not apply to them.
  6. You can run MediaWiki on anything so long as you can run a web server, PHP, and a database server on it. Most people run it on linux, but there's quite a few that run on windows as well. See https://www.mediawiki.org/wiki/Manual:Installation_requirements for more details.
  7. delete-rootuserpages lets you delete the page [[User:Username]], whereas delete-usersubpages only lets you delete e.g. [[User:Username/subpage 1]], [[User:Username/subpage 2]], etc. If you have the delete permission, you are correct in that you don't need either of the other two.
  8. I'm not familiar with that extension or how it operates, but I can give some insight into MediaWiki's permissions model in a nutshell: Various actions within the wiki are restricted to users who possess certain permissions. Permissions are granted to or revoked from groups. A user belongs to one or more groups. If any of the groups a user belongs to is granted the permission and none of the groups a user belongs to has revoked the permission, the user is allowed to perform that action. The ability to revoke permissions is probably used in less than 1% of wikis and
  9. There's a couple of extensions that can do stuff like that, FlaggedRevs is probably the most popular one of the bunch: https://www.mediawiki.org/wiki/Extension:FlaggedRevs It's rather heavyweight and difficult to configure, however, so you may instead be more interested in the alternatives. They're linked in the "See Also" section at the bottom of that page.
  10. A blank white page indicates a PHP error. This manual goes into a bit more depth on how to view and diagnose those errors. By default, sensitive actions on the wiki break out of frames (such as editing, registering for a new account, updating your preferences, etc.). You will need to configure $wgEditPageFrameOptions if you wish for your framed version of MediaWiki to allow such actions while still being inside of a frame.
  11. There could be a large number of reasons as to why this error is happening. If you don't see anything in your error logs, follow the advice shown and set $wgShowExceptionDetails = true; at the bottom of your LocalSettings.php in order to display the error details on-screen. Without those details, nobody will be able to assist you.
  12. Yes, the https://www.mediawiki.org/wiki/Extension:Auth_remoteuser extension lets you automatically authenticate people to the wiki given arbitrary external credentials. How exactly to set it up will vary based on the authentication provider (what actually validates that the usernames/passwords are valid, when using this extension you're bypassing the normal MediaWiki login flow so your user account password on the wiki will not be checked). For sending a credential through a link, you would need some sort of processing server-side to extract the credential, validate it, and then set the approp
  13. MediaWiki is not really designed for access control schemes were certain users can see pages that other users are unable to see, but https://www.mediawiki.org/wiki/Extension:Lockdown facilitates that method of operation. This would allow you to lock down certain wiki pages (such as every page in a particular namespace) so that only people with the correct group can read them. Then you simply add that group to the wiki accounts for the people that should have access, and when they log in they can view the pages. If you are referring to a solution outside of MediaWiki (not having restricted
  14. Namespaces are generally the recommended way of going about this. As you've discovered, you do need to specify the namespace in each link, however. There is no way to avoid this without an extension, although you can work around it by using a template that auto-fills the current namespace instead of directly using link markup.
×
×
  • Create New...

Important Information

We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue.