I hunted over the web looking for a way to search an entire MySQL database — all tables, all fields — for text. For the most part I find forums with answers such as “Well, you set up your database wrong”. These kinds of responses remind me of the sequence in the movie “Funny Farm” where the truck driver is trying to find the town of Redbud. In short:

“Hey Mac, how do you get to Redbud?”

“If I wanted to go to Redbud, I wouldn’t start from here.”

Nonsensical and useless. If you’re here now, then this is where you’re starting from; telling me to start from somewhere else is simply a non-answer. Funny in a movie, but frustrating in real life.

Today I came across a most excellent script, the MySQL Database Search & Replace Tool. It’s a PHP page that you can drop into a web site and call from your browser. It will search the entire database for a string of text — exactly what I needed.

In a quick test run it threw out a couple errors but then gave me useful results; so it’s not entirely polished, but quite functional and useful. Kudos to Mark Jackson and Eric Amundson for releasing this great tool!

This article was originally published at Nerdaphernalia. Planet WordPress is authorized to reproduce WordPress-related entries. If you're reading this at any other web site, the site owner is stealing copyrighted work. Please visit the original page:

Feed enhanced by Better Feed from Ozh

For example: Let’s say you want to make a plugin that works with other plugins. For other plugins to be compatible with it, however, they need to provide some new piece of information, and you want to do this with a custom header. So we’re going declare a new plugin header. Let’s call it… oh…. “Demo Header”. Here’s the code; just drop this in a plugin and activate:

function plugin_header_demo( $extra_headers ) {
	$extra_headers[] = 'Demo Header';
	return $extra_headers;
}
add_filter( 'extra_plugin_headers', 'plugin_header_demo' );

Pretty simple, eh? What we’ve just done is added “Demo Header” to the list of headers that WordPress will check for when get_plugin_data() is run. Now, along with Name, Version, Author, and so forth, a value for Demo Header is returned as well.

Note that this is only for cases where you want any plugin checked for this header. This changes the get_plugin_data() function and takes effect every time that function is run, on any plugin.

Want to do it for themes? The code is almost identical:

function theme_header_demo( $extra_headers ) {
	$extra_headers[] = 'Demo Header';
	return $extra_headers;
}
add_filter( 'extra_theme_headers', 'theme_header_demo' );

Note that this does not allow you to alter the pre-existing headers in any way. You can’t, for example, remove the “Name” header.

Personally, I intend to use this for a third-party update check plugin, which will also be incorporated into Strider Core. For that use, I’ll add an “Update URL” header (or similar).

Next up: How to define your own custom get_XXX_data() function that works like the ones for plugins or themes.

This article was originally published at Nerdaphernalia. Planet WordPress is authorized to reproduce WordPress-related entries. If you're reading this at any other web site, the site owner is stealing copyrighted work. Please visit the original page:

Feed enhanced by Better Feed from Ozh

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.

This article was originally published at Nerdaphernalia. Planet WordPress is authorized to reproduce WordPress-related entries. If you're reading this at any other web site, the site owner is stealing copyrighted work. Please visit the original page:

Feed enhanced by Better Feed from Ozh

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.

This article was originally published at Nerdaphernalia. Planet WordPress is authorized to reproduce WordPress-related entries. If you're reading this at any other web site, the site owner is stealing copyrighted work. Please visit the original page:

Feed enhanced by Better Feed from Ozh

I’ve never been too active about showing this to people, because the function required to do it is not one I consider completely stable — I din’t want to show people how to do it only to have it break the next time I update the VMB system. In response to the requests, however, I am adding a function to the upcoming release (currently in private beta). You can have that ability right now, in a way that should not cause problems with later updates — just add a short function to your existing vmb-functions.php file.
(...)
Read the rest of Virtual Multiblog — how to use unique headers on blogs running the same theme (293 words)

This article was originally published at Nerdaphernalia. Planet WordPress is authorized to reproduce WordPress-related entries. If you're reading this at any other web site, the site owner is stealing copyrighted work. Please visit the original page:

Feed enhanced by Better Feed from Ozh

I did a bit of grepping and parsing just now, and in the hopes that it might be of use to my fellow WordPress hackers, here is my list of every defined CONSTANT in the latest WordPress 2.7-bleeding setup.
(...)
Read the rest of WordPress Constants (170 words)

This article was originally published at Nerdaphernalia. Planet WordPress is authorized to reproduce WordPress-related entries. If you're reading this at any other web site, the site owner is stealing copyrighted work. Please visit the original page:

Feed enhanced by Better Feed from Ozh

Insert the following into your theme files where you want the plugin’s widget to appear:

<?php my_plugin_widget() ?>

The slightly more intelligent instructions will understand that the plugin might be deactivated, and suggest you wrap the function in an if() that checks for its existence:

<?php
if ( function_exists( 'my_plugin_widget' ) ) {
	my_plugin_widget();
}
?>

In your own plugins, you can streamline this for the end user by wrapping your function in a custom add_action. How? It’s incredibly easy. Just add an add_action() to your plugin file, like so:

add_action( 'show_my_plugin_widget', 'my_plugin_widget' );

function my_plugin_widget() {
	...
}

Now your users can use one straightforward line in their templates.

<?php do_action('show_my_plugin_widget'); ?>

One short line of code. No worrying about deactivated plugins. A small extra effort on your end can save your end users some frustration down the road.

Next Time: Cold Fusion! (article may be delayed by technical feasibility)

Previously: Use Classes in your WordPress plugins to increase code portability and reduce name conflicts

This article was originally published at Nerdaphernalia. Planet WordPress is authorized to reproduce WordPress-related entries. If you're reading this at any other web site, the site owner is stealing copyrighted work. Please visit the original page:

Feed enhanced by Better Feed from Ozh

In addition to its basic function, the code is designed to serve as a tutorial of sorts, showing authors how to use some very interesting plugin techniques, such as modifying any option on the fly as it is pulled from the options table, or how to modify sections of the core admin pages.

It’s worth a look, and thanks to Otto for sharing.

This article was originally published at Nerdaphernalia. Planet WordPress is authorized to reproduce WordPress-related entries. If you're reading this at any other web site, the site owner is stealing copyrighted work. Please visit the original page:

Feed enhanced by Better Feed from Ozh