Talk:Flow

Jump to: navigation, search

About this board

The Collaboration team has enabled Flow on this talk page (documentation).

Previous feedback is on Talk:Flow Portal/Archive2 (using old Liquid Threads), and on our labs server.

You can leave your message in any language, but answers will be made in English (or your language if we speak it).

By clicking "Add topic", you agree to our Terms of Use and agree to irrevocably release your text under the CC BY-SA 3.0 License and GFDL

What pages can be translated on MediaWiki?

6
Сунприат (talkcontribs)

What pages of Flow documentation on the MediaWiki provided with markup for translation?

Quiddity (WMF) (talkcontribs)

The current documentation pages, are all too large, or too out-dated, and not well-written for translation. I want to research what the "Best practices" are, but I have not had time, recently.

Do you (or anyone) have favourite pages that you wish Flow would copy? (in layout and structure and wording).

Сунприат (talkcontribs)

Hide, suppress, moderation (Flow/Functional_Specifications/Moderation,_Protection,_and_Refactoring#Moderation_and_Suppression, Extension:Flow/Moderation#States_.26_permissions)

Indentation model Topic:Senq838us190rqlp

Flow - Rationale, Components of the discussion system, Release and features FAQ, Design FAQ

make them as Flow/Nomenclature

Quiddity (WMF) (talkcontribs)

Ah, thank you. That helps me understand which pages (and details) you want translatable. Yes, we will try to split the large Flow page into smaller sub-pages.

But I was also wondering, are there any other extensions/pages, that you really like, at mediawiki or other wikis? E.g. I will probably use these extensions, as a model or guide: Template:VisualEditor Portal/core, Template:ContentTranslation Portal/core, other?

This comment was hidden by Сунприат (history)
Сунприат (talkcontribs)

No, I do not have favorite pages, which could be taken as a model.

Reply to "What pages can be translated on MediaWiki?"

How long is this Flow testing going to continue?

17
SMcCandlish (talkcontribs)

It's obviously difficult to use and most wikis want nothing to do with it. Not every idea WMF has needs to be pursued indefinitely.  — SMcCandlish ¢ ≽ʌⱷ҅ʌ≼  04:58, 24 July 2016 (UTC)

Sänger (talkcontribs)

They just don't get it, as usual.

They even ban the VirtualEditor from the talk pages just to get this junk some more traction.

Grüße vom Sänger ♫(Reden) 09:37, 24 July 2016 (UTC)

SMcCandlish (talkcontribs)

VisualEditor is available in Flow talk pages; it's the "[[ ]]" button in the bottom right corner of the editing window. (I prefer source view, myself, but Flow is too broken to have a preview mode from what I can tell, so the only way to get one is to use that feature to turn VE on and then off again.

VE itself is too broken to use it reliably. E.g., if you add a sig or something else that VE wants to escape for some reason, with <nowiki>...</nowiki>, it will apply the <nowiki>...</nowiki> to the entire line, which is liable to mess up something else (and so on; the complaints list about VE is a mile long).  — SMcCandlish ¢ ≽ʌⱷ҅ʌ≼  19:16, 24 July 2016 (UTC)

Trizek (WMF) (talkcontribs)

Can you give me some details concerning that <nowiki> problem, precisely? That way we can have the most accurate information to fix it.

SMcCandlish (talkcontribs)

I don't use it enough to debug that much. When I close with a four-tilde sig, switch to VE, and then back to source view, the whole line is nowiki'ed. ~~~~

If it has some "code" in it, e.g. a {{foo}} template link or a explicit HTML b tag, or '''apostrophe boldfacing''', the sig nowiki stuff goes backward from the sig until it hits the the code. ~~~~

Notably, it even no-wikied out the apostrophe boldfacing in that case, though it will not if you just do this:

Here's some apostrophe boldfacing followed by a sig. ~~~~

This would seem to indicate that as soon as any new markup is introduced that some list in VE is looking for, it will break. And that whatever parsing it is doing already has serious problems. The underlying design paradigm of "wrap everything you can get away with in nowiki if you encounter sig code anywhere" makes no sense at all to begin with.

PS: A serious flaw of Flow is you can't view source on what I'm writing, necessitating that I have to describe it and hope you know what I mean. This is why flow will never, ever be useful at a wiki, because we frequently have to discuss and illustrate code in a "view source on what I just wrote" manner.

Here I am signing with a sig again, going into VE to preview, then back into source mode and manually stripping out the nowiki this time.  — SMcCandlish ¢ ≽ʌⱷ҅ʌ≼  18:42, 27 July 2016 (UTC)

Quiddity (WMF) (talkcontribs)

Hi. Just two quick notes:

  1. It is possible to view source on what you wrote. We just need to click "Edit" in the dropdown menu (and possibly also use the [[ ]] button to flip into wikitext-mode). See screenshot. It could be better (in many ways), but it does work.
  2. Signatures aren't of necessity in Flow, as our posts are automatically attributed (and edits by other people are denoted). The few benefits that custom signatures have, will eventually be addressed via other means, per Flow#What happens to my custom signature?.

Hope that helps.

SMcCandlish (talkcontribs)

Whether sigs are "necessary" is irrelevant. They're a typical style here that many prefer, and VE's extreme and broken lengths to browbeat people into not using them are causing other problems. FAIL.  — SMcCandlish ¢ ≽ʌⱷ҅ʌ≼  22:13, 28 July 2016 (UTC)

Trizek (WMF) (talkcontribs)

"When I close with a four-tilde sig, switch to VE, and then back to source view, the whole line is nowiki'ed."

I have that problem when I use VE on a page too. It is not specific to Flow. I'm not sure if that problem would be fixed: signatures are only for classical talk pages, not for Flow or VE (which is not designed for discussions).

My question was more about other stuff with parasite <nowiki> markups. :)

