Nerdaphernalia » PHP

How to Close a WordPress Site

Stephen R — Wed, 18 May 2011 20:10:54 +0000

I recently was asked to close down a site I had put up using WordPress. I didn’t want to just delete the whole thing, as I figured somebody might want it put back up in the future. There are several easy ways to do this, but I think I’ve found the best.

My first impulse was to add an exit; line to index.php. The problem there is that it doesn’t close off the wp-admin section. I could comment out the database password in config, but that leaves a “Could not connect to database” message. I wanted every aspect of the site gone. Then it struck me: One file that absolutely every single call to WordPress must pass through is wp-config.php.

So if you want to “disappear” a WordPress site quickly and easily, just open up wp-config.php and add the following right after the opening PHP tag:

exit;

If you want to put up some kind of “goodbye” message in HTML, you can do something like this at the top of that file:


This site is closed.


Even more briefly, of course, you could stick a short message inside a die() statement.  The HTML gives you a bit more flexibility though.
Hope somebody finds this useful.  

© Stephen Rider 2011
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:

Permalink to How to Close a WordPress Site
Feed enhanced by Better Feed from  Ozh



Search Everywhere in MySQL
Stephen R — Mon, 17 May 2010 16:04:35 +0000
In recent months I’ve been tasked with taking over management of a web site programmed by somebody else.  They used Drupal, with which I’m not familiar, and so a big part of the job is simply figuring out how that system works.  In many cases I’ve wanted to search the entire database for a particular string of text, in order simply to find out where certain data is stored in the database.
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!

© Stephen Rider 2010
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:

Permalink to Search Everywhere in MySQL
Feed enhanced by Better Feed from  Ozh



Virtual Multiblog — how to use unique headers on blogs running the same theme
Stephen R — Wed, 27 Aug 2008 15:58:01 +0000
One of the most common questions I get regarding the Virtual Multiblog system for WordPress comes from people wanting to have multiple blogs running on the same theme, but with a different header for each blog.  It can be done, and it’s fairly easy to do.  Once you have it set up, you could use it to call any distinct file on a per-blog basis — a different CSS file, or a different footer perhaps.
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)

© Stephen Rider 2008
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:

Permalink to Virtual Multiblog — how to use unique headers on blogs running the same theme
Feed enhanced by Better Feed from  Ozh



Use Classes in your WordPress plugins to increase code portability and reduce name conflicts
Stephen R — Mon, 28 Jul 2008 15:16:21 +0000
One of the most powerful features of WordPress is the huge community of developers making plugins that extend the software far beyond what the core application provides.  It also allows people to add just what they want to use, rather than having a single bloated homogeneous download.  There are drawbacks as well, of course.
Any time a software package opens itself up to third-party additions, there is a potential for mischief.  With WordPress, different plugins can end up stumbling over each other, as each is coded for the core but doesn’t anticipate other plugins.  You can also have naming conflicts — when functions or variables in different plugins are given the same name.  This is often avoided by adding the plugin name to the beginning of each and every function, variable, constant, etc.
If you have multiple plugins, you probably have a good bit of code that you reuse in all of them.  If you’ve been appending the plugin name all along, then any time you update those common functions, you can’t simply copy the new versions over to the other plugins — you have to go over them and update the function names and any internal calls from one function to another.
These problems and others can be avoided by using classes.
By wrapping your plugin’s functions in a PHP class, you gain a number of advantages.  You can set plugin-wide variables.  You can use common function names and create easily-remembered “wrapper” functions that modify the way common WP functions do things.  You can create portable functions that can be copy-pasted into other plugins without any adjustment.
Ready?  Let’s get started…(...)
Read the rest of Use Classes in your WordPress plugins to increase code portability and reduce name conflicts (835 words)

© Stephen Rider 2008
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:

Permalink to Use Classes in your WordPress plugins to increase code portability and reduce name conflicts
Feed enhanced by Better Feed from  Ozh



