WordPress
WordPress on Drizzle - Beaten To the Punch
Wed, 17 Jun 2009 15:52:28 -0700
Looks like Jeff Waugh actually beat me to it.
Haven't seen the code... but he's done it and sounds like he's done a somewhat thorough job.
Sadly I learned this from Brian's presentation on Drizzle at OS Bridge. Doh.
Disabling Autosave in WordPress (Properly)
Sun, 23 Nov 2008 16:46:36 -0800
This is for 2.6.3 - not sure what other versions it will work on. Originally I got this from http://www.untwistedvortex.com/2008/06/27/adjust-wordpress-autosave-or-disable-it-completely/, however, it was still giving me a JavaScript error.
Note that this worked fine in FF 2.x, and IE6 for English; but for some reason it broke in Chinese and only in IE6. It kept telling me it was failing to update a post, even though it was a new post. I traced it down finally to autosave.js changing the value of the action to "editpost" instead of "post" - I am not exactly sure why the behavior is different in different browsers, but at this point I don't care. The autosave feature is not necessary for the blog site I am supporting for work.
At first I tried a wp-config.php attempt, from http://sheldon.lendrum.co.nz/disabling-wordpress-auto-save-and-revision-saving_227/04/ - but that must not work in 2.6.x - it still appeared to be autosaving. The next Google result was a plugin fashion that dequeued the autosave.js script - which was the culprit, but it wasn't quite complete (at least in my 2.6.3 install) - so here is the complete fix (no JavaScript errors that I can tell)
First, you need to make a file called "autosave.js" and throw it in wp-content/plugins, the content of which is:
function autosave() {
return true;
}
Next, throw this in an existing plugin or make a standalone file (I have a file with a bunch of random WP "fixes" so I just threw it in there):
function disable_autosave() {
wp_deregister_script('autosave');
wp_enqueue_script('wphacks', '/wp-content/plugins/autosave.js', array(), '20081123');
}
add_action('wp_print_scripts', 'disable_autosave');
A big thanks to the guy at Untwisted Vortex for getting me on the right path. I'm sure there might be a couple other ways to do this, but this works just fine, and maps with the primary goal of not editing the core code of the package.
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?
nginx + WordPress - Redux
Sun, 17 Aug 2008 01:52:48 -0700
Note: this has been outdated once again. Now it can be simplified with one simple directive shown here.
There's been a minor tweak required in my original WordPress+nginx rewrite rule post.
I think we've finally got it right now. I've been exchanging emails ad nauseum with Igor and I believe the behavior now works properly (part of the exchange was regarding PHP+basic http auth, there were some bugs around the regexps/nested location blocks or something)
Anyway, here is a perfect working example, running this very website:
server {
listen 80;
server_name michaelshadle.com;
index index.php;
root /home/mike/web/michaelshadle.com/;
include /etc/nginx/defaults.conf;
include /etc/nginx/expires.conf;
error_page 404 = /wordpress/index.php?q=$request_uri;
location ^~ /wordpress/wp-admin {
auth_basic "wordpress";
auth_basic_user_file /home/mike/web/michaelshadle.com/.htpasswd;
location ~ \.php$ {
fastcgi_pass 127.0.0.1:11000;
}
}
location ~ \.php$ {
fastcgi_pass 127.0.0.1:11000;
}
}
Likewise, you can also omit the basic HTTP authentication if you don't think you need it:
server {
listen 80;
server_name michaelshadle.com;
index index.php;
root /home/mike/web/michaelshadle.com/;
include /etc/nginx/defaults.conf;
include /etc/nginx/expires.conf;
error_page 404 = /wordpress/index.php?q=$request_uri;
location ~ \.php$ {
fastcgi_pass 127.0.0.1:11000;
}
}
Note: this does require a patched version of 0.7.10 - I assume he will put these changes into 0.7.11. Some of the changes required include the basic HTTP auth stuff. Also, when using error_page 404, it generated logfile noise in the error log. That was fixed as of 0.7.9 or 0.7.10, so no longer will you receive script-handled 404's in your error log.
This should be the last and final need to run WordPress properly under nginx. This has the approval of Igor, the creator - you cannot get better than that. (Note: this is WordPress 2.6.1, but I have not seen any reason the rewrite rule would be different since even before 2.x)
Let me know if it doesn't work! Or better yet, let the nginx mailing list know 
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)
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...
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
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);
Entries (RSS) and Comments (RSS). 14 queries. 0.199 seconds.