trojanloy

UPDATE: I tried changing the code again, to the following…

define('AKTT_API_USER_TIMELINE', 'https://api.twitter.com/1/statuses/retweeted_by_me.json');

If successful, this would ONLY import “new retweets,” and then I’d need to find some way to merge the functionality of retweeted_by_me.json with user_timeline.json. But it doesn’t matter, because I had the same problem as before… retweeted_by_me.json imported my RTs, but cut them off if they exceeded 140 characters (including the original tweeter’s username). So evidently FriendFeed isn’t using an unmodified version of retweeted_by_me.json, which was my theory.

I managed to create a partial workaround by editing twitter-tools/twitter-tools.php so that the following line…

define('AKTT_API_USER_TIMELINE', 'https://twitter.com/statuses/user_timeline.json');

…now reads:

define('AKTT_API_USER_TIMELINE', 'https://api.twitter.com/1/statuses/user_timeline.json?include_rts=true');

This causes “new retweets,” or “newfangled retweets” as I like to call them (also known as “native retweets,” I guess), to post like all other tweets. HOWEVER, they have the same limitation as newfangled RTs in the Twitter RSS feed — they are truncated after 140 characters if the retweeted tweet is long enough that adding “RT @originaluser” before the tweet causes it to exceed 140. Ugh! Among other things, this makes it pointless for displaying RTs of long-ish tweets that have links at the end, since you lose part of the URL.

I can’t figure out why this is happening — I know it’s *possible* to avoid it, because when you import new RTs into FriendFeed, it doesn’t happen — or how to fix it. Any ideas?

it does work, it just doesn’t display properly in the control panel

rockwell08, how were you able to ascertain this? Is there some URL that I can type in manually to access the otherwise-invisible control panel?

This might be relevant:

https://www.ads-software.com/support/topic/103044?replies=5

Look here:

https://www.ads-software.com/support/topic/103044?replies=5

WOOHOO! I’ve solved the problem.

Setting is_page = FALSE didn’t work, for whatever reason, but searching for how to do that led me to an alternate solution, discussed in this thread: adding <?php $more = 0; ?> to my template. That did the trick!

For the sake of future searchers, here is what the relevant portion of my code looks like:

