Oft werde ich gefragt, wieso Office-Dateien (Word, Excel, PowerPoint) im jeweiligen Office-Programm öffnen aber PDFs im aktuellen Browser-Fenster/Register öffnen. Leider kann das auch heute noch nicht einfach konfiguriert werden.
Je nach Browser und PDF-Reader kann das vielleicht auf dem Client konfiguriert werden, aber spätestens seit Firefox und Chrome mit eigenen PDF-Viewern einen neue Vielfalt möglicher Konfigurationen hervorgebracht haben, muss dies im SharePoint gelöst werden.
Es gibt im Internet einige Beispiele um dieses Problem per JavaScript zu lösen (siehe unten), jedoch funktioniert keines davon mit neuen AJAX-Features in SharePoint 2013 (Minimal Download Strategy und Client Side Rendering).
In diesem Beitrag zeige ich, wie es in SharePoint 2013 und Office 365 mit JavaScript gelöst werden kann.
Einfachste Lösung
Der einfachste Weg ist natürlich mit jQuery. jQuery binde ich in der Regel über die Master Page ein und platziere Globale JavaScripts in /SiteAssets/Scripts/Global.js. Für SharePoint 2013 könnte eine einfache Lösung folgendermassen aussehen:
$(document).ready(function () {
function updatePdfLinksTarget() {
$("a[href*='.pdf']").attr('target', '_blank').prop("onclick", null).attr("onmousedown", null);
}
updatePdfLinksTarget();
setInterval(updatePdfLinksTarget, 1000);
});
Die Lösung funktioniert mit sämtlichen PDF-Links aber ist nicht besonders effizient. Dieses JavaScript durchläuft jede Sekunde das gesamte DOM und modifiziert dabei immer alle Links mit .pdf im Pfadende. Somit müssen nicht alle möglichen Seiten-/DOM-Modifikationen von der Minimal Download Strategy (MDS) und Client-Side Rendering (CSR) speziell gehandelt werden.
Bessere Lösung
Eine effizientere Lösung ist, die PDF-Links auf der Seite nur zu suchen und modifizieren, wenn per MDS die Content Area aktualisiert wurde oder wenn per Client-Side Rendering sortiert, gefiltert oder die Seite gewechselt wurde (Paging). Das folgende JavaScript macht genau das:
function initUpdatePdfLinksTarget() {
if (typeof SPClientTemplates != "undefined" && SPClientTemplates.TemplateManager)
SPClientTemplates.TemplateManager.RegisterTemplateOverrides({ OnPostRender: [updatePdfLinksTarget] });
updatePdfLinksTarget();
}
function updatePdfLinksTarget() {
$("a[href*='.pdf']").attr('target', '_blank').prop("onclick", null).attr("onmousedown", null);
return false;
}
ExecuteOrDelayUntilScriptLoaded(function () {
if (typeof asyncDeltaManager != "undefined")
asyncDeltaManager.add_endRequest(initUpdatePdfLinksTarget);
else
initUpdatePdfLinksTarget();
}, "start.js");
Erklärung:
ExecuteOrDelayUntilScriptLoaded ersetzt den $(document).ready Event und wird einmalig aufgerufen. Falls MDS aktiviert ist (asyncDeltaManager vorhanden), wird initUpdatePdfLinksTarget bei jedem end-Request ausgeführt, also immer wenn die Content Area geändert hat. Letzteres führt dann updatePdfLinksTarget aus und registriert diese Funktion beim Client Side Rendering, also wenn sortiert, gefiltert oder die Seite gewechselt wurde.
Die Problematik mit jQuery(document).ready in SharePoint ist u.a. hier beschrieben: https://spcafcontrib.codeplex.com/wikipage?title=AvoidJQueryDocumentReady
Alternativer Workaround
Wer ganz auf Code verzichten will, kann auch die Anwender einfach schulen, PDFs in „in neuem Tab“ zu öffnen per Kontext-Menü oder Control & Click.
PDF in neuem Tab öffnen per Kontext-Menü
2sicgeeks 