• dkinsley

    (@dkinsley)


    Hey, I work on a multi-site instance of wordpress and we (my team and I) wanted to begin disallowing users from editing the site-title to be blank. Since my team and I are network admins, we create the site and always give it a title but occasionally the user will go in afterwards and delete the site title. The solution I came up with is to enqueue my own Javascript file that displays a message saying the title cannot be blank and disables the publish button whenever the site-title-box is empty. This action occurs on the option-general page (Settings>general) and the Appearance>Customize page.
    It works fine on the option-general page but I’ve been running into an issue on the customize>Site Identity page where the submit/publish button will be disabled and working how I envisioned until I change to another tab. When I come back to the Customize tab, the publish button is no longer disabled. Viewing the source code shows that switching tabs strips away the disabled attribute and I’m not sure why. My initial thought is that there is an event listener on the submit button that re-enables it but I can’t find where that is happening.

    Any help would be greatly appreciated and I can provide any code that may be useful. Furthermore, if there is a more efficient way to accomplish this, say an action that I can hook into when a submit button is pushed, that would also be very useful. Lastly, this occurs on both Chrome and Firefox.

    JavaScript Code:

    	wp.customize('blogname', function(setting){
    		setting.bind(function(value){
    			var code = "";
    			if(value.length == 0 || $.trim(value) == ""){
    				setting.notifications.add(code, new wp.customize.Notification(
    					code,
    					{
    						type:'warning',
    						message:'You must include a site title.'
    					}
    				));
    
    				$('input#save, #publish-settings').prop('disabled', true);
    				
    			} else{
    				setting.notifications.remove(code);
    				$('input#save, #publish-settings').prop('disabled', false);
    			}
    		});
    	});

    PHP Code:

    function check_site_title_not_null($hook){
    	//error_log($hook);
    	if($hook == 'options-general.php' || $hook == 'widgets.php'){
    		wp_register_script(
    				'non_blank_title_js',
    				admin_url('js/non_blank_title.js')
    				);
    		wp_enqueue_script(
    				'non_blank_title_js',
    				admin_url('js/non_blank_title.js'),
    				array('jquery'),
    				null,
    				true
    				);
    	}
    }
    add_action('admin_enqueue_scripts', 'check_site_title_not_null');
    • This topic was modified 8 years ago by dkinsley.
    • This topic was modified 8 years ago by dkinsley.
    • This topic was modified 8 years ago by dkinsley.
Viewing 2 replies - 1 through 2 (of 2 total)
  • Moderator bcworkz

    (@bcworkz)

    Regardless of what you do with JS, you should protect the data field server side by hooking “pre_update_option_blogname” and enforce your requirement by replacing any blank value with the old value so it’s impossible to set a blank value regardless of what happens client side. The problem with JS solutions is clever users can bypass it and submit what they want to the server anyway. There should always be server side enforcement.

    Unfortunately, I don’t know which event you need listen to in order to retain the disabled condition on tab change. Maybe it doesn’t matter too much since they cannot actually change the value to blank anyway. If they manage to submit a blank field, it’ll regress to the old value when the page reloads.

    Thread Starter dkinsley

    (@dkinsley)

    That “pre_update_option_blogname” should work perfectly! I preferred the WordPress way but couldn’t figure out the correct filter to hook into. Thanks for the help.

Viewing 2 replies - 1 through 2 (of 2 total)

The topic ‘Disabled Button re-enables itself after changing tabs’ is closed to new replies.