So update your bookmarks and links. Xinha4WP and any other plugins I write can now be found at:

http://plugins.baptiste.us

Hopefully that means this site will return to it’s original purpose - sharing family news (when I can find the time to post to it!) and not confusing relatives who see Xinha and think I learned a new language!

I’ve transferred over all the Xinha posts and pages to the new site. However, I’m going to leave them here as well along with all the comments that have been posted for future reference. I’ll just be closing the comments and pointing people to the new site. 

All plugin information has moved to http://plugins.baptiste.us
Comments are now closed. Please use the new forums instead

Now that WordPress 2.1 is out, I’ve had a couple of people note that Xinha4WP breaks after the upgrade. I’m knee deep in the development of another plugin so I haven’t had time to setup a 2.1 text environment and work on it. I hope to get a chance to do that this week. So if you rely on Xinha4WP - you may want to hold off on a WordPress 2.1 upgrade for now. I had checked the know gotchas for 2.1 and it didn’t look like we would hit any. Guess we did.

OK - I got WordPress 2.1 installed and Xinha4WP worked right out of the box. If you are having trouble with Cinha4WP after upgrading to WordPress 2.1, PLEASE post a comment with as much information as you can collect. Right now, it seems to be working fine for me so I can’t really tell what might be going on. I’ve only gotten two reports of problems so I think those may be separate issues. 

All plugin information has moved to http://plugins.baptiste.us
Comments are now closed. Please use the new forums instead

All plugin information has moved to http://plugins.baptiste.us
Comments are now closed. Please use the new forums instead

I’m working on a site that will likely have pictures in a lot of posts. I’ve installed Gallery2 and the WPG2 WordPress plugin, but what really makes WPG2 useful is the ability to include gallery pictures with G2Image. WPG2 includes the TinyMCE G2Image plugin by default, so you lose that when you use Xinha4WP.

G2Image was recently setup to be generic so it could be used in other applications. Since Xinha has such a robust plugin architecture, it shouldn’t be too hard to splice G2Image in. The tricky part won’t be inserting the WPG2 tags, it’ll be writing a filter so you SEE the images while editing, yet still save just the WPG2 tag. If I can’t get that going right away I may use G2Image to insert the actual <img src> HTML. We’ll see - my JavaScript is pretty rusty. 

I figured maybe something was in the theme headers, etc so I created a simple form with a couple variables that would  post to wp-comment-post.php and it worked. Hmm. So I tried the other angle and created a comment post test script that dump the form variables and called it from my theme form file. The variables disappeared. Any theme, the variables vanished in my test script.

This had me totally confused. Why couldn’t I get basic form data into my form. Google returned a variety of ideas, but none that worked. Finally, I stumbled across a ticket for WordPress searching for ‘Blank Page on comments’ and someone had the same problem I did and for the same reason. It’s a doozy.

I’m one of those people who find the ‘www’ in URLs redundant. All my sites support them both, but from an SEO point of view, I’ve started ensuring www.mydomain.com permanently redirects to mydomain.com. When I setup this blog a few years ago, I had put in ‘www.baptiste.us’ in the blog configuration. A few months ago, I added a permanent redirect for www.baptiste.us to always go to baptiste.us. Everything worked as far as I could tell and since I don’t comment on my blog except to respond to new comments, well… That redirect and the blog settings BROKE the comments and I didn’t realize it for quite a while (I just figured nobody had anything to say ). Here’s why.

In WordPress theme comment files, the form ‘action’ variable includes the site url in front of wp-comments-post.php. So for my comment form, the action was set to http://www.baptiste.us/wp-comments-post.php, regardless of the theme I used. The problem is, the Permanent Redirect from www.baptiste.us to baptiste.us WIPES OUT the form variables, even though everything else seems to work. Silently. Now this may be due to session conflicts, etc, I’m not 100% sure.

But the solution was easy. I took out the ‘www.’ in my blog’s config so comment posts went to the ‘baptiste.us’ domain right away instead of www.baptiste.us and comments started working again.

