Strider Core — coming soon

It’s been pretty quiet around here lately, mainly because I’ve been working on something but having trouble hammering the last few problems out of it.

As I work on the various plugins I make for WordPress, I find that there are several common bits of code appearing in all of them, and as I improved it in one place I would then have to go through and copy/paste (with modifications here and there) to the other plugins. This is a pain to keep track of, so I figured it would be a good idea to create a set of “core” files that I could simply drop in and have work. I found this had various implications, such as what happens when two plugins are using the same core set — duplicate function names and conflicts suddenly started popping up. How about when two plugins have differing versions of the core files?

So Strider Core was born. Among other things, I’ve created a system wherein different plugins can all run on Strider Core, and if they each have different versions of the core files, it will figure out which one has the highest version and use that for all of those plugins. Thus if Plugin A includes Strider Core 1.0, and Plugin B has Strider Core 1.1, the 1.1 core will be loaded for both plugins. Thus, activating one plugin can actually improve the functionality of other plugins.

Most of what I’m including in the first go are little bits of polish for the Admin — such as settings links from the Manage Plugins page, Menu icons, and the like. One significant addition, however, (and the thing I can’t quite get working right…) is a third party version checking system. Thus, anyone who makes plugins that are not hosted on WP-Extend will be able to have their plugin check for new versions simply by integrating Strider Core and adding a single line to the code.

That’s the plan anyway.

I’m going to try and get things going this weekend (with some luck), but even if I don’t get the version checking going, I will probably do a “beta” release so people can see what’s happening. I know some people have expressed interest in this system, so perhaps better to get it out sooner and get feedback before the “prime time” release.

If you’re interested, keep a lookout for an update to my Log Deprecated Calls plugin, as that is going to be the first plugin to use the new system.

Posted in Codecraft, Webcraft | Tagged , , | 5 Comments

“Computers in the future…”

I found a rather interesting (and amusing) quote in my recent reading:

In March 1949,[...] an article in Popular Mechanics, describing a state-of-the-art computer called the Eniac, speculated on what lay beyond: “Where a calculator like the Eniac today is equipped with 18,000 vacuum tubes and weighs three tons,” the writer predicted, “computers in the future may have only 1,000 vacuum tubes and weigh only half a ton.” To commemorate the fiftieth anniversary of the half-million dollar machine, the supercomputer of its day, a group of electrical engineering students at the university of Pennsylvania duplicated its circuitry on a silicon chip measuring 7.44 by 5.29 millimeters.

A Shortcut Through Time
George Johnson
p.103-04

Posted in Amusing, Technology | Tagged , , , , | Leave a comment

Comment Quiz plugin v1.1.1

A new version of the Comment Quiz plugin is up. 1.1.1 has some important bug fixes, so if you’re using any earlier version, I highly recommend picking this up.

I finally figured out SVN, so it’s on the official WordPress repository. In layman’s terms that means that automatic update will do the job for you (look at the Plugins page in Admin).

Here’s the link. Check it out for details. Mainly bugfixes since 1.1, but a few other changes in the mix as well….

Posted in Webcraft | Tagged , , , | 1 Comment

Virtual Multiblog 2.5

I’ve just released Virtual Multiblog for WordPress version 2.5. This has some significant bug fixes and other improvements. If you’ve had trouble getting it to work in the past, I’ve reworked the code that determines which blog is active, and I think this will help a lot of people.

A major improvement in this version is the way it handles defaults. Now you can set up defaults in the autoconfig file, and put just the differences into blog-specific config files. For example, if all your blogs use the same database, you can set the database info one time in mb-autoconfig.php, and then make blog-specific config files that only contain the table-prefix and nothing else.

If you are upgrading, from a previous version, please note the following instructions:

Upgrading

1) Upload the new multiblog folder to your wp-content directory. Copy wp-config.php and wp-config-vmb.php to the root WordPress directory. [Update: New versions of VMB no longer use the wp-config-vmb.php file. If you have it you can get rid of it; if you *don't* have it, don't worry about it. ;-) ]

2) The system no longer uses define() in the config files. Instead we are setting constants via an array called $vmb_const[]. For backwards compatibility, defines in blog-specific config files will still work for now (though it is deprecated). Any constants set in the autoconfig must use $vmb_const[].

3) Note that both mb-autoconfig.php and mb-config-{blog}.php will now be loaded (previously it was either/or). Anything set in autoconfig will be overridden by a matching pref in a blog-specific file.

