CK MacLeod

Sorry – in the above comment, where I wrote “When I didn’t notice any differences in behavior,” I meant to say, “When I didn’t notice any differences after upgrading to PHP 5.5.” So, the point was I updated to PHP 5.5, didn’t notice any changes, then deleted the site cache, and the problem cleared up. I had already deleted (and re-deleted) the browser cache, both on this site and on the site that still produces the empty page with search-highlighting turned on.

Hmmm, the differences between the development (XAMPP) and regular (shared hosting) environments behavior led me to look for configuration variables, and I noticed that the regular site was still on an older version of PHP (5.2). When I didn’t notice any differences in behavior, I deleted the site cache (which “shouldn’t” be involved in this matter, since it’s not supposed to cache for admin), and, voila!, Relevannsi seems to be working properly… EXCEPT not on the smaller site, which is at the same host, but doesn’t use caching.

So, I’m still stumped as to the likeliest cause of the remaining problem. The other obvious difference is that the problem page is, as previously noted, a WordPress Page, not a Post.

I will research some other possibilities, but, now that the problem with the larger site seems to be fixed, I’d probably forget about it. Only the fact that you said other people have complained about the problem leads me to think it might be worth continuing to investigate.

Not really sure cc. Seems like a newfangly kind of theme, and I confess I’m not totally up on all new fangles.

The page in question does include some shortcode – in fact a specific piece of shortcode used repeatedly that enables a javascript “spoiler,” though doesn’t either render the page in its entirety or enclose its content. The shortcode is not used on the site where I first encountered the problem.

I was just trying to check out the problem on my development (local) site. Had some odd functionality with Relevannsi, but the same problem that re-produces dependably on the nearly identical on-line site doesn’t on the local site.

I agree it’s odd, and not just because it affects the post-entry but not the comment text.

I have Relevannsi set up on two sites with similar customized themes. I didn’t seem to get get the behavior on the second site until I updated to 4.01 AND to the latest Relevannsi, but it’s hard to be sure. I get the behavior on (so far) one post, but not on others – in fact on 1 post only out of around 10. To be specific, actually, the one with the missing entry is a WordPress Page, not a Post, but on the first site the problem did show up with regular Posts, so that difference doesn’t look to be definitive.

Anyway, it’s not a big deal to remove the formatting, though it is a nice little extra… I hope you get a brainstorm on it!

Just happened to notice after leaving my own query: When I look at the source code of your page, the search input has the name “search,” while the default for WordPress search for the text line is name="s" not name="search".

https://codex.www.ads-software.com/Styling_Theme_Forms#The_Search_Form

As you will see, it also has two standard input lines: “text” and “submit.” I wonder if the designer of your theme has introduced a custom search function of some type.

(Also, incidentally, when I bring up your site on Firefox, I first get a blank page, then have to refresh to get the page to load properly. On Chrome, I get somewhat similar behavior when I try to use the Search function. The site loads properly the first time, but on search results draws an initial blank.)

Sorry, I fudged the distinction I meant to indicate. Shouldn’t have said “the Loop.” Meant that it doesn’t happen on home and archive pages that loop through excerpts, so show multiple posts. It happens on Pages with their own static content and comments. I didn’t check single.php because I don’t show most widgets on single.php, but seems like an obvious step.

Am using 4.0 and a heavily customized as well as plug-in-ized theme that started with Responsive a long time ago. When I get a chance, I’ll see if I can pinpoint the problem. Probably a plug-in conflict if you’re not running across it with your set-ups.

As far as I know, all of the posts (old as well as new) are default set to “show,” even with Admin set not to show.

Console shows a thickbox js error – TypeError: jQuery(…).on is not a function – with the version of Thickbox that is I believe included with WP.

that was 4 additional notes, not 3 ??

3 additional note:

1) if set to appear, the Floating buttons DO show up on pre-April 2014 posts.

2) if I create a new post, but backdate it to April via the Publishing settings, the buttons DO appear on the post.

3) Add-to-any CSS stylesheet has no effect.

4) Finally, if I add the “manual placement” A2A Kit php to my single.php, the buttons DO show up on the all posts.

In view of #4, I have for now, pending any updates, unchecked “display at bottom” and left the A2A Kit code in single.php, preserving the desired functionality as far as I can tell.

One other suggestion on the series widget:

5) Another desirable option would be include/exclude categories and/or specific post IDs, allowing for multiple instances of the widget, and, in effect “sub-series.” Might also apply to “series pages” and other uses, for instance if I have a group of multi-part posts on one subject matter – WordPress Development – and another group on an unrelated subject matter – Political Philosophy. When I get a chance I’ll see if I can achieve the same effect with multiple shortcodes on a single page or in a single text widget.

Also to be investigated: use in conjunction with various membership, paywall, and newsletter plug-ins and applications.

Oops – meant to include and obviously important on the Fatal Error: It is produced when using the “Select” style for list output.

Upon further investigation, the incidentally interpolated code from the Simply Exclude plug-in – “se_cfg[post][terms][is_home][45993]=on” and similar – is not directly related to the problem. With SE deactivated, a 414 error is produced via overlong URL is produced either with the Search Posts box as well as with the Filter function. The URL’s reiterate is_series_save=1 a few hundred times before tereminating with the same action2=1, whose function and origin I do not know.

I’ve attempted to identify a problem with is_series_save by searching through OS files, but various minor hacks – deleting the function that appears around line 140 of orgSeries-admin.php or replacing it with a version using in OS 2.2 have not solved the problem.

I’d very much like to use the plug-in and see if I want to adapt it, or the pro version, for extensive use on my blog, but disabled post-search and -filtering functionality doesn’t seem worth it. I think a plug-in that disables core WP functionality probably qualifies as broken though there are a few other possibilities I’ll check before I put in a final rating and move on.

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.

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!