Support

Account

Register Login

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

Search Results for 'Wysiwyg'

reply

  • Are you using ACF4 or 5?
    Do you have both the visual and text tabs available on the WYSIWYG field?

  • What version of ACF are you using?

    For the most part the ACF WYSIWYG editor works the same as the standard WP WYSIWYG editor, meaning that it automatically adds <p> and <br /> tags where it thinks it needs them.

    Here’s an older topic where the developer talks about this and ways that it can be removed. http://support.advancedcustomfields.com/forums/topic/removing-paragraph-tags-from-wysiwyg-fields/

  • Did you include the echo do_shortcode(); wrapper around the acf get_field(); text field? The ACF WYSIWYG field automatically runs shortcodes on the content. All other types of fields you have to do it yourself. You also need to use ‘get_field();and notthe_field();` because the former returns the values and the latter echos the value.

  • This can be done with a repeater field which allows the editor to add new rows. You could use a wysiwyg field for each entry or you could have individual columns for author, date, title, etc and then format each one when displaying the fields on the front end.

  • Hi @cloud9

    Yes this would load the WYSIWYG field with all formatting 🙂

  • This is what I get saved save the form

    Array
(
    [_acfnonce] => 
    [_acfchanged] => 1
    [acf] => Array
        (
            [field_55e95e746593e] => Sample Article
            [field_55e95e8b6593f] => Array
                (
                    [55f1131e17718] => Array
                        (
                            [acf_fc_layout] => 3_columns
                            [field_55ee67fc0ce35] => 3
                            [field_55ee68170ce36] => lorem ipsum
                            [field_55ee683b0ce37] => lorem ipsum
                            [field_55ee8f67a0990] => lorem ipsum
                        )

                    [55f1132e1771c] => Array
                        (
                            [acf_fc_layout] => full_column
                            [field_55ee687d0ce3a] => lorem ipsum
                        )

                )

            [field_55e95eb365940] => Array
                (
                    [0] => 64
                    [1] => 63
                )

            [field_55ee8eb9f1c6d] => 
            [field_55e95efb65941] => 
            [field_55efc8e15d926] => 
        )

)

    field_55e95e746593e = Title (Text)
    field_55e95e8b6593f = Content (Flexible Content)
    55f112041f2e9 = ??
    field_55ee67fc0ce35 = Select with 3 value
    field_55ee68170ce36 = Column 1 (Wysiwyg Editor)
    field_55ee683b0ce37 = Column 2 (Wysiwyg Editor)
    field_55ee8f67a0990 = Column 3 (Wysiwyg Editor)
    field_55ee687d0ce3a = Full Column (Wysiwyg Editor)
    field_55e95eb365940 = Category (Taxonomy)
    field_55ee8eb9f1c6d = Adding New Category (Text)
    field_55e95efb65941 = Featured Image (image)
    field_55efc8e15d926 = Anoter Content (Wysiwyg Editor) – This is the initial content field I used before using the Flexible Content

    As mention earlier, my initial intention was to create something similar to the capability of Page Builder. The reason I need to use Page Builder because the site I am working on allowed registered user to submit article.

    And I will like to avoid the registered user to access our back-end thus we use ACR PRO form. And Flexible Content is the closest I can get to Page Builder.

    You mention this

    flex content field will be in a nested field

    . Perhaps you can assist me how am I going about to do it?

  • Solved, i was modifying the acf/get_valid_field filter for the frontend but not checking if (!is_admin()), so i was getting the basic wysiwyg also on the backend everywhere. Sorry everyone.

  • I have been puzzling this out myself for a bit. I have a repeater field and each row of the repeater can have about 50 fields, many of them wysiwyg fields. Some of the posts have as many as 20 rows. This monster can actually timeout when you save a post. If I’d know this would happen I would have designed it differently.

    The problem is not with ACF per-say. The problems is in the fact that WP can only insert or update a single custom field at a time. When you have a couple thousand fields that need to be updated it becomes ridiculously slow. I’ve been digging around in WP looking for a solutions. What I’d like to do is store all the upates and inserts and do them all at once. but $wpdb does not seem to have any way of doing multiple queries in one request.

  • I have a similar issue with ACF 4.4.3 in a WYSIWYG field in a custom taxonomy – the text tab does not display and a JS error is thrown.

    I turned on script debug, and the error for input.js occurs on line 199, where it looks like the script is parsing the URL.

    There may be a bigger issue behind the non-rendering – I have a WYSIWYG field in a repeater on a page using a custom template. The text tab is not shown for that field, but there is no JS error in that instance.

  • Hi @pkarjala

    I see your issue. The thing about the conditional fields is that they are more about showing/hiding fields in the backend than deleting information.

    Consider a situation where someone want to show different information on a page depending on the season. For this they have radiobuttons to set which season it is and use conditional logic to show different fields (maybe wysiwyg, image field etc.) depending on autumn, winter, spring and summer. This information is the same each year. Then on the front-end they get the value of the radiobutton and show the fields accordingly. This way they can just switch between the different seasons and their information is still there ready to be used.

    What I’m trying to say is that it’s not entirely a black/white situation 🙂 I’ve had clients with similar situations as above which would hate it if a condition deleted the information. There’s also the danger of accidentally triggering a conditional (maybe accidentally check a different category on a post) and it would suck to have the content you just put in removed. But I guess you’d also have to save the post..

    This is just my thoughts on the subject.

    I’ll assign this to @elliot and we’ll see what he thinks 🙂

  • Hi John,

    Ive done a completely new local install of WordPress, I only installed ACF Pro and copied the theme from my original site to this new one and activated it.

    so in other words, everything is brand new, except for the theme.
    Now when I try to update a page, I still have the same white screen of death, this time without ANY error notice….
    some more info:

    – When I enable twentyfifteen theme and ACF Pro, and and create a field group to appear on all pages, and create a new page with custom fields in it, it works!

    here’s an important one:
    – With my custom theme and ACF Pro enabled, no field groups assigned to pages (just basic title and WYSIWYG editor), creating and updating pages works…..

    Again, I have this on multiple sites now, so it’s not just a one website situation.

    Any further clues?

  • I had needed to do this a couple months ago for a client. Rather than having class names entered into the administration of the fields as hereswhatidid did, I simply added the field name, field key, Flexible Content name (if any) and Flexible Content layout name (if any) to the body tag classes.

    I decided to make a plugin to enable this functionality, though on the plugin page I also provide code that will do the same thing (FAQ tab).

    https://wordpress.org/plugins/acf-wysiwyg-styling/

  • Hi Adrian,

    Alright good thing it worked out for you! Yeah in the latest ACF there has been some updates to the wysiwyg field in response to changes in WP 4.3 so that might be it.

    Good luck and feel free to post again if you have troubles with ACF.

  • for me this one was resolved by upgrading. I couldn’t get the regular acf repeaters to work right and this remained an issue (last i left it) but when i moved to acf pro, it seems to be built differently so this doesn’t happen. As a matter of fact i switched from repeaters to layouts and used the flexibile layout builder with repeaters and other stuff in each layout, resulting in even more wysiwyg fields and the like, and it still works fine.

  • Thank you Jonathan for your investigation. I was going to try your filter code, but after updating WordPress to 4.3 the problem is gone!

    I tested on two installations and saw the same thing on both. After updating WordPress to 4.3 the scrolling and fixed size of multiple ACF wysiwyg editors is back.

    (Before updating to WordPress I also updated ACF to 4.4.3 so it could be a combination of WP 4.3 and ACF 4.4.3, but only updating ACF did not change anything.)

    I’m going to mark this answer as “This solved my question” but I’m still thankful for your previous answers.

  • Just a side note. You may want to test creating a post with content in all of these fields, multiple layouts and multiple repeaters, etc. I have one site with a huge field group like this that times out when the client hits update. If I’d known it was going to happen I would have built it differently. Problem is that every field that’s saved generates a db query. Not saying you’ll have an issue, my field group has a lot of wysiwyg fields, which may also be contributing to the problem.

  • Okay, I think I’ve narrowed down the bug.

    In my original ‘Columns’ layout I had a radio button so people could select the column layout they wanted, for example “100%” or “33% / 66%” or “33% / 33% / 33%”.

    I set up 3 WYSIWYG editors and used conditionals to hide/show them in the editing panel based on what the user selected. So if you chose “100%” you’d see just one editor (this is the default), if you chose “33/66” you’d see two editors, and 3 editors for 33/33/33.

    So here are the steps to recreate the issue.

    1. Add a new ‘column’ layout on a page, select ’33/66′ and enter content in the two visible editor panels.
    2. Add another column’ layout, select ’33/33/33′ and enter content in the three editor panels.
    3. Save/update the page, you now have 2 column layouts displaying, the first with 2 columns, the second with 3.
    4. Click the (-) symbol to delete the 33/33/33 layout. WITHOUT SAVING, add another ‘column’ layout in the same spot. By default it shows with one 100% editor showing, and it’s blank. Looks like a totally empty row. Choose 33/66 – both still blank – same for 33/33/33. Now switch back to 100% and the single editor, enter a piece of content, and “Update” the page.
    5. Now look at the front end – your second column layout will show your new content in the first column/editor space, and the old content (that you thought was deleted) in the other two spots – still 3 columns. It’s like a magic trick. 🙂

    So, the “fix” is to delete all content out of all three Editors, save the page, then delete the layout, then save the page again – every time you want to delete a layout row. If you don’t do that, and get too many layout addition/deletions down the road, it becomes impossible to find the content that’s saved in the db because it doesn’t appear in the WYSIWYG editors when you add new layout rows.

    Or is it just me? 🙂 I just updated to the most recent ACF Pro though I’m not on 4.3 yet.

  • I just updated my WP installation to 4.3 and the ACF WYSIWYG is still acting strange, but a little different than before.

    It’s no longer changing the code saved. Whether I’m using paragraph tags, inline, or hard returns, it stays the same. However, it’s still getting rendered to the page oddly. For example, putting everything on one line adds an empty paragraph before my closing shortcodes.

    And this may have been buggy before I updated, but I just noticed that I can’t toggle between the visual and text editors. If I click the one that’s turned off, nothing happens. My selection apparently still gets sent to the cookie, though, because if I refresh the page, I’ll see the editor I tried to switch to.

  • Hello again,

    So I’ve talked to Elliot and the reason he’s not using wp_editor is that it’s not compatible with repeater and flexible fields.

    However there is a filter you can use to modify the tinyMCE settings in ACF

    acf.add_filter('wysiwyg_tinymce_settings', function( mceInit, id ){
	
	// do something to mceInit
	
	
	// return
	return mceInit;
			
});

  • Alright so I took another quick look and I can’t find any reference to the native wp_editor in the included wysiwyg field in ACF Pro core.

  • Hi John,

    Unfortunately no.. I’m not that deeply involved with the ACF development.
    However you might look at the changelogs and search for references to wysiwyg.

  • Oh, I assumed ACF was using wp_editor(). Maybe I was confused by the ACF WordPress WYSIWYG Field.

  • Alright thanks.

    There’s a lot of posts recently about the behaviour of the wysiwyg field. I’m considering talking directly to Elliot about this and see if there’s a deeper reason why he’s not using the default wp_editor function or if it’s something that could be introduced in an update. I think that would solve most issues people currently have including yours 🙂

  • Hi @adrian-b

    I’ve seen a lot of posts regarding the wysiwyg field as of late.. It would seem that ACF for some reason does not use wp_editor() to create the editor.. why that is I’m not sure but it could be simply because the wysiwyg field was introduced before wp_editor().

    I think I will take it up with elliot regarding possibly making the effort to switch to the native function rather than a custom editor.

  • It sure does look like ACF wysiwyg is handling things differently.

    I’m fairly sure the wysiwyg field is not created using wp_editor() (not 100% sure why but it’s possible wp_editor was introduced after the wysiwyg field).

    Just to make sure, do you have the latest version of ACF and WordPress? Do you run any filters or hooks on the ACF fields which could interfere?

Viewing 25 results - 726 through 750 (of 1,297 total)
1 2 3 … 29 30 31 … 50 51 52