Hi Jason, Regarding embedding Flow at the base of a standard wikipage (as LQT can do), that's not currently possible, but Flow does have a header area that uses wikitext, and can be as long as desired. See and test freely, at https://test.wikipedia.org/wiki/Talk:Sandbox Would that meet your use-cases? If not, please could you describe or point to examples of what you're after?
I've asked some of the Flow devs to comment on your questions about querying, and to give details on the upcoming/planned new ways to enable Flow selectively via the API, and via an on-wiki interface, without having to edit any config files. Nick / Quiddity On Wed, Feb 4, 2015 at 12:59 PM, Jason Ji <[email protected]> wrote: > Hi Max, > > I'm looking at Flow today. The documentation talks about how to replace > individual pages or entire namespaces with flow boards (using > $wgFlowOccupyPages and $wgFlowOccupyNamespaces). However, is there a way to > embed a Flow board at the base of a wiki page, as a more traditional > commenting system might look like? Also, is there a way to query for Flow > comments with parameters such as Flow comments by user, Flow comments by > associated page, etc? > > Thanks, > Jason Ji > > > On Fri, Jan 30, 2015 at 7:40 PM, Max Semenik <[email protected]> > wrote: > > > On Fri, Jan 30, 2015 at 10:11 AM, Jason Ji <[email protected]> wrote: > > > > > Thanks for your feedback. To clarify a bit, we're not thinking of using > > > LiquidThreads as it is - we have a different extension we will be > > building, > > > with some different needs than LQT has. For example, we may not need > any > > > integration with watchlists. So our thought is that we might fork LQT > and > > > modify it to suit our needs. We're still very early in the design > phase. > > > > > > > The bad part of LQT is not about interaction with watchlist. It will be > > essentially untouched by any trimming short of complete rewrite. > > > > > > > Max - when you say just use Flow, do you mean we should fork the Flow > > code > > > base and work from there, or that we should just install Flow? Flow > looks > > > interesting, but we're not sure it will have the features we need, and > > our > > > timeframe is likely to be shorter than the timeframe of Flow > development. > > > > > > > If you fork something, you will have to maintain it forever - why not put > > the same effort in contributing to mainline instead? And Flow is quite > > complete for most use cases, and its team is mostly working on adding > > support for various crazy workflows user communities have created in more > > than 10 years without a good discussion system. I don't think you need to > > wait for these. > > > > > > > Is there somewhere I can go read in detail about the bugs and unfixable > > > problems with LQT? We might not fork LQT at all, but we were also > > thinking > > > of using wiki pages to store comment text. So if that idea is > > fundamentally > > > broken, it would be great to know why. > > > > > > I already explained why, bugs are here: > > https://phabricator.wikimedia.org/search/query/ojED3mdcIKDQ/ > > > > > > -- > > Best regards, > > Max Semenik ([[User:MaxSem]]) > > _______________________________________________ > > MediaWiki-l mailing list > > To unsubscribe, go to: > > https://lists.wikimedia.org/mailman/listinfo/mediawiki-l > > > _______________________________________________ > MediaWiki-l mailing list > To unsubscribe, go to: > https://lists.wikimedia.org/mailman/listinfo/mediawiki-l > -- Nick Wilson (Quiddity) Community Liaison Wikimedia Foundation _______________________________________________ MediaWiki-l mailing list To unsubscribe, go to: https://lists.wikimedia.org/mailman/listinfo/mediawiki-l
