Not too long ago, I came across a nasty Sociable bug that completely prevented it from being used with certain server configurations. I located the source of the bug and nailed out a quick workaround that allowed the plugin to be used, but you lost the ability to change the site order. Tonight, I created a diff patch that is the first part of fixing that issue.

This diff has some lingering issues – namely dealing with legacy support and continued support. It works fine as is, but any previous installations will need to redo their social media choices, and future social media choices will need to be added in at the end of the data, rather than alphabetically. The first issue can be solved with some key scanning, the second issue isn’t a huge concern to me, since this array is only visible to developers, anyway.

When I got down to working on this plugin, I really had no idea what I was working with. I’ve never really looked into the Sociable code, and even less time on the WordPress code. However, I was going to get this thing fixes come hell or high water, and I think I accomplished my goal.

The first thing I did was write a regex find / replace to adjust the array. This array had nearly 100 elements in it, so a manual adjustment was out of the question. After I had adjusted that array, I went through the sociable.php file and put a bookmark everywhere that this array was possibly being used. WordPress is heavy on procedural code, so global variables such as this have to use the global command. I just sought out any function calling this variable globally. I also had to bookmark the end of scope on those functions, since the whitespacing and indentation was often done pretty haphazardly and in non-obvious ways.

I narrowed down my search to just three functions – sociable_html, sociable_restore_config and sociable_submenu. These three functions called this variable from the global scope and thus could be affected by my changes.

I first delved into sociable_restore_config(), which didn’t appear to actually use the array I modified. It really should not be calling it globally (which is horrible, anyway) and it might be some fragment of old code that never got properly cleaned up. The only place that things would be affected was the function to restore default settings. It was storing the keys based on the name of the engine, which won’t work under my patch. I modified this to save the IDs, but it is a bit hard to read. I’m not fully satisfied with this little trick, but it will do for now.

I next got into sociable_submenu() and noticed that most of the function will work with this new system. The most major concern is dealing with support on determining what is and is not an active site. Currently, it uses the string keys, but my patch changed those keys to autoincrement IDs in an array. This means that if you have Digg chosen, and it is #18, but a new engine is added before Digg, Digg is now #19, and the previous #17 will be chosen, as it is now #18. This could be a problem if the developer desperately wants to keep the array alphabetised, even though it really should be in the database.

This will also cause some legacy support issues in this area. Existing sites will store the value in the database as ‘Digg|Sphinn|Facebook’, but new sites will use ’18|47|22′ instead. This means that when it removes active sites, it won’t recognize ‘Digg’ as meaning ’18′ and will remove nothing. I can fix this with some variable scanning. If the variable is not an integer, do a foreach across the $sociable_known_sites and find which one it actually means. A single correction cycle will fix all issues – it won’t need to run that scan more than once per social media site.

The next thing I did was changed the form to display the correct information. Since the array has been adjusted and the keys no longer do what is expected, I had to change it to use the right value and display that on screen.

The only part I had difficulty with was the ternary statements in showing a social media site as being selected. Prior to my patches, it was doing an array merge on active sites and inactive sites, with the array keys being the name of the site. array_merge() leaves keys on strings, but wipes keys on numeric, so the keys used to remain intact but no longer would. This meant that if Facebook was ID #11, and it was chosen, it wouldn’t always display Facebook as being active. Instead it would merge active and inactive, and say the 11th item in the list is chosen.

In order to counter this issue, I did a little toying with array_combine(), array_keys() and array_merge() to merge the two arrays together and leave the array keys intact, even though they are numeric.

After this fix, all seemed to be well on the site. Legacy support for older key names and continued support to not break the data if the array is modified are going to be needed, but this patch changes the way the post data is sent to [hopefully] not cause an issue with certain Apache servers. Unfortunately, I can’t get my Virtual Machine (Ubuntu 9.04) to replicate the issue. I have a Fedora 10 VM that I may try to get the issue reappearing on, but if that doesn’t work, I can test the issue on Monday when I have access to the server that has a known issue.

Here is the diff patch, hopefully it will be implemented soon enough, as I think this does some good in correcting an issue that is out there. The traffic to my site searching for that issue is pretty substantial, and this patch covers the problem pretty well.

Update: I did some further thinking on the array_combine() trick and ended up removing it. It seemed like there should’ve been an easier way, and apparently you can just use + to union arrays based on keys, which is exactly what I doing. So, I adjusted the diff patch to use this setup, which is far cleaner and easier to read.