That’s about it. Check out the readme and the FAQ if you’re having issues. Here’s the page again: Virtual Multiblog for WordPress.

Posted in Webcraft | Tagged , , , | 17 Comments

Virtual Multibug

I received a comment recently tipping me off to a bug in my Virtual Multiblog system for WordPress. In certain cases, the system will show one particular blog no matter which address you go to.

If you’re having this problem and you’re using the $vusers[] list, try changing the order of the $vusers[] list. This alone may fix things.

I’ll try to get a “real” fix out soon (probably this weekend). A new version should be coming out anyway within days. :)

Posted in Webcraft | Tagged , , , , | Leave a comment

JavaScript Pull-Quotes 2.2 for WordPress

I just uploaded the new version 2.2 of my JavaScript Pull-Quotes plugin for WordPress.

Improvements:

  • German translation (Danke Mattias… or is it “Dank“?)
  • Updated the .po files for people creating or updating translations
  • Improvements to how the system handles changes to the contents of the “styles” folder.
  • A menu icon for those using Ozh’s Admin Drop Down Menu plugin

…plus the usual regimen of minor code improvements here and there.

Posted in Webcraft | Tagged , , , | 6 Comments

Hit a Moving Target in your WordPress Plugin

In recent changes to WordPress code, users are more than ever able to customize folder and file locations. [Edit: Refers to WordPress 2.6] The wp-config.php file can now be located one directory up from the one containing WordPress. The wp-content folder can be moved arbitrarily, as can (separately) the plugins folder. What’s a poor plugin author to do in keeping track of these ever-moving targets?

When those last two folders are moved, it is done by defining specific constants: WP_CONTENT_DIR and WP_CONTENT_URL for the wp-content folder, and WP_PLUGIN_DIR and WP_PLUGIN_URL for the plugins folder. In plugins it’s best to use these, except that they are not defined in a default setup, and don’t exist in earlier versions of WordPress.

The solution, fortunately, is simple: Check if they are already defined. If they’re not, then the folders are in the default locations and you can define them accordingly. Then just use the constants as normal. Here’s the code; just drop this somewhere in the beginning of your plugin:

if ( ! defined( 'WP_CONTENT_URL' ) )
	define( 'WP_CONTENT_URL', get_option( 'siteurl' ) . '/wp-content' );
if ( ! defined( 'WP_CONTENT_DIR' ) )
	define( 'WP_CONTENT_DIR', ABSPATH . 'wp-content' );
if ( ! defined( 'WP_PLUGIN_URL' ) )
	define( 'WP_PLUGIN_URL', WP_CONTENT_URL. '/plugins' );
if ( ! defined( 'WP_PLUGIN_DIR' ) )
	define( 'WP_PLUGIN_DIR', WP_CONTENT_DIR . '/plugins' );

There are a couple things to note:

  • By defining these, you might actually fix problems in other plugins — ones that assume these are defined and call them without checking.
  • I recommend not using the older PLUGINDIR constant at all. It is both obsolete and problematic. Use WP_PLUGIN_DIR instead.
  • You might be tempted to set WP_PLUGIN_DIR as something like dirname(dirname(__FILE__)). Don’t. First, it’s inefficient, as it unnecessarily calls dirname() twice. Second, I’ve seen (albeit unusual) situations where it caused problems*.

So. Not so complicated after all — it’s just one of those rote things that’s helpful to know. Use those four constants and you shouldn’t go wrong finding the right paths in WordPress.

*: Specifically, a plugin was being shared between two WP installs with a symlink. Running in the second blog the plugin was calling the directory of the first blog.
Posted in Codecraft, Webcraft | Tagged , , , , | 4 Comments

Chrome Rocks

Just trying out Google’s new browser, Chrome. The admin back end for WordPress (that is, the page I’m working on as I type this) is blazingly fast running on Chrome. Faster than Firefox, IE or Safari — as in: No Contest.

Google set out with a specific goal: to create a browser that is designed to run mature, full featured web applications; and at first blush, it appears that they have entirely succeeded. I haven’t even tried it on Google’s own applications, such as their online word processor.

The design of this browser is quite different from other browsers, especially under the hood. I’ll probably keep Firefox for general browsing, but I will almost certainly use this for “application” use, from blogging to online banking.

Bravo.

(…and get that Mac version released!)

Posted in Gadgets and Gewgaws, Technology | Tagged , , , , | Leave a comment