Jump to content
Sign in to follow this  
MarkE

SOLVED: Odd happenings with $templates->setImportData()

Recommended Posts

I have a situation where $templates->setImportData() is not behaving as expected. This might be more general issue as I can't see anything odd about my situation. Basically, the problem is that it seems to return the wrong result and not update the template, but returns no error messages.

RESOLVED:

  • The problem with the changes being truncated is that Tracy appears to truncate the json string. The php variable is fine. So maybe there is a Tracy problem, but nothing wrong with the API.
  • The problem with not saving is that setImportData is not intended to save the data. I borrowed the saveItem() method from ProcessTemplateExportImport and that does the trick.

Original problem description retained below for the record.

..............................................................................................................

I have tracked the results using Tracy bd(), as follows:

  1. Template data is exported as json into a file: 
    // Get the export data
    $rawData = $templates->getExportData($t); // $t is a template
    
    //Encode the array into a JSON string.
    $encodedString = wireEncodeJSON($rawData, true, false);
    
    //Save the JSON string to a text file.
    file_put_contents('json_array.txt', $encodedString);
    
    //Retrieve the data from our text file.
    $fileContents = file_get_contents('json_array.txt');
    
    //Convert the JSON string back into an array.
    $decoded = wireDecodeJSON($fileContents);

    bd() indicates that $rawdata and $decoded are identical.

  2. A simple mod is made to the context description of a field ('operator') in the txt file and the above is run (without the file_put_contents, so as not to revert the txt 😉), followed by
    $result = $templates->setImportData($t, $decoded);

    bd($result) gives (identical) 'old' and 'new' strings for the 'summary' field only (the first after 'title', which has no contextual changes). The remaining fields (including 'operator' which would be next) are not shown.
     

    array
    'fieldgroupContexts' => array
    'old' => 
    '{
        "summary": {
            "description": "About this page",
            "editRoles": [
                7258
            ],
            "flagsAdd": 224,
            "rows … 50
        }
    }'
    'new' => 
    '{
        "summary": {
            "description": "About this page",
            "editRoles": [
                7258
            ],
            "flagsAdd": 224,
            "rows … 50
        }
    }'
    'error' => array (0)

     

  3. Tracking this through the wire code, everything is as expected until Fieldgroups::___setImportData() where we have the following code (with my bd() additions):
    			$old = wireEncodeJSON($_data['contexts'], true, true);
    			$new = wireEncodeJSON($data['contexts'], true, true);
    
    			if($old !== $new) {
    			bd($old, 'old');
    			bd($new, 'new');
    				bd(trim($old), 'trim old');
    				bd(trim($new), 'trim new');
    				$return['contexts']['old'] = trim($old);
    				$return['contexts']['new'] = trim($new);
    				bd($return, 'return');
    				

    $old and $new are exactly as expected, with my change for the 'operator' description. trim($old) and trim($new) are the same as $old and $new. However, $return['contexts']['old'] and $return['contexts']['new'] have truncated the $old and $new strings as described earlier. bd($return) shows:
     

    array
    'fields' => array
    'old' => ''
    'new' => ''
    'error' => array (0)
    'contexts' => array
    'old' => 
    '{
        "summary": {
            "description": "About this page",
            "editRoles": [
                7258
            ],
            "flagsAdd": 224,
            "rows … 50
        }
    }'
    'new' => 
    '{
        "summary": {
            "description": "About this page",
            "editRoles": [
                7258
            ],
            "flagsAdd": 224,
            "rows … 50
        }
    }'
    'error' => array (0)

     

  4. In addition to the returned changes being incomplete, the template is not being updated for the import data. Initially I thought that these issues were connected, but on inspection, it seems that the the contexts are all set, regardless of any detected changes. Later in Fieldgroups::___setImportData() we have (again with my bd() addition)
    foreach($data['contexts'] as $name => $context) {
    					bd($data['contexts'][$name], 'Context for ' . $name);
    					$field = $fieldgroup->getField($name, true); // in context
    					if(!$field) {
    						if(!empty($context)) $return['contexts']['error'][] = sprintf($this->_('Unable to find field to set field context: %s'), $name);
    						continue;
    					}
    					$id = $field->id;
    					$fieldContexts = $fieldgroup->getFieldContextArray();
    					if(isset($fieldContexts[$id]) || !empty($context)) {
    						bd($data['contexts'][$name], 'Setting context for ' . $name . ', id = ' . $id) ;
    						$fieldgroup->setFieldContextArray($id, $context); 
    						$fieldgroup->trackChange('fieldContexts');
    					}
    				}

    The dumps indicate that all the data is present and correct and that the new context for operator has been passed to setFieldContextArray. However, the template itself (on inspection in the admin) appears to be unchanged.

  5. I can see that there is a saveContext() method for Fieldgroup and Fieldgroups classes, which I can't see being called, so I'm not sure how the context is actually being saved.

I'm afraid that, at this point my knowledge of PW (and, to an extent, of PHP) hindered me from making further progress, but maybe I missed something obvious along the way?

Do I misunderstand the setImportData() method, might there be something odd with my data, or is there a bug?

 

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
Sign in to follow this  

  • Recently Browsing   0 members

    No registered users viewing this page.

×
×
  • Create New...