SMcCandlish (talkcontribs)

I've also found that it will nowiki more than one visble line; it seems to nowiki backward from the sig until it reaches either a paragraph break (blank line) or something it recognizes as "code" in its very limited ability to parse. It's basically "style nazi" code, doing stupid unnecessary things to try to force people into never using sigs in situations in which some developer wants to force people to never use sigs. This is not part of the design spec of VE or Flow, and should be removed immediately as rogue developer bullshit.

It's especially boneheaded, because there are numerous legit uses of sig code that don't have anything to do with signing posts. For example, the ~~~~~ (5 tildes) version is very convenient for generating exact inline timestamps, and sigs of all three (three-tilde to five-tilde) types are useful in various template examples, which (as I pointed out in detail above) are something we often use in talk pages.

The fatal flaw here is in the false supposition that WP and its sister projects need a "discussion forum" that it utterly divorced from wiki coding. This has never been true and will never be true, since much of the time what the talk pages exist for is working on wikicode. Any thing that gets in the way to doing that, even slightly, is never going to be accepted by the community. And VE, outside the context of Flow, never has any business interfering with editors' use of sig code to begin with. So, it doesn't matter where this misfeature is coming from – VE itself or Flow, or as Sänger suggests below, in parsoid – it has to go.

Trizek (WMF) (talkcontribs)

Good point concerning the 3 or 5 tildes signatures, that can be useful. It has been reported, and I've added your comments to that task.

Concerning talk pages, I don't whish to have an endless discussion with you. Flow is appreciated by some communities or, on other places, individuals, especially when they need to work with beginners. You should ask these people about why they appreciate Flow. :)

Sänger (talkcontribs)

It seems to be a Problem with parsoid, it was a Problem with far more wikisyntax before on Flow, now just the use of customised sigs ain't working with preview. Grüße vom Sänger ♫(Reden) 08:24, 28 July 2016 (UTC)

Sänger (talkcontribs)

~~~~ This was just short in preview, no tags anywhere besides my 4 tildes.

Sänger (talkcontribs)

That was Windumb with IE, now mint with FF ~~~~

Let's see all those things the preview will do.

Wrong click first, was save instead of preview ;)

Sänger (talkcontribs)

OK, some things work, like bold, and probably italics.

Signature doesn't work after preview, i.e. with the VE in-between.

Let's try some other stuff: durchgestrichen, 1+1=3 and bold the other way.

Works as well.
Sänger (talkcontribs)

I mean VE on normal talk pages, instead of Flow. The <nowiki>...</nowiki> stuff happens here as well, it's part of the underlying Parsoid-engine methinks.

But Flow breaks with the rest of the wikiverse completely, it changes talk pages into dumb forum stuff.

SMcCandlish (talkcontribs)

