posts with the tag: events

Posted by: bob on Thursday September 15th 2011 no comments
Tags: events, publish_future_post, publish_post

This problem has been bothering me for a while now, and I only just came across the solution this week. The issue was that when you schedule a post for the future, when it does finally post it was seemingly not running the publish_post hook that I had set. Multiple solutions suggested using future_to_publish as a hook, and that did not work either. The actual solution was to hook to publish_future_post, but in addition the function I was executing had to be modified a bit.

The original function was something along these lines: When a post is published for the first time, post a link to it on Twitter. publish_post also fires when you update a post, so to make sure it was only posted on the original posting the accepted solution was to make sure post_date and post_modified dates were equal. Here is an simple example.

PHP Code:
<?php

// accepted solution, but this will not work as expected
// on scheduled posts.

add_action('publish_post','bob_on_publish_post');
add_action('publish_future_post','bob_on_publish_post');

function 
bob_on_publish_post($id) {
    
$post get_post($id);
    if(
$post->post_modified != $post->post_date) return;
    
    
// la de da, doing stuff.
    
    
return;    
}

?>

The reason this fails is that it turns out when a post is scheduled for future posting, post_date and post_modified are not equal after all. This issue caught me by surprise because it does not exist when working with Drafts. If the post is marked as draft, saved, and then manually published later, this test will still allow the hook to run. This is probably due to how WordPress handles filling up your database with redundant revisions, but it even works if you have a Plugin disabling revisions (like me).

Continue reading about the scheduled publish hook…

Posted by: bob on Thursday March 17th 2011 no comments
Tags: events, gtkprogressbar

Understanding the how to deal with pending events is an important part of programming with GTK. While not technically accurate (in any regards), it is useful to think of a PHP-GTK application as two threads or processes working together for one program. In one hand you have PHP running the program, on the other you have the GTK library running an idle loop to process its UI. If you hard lock PHP into a processing (for, while, foreach) loop GTK will be unable to process its updates until PHP finishes, and visa versa.

Here is an example where you might run into this issue. Lets say you have a directory full of files you need to read, and a window displaying a progress bar. These are two symptoms you might encounter:

  1. the appearance that your program has hardlocked and must be killed, and then at the last minute your progress bar jumps to 100%.
  2. your progress bar updates sporadically jumping large amounts instead of smoothly across.

… and both of these, generally, can be solved very easily. Most of the time just telling GTK to process events is enough to do it. And how do we do that?

Continue reading about GTK Pending Events…