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.
- Queries
- All Stories
- Search
- Advanced Search
- Transactions
- Transaction Logs
All Stories
Jun 23 2016
Jun 22 2016
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
Ads are looking weird on Mobile Chrome too. Samsung Galaxy A3, Android 5.0.2, Mobile Chrome 51. Can anyone check ads with other browsers?
This looks like it could've been a temporary glitch due to whatever JavaScript loading issues or somesuch on Google's end, or missing JS dependencies; more details, especially on reproducibility, would help. There's a possibility that this bug is one that manifests only on certain platforms (Windows, maybe just Windows 7) when using a certain version of Google Chrome.
Some background info on this: a while ago (when? I can't remember and I'm too lazy to look it up) a bunch of system messages (which link to help pages) were changed to point to MediaWiki.org help pages by default. This makes sense (for most MediaWiki users), because MW.org's help pages are "licensed" into the public domain, are guaranteed to be at least somewhat up-to-date and that way users don't necessarily have to copy the pages to their local wiki(s).
Currently (as of MediaWiki 1.26.3) there are 11 matches for Special:MyLanguage and 28 matches for mediawiki.org in /languages/i18n/en.json. Of these, the following are "user-facing" and might need to be customized for ShoutWiki:
Grunt is scheduled for Thursday, 5AM UTC.
Jun 13 2016
Monolith is now running 14.04, which took about half an hour with no reported downtime (or the window was under 3 minutes and not caught by external monitoring tools).
With Monolith now running 14.04, we should be able to give this another shot.
Jun 11 2016
Jun 9 2016
So the last time we updated our version of Metrolook was in {rSHWK3754}, in December 2015. I'm not sure if we'd need to update our version for the public launch -- no major changes have been done to the skin and AFAIK it's pretty feature-complete, but it'd be nice to be running the latest version, for i18n and whatnot.
Jun 6 2016
While T49 isn't technically blocking this, it makes sense to do it in one swoop
Jun 5 2016
Jun 4 2016
It's worth noting that we've altered Piwik's DB schema slightly (see /extensions/CreateWiki/CreateWiki_backend.php, function addToAnalytics). That being said, I recall we've discussed about this some years ago but I don't remember what was the precise rationale for this, besides the "this is how Piwik devs want you to use their thing from an external application". What benefits does this provide over our current setup of directly doing an INSERT?
May 31 2016
In T41#439, @lewiscawte wrote:Examples - the bot that creates the info pages on hub, and the previous hub pages.
May 30 2016
Examples - the bot that creates the info pages on hub, and the previous hub pages.
So without looking into it further, I seem to recall previous investigation of similar errors resulting in the conclusion that these files didn't exist, and therefore was failing as expected although a mental note was filed that better error handling was needed.
May 28 2016
The analytics code has been wrapped in a try-catch block since 2 November 2014, so it definitely shouldn't be the problem (unless it doesn't work as intended?); if estabilishing a connection to the analytics server fails for whatever reason, it should log an error message to the log (/var/log/hhvm/error.log) but continue deleting whatever it can. Grepping this error log file currently yields 14 matches, 13 of them being "Can't connect to MySQL server on <IP address>" and the odd one out being "Unknown database 'analytics'" (wtf).