Extension talk:VEForAll

About this board

Summary by Cavila

Fixed in v0.5.

Cavila (talkcontribs)

I've attemted to use this extension in MW 1.35 but the textareas using VE are all greyed out.

The browser's console (Firefox) shows no errors, just a long list of warnings like No name: {"type":"menu","include":{"group":"format"},"promote":["paragraph"],"demote":["preformatted","blockquote"]}

Sometimes, VE appears again but only after a hard browser refresh/reload.

MW 1.35, VE 0.1.2, VEForAll 0.3, PF 5.2.1

Bluespice AtMentions, Checklists and DateTimeTools

9
Squeak24 (talkcontribs)

Does VEForAll allow the icons for the BlueSpice AtMentions, CheckLists and DateTimeTools to be added to a form?

I am sure I also saw at the SMWCon Fall 2023 that there was an option for adding comments like you do with Word, but I can't remember how that was set up, can that be added for a VEForAll as well?

I am using PageForms with VEForAll.

Any help is appreciated.

Yaron Koren (talkcontribs)

I saw that BlueSpice presentation also (remotely). You don't actually mean "icons", I think - you mean "special syntax" or something. i.e., with the Checklists extension, if you add "[]" at the beginning of a line, it's displayed as a clickable checkbox. I think for all of those extensions, they have VisualEditor integration. I assume that means that it would work as well within a VEForAll-enabled textarea, but I have no idea.

I also saw that other presentation I think you're talking about, of the not-yet-released extension from ArchiXL currently called either "Semantic Comments" or "SmartComments". That extension, though, takes effect when viewing a page, not editing it, so VE/VEForAll should not be relevant. (I also think the InlineComments extension is the better tool for this - and it's already available - but that's a whole other story.)

Squeak24 (talkcontribs)

Thanks for the speedy reply Yaron.

This is what I see on the standard page without using a page form:

BlueSpice icons in VE

But, with Page Forms using VEForAll, these icons don't show:

Shows the VE in page forms without the BlueSpice icons.

I know I need to resolve the issue with the text over the icons, I did fix that once, but keep forgetting to do it since upgrading MW.

Any help is appreciated.

Yaron Koren (talkcontribs)

Oh, you did mean icons. Well, the icons do appear, it's just that (as you note) the text appears over them. If you resolved that once before, can you do it again? What do you need my help for?

Squeak24 (talkcontribs)

I will make the changed tomorrow, it's been a long day.

I can see the TaskList, but not the icon for the AtMentions.

I have just tested it with the @ and that brings up what I would want. Just wondering if it can be in the ribbon as well when using Page Forms, if not, no worries now I know typing @ works.

Yaron Koren (talkcontribs)

Oh, now I see that AtMentions icon. Maybe it can be added via the VEForAllToolbarConfigNormal hook - I don't know.

Squeak24 (talkcontribs)

OK, I will take a look, thank you!

Squeak24 (talkcontribs)

Good news, you can add them with that hook, this is what I have used for others:

$wgHooks['VEForAllToolbarConfigNormal'][] = function( &$defaultConfigNormal ) {

        $defaultConfigNormal[4]['include'][] = 'comment';

        $defaultConfigNormal[4]['include'][] = 'mention';

};

The comments are part of ApprovedRevs, not the BlueSpice extensions from what I can see.

Yaron Koren (talkcontribs)

That's great! Although I don't think it could be Approved Revs - I don't think Approved Revs modifies VisualEditor in any way.

Reply to "Bluespice AtMentions, Checklists and DateTimeTools"
Krabina (talkcontribs)

Is there a way to enlarge the size of the VE field in the standard input form of PageForms?

Krabina (talkcontribs)

Found a solution via MediaWikiCommon.css:

.ve-ce-documentNode {
	min-height: 800px !important;
}
Reply to "Size of VE field"

How to add the code block button

1
Krabina (talkcontribs)

In regular VE, in the insert menu ("+"), there is the code block button. How can I enable this in VEForAll?

Reply to "How to add the code block button"

VisualEditor Toolbar buttons in page forms textarea?

4
Stefan Kaifer (talkcontribs)

How can I add all toolbar buttons, as shown in the "normal" VisualEditor?

I've tried with the hook


$wgHooks['VEForAllToolbarConfigNormal'][] = function( &$defaultConfigNormal ) {

 $defaultConfigNormal[4]['include'][] = 'math';

};


, but it doesn't work.

Where can I find the corrent toolbarbutton names?

Stefahn (talkcontribs)

I do have the same issue. When I edit with the usual VE there is a menu called "Cite". When I edit with PageForms (and VEForAll) there is no "Cite" menu.

There are also much fewer entries in the "Insert" menu when using VEForAll.

Is this a bug?

Using MW 1.35.5, PageForms 5.3.4 and VEForAll 0.4.

Krabina (talkcontribs)

I have the same issue. There should be a configuration option which "Insert" elements of the regular VE are displayed (or which are hidden)

Krabina (talkcontribs)

The configuration options mentioned do not work for me (MW 1.35).

Reply to "VisualEditor Toolbar buttons in page forms textarea?"
Summary by Rand(1,2022)

