[Solved] How to get the latest user settings with the API?

[tulavu]

Hi,

Modx 2.7.3, I have a profile page with custom user settings (speed, difficulty, max_attempts, and more…)

On the profile page, the user can edit and save his settings.

I noticed the updated values are shown when the page reloads, however only when the user has just logged in and the user did not update his settings more than once after logging-in.

In other words:

IT WORKS WHEN: the user logs in, goes to his profile page and updates his settings —> the script saves the values and the page reloads with the updated values
IT DOESN’T WORK WHEN: the user had already updated his profile and tries to update it a second time — > the page reloads with the former values, a refresh is needed to see the updated values

I tried [[++difficulty]] or [[!++difficulty]]

Here is the relevant code, which is included in a foreach loop because there are several custom user settings to save:

foreach ( $fields as $key => $value ) {

    $setting = $modx->getObject( 'modUserSetting', [
	    'key' => $key,
	    'user' => USERID,
    ]);

    if ( !$setting ) {
	    $setting = $modx->newObject( 'modUserSetting' );
	    $setting->set( 'key', $key );
	    $setting->set( 'user', USERID );
    }	

    $setting->set( 'value', (string)$_POST[ $key ] );

    if ( $setting->save() ) {

	    //$modx->cacheManager->clearCache(); // THIS LINE DOESN'T HELP
	    //$modx->cacheManager->refresh(); // THIS LINE DOESN'T HELP
	    
	    $modx->user->addMany( $setting, 'UserSettings' );
	    $modx->getUser( '', true );

    }
}

I have tried several options to have the updated values showing up after the user has saved but it didn’t work.

Maybe is there another approach? Am I doing something wrong? Should I store all the new values in an array and only execute $setting->save() after the foreach loop is finished? Are there other solutions to have the correct values after the refresh?

Thank you very much for the help, all advice is greatly appreciated

[bobray]

See if this helps:

$setting->save(false);

It should tell MODX not to cache the setting.

[tulavu]

Thank you Bobray, it doesn’t help

[bobray]

How about this:

$modx->user->addMany( $setting, 'UserSettings' );
$modx->user->save();
// or $modx->user->save(false);

[tulavu]

sorry not

it is probably be something else elsewhere in my code

[bobray]

If there’s a snippet that displays the values, be sure to call it uncached:

[[!SnippetName]]

Also, use false for the cache flag argument in getObject(), getCollection(), etc.

[tulavu]

Thank you Bob, I’m gonna try this right now.

In the meantime I found a workaround but your solution would be better and cleaner.

I noticed the incorrect values occur only in the template with modx tags [[++mysetting]] and/or [[!++mysetting]].

However, the values fetched with the API are always correct:

$modx->log( modX::LOG_LEVEL_DEBUG,'TEST:'.$modx->getOption( 'mysetting', null, '', true )  
 ); 

Here is the workaround, I just save this value in a placeholder this way:

$modx->setPlaceholder('+mysetting', $modx->getOption( 'mysetting', null, '', true ) );

I try your solution now BobRay and I’ll post a feedback , maybe it could also help someone else to know what the cause of the issue was

[tulavu]

This is grand BobRay! It works fine now, the updated values are showing up properly:

$setting = $modx->getObject( 'modUserSetting', [
	    'key' => $key,
	    'user' => USERID,
], false );

[bobray]

I’m glad you got it sorted. It looks like maybe user settings are placed in the cache when the user logs in, and not updated even when modified ones are saved.

[tulavu]

In fact I thought it worked yesterday evening but this morning again this issue reccurs. My snippet is pretty complex with about two thousand lines and several conditional redirects after the submit. I am not 100% sure this is a modx issue, it is possibly in my code.

I am tracing my code line by line, if i find out something I will post the update here

If I don’t find I think i’m simply gonna set up a page refresh

[tulavu]

Here is what worked for me (i also implemented all what BobRay advised):

This did not show the uncached data:
[[!mySnippet]] and [[++my_user_setting]]

This now shows the uncached data:
[[mySnippet]] and [[!++my_user_setting]]

[bobray]

Is the snippet that sets the my_user_setting placeholder above the placeholder itself?

If not, it would explain your problem. In that case, your solution solves it by delaying the processing of the placeholder tag until after the snippet has run, but moving the snippet to the top of the page would also work and might be more reliable.

[tulavu]

Yes that is possibly the cause, the snippet is probably not called before the [[++my_setting]], i wil try this, thank you BobRay