Tag: WordPress

Updated Method to Create WordPress Child Themes

Twenty Ten Child Theme Mods

Once upon a time all that a WordPress Child Theme needed was to use an @import rule to bring in all the styles from the parent theme stylesheet. Evidently, that method still works as I’ve been using a couple of “old” child themes on live sites, until now.

Even so, it would be better to use updated and preferred methods for creating WP child themes. When The Codex says something is no longer best practice, we should pay attention.

Using @import to bring in other files costs us time. Nobody appreciates a slow site so any way that we can speed things up for our visitors is a good thing.

The correct method of enqueuing the parent theme stylesheet is to add a wp_enqueue_scripts action and use wp_enqueue_style() in your child theme’s functions.php.

A child theme requires one file, style.css, declarations in which will override those of the parent theme, but now we need a second file, called functions.php, to enqueue the new stylesheet. Continue reading Updated Method to Create WordPress Child Themes

WordPress Roles and Capabilities Trump User Levels

When someone signs up on a WordPress blog, the default role is as a subscriber. Once a subscriber logs in they can view and edit their profile, which includes things like username, password and contact info, but that’s all they can do. A subscriber can’t write a post, edit a page or upload any files. A site member would need higher privileges to do any of those things.

To handle various levels of user privilege, a system was developed in WordPress that was originally called the User Level System. In this system many capabilities were identified and these capabilities were classified according to the level of authority required or the privileges needed to perform certain tasks.

For example, a higher level of privilege was deemed necessary to edit another writer’s post. Accordingly, a user level that is now called Editor was given a variety of capabilities ranging from edit_others_posts to delete_published_posts. A lower user level, now called Author, was awarded a slimmer set of capabilities and it doesn’t include modifying others’ work.

Make Sure Site Visitors Can Register

To make sure your visitors can sign up to your blog, see the General Settings page under “New User Default Role” for a spin box that has the options of subscriber, administrator, editor, author and contributor. Default role is subscriber.

If you want people to be able to register on your blog, tick the Membership box next to “Anyone can register”, then click on the Save Changes button at the bottom of the page to make it so.

User Levels Supplanted by Roles

WordPress introduced user levels in version 1.5, but quickly replaced them in version 2.0 with Roles and Capabilities. User levels are deprecated since WP 3.0, but we may see them used in older plugins or themes, so it’s worth knowing about them. Basically, higher user levels have more privileges and can write, edit, post, publish and manage more than their lower-level counterparts.

The lowest user level equates with the subscriber role. Subscribers can sign in, see and modify their own profile, and besides that they can read posts and pages and comment.

The highest user level is reserved for the site administrator or blog owner and that would include level_0 up through level_10, the highest user level.

Prior versions of WordPress had 11 levels from level_0 to level_10, with level_0 being the lowest level and least capable, while level_10 users were able to do anything and everything with the WordPress blog.

WordPress defines users as the blog visitors who register and login to the web site. The Administrator is created during installation of the WordPress software. The Admin level has absolute power over all other users being able to add or delete users, edit their writings and promote or demote anyone to a different role.

Roles correspond to the old user level system like so:

  • Subscriber = level_0
  • Contributor = level_0, level_1
  • Author = level_0 to level_2
  • Editor = level_0 to level_7
  • Admin = level_0 to level_10

Many blog owners don’t need any special roles as they are the Admin and they control everything with their personal online spaces. Beyond the Admin there is a new level called Super Admin that comes into play when a network of sites needs to be administered. Multisite WordPress installations came into use as user levels were being deprecated, so there is no equivalent user level number for the Super Admin.

Capabilities for Standard Roles

The standard roles in WordPress are Administrator, Editor, Author, Contributor and Subscriber, in order of decreasing privilege.

The Admin user is created when WordPress is installed. Administrators have all capabilities, including the privileges to install, activate, edit and delete plugins, install, delete, edit or switch themes, edit or delete any post or page whether published or private, edit the dashboard, manage users, categories, links, options, comments and files, and import or export parts or all of the WordPress blog.

Editors have fewer privileges than admins, but they have the powers to manage their own and other’s posts. They can edit and delete pages or posts whether they’re published or private. Editors have the capabilities to manage categories, links and comments, and they can upload files. Editors can post code in pages, posts and comments, so make sure you trust your editors because they can post HTML markup or even JavaScript to your blog.

Authors have fewer privileges than editors and they all center around writing posts. Authors can publish, edit and delete the posts they create, even published ones. However, they cannot edit or delete other’s posts. Authors cannot create or alter Pages. They can upload files to add new media, and of course, read and comment on posts.

