tommcfarlin / wordpress-widget-boilerplate

[WordPress] The WordPress Widget Boilerplate is an organized, maintainable boilerplate for building widgets using WordPress best practices.

WordPress Widget Boilerplate

The WordPress Widget Boilerplate serves as a foundation off of which to build your WordPress widgets using modern tools such as Composer and an object-oriented approach all of which is documented in this series of posts.

Features

• The Widget Boilerplate is fully-based on the WordPress Widget API
• Uses PHPDoc conventions for easily following the code.
• Uses Composer to handle linting and code quality tools before committing it to a repository.
• Uses a strict file organization scheme to make sure the assets are easily maintainable.

Usage

The WordPress Widget Boilerplate is ready to activate as-is (and it includes a sample widget with a title, content, and checkbox).

1. Copy the wordpress-widget-boilerplate directory into your wp-content/plugins directory
2. Navigate to the "Plugins" dashboard page
3. Locate the menu item that reads "TODO"
4. Click on "Activate"

The purpose of having a working widget is to give you an idea as to where certain things belong. Further, the idea is to fork the existing code and make it your own for your own project.

It's organized in such a way that lends itself to unit testing, a higher level of cohesion, a lower level of coupling. It also uses features of the object-oriented paradigm to provide better organization of code base and features of PHP such as namespaces and type hinting.

Author Information

The WordPress Widget Boilerplate was originally started and is maintained by Tom McFarlin.

The project is open-source and receives contributions from awesome WordPress Developers throughout the world.

wordpress-widget-boilerplate's Issues

_multiwidget set to 1

when using your boilerplate with the new wordpress, I always get multiwidgets, making it hard to use the get_options as I would always need to know the index of the current instance.

Style and Script only on the widget page

I've seen that the css and js are loaded in all the page of the dashboard but thery are needed only in the widget page.

i'ts possible add a check for this?

use of WP_PLUGIN_URL breaks secure sites

Since WP3.0, use of WP_PLUGIN_URL constant in plugins and themes is not recommended. It causes mixed-content problems with secure sites. IE8 will pop up a warning when secure pages include files not served as https - as will be the case when css, or javascript files are en-queued with URI's built using WP_PLUGIN_URL.

See: http://codex.wordpress.org/Determining_Plugin_and_Content_Directories -- I quote:

WordPress makes use of the following constants when determining the path to the content and plugin directories. These should not be used directly by plugins or themes, but are listed here for completeness.

WP_CONTENT_DIR  // no trailing slash, full paths only
WP_CONTENT_URL  // full url 
WP_PLUGIN_DIR  // full path, no trailing slash
WP_PLUGIN_URL  // full url, no trailing slash

Use the code below if you want to stay compatibile with Version 2.9 and older:

if ( ! function_exists( 'is_ssl' ) ) {
  function is_ssl() {
    if ( isset($_SERVER['HTTPS']) ) {
      if ( 'on' == strtolower($_SERVER['HTTPS']) )
         return true;
      if ( '1' == $_SERVER['HTTPS'] )
         return true;
    } elseif ( isset($_SERVER['SERVER_PORT']) && ( '443' == $_SERVER['SERVER_PORT'] ) ) {
      return true;
    }
    return false;
  }
}

if ( version_compare( get_bloginfo( 'version' ) , '3.0' , '<' ) && is_ssl() ) {
  $wp_content_url = str_replace( 'http://' , 'https://' , get_option( 'siteurl' ) );
} else {
  $wp_content_url = get_option( 'siteurl' );
}
$wp_content_url .= '/wp-content';
$wp_content_dir = ABSPATH . 'wp-content';
$wp_plugin_url = $wp_content_url . '/plugins';
$wp_plugin_dir = $wp_content_dir . '/plugins';
$wpmu_plugin_url = $wp_content_url . '/mu-plugins';
$wpmu_plugin_dir = $wp_content_dir . '/mu-plugins';

