I had tweak a bunch of code to even get it to work, not to mention replace a whole bunch of deprecated functions. People seem to love those these days. I’m in the process of taking over a script from Chris G Bot, and again lots of deprecated functions. :/ I can try to see if I can unlock the namespace lock, but I need to find out where that is happening.

As for xTools, with a temporary solution now in place for articleinfo, I believe we can start working on a rewrite for xtools. We already have smarty templates, so interface shouldn’t be a major concern. I propose we break the workload up tools, and assign an individual tool to a user, while one other user writes the code for communicating to the proper medium to get results. Another idea is to write a Communication class and put it in a file call communincation.php. It will essentially do all the querying needed to get the results in one go for any tool. This means that all the query strings for the API and the DB, will be saved in this class. I think this is a preferred solution as this will allow us to easily make necessary changes to queries in response to any API or DB changes we encounter, without having to sift through the code. Another thing I propose is the addition of a configuration file such as config.local.inc.php and config.inc.php. This would be the location where hardcoded OAuth settings and file paths would be stored, or anything hardcoded that may need to be modified to move the tool. This will allow us to make the tool mobile and allow us to be able to set up a local installation about as fast as it takes to say “pi”. If anyone has some objections, I can start fashioning up some efficient communication codes and create the class, as well as some things to put in the config file.

Cyberpower678

English Wikipedia Account Creation Team

Mailing List Moderator

From: xtools-bounces@lists.wikimedia.org [mailto:xtools-bounces@lists.wikimedia.org] On Behalf Of MusikAnimal Sent: Tuesday, July 21, 2015 11:08 PM To: Discussion list for xTools Subject: Re: [xTools] Wikihistory is here

Awesome!!!! Great work Max! :)

I've updated [[MediaWiki:Histlegend]] to link to this for mainspace pages, and to the old xtools for other namespaces, as I figure that's better than the "article not found" message WikiHistory throws.

So I assume it's probably too much work to make this work for any namespace? Seemingly it would not be, as the API is uniform for any namespace... but hell if I'd know :)

Kudos!

On 21 July 2015 at 21:12, L235 Wikipedia l235@l235.net wrote:

Congratulations - have you made an on-wiki announcement?

Regards from Chansha, Hunan Province, China

L235

On Wednesday, July 22, 2015, Maximilian Doerr maximilian.doerr@gmail.com wrote:

Ladies and gentlemen. Wikihistory is now available for use on en.wikipedia.org. You can find it at http://tools.wmflabs.org/xtools/wikihistory/ J

Cyberpower678

English Wikipedia Account Creation Team

Mailing List Moderator

Hmm. I’m still more keen on putting all queries in one file and simply having the tool run a function called, Communication::getEditCountData();, or Communication::getArticleInfoData(); The Communication class will basically normalize/universalize the formatting of the data to fit the tools’ needs. Any change to the DB or API can be met with an easy fix to the class, be it how the data is returned, or what string is needed to get the data, without having to modify any other code on the tool. As for queries, logically the answer is yes. We only query what we need, or it will end up taking 4 days to run the query. :p We should avoid frameworks. If anything we should create our own basic framework, like the Communication class I suggested, which does all the data retrieval labor. It’s got to be something we can all understand, and modify as necessary.

Cyberpower678

English Wikipedia Account Creation Team

Mailing List Moderator

From: xtools-bounces@lists.wikimedia.org [mailto:xtools-bounces@lists.wikimedia.org] On Behalf Of MusikAnimal Sent: Wednesday, July 22, 2015 10:59 AM To: Discussion list for xTools Subject: Re: [xTools] Wikihistory is here

Hmm, I could go either way with this. Personally I might be more fond of separating out responsibilities to each tool entirely. The idea being if we updated one tool we wouldn't have to worry about it breaking the other tools. If database or API changes occur we might just as likely have to update the code that handles the data. An example would be when a column is renamed (although very unlikely to happen!), so you'd have to change the code that reads the API/db response.

Refactoring is of course a good thing, but maybe restrict it to the actual API/db query functionality (like a wrapper or something), and not the queries themselves. So if you had a dbquery/API wrapper, from each tool you could pass it the specific SQL/parameters you want, and the wrapper would take care of anything common to all queries, such as handling of continuation data. This is what I would envision a "communications class" to entail. For each tool, you could define the SQL queries that it uses at the top of the file for easy reference. My thoughts are they wouldn't change much, except for optimizations.

