Support

Account

Register Login

Home › Forums › Search › Search Results for 'Wysiwyg'

Search Results for 'Wysiwyg'

reply

  • That’s unfortunate inner-blocks isn’t supported yet. Like you, in the meantime I had to settle for using WYSIWYG editors inside of my columns.

    For my column layout, I went with a repeater and styled them to be horizontal. I widened the content area so there is more room to work inside each column, it works out pretty good. I also added a button group for different column layouts and then use JS to automatically resize the column widths based on the layout selected.

    Overall I guess I am happy with it.

    column layout

  • Elliot is going to look into inner-blocks later on this year, my guess is Nov/Dec… In the meantime what I have done to create my own columns, have each column in Accordion fields, and for the content of the columns use the WYSIWYG editor. I can get away with it, becaus so far all of my 41 blocks, are conversions from my preexisting shortcodes. And because TinyMCE displays the button to generate the shortcodes, it works pretty well. Also because I’m using accordions, I’m actually building the columns vertically, which give me more room to edit things. The biggest drawback is that if I want to change the layout (ie: from 3 columns to 4 columnjs), I have to delete the 3 column block and start a new 4 column block…

  • Hi John,

    Thanks. I appreciate the basic info, though perhaps I have understated my experience level. I’m more an intermediate-level coder with respect to both WordPress and PHP; I understand the basics of both, but still have to look up a lot of things like filters and actions or PHP functions and precise parameters as I more often than not need a refresher.

    So, I definitely do know which template I’m using for the page in question already. I can tell in the page editor, and it’s a template I wrote the PHP file for myself. Other fields and custom fields are working fine, including not only the built-in WYSIWYG editor but 3 other ACF fields. Only the ACF WYSIWYG field is not displaying anything.

    I’ve also tried echoing the problematic ACF field both inside and out of the loop, to no avail.

    Maybe a code snippet would be helpful. Here’s my template PHP file’s contents (page-feature.php). The $subtext variable (get_field(“additional_subtext”)) is the problematic field; the other three fields all work fine ($heading and $button_text are ACF Text fields, $btnLink is an ACF Link field).

    <?php
/**
 * Elegant Simplicity Theme: Feature Page Template
 *
 * This template is...
 *
 * Template Name: Feature Page
 *
 * @link https://developer.wordpress.org/themes/basics/template-hierarchy/
 *
 * @package Elegant_Simplicity
 * @since 5.2.0
 */

        get_header();

        $heading = get_field("heading");
        $btnText = get_field("button_text");
        $btnLink = get_field("featured_link");
        $subtext = get_field("additional_subtext");
?>
        <h1 class="cover-heading"><?php echo $heading; ?></h1>
<?php   while (have_posts())
          {
          the_post();
          get_template_part('template-parts/content-featurepost', 'page');
          }
?>      <p class="lead"><a href="<?php echo $btnLink; ?>" class="btn btn-lg btn-outline-secondary"><?php echo $btnText; ?></a></p>
<?php   if (!isset($subtext) || '' === trim($subtext))
          {
          echo $subtext;
          }

        get_footer();
