I don’t think the vars settings are necessary here—you don’t have enough fields to go over the limit.
What PHP code are you using in your frontend template to display that field?
In your case, I’d say custom post types are the *philosophically* correct way to go, just because the things you’re using pages for aren’t really ‘pages’. If I were doing it I’d have a ‘venue’ custom post type and an ‘event’ custom post type, and save pages for actual pages on the site—the About, Contact, etc. pages.
However! If it works for you as is, then stick with it. It doesn’t sound like you’re doing anything too hack-y, and it sounds like the admin interface will still be intuitive, so don’t worry about it and keep it as-is.
I’m not sure I understand your question fully; it’s hard to tell without knowing your site’s needs. But: ACF’s ability to conditionally show fields on different post templates, taxonomies, etc. does make it possible to avoid creating different post types when the default post types and conditionally-shown ACF fields will suffice.
Custom post types are certainly not obviated by this plugin, however. For example, a website for a running club would have custom post types for race and course in addition to the default post and page post types. An ACF object relationship field on the Race edit page could tie it to a specific course.
Does that make sense?
An easy fix might be to rename the ‘Uncategorized’ post category to a different default. Is that an option for you?
Your code is working correctly for me.
Are you sure that you have your date picker returning the date in the Ymd format? (See the attached screenshot of the ACF interface where the return format is set.) You can just echo get_field('event_date') to check the format you’re getting back.
Alternately, you could do it in procedural style this way, which should work no matter what format is being returned:
<?php $date = strtotime(get_field('event_date')); ?>
<span><?php echo date('d', $date); ?></span>
<span><?php echo date('M', $date); ?></span>
Also confirming that re-downloading and installing 5.0.5 takes care of the bug.
Crefio, can you let me know if you hear back about this? I’m experiencing the exact same bug.
TheBlogHouse: Have you tried removing the if statement and just loading that JavaScript on all admin pages?
I’m not sure exactly. I don’t have time to dig into it right now, but I assume this bug will be fixed in ACF shortly so it should be unnecessary soon. 🙂
Overbound, that if statement may be causing the JavaScript not to be injected in your admin footer. Can you use View Source or the Developer Tools inspector to check? If it’s not loading, try just removing the if statement. You’ll get JS errors where that button can’t be found (on pages that are the post edit page), but it should work.
I’ve noticed the same thing. This is a show-stopper for me, so, for the time being, I’ve put the following workaround in my functions file. It just removes the ‘disabled’ class from the ‘Publish’/’Update’ button as soon as it’s added, which allows you to click it.
// There is a bug with ACF 4.3.7 and WP 3.9 that disables the 'Save Draft'/'Publish' button if there are validation errors. This is a dirty workaround for that bug: we remove the 'disabled' class from the button every time the button gets clicked (which adds that class to prevent spurious submits).
function load_javascript_on_admin_edit_post_page() {
global $parent_file;
// If we're on the edit post page.
if ($parent_file == 'post-new.php' ||
$parent_file == 'edit.php') {
echo "
<script>
jQuery('#publish').on('click', function() {
jQuery.this.removeClass('disabled');
});
</script>
";
}
}
add_action('in_admin_footer', 'load_javascript_on_admin_edit_post_page');
You are probably running into the PHP default variable limit, and you need to increase it. Here’s an explanation: http://www.advancedcustomfields.com/faq/limit-number-fields/
You are probably running into the PHP default variable limit, and you need to increase it. Here’s an explanation: http://www.advancedcustomfields.com/faq/limit-number-fields/
I discovered something else: you can use the Iris change callback to make it so the ‘Current Color’ swatch (the one this you click to open the color picker) gets updated live along with the color changes instead of needing a Save and page refresh before updating.
Here’s the updated code doing both the custom swatches and ‘Current Color’ updating:
function load_javascript_on_admin_edit_post_page() {
global $parent_file;
// If we're on the edit post page.
if ($parent_file == 'post-new.php' ||
$parent_file == 'edit.php') {
echo "
<script>
jQuery(document).ready(function(){
jQuery('.color_picker').iris({
palettes: ['#125', '#459', '#78b', '#ab0', '#de3', '#f0f'],
change: function(event, ui){
jQuery(this).parents('.wp-picker-container').find('.wp-color-result').css('background-color', ui.color.toString());
}
});
});
</script>
";
}
}
add_action('in_admin_footer', 'load_javascript_on_admin_edit_post_page');
The color picker uses Iris. You can send a palette to existing Iris objects via Javascript as described in the Iris documentation. Here’s some example code to change all of the swatches/palettes on the post edit page. Put this in your theme’s functions file:
function load_javascript_on_admin_edit_post_page() {
global $parent_file;
// If we're on the edit post page.
if ($parent_file == 'post-new.php' ||
$parent_file == 'edit.php') {
echo "
<script>
jQuery(document).live('acf/setup_fields', function(e, div){
jQuery('.color_picker').each(function() {
jQuery(this).iris({
palettes: ['#125', '#459', '#78b', '#ab0', '#de3', '#f0f']
});
});
});
</script>
";
}
}
add_action('in_admin_footer', 'load_javascript_on_admin_edit_post_page');
ACF-Date-Ret....png