Fixed in R20:14. Thanks Jack :)
- Queries
- All Stories
- Search
- Advanced Search
- Transactions
- Transaction Logs
All Stories
Jul 31 2016
Using the uselang=qqx URL parameter on Special:AdminPanel/privacy I was able to figure out that the page expects the message keys to be adminpanel/privacy-privacy-section-editing and adminpanel/privacy-privacy-section-viewing (sic!), most likely because the special page is named AdminPanel/privacy in the constructor.
Wasn't an issue when using extends specialPage, only became an issue on extends FormSpecialPage.
Added in R20:13.
Most completed R20:12.
Two things have been split off into new tasks:
Completed with R20:9, Minor fix in R20:10
Completed R20:11
Completed in R20:7
Completed as of R20:3
Jul 30 2016
Jul 28 2016
Er, the extension has a global one and local ones on all the other wikis now, and just sort of merges those on those wikis, so if we converted to use that, uh...
So I added (and self-merged) a new hook point, RefreshedInSidebar, to Refreshed (upstream commit), which allows us to inject 125x125px ads into the sidebar area.
Jul 27 2016
@isarra Do you know anything any thoughts on this? You merged our nasty hack (the ShoutWiki Interwiki Magic extension) into the upstream Interwiki extension a long time ago.
Also, rename the submit button to "send"?
Needs to include a link back to the main AdminPanel page. And an explanation/link to an explanation of private wikis?
Jul 26 2016
Jul 25 2016
Fixed in rSHWK3876. Already deployed.
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
So we're looking at a 1.26 freeze sometime tomorrow evening (25/07/16) and then we'll begin working towards a 1.27 release with an internally agreed, rather hopeful timeline.
So I was thinking something along the lines of the libraries in vendor/ - which I believe use PHP namespaces (which I'd like to learn more about) and then if we need to write an even smaller meta-extension for that, then we could do that (and a name has disappeared from my head in the time it has taken to reply to this) and then load that globally.
One of the major problems I had with this idea the last time it popped into my mind was that where would the code go? Logically speaking it'd be a part of CreateWiki, as everything and anything is tied into the architecture that CW provides, requires and expects, but CW is enabled only on the English Hub! So we'll likely need to create a new meta-extension for this.
And thus we need a name for it, unless we'll settle for plain "ShoutWiki", and maybe source availability status would need to be considered. There are extensions which use and depend on the CW framework -- i.e. wiki_list and wiki_settings tables in $wgSharedDB -- which are open source (ShoutWikiAPI) and even more which are not, even if they are forked from an open source extension (ref).
Yes, it's FOSS, and yes, the usage of wfMsg might break it under MW 1.27, but that's the very least of this extension's problems. I mean, a literal s/wfMsg/wfMessage/g will work because of the existence of Message::__toString, so if someone really wants to run this under 1.27, it's not this issue really blocking that -- it's the fact that the extension's somewhat ShoutWiki-specific, requiring a core hack (for the CustomSpecialStatistics hook) and uses some other deprecated things, such as PHP i18n and setup files...not to mention the obvious lack of scalability (a known design issue at the time).
Jul 23 2016
Isn't this used on brickimedia production? It shouldn't be too likely to explode.
In T89#1158, @lewiscawte wrote:so that hopefully there's a bigger audience to test Refreshed
We're not here so you can test your code. Go break some other site.
So this was probably worded a bit badly. I'm sure that @SamanthaNguyen's intention wasn't to have unstable, potentially broken code deployed on ShoutWiki.
In T87#1235, @lewiscawte wrote:Can this be broken / merged into more manageable chunks/problems and file those as separate tasks. Refactoring an entire extension as one task makes it less manageable.
Echoing this, mainly because my screen is what's considered small these days (resolution-wise) and having to scroll up and down all the time is annoying. :P
We don't use this extension in production
This is correct, but that's also because we don't have that many overly technical wikis, and also because we've never advertised it. Granted, that hasn't stopped users in the past from requesting different kinds of unsupported extensions, but still.
Can this be broken / merged into more manageable chunks/problems and file those as separate tasks. Refactoring an entire extension as one task makes it less manageable.
My apologies, my intention wasn't malicious (e.g trying to break any of the wikis), just a suggestion. Sorry about that.
so that hopefully there's a bigger audience to test Refreshed
This isn't a small change. There are lots of things that need to be prepared to upgrade 7600 wikis to a new major version.
Jul 21 2016
FYI, you can tag the task in the commit, or the commit in the task, so you don't have to add comments. Whatever way around you want to do it, it is done via the "Edit Related Objects" option in the menu on the right of the page.
So this is slightly meta and off-topic, but you don't even need to use the "Edit Related Objects" option. Having "Bug: T<some task number>" in a new line in the commit message automatically links the commit and the associated task. For example:
CreateWiki: Fix a fatal bug in the backend.