Forums

A very very severe bug in NEW record and NEED to be FIXED

maxxoros 10 Sep, 2009
Well, this is a very very severe bug. Let me explain
For example

-- Your user_id = 77
-- There is an exising record in table that edit with CC has cf_id = 77

Create a new record, BINGO, it come to the fact that you are EDITING that record with cf_id = 77

Conclusion:
--- It comes out for a mistake, if there is cf_id = user_id, we will come trouble in create new record. New record will lead to editing record with cf_id = user_id

Please fix this issue ASAP, thanks for the great tool πŸ™„ πŸ™„
erict 21 Oct, 2009
I too am finding I have this exact problem. If this has already been discussed is there a fix to it and if so how/where?

Thanks!

- Eric
erict 21 Oct, 2009
After extensive searching I CANNOT find where this is coming from, the code all looks right to me to the best of my knowledge. We're going to need Max or Grey to look further into this as I cannot find where the trip up is.

What kills me is even in chronoconnectivity.html.php on line 59 $row->$primary evaluates to 0 when using new records but the actual content on the page reflects otherwise, this is quite maddeningπŸ˜›


If there are no dependent uses of the record set your using you can go into your MySQL manager (ie: phpMyAdmin) and run this (presuming your primary key it 'cf_id'):

UPDATE my_table_name SET cf_id = (cf_id + 10000)


Its a bad work around and presumes that you wont have more than 10,000 registered users but it will dodge the issue, or it did for me at least :\

- Eric
bottomupwebs 22 Nov, 2009
I'm having the same issue with several sites over the last two months.

Greyheads/Mike's suggestion of turning the DB "enable data storage" off means that the New Record does not get saved. :? That's not the solution. That's a different problem.(We aren't getting double records).

Just to repeat the issue...
When we use {new_record} - we end up editing a record with a cf_id that matches our user_id.

In other words - if your user_id happens to match a record's cf_id - you won't be able to make a new record.

Thanks maxxoros for your insight here. I think you are correct.

For those looking for a work around, start your cf_id from, say, 10000 and up. One way to do this is to edit your SQL database manually - set your auto increment to 10000 or more before entering data.

I hope this major issue gets corrected. Agreed - its a great app - thanks πŸ˜€
dwegner 23 Nov, 2009
Having same problem. HELP!
maxxoros 11 Dec, 2009
I can not find what s wrong with code, but, in my experience, update your newest CC and CF will solve it some how

But, It is still deep inside and could happen any time in future...So upgrate to a new version of CC and CF need to be careful to advoid this issue
jnobel 02 Mar, 2010
This is realy an absurd bug. I'v got a config with several forms and several users. For each of the combination I can expect problems once the recod count cf_id reaches one of the users is values.

I've dug deep in the code and indeed it's amazingly hard to find exactly where things go wrong.
Spent hours with debug code.

Must be somewhere in the evaled code ... When I reach HTML_ChronoContact::showform somehow
$MyForm->posted['cf_id'] equals my current user_id ...
nml375 03 Mar, 2010
Well,
I've figured out the cause for this issue.. Havn't quite figured the fix just yet...
Both new and edit record uses the very same code, with the exception of the presence of the cids url parameter (basically tells which database record to retrieve). If this parameter is not used, '' will be used (See the CFChronoConnection class in libraries/connection.php, method editRow).

Here we create a new JTable object matching the table we're "connected" with. If cids (now called $rowid) is non-false, it will be used to load the JTable object with data from the database. If the rowid does not exist in the database, or isn't submitted, an empty object will be loaded instead.

Next, we call HTML_ChronoConnectivity::editrecord with the new JTable object, in order to display our new/edit form. This will load the needed ChronoForms data and object. Once the form is loaded, a few tweaks are done, such as setting the action url; and - this is the very important part - sets up the cf_profile plugin to prefill the form. The plugin is run, and the form is displayed.

Now, here's the issue. The Profile plugin looks for a (user controlled) url-parameter, if it's not present, a default value is used. CC set this up so that the url-parameter is called '', and the default value has the value of the cids/rowid/primary key value. The plugin is thus expected to use the default value. However, if the default value is also empty (remember we had $rowid == '' when creating a new record), the plugin tries to be smart, and finally resorts to the current user's id. Unfortunately, this means that the plugin will load a present record with matching primary key, and submitting the form will subsequently edit the old record instead of creating a new one.

I suppose the best way of working around this, would be to not running the profile plugin in the case $rowid is empty (somewhere in the end of chronoconnectivity.html.php).

