Support

Account

Register Login

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

Search Results for 'Wysiwyg'

reply

  • There are some answers to this here https://wordpress.stackexchange.com/questions/325271/generate-a-excerpt-from-an-acf-wysiwyg-field

  • Since this topic still has some attention I came back to share my solution. I misunderstood the way of making a more simple toolbar. The current solution suites my needs:

    
if (class_exists('acf')) {
  add_filter('acf/fields/wysiwyg/toolbars', 'wysiwyg_toolbars');
}

function wysiwyg_toolbars($toolbars) {
  $toolbars['Very Very Simple'] = array();
  $toolbars['Very Very Simple'][1] = array('bold', 'italic', 'underline', 'strikethrough');

  $toolbars['Very Simple'] = array();
  $toolbars['Very Simple'][1] = array('bold', 'italic', 'underline', 'strikethrough', 'link');

  return $toolbars;
}

    After that, you can assign the field type to your designated field, just like you normally would do.

  • There is also a wysiwyg_tinymce_init action

  • You should be using the field key specific version of the filter rather than the generic field type version acf/load_field/type=wysiwyg

    If this is not possible then you should use the acf/prepare_field filter for specific fields.

  • I haven’t tested if this works in Gutenberg yet, but works great in the classic editor. https://support.advancedcustomfields.com/forums/topic/resrict-valid-formats-in-wysiwyg-editor/

  • When a post is set up WP does (or should) a single query to get and cache all of the postmeta fields for the post. These queries are based on the Post ID which is an indexed column in the DB. The number of queries should not be increased by the number of fields unless there is something else going on.

    Additional fields will increase the time it takes to do this one query but that time should not effect a single query more than a few milliseconds depending on what kind of content is being returned. It is possible, but it would be an extreme case. For an example of something that could effect performance here think about a page with 250 WYSIWYG fields with several paragraphs of content in every one of those fields. Let’s say that fields average of 1000 characters that equates to 250 X 1000 = 250,000 characters being returned by the DB and this can mean anywhere from 250K to almost 1MB of UTF8 data. Of course this is an exaggeration to make a point.

    There are things in ACF that will increase the number of queries, but this has to do with the formatting of the returned values. For example returning an array from image fields and galleries. Or returning post objects from relationship type fields.

  • +1 to infinity and beyond – we have so many fields that need the WYSIWYG field not for sheer quantity of text but for the style options the editor provides.

    An older javascript hack floating around doesn’t seem to cope with flexible content fields either…

  • Hi @elliot, this solution didn’t work in my situation, unfortunately.

      <?PHP
    $content = get_field('wysiwyg', false, false);
    echo apply_filters('the_content', $content);
   ?>

    It destroys the output of the wysiwyg, displaying nothing.

    I have the plugin Simple Lightbox installed, which I want to use for the gallery’s lightbox.

    Previously, I was using:

      <?PHP
     the_sub_field('wysiwyg');
   ?>

    To output the wysiwyg normally.

    Help appreciated.
    Steve

  • Yes, I can, I think.

    What worked for me is to get the name of the custom field from ACF. Then I placed the name of this field inside square brackets in the region I wanted it to display — like a shortcode. And just like that, the full HTML content from the WYSIWYG field showed up.

  • You have it exactly. Our clients want to be able to add and move around various elements but they want each of the same type of element to work and look exactly the same every time they are used and they don’t want their employees putzing with design elements and they also don’t want to put many hours into training them on their company’s design guidelines.

    The issue with dealing with React is that it is a completely different development process that increases dev time, especially when you have a team of one. When you’re in a business where you need to deliver a web site at an affordable price, and withing a short timeframe, increasing the development time increases cost to the client and increasing cost to the client means that you do not sell custom web development.

    Many developers, from what I’ve seen and read, are either doing what I’m doing, using some other page building plugin/application for WP, or they are just leaving and many that can do so are going to ClassicPress. I would do the same but the company I work with also depends on several plugins that will not work in ClassicPress and there isn’t any plans to make them work, so I’d have to build anything that I need, once again increasing cost that we need to find a way to pass on to the client. Yes, there are some people using blocks and they are using ACF to help them achieve this because Elliot has taken part of the pain out of the equation by adding blocks capabilities to ACF. My biggest issue with doing this is the fact that my clients are businesses that usually need advanced sorting and filtering capabilities and blocks store all of their content in the “post_content” row of the post, making sorting and filtering based on these fields nearly impossible without jumping through a lot more hoops.

    The thought of WP dropping the classic editor is why I don’t use it. WP includes a classic block, this means that as long as this exists TinyMCE will be a part of WP. As long as TinyMCE is part of WP there will always be a WYSIWYG editor in ACF.

    As far as the viability of the flex field. The biggest reason that ACF Pro is popular is because of the repeater. A Flex field is actually a fancy repeater that allows different sub field for each row. While a Group field is actually a cut down version of a repeater that always has exactly one row. If you take the repeater out of ACF then there’s really no Pro. The death of the repeater would likely mean the death of ACF.

  • This is an OLD question, but I stumbled upon it when trying to answer how to add items to the pre-defined Basic menu. Here is the code I’ve used, which was written using the information found at ACF.

    /********************************
ADD ADDITIONAL TOOLBAR SET TO ACF WYSIWYG
********************************/
if ( function_exists( 'get_field' ) ) {
  add_filter( 'acf/fields/wysiwyg/toolbars' , 'qd_toolbars'  );
  function qd_toolbars( $toolbars )
  {
    //INJECT/ADD AN OPTION INTO THE BASIC TOOLBAR
    $toolbars['Basic' ][1] = array_merge( array_slice( $toolbars['Basic' ][1], 0, 3, true ), array( 'subscript','superscript' ), array_slice( $toolbars['Basic' ][1], 3, null, true ) );

    //FIND MORE INFO ABOUT THIS OPERATION AT http://www.advancedcustomfields.com/resources/customize-the-wysiwyg-toolbars/
    // Add a new toolbar called "Very Simple"
    // - this toolbar has only 1 row of buttons
    $toolbars['Very Simple' ] = array();
    $toolbars['Very Simple' ][1] = array('bold' , 'italic' , 'underline', 'link', 'unlink' );

    // return $toolbars - IMPORTANT!
    return $toolbars;
  }
}

  • I am not the developer, I just work here on the forums answering questions, but I do know a lot about ACF.

    There are a lot, and I mean A LOT, of developers like me that will avoid moving to gutenbug. The reason for this is that my clients do not want be able to edit how content looks on the site. All of my clients are larger companies where every page must look like every other page, every paragraph must look like every other paragraph. If they add an image gallery then every gallery must look and work identically. Most of the time those that are adding the content are not the site owners but people that my clients hire to do the content adding and they do not want or need these people to have any ability to alter the look and feel of anything. I also do not use classic editor even for simple page content. My feeling here is that ACF will always include a WYSIWYG field and this it what my clients want to use. All of my clients are used to using Word Processors and this is how they want to edit pages.

    I do not foresee either the flex field or the WYSIWYG field going anywhere any time in the near future.

    But like I said, I’m not the developer, just the guy that works this forum. To get an answer from the developer you’d need to contact him, he does not spend a lot of time on this forum, that’s why I’m here so that he can concentrate on fixing and improving ACF. You can try contacting him here https://www.advancedcustomfields.com/contact/

  • Hello,
    this is console output in page edit with wysiwyg editor custom fields:

    
