Print

Print
Hi, Rebecca.

It looks like the problematic part might be in the form processing code starting around line 95 in $WEBPA_ROOT/tutors/forms/edit/add_question/class_wizardstep_1.php (where $WEBPA_ROOT is the installation directory of WebPA). As far as I can tell, it takes exactly what's entered into the form without any accounting for character encoding:

$this->wizard->set_field('question_text',fetch_POST('question_text'));

and

$this->wizard->set_field('question_desc',fetch_POST('question_desc'));

You might be able to work around that by using the iconv function in PHP--something like this:

$desc = iconv('UTF-8', 'ASCII//TRANSLIT',fetch_POST('question_desc'));
$this->wizard->set_field('question_desc',$desc);

What that should do is take any oddball characters like bullet points or Word quotation marks and convert them to their nearest "safe" equivalents. That being said, massive disclaimer: I'm not a WebPA developer or even particularly a PHP developer...I'm just someone who's had to
install and modify a couple of PHP applications and has learned enough PHP in the process to sort of get by. You'll probably want to run the above by an actual PHP person first.  

As for deleting the form, you may be able to do that from the database. There are two tables--pa2_form, that holds the actual form data, and pa2_form_module, that links form IDs with module IDs. You could either delete the form entry from both tables or--perhaps more 
safely--copy a working form's XML into the problem form's pa2_form.form_xml field, then delete it as normal in the user interface. Definitely try it out on a development system first if you have one, though. 

I hope all that helps you at least a bit. Let us know how it goes.

--
Tom Salyers
VLE Developer

The University of Sheffield
Corporate Information & Computing Services (CiCS)
10-12 Brunswick Street
Sheffield, S10 2FN
Tel:  0114 222 1141

On Wed, Apr 11, 2018 at 5:14 PM, Rebecca Gill - Newcastle University <[log in to unmask]> wrote:
An update on this issue: after further investigation we have identified a bug which affects text in the Description field when creating a criterion in a form.  If the text is copied and pasted from another source (e.g. Word or Outlook) and contains any special characters (e.g. quotation marks, bullet points and other punctuation marks) the criterion breaks the form.  It's still possible to view broken forms and open them for editing, but any criteria that had been added before the form broke are no longer visible, adding a new criterion throws the error reported in my earlier message, and it is not possible to delete the form.

The issue can be worked around by avoiding special characters in the Description field, but we would like to find a fix if possible.  Has anyone encountered this issue and is there a fix we can apply?

Thank you in advance


Rebecca