?>

    Thanks!

  • Hi, i got the same problem.
    no matter which acf field i use (textarea or wysiwyg editor) in the field group, all the postet html tags (for example an iframe) gets deleted when i save the page.
    that’s only happening on my server setup not on my localhost.

    can you tell me what i need to change on my server?

  • Just checking back in on this to say that this still happens with other form plugin shortcodes as well (Mailpoet, Formidable), and only when used in an ACF wysiwyg field. It seems the issue is that BR tags are added below each hidden field in the form, thus creating a bunch of empty lines above and below the form. Again, this does not happen in the native WP editor — only ACF. This happens with any theme I try. Has anyone had any success with fixing this problem?

  • Alright, I’m documenting this in case anyone in the future needs it. Took extra care to put the right search terms in the thread title, etc.

    Here’s what I got working. Don’t use acf/update_value. You want to use ‘acf/save_post’.

    Next, in functions.php, for some reason using `if( if_page_template(”) )’ was not working at all. It was causing the field to be deleted.

    But you had to “qualify” it in some way to make sure you’re only running on the right custom post template. So what I did was a check to see if the field I’m copying from exists, and it ONLY exists on that custom post template. So that check works out.

    Here’s the code:

    // Take the first WYSIWYG ACF field and copy it into the_content() in order to populate the_excerpt()
function my_acf_copy_content( $post_id ) {
  if ( get_field('acf_site_text_box_top') ) {
    $value = get_field('acf_site_text_box_top');
    wp_update_post( array( 'ID' => $post_id, 'post_content' => $value ) );
    return $value;
  }
}
add_filter('acf/save_post', 'my_acf_copy_content', 20);

    Be careful because without the qualifier, it flat out deletes your entire post on any post not using that custom field, which you then have to retrieve from the revisions.

  • Sorry to bump this thread like this.

    So my attempt above in the functions.php, while wrapped in the is_page_template() didn’t copy to the_content(); It actually just wiped that WYSIWYG box entirely, deleting the content from it.

    I removed the IF is_page_template(); and it worked though…

  • Thanks John but that’s not the issue. This was not happening before 5.8. I rolled back to 5.7.13 and it then worked perfectly again. Also the main WP content field works fine as well on 5.8 and doesn’t remove the p tags. So it’s definitely just the ACF WYSIWYG field.

    I also already have TinyMCE Advanced installed with the appropriate settings and have the issue. Tried deactivating that too just to see if it was conflicting and still the same issues.

  • The WYSIWYG field uses the built in TinyMCE/WP editor. This is something that this editor has always done. You need to install another plugin to prevent this from happening. https://wordpress.stackexchange.com/questions/137968/wordpress-removing-p-tags

  • Here’s another question, if you are going to build guberbug blocks then why on earth would you need an ACF field that emulates the guberbug editor? It’s going to eventually let you edit “side bars” or whatever they end up calling them, so there will be no real need to have different sections of blocks. The plan is to make the entire front end page editable with the new editor, meaning that there is no real reason to have separated “sections” to edit.

    Why would you need another instance of the block editor?

    And another question, why would you put a WYSIWYG editor into an ACF block built to work in guberbug? Wouldn’t you just create text fields, text area fields, and other types of fields and then format those fields in the block to appear the way they need to appear?

    Are you asking, will ACF let you nest the block editor inside of itself? Why would you do this? Wouldn’t you just create multiple “blocks”?

    After thinking about this for a while the entire question confuses the hell out of me as to what use it could serve.

    Granted, I’m on the other end, I dislike guberbug and I feel it is a bad decision. That is based on knowing the types of clients I serve and what their needs are. The last thing my clients want is for any editor to be able to putz around with the site design. I plan to built in 100% ACF fields.

    But I’m still paying attention to what’s going on and where this disaster is headed.

    Please explain what purpose this could serve?

  • My hope is that ACF will not use guberbug to replace the wysiwyg editor. If anything I would think this will be a new type of field, if it is added. In any event. I seriously doubt that Elliot will remove the old style wysiwyg field from the field types no matter what happens with WP. The field may need to be changed, but it should still be there.

  • Would also like to know if there’s any plan to have the Gutenberg editor applied to WYSIWYG fields.

  • Situation & Problem
    I’m implementing a custom admin page that gets ACF fields based on a selection.
    Everything is working fine, including the showing and saving of the fields.

    However, after a field is loaded using Ajax, certain JavaScript functionalities are not working:

    • In a repeater field, the add row button does nothing, it also shows nothing in the console when clicked.
      According to my browser a click event IS bound to it from acf-input.js:
      return a.apply(b || this, c.concat(e.call(arguments)))
    • In a wysiwyg field, the Visual button does not work. When clicked it shows the following error in the console: TypeError: r is undefined [tinymce.min.js]

    Am I maybe supposed to perform a JavaScript call to initialise the newly loaded fields? Or is there something wrong with my implementation of ACF?

    Info on my implementation
    Initial page load
    On initial page load I run acf_enqueue_scripts(); to load all ACF scripts/styling.

    Getting fields with Ajax
    On the page when a selection is made, an Ajax call is made to a custom route which performs the following to get the fields HTML:

    
// get fields based on group key received from POST request
$fields = acf_get_fields(['key' => $key]);

// render fields, and use output buffering to catch the HTML
ob_start();
acf_render_fields($fields, 'my-page');
$fields_html = ob_get_contents();
ob_end_clean();

return $fields_html;

    Which successfully returns the required HTML to the page.

    Saving Fields
    I very simply perform a POST with all the fields to a route which performs the acf_save_post('my-page') function.
    This function gets the fields from the request and saves them, which works wonderfully.

  • @acf-support forgive me for resuming an old post, but it would seem the fields get confused script-wise if they have the same name.

    I encountered the need to copy all ACF fields from a group_a of a post type type_a to a group_b of a post type type_b due to an analysis mistake.

    So, let’s consider this code snippet

    
        if ($tecnologie = get_field('tecnologie', $post->ID)) {
            $tecnologie_new = '<ul>';
            foreach ($tecnologie as $tecnologia) {
                $tecnologie_new .= '<li>';
                $tecnologie_new .= $tecnologia['tecnologia'];
                $tecnologie_new .= '</li>';
            }
            $tecnologie_new .= '</ul>';
            update_field('tecnologie', $tecnologie_new, $new_id);
        }

    Here, $post is of type type_a and $new_id is the ID of a new post I created of type type_b. In both field groups there’s a field called tecnologie, which is a Repeater in the first type and a WYSIWYG Editor in the second. I basically need to turn the repeated rows into a <ul> tag.

    Post type_a field group, field tecnologie:

    Post type_b field group, field tecnologie:

    The above script returns an error:
    ( ! ) Warning: Invalid argument supplied for foreach() in (…)\wp-content\plugins\advanced-custom-fields-pro\pro\fields\class-acf-field-repeater.php on line 844

    Because the type of field the plugin considers is the Repeater, despite the required update is on the WYSIWYG.

  • @acf-support forgive me for resuming an old post, but it would seem the fields get confused script-wise if they have the same name.

    I encountered the need to copy all ACF fields from a group_a of a post type type_a to a group_b of a post type type_b due to an analysis mistake.

    So, let’s consider this code snippet

    
        if ($tecnologie = get_field('tecnologie', $post->ID)) {
            $tecnologie_new = '<ul>';
            foreach ($tecnologie as $tecnologia) {
                $tecnologie_new .= '<li>';
                $tecnologie_new .= $tecnologia['tecnologia'];
                $tecnologie_new .= '</li>';
            }
            $tecnologie_new .= '</ul>';
            update_field('tecnologie', $tecnologie_new, $new_id);
        }

    Here, $post is of type type_a and $new_id is the ID of a new post I created of type type_b. In both field groups there’s a field called tecnologie, which is a Repeater in the first type and a WYSIWYG Editor in the second. I basically need to turn the repeated rows into a <ul> tag.

    Post type_a field group, field tecnologie:

    Post type_b field group, field tecnologie:

    The above script returns an error:
    ( ! ) Warning: Invalid argument supplied for foreach() in (…)\wp-content\plugins\advanced-custom-fields-pro\pro\fields\class-acf-field-repeater.php on line 844

    Because the type of field the plugin considers is the Repeater, despite the required update is on the WYSIWYG.

  • The size of the image may slow it down.

    You also have 4 date and/or time fields, times 60 rows, that’s 240 date/time fields that need to be initialized and these types of field do not offer the delayed initialization option. This is likely a contributing factor.

    Repeaters (and flex fields) are great, to a certain point. The pitfalls of using them for large amounts of data is something that has to be experienced. So that you know, I’m not knocking the way that you built this feature, I have been here. I once created a page editor for a client using a repeater for “sections” and each “section” could have up to 10 wysiwyg fields plus other associated fields. Everything was fine until the day they tried to create a page with 25 sections (250 WYSIWYG editors + other fields). Even delayed initialization did not help me as saving the page also timed out. I ended up rebuilding the CPT using “child” posts for each section.

    I don’t really have any good advice that will help.

  • Thanks John, that’s a good tip but no sir, I’m not using any WYSIWYG fields. Attached is a screenshot of what one repeater row looks like when editing the post.

    repeater-row....jpg

  • Are you using a lot of WYSIWYG fields? If you are set them to delayed initialization.

  • Hi Elliot,

    I have simmilar problem. After update WP to 5.1.1 and WooCommerce to 3.5.7 and ACF free to ACF pro, my custom fields had values. On the frontend WYSIWYG fields are cropped (one or few chars), after first save of the product, the content of the custom fields dissapears. New content inserted into CF’s doesn’t save…
    Could you please help me with this case?

  • @rrmeines it shouldn’t (in theory) make a difference how the wysiwyg field is being inserted since the ‘acf/init’ hook fires after ACF is loaded, so wpautop should be removed for any fields that use it.

    Maybe there is something else that is using the native ‘the_content’ filter which is overriding the acf filter?

    I’ve never tried using wysiwyg in a repeater or flexible context though, so that might be related to the problem you’re having.

  • Hi I can’t get this to work. I am using this code in my functions.php:

    function my_acf_add_local_field_groups() {
  remove_filter('acf_the_content', 'wpautop' );
}
add_action('acf/init', 'my_acf_add_local_field_groups');

    I am using wordpress 5.1.1 and using ACF PRO 5.7.13. I am using WYSIWYG fields inside a flexible content field. So I am using <?php the_sub_field('name_subfield'); ?> in my .php file

    Does anyone know if this is due to an update or if this never worked?

  • For those who would like to strip p tags, but keep br tags (or other tags), you can process the output of the field with strip_tags like so :

     $field = get_field('my_wysiwyg_field');
$formatted_field = strip_tags($field, '<br>');
echo $formatted_field; ?>

    Simple, yet effective

  • I like to switch between product specs, when i change product variation.
    I should be nice if it is below the Description of Woocommerce.

    For example see Philips Lighting website.
    I want the specs of a LED Light switching when i change variation.
    Per lamp another specs below of the Description or a Tab.
    A table with with specs, copy and paste.

    Problem: When i make Product Type is Equal to Product Variation (WYSIWYG Editor). I don’t see the Editor at the Product Variation position.

  • Got a bit more info — it seems like the fields actually display correctly if I *dont* have the fields registered on my child sites. On sites that don’t have the fields, the main site data comes through correctly, but on sites that do, the main site data is misformatted.

    EDIT: Or maybe not, it just seems super sporadic. I just re-enabled the fields on all sites, and nothing changed. It seems like not all fields are affected on all sites, it’s like a random mix of some fields working and some not… I have a WYSIWYG field that’s working fine on 4/5 child sites, but unformated on 1, and a repeater that doesn’t work on any. Very odd.

  • Hi there,

    The snippet that darrengrant posted works great:

    add_filter( ‘tiny_mce_before_init’, function( $settings ){
    $settings[‘block_formats’] = ‘Paragraph=p;Heading=h2;Subheading=h3’;
    return $settings;
    } );

    Though it applies to all wordpress wysiwyg’s. Is there a way to limit it to ACF wysiwyg fields only?

    Cheers,

Viewing 25 results - 376 through 400 (of 1,298 total)
1 2 3 … 15 16 17 … 50 51 52