aaronkarp

For what it’s worth, here’s the shortcode I’m using (and you can check out the result at https://planyourmeetings.com)
[thinktwit unique_id=0 usernames=”PYMLive planyrmeetings” show_author=username show_avatar=1 username_suffix=”: ” limit=20 max-days=7 update_frequency=0 show_published=1 links_new_window=1 no_cache=1 use_curl=0 debug=0 time_no_recent=”No recent tweets.”]

…and they’re gone again. Argh.

…and now avatars are showing up again. Apparently posting my problem fixed part of it. I suspect gremlins.

I don’t want to step on the developer’s toes by getting rid of his/her branding, but I just hid the div that has the header title.

.tweets_header {
display: none;
}

Yeah, I was thinking that disabling all of the plugins would have negated any effect like the one I was seeing, but I thought I’d mention it anyway, just to be sure. Sorry this didn’t help you. I guess mine was a rather specific case.

Follow-up: If you are using cForms, the easiest way to fix this problem is to go into cForms settings and uncheck Enable TinyMCE & Code editor buttons in the WP Editor Button support section of Global Settings.

I may have an insight on this, or at least a description of what seems to be the problem on my instance. Are you using cForms? Even if you’re not, a similar issue may be at the root of your woes. I found that some browsers are choking because my admin pages are https://, but some elements are coming over non-secure connections. Specifically, the cForms icon that appears in the TinyMCE toolbar was being flagged as insecure and not loading, which seemed to gum up the loading of the entire TinyMCE environment, causing the Visual Editor not to display and the text to remain white/HTML.

Disregard this, I figured it out. I left the pages tables out of my database export/import because changes had been made on the live server since I’d made a duplicate of the live database for testing purposes, and I didn’t want to overwrite anything. Of course, the pages necessary for logging in using the Front End Profile plugin didn’t exist on the live server. I disabled plugins via FTP, got logged into the dashboard, created the necessary pages, reenabled plugins, and all is well.

Looks like it was tag/pagename collision after all. Deleting the “toronto” tag fixed the issue. I still don’t understand why it seems to be ignoring the correct /topic/tag structure, but hey, it’s working, so that’s good.

Okay, now I find that *some* subpages load properly. mysite/destinations/toronto/ does not, but mysite/destinations/vancouver/ does. I’m thinking it might be a collision between the page name and a post tag, but since the permalink structure for tags is supposed to be mysite/topic/tag, that shouldn’t happen, right?

I’m having the same (or a very similar) problem. Sorry to see that no one has commented. I’m assuming you haven’t found a fix? In my case, the child pages’ permalinks bring up a tag archive page showing the child pages’ excerpts. The permalink structure of /parentpage/childpage works fine on the live site I’m working to replace, but in my WAMPserver testing environment (with the same WP configuration, as far as I can tell), I get the tag archive instead of the child page.

Of course, during the time it took me to write that post, everything returned to normal. Don’t mind me.

Never mind, I figured it out. If anyone else is wondering (probably not, as it’s really really simple, in frontpageSlideshow_TPL(), you can get the current slide number with $id + 1 and the total number of slides with count($fsentries). Nice and easy.