volomike

Has anyone forked this yet and stuck it up on www.ads-software.com with this tweak?

The user posted to me what the problem was, but for some reason it didn’t post back to here. So, I’m posting it for him in hopes that it helps a user out there:

“I figured out what the problem was. I had a long list of “Update Services” (under Writing Settings) that I cut & pasted from a list I found somewhere. I decided to run the list through a link checker and about 90% of the links were dead. After removing the dead links, no more ping errors.”

I was seeing this too. As far as I can tell, it’s part of the third-party Incutio XML RPC library used during the upgrade process.

/var/log/apache2/access.log:127.0.0.1 – – [10/Jan/2012:17:16:24 -0500] “POST /pinger/ HTTP/1.0” 404 493 “-” “The Incutio XML-RPC PHP Library — WordPress/3.3.1”

That was in my access log at the same time that I had errors in my Apache error log (/var/log/apache2/error.log) that said:

[Mon Jan 10 17:16:24 2012] [error] [client 127.0.0.1] File does not exist: /var/www/pinger

On your system, I would guess that /var/www/html is where your web server hosts its files. In my case, mine is /var/www.

That’s all I have for now. If you find anything else out, please post it back here.

<? function addDashboardAlert() { ?>
<style type="text/css">
.alert {
padding-top:4px;
padding-bottom:6px;
padding-left:302px;
background-color:#ebfbff;
border-bottom:1px solid #CCC;
display:none;
}
</style>
<script type="text/javascript">
$j = jQuery;
$j().ready(function(){ //when page has fully loaded
  $j('h2:contains("Dashboard")').parent().prev().after('<div id="my-plugin-alert" class="alert">X Plugin 2.0 is available. <a href="">Upgrade Now!</a></div>');
  setTimeout("$j('#my-plugin-alert').fadeIn('slow');clearTimeout();",1000);
});
</script>
<? } add_action('admin_head','addDashboardAlert'); ?>

I don’t know with IIS, but perhaps you can translate what I would suggest in Linux and do that with Windows.

On LAMP, given your problem, I would be mounting a shared volume with either NAS or iSCSI or NFS. I would mount this on each Linux web node as /var/www. The blog code would load on each web node from that code base. That way, there’s no syncing between web nodes because it’s the same file base. Then, I would use LVS (linuxvirtualserver.org) for the web farm, and point it back to a central MySQL database. (That alone would pick up performance. However, to improve the MySQL performance you could cluster it, or at least add replication so that you have a fast system to cutover too in the event of a problem.)

Hey! I found the fix! If you leave your search.php alone and let it do what it normally does, you can make (or edit) functions.php and tack on something like this:

$sCategory = 'chickens';

add_filter('pre_get_posts','filterPosts');

function filterPosts(&$args) {
	if ($args->is_feed) {
		$cats = get_categories();
		foreach ($cats as $cat) {
			if ($cat->name == $sCategory) {
				$nCatID = $cat->cat_ID;
				break;
			}
		}
		$args->set('cat',$nCatID);
	}
	if ($args->is_search) {
		$cats = get_categories();
		foreach ($cats as $cat) {
			if ($cat->name == $sCategory) {
				$nCatID = $cat->cat_ID;
				break;
			}
		}
		$args->set('cat',$nCatID);
	}
	return $args;
}

The first part referring to is_feed() helped me restrict a feed to a category. The second part referring to is_search() helped me restrict a search to a given category.

By trying to do this in search.php, instead, you will be hit with all kinds of “can’t get there from here” situations for some reason. Perhaps a bug in WordPress? I don’t know exactly. And the default query that is passed to search.php by default is already established and cannot be hooked for some reason unless you do it from functions.php, which gets called earlier than search.php. You can see this if you add an add_filter(‘all’,’test’) in search.php to dump out results to see what search.php does — it won’t let you have access to the main query it uses by default. This is why the intercept on pre_get_posts must be done from functions.php.

I’m getting the same exact problem. It’s like one can’t have their cake and eat it too. I have tried editing search.php in a custom theme in various ways, but they all have quirks so far:

– using in_category(‘cars’) inside a loop causes pagination to break!

– using query_posts(‘cat=4’) before the loop gives me category filter but ignores the search!

Thanks, MichaelH. That’s close, but not quite.

Dynamic Widgets basically lets me restricted which widgets get displayed on which pages, but doesn’t change the functionality of a widget.

Widget Logic lets me change the functionality of a widget but only as far as replacing its content, but you still have to make a callback function. And this is more easily done without this widget by editing your theme files. You can edit your sidebar.php file and tack something in at the top like:

add_filter('dynamic_sidebar_params','filterWidget');
function filterWidget($args) {
  switch($args[0]['widget_name']) {
    case 'Meta':
    case 'Categories':
    case 'Pages':
      return 0; //hide widget output
      break;
    case 'Links':
      //display new widget replacement output
      echo '<li class="widget"><h2 class="widgettitle">Links</h2>Hello world</li>';
      return 0; //hide previous widget output
      break;
    default:
      //echo "<br /><br />";
      //print_r($args);
      //echo "<br /><br />";
      return $args;
  } //end switch
}

The above code hides the Meta, Categories, and Pages widgets, but then takes the Blogroll (aka Links) widget and replaces its content entirely.

So, it’s through the add_filter() call on the dynamic_sidebar_params that I am going to be able to rebuild the default gadgets with replacement code. It’s fairly easy to rebuild the Archives, Recent Posts, and Recent Comments plugin logic with one that restricts by category. But rebuilding the Calendar and the Tag Cloud takes a bit of work.

Anyway, my problem is solved because I think this is the best approach. I mean, if one writes code that goes directly against the native SQL API in their plugin, it will work today, but will be a rocky road in the upgrade path potentially, especially as we approach the dramatic changes of WP 3.0 coming down the road. It’s best to try and remain within the codex as much as possible to provide the best upgrade path for your theme or widget, in my opinion.

This may not be the WP developer-recommended way, but I came up with a solution:

https://stackoverflow.com/questions/1984555/how-can-a-plugin-hijack-a-url-in-wordpress/1984985#1984985

This could then be attached to a custom admin panel such that one could hijack any URL they want.

This gives one the ability to embed another web app inside of WordPress. So one may ask — why do that? Well, by doing that, you get these advantages:

1. Can drive sales off something that is an addon to WordPress. Since WP has “buzz” in the marketplace, so too can the web app.

2. Solves the customer question — “Can it integrate with my WordPress site?”

3. Gives you an authenticated admin login page and a place to park an admin panel for your web app.