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).
- Queries
- All Stories
- Search
- Advanced Search
- Transactions
- Transaction Logs
All Stories
Jul 24 2016
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.
Jul 20 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.
See R20:2
Jul 18 2016
The EnhanceContactForm extension is about as simple as they come (although I should note that 1) the upstream version is slightly outdated again, the one in our repo includes an important HHVM patch, as ShoutWiki is using HHVM and thus we must address its quirks to avoid breaking the site, and 2) for whatever bizarre reasons that are beyond my comprehension upstream has managed to bloat a single-file extension into a bunch of irrelevant files and unnecessary (IMO) i18n).
What @cook879 is describing can be achieved with the jQuery UI dialog component (ResourceLoader module jquery.ui.dialog). Example use can be seen on Special:CreateWiki, step #3, when the chosen wiki type is "private" and you attempt to proceed to step 4 but both viewing and editing restrictions are set to "everyone" (in which case it obviously wouldn't be a private wiki!). The code for this can be found at /extensions/CreateWiki/scripts/createwiki.js, function checkForErrorsPage3. As always, ping me if you need help with this -- ResourceLoader is somewhat of a messy system even from the viewpoint of an experienced developer!
IMO i18n isn't that huge of an issue, because 1) we're building the product to be i18n-able right from the start, as it should be and 2) we can always change the labels etc. either directly in the code or as an "afterthough" via the Interface Messages Wiki (mwmsg.sw).
Jul 17 2016
I was thinking maybe a, for lack of better word, "pop-up", telling them the request has been emailed and will be reviewed by staff as soon as possible. Then they click "ok" to close this message and are redirected back to Special:AdminPanel.
I feel like we need a better name than user permissions. Maybe something along the lines of "privacy settings"? cc: @jack
To quote interns.shoutwiki:
Extension:EnhanceContactForm is how we currently do this in Special:Contact.
My bad, commented on the wrong task
Jul 15 2016
In T66#992, @Southparkfan wrote:Which errors did you get?
Which errors did you get?
Jul 14 2016
Jul 13 2016
The [[https://www.mediawiki.org/wiki/Manual:$wgForeignFileRepos|$wgForeignFileRepos]] configuration setting for {de,es,fi}.shoutwiki.com had the wrong (old) value for the directory key (essentially due to T41: Cleanup legacy image pathing), which tells MW where the physical files are stored at. This is fixed now, but you may need to purge the page to see thumbnails again.
Jul 12 2016
You could also do fancy things with contentmodels.
Jul 11 2016
Assuming most of our log entries are written to be "user safe", there should be nothing wrong with exposing the reason and date behind a wiki deletion (or multiple if that is the case).
They probably are (although I wouldn't want to go through all of them, or write a script to dump 'em either), but a lot of the time the reason isn't even interesting. A lot of them are like "request" or "ticket #so-and-so" or something like that -- obviously the deletion was requested since creators can't delete their wikis, and osTicket is a private communication channel between users and us; a user isn't able to view tickets created by others, so the fact that a wiki was deleted due to "osTicket #9803280" tells them absolutely nothing, I'm afraid.
We should consider that the creator/admin isn't going to be the only one looking at a wiki.
This is obviously true, hence why Special:DeleteWiki is staff-only instead of something that'd allow admins/stewards to delete any wiki that they've created.
I agree with the idea of merging both extensions. However, this isn't exactly a straightforward thing, because of the following:
- Usually users have the choice between a wiki user page and a social user profile, i.e. social profiles aren't enforced (SocialProfile's $wgUserPageChoice config var), so we need to take these into account...
- ...and even if social profiles were enforced, user boards and traditional user talk pages will coexist, because to my knowledge, it just isn't possible to get rid of user talk pages without significant core hacks. Generally speaking most users tend to prefer user boards over talk pages -- I guess it's easier to use those than to go to the desired user's talk page, click "edit", make changes, preview and finally save.
I'm in favour of either of these options - if we want to test the patch to HAWelcome and merge that it could be a great solution until a merge is completed.
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.