Inconsistent handling of URLs (esp pictures)

Are the ones you are seeing this in Retweets specifically? I have not seen this in non-retweets, but saw it routinely in retweets, so I looked into the problem, at least where truncation of Retweets are involved (which would often but not always break URLs just as you mentioned.)

The reason for this is outlined here:

https://code.google.com/p/twitter-api/issues/detail?id=2261

More discussion of this here:

https://dev.twitter.com/discussions/2994

I also found this discussion:

https://www.drupal.org/node/1182170

I modified the code from kjholla at that last link to do a mod to twitter-digest.php.

Here is the diff:

$ diff twitter-digest.php.orig twitter-digest.php
298a299,304

// Fix to stop truncation of native retweets by abulsme@abulsme.com based on comment by kjholla on https://www.drupal.org/node/1182170
if (!empty($tweet->retweeted_status) && is_object($tweet->retweeted_status)) {
$tweet->text = ‘RT @’ . $tweet->retweeted_status->user->screen_name . ‘: ‘ . $tweet->retweeted_status->text;
}

I submitted this fix to the widget author a little while ago, along with a couple other minor suggested changes and bug fixes. Hopefully there will be a new official release soon that addresses these.

That’s interesting! After some discussion with the plug-in author and some further research, I had concluded that the answer would likely involve a different method of capturing the full retweeted tweet (nothing to do with REGEX as I originally guessed), but an answer as simple as yours never occurred to me. Upon initial investigation, it appears to work perfectly – so congratulations and thanks (and fingers crossed)!

My impression is that the author is not interested in actively developing this plug-in further, though may add or accept interesting revisions. In one way or another, someone should publish an improved version. I’m not sure what the proper WP plug-in developer etiquette is in these cases.

As I’ve suggested elsewhere, the addition of CSS selectors to the output would also be helpful. They were the substance of my own first hack of the plug-in. I’ve also been exploring conversion of the “daily/weekly” digest application into more of a “tweet-scraping” tool for people, like me, who prefer to have the original texts archived and self-hosted instead of embedded “automagically.” Since I’m busy with other projects, I’ve contented myself so far with another minor hack, described here:

https://ckmacleod.com/2014/07/17/hacking-twitter-digest-plug-make-easy-tweet-posts/

Ideally, but far beyond my own capacities, we’d have something within WordPress resembling (within limits) Storify’s timeline-search capacity, so that we could more easily assemble both sides of a conversation. Much easier or anyway easier for me to envision would be a method for pre-formatting image-links as images for display, as on Twitter.com and Twitter’s own widget – though there’s also some appeal to me for a method that would involve also archiving those images rather than, again, depending on embeds.

In the meantime, as far as I’m concerned, your fix is major progress – so thanks again!

If you are interested, the other changes I submitted to the plug-in author for potential inclusion are:

* Fixed the regex that identifies twitter handles so it recognizes the twitter handle in dot replies, which previously were not getting made into links
* Added the timestamp of the retweeted tweet, after the handle and before the retweeted tweet text. This includes the date if the retweeted tweet is not from the same day as when it was retweeted, otherwise just the time. This way the digest shows not just the time you did the retweet, but the time of the original tweet as well.
* Move the timestamp to the beginning of each line rather than the end
* I changed the format of the timestamp when there is both a date and time to be date space time, rather than time comma date.
* Change the format of Retweets to fully say “Retweeted” to distinguish from manual retweets

Some of these just reflect my own personal preferences for formatting the tweets, so may or may not be of general interest. (Of course, it would be even better to have a way for users to define their own formatting template.)

You can see examples of the way this looks on the daily tweet digests on my site at https://www.abulsme.com

I’m reluctant to publish my changes directly, since it is not my plug-in. If you or anybody else is interested though, my email is listed on the site above, and I’d be happy to share my changes privately.

I am aware of one more outstanding bug that I’m not sure is within my skill to address. (I haven’t spent much time researching this one, and it sounds like at least part of the problem may be with PHP itself.) Namely, if your digest includes a tweet that contains emoji (or probably other types of Unicode) then it will fail at that tweet, and your digest will contain the tweets up to that point, but none after. [At least that was true last I checked, but that was a couple of updates ago I think, but the change log didn’t mention a fix to this.]

My other wish list item is to be able to set up separate digests for separate accounts. I currently have some automated tweets I publish related to one of my projects. Those tweets currently just get published on my personal twitter account, but I want to move them to a separate account in order to keep those things separate, but then start publishing a SECOND digest post for posts to that account. My first thought is to just clone the plugin and run two copies concurrently, but it would be nice if there was built in functionality for that within the main plugin. I admit that one may be somewhat of a niche request though. ??

Just a quick comment on having multiple “instances” of TD running simultaneously: It definitely wouldn’t be a niche request for people operating multi-author blogs in which each author might want his or her own digest or scraping-tool. As for myself, even if I don’t resume a daily digest, a different way of handling the database or overlapping queries would be preferable.

Introducing “multi-account” or “multi-handle” functionality of some type might also get you closer to the Storify-like capacity I mentioned. So, let’s say you and I had an interesting Twitter conversation: It would be nice if I could enter my handle and your handle, scrape up our tweets, and produce a post with them – if not, most likely, an auto-post.

That might be a different implementation than multiple accounts, or it might overlap. I’m not sure whether it would require multiple authentications or could all be handled with one.

Perhaps further discussion should be taken to email or some other venue: You can use comments on my blog thread linked above, or try the contact form at my blog, thou I can also just email you directly if you prefer.

Feel free to contact me if you wish. Not sure I can be much additional help though. I’m not actually a “real” developer. Just know enough to use google and hack up the few changes I made. ??