Support

Account

Home Forums Front-end Issues Frontend WYSIWYG Problems

Solving

Frontend WYSIWYG Problems

    • tatemz

    • July 10, 2013 at 5:06 am

    I have a popup container in which the content is loaded dyamically via AJAX. On that page, I have acf_head() before everything. When a button is clicked, a WordPress AJAX callback function is run in order to print the acf_form() output within the popup container. It seems that the repeater fields are broken as well as any WYSIWYG fields… Thoughts?

    • tatemz

    • July 10, 2013 at 5:22 am

    For the record, there are no js errors on that page.

    • Elliot

    • July 10, 2013 at 2:20 pm

    Hi @tatemz

    The problem is that the replacement HTML coming back from the AJAX is not recognized by ACF. This is why it is not styled correctly / interacts correctly.

    You will need to re initialize the ACF javascript on the HTML. You can do this quite easily by running a jQuery action on the new DOM element like so:

    
    $(document).trigger('acf/setup_fields', $('#new-element'));
    
    • tatemz

    • July 10, 2013 at 2:40 pm

    Thank you for your response! That was my suspicion as well, however it seems that your suggestion is not working. I tried these two snippets within the success function of the AJAX request:

    $(document).trigger('acf/setup_fields', $('#id-of-container'));

    AND

    $(document).trigger('acf/setup_fields', $('#id-of-acf-form'));

    Neither of those worked… I will be honest and say that I would be considered a newbie at jQuery, so perhaps you could offer any more guidance? Of course we all thank you for the helpful support in these forums… it is definitely gracious and helpful.

    • Elliot

    • July 10, 2013 at 3:38 pm

    Did you get any JS errors in your console log?
    Did you match the ID of the code to the ID of the form element?
    Did you run this code after the new HTML had been returned?

    • tatemz

    • July 10, 2013 at 3:54 pm

    No JS errors on page. Success AJAX callback function does indeed run. (Is there any way to print JS errors from the AJAX request url?)

    Matched ID in JS acf/setup_fileds trigger to the $options[‘form_attributes’][‘id’] from when setting up form.

    Ran code after HTML was returned as well as attempted a 5000 milisecond timeout function to double check. (Not really necessary since the HTMl is returned before the AJAX success callback function is run).

    If you are familiar with Zurb Foundation, I am using this JS to return the HTML within the container DOM:

    LINK

    $(".reveal-popup-button").click(function(event) {
        event.preventDefault();
    
        $("#my-popup-container").foundation("reveal", "open", {
            url: ajaxurl,
            action: "my_popup_ajax",
            type: "POST",
            success: function(data) {
                $(document).trigger("acf/setup_fields", $("#acf-ajax-form"));
            },
            error: function() {
            }
        });
    });

    And here is my WP AJAX action:

    function my_popup_ajax_callback() {
        echo "<div id="my-popup-content">";
            $args = array(
                "post_title" => "Draft",
                "post_status" => "draft",
            );
    
            $id = wp_insert_post( $args );
    
            $html = my_popup_build_acf_form( $id, 12 );
    
            echo $html;
    
        echo "</div>";
        die();
    }
    add_action( "wp_ajax_my_popup_ajax", "my_popup_ajax_callback" );

    And the function that returns the form’s HTML:

    function my_popup_build_acf_form( $id, $fieldgroup ) {
        $options = array(
            "post_id" => $id,
            "field_groups" => array( $fieldgroup ),
            "form_attributes" => array(
                "id" => "acf-ajax-form"
            ),
            "return" => add_query_arg( "updated", "true", get_permalink( $id ) ),
            "html_field_open" => "<div>",
            "html_field_close" => "</div>",
            "html_before_fields" => "",
            "html_after_fields" => "",
            "submit_value" => "Submit",
            "updated_message" => "Post updated.",
        );
    
        ob_start();
        acf_form( $options );
        return ob_get_clean();
    }
    • tatemz

    • July 11, 2013 at 1:44 am

    Maybe it is worth more information, but I understand that “live” triggers are able to be used on DOM elements populated after the page has loaded. Likewise, I have set up some working code in order to close this created popup when the newly created ACF form is submitted.

    Also here is a helpful example for other users viewing this forum to submit their acf form with jQuery – works very nicely.

    $( "#acf-ajax-form" ).live( "submit", function( event ) {
        event.preventDefault();
    
        $(this).find('input[type=submit]').attr("disabled", true).val("Processing...");
    
        var formData = $(this).serialize();
        var formUrl = formData.return;
    
        $.post(formUrl, formData, function(response) {
            // Close the popup container
            $('#my-popup-container').foundation('reveal', 'close' );
    
            // Clear the HTML
            $('#my-popup-container').html('');
        });
    });

    Is there a way in which we might perform the jQuery trigger that you suggested above (acf/setup_fields) to mimic the “live” event?

    • Elliot

    • July 11, 2013 at 4:57 pm

    Hi @tatemz

    Your code above does not ever change the html of the ajax form.

    Where is the new HTML and how is it added to the DOM?

    • tatemz

    • July 11, 2013 at 5:13 pm

    Foundation handles the HTML population with their “reveal” module.

    See comment above.

    Here is the source for the trigger that I used in the code above.

    The AJAX callback and DOM creation begins on Line 144.

    My AJAX function is actually the parameter ajax_settings that is being used on Line 144 and Line 158.

    As a note – I can confirm that the popup does open and revel. I can also confirm that the HTML of the form from my WordPress AJAX callback does indeed fill the popup container. The popup container is the very first child in the <body> tag. And the acf_head() is at the very top of my HTML and is placed via the plugins_loaded hook with a priority of 1

    • tatemz

    • July 11, 2013 at 5:24 pm

    Perhaps a screen shot to display the problem… This is after the button has been pushed and the AJAX request has filled the now-visible popup container ( please excuse the poor CSS ).

    • Elliot

    • July 12, 2013 at 6:17 pm

    Hi @tatemz

    I am unable to debug this issue for you at the moment as it would require me to search through 3rd party code.

    Lets break down the solution into steps.

    1. Being able to alert something after the form has posted and the new HTML is appended to the DOM

    2. console.log the new DOM html container after it is updated

    3. Use the code I posted above to trigger the acf/setup_fields action on the new DOM element

    • tatemz

    • July 13, 2013 at 11:15 pm

    Thank you, Elliot for your previous help. I have come up with some more information. I understand that I am using some third party code, however I have tested this functionality with basic jQuery .post() methods. Each variant has the same result.

    Here is the status of the situation:

    • acf_form_head() is at the top of my file.
    • WordPress ajaxurl has been defined.
    • WordPress AJAX callback hooks are defined and working.
    • A button triggers the AJAX callback and appends the result to a DOM element.
    • On a successful WP nonce verification and AJAX callback, the HTML for an acf_form() is populated but the ACF WYSIWYGs are not correctly initialized.
    • It seems that the acf/setup_fields trigger performs successfully as the media uploaders and location fields initialize their scripts successfully.

    I edited your wysiwyg.js file to deliver some debugging information:

    // validate tinymce
    if( ! _wysiwyg.has_tinymce() )
    {
    	console.log( "FAILED TO VALIDATE TINYMCE" );
    	return;
    }

    This indeed returns a failure on the initial page load (as there are no ACF forms or WYSIWYGs). However, even after the AJAX callback has successfully completed, a failure is returned for the number of WYSIWYGs in the form. I am dumb when it comes to anything about tinyMCE. I tried an attempt to solve this within the AJAX success callback (before the `acf/setup_fields’ trigger):

    $('.acf_wysiwyg textarea').each(function() {
        tinymce.execCommand('mceAddControl', false, $(this).attr('id'));
    });

    Suggestions or thoughts? I absolutely love ACF and use it for many of my client’s projects (love the repeater fields). I would love to help you solve this issue for future users, so in the meantime, I will be diving into your source and seeing if I can come up with a solution. Feel free to offer your suggestions and move on. I will simply keep posting my findings here for other users (and hopefully we can get some community support on this issue).

    • tatemz

    • July 13, 2013 at 11:35 pm

    Removing the tinyMCE validation throws this error:

    Uncaught ReferenceError: tinyMCE is not defined

    Naturally I included wp-includes/js/tinymce/tiny_mce.js and got this error:

    Uncaught TypeError: Cannot set property 'theme_advanced_buttons1' of undefined

    Diving deeper…

    As a first attempt, since the errors produced are due to ACF attempting to reset tinyMCE settings, I tried simply commenting out the lines that reset the settings, thus throwing this error.

    • Elliot

    • July 14, 2013 at 5:31 pm

    Hi @tatemz

    Seems like you may need to do some in depth debugging and perhaps hire a freelance dev to help you out on this one.

    I would love to, but I have my hands full at the moment tending to the support forum and working on the ACF plugin.

    I hope you find the issue and can fix it quickly

    Cheers
    Elliot

Viewing 14 posts - 1 through 14 (of 14 total)

You must be logged in to reply to this topic.

We use cookies to offer you a better browsing experience, analyze site traffic and personalize content. Read about how we use cookies and how you can control them in our Cookie Policy. If you continue to use this site, you consent to our use of cookies.