• Idealien

• in reply to: Pro License Key in config?
• April 9, 2020 at 12:56 am

I don’t see the wp-config concern as enough of a reason to prevent this given how many other plugins and values such as DB credentials are already following that pattern.

It would be great if WP supported .env files natively, it’s definitely the proper place for config values.

Agreed. Until that is part of core, using https://github.com/vlucas/phpdotenv isn’t that much overhead as an included composer package. The roots.io team has a good write-up of how they’ve incorporated into their repo structures, build pipelines, etc. But chances are if wp-config has been committed with values to git, adding a composer dependency may be beyond the same user base :/

• Idealien

• in reply to: ACF Front End Form Revisions
• January 18, 2019 at 8:46 am

The following snippets have served me well to store meta revisions on a front-end post save. Note that if your ACF group is very large this can have very large impacts on your DB and post save performance. YMMV. I have not tested it for WP > 5.0

I believe I sourced the initial concept from a different thread here but cannot locate at the moment.

//ACF - Extend ACF Save Behaviour to ensure front-end saves trigger revision
add_action('acf/pre_save_post', 'pre_save_post_update_revisions');
function pre_save_post_update_revisions($post_id) {
	// bail early if editing in admin
	// ACF already handles admin revisions correctly
	if (is_admin()) {
	  return $post_id;
	}
  
	// force a post update, this will generate a revision and
	// trigger the '_wp_put_post_revision' action
	$update_post = get_post($post_id);

	$saved_revision = wp_save_post_revision( $update_post );
  	return $post_id;
}

//ACF - Extend ACF Save Behaviour to ensure revisions include meta
add_action('_wp_put_post_revision', '_on_wp_put_post_revision');
function _on_wp_put_post_revision($revision_id) {

	// get the revision post object
	$revision = get_post($revision_id);
	// get the id of the original post
	$post_id = $revision->post_parent;

	// bail early if editing in admin
	if (is_admin())
		return;
  	//For Non-Admin Cases - ensure the meta data is written to revision as well as post
	if (!empty($_POST['acf'])) {
	  	foreach ($_POST['acf'] as $k => $v) {
 
			// bail early if $value is not is a field_key
			if (!acf_is_field_key($k)) {
				continue;
			}
			update_field($k, $v, $revision_id);
			update_metadata('post', $revision_id, $k, $v);
		} 
	}  
}

• Idealien

• in reply to: Conditional Logic using Taxonomy field
• July 29, 2016 at 1:51 pm

For those who aren’t afraid to write a little bit of JS to self-solve their problem. I put together a blog post explaining this – http://idealienstudios.com/crazy-with-conditionals/ – and specific JS Gist for reference.

Enjoy!

• Idealien

• in reply to: No revision when update from front end
• June 9, 2016 at 2:17 pm

FYI – When using @joelstransky snippet with the
Component Field Add-On, I do get similar errors to what @et3rnal posted. It looks like the $_POST[‘acf’][$v] index is not being properly identified for sub-fields within the component. I’ve cross-posted support request to the vendor page in link above, but thought I’d double up here in case anyone has suggestions to resolve.

• Idealien

• in reply to: No revision when update from front end
• June 9, 2016 at 12:30 am

Works on my environment, no errors noted.

@joelstransky 1000x thank you for an elegant solution!

• Idealien

• in reply to: Repeater fields and revision support
• February 16, 2016 at 4:30 pm

The feature plugin WP-Post-Meta-Revisions is what you need. With it active, changes to meta will be stored / saved as a full revision. The diffs do show, but perhaps not quite as elegantly as you’d like as they use field_key.

• Idealien

• in reply to: No revision when update from front end
• February 16, 2016 at 4:28 pm

The feature plugin WP-Post-Meta-Revisions is what you need. With it active, changes to meta from the front-end forms will be saved in / as a full revision.

If you want to present a revision (with all it’s meta at the time of revision) on the front-end, make sure you identify the revision ID (as post ID) to the ACF functions like have_rows and get_field_object.

• Idealien

• in reply to: ACF Front End Form Revisions
• February 16, 2016 at 4:25 pm

Correction – As long as you pass the revision ID (as post ID) to functions like get_field_object and have_rows, you don’t need to change much front-end logic for presenting revisioned meta on the front-end either.

• Idealien

