One thing I discovered yesterday, though, is that one line of code makes the difference between the Visual Editor using a custom, static image as the button and the Visual Editor using a span that you can stylize with CSS (to fit better with the native Visual Editor appearance).

In your TinyMCE plugin definition file (editor_plugin.js), when you use the addButton method for the editor, if you define an img property for that object, a custom, static image will be used. However, if you do not define that property, the Visual Editor will instead create an empty span with the class of mceIcon and a secondary class of mce_[plugin_name].

The [plugin_name] variable shown above is the name you assign to the plugin class instance when you use the tinymce.pluginManager.add method.

Therefore, the two pertinent snippets of your code might look like:

/* Open your plugin code with a tinymce.create method
	and some other code*/
// Register example button
ed.addButton('my_mce_button', {
	title : 'This is a button',
	cmd : 'myButtonCmd'
});
/* More code in here */
// Register plugin
tinymce.PluginManager.add('myButton', tinymce.plugins.myButtonPlugin);

Notice that the code above does not include an img property in the addButton method. That means that WordPress and TinyMCE will automatically assign a class of mce_myButton to an empty span where the button is supposed to appear in the visual editor.

Then, instead of using a static image, you can use CSS to stylize the span, adding background images for the normal state of the span and the hover state.

If you do, however, include the img property (which might look something like the code below), TinyMCE/WordPress will use that image for the button, meaning that the normal state and the hover state of the button will look basically the same (the background image that WordPress uses to create the border around the buttons will still change slightly when you hover over the button, though).

// Register example button
ed.addButton('my_mce_button', {
	title : 'This is a button',
	cmd : 'myButtonCmd',
	image : url + '/img/myButton_icon.gif'
});

Related posts:

1. WordPress: Adding a Proper Visual Editor to Your Plugin
2. Handling One Radio Button With JavaScript
3. Enable Theme Editor in WPMU

What’s worse, some of these samples even go so far as to include and use their own version of TinyMCE; which obviously incurs a great deal of overhead and makes the plugin package unnecessarily bloated.

There is a fairly simple solution, though. The first thing you need to know about is the the_editor() function built into WordPress. This function will output the necessary textarea, etc. to build the visual editor.

The next thing you need to do is to enqueue and invoke all of the necessary JavaScripts to make the editor work as expected. To do that, you’ll need to write a function similar to the code below. I recommend placing this function inside of a class definition to avoid any potential namespace conflicts.

function enqueue_editor() {
	wp_enqueue_script('common');
	wp_enqueue_script('jquery-color');
	wp_admin_css('thickbox');
	wp_print_scripts('post');
	wp_print_scripts('media-upload');
	wp_print_scripts('jquery');
	wp_print_scripts('jquery-ui-core');
	wp_print_scripts('jquery-ui-tabs');
	wp_print_scripts('tiny_mce');
	wp_print_scripts('editor');
	wp_print_scripts('editor-functions');

	/* Include the link dialog functions */
	require_once ABSPATH . 'wp-admin/includes/internal-linking.php';
	wp_print_scripts('wplink');
	wp_print_styles('wplink');
	add_action('tiny_mce_preload_dialogs', 'wp_link_dialog');

	add_thickbox();
	wp_tiny_mce();
	wp_admin_css();
	wp_enqueue_script('utils');
	do_action("admin_print_styles-post-php");
	do_action('admin_print_styles');
	remove_all_filters('mce_external_plugins');
}

As far as I can tell, all of these scripts and actions are necessary in order for the editor to work correctly. I assume, if you are not using the media upload feature, you could avoid calling wp_print_scripts('media-upload');, but that’s probably the only one.

Finally, you’ll need to use some specific HTML code to wrap your editor (in order to ensure the JavaScript works correctly). You should use something similar to the following when outputting the editor:

<div id="poststuff">
	<div id="<?php echo user_can_richedit() ? 'postdivrich' : 'postdiv'; ?>" class="postarea">
		<?php the_editor('<p>Some sample content.</p>'); ?>
	</div>
</div>
/* Insert the dialog box that's used by the "link" button */
add_action( 'admin_footer', 'wp_tiny_mce_preload_dialogs' );

Notes (and Caveats) on Use

• If you choose to give your editor a unique name/ID (other than “content”), you will need to add some CSS to your plugin to size the HTML editor appropriately. There is already a CSS definition for #content to make it stretch to the width of the editor properly, but if you assign a unique ID, that CSS obviously won’t apply (and your HTML editor will most likely only stretch about halfway across the editor area).
• There is a minor bug that keeps the media buttons from working properly if you give your editor a name/ID other than “content”.
• Unfortunately (at this time, at least), this only works to create a single visual editor on a page. If you attempt to include a second editor, there are various JavaScript issues/bugs that will cause the second editor not to work as you might expect. If you have the need to use multiple visual editors on a single page, you will need to look for another solution, sadly. There have been multiple requests to enhance the functionality of the the_editor() function to support multiple instances on a single page, but most I’ve found have been shot down as “wontfix” issues in the source trac.

Related posts:

1. Quick Tip: WordPress Visual Editor Button Icons
2. Adding Settings Fields to Your WordPress Plugin
3. Enable Theme Editor in WPMU

The Microsoft Express software includes:

• Visual Web Developer 2010 Express
• Visual Basic 2010 Express
• Visual C# 2010 Express
• Visual C++ 2010 Express

