Extension talk:CIForms

I'm running MediaWiki 1.39.8 LTS with CIForms versions 1.3.0 from the REL1_39 branch on your GitHub, I'm running into the following error trying to implement a mail-in form with Google reCAPTCHA, "Form submission Captcha challenge not found. Please try again or contact admin@mywiki.wiki to receive support", I am using a CSP with the $wgCSPHeader header, it contains the following CSP declarations:

$wgCSPHeader = [

"useNonces" => false,

"script-src" => [

'\'self'',

'https://www.gstatic.com/recaptcha/',

'https://www.google.com/recaptcha/'

],

"default-src" => [

'\'self'',

'https://api.flickr.com'

],

"style-src" => [ '\'self\'' ],

"object-src" => [ '\'none\'' ]

];

And I have the following CIForms Config:

$wgCIFormsSenderEmail = "admin@mywiki.wiki";

$wgCIFormsSenderName = "Admin - My Wiki";

$wgCIFormsMailer = "smtp";

$wgCIFormsSMTPHost = "smtp.company.email";

$wgCIFormsSMTPUsername = "admin@mywiki.wiki";

$wgCIFormsSMTPPassword = "password";

$wgCIFormsSMTPPort - 587;

$wgCIFormsDataAccess = [ "bureaucrat", "administrators", "content-moderators" ];

$wgCIFormsGoogleRecaptchaSiteKey = "key";

$wgCIFormsGoogleRecaptchaSecret = "secret";

The Google ReCAPTCHA secret and site key are valid and I've double checked that, and I'm not sure what could be causing the issue, there's no errors reported in my web console, by apache, by my CSP or anything. Help would very much be appreciated, thanks!

@Aeyeu first of all can you try to install 1.3.2 ? thank you

I did that, and it still is giving the same error, however with 1.3.2 I'm getting a composer requirement failure, which you may want to resolve.

"Root composer.json requires dompdf/dompdf ^1.0, ^3.0, found dompdf/dompdf[dev-rtl_language_support_and_computed_css, dev-resource-validation-updates, dev-vertical-align, dev-master, dev-rtl, dev-v2-maintenance, dev-stylesheet-parsing-updates, dev-develop, dev-paging-updates, v0.6.0, ..., v0.8.6, v1.0.0, ..., v1.2.2, v2.0.0, ..., v2.0.8, v3.0.0] but it does not match the constraint."

that seems strange, since composer requires dompdf/dompdf ^3.0

also there is this typo in your settings

 $wgCIFormsSMTPPort - 587; 

Yeah I fixed that mistake after searching for solutions, for some reason randomly when I refreshed the page I got a captcha in front of every wiki element and at the top of the page, completing this did nothing to fix the issue, even when disabling my CSP the reCaptcha had failed to generate.

I think it would be good to support also reCaptcha v2, see here https://stevesohcot.medium.com/php-tutorial-how-to-implement-a-captcha-im-not-a-robot-checkbox-using-google-e8f110590141 and here https://www.mediawiki.org/wiki/Topic:Y271jujxxtj2ckg3 @Lotusccong

Okay, what does this mean for me? Also are we able to get Cloudflare's Turnstile supported by chance?

I swapped to reCAPTCHA V3 and I get a different error now, "[972bca6f451455c90a42dbd1] /w/Special:CIFormsSubmit TypeError: htmlspecialchars(): Argument #1 ($string) must be of type string, array given"

Hi, I use reCAPTCHA V3 in CIForms for users to fill out their requests. Recently, users started to complain about errors when sending the form. It turned out the error is timeout-or-duplicate. Since the token is generated once the page is loaded and its lifetime is just 2 minutes, it can take more time for users to fill out the form. So far, I fixed it by calling the function that generates the captcha token every 90 seconds. The change was made in resources/validation.js. The patch is below. Is there any chance to fix this?

--- validation.js 2024-04-10 08:33:50.225438151 +0200

+++ validation_new.js 2024-04-10 08:33:43.701502919 +0200

@@ -35,6 +35,34 @@

.replace( />/g, '\x3E' );

}