Consolidate Options with Arrays in your WordPress Plugins
Stephen R — Tue, 08 Jul 2008 22:24:15 +0000
If you’ve ever written a plugin for WordPress you’ve probably dealt with giving the end user options.  Unless you’ve taken the low road and forced the user to directly edit the plugin file, “options” means a Settings screen in the WordPress admin, and most likely you are storing those options in the blog’s wp-options table.  Over time, bloggers using various plugins can end up with hundreds of extraneous records in their options table^*.  If they ever stop using a plugin, or if they ever want to manually clear out options, this job can be made difficult by all the clutter, and the problem is made far worse when plugin authors add a new record for each separate setting in a plugin.  Beyond the mess, plugins written this way generally make many more calls to the database than they need to, which adds unnecessary burden on the server.
I have seen and used plugins that added anywhere from ten to thirty new records to the options table, and a correspondent of mine reports that he has encountered a plugin that, upon activation, adds a whopping 140 new records to wp_options.   Egad!  There has to be a better way!
There is a better way.  With a few simple changes to your code, plugin authors can put all the various settings into an array, and enter that array as a single record in the options table.  This article will show you how.
On this site I use a plugin called ShrinkyLink.  It performs the straightforward but useful function of shortening long URLs to a specified length, or replacing the link text entirely with a specified string.  It was created by Andrew Rader, but as far as I can tell his web site no longer exists. For the purposes of this article, it has a number of good qualities:

It inserts 10 separate records into the WordPress options table
It is not likely to see further updates from the original author
It is useful and thus worthy of updating
The original author was kind enough to release it under the GPL2 license

The last version of ShrinkyLink was 0.2, released in 2006.  Today we’re going to begin the rehabilitation of this plugin and create a version 0.3 that stores all its settings in a single array.
I’m going to split this into multiple sections:

How to set and retrieve settings using arrays
Upgrading your plugin’s Admin Screen form to use an array
Upgrading existing settings from multiple records to a single array

Let’s get to it.
(...)
Read the rest of Consolidate Options with Arrays in your WordPress Plugins (1,731 words)

© Stephen Rider 2008
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:

Permalink to Consolidate Options with Arrays in your WordPress Plugins
Feed enhanced by Better Feed from  Ozh



