Development
Disappearing text in IE6 and "dead" JavaScript links
Sat, 01 Dec 2007 01:31:12 -0800
We discovered a couple little annoyances with IE6, and I thought it would be useful to publish their workarounds.
Issue #1:
Random text would "disappear" on a page. It actually was still there and would show sometimes after hovering over it. The fix turns out to be setting the CSS for the text in question to "height: 0.01%" - it's so simple but so needless. It shouldn't have to be done. It should just work.
Issue #2:
<a href="javascript:anything" onclick="something()">
Won't work. It will just act like a dead link (or perhaps just ignore the onclick...) This will work however:
<a href="javascript:something()>
Note: Typically I try to keep my href's to be plain "javascript:;" if I need to use anchor-based links, and then chain events off of it using the element's ID and jQuery.
Upgrading WordPress sucks.
Tue, 30 Oct 2007 17:36:20 -0700
It is almost perfect - just tar xvfz latest.tar.gz and let it overwrite the files in the wordpress/ dir... but life isn't easy like that.
A bunch of files have been deprecated from various releases and just sit around getting stale. Currently the installation instructions are to just "remove all files" in various places. I would rather just get a list of files that are safe to remove, and be able to blindly copy the archive using tar (or remotely using FTP, etc.)
That shouldn't be too hard.
Right now I have my WP installs for work and home in Subversion, and I can't just move the files because the SVN metadata and directories get lost. I'd prefer to just get a list and I can manually just "svn del" the files myself. So please, for future WP releases, would someone publish the list of files so I don't have to do all this manual work each time? How about a quick and dirty cheat sheet like so:
List of files deprecated by this release:
- foo.php
- bar.php
Database upgrade required: Yes/No
Functions changed or deprecated:
- wp_insert_post() now does this instead of that...
- etc...
This might also make it easy for [us] plugin authors to look at the function deprecation list and easily know if something we're doing could be in trouble 
Handling events pre-$(document).ready() in jQuery
Tue, 30 Oct 2007 17:03:42 -0700
jQuery is the best thing since velcro. No doubt. However, there is one thing that I've stumbled across that other people seem to have wondered about too. jQuery's got this great $(document).ready() capability to let you know when the DOM is ready and jQuery is loaded. However, what about those events (like a user quickly clicking on something) prior to this happening? If any of those require jQuery's functionality, you're SOL.
For right now, what I figured out is just doing this in the HTML:
<a href="javascript:;" id="somediv">Some link</a>
In the Javascript, it would be this:
$(document).ready(function() {
$("#somediv").click(function() {
... your actions here ...
});
});
This currently is the only way I could figure it out. This guy had a neat idea basically creating a cache of the events to trigger the minute the DOM is ready. I was thinking of just blindly applying this to all $("a"), but that still requires jQuery to be available, and that's the whole problem to begin with.
This issue makes me nervous because I'm trying to play within the rules that Yahoo! has worked out for optimal performance. However, when you put JavaScript files at the bottom of the page, that means it will be even longer before jQuery is loaded. The more I try to get the pages working with JavaScript files loading at the bottom, the more apparent it becomes that jQuery should still be called at the top/as soon as possible. Unless someone else has figured out a way to make both sides happy...
jQuery Spy improvements
Mon, 29 Oct 2007 15:17:36 -0700
I've made a diff against spy 1.4 to make sure it will not allow multiple spy instances on the page with the same object ID. If .spy() is called again, the old timer will be cleared and the new one (with new settings) will take over. It should still allow multiple *different* spies on the same page, just not two of the same thing (I was having an issue where it would keep reloading the same ID over and over because of a .click() event changing the configuration settings) - this allows real-time changing of the settings (say, the AJAX URL) without spawning additional timers.
I also added in a Math.random() parameter to force reloads every call and changed $.post to $.get - those can easily be removed if desired. Essentially I just create an array that has a list of all the spy IDs that are called, if a dupe is detected, the old timer is disabled and the new one starts like normal. Oh, and I changed the epoch behavior, for some reason on my browser it wasn't reporting the right time. I don't see why it needed the spy.epoch calculation at all.
Here's the patch file:
http://michaelshadle.com/files/javascript/spy-1.4-diff.patch
Feel free to submit your comments. This was the cleanest method I could figure out.
jQuery's no-conflict mode: Yet another reason why it's the best
Tue, 03 Jul 2007 15:29:26 -0700
It took me a bit to find out why jQuery (now bundled with WordPress) was not working as I expected inside of the WP admin area. The script was being called, but my code like $("#foo") was not working. I really had no clue where to begin, since it still has all those old JS libraries/frameworks being called as well. It was due to Prototype being packaged with it and conflicting with the "$" shortcut.
Long story short, jQuery already planned for library conflicts and has a quick solution. The no-conflict mode allows you to define your own shortcut, and of course it works like a charm.
It's easy to do - just put this line in your code somewhere:
var J = jQuery.noConflict();
Now $("#foo") will be J("#foo") and it will not conflict with any other libraries that may be installed. I hope WP gets rid of all the other stuff and goes with pure jQuery and plugins soon enough though
Why does WordPress allow empty post titles and bodies on publish?
Tue, 03 Jul 2007 14:53:23 -0700
I have noticed (and also reported this on the WP site) that when a user clicks "Publish" it does not check for empty post titles or empty post bodies. I believe this is a flaw in design. The code is there to check, but it doesn't work right; it allows for empty post bodies or titles for drafts (which is okay, they might not have a title yet) but it should stop the user from being allowed to publish an empty post.
Below is the code I came up with after messing around for hours... it relies on the bundled jQuery in the latest WP 2.x versions. It does client-side checks to alert the user to fix the issue, but there is no graceful way (at least that I could find) to handle this if the user does not have JavaScript or anything enabled. If the server gets an empty title or body, it will empty all the fields out, essentially forcing the post to fail. The user *will* lose their work then (unless their back button works nicely.)
The typical user will typically have JS enabled, and they shouldn't be publishing without a title. However, I am dealing with some inexperienced bloggers - so I want to make sure I have all the bases covered. Once again, the reason this is so ugly is due to the fact that I do not modify the core WP code; everything I do is in plugin fashion (although I did suggest a quick fix in the WP core code in my forum post.)
Links to my forum post and the bug submission:
Here's the code:
function empty_filter($text) {
return '';
}# if any field is empty, forcibly empty the fields so that it will fail post publishing
function check_empty_title() {
if(isset($_POST['publish']) && $_POST['publish'] == "Publish") {
if(empty($_POST['post_title']) || empty($_POST['content'])) {
add_filter('content_save_pre', 'empty_filter');
add_filter('excerpt_save_pre', 'empty_filter');
add_filter('title_save_pre', 'empty_filter');
}
}
}
add_action("load-post.php", 'check_empty_title', 1);function check_empty_clientside() {
echo <<<EOF
<script language="javascript" type="text/javascript">
var wpJ = jQuery.noConflict();
wpJ(document).ready(function() {
wpJ("#post").submit(function(){
if(wpJ("#title").val() == '') {
alert('You must put something in the post title!');
return false;
} else {
if(tinyMCE.getContent() == '') {
alert('You must put something in the post body!');
return false;
}
}
});
});
</script>
EOF;
}add_action('admin_head', 'check_empty_clientside', 1);
Which WP Plugins Do I Use?
Tue, 29 May 2007 01:05:48 -0700
I've had the opportunity to work with WP plugin creation quite a bit at work. We've been able to enforce a strict policy on our WP blog of not allowing *any* core WP code to be modified. The main reason for this is that it will make it much easier to upgrade and not break functionality later on.
Due to that, I've wound up creating or hacking up a bunch of custom plugins for work. One includes a complete authentication system override. Basically it traps all login, logout and registration requests and pushes them to custom URLs, and I trap all requests and process user information from cookies our external authentication system has defined. Then I take that information and force-feed it into the WP system, essentually telling it to emulate who I want it to.
That's not a very general-purpose one for any WP installations outside of my company though. However, I have created one that so far seems to be quite useful, and depending on responses, I may package/fix up more.
As of right now, I wind up customizing almost every plugin I use. Currently, all but the Akismet one is either completely written by me, or was taken from another one and hacked up with extra features.
My current plugin list includes:
- Akismet - because spam sucks.
- Comment Cleaner - based off "Chunk Urls" I've combined the URL chunking with word wrapping that behaves properly.
- "Misc Fixes" - a dummy plugin where I dump some personal tweaks like removing all the wptexturize() calls. Possibly some other good stuff, and maybe a testing ground before pulling code into a seperate official plugin.
- Remove Dashboard Feeds - my first official "public" plugin, a simple and effective way to disable the feeds from loading in the WP admin dashboard. Especially useful for when your server is behind firewalls, but also great if you don't really care about that information
- WP Mail Replacement - PHP's mail() function doesn't work as good as I'd like. I created one that uses popen() directly to the sendmail binary, and allows me to do anything I want - custom headers, attachments, etc. However, now that WP 2.2 is bundling phpMailer, this might not be an issue.
It seems like I use a lot more. I guess I felt cool having a handful of custom plugins, but I really only run a couple on my personal site for now. As I mess around with more, I'll be sure to post.
One thing I would like to see is the database functions put into the pluggable functions. Then I could create a MySQLi plugin that could override the core MySQL calls. That'd be a pretty easy way to allow for custom backends; in the meantime, it looks like I am stuck putting in a wp-content/db.php file (I believe that is the way to do it.)
While we're on the subject of plugins, I think I should be clear here. A "plugin" should not require the stock WP code to be altered. That is a patch or a hack. A plugin is something that can be plugged in without any modification of the core code.
A No-hack Dashboard Removal Plugin
Mon, 28 May 2007 23:47:42 -0700
I don't know why this wasn't discovered (or a better action put in by the WP folks to begin with that could be disabled) but I was able to find a way to disable the feeds from loading on the WordPress admin dashboard without any need for customized index.php files (which would need to be updated/re-uploaded every time WP is updated.)
I'm not sure why this isn't just a stock WP configuration option. It seems enough people have looked for ways around it. My biggest issue was that it requires connectivity directly with each RSS feed, which does not work very well behind our firewall at work. I'll be damned if I hack up some proxy-capable solution too for the feeds that we don't really even look at.
I knew that there had to be a way to mess with the actions being called to disable them from loading the Javascript, or make the fetch_rss() calls return nothing, or make the index-extras.php script return nothing... the easiest and apparently effective way was making a simple action trigger and finding the right order in which it was effective.
In the end, this is all the code that was required:
function remove_dashboard_feeds() {
remove_action('admin_head', 'index_js');
}add_action('admin_head', 'remove_dashboard_feeds', 1);
To make a long story short, I give you the "Remove Dashboard Feeds" plugin, located here. Just download, remove the .txt extension, throw it in the plugin directory and activate it. Simple enough. Works on WP 2.2, and probably 2.1. Not sure about earlier versions, but nobody should be running those anyway (keep up with the times as much as you can! Stay secure and optimized!)
MySQLi support for WordPress 2.0.7
Mon, 15 Jan 2007 22:20:50 -0800
Yet another patch (actually the same one, but copied for version compliance.)
Patch file: wordpress-2.0.7-mysqli.patch
Apply with: "patch -p0 < wordpress-2.0.7-mysqli.patch" in the WordPress install directory.
MySQLi support for WordPress 2.0.6
Sat, 06 Jan 2007 01:40:04 -0800
WordPress 2.0.6 was released earlier today. Shortly after I made the 2.0.5 patch. Oh well. Simple enough to make one for 2.0.6.
Patch file: wordpress-2.0.6-mysqli.patch
Apply with: "patch -p0 < wordpress-2.0.6-mysqli.patch" in the WordPress install directory.
Entries (RSS) and Comments (RSS). 13 queries. 0.419 seconds.