Tag: Wordpress

WordPress WP_Media_Image Widget Link Rel

Posted on by Andy King

WP_Media_Image widgets support a lot of options, but almost none of them are exposed to the end user. For example, there are toggles for adding target=_blank to the link of a WP Media Image Widget.

Adding this filter to your functions.php will force all WP_Media_Image widgets to link externally without any intervetion from the blog administrators:

function add_blank_target_to_image_widget( $instance, $args, $widget ) {
	$instance['link_target_blank'] = true;
	return $instance;
}
add_filter( 'widget_media_image_instance', 'add_blank_target_to_image_widget', 10, 3 );

Restrict-Widgets plugin 1.4.0 update for WordPress

Posted on by Andy King

I have been using an excellent plugin from dFactory called Restrict-Widgets to control how widgets are displayed on WordPress. It gives me the ability to restrict visibility of a specific widget to specific pages, categories, posts, and more. However after using it for a couple months I realized a major shortcoming in the visibility control design for more complex WordPress sites:

You can’t exclude any one item from the group filters without removing the group and including every other item within it but that one.

For example, let’s say you have a widget set up to only display on the Single Pages group. Later you decide you don’t want that widget to show up on one specific page. You would have to replace the Single Pages filter with a manual list of every single page you want the widget to show up on except one. This becomes extremely tedious on pages with dynamic content or content posted daily because the filter will have to be updated every time – completely defeating the purpose of supporting a group filter.

New Exclusions option in use

I have updated the plugin to have a new option called Exclusions. The option appears below the original option of Display / Hide from selected on widget options and works the exact same way where you can enter specific items or groups of items to be excluded from your original filter results.

Returning to our original example, you can now exclude that single page from your filter results without undoing your group filter for Single Pages.

As a bonus I also updated the 3rd party jQuery plugin previously used for the dynamic multi-select input box that autocompletes all of the options and displays them in tag form. restrict-widgets 1.4.0 uses jQuery Fastselect by Damir Brekalo .

You can find my 1.4.0 update for restrict-widgets on my GitHub. I created a pull request to the repo for restrict-widgets but I have a feeling it will never be merged. The repo was created by WP Plugin Mirror and was out of date with the latest release of restrict-widgets (1.3.1 as of writing). I updated the repo base to the latest code version and then applied my changes. The changes should be merge-able into any future update of restrict-widgets using git.

Download restrict-widgets 1.4.0 on GitHub

Using wp_editor for custom richtext input in WordPress Plugin

Posted on by Andy King

Eventually you will want to accept richtext input for your plugin and the best way to do that is with the built-in wp_editor() function in WordPress.

The basic rundown of wp_editor is that it accepts 3 arguments: content, editor id, and editor settings. The content argument is used for pre-filling text into the editor (either default text or saved text), the ID argument is used to give the editor a unique ID in the HTML so that you can access it by name later for grabbing the content to save from POST, and lastly the settings argument is an array you can view more about here. Probably the only settings there you may care about is enabling or disabling the “Add Media” button from appearing anywhere in the editor, and changing height of the editor

Loading any previously saved content for the editor

Assuming you want this textbox to always be filled with the current value of the data, you will need to load whatever the last saved value was from your WP options. If there is no previous data to load, the variable will remain unset.

$options = get_option('my_plugin_options');

Inserting the WP Editor into a page

To add the WP Editor into a page simply invoke it with this code: 

 $settings = array( 'media_buttons' => true, 'textarea_rows' => 5 );
        $content = isset($options['saved_text']) ? stripslashes(wpautop($options['saved_text'])) : '';
        $editor_id = 'my_textbox';
        wp_editor( $content, $editor_id, $settings );

Saving the content of the WP Editor into your WP Options

Once the user has finished making changes and saves, you will want to process the content of the WP Editor before saving it. Assuming you already have a working function for handling your page’s POST data (and if you don’t, I’ll have a write-up for that eventually), just add the following code to process the content of the WP Editor:

 $options['saved_text'] = (isset($_POST['my_textbox']) ? wp_specialchars_decode( $_POST['my_textbox'], $quote_style = ENT_QUOTES );

Displaying the saved content from WP Editor

Even though we have saved the content properly, there is still some additional processing which has to be done any time you want to output this data. The reason is because WordPress automatically escapes any data saved to the WP options table. You could avoid this by doing your own table operations to save data unescaped but I prefer to use the system provided already.

To display your saved data, you need to process it with two functions:

stripslashes(wpautop($content));

stripslashes() will prevent any existing slashes from being escaped with more slashes and wpautop() will convert any double line breaks into paragraph HTML entities.

WordPress HTML escaping for saved textarea data

Posted on by Andy King

While creating an admin area for a custom plugin I was working on for a client I had a need to add a WP Editor textarea to allow the client to add/edit richtext for use by the plugin. Everything appeared to work great until the client tried to add links to the textbox. They were being saved with quotes, ampersands, etc escaped to their full unicode names ($quot;, $amp;, etc). Slashes were getting doubled up.

The Solution

After some quick Googling I found a surprisingly mixed response of solutions which unsurprisingly did not work. They either introducted XSS vulnerabilities or destroyed the formatting of the richtext. The actual solution is twofold and will involve editing both your method of saving the text as well as displaying it anywhere (including in the editor itself).

Anywhere you are saving the content of the WP Editor textbox, you must run it through this function: 

//$content is your richtext content from the WP Editor.
wp_specialchars_decode($content, $quote_style = ENT_QUOTES);

Next, anywhere you want to output this data properly you must run it through two functions:

stripslashes(wpautop($content));

stripslashes() will prevent any existing slashes from being escaped with more slashes and wpautop() will convert any double line breaks into paragraph HTML entities.