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.
- Queries
- All Stories
- Search
- Advanced Search
- Transactions
- Transaction Logs
All Stories
Jul 20 2016
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.
Just be glad we got Scribunto working... you know how many insanely early mornings I put into fixing the blocking tasks to get T18 fixed?
Jul 10 2016
I've prepared fixes & deployed 'em for both skins; our version of Nimbus is now in sync with upstream (see commit d095013c0b2a on phabricator.wikimedia.org).
Does Nimbus also have a "MORE" menu like Monaco?
In addition to Monaco, "More Wikis" is also broken in Nimbus.
Issarra: Do you just work on design? Is the extension idea out of scope and possibly under someone else? If so, I'd be happy to open a new report. However, these two need to work hand-in-hand: Extension and page.
And as for the issue with relevance, we may be able to "tag" wikis and get Piwik to figure out which wikis may seem relevant - kind of like advertising, but in a much sexier way: Instead of products, communities. Putting folks on the map.
CJC - I agree with your response to #2 - we want to show what the community is doing, and not even just the bigger ones; we probably should stand up for the little guys as well, as my attourney of an uncle would have said.
To add to my previous comment, JUST the wiki logo. That is the only image displayed. And, I'm curious about using Microsoft's "Modern" - I'd leave that to the community.
I like what Wikia does, but Lewis has a point: They likely were in the right mindset, but as we know with Wikia, there's a difference between theory and execution. I have a really simple idea for SW:
Jul 9 2016
It would detect ad block users and put a nice little message asking them to consider unblocking us - nothing big or obtrusive or anything. But it hasn't really been thought about much besides a small, untested prototype I wrote a while ago.
- Sidebar would be great.
Jul 8 2016
- Literally just listing them provides no incentive to go to them. That is where at least a logo might make it more eyecatching. Maybe displaying a bit from an article? Not sure how that would work though.
Jul 6 2016
- What about this tiles like in Windows 8 & 10?
- I know only one way to get to Phabricator: write URL in the address bar. Link can make it easier.
2 - We should certainly be promoting some of our wikis on the home page - how we're going to do that I don't think has been decided yet. I'm not a big fan of just listing them, though.
I'm not a designer at all, but I have some ideas:
- Use flat design;
- List popular and big wiki;
- Make giant blue button that creates a wiki;
- Little amount of text, more pictures;
- What is the logo of Shoutwiki? Butterfly? Maybe change it?
- How much languages are supported? 10? It's not very much, don't you think so? If I remember correctly, Wikia supports more languages;
- More help pages;
- Make giant blue button that user can contact support Team with;
- Link to Phabricator somewhere;
- Make giant blue button that links to forum.
What do you think?
For reference, even if some of it might be a bit redundant:
Jul 5 2016
So I'm no authority on design, but here are my thoughts and an idea or two.
The Wikimedia code for this is available in their phabricator/extensions repository.
Jul 3 2016
Compiled 2/7/16.
"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:
Jul 2 2016
Upstream patch: https://gerrit.wikimedia.org/r/#/c/297114/
Local patch: {rSHWK3895}
Jul 1 2016
#site-logo { min-height: 150px; }
fixes this bug. I'll try to commit a patch later today...
Jun 28 2016
I feel like the ideal solution to this is to deal with it via CSS, even if we just do something where we detect no image we put a blank clear one in there. We can put in as many defaults as we like, but at the end of the day that doesn't stop users deleting the images and having the bug.
Jun 24 2016
Perhaps we should implement a default logo of some kind in the Nimbus skin itself? Right now it uses $wgLogo (i.e. Wiki.png on ShoutWiki), but some skins (such as Quartz) use that skin's custom logo (Wiki_wide.png in Quartz) and fall back to $wgLogo if there's no appropriate, skin-specific custom logo...which actually doesn't handle the "$wgLogo doesn't exist" case at all. Maybe I'm wrong and this indeed is a real code bug that we could and should handle with CSS or something. Thoughts?
Jun 23 2016
While importing from starter should avoid this problem, the imported image did not appear. This may be related to our recent changes to image paths and may or may not still be a problem - I know there were changes recently to fix some legacy paths in CreateWiki