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.
- Queries
- All Stories
- Search
- Advanced Search
- Transactions
- Transaction Logs
Advanced Search
Jun 21 2016
{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.)
Jun 15 2016
Jun 11 2016
Jun 6 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).