The fertile playground of a WordPress developer
More Testing, Different Plugin

Goodie, there’s a new version.  Let’s hope this works.

This is Just Crazy

OK, so I’ve been playing around with the postratings.php plugin that was supposedly for WordPress MU.  Like hell, it is.  I’m still jerking around to try and get this thing working, and so far, all I’ve managed is to make the bastard not bork my entire blog.  At least, so I think.

But of course, if you’re reading this, then I’ve definitely avoided a catastrophe before I went to sleep this evening.

OK, I Need to Learn More About Plugins. . . .

I’ve posted two new articles a few days ago. Their sole purpose was to test the Clean Trunks plugin in the MU environment. It appears as though it will not work without some modification.

The first, most obvious trouble seems to be that Clean Trunks needs to be kept in its own directory, and cannot have the two component files dumped into the /plugins directory on their own. If I put the plugin component files directly into the /plugins directory, the plugin engaged enough to pop an error message stating “the second argument was invalid in file clean_trunks.php on line 121. That seems to suggest that the call to create the object isn’t working correctly, causing this line to be in error:

if( in_array( $word, $this->stopwords ) ){

I take this to mean that the object that the $this variable refers to does not have the stopwords variable defined or that the object is not getting created. I’m not sure. I didn’t get a chance to work on this problem, specifically this weekend.

What I have done was to install the Plugin Manager plugin off the WPMUDEV.org site. This plugin makes it possible to globally activate or deactivate plugins in individual blogs. This brought up an interesting question for which I have found the confusing answer here. Namely, what is the difference between the /plugins folder and the /mu-plugins folder?

The answer is that the /mu-plugins folder is meant to contain plugins which are turned on globally with no options available to individual blog administrators or users. The /plugins folder is meant to contain plugins which are globally *available* but not turned on unless the blog administrator chooses to do so. However, in order for the blog administrator to make these choices, an option under Site Administration must be turned on that allows for a “Plugins” heading in the Administration Panel.

Whoopha! That’s a little confusing. Especially given the fact that plugins for the MU environment seem to be hit-or-miss, with little to no documentation. Some work in one directory but not the other, when really, you’d want to have the option to use both in this environment. I know I’ve been doing it wrong for the last week, myself. I’m going to need to rethink how things work, but really, going forward I would like to write plugins that take into account which directory it is installed in and provides appropriate options for both.

But I’ve got a lot to learn. Unlike my previous adventures with WordPress, this time, I’m trying to really get a handle on how the core works, if only in outline form. To that end, I have used grep on a Linux box I have to search out every instance of the do_action() keyword, documenting all the actions associated with WordPress MU. I now have a complete list of those actions, along with the files that reference them. I’ll eventually be putting together a Wiki to provide them here, but I’ve been having a bit of difficulty in loading the MediaWiki.

I Hope This Plugin Works

Testing the Clean Trunks plugin in the µ environment. We shall see, bizzle.

So far, no dice.  No errors, either, but no dice.

MU Blogs, Ordering and Aggregation

As I’ve come to discover, both from my own experience and also from reading here, there doesn’t seem to be any particularly easy way to aggregate data across multiple blogs in WordPress MU. To some extent, I suppose, this makes sense: the ‘Pressers had anticipated using MU for web hosts that wanted to provide easy-setup blogs for their customers. But for those of us looking to fuse the multi-blog concept into a cohesive whole, this is a bit frustrating.

MU saves each new blog in the database by creating a new set of standard WordPress tables, adding a prefix that includes a number representing the order in which it was created. For example, the first blog created would use the prefix wp_1_* and the next would be wp_2_. That’s great for dB organization, but not so great for combining the blogs with an eye towards creating anything useful. » Continue Reading…

Testing Sitemaps Plugin

Just checking a sitemaps plugin that I’ve downloaded and installed.  It says that you need to first post a blog entry before the sitemaps are created, . . .  so, that’s what I’m doin’.

Great Adventures in WordPress MU

This blog has officially been upgraded to a WordPress MU site! I’ve been thinking about making some changes to my political website, DragonFlyEye.Net, and I’ve decided that this is the way I’d like to go.

I last did a major overhaul of the site design about a year or so ago. I’d been learning more and more about how to make a proper website, including a lot of lessons learned from working with WordPress, and so I pooled those lessons into a new design that was much more flexible than anything I’d worked with in the past. While the “blog” continues to be driven by WordPress, the Flagship content is driven by my own design. The site is currently template-based, fully database-driven and even has a rudimentary “Widgets” thing going with sidebar pieces that I can mix and match. » Continue Reading…