fneumeier

Just found the solution: my individual RSS feed was set the wrong content type in the header:

header(‘Content-Type: ‘.feed_content_type(‘rss-http’).’;

wasn’t a problem until WP 4.5, though.

Now I’ve changed it to:

header(‘Content-Type: ‘.feed_content_type(‘rss2′).’;

and everything is up and running again.

I may have found the solution myself: I’ve just recently changed the status of some postings from “published” to “private”, hence I suppose they’ve already been in the queue …

Okay, to clarify: the “post_status” in the database is “private”, but still Broken Link Checker alerts about broken links in these postings, though in the plugins options only “published” postings are set for link checking.

Please, an ideas how to solve this?

Thought there must be a simple solution … thanks a lot!

Es war kein Plugin, sondern eine Javascript-Codezeile im Tracking-Code für Google Analytics in meinem Theme (in der header.php). Die Methode, die ich dabei eingesetzt hatte, um Klicks auf ausgehende Links zu tracken, ist inzwischen veraltet und wird von Google Analytics ach nicht mehr empfohlen – aber wie’s halt so ist mit Code, den man einmal einbaut und dann vergisst …

Theoretisch k?nnte das Problem also mit Google-Analytics-Plugins auftreten, falls selbige noch diese alte Methode einsetzen; halte ich aber für recht unwahrscheinlich.

Works perfectly for me as well. Thanks a lot, @samstudio !!

Fehler gefunden – hilft vielleicht anderen, die auf ein ?hnliches Problem sto?en.

Schuld war ein Event-Tracker für Google Analytics, der Outbound-Links trackt und dementsprechend bei Klicks auf “http”-Elemente anspringt (bei relativem Protokoll fehlt das “http”, sodass der Tracker hier nicht reagiert und damit das Problem nicht auftritt):

$(document).on('click', 'a[href^=http]', function(e){...CODE...}

Ersetzt durch anderen (ohnehin besseren) Tracker und alles ist gut.

Nochmal Danke für Eure Hilfe!
Franz

Klasse, allein schon wegen der Code-Reduzierung ??

L?st mein Problem leider nicht – aber wie gesagt vermute ich die Ursache inzwischen eh’ in meinem Theme; wahrscheinlich geht das irgendwo unsauber mit jQuery um und verursacht einen Konflikt.

Was die Protokoll-relative Verlinkung angeht, stimme ich Dir zu; für externe Links ist das eigentlich nicht gedacht und irgendwie auch sinnlos. Mir ist nur durch den Xing-Link aufgefallen, dass das relative Protokoll einen funktionierenden Workaround für mein noch nicht identifiziertes Problem darstellt. Warum auch immer ras relative Protokoll dazu führt, dass mein Problem damit nicht auftritt …. Ich werde das jetzt erstmal weiter so anpassen, bis ich den eigentlichen Fehler gefunden habe.

Herzliche Grü?e
Franz

Klingt gut. ich behelfe mich derweil damit, dass ich die entsprechenden Links im Skript auf relativ ?ndere ??

Danke übrigend bei der Gelegenheit für Eure gute Arbeit an diesem Plugin!

Herzliche Grü?e
Franz

Nach weiteren Recherchen nochmal etwas tiefer gebohrt: jQuery 1.11.1 ist die Standard-Version von WordPress, die geladen wird, sobald ein Plugin oder ein Theme jQuery nach der von WordPress pr?ferierten Methode mit wp_enqueue_script() einbindet. Die zu blockieren macht also nicht wirklich Sinn. Die im vorigen Kommentar genannten Plugins l?sen also lediglich das Laden der Standard-jQuery-Version von WordPress aus und sind damit wohl nicht die Ausl?ser des beschriebenen Problems.

Allerdings: Mein Problem tritt beispielsweise nicht im WordPress-Theme twentyfifteen auf — also liegt die Wurzel des übels wohl in meinem Theme, auch wenn ich nicht ansatzweise eine Ahnung habe, wo das Problem da liegen k?nnte. Aber das ist natürlich erstmal nicht das Problem des Shariff-Plugins ??

Für weitere Tipps w?re ich trotzdem dankbar, falls jemand welche hat …

Herzliche Grü?e
Franz

Danke, starguide!

Ich habe jetzt mal intensiver mit Plugins in mehreren verschiedenen WordPress–Installationen getestet und der Zusammenhang mit https://ajax.googleapis.com/ajax/libs/jquery/1.11.1/jquery.min.js ist offensichtlich. Das Problem ist nur: Es gibt anscheinend zahlreiche Plugins, die diese jQuery-Version benutzen. Ich habe allein fünf in meinen verschiedenen Installationen gefunden, darunter z.B. auch das recht verbreitete cforms2. (weitere, die ich identifiziert habe, sind: ICS Calendar, UberMenu2, WP-Slimbox, Scoll Triggered Box)

Auch wenn’s ein Workaround um das eigentliche Problem (=überflüssiges Laden mehrere jQuery-Versionen) ist, l?st die Referenzierung mit relativem Protokoll das Symptom zumindest in meinen Tests zuverl?ssig. W?re also vielleicht eine überlegung wert, zumindest vorübergehend das auf relativ umzustellen, denn ich gehe mal davon aus, dass durch die offenbar gro?e Verbreitung von jQuery 1.11.1 in Plugin viele dieses Problem haben werden …

Herzliche Grü?e
Franz

Since this update, I’m getting the default image listed first, no matter whether there is a picture in the content or a featured image. So the plugin can’t be used anymore with the default setting, as Facebook in any case always shows the default image. Any ideas how to change this?

@spherical: That’s what confuses me: I’m not using a backend theme, I did de-activate all other plugins for testing purpose and the problem is still there. My theme is a highly modified theme I’m using for a few years now and I didn’t do any changes recently …

Thanks, I’ll give it a try.

As for now, I’ve rolled back the Live Blogging Plugin to an earlier version where this issue doesn’t appear, though this might not be a long-term solution …

The plugin is Live Blogging Plus (https://www.ads-software.com/plugins/live-blogging-plus/).

I’ve checked a bit more in detail and it seams not so much of a compatibility issue with this plugin (both, Live Blogging Plus and WP Facebook Open Graph Protocol are working together easily) or an issue with the Live Blogging plugin at all (except that it leaves the “post_title” empty). I first thought it puts the post_content in the post_title field, but it seams to be standar behaviour of WordPress to use the post_content as fallback it post_title is empty.

The issue seams to be that the Live Blogging plugin leaves the “post_title” and FB Open Graph Protocol (or even WordPress core itself?) seams to use the first x characters of “post_content” as fallback in case the title is empty.

As the Content usually atarts with an image (inserted via [caption ...] shortode), this shortcode goes into the Open Graph tag unfiltered.

Is there a way to simply (optional or always) strip shortcode from the content for use in the Open Graph tags? Or strip shortcode in case the content field is used as fallback for an empty title? Or something like this?