ringmaster

Applying styles to the output is an exercise for the user:
http://pastebin.com/280595

Save that code as a plugin file. Create a post/page and put this comment on it (and usually nothing else) where you want the output to appear:

<!--linksdropdown-->

I have a plugin (Redirectify) that may do what you want.

Basically, download the plugin from my site, upload it to your wp-content directory and activate it via the WP admin panel.

Then, whenever you want a post’s URL to redirect to somewhere else (either on your site or somewhere else), add a new custom field with the Key “redirect” (you do this via the Advanced Editing page). In the Value field, put the full URL (including the http://).

Now whenever you visit that post, it will redirect to the URL you specified. On pages that display more than one post (like the home page) it will display the post content, but when you click to display that post by itself, it will redirect to wherever you told it to.

Download Redirectify here: http://www.asymptomatic.net/wp-hacks

Also, please don’t post support requests to the wp-docs mailing list. That’s not what it’s for. If you’re not getting results on the support forum, you’ll have to try to be more clear about what you want to do, and more patient for an answer. Seriously, the people that want to help may start to ignore you if you don’t relax and use a little common courtesy.

Open BAStats.php from the plugin directory for editing.

Look for a line near the top that says:
var $table_version = 6;

The number 6 may be a different number. Whatever it is, increase it by 1.

Save the file and reactivate the plugin to recreate the tables.

Apart from that, BAStats development is on a break. Why?

One reason- Because Asymptomatic gets 3000+ sessions (not hits, sessions) per day, and BAStats makes the MySQL process on the server eat processor time. I worry that as your traffic builds up, BAStats will start to have this effect on your system, too. Please report this if you’re using the beta and it happens to you.

Another reason- I’m embroiled in other development (plugins, work, secret WP projects) at the moment, and figuring this one out isn’t currently a priority for me.

Another reason- I wrote all of the reports myself, and some are slightly broken in ways that are difficult to fix. I get a lot of suggestions for what to add to the plugin, but never any suggestions on how to fix what’s currently wrong with the plugin. Introducing new features when the existing features aren’t perfect seems irresponsible. But maybe if people forwarded some fixes for the reports…

Keep in mind that BAStats has never left beta, although it’s been there for a while and has had several updates. Everyone who uses it seems to like it, and I might be the only person who has problems (I’m on a Windows server, see, which may soon change), so I’m sure to get back to it eventually, just not this afternoon. I hope you understand.

Note that the current version of BAStats outputs a SQL statement to the bottom of the stats page on purpose. Please stop reporting that the plugin is generating errors – this is not an error.

And finally, my email is encoded at the very bottom of my blog. No need to bump posts here (which someone else will usually be answering, since I rarely stop by here these days) – when you don’t get a response to your question, just email me.

The latest version of EzStatic (currently 1.9.2) fixes these issues.

Dollar signs in output are automatically rendered properly by converting them to entities for you. This was already done in my SVN copy of 1.9.1, so this is not a new issue.

The checkbox now “sticks” when you first publish a post. Previously, it would only work if you saved it first, then checked it.

I have verified that embedding PHP works in both posts and pages. It’s likely if you experienced it not working, your page was subject to the un-sticky checkbox bug. Download 1.9.2 and try again – it should work fine now.

With these fixes in place, you should not need to alter MicroShop’s dollar signs for it to function properly inside of WordPress.

Seems pretty restrictive.

This sort of error happens to me on IIS when I don’t add read permission for the web user to files that I add to the site. Note that the web user may be a different user than the one that is used for FTP. Usually the username starts with “IUSR_”, and often on hosting accounts the rest is the name of the domain.

I just tested my hypothesis by removing the read permissions (explicitly denying them, actually) to the plugins directory for my IUSR_EMPIRE2 user, the web server user for my desktop system. I see this message in WordPress: “Plugins are files you usually download separately…Couldn’t open plugins directory or there are no plugins available.”

How you can set this permission on a Go Daddy server, though, may be a question for Go Daddy support.

It’s also possible that WordPress uses one of those restricted functions to gather plugins. A brief look-through of the source doesn’t yield any hits though, and I would think you’d see a PHP error instead of a friendly WordPress message if this was the case, but you never know.

The new index and its associated files are in /wp-content/themes/default/

Index.php is the main file with the post loop in it, but the sidebar.php has the sidebar stuff in it that you’re probably going to modify most heavily.