Once this gets merged (to configure Comments on your wiki), I believe that will be everything.
- Queries
- All Stories
- Search
- Advanced Search
- Transactions
- Transaction Logs
Advanced Search
Mar 29 2019
Mar 28 2019
In T4222#80592, @MacFan4000 wrote:In T4222#80585, @Void wrote:Should also probably look at wiki.hackdown.me
That one works for me
Should also probably look at wiki.hackdown.me
Any updates on this?
@Reception123 status?
Accessing ManageWiki requires bureaucrat permission.
@Paladox status? (again)
You should be able to install PollNY now if you can't get AJAXPoll working.
Mar 26 2019
- Go into Special:ManageWikiNamespaces for the namespace in question, and make sure subpages is enabled for that namespace
- No idea.
- The extension can be configured, if you want. To add to all pages, you may want to look into something like MassEditRegex.
- Wiki statistics don't update immediately, they tend to take a few minutes up to a few hours to take effect.
Sorry for the delay into looking into this, but it looks like the default value for $wgLinkTitlesParseOnEdit is true, and we wouldn't accomplish anything by redefining it.
Mar 25 2019
Mar 22 2019
Mar 20 2019
In that case, then, would someone mind either enabling voteny or disabling blogpage on hypopediawiki?
Mar 19 2019
Mar 18 2019
The extension itself looks pretty simple (easy to add), although you may want to consider built in collapsible elements.
Mar 17 2019
I've done a quick fix on one of the modules, as I don't believe adding wikibase alone would fix it. Would need to confirm though.
That would likely be icinga.miraheze.org (login as guest/guest), however it's odd, because the servers (lizardfs1 and lizardfs2) both seem to still have 17 GB free. Is this just not allocated to the file system? Thing number two, can we actually do something about this, even if it winds up being a temporary thing?
Mar 14 2019
Mar 13 2019
In T4193#80079, @CiviHosting wrote:For the record, this is the code I have in place currently. The last part is commented out because otherwise the site won't start. Seems we have a bit of a chicken/egg problem with all.dblist...
Mar 12 2019
/srv/dblist/all.dblist comes from $wgCreateWikiDBDirectory ($wgCreateWikiDBDirectory . '/all.dblist'), and the actual file is created by the CreateWiki/ManageWiki extensions.
I've installed CreateWiki/ManageWiki before, and this is the config I needed:
$wgCreateWikiDatabase = "wiki"; // Or any central DB $wgCreateWikiSubdomain = "local.wmftest.net"; // Not sure about this one $wgCreateWikiDBDirectory = '/srv/dblist'; // Or any other suitable place for dblists $wgManageWikiCDBDirectory = '/var/cache/managewiki'; // Or any other location for a cache
You'll also need this at the bottom of LocalSettings.php to extract the config from ManageWiki:
$wgLocalDatabases = array(); $wmgDatabaseList = file( "/srv/dblist/all.dblist" ); // ManageWiki settings foreach ( $wmgDatabaseList as $wikiLine ) { $wikiDB = explode( '|', $wikiLine, 6 ); list( $DBname, $siteName, $siteLang, $siteExtensions, $siteSettings ) = array_pad( $wikiDB, 6, '' ); $wgLocalDatabases[] = $DBname; $wgConf->settings['wgSitename'][$DBname] = $siteName; $wgConf->settings['wgLanguageCode'][$DBname] = $siteLang; $siteExtensionsArray = explode( ",", $siteExtensions ); foreach ( $wgManageWikiExtensions as $name => $ext ) { if ( in_array( $name, $siteExtensionsArray ) ) { $wgConf->settings[$ext['var']][$DBname] = true; } } $siteSettingsArray = json_decode( $siteSettings, true ); if ( is_array( $siteSettingsArray ) || is_object( $siteSettingsArray ) ) { foreach ( $siteSettingsArray as $setVar => $setVal ) { $wgConf->settings[$setVar][$DBname] = $setVal; } } }
Mar 8 2019
FWIW, attempting to do CORS requests has never worked (at least not on my end), and I first set up a testing script for it nearly two years ago (but that has to do with the API).
Mar 7 2019
Mar 6 2019
In that case, I'd suggest looking at Moderation. It requires that every edit be approved by an administrator before it goes live. It's not exactly what you're looking for, but unless I'm missing something painfully obvious, there doesn't seem to be an extension (that we support) to approve users before they can edit.
Mar 5 2019
As far as I know, there's no easy extension you can install to get this done. Instead you need to setup editing restrictions using our existing tools.
250 is already in the default wgRCLinkLimits options, and usenewrc should be enabled by default.
Mar 4 2019
$wgRCLinkDays and $wgRCLinkLimits are a list of options, do you still want the original values available?
What setting do you want for usenewrc? Should it be enabled or disabled?
It appears that, in order to do this, you need to add .mw-editsection { display:none !important; } to the page MediaWiki:Common.css.
Mar 3 2019
Done
Feb 28 2019
Sorry for the delay! Working on it now!
Feb 27 2019
This can be done using Special:ManageWikiExtensions.
Feb 23 2019
Feb 21 2019
Looks like the if else block here is not doing what it should be.
Feb 19 2019
Some of our config got reset to an old version from before the global interwiki was setup. It has now been fixed.
Feb 15 2019
You can do this by using Special:ManageWikiPermissions to:
- Revoke the edit permission from the "*" group.
- Add the edit permission to the "sysop" group (administrators), and whatever other group you want to have access to editing.
And that's it.
Feb 13 2019
Isn't that resolved by using htmlspecialchars on line 164, as that is what defines $minCountInput?
Feb 11 2019
Feb 8 2019
The security of all wikis is the concern of the System Administrators. However, if you want to run js, you may, provided that it can be done using the interface of MediaWiki:Common.js.
Feb 7 2019
Can the permissions be handled within Special:ManageWikiPermissions?
Feb 4 2019
Feb 1 2019
You need to import MediaWiki:Common.css from wherever you imported the infoboxes from.
Jan 31 2019
Regardless, we've disabled the feature in https://git.io/fhyHl.
Jan 30 2019
I've just finished the Crat permissions setup, sorry I didn't do that before, but somethings didn't match up. I'm not sure what's wrong with $wgTidyConfig, because it is configured.
Jan 28 2019
Jan 27 2019
I've done some simple fixes. I'd also suggest you import MediaWiki:Common.css if this hasn't already been done.
I'm not sure there's anything left to be done, as everything appears to be working now.
If you provide a copy of the script locally on your wiki, you can load it from there without any difficulties. If you need any help doing that, let me know.
Hi, sorry this took so long, but we just discovered that the configuration was done wrong. It has been adjusted now.