Give your WordPress plugin credit without cluttering the GUI
Stephen R — Mon, 30 Jun 2008 13:34:03 +0000
In a previous post I discussed the idea of locating your plugin’s Settings screen where it made sense within the Admin menus — giving an example of my own pull-quotes plugin’s Settings going under the Design menu.  I briefly touched on a further aspect of this, when I suggested that authors not make their plugins scream “This is a plugin!”
I’m sure a lot of people reading that first thought “But wait!  I put a lot of time into my plugin — I want people to know that it’s a plugin!”  So we end up with an admin screen titled John’s Comment Filter Plugin 3.2 or worse, a “mystery meat” menu item that doesn’t identify what the plugin does at all¹!  That first example is somewhat like having a store with a giant flashing neon sign up front — it certainly gets the information across, but it’s not all that attractive, and very obtrusive on the surrounding landscape.
I admit that we’re riding a line here — we all want credit for our hard work; but awkward plugin integration, spread out over multiple plugins, can end up making WordPress itself look awfully kludgy.  Our blogs, and our plugins, deserve better than that!
So, we’re looking for a way to give credit where credit is due, while maintaining a clean integrated interface that looks as though it were a part of WordPress from the beginning.  First, name the menu item for what the screen is for, not what the plugin is called.  Ditto the page  and header.  By way of example, my pull-quotes plugin is called “JavaScript Pull-Quotes”, but the Admin screen is under Design -> Pull-Quotes, and the page title and header read “Pull-Quote Settings”.  The menu item and page header do <em>not</em> have to match the name of the plugin!</p>
<p>Okay, so… what if you still want to show the plugin name, and maybe have a link back to the plugin’s homepage?  Simply allow your eyes to drift downward to the bottom of the admin screen…</p>
<p></p>
<p>There’s the name of the plugin, the version number, and a link back to the home page; but it’s discreet and unobtrusive — it looks as though it belongs there.  The information is there if you’re interested, but it doesn’t get in your way if you’re not; giving us a good balance between giving credit and keeping the GUI clean.  Of course, if enough plugin authors start doing it on all their plugins, people will come to expect that bit of extra info, and that little slice of screen real estate will be as good as gold.</p>
<p>Here’s how I do it:</p>
<ul>
<li>Within the function that creates the content of the Admin page itself, put the following line (probably best at the very beginning or very end of the function):
<pre><code>add_action( 'in_admin_footer', 'myplugin_admin_footer' );</code>
</pre>
<p>This attaches a function to the page footer that will insert our attribution text.
</li>
<li>Then of course we have to add the footer function itself:
<pre><code>function myplugin_admin_footer() {
	$plugin_data = get_plugin_data( __FILE__ );
	printf('%1$s plugin | Version %2$s<br />', $plugin_data['Title'], $plugin_data['Version']);
}</code>
</pre>
</li>
</ul>
<p>That’s pretty straightforward — all we’re doing is outputting a line of HTML — but I should point out a couple of things.  <del datetime="2008-07-02T04:35:59+00:00" title="Removed -- see update note at bottom of article">First, we’re wrapping it in an <code>if()</code> and checking against <code>$_SERVER['REQUEST_URI']</code> because we don’t want our plugin’s attribution showing up on every page.  (Of course, you’ll have to change the URL string in that <code>if()</code> so it’s right for your particular page.)</del>  You can use <code>in_admin_footer</code> to insert anything you like, of course, but in the interests of creating something resembling a standard, I hope you consider sticking to the format I give above.  (One alternate that comes to mind, however, is that some people might prefer to use something like “Comments Filter Plugin | Version 3.2 | By John Smith”.  Go for it.   )  I definitely recommend the <code ><br /></code> at the end of the text you’re inserting — otherwise it will be clumped on the same line as the existing text, which will look cluttered and will diminish your own plugin’s attribution.</p>
<p>We’ve just torn down the ugly neon sign, and replaced it with an engraved brass plaque next to the door.  Not too bad, that.  In the longer run, this is something that might be nice to roll into core WordPress code, which would <em>really</em> make it a consistent standard.  Until then, it’s quite easy to give your own plugins credit in a way that cleanly and elegantly integrates with WordPress.</p>
<p class="update">[Update: Ozh improved upon my code a bit by moving the <code>add_action()</code> into the function that creates the Admin page itself.  It simplified things quite nicely, and the code above has been adjusted accordingly.]</p>
<p class="update">[There are updates to this topic <a href="http://striderweb.com/nerdaphernalia/2008/07/wordpress-plugin-attribution-footer-update/">here</a> and <a href="http://striderweb.com/nerdaphernalia/2008/07/on-attribution-and-plugin-priorities-in-wordpress/">here</a>.]</p>
<p class="note">Previously: <a href="/nerdaphernalia/2008/06/wp-use-action-links/">Use Action Links to direct users straight to your WordPress plugin’s admin page</a></p>
<p class="note">Coming next: <a href="/nerdaphernalia/2008/07/consolidate-options-with-arrays/">Consolidating your plugin’s settings so you don’t clutter up users’ <code>wp_options</code> tables</a></p>
<div class="fnote" id="fnote73_1">1: I didn’t originally intend to name names, but a good example jumped out at me recently.  Under the “Manage” menu I have an item called “<a href="http://joelstarnes.co.uk/pagemash/">pageMash</a>“.  Quick (no peeking!) — what does it do???  It’s an <em>amazing</em> plugin, by the way, just poorly integrated in the menus.</div>
<hr />
© <a href="http://striderweb.com/">Stephen Rider</a> 2008
<p>This article was originally published at <a href="http://striderweb.com/nerdaphernalia">Nerdaphernalia</a>.  <a href="http://planetwordpress.planetozh.com/" rel="nofollow">Planet WordPress</a> is authorized to reproduce WordPress-related entries.  <em>If you're reading this at any other web site, the site owner is stealing copyrighted work.  Please visit the original page:</em></p>

<small><a href="http://striderweb.com/nerdaphernalia/2008/06/give-your-wordpress-plugin-credit/">Permalink to Give your WordPress plugin credit without cluttering the GUI</a></small>
<p><small>Feed enhanced by <a href='http://planetozh.com/blog/my-projects/wordpress-plugin-better-feed-rss/'>Better Feed</a> from  <a href='http://planetozh.com/blog/'>Ozh</a></small></p>