This page uses the non standard property “zoom”. Consider using calc() in the relevant property values, or using “transform” along with “transform-origin: 0 0”. post.php

JQMIGRATE: Migrate is installed, version 3.3.2 load-scripts.php:5:709

MouseEvent.mozPressure is deprecated. Use PointerEvent.pressure instead. 2 wp-tinymce.js:3:8856

    Nothing else appears there even during custom fields editing.

  • I can confirm this bug. Enabling the classic editor plugin did in fact fix the bug, but for only the ‘first’ WYSIWYG custom field. Additional WYSIWYG fields lost the editor buttons? And there’s still a weird bug hiding the content unless you toggle back and forth between the Visual and HTML editors.

    Thanks for all of your work on this amazing plugin!

  • Yes. Same issue. If I set my custom field to WYSIWYG, go to create a post with the field, switch the WYSIWIG editor from Visual to text and paste my iframe code in, when I switch back to visual, I see the rendered iframe content. However when I go to the front end, the iframe content doesn’t display. OTHER text like <h3>A Related Product</h3> WILL display, but the iframe code is stripped out.

  • Hi,

    Actually, clearing the Firefox cache was just a temporary fix. The problem is back today even for WYSIWYG custom fields that worked correctly after the cache clearing I made yesterday.

  • Hello Everyone, I was facing the same issue, trying to include a read-more button on a textarea field, I tried to switch it to wysiwyg and then create the read more, but it created unwanted p tag. I use javascript-plugin oriented solution instead and not a PHP/Wordpress oriented solution.

    i’m using this Readmore.js plugin
    https://github.com/jedfoster/Readmore.js/tree/version-3.0

    Which we can configure with 2 steps:
    1 – adding specific class to the the field we want to add the read more (textearea in my case)
    2 – write the script for the readmore-js to work

    // My selector where my textarea field is included
