New Version of Sub-directory Plugin… now acts more like WordPress

I’ve updated the subdir-mu-plugins Plugin to behave a little bit more like WordPress’s plugins and a little less like WordPress MU’s plugins. The latest version (0.42.2) can be found here.

Here’s a little background:

WordPress single instance will only load files that have the “Plugin Name:” directive. This is partly related to the fact that WordPress supports disabling plugins through a user interface. WordPressMU supports this feature as well for the plugins placed in the “wp-content/plugins” directory. But these plugins are enabled and disabled on a blog by blog basis. For those plugins in “wp-conten/mu-plugins” it will load all PHP files. So for example, if a plugin has extra support PHP files that aren’t safe to load all the time (but can be loaded at the right time by the plugin for example) these types of plugins don’t work well in WordPressMU.

My original version of this subdirectory plugin was intended to mimic the original WordPressMU behavior of loading all php files. Well, this seemed like a good idea at the time, but really the point of this plugin was to allow you to use more WordPress (non-MU) designed plugins… those that lived in subdirectories. And well, many of those plugins also depend on WordPress’s behavior of not loading PHP files that don’t contain the “Plugin Name:” directive. So I’ve decided this original behavior wasn’t the best idea.

The new version will scan subdirectories and attempt to read the plugin-info from all PHP files and only load those PHP files who have a “Plugin Name” directive.

I’ve now changed the behavior of this subdirectory loading plugin to behave a little more like WordPress. Namely it will only load files from subdirectories that have a “Plugin Name” directive.

The Case of the Disappearing TinyMCE

I’ve been having off and on problems with my TinyMCE rich text editor disappearing from WordPress… At first it seemed very random, sometimes it was there sometimes it wasn’t. Then it seemed like the problem went away, as in TinyMCE didn’t go away, and then the problem came back, as in TinyMCE was nowhere to be found.

Well, this weekend I finally figured out at least one thing that would cause this problem to happen.

Apparently one of my plugins was outputting an extra couple lines of non-php at the end of the file. Although this seems like a perfectly innocuous thing it causes big trouble for TinyMCE specifically the gzip support built in to the wordpress/tinyMCE integration.

So imagine this…

<?php
/***************************************
* Example of PHP that does nothing, except
* break TinyMCE.
*
* Notice that after the 'end php tag' there are
* two blank lines.
****************************************/
?>
 
 

These two extra lines will break TinyMCE. I haven’t found a minimal reproduce case yet, but I am sure this is related to the call to ob_start(”ob_gzhandler”); This sort of makes sense in that ob_start() is a relatively sensitive function insofaras you can’t call echo or other functions that output to the main output stream from within a callback function, but we’re not really doing that. I suspect there is some kind of a bug in ob_start() or in the ob_gzhandler handler that doesn’t like these kind of non-PHP outputs in the middle of a PHP stream.

Another case I found which creates this same behavior is…

<?php
/***************************************
* Example of PHP that does nothing, except
* break TinyMCE
*
* Notice that a single space outside of the
* php context.
****************************************/

?> <?php

?>

Anyway, if you see your TinyMCE disappearing on you, then it may be that you have a plugin with a couple extra blank lines at the end of the file outside the context of the PHP script processor.

Creative Common License Chosen

I have decided to utilize the “Creative Commons Attribution-Noncommercial-Share Alike 3.0 License” for all code released on this blog. I will be updating all the source shortly to reflect this change.

This work is licensed under a:

Creative Commons Attribution - Noncommercial - Share Alike 3.0 License.

My reasoning behind this choice is as follows:

• I intend for these posts to be informative and educational. They are not intended to be fully functioning implementations. They are intended to represent reusable ideas. Therefore, you shouldn’t need more than this license to learn from what I’m presenting here.
• If you are planning on using this as is, then I would like you to give me the appropriate level of credit. And if you see me on the street, please introduce yourself and say “Thanks Man!”
• If you are planning on using this code as is for commercial purposes, then, well, please contact me. I make my living as a technologist, and if you’re making money off my hard work, then I want some control over that. That being said, I don’t mind teaching you what I’ve learned, and so please feel free to read my code, learn from it, and go about your business as you see fit.

Thanks.

Update to WPMU- Top Posts Plugin