For performance reasons and for the user experience, we only query what we need for a given tool, right? For instance, if I use the Top Edits by user tool, it's not going to use the same SQL queries as the edit counter? If this is true, which I think it should be, I don't see many queries that would be shared amongst tools anyway. They all sort of do their own unique thing.

That's my two cents, but as the developers you guys should decide what's best.

Just so we're clear, I think we've ruled out usage of any frameworks, correct? Just the templating engines? So long as there's no backend code in the markup I think we'll be making a huge improvement over the current codebase.

On 22 July 2015 at 09:15, Maximilian Doerr maximilian.doerr@gmail.com wrote:

I had tweak a bunch of code to even get it to work, not to mention replace a whole bunch of deprecated functions. People seem to love those these days. I’m in the process of taking over a script from Chris G Bot, and again lots of deprecated functions. :/ I can try to see if I can unlock the namespace lock, but I need to find out where that is happening.

As for xTools, with a temporary solution now in place for articleinfo, I believe we can start working on a rewrite for xtools. We already have smarty templates, so interface shouldn’t be a major concern. I propose we break the workload up tools, and assign an individual tool to a user, while one other user writes the code for communicating to the proper medium to get results. Another idea is to write a Communication class and put it in a file call communincation.php. It will essentially do all the querying needed to get the results in one go for any tool. This means that all the query strings for the API and the DB, will be saved in this class. I think this is a preferred solution as this will allow us to easily make necessary changes to queries in response to any API or DB changes we encounter, without having to sift through the code. Another thing I propose is the addition of a configuration file such as config.local.inc.php and config.inc.php. This would be the location where hardcoded OAuth settings and file paths would be stored, or anything hardcoded that may need to be modified to move the tool. This will allow us to make the tool mobile and allow us to be able to set up a local installation about as fast as it takes to say “pi”. If anyone has some objections, I can start fashioning up some efficient communication codes and create the class, as well as some things to put in the config file.

Cyberpower678

English Wikipedia Account Creation Team

Mailing List Moderator

From: xtools-bounces@lists.wikimedia.org [mailto:xtools-bounces@lists.wikimedia.org] On Behalf Of MusikAnimal Sent: Tuesday, July 21, 2015 11:08 PM To: Discussion list for xTools Subject: Re: [xTools] Wikihistory is here

Awesome!!!! Great work Max! :)

I've updated [[MediaWiki:Histlegend]] to link to this for mainspace pages, and to the old xtools for other namespaces, as I figure that's better than the "article not found" message WikiHistory throws.

So I assume it's probably too much work to make this work for any namespace? Seemingly it would not be, as the API is uniform for any namespace... but hell if I'd know :)

Kudos!

On 21 July 2015 at 21:12, L235 Wikipedia l235@l235.net wrote:

Congratulations - have you made an on-wiki announcement?

Regards from Chansha, Hunan Province, China

L235

On Wednesday, July 22, 2015, Maximilian Doerr maximilian.doerr@gmail.com wrote:

Ladies and gentlemen. Wikihistory is now available for use on en.wikipedia.org. You can find it at http://tools.wmflabs.org/xtools/wikihistory/ J

Cyberpower678

English Wikipedia Account Creation Team

Mailing List Moderator

Pretty much. The Communication class will do the big labor of efficiently collecting and organizing the raw data. The tool simply makes use of the data, and processes it as needed, and then throw that data into the Smarty template. No DB calls, initializations, API queries, nothing. It’s all graciously handled by the communication class. I will start working on the Communication class tonight, and create some stuff to put in a config file.

But I am reminded on one thing. We need to respect optin consensus globally. At current global consensus favors optin, while enwiki has no opt.

Cyberpower678

English Wikipedia Account Creation Team

Mailing List Moderator

From: xtools-bounces@lists.wikimedia.org [mailto:xtools-bounces@lists.wikimedia.org] On Behalf Of MusikAnimal Sent: Wednesday, July 22, 2015 11:46 AM To: Discussion list for xTools Subject: Re: [xTools] Wikihistory is here