Ah, I see what you mean. I avoid VE so much, I'm probably not aware of where/if it can be used non-problematically, after however many bug-fixing rounds it has been through by now. I understand the desire for VE to exist – both user demand for "less geeky" tools and WMF demand to supply that demand – but for technical users, VE is mostly just a hindrance. A live-preview system as used by a lot of higher-end forum software would probably be a better approach. I'm on a lot of tech boards, and fairly often encounter this feature; e.g. you can be adding complicated code, and see that it shows up as code in the preview the instant you wrap <code>...</code> around it (or the BBcode or Markdown equivalent, if it's not using a subset of HTML for input). I haven't taken notes on which ones are doing what, so I couldn't offer a personal favorite at this point. I also wonder what plugins have been developed for MediaWiki by now; I know there are people building stuff that WP itself doesn't use yet (if ever).

Sänger (talkcontribs)

I probably won't use VE as well, the normal editor is more convenient for me. Just for tables it seems, the VE is more comfortable, more intuitive, as the old fashioned stuff with lots of | and - and brackets.

But for n00bs it could be fine, as the VE seems to behave as a real editor, and doesn't break stuff any more.

Reply to "How long is this Flow testing going to continue?"
Peteforsyth (talkcontribs)

Hi, it has been my understanding that one of the many purposes of Flow is to address breaking links to comments in discussions (as discussions get archived, etc.) On that basis, I left a link to this talk page, in an answer on Quora, in 2013: https://www.quora.com/What-do-you-find-confusing-about-Wikipedias-discussion-systems/answer/Pete-Forsyth

However, the link there no longer works: https://www.mediawiki.org/wiki/Talk:Flow#Response_to_Quora_question_24055

What happened to my comment here? Why is the link now broken?

Jay8g (talkcontribs)

For real permalinks, use the "Permalink" option in the topic (or post) menu.

Peteforsyth (talkcontribs)

OK...thanks for the answer, and good to know. IMO this is another significant shortcoming of Flow.

Peteforsyth (talkcontribs)

Update, I found my post -- but it was apparently moved (perhaps copy-pasted and then deleted? When? By whom? Quiddity perhaps?) This is a problem, because in a pre-Flow world I would have simply used a permalink to an old revision. So in this way, it seems that Flow is providing less functionality than the preceding system. Flow/Research/Experienced_user_responses#Pete_Forsyth

Quiddity (WMF) (talkcontribs)

Hi Pete. You had made your post at this page location, but that was when the page was using LiquidThreads. In December 2013, that LQT board was page-moved to /Archive_2 so that the page could start to use Flow. Then in June 2015, the LQT page (/Archive_2) was converted to Flow along with the other LQT pages on this wiki. So, your topic is now at Topic:R2nb2zhwpjlovnge, and if it were not for the page-move, then the LQT permalink (if that's what you had in your Quora post) would've been successfully redirected to the Flow permalink. HTH.

Mattflaschen-WMF (talkcontribs)

I think it may have worked if Pete had linked to the LQT Thread namespace page as well (we have handling for redirecting those to Flow Topic). I'm not positive, though, due to the complexities in this case.

Peteforsyth (talkcontribs)

Aha, that makes a lot of sense -- thank you Quiddity (WMF)!

Ark25 (talkcontribs)

Ugly vs. good looking permalinks: This link is ugly: Topic:Rxozcohzzgcnydpf - and this is good looking: Thread:Extension talk:VisualEditor/VisualEditor freezes at loading bar. - Since by default we get "ugly" permalinks, my question is: can we also get the "good looking" permalinks for topics somehow? Thanks

Quiddity (WMF) (talkcontribs)

@Ark25, not currently, but there is regular discussion amongst the team about resolving this. The task to watch for updates, is Phab:T59154.

Reply to "Permalinks?"
Pine (talkcontribs)

I believe that Flow is being used on an opt-in basis on Wikidata and Catalan Wikipedia, and is used on user talk pages by default on MediaWiki.

Is that correct?

Are there any wikis other than MediaWiki where Flow is enabled on all talk pages by default?

Are there any wikis where Flow is widely used on an opt-in basis, even if it's not the default?

Quiddity (WMF) (talkcontribs)
  1. Yes. For more details, Flow rollout is described and documented at Flow/Rollout.
  2. Not currently, but kab.wikipedia has requested it.
  3. Yes, Zh.wikipedia is a particularly active wiki, per the stats at https://edit-analysis.wmflabs.org/beta-enables/#projects=testwiki,zhwiki,wikidatawiki,cawiki,urwiki,bswiki,mediawikiwiki/metrics=Flow%20Beta%20Enables
  4. There's a survey coming soon, which will give more info/insight into all this.
Roan Kattouw (WMF) (talkcontribs)

Re #2, gom.wikipedia already has Flow on all talk pages.

Pine (talkcontribs)

Thanks!

Reply to "How widely is Flow being used?"

Users should confirm they want to leave the page without saving

3
Guycn2 (talkcontribs)

Hello. I have just written a message using Flow.

Accidentally, I opened a link on the same tab, and consequently my entire message was lost!!

Even after I clicked the "back" button on my browser, I couldn't see the message I had written.

This happened even though the option Warn me when I leave an edit page with unsaved changes on my preferences IS checked!

To avoid such cases, users should be prompted if they write a message and try to leave the page without saving. I hope this talk page is the right place for this request.

Trizek (WMF) (talkcontribs)

Hello

Thank you for your feedback, this is the right place for it.

Some people already requested that feature. I'm going to ask developers if they can fix it soon.

Guycn2 (talkcontribs)

Thank you :)

Reply to "Users should confirm they want to leave the page without saving"

Beta features: enable, disable, enable doesn't seem to work

2
Dereckson (talkcontribs)

@Lionel Scheepmans reports on fr.wikipedia to have enabled, then disabled Flow. The wikitext archived talk page was successfully restored. But then, they toggled on the beta preference again. Nothing happens, while the user expected to get back Flow.

Lionel Scheepmans (talkcontribs)

See also this page : https://fr.wikipedia.org/wiki/Discussion_utilisateur:Lionel_Scheepmans/Flow_Archive_1

And this one : https://fr.wikipedia.org/w/index.php?title=Sujet:T63k4mt1p090if46&topic_showPostId=t63pgjfh8ikwd7nd&fromnotif=1#flow-post-t63pgjfh8ikwd7nd

I've also remove {{Page de discussion wikitexte convertie en Flow|archive=Discussion utilisateur:Lionel Scheepmans/Flow Archive 1|{{Page de discussion wikitexte convertie en Flow|archive=Discussion utilisateur:Lionel Scheepmans/Flow Archive 1|date=2016-06-18}}date=2016-06-18}} from my talkpage after disabled Flow.

Reply to "Beta features: enable, disable, enable doesn't seem to work"

How to move a topic to another discussion?

2
Dvorapa (talkcontribs)

Any option?

Quiddity (WMF) (talkcontribs)

Not at the moment. phab:T88140 tracks that feature.

Reply to "How to move a topic to another discussion?"
Stefahn (talkcontribs)

I wanted to search for a specific term on Skin talk:Chameleon and didn't find a search option. I ended up here reading that implementing the search option is postponed. Is there a plan when it will be available?

For me it's essential to have a search option.

PS: I tried but it doesn't seem to find content that was posted in Flow...

Tar Lócesilion (talkcontribs)

You're not alone. Later this year, there will be a satisfaction survey. Keep it in mind and take part.

Trizek (WMF) (talkcontribs)

Special:Search does not includes Flow topics. That's a big issue and, unfortunately, that's something which requires a lot of resources to be integrated and maintained. As Tar wrote, we are going to have a survey (I hope soon), in which search is included as a possible priority.

Reply to "Search on Flow"
天帝驕子 (talkcontribs)

Anyone can help me to move zh:user talk:上天驕子 to zh:user talk: 上天驕子/Flow

Trizek (WMF) (talkcontribs)

Done!

Didn't you manage to do that by yourself, by deselecting Flow on your Beta preferences?

天帝驕子 (talkcontribs)

Thanks!I've tried it myself in the Taiwan user talk page, and I can't do this.

Trizek (WMF) (talkcontribs)

That's wired. We will investigate, I may recontact you about that.

Reply to "Help"
81.22.162.228 (talkcontribs)

I get this error when I'm trying to use VisualEditor in Flow conversations:

[9149bd06] Exception Caught: Conversion from 'html' to 'wikitext' was requested, but core's Parser only supports 'wikitext' to 'html' conversion.

VisualEditor is working on other sites normally.

I have these lines in my LocalSettings.php:

$wgVisualEditorParsoidURL = 'http://localhost:8000';

$wgVisualEditorParsoidForwardCookies = true;

$wgSessionsInObjectCache = true;

$wgFlowContentFormat = 'html';

$wgFlowEditorList = array( 'visualeditor', 'none' );

Parsoid seems to depub html > wikitext without problems.

Can you tell how to fix this?

Mattflaschen-WMF (talkcontribs)

What version/git commit of Flow and core do you have?

In recent versions of Flow, you need to use $wgVirtualRestConfig (recommended, if it's mentioned in your Flow.php) or $wgFlowParsoid* variables (either the only way, or a deprecated but still-working way).

Mattflaschen-WMF (talkcontribs)

You can see https://git.wikimedia.org/blob/operations%2Fmediawiki-config/HEAD/wmf-config%2FCommonSettings.php (either for $wgVirtualRestConfig or history of that for the old way).

81.22.162.228 (talkcontribs)

I'm using the latest version. I haven't defined $wgVirtualRestConfig in my LocalSettings.php and I cant find this from Flow.php. Flow parsoid configuration looks like this:

$wgFlowParsoidURL = null; // also see $wgVisualEditorParsoidURL

$wgFlowParsoidPrefix = null; // also see $wgVisualEditorParsoidPrefix

$wgFlowParsoidTimeout = null; // also see $wgVisualEditorParsoidTimeout

If i set $wgFlowParsoidURL = http://localhost:8000 i get an error: [c949daba] Exception Caught: Failed contacting Parsoid and neither editor is working in Flow conversations.

81.22.162.228 (talkcontribs)

This is what logfile says:

FlowHooks::initFlowExtension: Warning: $wgFlowContentFormat was set to 'html', but you do not have Parsoid enabled.  Changing $wgFlowContentFormat to 'wikitext'


81.22.162.228 (talkcontribs)

...and i've checked: Parsoid service is up and running. I even tested it on http://localhost:8000 and its working normally.

Mattflaschen-WMF (talkcontribs)

What do you have for all the $wgFlowParsoid... variables in your LocalSettings.php? You only mentioned one. They should all (well, one or two are optional) be set to the same as their equivalent VE one is/would be.

If you use IRC, joining us in #wikimedia-collaboration on Freenode may be faster.

81.22.162.228 (talkcontribs)

require_once "$IP/extensions/VisualEditor/VisualEditor.php";

$wgVisualEditorParsoidURL = 'http://localhost:8000';

$wgVisualEditorParsoidForwardCookies = true;

$wgSessionsInObjectCache = true;

require_once "$IP/extensions/Flow/Flow.php";

$wgFlowContentFormat = 'html';

$wgFlowEditorList = array( 'visualeditor', 'none' );

#$wgFlowParsoidURL = 'http://localhost:8000';

$wgVirtualRestConfig['modules']['parsoid'] = array(

  'url' => 'http://localhost:8000',

  'domain' => 'localhost',

  'prefix' => 'localhost',

);

I also have defined namespaces but I didn't write those here. I haven't made changes to Flow.php or VisualEditor.php.

Mattflaschen-WMF (talkcontribs)

If $wgVirtualRestConfig is not mentioned in a comment in Flow.php, there is no need to set it for Flow's purposes, and it won't have any effect on Flow (other than maybe confusing people).

You should uncomment $wgFlowParsoidURL and also set $wgFlowParsoidPrefix, $wgFlowParsoidTimeout, and $wgFlowParsoidForwardCookies.

I think:

$wgFlowParsoidURL = 'http://localhost:8000';
$wgFlowParsoidPrefix = $wgDBname;
$wgFlowParsoidTimeout = 100;
$wgFlowParsoidForwardCookies = true;

should work.

You can raise the timeout if wanted/needed.

81.22.162.228 (talkcontribs)

Hi

$wgVirtualRestConfig is not mentioned in Flow.php. Should I use these in LocalSettings.php or Flow.php?

$wgFlowParsoidURL = 'http://localhost:8000'; // also see $wgVisualEditorParsoidURL

$wgFlowParsoidPrefix = $wgDBname; // also see $wgVisualEditorParsoidPrefix

$wgFlowParsoidTimeout = 100; // also see $wgVisualEditorParsoidTimeout

$wgFlowParsoidForwardCookies = true;

If set these settings to LocalSettings.php and comment in Flow.php I get: "Due to a technical error, this post could not be retrieved." Failed connecting parsoid. Neither editor is working (WysiWYG, VE). If I do vice versa I get the same error. If I set these above setting to both files I get the same error.

Why does it fail if i use VisualEditor for e.g. new pages and can save those successfully. Ii can still access and see parsoid running at the server. I've restarted the service.

If i comment these setting in both of the files, WysiWYG wikitext editor is working but VE gives: Exception Caught: Conversion from 'html' to 'wikitext' was requested, but core's Parser only supports 'wikitext' to 'html' conversion.

My LocalSettings.php:

require_once "$IP/extensions/VisualEditor/VisualEditor.php";

$wgDefaultUserOptions['visualeditor-enable'] = 1;

$wgHiddenPrefs[] = 'visualeditor-enable';

$wgDefaultUserOptions['visualeditor-enable-experimental'] = 1;

$wgVisualEditorParsoidURL = 'http://localhost:8000';

$wgVisualEditorParsoidForwardCookies = true;

$wgSessionsInObjectCache = true;

require_once "$IP/extensions/Flow/Flow.php";

$wgNamespaceContentModels[NS_PROJECT_TALK] = CONTENT_MODEL_FLOW_BOARD;

$wgNamespaceContentModels[NS_USER_TALK] = CONTENT_MODEL_FLOW_BOARD;

$wgNamespaceContentModels[NS_CATEGORY_TALK] = CONTENT_MODEL_FLOW_BOARD;

$wgNamespaceContentModels[NS_USER] = CONTENT_MODEL_FLOW_BOARD;

$wgNamespaceContentModels[NS_TALK] = CONTENT_MODEL_FLOW_BOARD;

$wgFlowContentFormat = 'html';

$wgFlowEditorList = array( 'visualeditor', 'none' );

require_once "$IP/extensions/Echo/Echo.php";

If I add this to LocalSettings.php:

$wgVirtualRestConfig['modules']['parsoid'] = array(

 

'url' => 'http://localhost:8000',

 

'domain' => $wdDBname,

 

'prefix' => '100'

);

I get: [98970307] Exception Caught: Conversion from 'html' to 'wikitext' was requested, but core's Parser only supports 'wikitext' to 'html' conversion


81.22.162.228 (talkcontribs)

I corrected this one in LocalSettings.php:

$wgVirtualRestConfig['modules']['parsoid'] = array(

 

'url' => 'http://localhost:8000',

 

'domain' => 'localhost',

 

'prefix' => 'localhost'

);

I also tested echo 'Foo' | node parse and it is working.

81.22.162.228 (talkcontribs)

Log file still says: Warning: $wgFlowContentFormat was set to 'html', but you do not have Parsoid enabled.

Mattflaschen-WMF (talkcontribs)

$wgVirtualRestConfig is not going to work with your version of Flow. Please do not change or post that setting.

Never change settings in Flow.php (unless you're a developer working on Flow, but that's a different matter). Please change Flow.php back to the version you downloaded.

Add the lines I mentioned to LocalSettings.php ($wgFlowParsoidURL, $wgFlowParsoidPrefix, $wgFlowParsoidTimeout, $wgFlowParsoidForwardCookies).

After changing LocalSettings.php, retest. If it doesn't work, post your full LocalSettings.php.

> Why does it fail if i use VisualEditor for e.g. new pages and can save those successfully. Ii can still access and see parsoid running at the server. I've restarted the service.

Flow uses a different set of settings.

81.22.162.228 (talkcontribs)

Hi, Flow.php restored from the original file. Changed settings as you described - not working: Failed to contact Parsoid. Here is the LocalSettings.php:

#This file was automatically generated by the MediaWiki 1.25.1

# installer. If you make manual changes, please keep track in case you

# need to recreate them later.

#

# See includes/DefaultSettings.php for all configurable settings

# and their default values, but don't forget to make changes in _this_

# file, not there.

#

# Further documentation for configuration settings may be found at:

# https://www.mediawiki.org/wiki/Manual:Configuration_settings


# Protect against web entry

if ( !defined( 'MEDIAWIKI' ) ) {

exit;

}


# Uncomment this to disable output compression

# $wgDisableOutputCompression = true;

$wgSitename = "Raksu";


####### UPLOAD FILE TYPES #######

$wgFileExtensions = array( 'png', 'gif', 'jpg', 'jpeg', 'doc',

    'xls', 'mpp', 'pdf', 'ppt', 'tiff', 'bmp', 'docx', 'xlsx',

    'pptx', 'ps', 'odt', 'ods', 'odp', 'odg', 'pdf');


# Custom Mediawiki settings

// Search settings

$wgAdvancedSearchHighlighting = true;

$wgEnableMWSuggest = true;

$wgUseTwoButtonsSearchForm = true;

#Set default searching

$wgNamespacesToBeSearchedDefault = array(

NS_MAIN =>           true,

NS_TALK =>           false,

NS_USER =>           false,

NS_USER_TALK =>      false,

NS_PROJECT =>        false,

NS_PROJECT_TALK =>   false,

NS_FILE =>           false,

NS_FILE_TALK =>      false,

NS_MEDIAWIKI =>      false,

NS_MEDIAWIKI_TALK => false,

NS_TEMPLATE =>       false,

NS_TEMPLATE_TALK =>  false,

NS_HELP =>           false,

NS_HELP_TALK =>      false,

NS_CATEGORY =>       true,

NS_CATEGORY_TALK =>  false,

);

## The URL base path to the directory containing the wiki;

## defaults for all runtime URL paths are based off of this.

## For more information on customizing the URLs

## (like /w/index.php/Page_title to /wiki/Page_title) please see:

## https://www.mediawiki.org/wiki/Manual:Short_URL

$wgScriptPath = "";

$wgScriptExtension = ".php";


## The protocol and server name to use in fully-qualified URLs

$wgServer = "";


## The relative URL path to the skins directory

$wgStylePath = "$wgScriptPath/skins";

$wgResourceBasePath = $wgScriptPath;

## The relative URL path to the logo.  Make sure you change this from the default,

## or else you'll overwrite your logo when you upgrade!

$wgLogo = "$wgResourceBasePath/resources/assets/raksu_uusilogo.png";


## UPO means: this is also a user preference option

$wgEnableEmail = true;

$wgEnableUserEmail = true; # UPO


$wgEmergencyContact = "";

$wgPasswordSender = "";


$wgEnotifUserTalk = false; # UPO

$wgEnotifWatchlist = false; # UPO

$wgEmailAuthentication = false;


## Database settings

$wgDBtype = "mysql";

$wgDBserver = "localhost";

$wgDBname = "wikidb";

$wgDBuser = "";

$wgDBpassword = "";


# MySQL specific settings

$wgDBprefix = "";


# MySQL table options to use during installation or update

$wgDBTableOptions = "ENGINE=InnoDB, DEFAULT CHARSET=binary";


# Experimental charset support for MySQL 5.0.

$wgDBmysql5 = false;


## Shared memory settings

$wgMainCacheType = CACHE_NONE;

$wgMemCachedServers = array();


## To enable image uploads, make sure the 'images' directory

## is writable, then set this to true:

$wgEnableUploads = true;

$wgUseImageMagick = true;

$wgImageMagickConvertCommand = "/usr/bin/convert";


# InstantCommons allows wiki to use images from http://commons.wikimedia.org

$wgUseInstantCommons = false;

## If you use ImageMagick (or any other shell command) on a

## Linux server, this will need to be set to the name of an

## available UTF-8 locale

$wgShellLocale = "en_US.utf8";


## If you want to use image uploads under safe mode,

## create the directories images/archive, images/thumb and

## images/temp, and make them all writable. Then uncomment

## this, if it's not already uncommented:

#$wgHashedUploadDirectory = false;


## Set $wgCacheDirectory to a writable directory on the web server

## to make your wiki go slightly faster. The directory should not

## be publically accessible from the web.

#$wgCacheDirectory = "$IP/cache";

# Site language code, should be one of the list in ./languages/Names.php

$wgLanguageCode = "fi";


$wgSecretKey = "secret_key_hided";

# Site upgrade key. Must be set to a string (default provided) to turn on the

# web installer while LocalSettings.php is in place

$wgUpgradeKey = "";

## For attaching licensing metadata to pages, and displaying an

## appropriate copyright notice / icon. GNU Free Documentation

## License and Creative Commons licenses are supported so far.

$wgRightsPage = ""; # Set to the title of a wiki page that describes your license/copyright

$wgRightsUrl = "";

$wgRightsText = "";

$wgRightsIcon = "";

# Path to the GNU diff3 utility. Used for conflict resolution.

$wgDiff3 = "/usr/bin/diff3";

# The following permissions were set based on your choice in the installer

$wgGroupPermissions['*']['edit'] = false;

## Default skin: you can change the default skin. Use the internal symbolic

## names, ie 'vector', 'monobook':

$wgDefaultSkin = "vector";

# Enabled skins.

# The following skins were automatically enabled:

wfLoadSkin( 'CologneBlue' );

wfLoadSkin( 'Modern' );

wfLoadSkin( 'MonoBook' );

wfLoadSkin( 'Vector' );


# Enabled Extensions. Most extensions are enabled by including the base extension file here

# but check specific extension documentation for more details

# The following extensions were automatically enabled:

wfLoadExtension( 'Cite' );

wfLoadExtension( 'CiteThisPage' );

wfLoadExtension( 'Gadgets' );

wfLoadExtension( 'ImageMap' );

wfLoadExtension( 'InputBox' );

wfLoadExtension( 'Nuke' );

wfLoadExtension( 'PdfHandler' );

wfLoadExtension( 'Renameuser' );

wfLoadExtension( 'SyntaxHighlight_GeSHi' );

wfLoadExtension( 'TitleBlacklist' );

wfLoadExtension( 'WikiEditor' );


# End of automatically generated settings.

# Add more configuration options below.

# WikiEditor settings

# Enables use of WikiEditor by default but still allow users to disable it in preferences

$wgDefaultUserOptions['usebetatoolbar'] = 1;

$wgDefaultUserOptions['usebetatoolbar-cgd'] = 1;


# Displays the Preview and Changes tabs

$wgDefaultUserOptions['wikieditor-preview'] = 1;


# Displays the Publish and Cancel buttons on the top right side

$wgDefaultUserOptions['wikieditor-publish'] = 1;

#Set Default Timezone

$wgLocaltimezone = "Europe/Helsinki";

$wgLocalTZoffset = date("Z") / 60;


# EXTENSION: UNIVERSAL LANGUAGE SELECTOR

require_once "$IP/extensions/UniversalLanguageSelector/UniversalLanguageSelector.php";

# EXTENSION: Visual Editor

require_once "$IP/extensions/VisualEditor/VisualEditor.php";


// Enable by default for everybody

$wgDefaultUserOptions['visualeditor-enable'] = 1;

// Don't allow users to disable it

$wgHiddenPrefs[] = 'visualeditor-enable';

// OPTIONAL: Enable VisualEditor's experimental code features

$wgDefaultUserOptions['visualeditor-enable-experimental'] = 1;

// URL to the Parsoid instance

// MUST NOT end in a slash due to Parsoid bug

// Use port 8142 if you use the Debian package

$wgVisualEditorParsoidURL = 'http://localhost:8000';

$wgVisualEditorParsoidForwardCookies = true;

$wgSessionsInObjectCache = true;

$wgVisualEditorNamespaces ['*'];

#$wgVisualEditorNamespaces = array( NS_MAIN, NS_TALK, NS_USER, NS_USER_TALK, NS_CATEGORY);

# EXTENSION: Confirm Account

require_once "$IP/extensions/ConfirmAccount/ConfirmAccount.php";

#$wgConfirmAccountRequestFormItems['Biography']['minWords'] = 0;

$wgConfirmAccountRequestFormItems['Biography']['enabled'] = false;

#$wgConfirmAccountRequestFormItems['Areasofinterest']['enabled'] = false;

 $wgMakeUserPageFromBio = false;

 $wgAutoWelcomeNewUsers = false;

 $wgConfirmAccountRequestFormItems = array(

 'UserName'        => array( 'enabled' => true ),

 'RealName'        => array( 'enabled' => true ),

 'Biography'       => array( 'enabled' => false, 'minWords' => 50 ),

 'AreasOfInterest' => array( 'enabled' => false ),

 'CV'              => array( 'enabled' => false ),

 'Notes'           => array( 'enabled' => false ),

 'Links'           => array( 'enabled' => false ),

 'TermsOfService'  => array( 'enabled' => false ),

 );

# USER RIGHTS

# Disable reading by anonymous users

$wgGroupPermissions['*']['read'] = false;

# But allow them to access the login page or else there will be no way to log in!

# [You also might want to add access to "Main Page", "Wikipedia:Help", etc.)

# But allow them to read e.g., these pages:

$wgWhitelistRead = array ("Main Page", "Special:Userlogin", "Help:Contents", "-", "Special:Requestaccount", "Toiminnot:Pyydä_käyttäjätunnusta");

#$wgGroupPermissions['*']['createaccount'] = false;

# EXTENSION: Input box

wfLoadExtension( 'InputBox' );

# EXTENSION: Fancy Box Thumbs

require_once("$IP/extensions/FancyBoxThumbs/FancyBoxThumbs.php");

# EXTENSION: MediaWiki Chat

require_once "$IP/extensions/MediaWikiChat/MediaWikiChat.php";

# EXTENSION: Access Control

require_once("extensions/AccessControl/AccessControl.php");

# EXTENSION: User merge and delete

require_once "$IP/extensions/UserMerge/UserMerge/UserMerge.php";

// By default nobody can use this function, enable for bureaucrat?

$wgGroupPermissions['bureaucrat']['usermerge'] = true;

// optional: default is array( 'sysop' )

$wgUserMergeProtectedGroups = array( 'groupname' );

# EXTENSION: Enable Subpages

# Enable subpages in the main namespace

$wgNamespacesWithSubpages[NS_MAIN] = true;

# Enable subpages in the template namespace

$wgNamespacesWithSubpages[NS_TEMPLATE] = true;

# EXTENSION: Hide Prefix 

require_once "$IP/extensions/HidePrefix/HidePrefix/HidePrefix.php";

# EXTENSION: Flow

#The Flow extension provides a new discussion and collaboration system for talk pages

require_once "$IP/extensions/Flow/Flow.php";

#To enable Flow for a namespace, use $wgNamespaceContentModels. For example:

#$wgNamespaceContentModels[NS_PROJECT_TALK] = CONTENT_MODEL_FLOW_BOARD;

$wgNamespaceContentModels[NS_USER_TALK] = CONTENT_MODEL_FLOW_BOARD;

$wgNamespaceContentModels[NS_CATEGORY_TALK] = CONTENT_MODEL_FLOW_BOARD;

#$wgNamespaceContentModels[NS_USER] = CONTENT_MODEL_FLOW_BOARD;

$wgNamespaceContentModels[NS_TALK] = CONTENT_MODEL_FLOW_BOARD;

#$wgNamespaceContentModels[NS_TIEDOTTEET_TALK] = CONTENT_MODEL_FLOW_BOARD;

$wgFlowContentFormat = 'html';

$wgFlowEditorList = array( 'visualeditor', 'none' );

// Parsoid configuration

#Flow uses the Virtual REST Service to contact a Parsoid or RESTBase service. 

#If your wiki loads the VisualEditor extension, then you've probably already set this up.

$wgFlowParsoidURL = 'http://localhost:8000'; // also see $wgVisualEditorParsoidURL

$wgFlowParsoidPrefix = $wgDBname; // also see $wgVisualEditorParsoidPrefix

$wgFlowParsoidTimeout = 100; // also see $wgVisualEditorParsoidTimeout

$wgFlowParsoidForwardCookies = true;

//Flow talk notifications

require_once "$IP/extensions/Echo/Echo.php";

81.22.162.228 (talkcontribs)

Im still fighting with this issue. Please Help.

Wess (talkcontribs)

Have you found a solution for this?

Reply to "Using VisualEditor in Flow"