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
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 <jason.y.ji(a)gmail.com> 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 <maxsem.wiki(a)gmail.com>
wrote:
On Fri, Jan 30, 2015 at 10:11 AM, Jason Ji
<jason.y.ji(a)gmail.com> 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