If you are planning to use the Microsoft Express software, check out the very detailed FAQ which offers insight into what you can and can’t build using the free versions of the development software.

Related posts:

1. Office 2010 and Chrome OS
2. Microsoft Releases IE8 Comparison Chart
3. Zend Releases Studio 7.0 Beta

Occasionally, when working on my Web server, I need to create a new user on the server and grant one or more other users permission to view and edit files within the new user’s home directory. This task, in itself, does not seem all that difficult on the surface. However, because most Unix servers are set up (and rightfully so, for security purposes) not to allow most users to navigate outside of their own home directories, it becomes a problem.

Let’s say, for example, that you have two users on your Web server that you want to allow permissions to view and edit each other’s home directories, but you don’t want them to have access to any other files and folders on the Web server.

For purposes of this example, let’s call them user1 and user2.

You create user1 on your Web server. In the administration control panel of my hosting package, when new unix users are created, they are automatically added as new users for all of the other modules (FTP, usermail, etc.), home directories are automatically created for them and a new group is automatically created for the user. With the possible exception of automatically adding them to the other modules, I believe most unix boxes are set up this way.

Therefore, now that you’ve added “user1″ to your box, you now have a new folder located at /home/user1, you have a new group called “user1″ and user1 is now allowed to FTP into his home directory. However, provided your FTP and SSH servers are set up properly, that user cannot navigate outside of the /home/user1 directory.

Now, you create “user2″ on your unix box. Once that’s completed, you now have a directory located at /home/user2, you have a new group called “user2″ and user2 now has FTP permissions to navigate only within the /home/user2 directory.

Already, you can probably see the problem. Because user1 cannot go any higher in the directory structure than /home/user1, that obviously means he cannot navigate into /home/user2.

In order to solve that problem, we have to take a few simple steps.

First, we need to open a shell. In the case of a remote Web server, you would do so using an SSH connection. However, if this is a local machine, you can do so fairly easily by simply opening the terminal.

The first thing you want to do is “su” (switch user) as root. You do that simply by typing:

# su root

Then, enter the password for the root user when prompted.

Now, within the shell, you are performing all actions as the root user (be careful doing this, and make sure to exit the root account when you are finished).

The next step is to create new directories for each user. Within /home/user1, you should create a directory for user2. It could be something as simple as /home/user1/user2files. You would do that in the following way:

# mkdir /home/user1/user2files

Now, do the same for user2:

# mkdir /home/user2/user1files

The next step is to mount each user’s home directories as virtual directories for the other users. You do that by typing the following commands:

# mount --bind /home/user1/ /home/user2/user1files

# mount --bind /home/user2/ /home/user1/user2files

What you’ve done by typing those two commands is the following: You have now set up the Unix file system to look inside of /home/user1 whenever someone navigates into /home/user2/user1files. Essentially, /home/user2/user1files is now simply an alias of /home/user1. The second command did the same basic thing, except that it aliased /home/user2 as /home/user1/user2files.

The next step is to make sure your users will have the appropriate permissions. There are two things you need to do. First, you need to add user1 as a member of the “user2″ group, and vice versa. Within my administration area, I did this by simply editing each group and adding the appropriate members.

Finally, make sure that the directories are set up to allow group members to manipulate the files. By default, most Web servers will automatically assign the permissions to new files as 664. That means that the original user that generated the file has read and write permissions on the file, and so does the group to which that user belongs.

That’s great, but it causes one minor problem. If user1 adds a new file to /home/user1/user2files, the user and group will both be set to “user1″. If we decided not to add user2 as a member of the “user1″ group, then user2 won’t have any permissions over those files.

That’s a fairly easy fix, however. To accomplish this, you need to set the GID for the /home/user2 directory. Setting the GID basically means that any files added to that directory will automatically inherit the group that owns the directory, no matter which groups the file’s creator belongs to.

Within my administration panel, I did this by simply navigating to the folder within the File Manager, then using the “Info” button to set the GID. On most *nix boxes, you can do this by right-clicking on the folder itself and selecting “Properties” (I believe).

Now, no matter what files are added to /home/user1/user2files (or /home/user2, since /home/user1/user2files simply points to /home/user2) and no matter who adds them, the group will always be set to “user2″.

While you are editing the properties of that directory, you need to make sure that “Sticky” is not enabled. If “Sticky” is enabled, only the file’s owner will have permission to remove the files. Group members will not be able to delete the file.

Finally, you need to edit your fstab configuration file to finish mounting the virtual directories you created. To do that, open the shell and su as root, again. Type the following command:

# vi /etc/fstab

That will open a program called “vi” (or Visual Editor). I found a good link with instructions explaining how to use vi. Once you’ve opened fstab in vi, you need to add a line for each folder you mounted. The lines should look like:

/home/user2  /home/user1/user2files none bind 0 0

If you don’t add the mount commands to the fstab file, then the changes you made will all be lost whenever the server is restarted. The format of that line should be (items highlighted in red are the only things you should change):

/real/directory /virtual/directory none bind 0 0

Once you complete all of those steps, both of your users should be able to work within each other’s home directories without you having to grant them access to other files and folders on the computer.

Related posts:

1. fileNice – a PHP-based file browser
2. User Interviews – Analysis Simplified
3. Is Your Site User Friendly?