@maculotti-a I had the same issue and noticed it was happening on multiple WP Engine sites, which disables revisions by default. After enabling revisions (via chat support) Preview started working again. Maybe your host does the same.
Thanks @proxxim! Outputting the link via function could be helpful too.
I had a similar issue, found this thread, and just wanted to say @hube2 your solution of grouping/cloning/component-izing links like this is brilliant. Rolling it into my starter theme as soon as I’m able.
In case anybody else finds this, I had the same issue when displaying an image as a background image. I was using something like:
<?php if ($photo) { echo 'background-image: url("' . esc_url($photo['url']) . '");'; } ?>">
Turns out the double quotes within the url(“”) caused the file name to output without slashes. I believe that’s valid CSS but I guess PHP doesn’t like it. Solved it by removing the double quotes:
<?php if ($photo) { echo 'background-image: url(' . esc_url($photo['url']) . ');'; } ?>">
Or by using single (escaped) quotes:
<?php if ($photo) { echo 'background-image: url(\'' . esc_url($photo['url']) . '\');'; } ?>">
Here’s what I heard back from support in case it helps anybody else. It’s not a bug, per se, but related to the newer HTML escaping and now requires a filter, customized to your needs:
ACF 5.10 introduced a new safer escaping system for anything rendered by ACF to prevent XSS attacks, by using WordPress’s kses system.
You can find more information on this here: https://www.advancedcustomfields.com/resources/html-escaping/
Specifically, at the bottom of that article you can see our code snippet you’ll need to add to your theme or plugin in order to allow SVGs inside your markup, as WordPress does not allow them by default.
Thanks John. Submitted.
Thanks for posting that, @joshf! I missed the update and indeed, this thread is the first thing that comes up for “Advanced Custom Fields duplicate repeater.”
@jusxon I do something similar but actually like your method mimicking the click a bit better than mine of adding and removing classes. Still hoping this becomes an option some time in the future.
I think in most cases this is great, but would love the ability to turn this off on certain groups. Would much rather a revisit to the page showed my “Content” tab rather than the “Customize” tab.
That fixes it, thank you! Look forward to it in the next update.
I’ve submitted a ticket and will update this post with their response.
Seems like it shouldvalidate, at least according to the <input type=range> spec. Per https://developer.mozilla.org/en-US/docs/Web/HTML/Element/input/range:
By default, the granularity, is 1, meaning that the value is always an integer. You can change the step attribute to control the granularity. For example, If you need a value between 5 and 10, accurate to two decimal places, you should set the value of step to 0.01
Not sure if it will help you, @martin-matties, but it’s worth trying:
Go to your Field Groups and see if you have any field groups in the trash:
If yes, click “Trash” then empty it by clicking “Delete permanently” on the field group(s).
If you don’t have any in the trash or that doesn’t help — hopefully somebody else can help you.
Wanted to echo that I’m randomly seeing fields inside a flexible content layout become “required” as well.
It’s a rather long flexible content field, with 9 possible layouts and 2-4 sub fields each. Working locally right now. Not using the Local JSON feature.
Apologies that I don’t have time to debug now, on a deadline, but I’ll keep an eye on this thread and followup after.
Just in case anybody fins this in the future and is on ACF 4.X, I had the same error message (though on an Options page with a textarea field) and it turned out to be unrelated to my fields at all, but because I had a deleted ACF Field Group in the trash. It was a duplicated and renamed group from an ACF import. Anyway, I emptied the Field Group trash and the error went away and my page fields worked again.
No idea if this is applicable to you, but just in case it helps anybody in the future I had the same error message (though on an Options page with a textarea field) and it turned out to be unrelated to my fields at all, but because I had a deleted ACF Field Group in the trash. It was a duplicated and renamed group from an ACF import. Anyway, I emptied the Field Group trash and the error went away and my page fields worked again.
Seeing this issue as well (ACF 5.2.5). Changing the field to a ‘select’ until fixed.
This still seems to be an issue on mobile/tablet view:
Screenshot: http://take.ms/dt2Ct
My workaround is similar to @planktonwebdesign, adding the following to an admin CSS file:
@media screen and (max-width: 782px) {
ul.acf-radio-list li input,
ul.acf-checkbox-list li input { width: 25px !important; }
}
Thanks!
For anybody else that finds this, I ended up using this solution: wordpress.mfields.org/2010/set-default-terms-for-your-custom-taxonomies-in-wordpress-3-0/.
If you add your taxonomies manually in functions.php, maybe take a look here first: wordpress.stackexchange.com/a/7171/50427.
Just ran into this need as well. +1
I can’t speak to the functions above, but if you’re looking to do a lot of admin sidebar tweaking, look into the Admin Menu Editor plugin https://wordpress.org/plugins/admin-menu-editor. Allows for resorting, hiding, adding, and all sorts of editing to the admin menu. Great for handing off to less-savvy users.
Looks like this issue is back…
– WP 4.1 with ACF PRO 5.1.5
– Totally clean install to test this issue
– ACF is the only plugin
– Theme is bare except for WP_DEBUG enabled in functions.php
– No PHP errors on admin page or JS errors in console
The field group holds a repeater field with a WYSIWYG field inside. When editing a post, re-sorting the repeater causes the WYSIWYG field to remove all paragraph and line breaks. This only happens when the WYSIWYG is in Visual mode (Text mode preserves the breaks OK).
I made a quick 1 min. screencast showing the issue here: https://www.youtube.com/watch?v=JoC71DGS1eM
Any ideas? Thank you!
I’m having a similar issue, ACF strips double quotes when they’re entered into a textbox by the client. Doesn’t matter if the “New Lines” option is set to “Automatically add paragraphs, Automatically add <br>, or No Formatting.” The solution is to use single quotes but I really wish that wasn’t the case.
And to possibly help with your particular case, @michael-b, have you tried using a “typographer” or “curly” quote instead? Either the entity itself (”) or alphanumeric version (”
)
Welcome to the Advanced Custom Fields community forum.
Browse through ideas, snippets of code, questions and answers between fellow ACF users
Helping others is a great way to earn karma, gain badges and help ACF development!
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.