Contributors have even fewer privileges than authors. Contributors can edit, delete and read their own posts. Posts created by Contributors will be held in moderation for an Editor to approve and publish.

Finally, Subscribers have but two capabilities. They can read posts and they can view and update their own profile.

Modifying and Managing Roles

Several WordPress plugins exist for managing roles and capabilities. The plugins listed here get very high marks at the WordPress Plugin Directory.

Members Plugin

Members plugin is described as an “extensive role and capability management system” that allows you to create, edit and delete roles and capabilities for those roles. Using shortcodes, this plugin lets you control access to your content, including the ability to make the entire site and its RSS feed private.

Role Scoper Plugin

Role Scoper plugin is a complete solution for assigning permissions and roles to specific pages, posts or categories. Independent of WP roles, users of any level can be elevated to read or edit any content. Alternatively, content can be restricted from any user regardless of their WP roles or capabilities.

User Access Manager Plugin

User Access Manager plugin lets you “manage the access to your posts, pages and files”. Reading and editing permissions for pages and posts are assigned via user groups. Registered users are placed into user groups for which appropriate access rights have been created. User groups can supplement or take the place of WP roles for providing or preventing access to pages and posts.

Advanced Access Manager Plugin

Advanced Access Manager plugin is a “powerful and flexible Access Control tool” that supports single and multisite WordPress installations. Roles can be created and capabilities assigned per role. The Dashboard and Admin menu can be filtered to show only the important bits for each role.

User Role Editor Plugin

User Role Editor plugin allows you to create new roles and customize their capabilities. Options include setting the default role for new users, removing capabilities from users, deleting roles no longer needed, and changing capabilities on a per user basis.

Gary’s ultimate guide for assigning user levels to roles and capabilities is most useful for those wanting to modify or create plugins and themes. Many code snippets are shared in this post for assigning capabilities, testing whether a user has a certain capability, and adding new roles and capabilities.

Loading WordPress with One jQuery

If there are several plugins on your WordPress sites there may be more than one copy of jQuery, or other script, that’s loaded, especially if you’re relying on the same scripts for control of the site theme as well. Only one copy of each script should be loading up. More than that represents wasted bandwidth for you and wasted time for your site visitors.

To control what scripts are used on your site it may be wise to learn how to disable scripts from loading in the first place. Similar methods can be applied to streamline the number of scripts or stylesheets loaded onto your site.

Check out this great tutorial on disabling scripts and styles. Thanks for sharing, Justin!

You’ll need to modify the functions.php file of your theme to remove styles or scripts. The technique is similar in each case.

  1. Find the ‘handle’ of the script that you’d like to remove.
  2. Pass the script handle to wp_deregister_script().
  3. Wrap one or more ‘deregistrations’ in a new function, like my_deregister_javascript() in this example.
  4. Use add_action() with wp_print_scripts method and add your new function to the functions.php file of your theme.

[plain]
function my_deregister_javascript() {
wp_deregister_script(‘jquery-form’);
}
add_action(‘wp_print_scripts’, ‘my_deregister_javascript’);
[/plain]

From the reference on add_action in the WordPress codex we can see that two arguments are required, namely the $tag or handle of the script and the $function_to_add or the function to which the script is hooked. Two optional parameters can be added to the add_action function to specify the $priority or the order in which the functions are executed, and $accepted_args or the number of arguments that the function accepts. Generically,

[plain]
add_action( $tag, $function_to_add, $priority, $accepted_args );
[/plain]

In the example above we’ve used ‘wp_print_scripts’ for $tag and ‘my_deregister_javascript’ for $function_to_add while the optional $priority and $accepted_args were not used. This will hook the new function ‘my_deregister_javascript’ to the action called ‘wp_print_scripts’.

Alternatively, a WordPress plugin could be used to manage the scripts and actions called for on your site. Use Google Libraries is a plugin built to detect the scripts needed for a site to run properly, including all the scripts called for by plugins and the active theme. Scripts are loaded in the proper order taking into account dependencies, whether previously known to WordPress or whether provided by the plugin and theme authors. This plugin uses the content delivery network (CDN) of google to supply the most popular javascript libraries, including jQuery and jQuery UI, among others.

Include jQuery or JavaScripts in WordPress

Plugin and theme authors use jQuery for their special effects, but there seems to be some confusion about the proper way to include JavaScript files in WordPress. If you’d like to use jQuery effects on your pages or in your theme, or if you want to include any javascript plugin or personal script, read on to see how to do it properly with WordPress sites.

