FAQs

Note: Joomla! 3.4 is not compatible with PHP 7, the beta releases of Joomla! 3.5 are. I set up my test site by installing Joomla! 3.4.8 using PHP 5.6, then upgrading to Joomla! 3.5.0 beta 2 using the Testing mode in the Joomla! Upgrade option. Then I set my server to run PHP v7. 

Admin templates with Joomla! 3.5

ChronoForms v5.0.10+ appears to run correctly on Joomla! 3.5 with PHP 5.6 but not with the default Isis template - you just see the spinning loading image. Here are ways to fix this:

• Disable the 'Pinned toolbar' setting under: Extensions > Templates > Isis > Advanced > Pinned Toolbar (thanks to user carlo scarpello).
• Change to the Hathor Admin template (thanks to user carionpiet).
• There is an updated version of the Isis template called Isis3 available from GitHub here. If you get the Zip Download from GitHub you can install it in Joomla! as a normal template and it will show up as Isis3 in the template list. (thanks to user t3living)

Problems with Custom Actions

ChronoForms v5.0.11 fixes some minor bugs including a JavaScript error. That fix breaks any custom [GH] actions you have that still use the old code. I have updated the actions and you can re-download them from the original DropBox links if you still have them, if not please PM me to ask for the link.

Installing actions in CFv4

If you restore a form or install an action in CFV4 you get an UPLAOD FAILED message (typo included). The fix for this is to edit the file /administrator/components/com_chronoforms/controller.php around line 363 and line 459 and in each case replace

$uploadedfile = JFile::upload($file['tmp_name'], $path.DS.$filename);
if(!$uploadedfile){
  JError::raiseWarning(100, "UPLAOD FAILED".": ".$file['error']);
  $mainframe->redirect("index.php?option=com_chronoforms");

$uploadedfile = JFile::upload($file['tmp_name'], $path.DS.$filename, false, true);
if(!$uploadedfile){
  JError::raiseWarning(100, "UPLOAD FAILED".": ".$file['error']);
  $mainframe->redirect("index.php?option=com_chronoforms");

Backing up Forms in CFv4

You get an ereg() function is deprecated error when trying to backup a form. The fix is to edit the /administrator/components/com_chronoforms/controller.php file around line 321 and replace this code 

   if (ereg('Opera(/| )([0-9].[0-9]{1,2})', $_SERVER['HTTP_USER_AGENT'])) {
    $UserBrowser = "Opera";
   }
   elseif (ereg('MSIE ([0-9].[0-9]{1,2})', $_SERVER['HTTP_USER_AGENT'])) {
    $UserBrowser = "IE";
   } else {
    $UserBrowser = '';
   }

with this

   if (preg_match('/Opera(\/| )([0-9].[0-9]{1,2})/', $_SERVER['HTTP_USER_AGENT'])) {
    $UserBrowser = "Opera";
   }
   elseif (preg_match('/MSIE ([0-9].[0-9]{1,2})/', $_SERVER['HTTP_USER_AGENT'])) {
    $UserBrowser = "IE";
   } else {
    $UserBrowser = '';
   }

Code bugs with PHP7

The following bugs with PHP 7 are fixed in CFv5.0.11 

If you use both CCv5 and CFv5 please install CC first then CF as the CC files still need to be updated. 

When I upgraded to PHP 7 and go to the ChronoForms Forms Manager I see

Fatal error: 'break' not in the 'loop' or 'switch' context in /home/my_folder/my_domain.com/libraries/cegcore/helpers/html.php on line 45 

This can be corrected by commenting out two break; statements on lines 45 and 52

The Forms Manager then opens correctly, clicking View Form opens the form in the front-end with no errors, and, from limited tests, the forms appear to work correctly.

I have checked the CF files for similar break; errors and haven't found any - there are many 'break;'s but they are all in loop of switch statements. 

Note: I have not checked the CF installer using PHP 7 

The form Backup function is broken in PHP 7 as it used ereg() which has now been removed. 

The fix is to replace ereg( with preg_replace( in lines 319 and 321 of /administrator/components/com_chronoforms5/chronoforms/chronoforms.php

Similarly CCv5 needs the same change in lines 248 and 250 of the file /administrator/components/com_chronoconnectivity5/chronoconnectivity/chronoconnectivity.php

Other bugs in CFv5

This section is here as an aide mémoire for future versions.

There is a problem with the Designer > Events tab where the events don't display because of a small code error. There is a fix in this forum post.

There is a problem with the code used to detect index.html files in the events folder (there isn't one in the default distribution but they are sometimes added by security components). If the domain name includes a second . then it fails. There is a fix in this forum post.