Well I must say Communication::getArticleInfoData() is very nice on the eyes :) I think you've won me over just on that!

We can adapt the queries from the old xtools, no? That way our devs already have that ready for them. From there it's just calling the fetch data method and rendering the template.

So for a given tool, on a high level the developer would do something like (1) convert all the markup to templates (2) once the form is submitted (or relevant URL parameters are provided) do the query via Communications class (3) render data in templates (4) Go drink a beer. Am I missing anything?

On 22 July 2015 at 11:10, Maximilian Doerr maximilian.doerr@gmail.com wrote:

Hmm. I’m still more keen on putting all queries in one file and simply having the tool run a function called, Communication::getEditCountData();, or Communication::getArticleInfoData(); The Communication class will basically normalize/universalize the formatting of the data to fit the tools’ needs. Any change to the DB or API can be met with an easy fix to the class, be it how the data is returned, or what string is needed to get the data, without having to modify any other code on the tool. As for queries, logically the answer is yes. We only query what we need, or it will end up taking 4 days to run the query. :p We should avoid frameworks. If anything we should create our own basic framework, like the Communication class I suggested, which does all the data retrieval labor. It’s got to be something we can all understand, and modify as necessary.

Cyberpower678

English Wikipedia Account Creation Team

Mailing List Moderator

From: xtools-bounces@lists.wikimedia.org [mailto:xtools-bounces@lists.wikimedia.org] On Behalf Of MusikAnimal Sent: Wednesday, July 22, 2015 10:59 AM

To: Discussion list for xTools Subject: Re: [xTools] Wikihistory is here

Hmm, I could go either way with this. Personally I might be more fond of separating out responsibilities to each tool entirely. The idea being if we updated one tool we wouldn't have to worry about it breaking the other tools. If database or API changes occur we might just as likely have to update the code that handles the data. An example would be when a column is renamed (although very unlikely to happen!), so you'd have to change the code that reads the API/db response.

Refactoring is of course a good thing, but maybe restrict it to the actual API/db query functionality (like a wrapper or something), and not the queries themselves. So if you had a dbquery/API wrapper, from each tool you could pass it the specific SQL/parameters you want, and the wrapper would take care of anything common to all queries, such as handling of continuation data. This is what I would envision a "communications class" to entail. For each tool, you could define the SQL queries that it uses at the top of the file for easy reference. My thoughts are they wouldn't change much, except for optimizations.

For performance reasons and for the user experience, we only query what we need for a given tool, right? For instance, if I use the Top Edits by user tool, it's not going to use the same SQL queries as the edit counter? If this is true, which I think it should be, I don't see many queries that would be shared amongst tools anyway. They all sort of do their own unique thing.

That's my two cents, but as the developers you guys should decide what's best.

Just so we're clear, I think we've ruled out usage of any frameworks, correct? Just the templating engines? So long as there's no backend code in the markup I think we'll be making a huge improvement over the current codebase.

On 22 July 2015 at 09:15, Maximilian Doerr maximilian.doerr@gmail.com wrote:

I had tweak a bunch of code to even get it to work, not to mention replace a whole bunch of deprecated functions. People seem to love those these days. I’m in the process of taking over a script from Chris G Bot, and again lots of deprecated functions. :/ I can try to see if I can unlock the namespace lock, but I need to find out where that is happening.

As for xTools, with a temporary solution now in place for articleinfo, I believe we can start working on a rewrite for xtools. We already have smarty templates, so interface shouldn’t be a major concern. I propose we break the workload up tools, and assign an individual tool to a user, while one other user writes the code for communicating to the proper medium to get results. Another idea is to write a Communication class and put it in a file call communincation.php. It will essentially do all the querying needed to get the results in one go for any tool. This means that all the query strings for the API and the DB, will be saved in this class. I think this is a preferred solution as this will allow us to easily make necessary changes to queries in response to any API or DB changes we encounter, without having to sift through the code. Another thing I propose is the addition of a configuration file such as config.local.inc.php and config.inc.php. This would be the location where hardcoded OAuth settings and file paths would be stored, or anything hardcoded that may need to be modified to move the tool. This will allow us to make the tool mobile and allow us to be able to set up a local installation about as fast as it takes to say “pi”. If anyone has some objections, I can start fashioning up some efficient communication codes and create the class, as well as some things to put in the config file.

