User talk:Thingles

Logos on this wiki
Heiya Jamie, why not allowing them to be embedded rather than uploading all of them here? Cheers --&#91;&#91;kgh&#93;&#93; (talk) 20:19, December 28, 2012 (CST)


 * Good question. My thought was that the data for a wiki may end up outlasting the wiki itself and the logo image being local would insure that it is available as long as this wiki is. I could support both with a two different fields, or even just detect if the page exists and if it doesn't assume there is a URL in the field. Do you feel strongly remote URL's should be supported? Thingles (talk) 20:22, December 28, 2012 (CST)


 * That's true and a valid idea. I was more thinking from a copyright point of view here. Since this wiki is CC BY-SA and most logos are copyrighted there may arise issues. I believe this can be circumvented by always tagging them as copyrighted an adding a note about logos to the copyright information page of this wiki. Another way to avoid such issues would be to allow remote URL's. Cheers --&#91;&#91;kgh&#93;&#93; (talk) 06:58, December 29, 2012 (CST)

I case we run out of ideas which wiki to add
Heiya Jamie, I do not know if you are aware of this stats portal. There you can also see which information they collect. However, I already like this wiki better. :) Cheers --&#91;&#91;kgh&#93;&#93; (talk) 07:07, December 29, 2012 (CST)


 * I found that when doing a little searching (I linked it on my bookmark wiki). It seems like there are a couple of efforts (and are a couple of abandoned projects as well) to track usage across multiple wikis. I envision WikiApiary overlapping a little with those, but not much. For example, I put the initial set of wikis into apiary so I would have a test set, and I also think it would be crazy to not have the main Wikimedia wikis present. But I don't want to load lists of thousands of wikis. I found the lists for Wikia and such, and I could bulk load them, but I'm not sure that is where I want this to go.


 * Those projects are just numbers and dashboards. I haven't seen anything that looks at versions of MediaWiki and what extensions are installed. I intend to add email features to WikiApiary so you will get an email with weekly and monthly reports on activity. I also want to send emails when versions of extensions or MediaWiki that a site is using are out-of-date. I'm considering adding a feature to do a weekly backup of a wiki (this would require a small fee).


 * Indexing activity on wikis is cool, and there will be some of that. But I'm putting this together in part to answer my own needs (and I think the needs of other wiki admins). What happened on my wiki this week? How active is my wiki? Are my extensions current? Is my wiki backed up? Thingles (talk) 07:33, December 29, 2012 (CST)


 * PS - Thanks for the early praise too! :-)


 * I believe you have done your homework. :) s23 tried to retrieve usage numbers for extensions but this was soon broken. Just recently they removed the link to the usage stats from the extension's template on mediawiki.org. I think to have usage stats for extensions is a great information to have both for developers and users. This wiki is indeed the only one of which I know that caters for this, apart from the smw community wiki which has a much narrower and manual approach on this. Indexing of wikis will come automatically as a side-effect as soon as this wiki gains popularity. Probably you will have to think about "banning" large wikifarms (mediawiki, wikia, etc.) since everything is well known about them and they do their own activity monitoring. However focussing on wiki activity and key tasks is the way to go. +1 for this approach. Cheers --&#91;&#91;kgh&#93;&#93; (talk) 08:22, December 29, 2012 (CST)

Splitting into wiki farms
Heiya Jamie, one thing which might be good to do is to split up the stats for wiki farms as they do at wikistats (s23). Putting an emphasis on wikis of one wikifarm may distort the interpretation of the data displayed. Just an idea for the improvement tracker. :) Cheers --&#91;&#91;kgh&#93;&#93; (talk) 07:14, December 29, 2012 (CST)


 * That is part of what I see using the Tags for. For example, I use my name as a tag for the wikis that I run. Right now this is only used for navigation, but I could see rolling up usage information across the tags in the future. Similarly I tagged Wikimedia run wikis so they can be bundled. Aggregating stats and information across those tags is a future task. Right now the time series data stored outside of the wiki doesn't know about tags. It would be straightforward though to have tags aggregate info just like website_id (example) does now.


 * Probably I just picked the only wiki here without tags to see how you do it. Sounds reasonable to me. :) --&#91;&#91;kgh&#93;&#93; (talk) 08:24, December 29, 2012 (CST)

Changes to templates and forms
Heiya, I have some minor changes to templates and forms. Just revert the ones you do not like. Cheers --&#91;&#91;kgh&#93;&#93; (talk) 19:08, December 29, 2012 (CST)


 * All looks awesome! Thanks for contributing!!! Thingles (talk) 06:15, December 30, 2012 (CST)