<?php $pageposts = $wpdb->get_results(\"SELECT *
FROM $wpdb->posts
WHERE ID NOT IN
(SELECT post_id from $wpdb->post2cat
WHERE category_id = ANY(SELECT cat_ID
FROM $wpdb->categories WHERE cat_ID = 369
OR category_parent = 369 OR category_parent =
ANY(SELECT  cat_ID FROM $wpdb->categories
WHERE category_parent = 369) OR category_parent =
ANY(SELECT cat_ID FROM $wpdb->categories
WHERE category_parent = ANY(SELECT  cat_ID
FROM $wpdb->categories WHERE category_parent = 369))))
AND $wpdb->posts.post_date < (NOW() + INTERVAL 2 HOUR)
AND $wpdb->posts.post_status = 'publish'
AND $wpdb->posts.post_type = 'post'
ORDER BY $wpdb->posts.post_date
DESC LIMIT $offset, $perpage\", OBJECT);
?>
 <?php if ($pageposts): ?>
  <?php foreach ($pageposts as $post): ?>
    <?php setup_postdata($post); ?>

<?php $more = 0; ?>

Ignore the backslash(es) before the quotation marks… they don’t belong there, but I can’t figure out how to get rid of them above.

Thanks, moshu, for pointing me in the right direction!

Heh, I understand.

P.S. to HandySolo: Is there any way to modify your Akismet setup, so that readers would get a message indicating that their support request has been sent into the queue by an automated spam blocker, and that if it’s not spam, the admins will approve it shortly? I know such a message would have prevented me from being so impatient – it was the frustration of not have any clue what was happening that caused me to post repeatedly and append my annoyed note to the admins.

If that’s not technically possible, maybe even a general message to all posters that appears below the Submit button that says something like, “Occasionally, new support topic submissions are held as possible spam until they can be approved by an administrator. If you topic does not immediately appear, this is probably why. Please be patient and do not re-post your topic. If it does not appear within _______, then you may want to contact ______ to check on the status,” blah blah blah. Something like that.

Just a humble suggestion. ??

HandySolo, thank you, and I apologize. I actually eventually guessed that it was probably a technical issue, but only after posting the above. To use a Wikipedia term, I shouldn’t have “assumed bad faith” … my mistake.

(Also, I don’t think I deliberately tried posting it 7 times – I’m pretty sure it was 4, and the first two, I thought maybe had been deleted because I had the code messed up. If there were 7 attempts, maybe there was some glitch whereby it registered twice when I clicked the Submit button… dunno.)

Moshu, thank you! I had done some searching, but hadn’t thought of looking at is_page. I’ll poke around and see what I come up with, and will come back here if I can’t find what I’m looking for.

I had this problem (or a slight variation of it) too, after upgrading from 1.5.2 directly to 2.1. I reverted to my backups, then tried upgrading incrementally from 1.5.2 to 2.0 to 2.0.7 to 2.1. That solved the problem.

You can see my help ticket here.

If you have pre-upgrade backups, I would suggest reverting to the prior version and re-upgrading incrementally. Of course, you’d lose any comments and posts that were added to the database since the original upgrade, but if you have access to MySQL through phpMyAdmin or whatever, it would be pretty easy to move those over into the re-upgraded database.

Alternatively, over on this thread, elpis2000 proposed a solution involving the wp_options table in MySQL. I don’t know whether it works, as I’ve already fixed the problem on my blog through the incremental-upgrade method, but you might want to try it.

For what it’s worth, there’s also discussion of this topic here. I agree that WordPress really needs to address this — it does seem to be a common, if not universal, problem in non-incremental upgrades to WordPress 2.1, and there’s nothing in the documentation suggesting that you need to upgrade incrementally. So WP needs to either diagnose & fix the problem, or else at the very least, add a warning to its upgrade instructions telling people to upgrade incrementally.

I’m afraid I don’t know, nicholaswong. You might want to check this thread, though.

In terms of “how to downgrade,” it would depend on whether you made a backup of both your database and you WP files before you upgraded, as the upgrade instructions suggest. If you did, you could revert to the backup and then re-upgrade incrementally; that’s what I did. Of course, you’d lose any comments and posts that were added to the database since the original upgrade, but if you have access to MySQL, it would be pretty easy to move those over into the re-upgraded database … I could help you with that if needed. However, it all depends on whether you have a pre-upgrade backup.

It’s my fault that the topic is marked as “resolved.” I created it, and then changed its status to “resolved” because it was, for me, resovled by upgrading incrementally, from 1.5.2 to 2.0 to 2.0.7 to 2.1. However, since that solution doesn’t seem to resolve the problem for everyone, I’ll changed its status back to “not resolved.”

For the record, the .htaccess solution definitely didn’t work for me. That was one of the first things I tried. I don’t know whether elpis2000’s suggested changes to wp_options would have done the trick… since I’m no longer having the problem (thanks to my incremental-upgrade solution), I can’t test it.

Anyway, good luck to everybody who’s still having this issue…

Geekninja, perhaps you might try upgrading from 2.0.5 to 2.0.7 and *then* to 2.1? That would most closely simulate the incremental upgrade that worked for me.

Not sure if this will solve your problem, but it solved mine: I tried upgrading incrementally, from 1.5.2 to 2.0 to 2.0.7 to 2.1, instead of going directly from 1.5.2 to 2.1, and I didn’t have the same problems.

It appears these problems only occur when you upgrade directly from WordPress 1.5.2 to WordPress 2.1. I tried upgrading incrementally, from 1.5.2 to 2.0 to 2.0.7 to 2.1, and I didn’t have the same problems.