Moral of the story - if you have a permanent redirect setup for your WordPress blog, be sure the desired domain is the domain set in the WordPress config. If you want everyone to end up at www.mydomain.com, you better have the ‘www’ in your WordPress config. If you want the www to always go away, make sure it’s not in your config either. Hopefully this post saves someone else the time and aggravation if they stumble into this trap.

So 3 days and nights of debugging on and off and all it took was updating two config variables in WordPress. Problem solved

All plugin information has moved to http://plugins.baptiste.us
Comments are now closed. Please use the new forums instead

I’ve been working on the next release of Xinha 4 WordPress over the past month and figured I’d release a beta version for folks to try out. I’ve been using this beta for the past few weeks on my sites and it has been working well. I still have a few things to add and fix before a final version is released.

You can download the beta version in zip and tar format. 

Installation is easy:

1. Move your existing xinha4wp plugin directory to something like xinha4wp_old (just in case)
2. Unzip/tar the new version into place (/wp-content/plugins/xinha4wp)
3. Open the Xinha4WP options screen and look for a successful upgrade message.
4. Clear your browser’s disk cache. 

Here are some important notes about this version:

• It contains a much improved version of Xinha from the Oct 30th nightly build.
• Works with both WordPress and WordPress-MU.
  
• The HTML cleanup feature has a number of new filters you can use. I added options allowing you to set the defaults for each filter (on or off) in the prompt, but I haven’t been able to get them to work. So for now, all but one of the filters will be enabled when you cleanup by default (you can manually enable/disable them during each check)
• The Image Manager plugin now allows the setting of a custom directory name. The directory MUST be a subdirectory of wp-content. It will default to the uploads directory, but this can be overridden in the Post or Comments settings screen at the bottom. If you used an old version of xinha4wp and had the images going into /wp-content/images you must set the directory field to ‘images’
• IMPORTANT! After you install the beta, open the Xinha4WP options screen to upgrade the database schema. Once you do this, follow the instructions in the update message to clear your browsers disk cache. Firefox was caching the old Xinha javascript files, even on restarts, which cause a lot of trouble. One clear way to know if the ‘new’ Xinha is being loaded is the HTML Cleanup button. If you still see the old ‘W3C’ button, the old code is being loaded. If you see a yellow broom button, the new code is being loaded.
• This version includes a new HTML generation engine which should be disabled by default. I find it generates very clean HTML, making HTML Cleanup rarely necessary. However it has a couple of quirks like including BR tags at the end of paragraphs.
• Xinha4WP no longer checks for Text Control plugin. If your post has linefeeds in it, WordPress will convert them to hard line breaks. The HTML Cleanup button will remove all these extra line feeds, so if you cut and paste often, one HTML Cleanup per post is suggested.
• The new form spellcheck feature in Firefox 2.0 WILL highlight misspelled words. However, Xinha has a context menu plugin and if it is enabled, you won’t be able to correct spelling with Firefox since Xinha intercepts the right mouse click for its own menu. Use Xinha’s spell check feature instead.
• It doesn’t break EventCalendar3 like it used to.
  

This version will work with WordPress v1.5.x and v2.0.3 or higher as well as WordPress-MU 1.0.x. If you use this with WordPress v2 or WordPress-MU, you MUST disable the Rich Text Edit option in your global options AND the Admin profile. Otherwise you will see both WYSIWYG editors.

Please post any problems with the beta you have here instead of the main Xinha4WP page.

NOTE Poor coders like myself always appreciate donations to keep the tumbler full!

All plugin information has moved to http://plugins.baptiste.us
Comments are now closed. Please use the new forums instead

A new WordPress plugin called LandingSites came out recently that allows people referred to your site from search engines to see a list of related posts in case the original post wasn’t what they wanted. This is a great feature that has existed on some other CMS products for a while.

If a user searches for something and clicks on a link to your WordPress site, now you can present them with the linked post and also a list of other posts that are related. This is very similar in functionality to the Related Entries Plugin, except it only takes effect if a user was referred from a search engine. This allows you to only take the related search hit for referred users instead of every user. It also lets you greet new users with a friendly message about what they were searching for and what else might interest them based on their search terms.