wrong file names for widget style/script register

Hey, found a couple of issues:

    wp_register_style( 'widget-name-widget-styles', plugins_url( 'widget-name/css/admin.css' ) );

line 190: change admin.css to widget.css

    wp_register_script( 'widget-name-admin-script', plugins_url( 'widget-name/js/admin.js' ) );

line 201: here it should be widget-name-widget-script and widget.js

Improve stylesheet imports

Reference

Color Picker Disappears on widget save

Hi
So here is the issue:
I have coded a widget to display some items in a carousel kind of way, I am trying to use wordpress 3.5 built in colorpicker for a text input in my widget options.
Everything works fine, but there are some bugs:
first of all, I have to save the widget once, reload the page and then the color picker works.
second, when I hit save on my widget, even after setting the color, the color picker disappears and all i can see is the text input with the color hex value. it works fine, but I don't to have the bugs I mentioned.

here is the code used to make the colorpicker/text input field:
(admin.php)

<p>
<label for="<?php echo $this->get_field_id( 'next-prev-color' ); ?>"><?php _e( 'Next Prev Handle Colors:', 'next-prev-color' ) ?></label>
<input type="text" class="widefat my-color-field" data-default-color="#666666" value="<?php esc_attr_e( $instance['next-prev-color'] ); ?>" id="<?php echo $this->get_field_id( 'next-prev-color' ); ?>" name="<?php echo $this->get_field_name( 'next-prev-color' ); ?>" />
</p>

can you help plz?

create_function is deprecated as of PHP 7.2

WordPress-Widget-Boilerplate/widget-boilerplate/plugin.php

Line 259 in 99a8db6

add_action( 'widgets_init', create_function( '', 'register_widget("Widget_Name");' ) );

Should do this instead.

function sth_register_widgets() {
	register_widget( 'Widget_Name' );
}
add_action( 'widgets_init', 'sth_register_widgets' );

// OR:

add_action( 'widgets_init', function() { register_widget( 'Widget_Name' ); } );

Error 500 on windows servers

Hi

Whenever I develop a plugin using Plugin/Widget Boilerplate, I have no problem using them on linux severs, but once I install it on a wordpress that is running on a windows server I get error 500 and the whole wordpress installation collapses.

Any idea how to fix it?

Minor comment fixes

plugin.php, line 196

// TODO be sure to change 'widget-name' to the name of *your* plugin

This TODO is no longer needed since the code takes the text domain from the slug.

plugin.php, line 166

} // end widget

should be

} // end update

Load File Helper Not Working

I've noticed two issues with the load_file function:

1.) It's missing an argument when called in the register_scripts_and_styles function.
2.) file_exists($file) is never returning true for me.

Not big deals. Just FYI

ID class variable?

In widget(), there's a call for the ID class variable (line 125), but I'm not seeing that variable set anywhere. Is that supposed to be the widget_slug? Submitting a pull request.

Undefined index

Hi i'm integrating your boilerplate with my theme (not as a plugin) and i'm getting this error

Notice: Undefined index: widget_id in plugin.php on line 115

$cache[ $args['widget_id'] ] = $widget_string;

any ideas?

Localization incomplete

Hi.
I've found the wp widget boilerplate on wptuts and I've made the "social networks" example.

As I'm not an english developer, I decided to test the localization part. All is working fine except for the widget description in the widgets menu. The description is still in english.

This seems to be because you start creating the widget before loading the correct localization file. I suggest you to put the load_plugin_textdomain function right after the init_plugin_constants function.
By doing this, the PLUGIN_LOCALE variable is instanciate and so the translation can be effective for the $widget_opts array. I've tested it and the widget description in the widgets menu appears in the correct language.

I let you try this and if I'm right, maybe update the plugin.php file.

Load Scripts and Styles only on pages that use the widget

Currently the widget loads the scripts and styles on every page of the site. Any to have them just load on front-end pages that display the widget?