A quickfix seems to locate the "runPlugin" line of code in chronoconnectivity.html.php:
        evaluate=1';
        $pluginObject->params = $paramsString;
        $EditFormPlugins->runPlugin('', array('ONLOAD', 'ONLOADONSUBMIT'), 'cf_profile', $pluginObject);
        
        $EditForm->showForm(trim($MyConnection->connectionparams('front_edit_form')), JRequest::get( 'post' , JREQUEST_ALLOWRAW ), false);

and edit it accordingly:
        evaluate=1';
        $pluginObject->params = $paramsString;
        if (!empty($row->$primary) && $row->$primary != ''){
            $EditFormPlugins->runPlugin('', array('ONLOAD', 'ONLOADONSUBMIT'), 'cf_profile', $pluginObject);
        }
        $EditForm->showForm(trim($MyConnection->connectionparams('front_edit_form')), JRequest::get( 'post' , JREQUEST_ALLOWRAW ), false);


/Fredrik
jnobel 04 Mar, 2010
Thanks Fredrik for the fine analysis.
When I ran into the problem I tought I'd tried commenting out the call to the plugin entirely but it didn't seem to have effect.
But then again, It was 3:30 in the morning and I might have forgotten to FTP the right file to the server :-)
Eventually I did the set cf_id = cf_id + 10000 fix...
nml375 04 Mar, 2010
Well, commenting out the call to the plugin alltogether would break the edit function, so I would not advice that approach. Also, the workaround with huge cf_id's ain't the best, as sooner or later you'll end up with a collision. Better to get a proper fix while you remember the error is in there. From limited testing, the fix I posted earlier seems to do the trick neatly; anyone else tried it with good/bad experiences?

/Fredrik
GreyHead 05 Mar, 2010
Hi Fredrik,

Wonderful detective work there!!

If you have a working test ChronoConnection please will you try this mod to the plugin code. In cf_profile.php around line 211 add the extra 'elseif' in this version to override the default selection of the user_id if the code is called by chronoconnectivity:
		$parid 	= JRequest::getVar($params->get('parameter'));
        if ( $parid ) {
            $record_id = $parid;
        } elseif ( $option == 'com_chrononconnectivity' ) {
            $record_id = false;
	} elseif ( $params->get('default_param_value') ) {
	    $record_id = $params->get('default_param_value');
        } else {
            $record_id = $my->id;
            if ( $record_id == 0 ) {
                //$record_id = '##guest##';
            }
        }

Bob
nml375 05 Mar, 2010
Hi Bob,
Sorry, but your approach did not solve the issue. The reason for this is found within library/plugins.php of the ChronoForms component, on line 101 (the runPlugin method). Here, the first parameter for the onload method call is hardcoded to 'com_chronocontact', not the name of the component that actually loaded and executed the CF Plugin.

The only problem I can imagine with my current suggestion for a solution, is that we don't honor the "Evaluate Code" that is otherwize done by the cf_profile plugin. I have, however, tested this solution on a form that uses the addScriptDeclaration() method of the JDocument class in order to add custom javascripts (alters the state of a second dropdown depending on the value of a first). This works as intended both with "edit record" and "new record", and I've yet to see any warnings or errors. I believe this would only be an issue if you've got some code that outputs new php-code to be executed:
<?
$string = '<? echo "A second evaluation"; ?>';
echo $string;
?>

I'm not that sure this kind of form coding is that usual however...

/Fredrik
GreyHead 07 Mar, 2010
Hi Fredrik,

Another attempt to modify the Profile plugin . . .
		$uri =& JFactory::getURI();
		$parid 	= JRequest::getVar($params->get('parameter'));
        if ( $parid ) {
            $record_id = $parid;
        } elseif ( $uri->getVar('option') == 'com_chrononconnectivity' ) {
            $record_id = false;
		} elseif ( $params->get('default_param_value') ) {
			$record_id = $params->get('default_param_value');
        } else {
            $record_id = $my->id;
            if ( $record_id == 0 ) {
                //$record_id = '##guest##';
            }
        }
Trying to find the option from the URI query string this time.

Bob
nml375 07 Mar, 2010
Hi Bob,
Havn't tried this one yet. However, both the option and task parameters are included as hidden form inputs, and are thus available in the $_POST array. I'm not sure if these are also added to the action URL or not, I'll have to take a look at it later tonight..

Also, I'm not so sure editing the CFplugin is the way to go, as it is a well-known behaviour for as long as I can remember. In CC, the CFplugin is run with the editable parameter set to 1, so it'll look for form field inputs rather than {fieldname} placeholders. As such, there really isn't any need to run the plugin when creating a new record. It's good to know there are options for solving this issue however.