+  function executeRecaptchaValidation() {

+    var site_key = mw.config.get('ci_forms_google_recaptcha_site_key');

+

+    mw.loader.getScript('https://www.google.com/recaptcha/api.js?render=' + site_key)

+        .then(

+            function () {

+                if ($('input[name="g-recaptcha-response"]').length) {

+                    grecaptcha.ready(function () {

+                        grecaptcha.execute(site_key, { action: 'validate_captcha' })

+                            .then(function (token) {

+                                $('input[name="g-recaptcha-response"]').val(token);

+                            })

+                            .catch(function (error) {});

+                    });

+                }

+            },

+            function (e) {

+                mw.log.error(e.message);

+            }

+        );

+  }

+

+  executeRecaptchaValidation();

+  // Obnoveni recaptcha tokenu kazdych 90 vterin

+  setInterval(executeRecaptchaValidation, 90 * 1000);

+

+

+  /*

var site_key = mw.config.get( 'ci_forms_google_recaptcha_site_key' );

mw.loader

@@ -57,6 +85,8 @@

}

);

+  */

+

$( '.ci_form' ).each( function ( index ) {

var paging = $( this )

.find( 'input[type=hidden][name=form_paging]' )

@Jachym16 thanks a lot! added in latest version (1.3.2)

Hi, Thank you for resolving that issue. However, it turned out to be a temporary solution for me. Since the form is placed on a landing page, it generated a large number of unwanted reCaptcha tokens. Recently, reCaptcha started to give everyone a score of about 0.1 (though I'm not sure if it's related). I believe the best solution would be to request the token only when the Submit button is pressed. Please find the patch file below. Thanks, Jáchym

--- validation.js	2024-07-08 10:54:01.464233524 +0200
+++ validation.js.new	2024-07-08 11:04:26.478076333 +0200
@@ -35,21 +35,29 @@


 			.replace( />/g, '\x3E' );
 	}
 
+
   function executeRecaptchaValidation() {
     var site_key = mw.config.get('ci_forms_google_recaptcha_site_key');
 
-    mw.loader.getScript('https://www.google.com/recaptcha/api.js?render=' + site_key)
+    return mw.loader.getScript('https://www.google.com/recaptcha/api.js?render=' + site_key)
         .then(
             function () {
-                if ($('input[name="g-recaptcha-response"]').length) {
-                    grecaptcha.ready(function () {
-                        grecaptcha.execute(site_key, { action: 'validate_captcha' })
-                            .then(function (token) {
-                                $('input[name="g-recaptcha-response"]').val(token);
-                            })
-                            .catch(function (error) {});
-                    });
-                }
+                return new Promise((resolve, reject) => {
+                    if ($('input[name="g-recaptcha-response"]').length) {
+                        grecaptcha.ready(function () {
+                            grecaptcha.execute(site_key, { action: 'validate_captcha' })
+                                .then(function (token) {
+                                    $('input[name="g-recaptcha-response"]').val(token);
+                                    resolve();
+                                })
+                                .catch(function (error) {
+                                    reject(error);
+                                });
+                        });
+                    } else {
+                        resolve();
+                    }
+                });
             },
             function (e) {
                 mw.log.error(e.message);
@@ -57,35 +65,6 @@
         );
   }
 
-  executeRecaptchaValidation();
-  // Obnoveni recaptcha tokenu kazdych 90 vterin
-  setInterval(executeRecaptchaValidation, 90 * 1000);
-
-
-  /*
-	var site_key = mw.config.get( 'ci_forms_google_recaptcha_site_key' );
-
-	mw.loader
-		.getScript( 'https://www.google.com/recaptcha/api.js?render=' + site_key )
-		.then(
-			function () {
-				if ( $( 'input[name="g-recaptcha-response"]' ).length ) {
-					grecaptcha.ready( function () {
-						grecaptcha
-							.execute( site_key, { action: 'validate_captcha' } )
-							.then( function ( token ) {
-								$( 'input[name="g-recaptcha-response"]' ).val( token );
-							} )
-							.catch( function ( error ) {} );
-					} );
-				}
-			},
-			function ( e ) {
-				mw.log.error( e.message );
-			}
-		);
-
-  */
 
 	$( '.ci_form' ).each( function ( index ) {
 		var paging = $( this )
@@ -425,5 +404,16 @@
 				return false;
 			}
 		}
+    
+    // zabrani odeslani formulare - provede se manualne po validaci recaptcha
+    evt.preventDefault();
+
+    executeRecaptchaValidation().then(() => {
+        this.submit(); // submit formulare
+    }).catch(() => {
+        alert('reCAPTCHA validation failed. Please try again.');
+    });
+
+
 	} );
 } );