Queue Up Your Scripts with Actions

Since jQuery itself is already included in the core of WordPress, how should we include a javascript file that we’ve created or even one of the popular jQuery plugins that rely on jQuery? WordPress helps us in this endeavor with a function called ‘wp_enqueue_script()‘ and two actions that are used to call this special function.

The actions are used for either the user side or the admin side, depending on the purpose of your javascript. Use the ‘wp_enqueue_scripts‘ action to call wp_enqueue_script() for use in your themes. If the script functionality is needed on the admin side, use ‘admin_enqueue_scripts‘ action instead.

The format of the wp_enqueue_script() function call is as follows:

[plain]
wp_enqueue_script(‘$handle’, ‘$src’, ‘$deps’, ‘$ver’, ‘$in_footer’);
[/plain]

where $handle is the name of the script as a lowercase string, $src is the URL to the script, $deps is an array of scripts that the script you’re calling depends on or the scripts that must be loaded first for your script to work, $ver is the script’s version number in string format, and $in_footer is a boolean value to indicate whether the script should be loaded in the <head> or at the end of the <body> in the footer.

The $handle string is the only required parameter, so the other four parameters are optional. The $src, $ver, and $in_footer parameters default values are ‘false’, and $deps defaults to an empty array.

It seems that $src would need to be a required option, but WordPress already knows about several scripts and where to find them. Consult the list of default scripts included with WordPress to pick up their handles.

For example, to queue the jQuery Color plugin, we’d simply use this:

[plain]
wp_enqueue_script(‘jquery-color’);
[/plain]

To include a script and specify the source, try this for including the jQuery Cycle plugin in the <head>:

[plain]
wp_enqueue_script(‘jquery-cycle’, ‘URL’, array(‘jquery’), ‘1.3.2’);
[/plain]

The URL should not be a hard-coded value for local scripts. Refer to the Function Reference pages in the codex for proper URL formats for plugins and themes.

Register Your Scripts First

Make sure that your scripts are registered first before calling them. Registering a script basically tells WordPress where to find the code for your script. Use the function wp_register_script() to specify the location and handle of your script. The format is similar to the wp_enqueue_script() function:

[plain]
wp_register_script(‘$handle’, ‘$src’, ‘$deps’, ‘$ver’, ‘$in_footer’);
[/plain]

The parameters have the same meanings and default values as used with wp_enqueue_script(). When in doubt, see what the WordPress Codex has to say about wp_enqueue_script() and wp_register_script().

Create a Function for the Header

Put it all together using wp_register_script(), wp_enqueue_script(), and the appropriate action to call the functions. Create a simple function, like id_scripts() below, and use the add_action() hook to queue up the scripts.

[crayon]
function id_scripts() {
wp_register_script(‘script_alpha’, ‘URL’, array(‘jquery’), ‘1.0’);
wp_enqueue_script(‘script_alpha’);
}
add_action(‘wp_enqueue_scripts’, ‘id_scripts’);
[/crayon]

As a side note jQuery itself doesn’t have to be queued via a statement like wp_enqueue_script('jquery');, because it is listed as a dependency of ‘script-alpha‘ in this case.

When enqueuing a custom script that depends on a jQuery plugin, specify jQuery and its plugin in the $deps parameter of the wp_register_script() action for the custom script. For example, if your custom script depends on the jQuery Cycle plugin, which itself depends on jQuery, use array('jquery', 'jquery-cycle') for the $deps parameter. This specifies that both jQuery and its plugin Cycle should be loaded (in that order) before the custom script.

Place this code in the header.php of your theme. Remember, first register the javascript file, then enqueue it and make sure this is done before the wp_head(); statement. Your custom script can then be placed in header.php after the wp_head() call.

Use Theme functions.php to Safely Reference Your Script

When using a child theme take note that the header.php in a child theme will override the default header.php in the parent theme. Instead of placing the script-queuing code in the header, one could more safely put this code in functions.php. The advantage to that way is that the functions.php of a child theme is processed before the functions.php of the parent theme. Both the parent and child theme functions.php are processed, unlike header.php files.

If you’re the least bit unsure about messing with header.php, then just use functions.php to queue up your javascript files. Don’t forget the opening and closing PHP tags in functions.php, else it won’t work. Put the javascript that would come after the wp_head() call in a separate .js file in the child theme and you’re good to go.

Verify that everything is working correctly by viewing the source of the HTML document for a WordPress post that should have the script included. The <script> tags should be visible in the header or in the footer depending on how the scripts were called.