Congratulations - have you made an on-wiki announcement? Regards from Chansha, Hunan Province, China L235 On Wednesday, July 22, 2015, Maximilian Doerr <maximilian.doerr(a)gmail.com> wrote: -- Thanks, L235 https://en.wikipedia.org/wiki/User:L235

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(a)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 &lt;l235(a)l235.net&gt; wrote: Congratulations - have you made an on-wiki announcement? Regards from Chansha, Hunan Province, China L235 On Wednesday, July 22, 2015, Maximilian Doerr &lt;maximilian.doerr(a)gmail.com&gt; 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 -- 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(a)lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/xtools

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(a)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 &lt;maximilian.doerr(a)gmail.com&gt; 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(a)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 &lt;l235(a)l235.net&gt; wrote: Congratulations - have you made an on-wiki announcement? Regards from Chansha, Hunan Province, China L235 On Wednesday, July 22, 2015, Maximilian Doerr &lt;maximilian.doerr(a)gmail.com&gt; 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 -- 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(a)lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/xtools _______________________________________________ Maintainers: Cyberpower678, Technical 13, MusikAnimal, Elee, Nakon, L235 xTools mailing list xTools(a)lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/xtools

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(a)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 &lt;maximilian.doerr(a)gmail.com&gt; 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(a)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 &lt;maximilian.doerr(a)gmail.com&gt; 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(a)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 &lt;l235(a)l235.net&gt; wrote: Congratulations - have you made an on-wiki announcement? Regards from Chansha, Hunan Province, China L235 On Wednesday, July 22, 2015, Maximilian Doerr &lt;maximilian.doerr(a)gmail.com&gt; 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 -- 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(a)lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/xtools _______________________________________________ Maintainers: Cyberpower678, Technical 13, MusikAnimal, Elee, Nakon, L235 xTools mailing list xTools(a)lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/xtools _______________________________________________ Maintainers: Cyberpower678, Technical 13, MusikAnimal, Elee, Nakon, L235 xTools mailing list xTools(a)lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/xtools

"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.

Hi Kudpung, I believe you are suffering from a miscommunication here. Wiki history is only a temporary solution here because it is very restrictive by nature. It lacks info articleinfo has and the namespace issue. It I was adamantly built to only support article space. I'm still working on fixing this but it's a difficult task given the code. The objective is to get articleinfo up and running as it provides extraordinary amounts of information. The point of the rewrite is to simply create code we can all understand and maintain. The HTML output will not change nor will the functionality. The current code is too hard to maintain, and articleinfo is a perfect example of that. Picture it this way the problem with article info is like an oil leak in a car. You take it to service, where the services are maintainers. They look at it and find all the lines are intact. Your car continues to leak and nobody at any service center can figure out what is going on. This is the situation we are in. We are simply rebuilding the tool's core that does the labor of data retrieval and processing. Cyberpower678 English Wikipedia Account Creation Team Mailing List Moderator