@Jachym16 perhaps this is preferable https://gist.github.com/jonathanstark/dfb30bdfb522318fc819 -- I will check it later

Hi. CIForms currently has a Composer dependency on dompdf/dompdf 1.x which is affected by CVE-2022-0085, CVE-2022-41343, CVE-2023-23924 and CVE-2023-50262. Please consider upgrading to dompdf 2.x.

thank you, I will do at the next update of the extension

@Taavi fixed in the latest version (1.3.2), thanks a lot!

Is there a way to also send the pdf-form to the user who filled the formula?

I shy away from editing the extention code directly but I think there is no other way?

Can you help me with that?

I solved it...

I added th the CIFormsSubmit.php on line 137 this:

if ($user->getEmail() !== '') {

        $mail->addAddress( $user->getEmail() );

        }

Now the Mail es sent to the user who filld the formula if he/she is loggend-in and has a email-adress in user. may be not the best solution but works

@Parzival1200 thank you, I will take it into account at the next release

@Parzival1200 added in the latest version (1.3.2) thank you!

I had our MediaWiki software updated from 1.35 to 1.39. After the upgrade, the number "1" started appearing on all our wiki pages that use CIForms, in the top right corner of the page, in the title line.

<div class="mw-indicators">
<div id="mw-indicator-ciform" class="mw-indicator"><div class="mw-parser-output">1</div></div>
</div>

Apparently, this is a page status indicator. Any tips how to turn it off? I guess I could hide it via CSS.

You should locate the indicator in the page source (or template) and remove it from the page. Hiding it with CSS is just hiding the problem, not solving it.

Neither the page source nor the template adds the indicator. Even a brand new page with the following code displays it.