The plugin installed just fine and I was able to add it to my theme fairly easily. However, the code was loaded with substr() calls and other slow functions. A lot of processing was being done, even if a user was not referred to your site (i.e. they were just browsing around). Instead of using a cascade of if(substr = searchengine) calls, I implemented a match array keyed off known search engine hosts that returns the query delimiter immediately. I also condensed the code into a few functions to remove redundant code.

The updated code can be downloaded here. Note that if you run WordPress 2.0, uncomment the bottom section where ls_install is. WP 1.5 users need to execute the SQL manually (I may add a WP 1.5 init routine if the spirit moves me). I need to add a version check to make this 100% portable, but I’m already nodding off… I may update it tomorrow to add the portability check.

Enjoy!

UPDATE: Now that I got a little sleep, I’ve updated things a bit to keep me from being embarassed for being lazy! The biggest change is the implimentation of static variables for the terms, delimiter, and referer. Since we call these routines multiple times in template code, it was redundant. Now using a static variable, the values are maintained during a page’s processing which eliminates a lot of processing. We process once for each value and reuse it every time we are called. I did not cache the database query since I can’t imagine why you would need to grab the related posts twice in one page.

I also made the DB schema update portable for WP 1.5 and 2.0 so the schema will be updated for you automagically even if you aren’t using WP 2.0.x. Anyone with a WP 1.2 install, please check that it works as well. I used a little trickery and a stored option to ensure the DB schema is only checked during admin interface page views, not main page views and can be checked quickly without a DB query (since options are cached already)

I fixed the problem where SQL queries failed if the post ID wasn’t available (i.e. you used it on a main page, etc) so you won’t see a post in the related list when viewing it.

Finally, I added support for search engines like A9 and Excite which include the search term as a URL path instead of in a query variable.

Wired has an astounding article at the absolute paranoia that has driven government agencies to run background checks and fingerprint model rocket enthusiasts and arrest suppliers of minute quantities of chemicals for home experimentation. I used to fire off model rockets all the time as a kid. I recall Boy Scout camporees that were dedicated to building model rockets with a huge launch on Sunday afternoon. I still have the 32 pad launch system in my basement we build for it. I have reloadable rocket engine shells from a company that has now been forced out of business by the US government.

No matter what your political affiliation - you really need to read this article. Our children will have no concept of discovery and curiosity outside the Internet. How can we expect our kids to strive to be scientific luminaries if they aren’t allowed to touch anything until they are in college?

9/11 was a horrific event, but the aftermath on our society and the utter destruction of our country’s institutions in the aftermath by our own government is the saddest thing I’ve ever seen. What kind of message will it send to my children that their father has to be finger printed and have a background check when he wants to show them the excitement of model rocketry.

All plugin information has moved to http://plugins.baptiste.us
Comments are now closed. Please use the new forums instead

OK, I admit that I had hoped to have Xinha4WP ready for WordPress 2.0, but other projects and life in general kept me from doing that. I had tried out Xinha4WP on Wordpress 2.0.0 and found it would sort of work but it looked like a lot of work was needed.

I did not have a huge desire to move to WordPress 2.0, mostly because 1.5.x was working for my sites and I had other projects I had to take care of. Well, the time was coming to get to v2.0 - too many cool new things were coming up for 2.0 or higher (the Installer plugin is awesome). So I finally found some time to give the Xinha4WP v2.0 changes a go.

First step was updating my test install to WordPress v2.0.2 and poke around. I’m not 100% sure, but the way they structured the Post HTML made it seem like TinyMCE wasn’t so static as it used to be. In fact it was downright gentle. If ‘Rich Editing’ was enabled it included some JavaScript for the toolbar, but otherwise the textarea tag was left alone - this is a good thing. So on a hunch, I installed Xinha4WP v1.1 and disabled Rich Editing for all users. The Admin user still had Rich Editing set for it, so I disabled it and hit ‘Write’