/Fredrik
GreyHead 07 Mar, 2010
Hi Fredrik,

I'm sure that you are right that it would be better to change the ChronoConnectivity code - but I don't have any effective way to do that. I can though, change the plugin code so a workaround in there would at least hide the problem.

I've just been trying to find a way to suppress the insertion of the user-id in the case where the code is being called by ChronoConnectivity. But I'm not at all sure that my little test form is checking the right things :-(

Bob
nml375 07 Mar, 2010
Hi Bob,
That makes a good enough point, and as I said, it's good to know there are several options for solving this issue.

Had time to check the generated action URL now; tested both new and edit record, with both menu-link and direct connection link:
<form name="ChronoContact_application" id="ChronoContact_application" method="post" action="index.php?option=com_chronoconnectivity&connectionname=test" >
...
  <input type="hidden" name="option" value="com_chronoconnectivity" />
  <input type="hidden" name="cf_id" value="0" />
  <input type="hidden" name="task" value="saverecord" />
  <input type="hidden" name="1d4a3c744f52fd735b79f9e4e041aa2b" value="1" />	
  <input type="hidden" name="1cf1" value="5795d288842202ba4856083d3f5735cb" />
</form>

cf_id is the primary key for this table, and has the value 0 for "new record", and the value for the current row for "edit record". I'd rather suggest you use the JRequest::getCmd() method than the JURI class, mainly as it's more intuitive. In this case you could use either 'get' or 'post', not sure which would be preferable. I suppose you could actually go for the default, where joomla uses the $_REQUEST array (combination of $_GET, $_POST, and $_COOKIE).

/Fredrik
dwegner 15 Apr, 2010
It looks like this is the fix for this. It basically checks to see if the task=newrecord. If so then set the record_id to false.
 $uri =& JFactory::getURI();
      $parid    = JRequest::getVar($params->get('parameter'));
        if ( $parid ) {
            $record_id = $parid;
        } elseif ( $uri->getVar('task') == 'newrecord' ) {
            $record_id = false;
      } elseif ( $params->get('default_param_value') ) {
         $record_id = $params->get('default_param_value');
        } else {
            $record_id = $my->id;
            if ( $record_id == 0 ) {
                //$record_id = '##guest##';
            }
            }
bobby_m 08 Jun, 2010
Why didn't this fix get put into the core code for CF and CC? I just found out about this bug on my own site. Everything was working fine because most users adding records had user IDs above 60, when cf_ID number finally got up into that area, {new record} use started editing records where userID = existing cf_ID.

Isn't this sort of bug a complete killer? It is for my use.

So far my workaround is to skip using {new record} within the CC instance and just add a straight "a href" link to Chronoform itself. That seems to show the proper user name and an otherwise blank form rather than editing an existing record.

I see the code in the previous post but I'm not sure exactly what it does or where it needs to be added.

Bobby
GreyHead 08 Jun, 2010
Hi Bobby,

So far my workaround is to skip using {new record} within the CC instance and just add a straight "a href" link to Chronoform itself. That seems to show the proper user name and an otherwise blank form rather than editing an existing record.

That's what I do - I also add the code to the ChronoForm to check the uid from the calling URL and load the data from the database. A bit more work but much more robust.

Bob
nml375 08 Jun, 2010
Hi Bobby,
I would agree that this is a serious issue. Unfortunately, Max has not released an update with any of the proposed fixes as of this date.

Not using the {new record} placeholder works "well enough" as long as you remember to not use it. Personally, I try to avoid using workarounds to fix bugs "outside" my code, though sometimes that's not really practical or unavoidable.

Applying the different fixes;
There are several different proposals as to fixing this issue. The fix proposed by me, in a previous post, involves modifying a few lines inside the chronoconnectivity.html.php file within the ChronoConnectivity component. Once installed on your Joomla system, this would usually be located at
/path_to_webroot/public_html/components/com_chronoconnectivity/chronoconnectivity.html.php

Bob posted a few alternate fixes modifying the Profile CFPlugin of ChronoForms instead, which should be this file instead
/path_to_webroot/public_html/components/com_chronocontact/plugins/cf_profile.php

The suggested fix by "dwegner" applies to this file as well.

Using these fixes still requires you remember to apply one of them when the component is installed on a new site, so we still have to wait for Max to release an updated version of the ChronoConnectivity component..

/Fredrik
conner1 29 Jun, 2010
Has this been fixed now?
JvdStel 19 Jun, 2011
It's been a year now. In the meantime, has there been a new release of CC that fixes this bug?
This topic is locked and no more replies can be posted.