{{#CI form: title = Hello world}}

I don't know what's #CI form and what it does. Can you create a page with *only* Hello world?

Also, what extensions have you installed? Maybe one of the extensions is adding it

@Cru121 and @Ciencia Al Poder I'm sorry for the delay, I plan to publish a version that solves the issue as soon as possible, with some new feature

@Cru121 it should be fixed with the latest version (1.3.2) !

Hi,  I have a problem with exporting the forms data into PDF. Not all Czech characters inside the PDF are formatted correctly. I found out that it is the text font that is causing this issue. I found a font that fixes the problem. The solution is to add the line of code from below into createPDF function, inside the $form_output_html variable, inside <style>. After that, all Czech characters are formatted correctly.

$form_output_html .= '* { font-family: DejaVu Sans, sans-serif; }';

@Jachym16 added in the latest version (1.3.2) thank you !

I currently have the 1.39 package for CI Forms running on MediaWiki 1.41. I've had this issue even when MediaWiki was at version 1.39. Basically when I load the pages Special:CIFormsManage or Special:SpecialPages, I get the following errors:

[562694b55f00e86faf703aa2] /index.php/Special:CIFormsManage Error: Class "MediaWiki\Navigation\PrevNextNavigationRenderer" not found Backtrace: from /var/www/html/extensions/CIForms/includes/specials/PrevNextNavigationRendererCIForms.php(24)

1. 0 /var/www/html/extensions/CIForms/includes/specials/CIFormsManage.php(24): include_once()
2. 1 /var/www/html/includes/AutoLoader.php(221): require(string)
3. 2 [internal function]: AutoLoader::autoload(string)
4. 3 /var/www/html/vendor/wikimedia/object-factory/src/ObjectFactory.php(285): class_exists(string)
5. 4 /var/www/html/vendor/wikimedia/object-factory/src/ObjectFactory.php(174): Wikimedia\ObjectFactory\ObjectFactory::validateSpec(string, array)
6. 5 /var/www/html/vendor/wikimedia/object-factory/src/ObjectFactory.php(149): Wikimedia\ObjectFactory\ObjectFactory::getObjectFromSpec(string, array)
7. 6 /var/www/html/includes/specialpage/SpecialPageFactory.php(1474): Wikimedia\ObjectFactory\ObjectFactory->createObject(string, array)
8. 7 /var/www/html/includes/MediaWiki.php(304): MediaWiki\SpecialPage\SpecialPageFactory->getPage(string)
9. 8 /var/www/html/includes/MediaWiki.php(960): MediaWiki->performRequest()
10. 9 /var/www/html/includes/MediaWiki.php(613): MediaWiki->main()
11. 10 /var/www/html/index.php(50): MediaWiki->run()
12. 11 /var/www/html/index.php(46): wfIndexMain()
13. 12 {main}

Not sure how to resolve this as no forums online seem to address this issue. Any help would be appreciated.

@Tarunjoseph93 since MW 1.41 the class PrevNextNavigationRenderer has been removed, as a consequence CIForms is not currently compatible with MW 1.41. I have scheduled to do a general maintenance of the extension, but I don't have yet an ETA. If you need urgent support you can contact me by email

Does this mean I need to revert my MW version to 1.40 or 1.39?

unless you can/want disable CIForms, yes

@Tarunjoseph93 it should be fixed with the latest version (1.3.2) !

When we click the Download lick, it only show the 1.40, 1.41 and Master (latest development version) .

Which one that I should choose for MW 1.39 ?

I think always master, unfortunately the extension does not work on MW 1.41.0. I planned to do a general update of it but had other priorities meanwhile @Lotusccong

Will look forward to update to MW 1.4+ Great and much appreciated extension!

hello @School4schools thanks for your feedback, if you have a public use-case I can post it on the extension's page

My site is www.school4schools.wiki I was interested in CIF forms for contact forms (I turned them off bc of spam) and quizzes for classes. I haven't implemented them yet, as this is a long-term, side-project. I do need to update to 1.41 for certain new features it brings, including for mobile viewing via MobileFrontend extension, which doesn't work w/ 1.39.

So I'm not a priority, but letting you know you have a great extension!

@School4schools @Lotusccong the latest version (1.3.2, master) should work with recent versions of Mediawiki as well !

Hi, I just installed this on MW 1.41 without reading this discussion and I've just learned that it isn't compatible with 1.41 yet,

When I go to Tools -> Special Pages I get an error now and cannot view those pages'

[3ea6e9ec6c538d7cf9d141aa] 2024-03-01 14:01:37: Fatal exception of type "Error".

If I disable the plugin in LocalSettings.php I can then view the special pages again.

I'm not sure what I should do? I'm concerned it's permanently damaged my install in some way. What is the recommended course of action?

Also when I ran the maintainance/update.php It seemed to run ok but there was a warning that I should have executed maintainance/run.php instead. Could this be the problem?

Thanks.

I've just looked in the error log:

[01-Mar-2024 14:16:40 Europe/London] PHP Deprecated:  Use of ParserOutput::getFlag was deprecated in MediaWiki 1.38. [Called from CIForms::onOutputPageParserOutput in <snipped>/extensions/CIForms/includes/CIForms.php at line 79] in <snipped>/includes/debug/MWDebug.php on line 386

hello @Findjam if you just comment it on LocalSettings there won't be any kind of damage to the MW installation. Just, currently it does not work on MW 1.41, I don't still have an ETA for this but you can contact me directly for specific support

Hi Thomas,

Thanks for the reply. No problem at all. I have done that and I just rolled back the DB a few hours just to be on the safe side. No harm done.

Look forward to the update as this really does seem to be the best and most feature rich Form extension, unless I've missed something. If I find some time I may roll my sleeves up and take a look, possibly create a PR on GitHub.

there is also the following Extension:VisualData

@Findjam the latest version (1.3.2) should work with recent versions of Mediawiki as well !

Is there any update as to the PrevNextNavigationRenderer error on Special Pages showing up for 1.41 and greater? I can't really downgrade my wiki install but your extension looks great and does exactly what I need in many ways.

fixed in the latest version (1.3.2)