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?
- Queries
- All Stories
- Search
- Advanced Search
- Transactions
- Transaction Logs
All Stories
Jul 11 2016
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
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.
LuaSandbox is now deployed on Monolith, and namespaceDupes.php is running to move all the Module: namespace pages to the correct namespace.
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.
In addition to this, the wiki 'type' value we ask users to set has no impact on these settings and sometimes does not reflect the permissions at all.
{rSHWK3884}, which I deployed earlier on, fixed this. (At least I believe it was that revision, might also have something to do with the few older patches, of which at least one was related to analytics. Anyway RESOLVED FIXED.)
Currently running, position (alphabetically as of posting): brandyland.
Jun 17 2016
Jun 16 2016
Grunt and Vertex were upgraded this morning.
There's a document.write in https://phabricator.wikimedia.org/diffusion/EDSN/browse/master/DismissableSiteNotice.hooks.php , what do you think?
So something somewhere is calling document.write, which isn't really supported in MediaWiki anymore and that's breaking things. This results in a warning logged into the browser's JS console: "Use of 'write' is deprecated. Use jQuery or mw.loader.load instead.". This traces back to the file /resources/src/mediawiki.legacy/wikibits.js.
I was able to reproduce the broken ad behavior in Opera 37.0.2178.32 under Windows 7.
div#mw-panel-right { top: 120px; }
might/should fix this, at least for anons. Tested on Opera 37.0.2178.32 under Windows 7. No idea what to do w/ logged-in users, though.
The ad needs pushing further down the page. Overlaying that user menu on top of the ad is just calling for an invalid click activity strike.
Jun 15 2016
Oddly enough, I've gotten several different ad placements, including the correct one. This is on Chrome 51.0.2704.84 on OS X 10.11.4 (El Capitan). Here are some examples:
Sidebar isn't working, after a couple of refreshes here and there - Using Windows 10, Chrome v51.0.2704.84, 1366 x 768