Ce fil est résolu. Voici une description du problème et la solution proposée.
Problem:
When a Form is edited and the notification settings changed, do those changes apply to posts already created with the form?
Solution:
No, only newly created posts will have the new notification settings. The thread below describes custom code that could be run one-time after a Form has had its notification settings changed to update existing posts.
This support ticket is created Il y a 6 années et 2 mois. There's a good chance that you are reading advice that it now obsolete.
This is the technical support forum for Toolset - a suite of plugins for developing WordPress sites without writing PHP.
Everyone can read this forum, but only Toolset clients can post in it. Toolset support works 6 days per week, 19 hours per day.
Aucun de nos assistants n'est disponible aujourd'hui sur le forum Jeu d'outils. Veuillez créer un ticket, et nous nous le traiterons dès notre prochaine connexion. Merci de votre compréhension.
Les langues: Anglais (English )Espagnol (Español )
Fuseau horaire: Europe/London (GMT+00:00)
Hi Julie
I checked the database and saw that some data relating to the notification is saved with the post created with the form (with the key "__cred_notification_data"), so I suspect the answer to your question is no.
I ran a test to verify that, and found that older posts created with the same form do not trigger the same notifications (e.g. if you have a notification that is run whenever a post status is changed).
I think you would need to edit the older posts with an edit form that had the required notification settings, or it might be possible to run a script that copies the __cred_notification_data field from a new post to the old posts.
I don't know if that would work, the only way to know would be to try it and see.
Before raising this ticket, I checked the meta_value content for meta_key _cred_post_expiration_notifications which is where the email body content is stored and ran a couple of tests but needed to clarify whether this is expected or whether I might have an issue somewhere.
Whilst I'm relieved in one way that you're experiencing the same behaviour, I do feel this is a bit of a loophole and it really shouldn't be like this. It's natural to want or need to change email notifications periodically especially as a website matures all users should be receiving the same content in the emails received in a certain set of circumstances.
My biggest concern about performing what is essentially a manual update is that the data sits inside serialised data; one small error and a whole website is rendered useless. I do use an update script that can deal with serialised data BUT in my experience, it doesn't cope effectively when the existing and/or new data is beyond a certain length and the larger the site, the higher the risk that data is updated that actually shouldn't be.
Whilst I'd be happy to play around on a test site, having to perform such updates on a live site would be a totally different ball game. Email notification content not updating automatically for existing posts is a huge weakness. Even an extra step to achieve this inside Toolset would be an improvement.
I'd appreciate it if this could be escalated please (with a view to either providing Toolset users with foolproof instructions on how to do the update via a script or getting something built in to do it).
Les langues: Anglais (English )Espagnol (Español )
Fuseau horaire: Europe/London (GMT+00:00)
Hi Julie
There wasn't a great deal of appetite for changing this because it is unclear that updates to notification settings should unambiguously affect previously submitted content, and the developers are naturally wary of proliferating options.
So the best way to handle this would be a script to run when you make changes to a notification. After a post with the new settings has been submitted, you can simply copy the __cred_notification_data postmeta to other posts of the same type to update them.
I don't know if you need any help with that, you can use the standard get_post_meta and update_post_meta functions.
This week we should be releasing Types 3.1 which includes a built-in code snippet feature (so you won't have to add code to your functions.php file) which includes the option to run snippets one time only, which would be ideal for such a script.
you can simply copy the __cred_notification_data postmeta to other posts of the same type to update them
that might be OK for just a couple of posts but not if there are lots of them.
thank you that would be much appreciated - I'm not in a rush for a solution as the site is still being developed so please do prioritise other tickets.
In the meantime, just to let you know I tried updating some serialised data using an SQL update query but phpMyAdmin didn't like the contents. I've also noticed that once a post has expired, the meta_key _cred_post_expiration_notifications (and its meta-value) disappears from the database so I'm running a test to see what happens when an edit form with a cred-save_data hook to update the expiry date is submitted (particularly if the notification contents have changed in the meantime).
Les langues: Anglais (English )Espagnol (Español )
Fuseau horaire: Europe/London (GMT+00:00)
Hi Julie
Here's a snippet I used to copy the __cred_notification_data post meta from a source post (which would be a post you just published with the CRED form that has the new notification settings) to all other posts of the same type.
<?php
/**
* Copy post meta from one post to all other posts of that type
*/
$key = '__cred_notification_data';
$copy_id = 119; // post ID from which notification settings will be copied
$post_type = 'thing';
$copy = get_post_meta( $copy_id, $key, true );
$args = array(
'post_type' => $post_type,
'post_status' => 'any',
'numberposts' => -1,
'post__not_in' => array( $copy_id )
);
$pastes = get_posts( $args );
foreach ($pastes as $paste) {
update_post_meta( $paste->ID, $key, $copy );
}
In Types 3.1 we have a new Code Snippets feature (in Toolset > Settings) where you can add such code and you can leave it inactive and just run it on demand when you need to.
One last question: is it possible to add an additional argument to this: post type = thing and wpcf-custom-field value = XYZ (so the content of the source post is only copied to 'thing' posts where the value of custom-field is 'XYZ')? and what would the code then look like please?
Les langues: Anglais (English )Espagnol (Español )
Fuseau horaire: Europe/London (GMT+00:00)
I added those directly to the query args (as meta_key and meta_value), to be edited as required.
/**
* Copy post meta from one post to all other posts of that type
*/
$key = '__cred_notification_data';
$copy_id = 119; // post ID from which notification settings will be copied
$post_type = 'thing';
$copy = get_post_meta( $copy_id, $key, true );
$args = array(
'post_type' => $post_type,
'post_status' => 'any',
'numberposts' => -1,
'post__not_in' => array( $copy_id ),
'meta_key' => 'wpcf-custom-field',
'meta_value' => 'XYZ'
);
$pastes = get_posts( $args );
foreach ($pastes as $paste) {
update_post_meta( $paste->ID, $key, $copy );
}