Re: [Wikitech-l] Dynamic search results as category pages
Sent from my iPhone On Jan 24, 2014, at 7:55 AM, Brian Wolff bawo...@gmail.com wrote: On Jan 24, 2014 1:54 AM, Yuri Astrakhan yastrak...@wikimedia.org wrote: Hi, I am thinking of implementing a #CATQUERY query magic keyword for the category pages. When this keyword is present, the category page would execute a query against the search backend instead of normal category behavior and show result as if those pages were actually marked with this category. For example, this would allow Greek Philosophers category page to be quickly redefined as a cross-section of greeks philosophers categories: #CATQUERY incategory:Greek incategory:Philosopher Obviously the community will be able to define much more elaborate queries, including the ordering (will be supported by the new search backend) ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l I like the idea in principle, but think the syntax could use bikeshedding ;) If we use this as category pages, im a little worried that people could get confused and try to add [[category:Greek philosophers]] to a page, and expect it to work. We would need good error handling in that situation Also, at least at first, you couldn't use one of these synthetic categories to filter search results so you couldn't use them to build other synthetic categories. including the ordering (will be supported by the new search backend) Cool. I didnt realize search would support this. That's a pretty big deal since people expect there categorirs alphabetized. So I looked into it and it would be easy to implement with Cirrus _but_ I'm not yet sure about the memory implications. We have a ton of headroom on memory now so it might not matter but I need to test it before I can be as confident that it is ok as I was last night at 1am. It may have caveats like synthetic categories must be less than 1000 articles or not all results are included. Another cool project would be to expand intersection/Dyanamic P age List (Wikimedia) to be able to use search as a different backend (however, that extension would need quite a bit of refactoring to get there) -bawolff ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
[Wikitech-l] TitleValue
At the architecture summit yesterday we had a conversation about the TitleValue proposal and the vast majority of folks thought it was a great start. Something like 10% of us thought the patch _might_ be a start down the path to Javaify MediaWiki. I was one of the 10%. We resolved to talk more about the commit before merging it because of the objections of our minority. I felt somewhat vindicated. I slept on it. Now I don't think we made the right choice. I think more discussion is a waste of time and we should just keep moving and try to catch the Javaification if it starts creeping in. The TitleValue proposal is an improvement over what we have now so I figure we should just do it. Is that ok? In the mean time, mostly to humor me, does anyone want to start a list on wiki of some of the Javaification things they are scared of? I promise to contribute some paranoid ramblings which we can debate on the wiki or mailing list. Thanks, Nik ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] RFC cluster summary: HTML templating
I've always been a mustache/handlebars man myself. They fit pretty well with php and javascript as building the kind of data structures they want is petty eat there. Sent from my iPhone On Dec 27, 2013, at 11:58 AM, Ryan Kaldari rkald...@wikimedia.org wrote: What sort of control structures would you want supported? Keep in mind that ideally we want something that is simple enough that it could be loaded as a client-side library on mobile, and also be reasonably sure that it won't introduce any security issues. Ryan Kaldari On Dec 27, 2013, at 7:53 AM, Tyler Romeo tylerro...@gmail.com wrote: It sounds pretty much like the two templating RFCs are asking for the same exact thing, except just using different templating engines as the solution. If we want a comprehensive templating system in PHP core, Mustache is not going to be enough (I've used it before, and dealing with the lack of control structures is frustrating unless the templates are really simple). So I'd support using Twig or something similar to it like jinja2. Either way the RFCs can definitely be combined. *-- * *Tyler Romeo* Stevens Institute of Technology, Class of 2016 Major in Computer Science On Thu, Dec 26, 2013 at 9:09 PM, Jon Robson jdlrob...@gmail.com wrote: +1 to creating a new RFC that satisfies the needs of all 3. Although not mentioned Kaldari's proposal highlights a big existing need in MobileFrontend. Here we use JavaScript templates extensively and are now finding situations where we have the same HTML being generated on the server and client (for example after an edit the entire page is re rendered on the client). I'm very excited to discuss this and push these RFCs along. Please feel free to bring me into any conversations. On 26 Dec 2013 18:04, Rob Lanphier ro...@wikimedia.org wrote: Hi folks, This is an attempt to summarize the list of RFCs that are listed under this cluster: https://www.mediawiki.org/wiki/Architecture_Summit_2014/RFC_Clusters#HTML_templating ...and possibly get a conversation going about all of this in advance of the Architecture Summit. The main focus of all of these RFCs is around HTML generation for user interface elements. This category is not about wikitext templates or anything to do with how we translate wikitext markup Template Engine is Chris Steipp's submission outlining the use of Twig. From my conversations with Chris, it's not so much that he's eager to adopt Twig specifically so much as standardize on *something*, and make sure there's usage guidelines around it to avoid common mistakes. He's seen many attempts at per-extension template libraries that bloat our code and often start off with big security vulnerabilities. There are many extensions that use Twig, and it seems to be a popular choice for new work, so Chris is hoping to standardize on it and put some usage standards around it. HTML templating library is Ryan Kaldari's submission, promoting the use of Mustache or something like it. His main motivation is to have a Javascript template library for front-end work, but is hoping we choose something that has both Javascript and PHP implementations so that any PHP template system implementation is compatible with what we use for Javascript templating. MVC Framework is Owen Davis's description of Wikia's Nirvana framework, which has been central to all of the user-facing work they've been doing for the past 2-3 years. As Owen points out in the talk page for this, it's really view-controller rather than full MVC. A big plus of adopting this RFC is that it would make it much more likely that Wikia-developed extensions (of which there are many) would be of greater use to the larger MediaWiki community, and would generally help facilitate greater collaboration between Wikia and the rest of us. OutputPage Refactor is another submission from Owen Davis, which isn't really about templating, so much as taking the HTML generation code out of OutputPage. Wikia has been maintaining a fork of OutputPage for quite some time, so they already have quite a bit of experience with the proposed changes. This is clustered with the templating proposals, since I imagine the work that gets factored out of OutputPage would need to be factored into whatever templating system we choose. The first three seem somewhat mutually exclusive, though it's clear our task is likely to come up with a fourth proposal that incorporates many requirements of those three. The OutputPage Refactor proposal, given some fleshing out, may not be controversial at all. Where should we go from here? Can we make some substantial progress on moving one or more of these RFCs over the next few weeks? Rob ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] RFC cluster summary: HTML templating
My experience with mustache was that it was reasonably speedy, but that was with Python, java, and javascript libraries, not php. I believe the default way of referencing text in mustache is to escape it. You have to add some special character to the reference to not escape it. I'm pretty sure I've done this one time in my whole life. Sent from my iPhone On Dec 27, 2013, at 12:09 PM, Chris Steipp cste...@wikimedia.org wrote: On Dec 27, 2013 7:54 AM, Tyler Romeo tylerro...@gmail.com wrote: It sounds pretty much like the two templating RFCs are asking for the same exact thing, except just using different templating engines as the solution. If we want a comprehensive templating system in PHP core, Mustache is not going to be enough (I've used it before, and dealing with the lack of control structures is frustrating unless the templates are really simple). So I'd support using Twig or something similar to it like jinja2. Either way the RFCs can definitely be combined. Mustache is probably the second most popular engine that I hear people talk about. I would love to hear more details about what you see as it's shortcomings, or positive features that we would want to look for in whatever library we choose. Kaldari's rfc about JavaScript is a use case I hadn't personally seen in any extensions that I reviewed. But anything to help with our pile of Dom xss vulnerabilities I would gladly support. Are there any other libraries that have the same (or similar) syntax and security properties from php and JavaScript we should look at? I'm happy to research the security of any recommendations we get. Obviously, along with security performance is the next big issue. It would be great if someone could work with Ori to get a feel of how any recommendations perform too. I did some very basic testing on twig. It would be great to see how mustache performes on similar tests. *-- * *Tyler Romeo* Stevens Institute of Technology, Class of 2016 Major in Computer Science On Thu, Dec 26, 2013 at 9:09 PM, Jon Robson jdlrob...@gmail.com wrote: +1 to creating a new RFC that satisfies the needs of all 3. Although not mentioned Kaldari's proposal highlights a big existing need in MobileFrontend. Here we use JavaScript templates extensively and are now finding situations where we have the same HTML being generated on the server and client (for example after an edit the entire page is re rendered on the client). I'm very excited to discuss this and push these RFCs along. Please feel free to bring me into any conversations. On 26 Dec 2013 18:04, Rob Lanphier ro...@wikimedia.org wrote: Hi folks, This is an attempt to summarize the list of RFCs that are listed under this cluster: https://www.mediawiki.org/wiki/Architecture_Summit_2014/RFC_Clusters#HTML_templating ...and possibly get a conversation going about all of this in advance of the Architecture Summit. The main focus of all of these RFCs is around HTML generation for user interface elements. This category is not about wikitext templates or anything to do with how we translate wikitext markup Template Engine is Chris Steipp's submission outlining the use of Twig. From my conversations with Chris, it's not so much that he's eager to adopt Twig specifically so much as standardize on *something*, and make sure there's usage guidelines around it to avoid common mistakes. He's seen many attempts at per-extension template libraries that bloat our code and often start off with big security vulnerabilities. There are many extensions that use Twig, and it seems to be a popular choice for new work, so Chris is hoping to standardize on it and put some usage standards around it. HTML templating library is Ryan Kaldari's submission, promoting the use of Mustache or something like it. His main motivation is to have a Javascript template library for front-end work, but is hoping we choose something that has both Javascript and PHP implementations so that any PHP template system implementation is compatible with what we use for Javascript templating. MVC Framework is Owen Davis's description of Wikia's Nirvana framework, which has been central to all of the user-facing work they've been doing for the past 2-3 years. As Owen points out in the talk page for this, it's really view-controller rather than full MVC. A big plus of adopting this RFC is that it would make it much more likely that Wikia-developed extensions (of which there are many) would be of greater use to the larger MediaWiki community, and would generally help facilitate greater collaboration between Wikia and the rest of us. OutputPage Refactor is another submission from Owen Davis, which isn't really about templating, so much as taking the HTML generation code out of OutputPage. Wikia has been maintaining a fork of OutputPage for quite some time, so they already have quite a bit of experience with the
Re: [Wikitech-l] Deploymight highlights - week of December 16th
Sent from my iPhone On Dec 13, 2013, at 8:13 PM, MZMcBride z...@mzmcbride.com wrote: Greg Grossmeier wrote: * There will be a new version of PHP deployed to the Wikimedia servers on Monday as well. This should not change any user-facing actions (this update will help deal with a server problem where temporary files are not deleted when appropriate). Is there more specific information available about this? That is, we'll be updating from PHP version X to PHP version Y. And what specifically will be changing? Only a patch for temporary files or will other changes be included as well? I ask because even minor changes in PHP can have strange and unforeseen consequences across such a large codebase. * The GLAM Wiki Toolset[3] will be enabled on Commons, allowing for GLAM institutions (Galleries, Libraries, Archives and Museums) to more easily upload bulk collections of images with associated metadata. I was curious whether this new tool would be restricted to specific user groups on Commons. I tracked down https://gerrit.wikimedia.org/r/101061 (via https://bugzilla.wikimedia.org/56181) and it seems that the answer is no (i.e., it will be available to all). Has anyone checked with the Commoners about this proposed deployment? I believe Commons generally has far more restrictive user rights/groups (e.g., requiring users to be a in special user group to simply rename files). * The new search backend (CirrusSearch) will be enabled on: ** all wikinewsies set as secondary search; ** itwiktionary, disabled wikis, cawiki, and enwikisource set as primary search; ** all users on all wikisources will have the option of enabling it as their own personal primary search via BetaFeatures[4]. While https://www.mediawiki.org/wiki/Search mentions disabled, I have no idea what this means. I looked at the database lists at https://noc.wikimedia.org/conf/, but still can't figure out what disabled wikis means. I'm familiar with closed, fishbowl, private, deleted, etc. Disabled is a new term to me. Can someone please clarify? Sorry, I'm using the wrong term. It is just closed wikis. Nik MZMcBride ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Making MediaWiki extensions installable via Composer
Sent from my iPhone On Dec 8, 2013, at 10:22 PM, Rob Lanphier ro...@wikimedia.org wrote: On Sun, Dec 8, 2013 at 3:06 PM, Jeroen De Dauw jeroended...@gmail.comwrote: On Sun, Dec 8, 2013 at 2:42 PM, Bryan Davis bd...@wikimedia.org wrote: Finding a way to separate MW the library from MW the application may be a solution to this conflict. I don't think this would be a trivial project, but it doesn't seem impossible either. That'd be fanatic if it happened for many other reasons as well. For all intents and purposes it is a big caste in the sky though. I expect this to not happen in the coming years, unless there is a big shift in opinion on what constitutes good software design and architecture in the community. It sounds like you're retreating from an argument you haven't even started yet. A successful proposal will likely be one that can be executed incrementally without huge workflow shifts, so there may have been resistance in the past to a particular blow it all up and start over strategy. However, I haven't yet heard anyone put forward the argument that MediaWiki's monolithic architecture is the correct long-term architecture. I largely agree with Bryan that separating MediaWiki the library from MediaWiki the application is something we should consider tackling. I have a quibble with the wording: it should be MediaWiki the set of libraries, not a single library, and it seems like we could start teasing them out one at a time if we can agree on a general framework under which this would be done. Rob ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l Not to be a downer but isn't this one of the things x windows did that upset people? I'm not arguing that this approach is doomed, just that care must be taken. Honestly I don't know the situation well enough to have a super strong opinion. Nik ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
