pmkelly

I’ve checked and double checked. The timeline album definitely exists. For some reason, the NextScripts plugin doesn’t use it. New posts always go to the app album.

Are there any funny permission things to check? Can you think of a reason the plugin would fail to find the timeline album even though it exists?

I saw that in the instructions and believe I did that (years and years ago). I post most of my images just directly on my timeline and they end up in an album called “Timeline Photos”. I even posted another one by hand this morning just to make sure.

Am I missing something?

Updated plugin this morning and get the same error as OP (“Fatal error: Call to undefined function restore_current_blog() in /[-shortened-]/plugins/social-networks-auto-poster-facebook-twitter-g/NextScripts_SNAP.php on line 248

Ah, glad I found this. Same problem, and the solution above does the trick. Thanks! (Although now my WP dashboard is telling me to update the plugin, which I assume I should not do?)

Hi Jeremy. I’m running into a similar issue. Featured images appear on the front page only. I cannot find any option at all that appears to let me do this for an actual single post. Whether I go through Jetpack->Mobile Theme->Configure or if I go through the “Settings” link for the plugin itself, I end up at the same page. And there is only one option there (to turn featured images on/off on the front/archive pages). Thanks.

OK, this feedback has been useful. It appears that both of these issues (font and dash) are at play. As a quick experiment, if I delete the spaces on either side of the dash in the title, it then appears correctly. When I put spaces around it, apparently something changes and the font then displays it “low”. Will have to explore the issue more later.

No, everything was typed directly into the WordPress editor.

Not sure this was an “ideal” resolution, but here’s what happened in case it is useful for anyone.

I moved to another hosting company.

Something of a last-resort option, and I am not putting it out there as a suggestion for others to follow. I never did figure out what the underlying issue was. But after a week of back-and-forth with my original host’s technical support, they basically told me “it’s a problem with your wordpress installation and not anything to do with our servers”.

I moved the exact same files to another provider, imported the database, and the problem is no longer apparent.

Again, not suggesting others take this path, since I never did determine the real cause for the issue.

Took forever to get hold of the log files, but have access to them now. The offending error in the log — or at least one of them — appears to be:

php5: UnableToConcatenateString `\x10\xb4\xaa\x03′ @ fatal/string.c/ConcatenateString/443., referer: https://www.pmkelly.com/wp/wp-admin/media-new.php

Any thoughts?

Will give it a try. Thanks!

I am also using the “official” facebook share button (as opposed to this plugin) and the problem mentioned above was driving me nuts. Finally invested some time to come up with a hack/fix. Again, this explains the workaround I used for the “raw” facebook share button, but I assume it could be added to this plugin as well.

https://www.pmkelly.com/2010/08/facebook-share-button-count/

I tried clearing the cookies, but continued to observe the same behavior. Your suggestion that debug pages are not being cached at all gave me another idea, though, and it does indeed appear that “debug mode” may be a red herring here.

What I noticed is this. When the plugin is *COMPLETELY* disabled, the pages all seem to load in a couple of seconds. That is the plugin is deactivated under the “Plugins” section in WordPress.

When the plugin is activated in the “Plugins” section, but the first option in W3 Total Cache is *UNCHECKED* (Deselect this option to disable all caching functionality) and “Debug Mode” is *NOT* selected, then the load time for each page is about 23 seconds.

And finally, when the first option in W3 Total Cache is *CHECKED*, the test results are all consistent with the findings I reported two weeks ago.

So it seems that there is some “overhead” associated with cache generation that is extremely slow on my site… and this slowdown is observed even when all caching function is disabled from the W3 Total Cache settings panel.

Is there an easy place in the code where I can get it to not “write out” the debug information? That is, leave debug mode “on” so it speeds everything up, but then “turn off” the actual part of the code that puts debug information at the end of every file source? I like the speed, but do not really want all of that information out there on a daily basis.

For some of these timings, minify was “on” and for others it was “off”. I always saw the same behavior. When minify was “on”, all three settings (HTML minify, JS minify, and CSS minify) were turned “on”. I did not experiment with different combinations within that panel.

I just ran another quick test to confirm that the minify setting does not seem to affect the observed issue. The only variable that is significantly affecting speed during cache generation is whether or not debug mode is on or not. Once the cache is generated, though, all settings across the board deliver a page in about 2 seconds.

I should point out that I am testing this from a browser that is not logged in to wordpress, so it should be consistent with somebody visiting my site from the outside world. I manage the W3 Total Cache settings from one browser (Chrome, logged into wordpress), clearing the cache each time, and then load the pages from another browser (Firefox, not logged into wordpress).

Well, OK, it looks like I did not have the w3-total-cache tag associated with this thread when I started it. Apologies for missing that the first time. Any thoughts or suggestions?