Note, I’ve updated the code to 0.42.1 with the following changes…

• Small bug fix to ‘maybe_create_table’ behavior. Namely, we used to try to load it if this function wasn’t available, and now we simply check that the function is available.

• Added blog_id to the posts returned by get_top_posts. This can be useful in forming correct permalinks to your blog posts.

• Added function zap_setup_post_globals() which in some cases will setup the globals for other wordpressmu templates to work, but this doesn’t always reliably work

You can get the latest code here.

Supporting Subdirectory Plugins in WordPressMU

WordPressMU treats plugins a little differently than standalone wordpress does. Namely it supports two types of plugins. Those loaded and controlled on a per-blog basis (like normal WordPress) which are stored in the wp-content/plugins directory; and those that are loaded for all blogs on all pages, which are stored in the wp-content/mu-plugins directory.

I won’t attempt to explain all the good reasons for why these plugins are segregated, instead this is a quick description of a small feature enhancement to the mu-plugins behavior. Namely, one of the differences between how plugins are loaded from mu-plugins vs. how they are loaded in standalone wordpress or the plugins directory; is that mu-plugins only loads php files in the root directory. (It also happens to include all php files, which is another important difference.)

What if you wanted to cleanup your mu-plugins directory a little and store some plugins in subdirectories. Well, here is a simple mu-only plugin that adds this feature.

Download: here.

Install: Rename this file as .php and place it in your “wp-content/mu-plugins” directory.

Usage:  You can now place mu-plugins into subdirectories of you “wp-content/mu-plugins” directory and they will load like any other mu-plugin.

Sitewide tags for WPMU without core changes

Thanks to the hard work of Dr. Mike, users of WordPressMU have found a solution for implementing site-wide tags and searching without significant changes to the WordPressMU or WordPress core code bases. The basic idea behind the most popular solution is to make an instances of WordPress (classic) that stores a mirror of your WordPressMU sitewide feed. I won’t go into details explaining how this is done, because there is a very clear and well documented process found here in the WordPressMU forums.

I’ve used this solution and it appears to work very well, and is actually very easy to implement. It took me about an hour when I first set it up.

However, in the process of sharpening my wordpress skill, I wanted to learn a little bit more about filters and actions. After seeing what some other people have done with filters, I’m pretty much convinced that if you know the right filter to add, you can probably implement almost anything without making core changes. So, I wanted to try to build a solution that allows you to use Dr. Mike’s cool workaround without making any changes to the wordpress core code. This plugin does that.

Actually, it’s really simply, it just adds a “post_link” filter that returns the $post->guid as the permalink. This is essentially the same thing that was being done by the change to “link-template.php” that Dr. Mike’s instructions say to do for step 6.

Download: You can get a copy of the plugin here.

Install: Standard stuff, rename the file to .php, place it in your plugins directory (in this case on your wordpress install, not on your wordpressmu install) and activate it. After you have it installed you can revert your changes to “link-template.php” back to the original.

Usage: nothing special to do.

WPMU- Top Posts Plugin

I’ve hacked together a prototype of a Top Posts plugin for WordPressMU.

The concept is to create a global table that stores the blog_id, post_id, and time for each hit to a post/page, and then allows you to get list of the posts with the most hits. This is an early early version.

You can download it here.

Installation:

Put this php file in your ‘wp-content/mu-plugins’ directory. Sit back and enjoy.

Usage:

The simple version would be to call:

<?php zap_top_posts_html(); ?>

This will return a <ul>…</ul> block of html.

But you can also use this much like you would use get_posts() in any template. For example, the following should also work…

<ul>
 <?php
 $myposts = zap_get_top_posts();
 foreach($myposts as $post) :
 ?>
    <li><a href="<?php echo $post->guid; ?>">
	<?php the_title(); ?></a>
	[<?php zap_the_post_hits(); ?>]</li>
 <?php endforeach; ?>
</ul>

Anyway, this is just a prototype. I haven’t really done that much testing. I have no idea how well it will perform in general. I know there are a couple bugs in there. As I fine tune this, I will post additional updates.

Known issue: You can’t use the get_permalink() and the_permalink() tags becuase they depend on other global variables that are not properly set up with these functions. If you want the link to the post use $post->guid.