Cyberpower678

English Wikipedia Account Creation Team

Mailing List Moderator

From: xtools-bounces@lists.wikimedia.org [mailto:xtools-bounces@lists.wikimedia.org] On Behalf Of MusikAnimal Sent: Tuesday, July 21, 2015 11:08 PM To: Discussion list for xTools Subject: Re: [xTools] Wikihistory is here

Awesome!!!! Great work Max! :)

I've updated [[MediaWiki:Histlegend]] to link to this for mainspace pages, and to the old xtools for other namespaces, as I figure that's better than the "article not found" message WikiHistory throws.

So I assume it's probably too much work to make this work for any namespace? Seemingly it would not be, as the API is uniform for any namespace... but hell if I'd know :)

Kudos!

On 21 July 2015 at 21:12, L235 Wikipedia l235@l235.net wrote:

Congratulations - have you made an on-wiki announcement?

Regards from Chansha, Hunan Province, China

L235

On Wednesday, July 22, 2015, Maximilian Doerr maximilian.doerr@gmail.com wrote:

Ladies and gentlemen. Wikihistory is now available for use on en.wikipedia.org. You can find it at http://tools.wmflabs.org/xtools/wikihistory/ J

Cyberpower678

English Wikipedia Account Creation Team

Mailing List Moderator

Cyberpower678, congratulations on the breakthrough. It's pretty clear that the data feed is slightly different from the articleinfo datafeed . I like how the connection is instantaneous after the properly-spelled article name gets entered. It took me awhile, after experimentation, to understand that 'Science' is what is required in the datafield to see the 'science' enwiki article.

Everyone, I wonder if it would be possible to patch in the URL to wikihistory when the enwiki user selects Page history (i.e., articleinfo) in xTools. Aesthetics aside, a user simply cares about the results. Or perhaps, simply announce the current status in village pump, with some 'oh, by the way'-instructions on how this works for enwiki.

On Wed, Jul 22, 2015 at 9:09 PM, Chris cs@edubkk.org wrote:

"As for xTools, with a temporary solution now in place for articleinfo, I believe we can start working on a rewrite for xtools.”

Just mentioning that a) No need for this to be a temporary solution. I do not understand the preoccupation with rewriting everything. We saw where that got us with the Edit counter.

b) The solution is still a major prority because the developers have ignored the fact that the ‘ArticleHistory’ tool is required for ALL namespaces.

Again, we have issues here of the devs, however much they are working voluntarily and in good faith, are doing what they want to do and not what the community /users need and want. This is a common problem in the whole world with all software development whether free, open source, or paid for. This may be a communication problerm where multiple devs are involved on the making of a single software application.

Kudpung.

On 22 Jul 2015, at 20:15, Maximilian Doerr maximilian.doerr@gmail.com wrote:

As for xTools, with a temporary solution now in place for articleinfo, I believe we can start working on a rewrite for xtools.

---

Maintainers: Cyberpower678, Technical 13, MusikAnimal, Elee, Nakon, L235 xTools mailing list xTools@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/xtools

WikiHistory: So far, so good. Please let us know as soon as it is working for all namespaces. Namely this is what is holding up a lot of research work for new policies.

Kudpung

On 22Jul, 2015, at 08:12, L235 Wikipedia l235@l235.net wrote:

Congratulations - have you made an on-wiki announcement?

Regards from Chansha, Hunan Province, China

L235

On Wednesday, July 22, 2015, Maximilian Doerr <maximilian.doerr@gmail.com mailto:maximilian.doerr@gmail.com> wrote: Ladies and gentlemen. Wikihistory is now available for use on en.wikipedia.org http://en.wikipedia.org/. You can find it at http://tools.wmflabs.org/xtools/wikihistory/ http://tools.wmflabs.org/xtools/wikihistory/ J

Cyberpower678

English Wikipedia Account Creation Team

Mailing List Moderator

-- Thanks, L235 https://en.wikipedia.org/wiki/User:L235 https://en.wikipedia.org/wiki/User:L235 _______________________________________________ Maintainers: Cyberpower678, Technical 13, MusikAnimal, Elee, Nakon, L235 xTools mailing list xTools@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/xtools