</article>
<article>
<h1>Use Action Links to direct users straight to your WordPress plugin’s admin page</h1>
<p>Stephen R — Thu, 19 Jun 2008 14:30:12 +0000</p>
<p>I’ve recently come across repeated discussions (especially on the <a href="http://lists.automattic.com/mailman/listinfo/wp-hackers">wp-hackers mailing list</a>) debating where plugin authors should place their custom admin pages.  I discussed that question directly in my <a href="/nerdaphernalia/2008/06/on-plugin-design/" title="Nerdaphernalia: On Plugin Design and Integration">previous post</a>, and basically stated that the plugin’s admin page can go any number of places, depending on what the plugin does.  Some people disagree with this argument, saying that <strong>all</strong> plugin admin screens should go under one menu — usually “Settings” or “Plugins”, depending on whom you ask.</p>
<p><span class="pullquote">While I disagree, they do raise one good point</span>:  many end users will have trouble finding your admin page because they have come to expect such pages to all be dumped under Settings.  Many plugin authors solve this by hard coding a link into the plugin Description, but this really isn’t the right place for that, and it can create inappropriate clutter in <a class="fnotelink" href="#fnote72_1">certain situations<sup>1</sup></a>.  There is a better way.</p>
<p>WordPress 2.5 makes it fairly easy for plugin authors to add “action” links to the Plugin Management screen, like so:</p>
<p><br />
(...)<br/>Read the rest of <a href="http://striderweb.com/nerdaphernalia/2008/06/wp-use-action-links/">Use Action Links to direct users straight to your WordPress plugin’s admin page</a> (522 words)</p>
<hr />
© <a href="http://striderweb.com/">Stephen Rider</a> 2008
<p>This article was originally published at <a href="http://striderweb.com/nerdaphernalia">Nerdaphernalia</a>.  <a href="http://planetwordpress.planetozh.com/" rel="nofollow">Planet WordPress</a> is authorized to reproduce WordPress-related entries.  <em>If you're reading this at any other web site, the site owner is stealing copyrighted work.  Please visit the original page:</em></p>

<small><a href="http://striderweb.com/nerdaphernalia/2008/06/wp-use-action-links/">Permalink to Use Action Links to direct users straight to your WordPress plugin’s admin page</a></small>
<p><small>Feed enhanced by <a href='http://planetozh.com/blog/my-projects/wordpress-plugin-better-feed-rss/'>Better Feed</a> from  <a href='http://planetozh.com/blog/'>Ozh</a></small></p>

</article>
<article>
<h1>Virtual Multiblog v2.3 for WordPress</h1>
<p>Stephen R — Fri, 13 Jun 2008 14:50:24 +0000</p>
<p>I’ve released a new version of the Virtual Multiblog system for WordPress.</p>
<p>Version 2.3 is mostly under-the-hood improvements, but it might fix some of the issues people have.  Additionally, I’ve made a few updates so it fits more seamlessly within the WordPress 2.5 Admin section.</p>
<p>I’ve also managed to abstract the optional Multiblog Support plugin to such a point that after this update you may never have to update it again!  All plugin functions are now within the <code>/multiblog/</code> folder, so changes down the road will happen within the main VMB system files instead of the separate plugin file.</p>
<p><a href="/nerdaphernalia/features/virtual-multiblogvirtual-multiblog/">Go get it</a>, and Enjoy!   </p>
<hr />
© <a href="http://striderweb.com/">Stephen Rider</a> 2008
<p>This article was originally published at <a href="http://striderweb.com/nerdaphernalia">Nerdaphernalia</a>.  <a href="http://planetwordpress.planetozh.com/" rel="nofollow">Planet WordPress</a> is authorized to reproduce WordPress-related entries.  <em>If you're reading this at any other web site, the site owner is stealing copyrighted work.  Please visit the original page:</em></p>

<small><a href="http://striderweb.com/nerdaphernalia/2008/06/virtual-multiblog-v23-for-wordpress/">Permalink to Virtual Multiblog v2.3 for WordPress</a></small>
<p><small>Feed enhanced by <a href='http://planetozh.com/blog/my-projects/wordpress-plugin-better-feed-rss/'>Better Feed</a> from  <a href='http://planetozh.com/blog/'>Ozh</a></small></p>

</article>
</main></body></html>