1. Relevanssi Search
The latest update of Relevanssi, version 3.3.4, seems to have handled the problems mentioned in my “interim report” – so I am using it now on the blog, and searches will now include all comments as well as posts, with the exception of Wall comments. Including the Wall tends to produce results with large numbers of misleading hits. Ideally, and perhaps with not too great difficulty, a separate, narrow search of Wall Comments could be set up, but it’s a low priority for me, especially since I’m always on the verge of dropping the Wall anyway. I’d have some further suggestions for the developer on presenting the plug-in and guiding new users, but I don’t have the time right now for a full improving WP Search with Relevanssi post. Maybe later.
2. Twitter Digest
I now realize that my initial guesses regarding production of truncated links were off (though the unnecessary excursion to Regular Expressions-land was educational). Instead, I’ve discovered a problem that is in some ways much simpler, though not easy for me at my present level of knowledge of the Twitter API and REST functions to solve. (I’m not even sure if I have just correctly stated the nature of the problem!)
I’ll put the problem here in something more like common language, prefatory to writing it up and grabbing examples:
Though I still think there might be some relatively infrequently arising RegEx or other problems in tweet re-formatting, after reviewing the “raw take” from Twitter prior to processing of output, the problem clearly originates there, or rather in the simple way that the Twitter Digest plug-in handles the data.
In short, in the case of retweets, the Twitter “fetch” provides two “text”‘s associated with user ID Strings. The plug-in takes the first “text” associated with the present user’s ID string. Unfortunately, this text will be in the old “RT” + “@twitterusername” format, meaning that tweets get cut off, sometimes extensively, to fit the 140 character limit. The original retweeted tweet is present in the Twitter data, in full, but is associated with the other (prior, retweeted) user’s ID String.
I will need to know how, in the case of retweets, how to get the second “text” rather than the first, and process it in order with regular tweets. Most twitter clients and Twitter itself use the second “original tweet” on user timelines unless the user/re-tweeter has actually manually entered “RT @[user-name”]”, or used a modified “quote” format, in order to re-tweet. So clearly it’s a problem that is both solvable and quite commonly solved in Twitter applications.
Though I don’t know how to do this yet, I haven’t given up hope of stumbling across a readymade solution or near-solution somewhere, perhaps in one of the many existing Twitter for WP plug-ins. If I don’t find what I need, I may create a “StackExchange” post on the subject. I am not sure how long it will take me to figure out how to do what I need to do, but this knowledge might eventually be very useful for developing more advanced twitter applications, for instance by utilizing some of the other information that Twitter Digest and similar applications fetch but don’t do anything with – such as full image URLs, user avatars, user background and profile images, data on favorites and retweets, and so on.