visual77

Thanks for the feedback. I looked into fixing issues #1 and #2 and decided that I was just adding bandaids that would come back later to suck.

You were right on saying this change is not ideal. While I could get it to work and play nice with legacy and continued support, it would get awkward.

I have an idea that adjusts only that hidden input. It would still use numeric IDs instead of string keys, but only that one spot – the array would go unchanged, the database save string would go unchanged, the sociable_html() function would remain, etc.

I hope to get that diff up tonight, but I can’t guarantee it. Tomorrow night, though, if I am unable to finish it tonight.

Silly me – that whole array_combine trick was unnecessary. I went back and looked at it again, and simply using + to do an array union has the same effect. I just updated the diff to use this more efficient set up.

I’ve got a first patch completed and available. Apply this diff to 3.4.3 to take the changes.

https://www.visual77.com/wp-content/uploads/2009/07/sociable-patch-001

This *will* fix the errors, but does have some drawbacks. I rearranged the $sociable_known_sites array to use numeric IDs instead of string IDs. I then rearranged the settings form and how it determined active and disabled sites. I’ve tested with adding, deleting and rearranging sites, along with restoring the settings and viewing it on the posts, it works in all scenarios.

The drawbacks are mostly dealing with legacy support and continued support. Applying this patch would require redoing the active sites, as the current setting uses strings and this patch does not, but I have a plan to correct that issue. Continued support is fully possible, but future engines have to be added to the end of the array, which would break the alphabetical order. This array would be much better suited to a table in the database, however.

I found myself having to do some interesting stuff to get it working, especially with that array_merge($active, $disabled) when displaying all the sites. Since array merge scrubs numeric keys, and this patch relies on numeric keys, I had to use a combination of array_combine, array_keys and array_merge to maintain the array as needed and keep functionality intact.

However, as I said in my last post – I’m working blind, so take this fix with a grain of salt. If I can get my VM to replicate the issue before Monday, I’ll do a proper test, otherwise, I will let you know on Monday if this fixes the error in a server that has the error.

I finally have some time to debug this issue and now I’m having trouble replicating it. My VM environment just won’t throw the error. The environment that I originally had the error is off limits to me at the moment, and I don’t know the exact configuration it is working with.

So… since I’m working blind here, I’ll focus on changing that post data to IDs and pipes, correct other calls to make use of this new data structure, and hope it works. I’ll post the diff patch once I’m done, but I can’t be sure it will actually fix it until I can replicate the bug and try it out in that environment – which would happen Monday when I can access the bugged server again.

I’ll give that a shot. I think the regex is just scanning for the word ‘ping’ and assuming it’s an intrusion. My plan is to adjust the array to use numeric keys instead of string keys, and have the site order use those IDs instead of the name of the engine. I can’t imagine mod_security freaking out over just numbers and pipes.

If it’s only two people complaining, then those two people search for that exact error message and find my fix surprisingly often.

I’ll have a diff ready for you before the end of the day tomorrow.

That’s a pretty odd comment. You can do something about it, and get it working for people, but you won’t and instead point the blame at someone else.

Want me to fix it up for you so people can use your stuff on all platforms, since you seem unwilling to do so?

Have you tried just removing Ping.fm from the list of social media sites that Sociable supports? You can do this by editing wp-content/plugins/sociable/sociable.php and remove lines 345 – 349. Those were the lines for me, at least. If you have any experience with PHP syntax, it will be easy to spot, but just remove the item in the array for Ping.fm.

Could you take a screenshot of the entire WP Super Cache settings page? Screengrab is a great Firefox extension for capturing an entire page in a single image.

Go into your mysql database through an interface such as phpmyadmin. Go to the wp_options table and sort by the option_name field. Find the option called ‘polldaddy_api_key’ and delete it.

Alternatively, just execute this sql call from within the mysql interface:

delete from wp_options where option_name = 'polldaddy_api_key';

Open up wp-content/plugins/social-access-control/social-access-control.php and right before line 453, add this line:

if(!is_object($user)) var_dump(debug_backtrace());

The resulting dump is going to be pretty big, so if you can’t post it here, you can email it to me at [email protected] and I’ll take a look. I’m having trouble replicating the bug. I think it may be caused by your particular Social Access Control settings.

What other plugins do you have installed?

Well, this was more of a pain to debug than I had thought it would be, but I’ve got an answer for you.

Open up wp-content/plugins/feedwordpress/feedfinder.class.php and change line 110.

Right now, it should say:
$headers['Accept'] = "application/atom+xml application/rdf+xml application/rss+xml application/xml text/html application/xhtml+xml */*";

Change it to say:
$headers['Accept'] = "application/atom+xml, application/rdf+xml, application/rss+xml, application/xml, text/html, application/xhtml+xml, */*";

I tried this with youtube feeds and it works, along with a few RSS feeds. That should patch up the issue and get you running again.

I ran into this same issue and spent some time debugging it to find the error. I wrote a post on it to help other people get through it.