Voila - Xinha4WP came right up and so far seems to be working like a champ! So if you’ve been wanting to get Xinha4WP working on WordPress v2.0, it looks like you can with WP 2.0.2. I’m still working on a Xinha4WP v2.0 that will make installation seamless and take care of disabling TinyMCE for you, but for now, try this….

1. Make sure you have WordPress v2.0.2 installed.
2. Disable ‘Rich Editing’ under Options->Writing. Also make sure any users you have created also have it disabled in their profile.
3. Ignore the warnings about Text-Control for now. I believe WP 2.0.x is handling the line feed issue better than 1.5.x did - still need to test.
4. Try to write a post. Xinha4WP works just fine for me here. How about you?

Note: The built in upload tools will only work if Xinha4WP is in HTML View mode. Since Xinha4WP has its own Image Manipulation plugin, I’d suggest using that instead. Xinha4WP v2.0 will strip out the image upload stuff from WordPress for simplicity.

Xinha4WP didn’t work for comments, but that is theme related. v2.0 will include CSS overrides to prevent the theme based issues with comment posting we’ve seen before. So it may work for you for comments, it may not. 

So there you have it. It looks like a recent bug fix release of WP made things MUCH easier. I’m off to code. I’m REALLY hoping to have something by this weekend for beta testers. Check the Xinha4WP page for updates. Thanks for your patience!

UPDATE: Make sure you disable toolbar flow!

Having just been open sourced, I’m working to compile iFolder-Server RPMs for the x86_64 platform on Fedora Core 4. I’m using 4 instead of 5 simply because iFolder uses mono and I wasn’t able to find FC5 rpms (the Fedora Dev RPMs probably would have worked, but I can always upgrade to FC5 later).

So off we go…

First off, I needed a server to build and run iFolder on. I currently have a Linux Virtual Server system running so I decided to setup a new server instance for iFolder. I setup FC4 in the new vserver using yum. If you attempt this, you’ll need the usual development packages, gcc, automake, autoconf, m4, make, rpm-build, etc. RPM will spit out any dependencies you need when you first try to build an rpm. You also need mono installed. If you use yum, drop mono.repo into your /etc/yum.repos.d directory and then install the following mono packages:

yum install mono-core mono-data mono-devel mono-web

iFolder depends on two other RPMs: log4net and libflaim. You can find source RPMs here. Click into the latest build directory, then ‘linux’, then FEDORA-CORE-4.0-i386, then srpms.

Building log4net was easy:

rpmbuild –rebuild log4net-1.2.9-4.src.rpm

It built for me no problem. Next up was libflaim, which iFolder-Server relies on heavily. My first attempt resulted in the following error:

Makefile:141: *** Host operating system could not be determined. Stop.

Interesting. I poked around the net a bit and found someone who had run into the same thing trying to compile it on Gentoo. Fair enough. Its a hack, not a real fix, but here is how I got it built:

Install the source rpm: rpm -ivh libflaim-4.8.61-1.src.rpm
Edit /usr/src/redhat/SPECS/libflaim.spec and change the make and make install lines to:

%build
make lib_dir_name=%{_lib} libs HOSTTYPE=x86_64 OSTYPE=Linux

%install
make rpm_build_root=$RPM_BUILD_ROOT install_prefix=%{prefix} lib_dir_name=%{_lib} install HOSTTYPE=x86_64 OSTYPE=Linux

I basically hardcoded the values at the end. You probably could have done `uname -s` and `uname -m` but I was lazy.

Now try and build it from /usr/src/redhat/SPECS: rpmbuild -ba ./libflaim.spec

Voila! libflaim and libflaim-devel RPMs were sitting in /usr/src/redhat/RPMS/x86_64 waiting to be installed. They installed no problem.

Now for the real fun, building iFolder-Server. My first attempt gave me an error about libtoolize not existing. So I used yum to install libtool and tried again. The next error complained that /usr/lib/libflaim.a did not exist. This makes sense. x86_64 machines put their 64bit libraries in /usr/lib64. Being lazy again, I went ahead and softlinked /usr/lib64/libflaim.a into /usr/lib. BAD I know. But I wanted to just see if it would work. Sure enough, I got past that error, though I was still seeing this warning:

/bin/sh ../../../../libtool –tag=CXX –mode=link g++ -g -O2 -o libFlaimWrapper.la -rpath /usr/lib /usr/lib/libflaim.a libFlaimWrapper_la-CSPObjectIterator.lo libFlaimWrapper_la-CSPropertyIterator.lo libFlaimWrapper_la-CSPStore.lo libFlaimWrapper_la-CSPStoreObject.lo libFlaimWrapper_la-FlaimWrapper.lo

*** Warning: Linking the shared library libFlaimWrapper.la against the
*** static library /usr/lib/libflaim.a is not portable!
g++ -shared -nostdlib /usr/lib/gcc/x86_64-redhat-linux/4.0.2/../../../../lib64/crti.o /usr/lib/gcc/x86_64-redhat-linux/4.0.2/crtbeginS.o .libs/libFlaimWrapper_la-CSPObjectIterator.o .libs/libFlaimWrapper_la-CSPropertyIterator.o .libs/libFlaimWrapper_la-CSPStore.o .libs/libFlaimWrapper_la-CSPStoreObject.o .libs/libFlaimWrapper_la-FlaimWrapper.o /usr/lib/libflaim.a -L/usr/lib/gcc/x86_64-redhat-linux/4.0.2 -L/usr/lib/gcc/x86_64-redhat-linux/4.0.2/../../../../lib64 -L/usr/lib/gcc/x86_64-redhat-linux/4.0.2/../../.. -L/lib/../lib64 -L/usr/lib/../lib64 -lstdc++ -lm -lc -lgcc_s /usr/lib/gcc/x86_64-redhat-linux/4.0.2/crtendS.o /usr/lib/gcc/x86_64-redhat-linux/4.0.2/../../../../lib64/crtn.o -Wl,-soname -Wl,libFlaimWrapper.so.0 -o .libs/libFlaimWrapper.so.0.0.0

Which is 100% correct. It is NOT portable! But it kept on compiling.

Now I’ve run into an error I’m not sure how to fix. The build uses somethign called the gSOAP Skeleton Compiler:

** The gSOAP Stub and Skeleton Compiler for C and C++ 2.7.0c
** Copyright (C) 2001-2004 Robert van Engelen, Genivia, Inc.
** All Rights Reserved. This product is provided “as is”, without any warranty.

which appears to build fine:

Saving envStub.h
Saving envH.h
Saving envC.c
Saving envClient.c
Saving envServer.c
Saving envClientLib.c
Saving envServerLib.c

Compilation successful

but as the build tries to use part of this package, it dies:

