Tweets Made When Option Unchecked

[GoogleCodeExporter]

What steps will reproduce the problem?
1. Uncheck the "Update Twitter when the an old post has been edited" option
and click the "save options" button.
2. Edit and old post and save.

What is the expected output? What do you see instead?
A tweet is sent even though the option has been unchecked.

What version of the product are you using? On what operating system?
1.1.0

Original issue reported on code.google.com by goldd...@gmail.com on 22 Jan 2009 at 5:50

[GoogleCodeExporter]

I fixed this in my own install of the plugin by changing the main IF statement 
in
tweetly_updater.php as follows:

        if ($thisPostPreviousStatus == 'publish') {
            if(get_option('oldpost-edited-update') == '1') {
                $sentence = get_option('oldpost-edited-text');
                if (strlen(trim($thisposttitle)) == 0) {
                        $post = get_post($post_ID);
                        if ($post) {
                                $thisposttitle = $post->post_title;
                        }
                }
                if(get_option('oldpost-edited-showlink') == '1') {
                        $thisposttitle = $thisposttitle . ' @' . $shortlink;
                }
                $sentence = str_replace ( '#title#', $thisposttitle, $sentence);
            }
        } elseif(get_option('newpost-published-update') == '1'){
                $sentence = get_option('newpost-published-text');
                if(get_option('newpost-published-showlink') == '1'){
                    $thisposttitle = $thisposttitle . ' @' . $shortlink;
                }
                $sentence = str_replace ( '#title#', $thisposttitle, $sentence);
        } else {
            exit();
        }

Note that I changed the ELSE on line 69 to an ELSEIF and added my own ELSE on 
line 75
so the IF will exit.  This prevents the posts from tweeting if the options are 
set to
anything except 1.

Original comment by goldd...@gmail.com on 22 Jan 2009 at 6:11

[GoogleCodeExporter]

Actually the exit(); doesn't work.  putting $sentence = ""; in the ELSE does.

Original comment by supp...@golddave.com on 22 Jan 2009 at 7:49

[GoogleCodeExporter]

Actually $sentence = ""; doesn't seem to be working properly either.

Original comment by goldd...@gmail.com on 23 Jan 2009 at 3:01

[GoogleCodeExporter]

What is your Wordpress version?

Original comment by mizeh...@gmail.com on 24 Jan 2009 at 10:41

[GoogleCodeExporter]

There was an error in the varaible names of the Tweetly Updater options so some 
of
the options were simply ignored. You should upgrade to 1.1.1 an resave your 
options
for Tweetly Updater.
Also it turned out that the $_POST['prev_status'] variable that was used to get 
the
previous status of the post doesn't work anymore (at least in the latest WP 
version).
Since I see no other way to get the previous status of a post, the new version 
adds a
custom field with the shortend url to the post. So every post with such a field
counts as an update.

Original comment by mizeh...@gmail.com on 24 Jan 2009 at 2:06

• Changed state: Fixed

[GoogleCodeExporter]

I'm using WP 2.7.

I was playing with the code the other day and noticed that $_POST['prev_status']
wasn't working.  I'm trying to find a better solution than adding a custom 
field.

I like this plugin because it is compact and uses bit.ly.  If it's going to 
depend on
custom fields then it becomes less attractive to me.

Original comment by goldd...@gmail.com on 25 Jan 2009 at 6:46

[GoogleCodeExporter]

Yes, the custom field is suboptimal in this place. But I see no other way to 
get the
previous status. I thought about revisions, but the "draft" status gets 
overwritten
when you publish a post, so you can not find it anymore when you iterate over 
past
revisions. 

Original comment by mizeh...@gmail.com on 25 Jan 2009 at 8:07

[GoogleCodeExporter]

I was looking through post-new.php and realized there is a field being posted 
called
"original_post_status". I took version 1.1.0 and substituted
$_POST['original_post_status']; in place of $_POST['prev_status'];. A quick test
showed that this worked but it needs more testing.  Does this solution seem 
plausible?

Original comment by goldd...@gmail.com on 25 Jan 2009 at 9:34

[GoogleCodeExporter]

I will look minto this. But all these solutions around $_POST work only with 
posts
submitted via the admin interface forms. They will not work with posts that are
submitted via xmlrpc or the api. Why do you think custom fields are problematic?

Original comment by mizeh...@gmail.com on 26 Jan 2009 at 5:34

[GoogleCodeExporter]

I personally only post from the admin interface. I don't even know how to post 
via
xmlrpc or the API.  (I'd be interested in learning how.)

I don't like adding a custom field because if I end up removing this plugin in 
the
future I don't want to leave any remnants of it behind.

Original comment by nycstin...@gmail.com on 26 Jan 2009 at 5:40