Phil

My notes above applied to version 2.3.6 of the plugin. I presume this functionality will be included in the next version because the functionality is already in the github version (handled in a pull request even before my notes above).

Thanks for your work on this, Davide!

Some ideas here, for any still looking.

Thanks Davide. Your info helped me give permission to a non-administrator to manage redirects. My slightly different approach:

The add_management_page() function you mentioned (in redirection.php) appears to filter the 3rd parameter ($capability) since v2.3.5:

apply_filters( 'redirection_role', 'administrator' )

I used this filter in my theme files to enable certain users to manage redirects (i.e., users with a custom edit_redirects capability I created with the User Role Editor plugin):

add_filter('redirection_role', 'my_redirection_role');
function my_redirection_role($role) {
  return 'edit_redirects';
}

Then with the Admin Menu Editor plugin I set the “Required capability” for the Tools -> Redirection menu to edit_redirects.

Now users with the edit_redirects capability can access the redirects management page. But… their changes won’t save. I’m guessing the Redirections plugin author would want to apply the above redirection_role filter again in the init() function near the top of ajax.php:

function init() {
  // if ( current_user_can( 'administrator' ) ) {
  if ( current_user_can( apply_filters( 'redirection_role', 'administrator' ) ) ) {

After making that edit, my edit_redirects capable user can fully manage redirects.

Thanks John Godley, for a great plugin!

I too was using GFCPT to update existing posts, with taxonomies represented by checkbox fields. The GFCPT plugin successfully assigns new taxonomies (appends new), but fails to unassign taxonomies whose checkbox is unchecked.

As Chris noted, the issue appears resolved once I remove the “true” (for the “append”) argument from wp_set_object_terms() in GFCPTAddonBase->save_taxonomy_field() (under the condition of $field[‘type’] == ‘checkbox’). I didn’t try to imagine potential use cases this edit might break.

Thanks Brad and Chris.

I came across the same issue and welcome corrections/feedback to the approach below. In addition to fully enabling GF’s dynamic population, this appears to be an alternative resolution to the problem of wysiwyg field content not being retained when validation fails, discussed here. It could also be an opportunity to incorporate the wp media button, as discussed here.

Because we’ll replace the functionality of the wysiwyg_enqueue_scripts() function elsewhere, comment out line 27 in the file gf_wysiwyg_class.php:

// add_action( 'gform_enqueue_scripts' , array(&$this, 'wysiwyg_enqueue_scripts') , 10 , 2 );

For good measure, comment out the entire associated wysiwyg_enqueue_scripts() function starting on line 105. We’ll insert its functionality into the wysiwyg_field_input() function where we have access to the $value parameter we’ll pass to the wp_editor() function for dynamic population. Go ahead and replace the entire wysiwyg_field_input() function (starts on line 67) with this:

function wysiwyg_field_input( $input, $field, $value, $lead_id, $form_id ) {
  if ( $this->is_wysiwyg($field) ) {

	$input_id = 'input_' . $form_id . '_' . $field["id"];

	if (is_admin()) {

	  $tabindex = GFCommon::get_tabindex();
	  return sprintf("<div class='ginput_container'><textarea readonly name='input_%s' id='input_%s' class='textarea gform_wysiwyg' {$tabindex} rows='10' cols='50'>WYSIWYG editor</textarea></div>", $field["id"], 'wysiwyg-'.$field['id']);

	} else {

		$args = array(
			'textarea_name' => 'input_'.$field["id"],
			'wpautop' => true,
			'media_buttons' => false, // possibly true
			'editor_class' => 'frontend',
			'textarea_rows' => 5,
			'tabindex' => 0 //$tabindex
		);          

		ob_start();
		wp_editor($value, $input_id, $args);
		$html = ob_get_contents();
		ob_end_clean();

		return "<div class='ginput_container'>" . $html . "</div>";
	}

  }

  return false;
}

I tested the above with WP v3.4.2, GF v1.6.10, and GF + WYSIWYG v0.1 beta. It works for me with all methods of dynamic population I’m aware of (query string, shortcode, hooks, $field_values parameter of gravity_form() function, and “Default Value” set for field in the form editor in the admin).

Obviously, you’ll want to test it fully before using on your production site. As time permits, maybe the plugin author will comment on whether this breaks something and whether it fits with the rest of the code conceptually.

Perhaps you’ve already figured it out, but maybe this will help others. I think these will apply site-wide, but you could write the functions with some conditional statements to target a specific form.

Visual Editor as Default

// Set Visual editor WYSIWYG as default
// https://wp-snippets.com/set-default-editor/
add_filter( 'wp_default_editor', create_function('', 'return "tinymce";') );

Show “Kitchen Sink” Options by Default

// Show "kitchen sink" editor by default
// https://wpmu.org/show-the-wordpress-kitchen-sink-options-on-the-editor-by-default/
add_filter('tiny_mce_before_init', 'my_unhide_kitchen_sink');
function my_unhide_kitchen_sink($args) {
	$args['wordpress_adv_hidden'] = false;
	return $args;
}

Thanks Marcus!
I admire your work. I’m grateful you’ve shared it with the rest of us.

@aglonwl, excellent reminders, thank you!
I hope I’m not off-track, but I still see a remaining issue below. I’m using

• default TwentyEleven theme (1.4)
• WP (3.4.2 in debug mode)
• EM (5.2.8) as the only plugin enabled

I understand the debug notice doesn’t interfere with functioning and is lower priority.

Re: Update to v 5.2.8
@marcus, thank you for your reply here and for so quickly addressing this issue in v. 5.2.8. I see that you added the confirmation !empty($_REQUEST['_emnonce']) before wp_verify_nonce() in em-location-post-admin.php and em-event-post-admin.php. I believe this resolves the issue for quick-edit with events.

However, quick-edit with locations now gives a notice (only if WP is in debug mode) about the undefined $this variable in the chunk of code in the function’s else portion, i.e.,
do_action('em_location_save_pre', $this);
and
apply_filters('em_location_save', true , $this);

I think $this could be switched to $EM_Location in each case. The do_action should probably be moved down a line in the code though, after $EM_Location = new EM_Location($post_id, 'post_id');
That way $EM_Location is not null for functions hooking into ’em_location_save_pre’.
Maybe the latter (no-nonce) portion of EM_Location_Post_Admin->save_post() just needs to more thoroughly handle the quick-edit stuff, like EM_Event_Post_Admin->save_post() seems to do (?).

In the short term, I think that someone who wants to get rid of the “undefined $this” notice, but doesn’t want to modify the EM core files as shown here, could use the “temporary workaround” solution in my first post above. If doing so, however, note that for quick-edit saves, any functions hooked into ’em_location_save_pre’ or ’em_location_save’ would not run.

Thanks all!