I tricked myself
Heiya Jamie, I tricked myself and added the extension to the wrong namespace. Thus Sudo may go. Senior moments I guess. ;) Cheers --&#91;&#91;kgh&#93;&#93; (talk) 05:58, December 30, 2012 (CST)


 * No worries. I deleted that page and I see you updated the Form:Extension to be smart about the namespace. Thanks! Thingles (talk) 06:12, December 30, 2012 (CST)


 * The Extension pages themselves should always get created automatically via Property:Has extension and the use Creates pages with form property but it seems that it doesn't always happen. :-\ Thingles (talk) 06:15, December 30, 2012 (CST)


 * Thank you for deleting. Automatic creation is great, but currently one has to look through them anyway to add the URL and the current version. Updating this will probably be tricky thing. Cheers --&#91;&#91;kgh&#93;&#93; (talk) 06:33, December 30, 2012 (CST)


 * My hope is to have a bot do that work, but that is far down the list and will still be prone to problems since the Extension information on the MediaWiki site is often out-of-date as well. Thingles (talk) 06:41, December 30, 2012 (CST)


 * That's indeed true. Perhaps you can tell the bot to throw a message in case it detects an newer version during data retrieval than the one provided at the extension page? This will be of help for the time being, I guess. --&#91;&#91;kgh&#93;&#93; (talk) 06:50, December 30, 2012 (CST)


 * That's a great idea! Just have Bumble Bee post to the talk pages indicating that the extension appears to have new versions. Nice. Thingles (talk) 07:02, December 30, 2012 (CST)


 * Cool. :) --&#91;&#91;kgh&#93;&#93; (talk) 07:07, December 30, 2012 (CST)

Tags for extensions
Heiya Jamie, what about adding tags to extensions, too? Programmers names could be added and extension groups according to Special:Version (semantic, spam, media, special, parser, other, etc.) Cheers --&#91;&#91;kgh&#93;&#93; (talk) 06:52, December 30, 2012 (CST)


 * That sounds like a great idea. Should they be in a different property? I'm thinking Property:Has extension tag so that there is a different "tag space" for extensions. Thingles (talk) 07:03, December 30, 2012 (CST)


 * Definitely. I am just thinking of having not a common include all property, but one for Programmers Property:Has programmer possibly together with a "Programmer" namespace and one for the group Property:Has extension group with allowed values. Cheers --&#91;&#91;kgh&#93;&#93; (talk) 07:12, December 30, 2012 (CST)


 * I would just go with one Property:Has extension tag for now and see where it goes. A separate developer/programmer property feels redundant to the MediaWiki extension repository. Thingles (talk) 07:15, December 30, 2012 (CST)


 * Sure, fair enough. --&#91;&#91;kgh&#93;&#93; (talk) 07:26, December 30, 2012 (CST)


 * Up and running. :) --&#91;&#91;kgh&#93;&#93; (talk) 08:19, December 30, 2012 (CST)


 * This is awesome by the way! Thingles (talk) 14:32, December 31, 2012 (CST)

I am amazed ...
... to see that just the 100 something websites which have been added here already use about 15 % of all MediaWiki extensions. I would not have expected to see this variety. --&#91;&#91;kgh&#93;&#93; (talk) 14:10, December 30, 2012 (CST)


 * Wow! That is very cool to know. I personally love to be able to see the versions that are being used. Something I'm going to add to the roadmap is snapshotting the extension/version count each day, so we can see how long it takes for new versions of things to roll out. Thingles (talk) 14:38, December 30, 2012 (CST)


 * There are about 2200 extensions published on mw.o and I estimate that another third is located on various other places around the web. So its 7.5 % and not 15 %. Ouch.


 * From a devolopers point of view it it probably as interesting to know how long it takes until sysadmins upgrade their MediaWiki, too. I would also add this to the roadmap. Talking about the roadmap: It would be cool if the statistics on PHP versions used could be aggregated by version and not by version and variety, i.e. one bar for 5.3.2 and 5.3.2-lenny-foo. Cheers --&#91;&#91;kgh&#93;&#93; (talk) 15:03, December 30, 2012 (CST)


 * I created a new template Get simple version number that will take the version just left of the - and separated the properties. There are now properties for the version as well as secondary properties for the version details. This is a very nice change. Thanks for suggesting it! Thingles (talk) 14:32, December 31, 2012 (CST)


 * Great, that's very smart how you did it. I can definitely learn from you here and will do so. I appreciate this. :) Were is still one suggestion which might need some voodoo. I order to get a decent sorting some internal padding will have to be added. So far the sorting is 1, 10, 2, etc. Thus 01, 02, ..., 10 would be cool. Perhaps this is some additional requirement to the request to get decent number formatting to SMW. O_o Cheers --&#91;&#91;kgh&#93;&#93; (talk) 06:21, January 1, 2013 (CST)


 * Thanks for the complement! :-) That template is a simplified version of one I made to get the hostname from a URL. The sorting of versions is still a problem. The right way to do that is to store three separate number properties: major version, minor version, fix version. I could easily take the output of the simple version, split it into an array using the  and then shove them into three new properties. Then sort on those. That is likely the real/right way to do it but I'm hesitant to add 9 new properties (MediaWiki, PHP and Database). But I probably shouldn't worry about it. Thoughts? Thingles (talk) 07:58, January 1, 2013 (CST)


 * I would not worry about having too many properties. With the new SQL-store in place performance should not suffer from this as it would have before. You could even create a separate table for the properties as soon as they hit a substantial number of values. I also think this is quiet a common usecase. I remember people on the mailing list asking to do this with IP addresses. This could even be added to the SMW community wiki as a tip or to the mediawikicookbook though it is currently done or even gone. I should add your website to my favourites. :) --&#91;&#91;kgh&#93;&#93; (talk) 08:26, January 1, 2013 (CST)

