Development
Changing the WordPress $table_prefix - a word of caution
Thu, 02 Oct 2008 01:20:30 -0700
I just changed the table prefix from "wp_" to "wp_en_us_" to support multiple installs in the same database, one for each locale. This seemed pretty straightforward - just rename the table names and change the table prefix in wp-config.php, right?
Wrong.
The WP code is littered with references to $table_prefix - including columns in the "usermeta" and "options" table. Key columns such as "wp_capabilities" in the "options" table need to be renamed appropriately, or your user roles are totally broken. In "usermeta" you need to make sure the "wp_user_level" and "wp_capabilities" meta_keys are updated too.
Sadly, after spending a couple hours var_dump() and exit()'ing throughout the code I realized the issue. I am not exactly sure the prefix of some of these keys needs to be aligned with the $table_prefix - maybe WPMU uses that or something. But anyway, what an annoying headache.
I am not sure but I think -all- "wp_" keys might need this same treatment. I've only really cared about the user roles and such since I had a lot of users trying to figure out why they can't post anymore. At least that's fixed.
Note: I don't know if this is clearly documented anywhere. If it is, I should be embarrased. However, I still want to voice a complaint that this isn't very straightforward. Maybe put a comment in wp-config.php?
Large File Uploads Over HTTP - The Final Solution (I Think)
Tue, 26 Aug 2008 20:18:11 -0700
Problem statement: HTTP sucks for file uploads.
You know it. I know it. The problems?
- No resuming
- POST multipart/form-data bloats the size of the file due to encoding
- Slow connections typically time out on large files
- Any server resets or any other network "burps" on the path from client to server effectively kills the upload
- People have had moderate success by tuning their webserver and PHP to accept large POSTs, and in general, it works - but not for everyone and it suffers from everything previously noted.
What would the ideal file upload experience support?
- It should resume after manual pause, a server reset, a timeout, or any other error.
- It should allow for multiple files being uploaded at once.
- It should work transparently over HTTP - which means proxies will support it like any normal web request, it can be done over HTTPS (SSL), it will reuse cookies and standard HTTP authentication methods.
- (Ideally!) the browser would handle this itself without requiring Java, Flash, or any other applets.
With all this in mind, I somehow stumbled across the idea (roughly posted here) based on the time-tested learnings from Usenet and NZB files, and BitTorrent. The main idea? Splitting the file up into manageable segments. There's also some other logic too, but that's the main idea.
Why do I claim this is the final solution?
- It can reuse the same HTTP/HTTPS connection, so proxies and HTTP authentication can be honored.
- It doesn't care what speed of your connection - due to the small size of the files, it's easier to get them to the server and each piece can be confirmed one step at a time. No more having to start from the beginning due to a failure or timeout.
- It will support multiple files at once. The server could (although we might not implement it this way) support multi-threaded uploading of the same file, too, just like BitTorrent or Usenet downloading - upload multiple pieces at the same time and assemble them in the end. We're trying to make a decision whether or not we want to do that right now. The fundamental difference is an implementation detail on the server end.
- It allows for any client that can split a file up, hash it, encode it and upload it via POST
- It will still require an applet, since browsers have no support for anything but standard file upload semantics (Although this would be a neat thing to get into a specification)
What's required, how does it work?
As of right now, this is what I have down (it has changed already since the PHP post):
- The client contacts the server to begin the transaction. It supplies the following information:
- Action = "begin"
- Final filesize
- Final filename
- Final file hash (SHA256 or MD5, still haven't determined which one)
- A list of all the segments - their segment id, byte size, hash (again SHA256 or MD5) - XML or JSON or something
- Server sends back "server ready, here's your $transaction_id"
- Client starts sending the file, one segment at a time, with the following information:
- Action = "process"
- Transaction ID = $transaction_id
- Segment ID = $segment_id
- Content = base64 or uuencoded segment (for safe transit)
- Server replies back "segment received, transaction id $transaction_id, segment id $segment_id, checksum $checksum"
- Client compares the checksum for $segment_id, if it matches, move on to the next segment. If not, retransmit.
- When the client is done sending all the segments, client sends message to the server:
- Action = "finish"
- Transaction ID = $transaction_id
- Server assembles all the segments (if they're separate) and sends to the client:
- Transaction ID = $transaction_id
- Checksum = $checksum of the final file
- Client compares the checksum to it's own checksum. If it matches, client sends message to server:
- Action = "complete"
- Transaction ID = $transaction_id
Viola, done. I think the "protocol" transmits some extra information that isn't needed; so some of this might need to be cleaned up. This is the initial idea though. Props to Newzbin for inventing NZB files which was a big influence in this concept.
I'm somewhat rushing this post out, hopefully it solicits some feedback. I'm going to be revising this and working with a Java developer to work on a client written in Java. Hopefully someday we'll get one with less overhead. I'll post PHP code as I write it too to handle the server portion of it.
Simple WordPress Hack - Redirect the index.php!
Sat, 16 Aug 2008 01:05:42 -0700
I don't know how or when, but I wound up getting indexed with index.php in some of my URLs.
For some reason, WordPress hasn't decided that they should parse and remove that. So for the interim, I've decided to finally throw in a couple quick lines of code to do the trick. Throw it in any plugin you want or make a standalone file, it works fine with my 2.6.1 so far.
add_action('init', 'chop_index');
function chop_index() {
if(preg_match('/index\.php$/', $_SERVER['REQUEST_URI'])) {
$url = preg_replace('/index\.php$/', '/', $_SERVER['REQUEST_URI']);
$url = preg_replace('/\/\/$/', '/', $url);
header("Location: http://".$_SERVER['HTTP_HOST'].$url, true, 301); exit();
}
}
WordPress+nginx Rewrite Rules - Stop The Insanity!
Thu, 01 May 2008 08:00:20 -0700
Note: this has been outdated now. I have an updated post with the latest and Igor-approved method here.
When I was switching over to nginx, I found a handful of random and overkill config examples to make it work. I thought I had found the simplest solution already, but Igor (the creator of nginx) actually gave me an even "better" solution in nginx.
This is assuming WordPress is physically installed in /wordpress, and pages are served up using friendly URLs, /2008/02/03/post-title/ - just like this site. All the rewrites are off the root. I assume you've already got PHP setup to parse properly and you have a working server {} block. I'll post that info too if people really need it.
1st example (seems like overkill, can't figure out a reason why people are splitting up the rewrite rules - I guess because they assume "wp-anything" is all static?):
if (!-e $request_filename) {
rewrite ^([_0-9a-zA-Z-]+)?(/wp-.*) $2 break;
rewrite ^([_0-9a-zA-Z-]+)?(/.*\.php)$ $2 last;
rewrite ^ /index.php last;
}
2nd example (this was as good as I thought it could be, but I was wrong):
if (!-e $request_filename) {
rewrite ^(.+)$ /wordpress/index.php?q=$1 last;
}
3rd example (this is the best, according to Igor):
error_page 404 = /wordpress/index.php?q=$uri;
(Ref: http://article.gmane.org/gmane.comp.web.nginx.english/4739)
Google AppEngine - 1) Develop Site, 2) ??Get Bought By Google??, 3) Profit
Thu, 10 Apr 2008 17:58:23 -0700
A co-worker and I were discussing the lack of languages in Google's AppEngine program. I'd want PHP, he'd probably prefer .NET... there seems to be a lot of "please add XYZ!" in the bug tracker for it.
Anyway, I have a sneaking suspicion that this is a covert operation for Google to provide it's preferred architecture, authentication, etc. so people create the next generation of massively scalable sites (and/or convert their existing ones or create clones of existing ones) that run on their platform... and then Google can swoop in and buy them. The total headache and cost of bringing it in house is essentially nil, since there are no user conversions, data conversions or anything else to deal with. Just slap Google on it, and viola.
I could be wrong, and I suppose we will see as Google starts addressing these requests. Perhaps they'll be fine with -any- language and still want people to make apps they can easily consume. I guess people will report out as they begin developing and growing their sites and Google approaches them (or not...)
Due to popular demand - more MySQLi for WordPress!
Tue, 04 Mar 2008 02:50:55 -0800
I've had two requests now for MySQLi updates, so here ya go. It's pretty simple to do it yourself - just look for any mysql_ string, replace it to mysqli_ (where applicable) and in some instances, change the order of the parameters.
Below is the version of wp-includes/wp-db.php for production WP 2.3.3
- Download the file here
- Copy it over the existing wp-includes/wp-db.php file
- Enjoy!
Below is a version that works against the latest in SVN trunk (right now revision 7152) using the new db.php override feature (apparently still not in 2.3.x)
- Download the file here
- Copy it to wp-content/db.php (important - this is a hard-coded location)
- Enjoy!
Let me know if there are any issues, but in my quick little sandbox I made it worked fine...
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.
Entries (RSS) and Comments (RSS). 13 queries. 0.199 seconds.