gcc -DPACKAGE_NAME=\”\” -DPACKAGE_TARNAME=\”\” -DPACKAGE_VERSION=\”\” -DPACKAGE_STRING=\”\” -DPACKAGE_BUGREPORT=\”\” -DPACKAGE=\”simias\” -DVERSION=\”1.5\” -DSTDC_HEADERS=1 -DHAVE_SYS_TYPES_H=1 -DHAVE_SYS_STAT_H=1 -DHAVE_STDLIB_H=1 -DHAVE_STRING_H=1 -DHAVE_MEMORY_H=1 -DHAVE_STRINGS_H=1 -DHAVE_INTTYPES_H=1 -DHAVE_STDINT_H=1 -DHAVE_UNISTD_H=1 -DHAVE_DLFCN_H=1 -I. -I. -I/usr/include/libxml2 -DWITH_NONAMESPACES -DWITH_COOKIES -MT libsimias_la-envC.lo -MD -MP -MF .deps/libsimias_la-envC.Tpo -c envC.c -o libsimias_la-envC.o >/dev/null 2>&1
../../../tools/gsoap/linux-2.7/wsdl2h -c -o libsimias.h ../WebService/Simias.wsdl
make[3]: ../../../tools/gsoap/linux-2.7/wsdl2h: Command not found
make[3]: *** [libsimias.h] Error 127
make[3]: Leaving directory `/usr/src/redhat/BUILD/ifolder3-server-3.5.6102.1/src/core/libsimias’
make[2]: *** [all-recursive] Error 1
make[2]: Leaving directory `/usr/src/redhat/BUILD/ifolder3-server-3.5.6102.1/src/core’
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory `/usr/src/redhat/BUILD/ifolder3-server-3.5.6102.1/src’
make: *** [all-recursive] Error 1

Bummer. It looks to be a path issue, because the tool DOES exist:

/usr/src/redhat/BUILD/ifolder3-server-3.5.6102.1/tools/gsoap/linux-2.7/wsdl2h

And that’s where I am at. I’m going to forward all this to the iFolder folks so the source RPMs can get fixed. Hopefully I can figure out a way to get past this as I’m really looking forward to firing up iFolder on x86_64. I’ll update this as I make progress.

UPDATE 1: Here are the bugs I submitted for the above three problems: 165693 165696 165700

UPDATE 2: Here is a HOWTO related to Fedora building. Note the SELinux issues.

UPDATE 3: One thing I forgot to mention was when I used yum to install compat-libstdc++-33, it returned both the i386 and x86_64 versions to be installed. Wanting to keep things x86_64, I said ‘N’o to the install and grabbed the x86_64 version of compat-libstdc++-33 from rpmfind.net and installed it manually. Once I did that, all the other dependencies worked.

UPDATE 4: Ah-ha! Its not a missing file. Its another library problem. gsoap seems to expect that ld-linux will be in /lib. Note what happens when I try the failing command manually:

/usr/src/redhat/BUILD/ifolder3-server-3.5.6102.1/src/core/libsimias> ../../../tools/gsoap/linux-2.7/wsdl2h -c -o libsimias.h ../WebService/Simias.wsdl
bash: ../../../tools/gsoap/linux-2.7/wsdl2h: /lib/ld-linux.so.2: bad ELF interpreter: No such file or directory

Well that makes sense. ld-linux is not in /lib. It’s in /lib64: /lib64/ld-linux-x86-64.so.2

That would explain the failure. I’ll try a link hack again (bad bad I know) and if that works see how this can be fixed properly.  Well, if you softlink the library, the same part of the compile says it is trying to access a corrupt shared library. But it has me on the right track. Time to dig into the various Makefiles and see if I can figure out where it is hardcoded….

UPDATE 5: Duh - should have figured this out earlier. The iFolder-Server source rpm includes a precompiled version of gsoap - built on x86 so it fails to run on x86_64. I’m grabbing the latest gsoap source now and will build it on x86_64 which should allow the build to continue. I hope….

UPDATE 6: SUCCESS!!!!! Man that was painful! The ifolder source RPM includes a precompiled version of gsoap 2.7.0 which is an x86 compiled version. I found a gsoap v2.7.2 source RPM which I was able to build. I also was able to create a source RPM for v2.7.7 of gsoap, but the errors I got seemed to indicate soem API changes from 2.7.0. So I decided to just do for x86_64 what had been done for x86. I found v2.7.0f of gsoap (and a couple of patches) and compiled it for x86_64. I then spliced in that version of gsoap into the ifolder source tree. Tarred and zipped it up and put it in /usr/src/redhat/SOURCES and did an rpmbuild -ba off the ifolder SPEC file. And Voila! It Built! And it installed. Be afraid! I’m beat now, so I’m going to give it a whirl in the morning to see if it’ll actually run!

I’ll try emailing the developers tomorrow. If they can extract the gsoap dependencies such that the iFolder RPM uses a gsoap RPM, that would be very nice. The gsoap RPMs were somewhat confusing since the v2.7.2 RPM patched the gsoap source to switch from a simple stdsoap2.h to a numebr of headers (dom.h, xml.h, etc) I think gsoap made some major changes from v2.7.0 up through v2.7.7.

I’ve now got a buildable ifolder-server source RPM that will build on x86_64 (but since it is precompiled gsoap still it’ll ONLY build on x86_64) If I’m able to get iFolder running on x86_64, I’ll post a link to the src rpm I have.

Dad: “Do you want some milk?”
3rd: “I want some juice please”
Dad: “No juice this morning. You can have milk or water”
3rd: “Water is for dogs!”

OK then! Milk it is!

Yes, we have 3 dogs and #3 enjoys filling their water bowl … and dumping it out … and filling it again … and dumping it out…

When the other car hit, it lifted the back of my car up off the ground a bit and my car angled onto the right front tire (I had begun to turn the wheels left in anticipation of turning as the oncoming car went by). This directed me towards the ditch on my left and tore the tire off the rim. The scary part was my car went right across oncoming traffic. In the morning, since the middle school and high school are a mile or so down the road, traffic is heavy. Amazingly, nobody hit me head on as I flew across the oncoming lane and nobody hit the car that hit me.

Needless to say, this was a high speed collision. Looking at this picture, you see the Honda farther down the road. This is where it stopped after the collision - so a Honda Civic, hitting a stopped and braked Chevy Impala, continued on that far, since in the picture, my car was probably right about where it was on the road during the accident (the picture was taken after the tow truck had pulled it out of the ditch and across the road) Thankfully, both drivers walked away without a scratch. If you ever needed proof that the new safety features being put into cars are worth it, take a look at these pictures. The other driver had airbags which deployed and did exactly what they were supposed to. My driver’s seat absorbed a far amount of the jolt, however it gave a bit. I didn’t get a shot of it, but the seat frame actually twisted some (I weigh 200 lbs so the seat experienced a LOT of force). The seat giving way a bit and twisting some probably helped absorb some shock to my body as well. I make sure the headrest is always extended since I’m over 6′ 2″ so my head was supported. As I write this the next morning - I’m not even sore, which I expected to be. Thankfully my body was accelerated forward evenly by the seat and my head did not snap back … much (my ball cap did end up in the back seat though!).

An interesting thing - if you’ve been in an Impala, there is a deep compartment behind the ashtray under the radio and AC controls. I had set my Sirius satellite radio receiver down there. Now the receiver isn’t the heaviest thing in the world - weighs maybe a pound. My car jerked forward so quickly that the receiver flew out of the deep compartment, hit me, and bounced into the passenger seat footwell. Thus a 3500 lb vehicle moved forward so quickly that a 1 pound device got ‘left standing still’ and thus appeared to fly towards me and hit me. Ah physics.

The trunk of my car totally collapsed. The white rectangle at the center of the impact in this picture is MY license plate. That’s how far the car traveled into my trunk when it hit, which this shot illustrates. Note how the rear part of the frame pushed downward, ‘catching’ the oncoming car, and directing the impact upward a bit, protecting the gas tank. This ensured that the other car did not shove under my car, driving the rear of my car into their windshield. There were no gas leaks after this accident which amazed me. The front end of the other car disintegrated, but the rest of the car was amazingly intact. The passenger compartment of the other car was fine - there was no compression from the engine into the passenger area. Most of the debris on the roadway was the heavy duty foam filler from the bumpers which also absorbed much energy.

Thankfully I had just dropped my kids off at school and they weren’t in the car when this happened. But you can see that even though the trunk crumpled severely, the back seats were intact and did not buckle.

So I want to send a huge thank you to the engineers at GM and Honda who worked so hard to improve the safety of passengers and the ability of newer cars to handle high speed collisions. While there was plenty of luck involved (no oncoming traffic hit me, the car that hit me was a car, not an SUV or truck, etc), the aftermath of the accident made it clear that certain design decisions played a huge role in how the collision progressed. I also am thankful for the folks at the Insurance Institute for Highway Safety who have done so much to raise concerns over bad vehicle designs that can’t handle reasonable collisions. Interestingly, the rating on my car for rear collision head injuries was ‘Poor’ due to the geometry of the head rest. The Honda’s front crash ratings were good across the board.

We’ll hear more regarding the car and repairs next week, but given the damage, I can’t imagine it’s repairable. Not sure what I’ll try to replace it with.

Many people have had birds fly into their homes and getting them out is always exciting. But you haven’t had TRUE natural fun until a furry woodland creature comes over to visit. A few years ago a squirrel managed to come down a chimney and got stuck in our living room fireplace (which had glass doors on it) You want to talk about one pissed off rodent! We tried coaxing him into a pillowcase with a broom and very heavy gloves but he wasn’t biting (yet) So we opened all the doors and swatted him out of the fireplace. Man can those suckers move. He jumped along the walls (gouging them quite nicely in a few places) and finally dove out the door. Right into our yellow lab. I’m not sure whose heart almost stopped first - the squirrel or our dog who wasn’t expecting a pissed off rodent to come flying out our doorway. My wife & I were rolling on the floor as our lab recovered and chased the squirrel up a tree.

Well today we discovered that we have another ‘guest’ and whatever it is, it wants to check out NOW. It decided to try and chew its way out through a bedroom window. The disconcerting thing is, well, it didn’t quite succeed. It destroyed the window for sure, but didn’t quite get out. So needless to say we have a live animal trap set and ready so we can help our furry friend out the door since we can’t find the little sucker ANYwhere. I expect we’ll be sleeping downstairs tonight since the door to the room with the stairs stays closed - so it’s still up there. Here’s hoping it doesn’t decide to chew its way out anything valuable - replacing a window is going to be expensive enough! No clue what it is - though if you click the thumbnail to view the picture fullsize, you’ll see what looks like a paw print on the left pane of glass.

Update: Only took 12 hours to catch the sucker. He sprang the trap once without getting caught, but a mix of dry cat food and bird seed was too much temptation. In just under 24 hours he totally destroyed two windows (we found he had chewed the top sashes too behind the shades) and took a chuck out of the cherry vanity (he almost got gassed over that) Good thing the windows are due to be replaced during our upcoming renovations or I’m not sure he would have had such a joyful reunion with the wild! Squirrels make the funniest sound when they’re annoyed. He was NOT a happy camper! Now I’m off to seal the fireplace flu since it’s never used except by furry guests. Ah the fun of an old house!

All plugin information has moved to http://plugins.baptiste.us
Comments are now closed. Please use the new forums instead

I’ve used WP-Stattraq on various blogs I host in addition to AWStats. Stattraq gives a nice compact view of what’s being hit and from where. However as my sites drew more traffic, the Stattraq pages were taking a long time to load. On a hunch, I poked around the database structure and found that certain fields that were being searched by often (time, etc) were not indexed.

I added indexes to the wp_stattraq table for the following fields: ip_address, article_id, and access_time. I used phpMyAdmin, but you can also do it by logging into the mysql console client on your server:

bash>mysql -u (wordpress_db_user) -p -D (wordpress database) -h (database host if not local)

mysql>ALTER TABLE `wp_stattraq` ADD INDEX ( `ip_address` );
mysql>ALTER TABLE `wp_stattraq` ADD INDEX ( `article_id` );
mysql>ALTER TABLE `wp_stattraq` ADD INDEX ( `access_time` );

I’m not 100% sure if MySQL will build the index from all existing records when you create one or if you need to force it. To be safe, I optimized the table:

mysql>OPTIMIZE TABLE `wp_stattraq`;

Now your WP-Stattraq pages should load much faster. For me the difference was amazing. I did this for all my sites a few months ago and have been meaning to blog about it, but never got around to it. I dropped by Randy’s site to see if anything was new, and he posted about the problem and fix as well a couple of days ago. It’ll be included in the next version of WP-Stattraq.

Now if I can just figure out why v1.0b won’t peg hits for individual pages.

UPDATE: Via Paperback Writer, I also found another nice speedup for StatTraq - that will make your pages load faster for viewers. At boakes.org, he suggests you delay the insertion of the ‘hit’. This is a great tweak. Simply change your stattraq.php plugin file by finding the ‘INSERT INTO’ database SQL and change it to INSERT DELAYED INTO. This tell the script to hit the database and not to wait for confirmation of a successful insert, which is good if you care about the data, but these are hit stats. If a DB problem arose, losing a couple hit ticks would be fine.