Extension:MagicNoCache
Heiya, what about this extension? I think it could be useful for e.g. "Main page" and "Extension:Main page" Cheers --&#91;&#91;kgh&#93;&#93; (talk) 05:57, December 31, 2012 (CST)


 * Maybe, but I wouldn't mind allowing the Main Page to be cached though. In general the current layout will only work so long. Now at over 100 sites there are probably too many. I started a topic on Talk:Main Page to explore what really belongs on the main page. Thingles (talk) 14:34, December 31, 2012 (CST)

Short descriptions for extensions
I think we will have to add short descriptions to the extensions as well in order to add additional value. Just having the name, the current version and a link to it does not seem enough to me. --&#91;&#91;kgh&#93;&#93; (talk) 06:37, January 1, 2013 (CST)


 * I've been struggling myself with the fact that I'm throwing away all this data that I get when I pull extensions. This is the JSON block I get back

{	"query": { "extensions": [ {				"type": "parserhook", "name": "SyntaxHighlight", "description": "Provides syntax highlighting using [http:\/\/qbnz.com\/highlighter\/ GeSHi Highlighter]", "descriptionmsg": "syntaxhighlight-desc", "author": "Brion Vibber, Tim Starling, Rob Church, Niklas Laxstr\u00f6m", "url": "http:\/\/www.mediawiki.org\/wiki\/Extension:SyntaxHighlight_GeSHi" },			{				"type": "parserhook", "name": "ParserFunctions", "description": "Enhance parser with logical functions", "descriptionmsg": "pfunc_desc", "author": "Tim Starling, Robert Rohde, Ross McClure, Juraj Simlovic", "url": "http:\/\/www.mediawiki.org\/wiki\/Extension:ParserFunctions", "version": "1.3.0" },			{				"type": "parserhook", "name": "CategoryTree", "description": "Dynamically navigate the category structure", "descriptionmsg": "categorytree-desc", "author": "Daniel Kinzler", "url": "http:\/\/www.mediawiki.org\/wiki\/Extension:CategoryTree" }, …


 * When I record the extension for the website I'm only capturing the stuff unique to the website, name and version (if provided).


 * I could easily modify the bot to write all these fields in the extension pages for each website. Or, more difficult, is to have the bot modify the Extension pages in the extension namespace with this information. But that introduces complications like what if author value changes from 1.0 to 1.1 and both are in use. The bot needs to have logic to know that 1.1 > 1.0 and write that. Complicated.


 * Maybe for now I should just modify the bot to write all data in the extension subpage, and thus into the extension subobjects and then see what we can do in the templates? That means we would have 100 descriptions for Extension:ParserFunctions that probably are all the same, but maybe not. Then we decide what we want to pull into the Extension:ParserFunctions page. Thingles (talk) 07:39, January 1, 2013 (CST)


 * Hmm, actually this only has to be done once for each extension upon creation. Only versions change frequently and sometimes the author. Perhaps it is possible to do this once, add the data to the page and check e.g. quarterly if there was a change or so. Whatever appears more easy to implement I suppose. Cheers --&#91;&#91;kgh&#93;&#93; (talk) 08:42, January 1, 2013 (CST)

Database error on saving a new wiki
Heiya Jamie, the External Data extension causes some troubles: A database query syntax error has occurred. This may indicate a bug in the software. The last attempted database query was:

(SQL query hidden)

from within function "EDUtils::searchDB". Database returned error "1064: You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near 'ORDER BY capture_date desc LIMIT 1' at line 1 (localhost)". Did you change something there? Cheers --&#91;&#91;kgh&#93;&#93; (talk) 07:03, January 1, 2013 (CST)


 * My bad. Fixed (diff) by checking for existence of  before calling the Template:Website indexes.   is an odd magic word since it doesn't exist until after the first save. So, if you use it, you have to conditionally check it if you have dependencies on it. I used   as my external key for the bots and the Apiary database to work with the wiki.


 * I could have figured this out myself. Yes, this magic word is a bit odd, but this is within it's nature. To tell you the truth: I asked for this on bugzilla about two years ago and I was very surprised that they actually added it. --&#91;&#91;kgh&#93;&#93; (talk) 08:29, January 1, 2013 (CST)


 * I'm glad you asked for it and that they put it in. It's actually a very very critical magic word for cases where wikis have to interact with other systems or applications. Thingles (talk) 08:42, January 1, 2013 (CST)


 * This was the very reason why I asked for this. At the beginning there was quite some opposition to it. Luckily a story of history past. --&#91;&#91;kgh&#93;&#93; (talk) 08:44, January 1, 2013 (CST)