• in reply to: Revisions not showing custom fields
• February 16, 2016 at 8:32 am

https://github.com/adamsilverstein/wp-post-meta-revisions

• Idealien

• in reply to: Issue when ACF restores a post's relationship custom field value from a revision
• February 16, 2016 at 8:32 am

https://github.com/adamsilverstein/wp-post-meta-revisions

This “Feature plugin” will eventually be merged into WP Core and addressed some of the issues you highlight.

• Idealien

• in reply to: ACF Front End Form Revisions
• February 16, 2016 at 8:26 am

You’ll need to have https://github.com/adamsilverstein/wp-post-meta-revisions – or at least until it becomes part of core to enable meta field changes triggering revisions.

That helps for everything “back end” but does not let you present any of the revisioned meta on the front-end. This SQL might give you a starting point

SELECT * FROM wp_postmeta WHERE post_ID = [dynamic] AND post_ID IN (SELECT ID FROM wp_posts WHERE post_type = 'revision') ORDER By meta_key;

• Idealien

• in reply to: Submit red error messages not clear on tabbed layout
• February 15, 2016 at 1:34 pm

This is multiplied by having layouts within tabs that may also have validation errors. The snippet below is by no means perfect, nor certain to cover every case of layout / repeater / tab / etc, but it is a starting point that you could work with:

jQuery(".acf-error-message").closest(".layout").find(".acf-fc-layout-handle").css("background", "red");

You’d need to get it to fire as a part of or after the ACF validation adds the error code into page.

• Idealien

• in reply to: Front-End Form with template (and The Events Calendar)
• April 25, 2014 at 11:36 pm

With TEC 3.5.1, ACF 4.3.7 and WP 3.9 I am getting a similar JS error again.

The following snippet works to resolve a similar issue with the jquery-ui-datepicker dependancy. It does de-activate the datepicker, which in my particular use case is not needed. I’m not sure why the conflict occurs in the first place either – but hopefully it helps for another future version to resolve conflict.

wp_dequeue_script('acf-input' );
wp_deregister_script('acf-input');
wp_register_script('acf-input', '/wp-content/plugins/advanced-custom-fields/js/input.min.js', array('jquery', 'jquery-ui-core'), '4.3.7');
wp_enqueue_script ('act-input' );

• Idealien

• in reply to: Front-End Form with template (and The Events Calendar)
• April 25, 2014 at 6:00 am

This reply has been marked as private.

• Idealien

• in reply to: Moving ACF between environments and acf_form($options)
• February 26, 2014 at 9:46 am

Solved. I had the register_field_group in plugin tied to admin_init instead of init.

As a future enhancement to the plugin, I might suggest a section to the admin page that lists field groupings which are created via plugin / theme for reference.

• Idealien

• in reply to: Moving ACF between environments and acf_form($options)
• February 26, 2014 at 9:43 am

And the code (which doesn’t display my form) on template:

$args = array('post_id' => 'new', 'field_groups' => array('acf_photo-gallery-details'));
						
acf_form( $args );

In other templates I do have the call to acf_head(). I do see the Update button display and when inspecting source the rest of the hidden fields and form. But no actual fields.

• Idealien

• in reply to: Front-End Form with template (and The Events Calendar)
• February 12, 2014 at 4:14 am

FYI – The Tri.be support forum found a resolution for issue with a snippet to de-register the acf-datepicker that, according to them, is conflicting with the use of standard jquery-ui-datepicker. From https://tri.be/support/forums/topic/plugin-conlict-js-errors-from-tec-front-end-acf-form-on-an-event-template/ :

What is happening is that ACF is using it’s own custom datepicker, enqueued with “acf-datepicker”. The thing is, it conflicts with WP’s ’jquery-ui-datepicker’, which is basically the same thing only it is provided by WordPress. Our plugin uses ’jquery-ui-datepicker’ to avoid conflicts just like this. Other plugins need to be using the scripts that WordPress provides, as this limits conflicts and optimizes the site loading times. Unfortunately ACF is not doing this.

• Idealien

• in reply to: Front-End Form default image and loss of post type
• February 12, 2014 at 3:53 am

This reply has been marked as private.

• Idealien

• in reply to: Front-End Form with template (and The Events Calendar)
• February 7, 2014 at 4:13 pm