Resolved: T300542.

Rand(1,2022) (talkcontribs)

This extension seems to be working alright for me except for one bug.

If it is used in multiple instances, it won’t let me submit the form. The save button remains unresponsive. It is only when I additionally include a textarea with VE outside of the multiple instances elsewhere in the form that the save button lets me submit. I don't see any error message in the browser console.

MW 1.39 / VEforAll 0.5

Sen-Sai (talkcontribs)

What form extension are you using?

This post was hidden by Cavila (history)
Rand(1,2022) (talkcontribs)

Page Forms, in this case.

Yaron Koren (talkcontribs)

I assume this is more or less the same issue as T300542. Let me make sure if I understand it: if you make some unrelated change to some non-VE input in the form, does the "Save" button remain unusable?

Rand(1,2022) (talkcontribs)

That (T300542.) is probably the exact same issue, including the behaviour that adding a single instance activates the Save button.

I do have other inputs such as one for the title of the page, but changing their content does not suddenly make the Save button usable again.

Rand(1,2022) (talkcontribs)

I haven't tested the patch myself, but someone was able to confirm it works. I'll close this as resolved.

404 API error on 1.39

6
141.70.45.21 (talkcontribs)

API call from page form textarea to convert wikitext in html results in 404 error.

(action: veforall-parsoid-utils

format: json

from: wikitext

to: html

content: <div> ... </div>)

Response:

{

    "error": {

        "code": "veforall-api-error-parsoid-error",

        "info": "Request to parsoid for wikitext to html conversion of content connected to title example failed: 404",

        "*": "See /api.php for API usage. Subscribe to the mediawiki-api-announce mailing list at &lt; wikimedia/postorius/lists/mediawiki-api-announce.lists.wikimedia.org/&gt; for notice of API deprecations and breaking changes."

    }

}

This worked in 1.37 just fine on PHP 8.0.

The error log shows multiple Http::createMultiClient Deprecation notices from VEForAll


PHP message: PHP Deprecated:  Use of Http::createMultiClient was deprecated in MediaWiki 1.34. [Called from VEForAll\ApiParsoidUtilsOld::parsoid in /extensions/VEForAll/includes/ApiParsoidUtilsOld.php at line 125] in /includes/debug/MWDebug.php on line 381" while reading response header from upstream, request: "POST /api.php HTTP/2.0", upstream: "fastcgi://unix:/var/run/php/php8.0-fpm.sock:"


Version: 0.4 (REL_39) so it should be 0.4.1

The error is not helpful either.

Yaron Koren (talkcontribs)

Yes, you should upgrade to VEForAll 0.4.1 - I'm guessing that will fix the problem.

141.70.45.21 (talkcontribs)

They should upgrade the version you get from the mediawiki downloader. If I download it from there for 1.39 I get 0.4. I have to take the version from github

141.70.45.21 (talkcontribs)

I downloaded the 0.4.1.tar.gz, extracted it into VEForALL on 1.39.2 and got the following error:

Error at /extensions/VEForAll/includes/ApiParsoidUtils.php(204)

from /extensions/VEForAll/includes/ApiParsoidUtils.php(204)

#0 /extensions/VEForAll/includes/ApiParsoidUtils.php(91): VEForAll\\ApiParsoidUtils->getVRSObject()

#1 /extensions/VEForAll/includes/ApiParsoidUtils.php(24): VEForAll\\ApiParsoidUtils->convert()

#2 /includes/api/ApiMain.php(1900): VEForAll\\ApiParsoidUtils->execute()

#3 /includes/api/ApiMain.php(875): ApiMain->executeAction()

#4 /includes/api/ApiMain.php(846): ApiMain->executeActionWithErrorHandling()

#5 /api.php(90): ApiMain->execute()

#6 /api.php(45): wfApiMain()

#7 {main}"

Exception caught: Class \"VEForAll\\RequestContext\" not found"


Looking at includes/ApiParsoidUtilsOld.php and adding "use RequestContext;" at the top of includes/ApiParsoidUtils.php fixes the error

141.90.9.33 (talkcontribs)

Can confirm, this seems to work. Without this edit, I can't even edit existing pages, let alone create new ones via PageForms.

Yaron Koren (talkcontribs)

Sorry about that! And thanks for finding a solution. I just checked in that line addition. I'm amazed that no one pointed this out until now... maybe most users still have not upgraded to 1.39.

Reply to "404 API error on 1.39"

Loss of data if Save clicked before full loading

2
Varlin (talkcontribs)

I use VEForAll with Page Forms. I have some fields, and a textarea that loads VisualEditor with VEForAll. It happens that the page is "almost" loaded, except the VEForAll part. Then, the textarea is still "blank" (its content is not loaded) and if I click the Save button before I wait the full loading of VEForAll, then the page is saved with this "blank" content. There is loss of data. I think a quick workaround would be to ensure that the Save button remains disabled until full loading of the page.

Revansx (talkcontribs)
Reply to "Loss of data if Save clicked before full loading"

What commit # to checkout for MW 1.34 combability?

15
Revansx (talkcontribs)

The "Compatibility Policy" for VEForAll is "master", but sadly that crashes my MW 1.34 wiki.

