Jump to content

Skizzerz

Administrators
 View Profile  See their activity

  • Posts

    174

  • Joined

  • Last visited

 Content Type 

Everything posted by Skizzerz

  1. Skizzerz
    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.
  2. Skizzerz
    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 not really applicable to most use cases, so we can simply point 4 to "If any of the groups a user belongs to is granted the permission, the user is allowed to perform that action." If the extension you mention is based on the normal permissions framework, then you'd have one permission needed for Sales and one permission for Sales Manager. You'd need two groups as well, a Sales group (with only the Sales permission), and a Sales Manager group (with both the Sales and Sales Manager permissions). Then a user only needs to belong to one group which incorporates all the permissions they need. If the extension is looking at specific groups rather than using the normal permissions framework, then unfortunately there is no way to have one group "belong" to another group. You will have to add the user to all of the appropriate groups. A user can belong to more than one group without issue.
  3. Skizzerz
    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.
  4. Skizzerz
    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.
  5. Skizzerz
    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.
  6. Skizzerz
    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 appropriate AUTH_REMOTEUSER environment variable context. I don't believe anything currently exists for this but if you aren't too concerned about the security of the credentials it'd be easy enough to do entirely via mod_rewrite
  7. Skizzerz
    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-access wiki pages), then I fail to see how this relates to MediaWiki at all.
  8. Skizzerz
    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.
  9. Skizzerz
    You'll want to install some anti-spam extensions. I recommend ConfirmEdit (adds a CAPTCHA) and AbuseFilter (lets you manually define filters that can block edits) at a minimum. This will prevent spambots from being able to easily sign up and create spam pages on your wiki. For the email issue, I can't really say what may be going on there. It could just be confirmation emails, because I'm not aware of any active security vulnerabilities that allow users to send email to arbitrary other addresses via the wiki.
  10. Skizzerz
    You could use ParserFunctions #ifeq to compare the version a page is for with the current version, and display the warning banner and related things if they don't match. More complicated things can be done as well by making use of other functions that can split strings up to compare each component of a version number independently. See https://www.mediawiki.org/wiki/Help:Extension:ParserFunctions for some more details on the ParserFunctions extension. Other extensions exist which add even more capabilities compared to what is listed there.
  11. Skizzerz
    Did you install parsoid and ensure it's accessible?
  12. Skizzerz
    The first one will cause issues so I wouldn't recommend it. For options 2 or 3: Make a very heading, such that it wraps around multiple lines on a desktop browser. See which of the options looks better there. Try it on tablet and mobile devices (or use browser dev tools to emulate those device sizes if you don't have any actual devices available), focusing mostly on normal-sized headings. These headings will probably not wrap on tablet, but may wrap on mobile. See which of the options looks better there. As for where to put it: depends. Common.css affects every skin, Vector.css affects only the vector skin. Given that skins can put edit links pretty much wherever they want, there's no guarantee that your change for vector will work properly on other skins.
  13. Skizzerz
    You can add custom CSS to your wiki to move it back to the right; you may wish to test that your edits look good across a variety of screen sizes from mobile phones up to desktops. The edit section tag is in a class called "mw-editsection", so you can use that for your selector. To add custom CSS to your wiki, edit the page MediaWiki:Common.css while logged into an administrator account, or MediaWiki:Vector.css if you wish for those changes to only apply to the Vector skin. See the manual page on mediawiki.org for more information.
  14. Skizzerz
    Limitations in MediaWiki, for the most part. Injecting javascript into <head> is a chore, injecting javascript at the end of <body> is natively supported. In practice where you put the code makes no difference whatsoever.
  15. Skizzerz
    Try the following troubleshooting steps: Verify that you have the correct analytics ID in the extension Verify that the analytics code is appearing in the page source. If it does not, you either do not have the extension enabled (check Special:Version), or the extension is configured to not track you (because you are sending DNT with your requests, or you are part of an exempt user group). If the latter case, you can modify the extension config in LocalSettings.php. If the code appears but you still see no data, ensure that your browser isn't blocking the request. Many ad blockers will block Google Analytics and some browsers such as Firefox have built-in privacy settings that may block trackers as well.
  16. Skizzerz
    If you see $wgDBmwschema in your LocalSettings.php, delete that line entirely.
  17. Skizzerz
    What error messages did you receive as part of the upgrade process? Try generating a fresh LocalSettings.php as @HSRobinson suggested (installing to a new database, modifying the database name/password in LocalSettings.php to point to the existing 1.18 database, then running the updater again). If this method works, then the likely issue is that you forgot to update some skins or extensions -- when updating MediaWiki you also need to download the updates for all skins/extensions you use. If a skin or extension doesn't have updates between 1.18 and 1.33, it is likely not compatible with 1.33 and an alternative should be found.
  18. Skizzerz
    You need access to the backend server (such as via SSH) in order to directly look at and query the database tables. If you are looking for something more powerful to generate lists of pages on-wiki based on whatever criteria, you can check out the DPL extension. Fair warning though: it's very easy to knock your wiki offline temporarily with a poorly-written DPL query.
  19. Skizzerz
    I don't see any issues on the linked page. Can you describe in more detail what your problem actually is? Screenshots or error messages are helpful
  20. Skizzerz
    If you're unable to connect, it sounds like it may be blocked by the firewall. You'll want to ensure that HTTP and HTTPS are enabled for outside connections into your NAS box.
  21. Skizzerz

    GTag

    Skizzerz posted a file in Extensions

    Version 1.3.0

    664 downloads

    GTag Extension for MediaWiki The GTag extension lets you insert the new Google Analytics tracking tag on your MediaWiki site (gtag.js). Requirements MediaWiki 1.35 or later Installation Download the file (a free account is required) and extract the file to your extensions directory. We recommend that you "follow" the download so that you are notified of new updates via email when they are released. To install the extension, add the following to your LocalSettings.php file: wfLoadExtension( 'GTag' ); $wgGTagAnalyticsId = 'UA-XXXXXXXX-X or G-XXXXXXXX'; // replace with your GA id Configuration In addition to the required $wgGTagAnalyticsId, this extension features many optional configuration variables that you may add to your LocalSettings.php file. $wgGTagAnalyticsId (string): Google Analytics ID, for example 'UA-XXXXXXXX-X' or 'G-XXXXXXXX'. Required. $wgGTagAnonymizeIP (boolean, default false): If true, anonymize the IP address sent to Google Analytics. $wgGTagEnableTCF (boolean, default false): If true, support the IAB Transparency & Consent Framework used by many 3rd party cookie consent widgets. You will need to implement such a widget yourself into your wiki; the extension does not come with one. $wgGTagHonorDNT (boolean, default true): If true, honor "Do Not Track" requests from browsers. If false, ignore such requests. $wgGTagTrackSensitivePages (boolean, default true): If true, insert tracking code into sensitive pages such as Special:UserLogin and Special:Preferences. If false, no tracking code is added to these pages. In addition to these configuration variables, you may assign the right gtag-exempt to user groups to prevent them from being tracked. This can be useful to give to staff groups so that your internal users and staff are not tracked, giving you a better idea of who is actually using your site. For example: $wgGroupPermissions['sysop']['gtag-exempt'] = true; Support Free community support is available on the mwusers.org forums. Paid support plans are available as well.
    Free
  22. Skizzerz
    This feature is added by the Cite extension. You will need to enable the extension in LocalSettings.php before it will work. If you downloaded MediaWiki via a tarball, you likely already have the extension files downloaded; they just aren't enabled by default.
  23. Skizzerz
    Check if there is any disk space quota or limit that's being reached. The disk being full would be my first thought when uploads suddenly stop working when nothing else changes.
  24. Skizzerz
    Nothing like this is built-in, so you have two options: Create the graphs in an external program and upload them to MediaWiki as image or svg files. Then, you can use the regular image embedding features to show them in the article. Install an extension such as https://www.mediawiki.org/wiki/Extension:Graph and use that to program and display the graphs.
  25. Skizzerz
    Pretty standard composer stuff, but it's very intimidating if you aren't already familiar with it. The last response in that linked issue is correct -- you need to run the composer command from your wiki root (same directory where LocalSettings.php is). You may have casing issues as well. Generally speaking (and I cannot confirm whether this is correct for chameleon or not), the value for $wgDefaultSkin must be all lowercase but the value inside of wfLoadSkin() should have a capital first letter.
×
×
  • 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.