Fixed, thanks for the report!
- Queries
- All Stories
- Search
- Advanced Search
- Transactions
- Transaction Logs
Advanced Search
Mar 26 2024
Dec 28 2023
Ooh, that's a new one... shall investigate.
Dec 27 2023
Sep 7 2023
Relevant API docs:
My thinking for an implementation is to write this to hand off each of these to the job queue and have it fire these off whenever. Probably one job per search engine, as there will be auth tokens etc involved.
Jul 1 2021
Apr 22 2021
Jan 26 2021
Oct 15 2020
The founder of rudubbing.shoutwiki.com reports the same problem.
Oct 14 2020
Jul 10 2020
In T288#4356, @dylan.west wrote:Now I see the "CreateWiki disabled until 1.34.x release is stabilised - see here..." message. Should I be seeing this?
Now I see the "CreateWiki disabled until 1.34.x release is stabilised - see here..." message. Should I be seeing this?
Completely forgot "normal users" don't just bypass the throttle check. My bad.
Jul 7 2020
Jun 28 2020
Gotcha, I saw that forum post earlier, but it was when the most recent reply to it was an instruction to post to phabricator.
Is this a side effect of the resolution to the following task: New wikis not created properly?
For the record, Special:MyWikis throws the same error.
Jun 12 2020
Jun 11 2020
Jack cleaned up the affected wikis, and I've turned off CreateWiki (ish) for the time being. New wikis before we get back to 1.34 are going to cause more issues than its worth.
Jun 1 2020
May 26 2020
So we now run a find command which pipes to xargs to delete directories under /path/to/settings/deleted that haven't been modified in 30 days. This gives us enough time to hopefully notice we've deleted the wrong wiki or for someone to appeal a deletion (not that we have a formal appeals process) while not hoarding deleted wikis forever.
Apr 25 2020
It is entirely intentional. Language subdomains are a blocker for our HTTPS rollout, so we're actively removing the ability to create new ones and are in the process of clearing up as many of them as we can. When we get a better idea of how many we need to keep, further details will be provided to existing wikis.
Apr 24 2020
Mar 16 2019
Pretty sure this got done ages ago as well.
Mar 6 2019
The wiki should now be usable. Again, sorry for the inconvenience! Please let us again know if you run into something that seems out-of-place or simply broken.
Thank you. Subdomain of current affected Wiki - http://remembrancerorder.shoutwiki.com/ (Subgroup - Books)
Mar 5 2019
Hi @jcbynum1 and thanks for the detailed bug report with reproduction steps -- we really appreciate taking the time to write how to try reproducing the bug! Right now the MediaWiki 1.32 database upgrades and all are still running in the background, which causes an increased load on the server, which you may have noticed as slower page loads and an increased "sluggishness" in general. As @lewiscawte noted on a similar forum thread on ShoutWiki Hub, we believe that the issue you're experiencing is connected to that and we expect the wiki creation wizard to work again once the database upgrades are done.
Feb 25 2019
Jan 27 2018
Jan 26 2018
Oct 20 2017
Jun 11 2017
Isn't there already a task to rewrite CreateWiki's backend?
Jun 8 2017
Mar 14 2017
Mar 13 2017
Mar 5 2017
Shouldn't a default logo image be provided inside of Refreshed source code itself instead? Currently Refreshed doesn't provide any, and it's be nice if not only SW wikis could have a default but other wikis have one too.
Mar 4 2017
In T178#2544, @SamanthaNguyen wrote:What about the default logo? I believe there should be some sort of image placeholder created or have it support text, so I'll look for the upstream ticket/make a ticket upstream
Agreed with @ashley that Hub should be on the dropdown menu. What about the default logo? I believe there should be some sort of image placeholder created or have it support text, so I'll look for the upstream ticket/make a ticket upstream
Mar 3 2017
In T178#2541, @lewiscawte wrote:We should probably decide what we want the logo dropdown to contain and configure it by default that a wiki can upload its own image for that. I'd assume we want the wiki and then Hub?
The logo and the drop-down menu are separate features. The drop-down menu is controlled by MediaWiki:Refreshed-wiki-dropdown and its syntax is documented on MediaWiki.org. If it's empty (the default), the little "arrow" next to the wiki's wordmark won't be shown.
The actual site logo is configured by MediaWiki:Refreshed-this-wiki-wordmark (for desktop/normal screen resolutions) and MediaWiki:Refreshed-this-wiki-mobile-logo (for mobile/smaller screen resolutions); see the documentation for details.
We should probably decide what we want the logo dropdown to contain and configure it by default that a wiki can upload its own image for that. I'd assume we want the wiki and then Hub?
Feb 5 2017
Jan 31 2017
Jan 19 2017
"I love doing massive find and replaces in all the settings files that require loads of escaping." said no Lcawte ever.
Nov 15 2016
@CJC fixed this a while ago, CW has recently been updated so there's nothing else to be done here.
Nov 14 2016
Nov 13 2016
This should be fixed now that rSHWK3987 is live.
Nov 11 2016
Sep 24 2016
It's in the i18n files - "createwiki-newmainpage" is the message. Will need to be changed in all language files.
In T124#1708, @SamanthaNguyen wrote:...
em units are used because they're relative ...
Sep 21 2016
In T124#1708, @SamanthaNguyen wrote:Don't use inline styling, it's harder to maintain and also decreases customizability because of CSS specificity. ( https://developer.mozilla.org/en-US/docs/Web/CSS/Specificity ) It'd be better to add a class,
Aug 6 2016
Jul 25 2016
Quoth lines 315-319 of /extensions/CreateWiki/CreateWiki_backend.php:
// Allow this feature to be turned off, because history has sadly taught // us that we might need to do that every now and then... // This has to be here instead of being at the very beginning of this // function so that we can use the $wikiId variable here. if ( $wgCreateWikiAnalyticsLogMode && $wgCreateWikiAnalyticsLogFile ) {
Set $wgCreateWikiAnalyticsLogMode to true and $wgCreateWikiAnalyticsLogFile to a valid path and it won't even try to query the analytics DB, but rather writes the data to a comma-separated file.
If those variables aren't set and thus a connection to the analytics DB is attempted, in lines 351-353 we log the error message to both CW's own log ($wgDebugLogFile['CreateWiki']) as well as the standard error log (error_log()). Do you want the ordinary error_log removed and/or a new wfDebugLog call with a new group name (such as CreateWikiAnalytics) inserted?
Jul 24 2016
Jul 13 2016
Jul 11 2016
The Piwik setup is in another country, with a different hosting provider, on a different network which makes it a lot slower to call - it used to be on rar which had private network access. Additionally, when MySQL throws an error (like connection), it takes a long time and has the entire CreateWiki request time out normally (unless something has been done to fix that), which results in broken wikis.
Jul 3 2016
"Hundreds of lines of error handling code" is hopefully somewhat of an overstatement. ;-) T64 and the like can be worked around with a try-catch loop, for example. Right now in CreateWikiBackend::initDB(), line 479, we blindly source the files listed in $wgCreateWikiSQLFiles (regardless of their existence or the lack of thereof!) against the newly created DB with DatabaseBase::sourceFile(), which seems to throw a MWException if it can't open the file. So maybe something like this would work:
Jun 22 2016
So I've implemented this functionality to CreateWiki, it uses wl_timestamp from wiki_list as it's timestamp. The code could probably be cleaned up a little further, but it works for now.
I forgot what page three is, but remove any redundancies, clarify any unclear bits, group related bits, etc. Basically like the page 1 changes.
For page two, make it out like sections for each skin, with a big checkbox by the title of each. Technically the entire thing is a table, as such:
Also note that the form styles like the buttons and stuff should actually be provided by the skin or mw-ui/oojs; unfortunately none of the skins actually do, and stuff. But the padding would be standard form padding; the blue button would be standard progressive, etc.
Jun 21 2016
the wiki 'type' value we ask users to set has no impact on these settings and sometimes does not reflect the permissions at all
Actually it does, kinda. On step 3, "Editing restrictions" and "Viewing restrictions" drop-down menus don't appear unless the wiki type is either private or school (although they, for whatever reason, did appear to me once even when wiki type was set to public. JS is weird.).
Furthermore if the chosen wiki type is "school", then the additional option "Users with an email address from" appears in both of the aforementioned drop-down menus. This causes a configuration variable, either $wgViewValidEmail or $wgEditValidEmail to be written to the generated Settings.php file. And as you noted, these two variables do nothing even though they probably should. We should probably look into integrating the PrivateDomains extension here somehow, since AFAIK the underlying idea was always to use PrivateDomains for these not-so-public wikis.