const readMoreParagraphs = document.querySelectorAll('.item-texte');

new Readmore( readMoreParagraphs, {
    speed: 200,
    collapseHeight: 20,
    lessLink: '<a href="#" class="read-more">Read less</a>',
    heightMargin: 16,
    moreLink: '<a href="#" class="read-more">Read more</a>',
});

  • See this page about format value filters, it has an example of using shortcode in fields other than wysiwyg fields https://www.advancedcustomfields.com/resources/acf-format_value/

  • The only thing that I can do to help you is to tell you what the data in an ACF field is, but I cannot tell you how to get this data to work in Elementor.

    Elementor bypasses ACF functions and pulls the data directly from the database. Because of that there isn’t any way for ACF to do what it needs to do to format the values correctly the way it would do when calling acf function like get_field().

    A WYSIWYG field holds content like the main content editor. Elementor would have to apply “the_content” filters to that content for get it formatted correctly.

    To use a shortcode Elementor would have to call do_shorcode() on the content of the field.

    Like I said, I can tell you the data stored in the DB for each type of field, but the only place you’re going to get an answer to how to use that data is by getting help with Elementor.

  • I can only assume that you have a group field called “bakgrund” and “del1” is a wysiwyg field sub field of this group.

    getting the field should format the wysiwyg sub fields

    I am lost as to why you are doing this

    
$infostring1 = html_entity_decode($background['del1']);
$infostring1 = preg_replace("/\s/",'',$infostring1);
$infostring1 = htmlentities($infostring1);

    as it is removing all of the html formatting applied to the wysiwyg field.

    Why are you not just using echo $background['del1'];

  • I am trying to make it work with qtranslate So I disabled qtranslate and the ACF WYSIWYG field works well even if the error still appears in js console. I am having similar issues when ACF Pro and the EasyRecipe plugin is installed

  • Hey @wpfreshysites-com

    Yes, you could this by target the proper field type:

    // ACF > WYSIWYG — Custom Toolbar
	add_filter( 'acf/fields/wysiwyg/toolbars', function ( $toolbars ) {

		// Unset Basic Type Toolbar
		unset( $toolbars['Basic'] );

		// [1] formatselect. bold, italic, bullist, numlist, blockquote, alignleft, aligncenter, alignright, link, wp_more, spellchecker, fullscreen, wp_adv
		// [2] strikethrough, hr, forecolor, pastetext, removeformat, charmap, outdent, indent, undo, redo, wp_help

		// Register a basic toolbar with a single row of options
		$toolbars['Full'][1] = [ 
			'formatselect',
			'fontsizeselect',
			'bold', 
			'italic',
			'alignleft', 
			'aligncenter', 
			'alignright', 
			'bullist',
			'numlist',
			'link', 
			'unlink',
			'forecolor',
			'hr',
			'removeformat'
		];
		$toolbars['Full'][2] = [];
	
		return $toolbars;
	});

  • If you want to use a single wysiwyg field then my recommendation would be some type of shortcode plugin that allows creating columns.

  • https://stackoverflow.com/questions/64859175/how-add-custom-button-to-acf-wysiwyg-tinymce OR https://ru.stackoverflow.com/questions/1205445/Как-создать-свою-кнопку-для-acf-wysiwyg-tinymce

  • Not sure if this will help you, and I have not done this with WC.

    Some time ago I decided, not long after guberbug gutenberg was released that I would not be using it. I also at that time decided that I will not be using the standard “Classic Editor” area for content. The reason for this is that there is no guarantee that classic editor will continue to be supported. However, I believe that ACF will always include a WYSIWYG field that uses tinyMCE. I also believe that there will always likely be a way to disable the new editor.

    So, I remove all editors. I am currently using classic editor to disable the new editor and I use ACF to hide the default content field and I create my own custom fields that includes a field for the content if the post type calls for such a field.

    Depending on what I am doing I either just show this field in the template instead of “the_content()” or I create an acf/save_post action that copies this content into “post_content”. For use with WC I would likely go with the second option of copying the content to the standard location because that way I would not need to mess about with WC templates in order to use my custom field.

    In your case I would likely have two fields in one group, “Full Descriptiosn” and “Short Description”

Viewing 25 results - 301 through 325 (of 1,301 total)
1 2 3 … 12 13 14 … 51 52 53