danidada

Hello, thanks for your reply Amin and sorry for my delay.
I understand your mention about the custom coding being out of scope, but let me just correct one thing in your reply: you wrote “If only the modified field is injected using array_replace(), the notification conditions will not have the complete context of the submission” but in here

Forminator_Front_Action::$prepared_data = array_replace( Forminator_Front_Action::$prepared_data, $submitted_data );

$submitted_data is extracted from the entry

private function data_from_enty( $entry ) {
        	$post_data = array();
        	foreach ( $entry->meta_data as $key => $meta ) {

        		if ( ! isset( $meta['value'] ) ) {
        			continue;
        		}
        		$post_data[ $key ] = $meta['value'];
        	}
        	return $post_data;
        }

so it contains all data, not only the edited one.

The only way I’ve found to workaround the problem is to manually remove the conditions in the notifications ( in $custom_form->notifications before passing it as the first parameter of $forminator_mail_sender->process_mail ) but I don’t really like it (although it works) so if I need to pass the context as you said with another call like you wrote, could you enlighten me? Because I didn’t find any of it in the code.

Thanks again

Hello Patrick,

I am using the class and function you mentioned but the data sent in the notification is the “old” data, not the updated entry data. I have used the same code as in the plugin.

                    // this one is the code updating the field value 
Forminator_API::update_form_entry( $form_id, $entry_id, array( array('name'=>'hidden-3', 'value'=>"si") ) );

                    $error = '';

                    if ( isset( $entry_id ) ) {

                        $forminator_mail_sender = new Forminator_CForm_Front_Mail();

                        $entry                  = new Forminator_Form_Entry_Model( $entry_id );


                        if ( empty( $entry->form_id ) || ! empty( $entry->draft_id ) ) {

                            $error = esc_html__( 'Entry ID was not found.', 'forminator' );

                        }

                        $module_id = $entry->form_id;

                        Forminator_Front_Action::$module_id     = $module_id;

                        Forminator_Front_Action::$module_object = Forminator_Base_Form_Model::get_model( $module_id );

                        // Emulate Forminator_Front_Action::$prepared_data.

                        Forminator_Front_Action::$prepared_data = recreate_prepared_data( Forminator_Front_Action::$module_object, $entry );

                        // Emulate Forminator_Front_Action::$hidden_fields.

                        if ( ! Forminator_Front_Action::$module_object ) {

                            $error = esc_html__( 'Error: Module object is corrupted!', 'forminator' ) ;

                        }

                        Forminator_Front_Action::$module_settings = method_exists( Forminator_Front_Action::$module_object, 'get_form_settings' )

                        ? Forminator_Front_Action::$module_object->get_form_settings() : Forminator_Front_Action::$module_object->settings;

                        Forminator_CForm_Front_Action::check_fields_visibility();

                        $module_object = Forminator_Base_Form_Model::get_model( $module_id );
// printed data is the updated one
                        var_dump($entry);
//data sent by mail is the old one
                        $forminator_mail_sender->process_mail( $module_object, $entry );

Thanks, please update this thread when it will be fixed and released.

I’m just adding a detail: I could restrict the block to the custom post type, but the issue was to allow its use inside the fse template for the custom post type because I’m registering it through “acf_register_block_type” and using the parameter “post_types” doesn’t let me have it available inside the template editor.

Hello! Yes there is not option on my editor:

It’s a custom FSE theme and these are the plugins installed:

I found a workaround that fix the problem:

enabling the delay initialization and forcing visual mode only it loads it as code and on click inside the area display it properly with editing fully working.

Sorry to have open this as a conflict of Premium Blocks plugin when it was not the culprit because it’s a wp bug.

ps. can I ask something that’s not related to this issue? For the Icon Block can the standard icons be replaced with a filter to load only custom icons?

• This reply was modified 8 months ago by danidada.

Sure!

I have added unuseful details probably cause I think it’s not related to the theme but it’s between the SFC (https://it.wordpress.org/plugins/secure-custom-fields/) plugin, when on a page there is a field type Editor WYSIWYG (attached photo) and the plugin Premium Blocks for Gutenberg is active (without placing any blocks and enable/disable settings doesn’t make any difference) than in the page editor that field type is not editable in Visual mode but only on Text mode. If you edit it on Text mode and than switch back to Visual mode it’s white empty and the console shows that error.

Attached screenshots, hope this helps.

Here, i change the sensitive data:

https://pastebin.com/BZ15JkgH

Here two screenshots: https://ibb.co/k089k6P, https://ibb.co/T4xLXd2
now the form shared on pastebin it’s set as “none” for expiration because it wasn’t updating the date, as you can see in the next screenshot the message has 23 as date but the datepicker is 20 (the old date)

• This reply was modified 1 year, 7 months ago by danidada.