So I tried the REL1_34 branch of VEForAll which kinda works (basic editing is ok) but using anything on the toolbars features cause it crash.

I can't update to 1.35 yet. Does anyone know a branch, commit, or fork of VEForAll that works with 1.34?

  • MediaWiki: 1.34.4 (e34e7f2) 13:19, 24 September 2020
  • VisualEditor: 0.1.1 (74116a7) 18:02, 23 December 201
  • VEForAll: 0.1 (3032e34) 14:14, 3 October 2019
Yaron Koren (talkcontribs)

I think the latest code should work fine with MW 1.34.

Revansx (talkcontribs)

Here's the error I get when I use VEForAll master:

Fatal error: Uncaught ExtensionDependencyError: VEForAll is not compatible with the current MediaWiki core (version 1.34.4), it requires: >= 1.35.0. in /opt/htdocs/mediawiki/includes/registration/ExtensionRegistry.php:334 Stack trace: 
#0 /opt/htdocs/mediawiki/includes/registration/ExtensionRegistry.php(186): ExtensionRegistry->readFromQueue(Array) 
#1 /opt/htdocs/mediawiki/includes/Setup.php(143): ExtensionRegistry->loadFromQueue() 
#2 /opt/htdocs/mediawiki/includes/WebStart.php(81): require_once('/opt/htdocs/med...') 
#3 /opt/htdocs/mediawiki/index.php(41): require('/opt/htdocs/med...') 
#4 {main} thrown in /opt/htdocs/mediawiki/includes/registration/ExtensionRegistry.php on line 334
Revansx (talkcontribs)
Revansx (talkcontribs)

I just changed line 12 of extension.json from

"MediaWiki": ">= 1.35.0",

to

"MediaWiki": ">= 1.34.0",

and it seems to work better on MW 1.34.4 than the REL1_34 branch does. Does that make sense?

Yaron Koren (talkcontribs)

Oh, wow, I didn't notice that the required MediaWiki version for VEForAll was bumped up about six months ago. I just reverted that change, so now the requirement is back to 1.29. I'm glad to hear that it still works with earlier versions.

Revansx (talkcontribs)

Thanks. I fetched that latest version and verified that extension.json had the MW was requirement at >1.29.0.

  • Good news - All the VE tools work including tables
  • Bad news - The Save button no longer works.

Cindy mentioned that she thought saw a change recently that specifically mentioned 1.35 that might have driven the bump in MW version required. Does that ring any bells?

Yaron Koren (talkcontribs)

No. Do you see any error messages in the JavaScript console?

Revansx (talkcontribs)

I do not.

Revansx (talkcontribs)
Revansx (talkcontribs)

Here's what it is doing:

In VE mode:

  • If the text field is empty, then the form saves
  • If I add text to a VEForALll textarea field, then the form no longer saves

In wikitext node:

  • If I add text to a textaraea field, the form will save as if should

When I go to "re-edit" a form that has text saved from the wikitext mode:

  • The text shows in the textarea fields, but there are not editable
  • When I save the form, the existing text is lost.

There are no JS errors in any failure mode

It seems to be an API issue.

Cavila (talkcontribs)

Same here (MW 1.35). I haven't tested things extensively, but in the case of multiple-instance templates I have the same problems you described. Which is a pity because VEforAll is the only extension which at least in theory, supports having WYSIWYG editors in multiple instances.

Still no fixes I'm afraid.

Revansx (talkcontribs)

It should be an easy fix for those maintaining the skin.. We just have to do our part and report it! :-)

Yaron Koren (talkcontribs)

@Cavila - what versions of VEForAll and Page Forms are you running?

Cavila (talkcontribs)

I've tested VEForAll 0.4 with PF 5.3.2 as well as with an earlier version (PF 4.7).

  • For pre-existing instances, the textarea with editor=visualeditor shows the 'raw' source text. It looks slightly greyed out and is not editable.
  • I can add new instances with VE loading just fine.
  • Unless I click the bottom right toggle. If it works (which it doesn't necessarily), there seems no way to toggle back to VE.
  • There are some warnings but no error messages in the console such as Empty string passed to getElementById() and No name: {"type":"menu","include":{"group":"format"},"promote":["paragraph"],"demote":["preformatted","blockquote"]}
  • After I hit save, the content in textareas with VE is gone.
Reply to "What commit # to checkout for MW 1.34 combability?"

Issue with save button (need to click twice)

4
Simonsarazin (talkcontribs)

I need to click twice on the save page button to get the page registred.

I'm using mediawiki 1.31.3

Do you have the same problem ?

DHillBCA (talkcontribs)

Yes - I am encountering that in 1.35.3 with the current versions of Page Forms and VEForAll. Annoying, not crippling.

185.165.34.64 (talkcontribs)

Thanks. Yes, i also have the same problem with the 1.35. Did you found a way to resolve this ?

Flockies (talkcontribs)

it seems related with PageForms extension, a patch gerrit.wikimedia.org /r/c/mediawiki/extensions/PageForms/+/711131 has been proposed but it not been applied in master branch

Reply to "Issue with save button (need to click twice)"