Digging deeper I found that in addition to their specific event page types they also wrap inside a more general template – /wp-content/plugins/the-events-calendar/views/ecp-page-template.php – that you can copy into your theme and customize presentation of. That does make a call to get_header() that I can put the acf_form_head() in front of.

I’m still left with two JS errors:

• TypeError: e.fn.datepicker.noConflict is not a function calling from wp-content/plugins/the-events-calendar/resources/tribe-events.min.js?ver=3.4.1
• TypeError: g is undefined calling from /wp-includes/js/tinymce/tiny_mce.js?ver=359-20131026

Cross-posted onto the tri.be support forum for plugin conflict impact – http://tri.be/support/forums/topic/plugin-conlict-js-errors-from-tec-front-end-acf-form-on-an-event-template/#DiscussionForm

• Idealien

• in reply to: Front-End Form with template (and The Events Calendar)
• February 7, 2014 at 1:05 pm

Only on the front end.

I’m using the gallery add-on which I purchased purely for the front-end ability to batch upload photos with the standard media upload UI. The gist of the rest of process (which is working):

• ACF adds a select field to event post type that is populated with Gravity Forms for admin to select which registration form to use. That is displayed on upcoming events via template.
• Create a CPT for galleries
• ACF provides meta fields on gallery (eventID, photographer, email and multi-photo from add-on.

The last piece is having the ACF form show up on event to allow batch upload of photos which is limited by the issue described above.

I have a temporary workaround of putting a separate the photo submission form onto a separate page that populates the eventID via select field populated with past dated events. But requirement is that everything stays tied to the individual event along with comments, post-event feedback (GF) form.

• Idealien

• in reply to: Front-End Form default image and loss of post type
• February 2, 2014 at 2:45 pm

Yes. It applies to a _ anywhere within the field name too.

• Idealien

• in reply to: Front-End Form default image and loss of post type
• February 1, 2014 at 4:59 am

Issue: Field Group location rule is being stored to database but is NOT being shown as selected when viewing the Field Group.

Steps to reproduce:
1) Go to Custom Fields menu
2) Select Add New Field Group from top of page. Title: Gallery Details
3) Create fields (XML at bottom of this post)
4) Select Location Rule = Show this field group if Post Type is equal to gallery.
5) Publish Field Group.
6) Go to Gallery Post Type edit screen and the ACF form is there.
7) Go back to Field Group and Edit Gallery Details.
8) The Location Rule defaults back to Post Type = post.
9) If I update anything in the field group and do not also re-change the location rule back to Post Type = gallery, the ACF form will be moved from gallery CPT to post.

I *believe* the issue is related to my initial choice to use _ in my field names (gallery_photo, gallery_event, gallery_photographer) causing the location group to return to default.

• Idealien

• in reply to: Front-End Form default image and loss of post type
• January 30, 2014 at 5:06 am

#2 has been resolved thanks to this thread – http://support.advancedcustomfields.com/forums/topic/front-end-form-values-staying-filled/ – about pre-populated values with _new in the options table.

• Idealien

• in reply to: Front-End Form default image and loss of post type
• January 29, 2014 at 2:05 pm

1) When I go to the Custom Fields edit screen and change the location rule my group applies to CPT (gallery) it will save to that type. All subsequent form entries go to the CPT. But when I go back to the custom field edit screen, the drop-down displays as default post. Essentially every time I go back to the form I have to manually change the location back to CPT option.

2) With acf_form_head(); above get_header() call in a child theme of http://320press.com/wpbs/ in a very vanilla page template I have the following:

<?php 
$args = array(
'post_id' => 'new',
'field_groups' => array( 252 )
);
 	
acf_form( $args ); 
?>

3) Unfortunately it’s all in local dev atm. But followed very closely to the instructions from http://www.advancedcustomfields.com/resources/tutorials/using-acf_form-to-create-a-new-post/ for it. Dev environment is a vagrant VM and Capistrano/Composer stack based on Roots.io bedrock mostly.

Thanks

• Idealien

• in reply to: CPT Loop not returning get_field but does get_post_meta
• December 17, 2013 at 6:51 am

Changed my local dev environment from VVV to a more generic lamp vagrant setup and the issue has gone away. Not sure what the direct cause in that mix is but happy that it is no longer affecting me.