Beiträge von b3317133

Neuen Menüpunkt erstellen, im Frontend rechte Maustaste auf den neu erstellten Menüpunkt, "Element untersuchen", da steht er dann beim übergeordneten [FONT=Courier New]<li id="menu-item-XXX[/FONT]

Wahlweise kann man auch eine eigene CSS-Klasse beim Menüpunkt anlegen mit eingeben, das entspr. Feld kann man über "Ansicht anpassen" im Menü-Editor sichtbar machen.

Füge neben "Kontakt" einen entspr. Menüpunkt zu "Trainingszeiten" ein und verwende dann den o.g. CSS-Code mit dem dafür passenden ID bei XXX als Basis für weitere Anpassungen.

Man könnte einen Menüpunkt einfügen und den per CSS entspr. colorieren & verschieben, in etwa so:

#menu-item-XXX {
    float: right;
    background: #f00;
    margin-top: -20px;
    border-radius: 10px;
}

Link zur Seite?

Wie stellst Du denn fest, was wo funktioniert oder nicht?

Aktueller Stand bei beiden Websites:

Die "OK-Meldung" wird gezeigt, bei jedem Klick auf den Link, sie kommt direkt aus dem Link, nicht aus dem Opt-Out Code.

Der Aufruf [FONT=Courier New]gtmOptOut();[/FONT] im Link setzt wie erwartet ein [FONT=Courier New]GTM-optout[/FONT] Cookie und wenn das gesetzt ist, wird bei späteren Aufrufen kein [FONT=Courier New]gat_UA-XXXXXX[/FONT] Cookie mehr erzeugt.

Evtl. hast Du einen Werbeblocker o.ä. für den einen Website laufen und für den anderen nicht, denn wenn z.B. wg. eines Blockers der Tag Manager Code nicht von Google geladen wird, gibt es die Funktion [FONT=Courier New]gtmOptOut()[/FONT] nicht und dann wird wg. des Scriptfehlers (den man als [FONT=Courier New]gtmOptOut() is not defined[/FONT] o.ä. in der Browser Console sehen kann) auch die "OK-Meldung" nicht mehr angezeigt.

Das Tag Manager Opt-Out besteht aus einem Cookie, es entfernt nicht irgendwelchen Code, den man selbst in Theme-Dateien oder über Theme-Optionen oder über Plugins dort eingefügt hat.

Würde generell eine genauere Recherche zum Thema empfehlen, sonst entstehen ähnliche Wechselwirkungen wie die offenbar bisher verwendeten copy&paste "Optimierung" Code-Snippets, die letztlich eher das Gegenteil bewirkt haben...

Die Datei ist beschädigt, ggf. fehlerhaft überschrieben, oder man sieht den Inhalt nicht komplett aufgrund irgendwelcher Steuerzeichen.

Der gepostete Teil steht in einer sauberen Datei erst ab ca. Zeile 970.

Sichere die Datei von Deinem Server für eine spätere Analyse und lade eine neue, saubere Datei aus einem Installations-Archiv hoch.

Résumé: Der Website ist mit ziemlicher Sicherheit gehackt worden und sollte gesamt als kompromitiert betrachtet werden, so geht es weiter, inkl. Aktualisierung oder Ersatz der o.g. Komponente im Theme.

Das Problem bzgl. [FONT=Courier New]add_custom_background[/FONT] ist nicht gelöst, man sieht es nur nicht mehr. Belässt man es so, besteht die Möglichkeit, dass in einer zukünftigen WordPress Versionen die Seite überhaupt nicht mehr funktionieren wird.

Poste doch mal die ersten 10 Zeilen Deiner Datei wp-login.php, könnte auch ein Hack/Trojaner sein. Würde mich ehrlich gesagt nicht wundern, das uralte Theme verwendet eine ebenso uralte timthumb.php Komponente, mehr dazu hier...

Genauer schauen, exakte Zeilennummern siehe oben...

Und der Head-Block ist zweimal vorhanden, Details siehe oben...

Das Links anpassen solltest Du selbst umsetzen können. Die Weiterleitung wäre ähnlich wie im PHP-Code, nur eben in JavaScript.

Um das alles als (wie es offenbar angedacht ist) Seitentemplate für Deine WordPress Installation korrekt umzusetzen, würde sich die Jobbörse hier im Forum empfehlen, auch da es ohne Zugang zum Website sonst ein grosses Ratespiel wird...

Nur ein Beispiel: Wenn Du den Tag Manager z.B. sonst auf dem Website über ein Plugin verwaltest, und es da (gerade im Hinblick auf DSGVO) ein Opt-Out gäbe o.ä., müsste man das im Template entspr. berücksichtigen usw.

Am Rande: Hatte kürzlich einen Fall, wo alle möglichen Änderungen von PHP memory_limit usw. und aller vorhandenen WordPress Konstanten zwar stets in phpinfo() und in entspr. Plugins usw. schön mit den neuen Werten angezeigt wurden, aber jedes PHP-Script in oder ausserhalb von WordPress trotzdem ab einem bestimmten Verbrauch abgebrochen ist.

Lag am Hosting Account, wo auf anderen Wegen ein hartes Límit gesetzt war, erst nach einem höherwertigen Account Upgrade entsprachen dann die angezeigten Werte auch der Realität und siehe da, alles hat funktioniert...

In beiden Websites wird der Google Tag Manager Code zweimal eingefügt, wie man das sieht, siehe hier in #6.

Der offensichtliche HTML-Fehler im zweiten Website besteht nach wie vor, wie man das sieht, siehe hier in #8.

Das Cookie "GTM-optout" wird im ersten Website nach der Abschalten der "Optimierungen" offenbar korrekt gesetzt, siehe ebenfalls #6.

Das verwendete Theme SimplenBright 1.0.5 stammt aus dem Jahr 2012(!) und ist mit der aktuellen WordPress Version nicht mehr uneingeschränkt kompatibel, dass es da nochmal ein Update des Herstellers gibt, scheint unwahrscheinlich, siehe Changelog.

Die Meldung bzgl. [FONT=Courier New]add_custom_background[/FONT] siehst Du höchstwahrscheinlich, weil in [FONT=Courier New]wp-config.php[/FONT] die Konstante [FONT=Courier New]WP_DEBUG[/FONT] auf [FONT=Courier New]true[/FONT] gesetzt wurde.

Der Fehler 500 hat andere Gründe, die man aus der Meldung allerdings nicht ableiten kann.

Und v.a. in die Datei functions.php im Child-Theme Ordner!

Hatte in letzter Zeit einige "habe nichts gemacht und alles ist kaputt" Fälle, wo die Leute irgendwelche copy&paste Code-Schnipsel fälschlicherweise in wp-includes/functions.php eingefügt haben... :confused:

Der Code kann und wird so nicht funktionieren, weder mit noch ohne Tracking.

1. Die Ausgabe von HTML verhindert die korrekte Weiterleitung via [FONT=Courier New]header()[/FONT] in PHP.

2. Die Links bei [FONT=Courier New]$target = 'https://...'[/FONT] müssen natürlich auf die passende App-Seite angepasst werden...

Für eine (extern) trackbare Weiterleitung muss man eine andere Lösung basteln, via JavaScript statt PHP, das hat aber alles mit WordPress eher gar nichts mehr zu tun...

Zitat von Blaser Solutions

Ich habe bereits das Forum nach diversen Möglichkeiten durchsucht aber leider bin ich nicht fündig geworden. Falls also diese Frage bereits gestellt wurde, so tut es mir leid das ich nicht auf die entsprechenden Ergebnisse gestossen bin.

Schau mal z.B. hier bei Google.. allerdings gibt es keinen wirklich vernünftigen Grund, diesen Tag zu entfernen, man wird immer über diverse Wege herausfinden können, welche Version läuft.

Was genau ist im Ordner [plain]http://www.300420182131[/plain]?

Befinden sich die WordPress-Dateien (z.B. wp-config-sample.php) im Webspace direkt im Ordner

[plain]/meineSeite.de/wp-config-sample.php[/plain]

oder ist da ggf. noch ein Ordner dazwischen, z.B.

[plain]/meineSeite.de/wordpress/wp-config-sample.php[/plain]

o.ä.?

Zitat von galoma_patrick

Hat jemand vielleicht eine Idee, die mich weiterbringen könnte und das Problem lösen würde?

.htaccess per FTP löschen, dann in WordPress unter "Einstellungen > Permalinks" einmal ohne Änderungen "Speichern" klicken, dadurch erzeugt WordPress selbst die .htaccess neu.

Wenn es dann damit wieder Fehler gibt, ist es ein Problem ausserhalb von WordPress.

Und: Was steht in der Browser-Konsole wenn die Seite nicht vollständig geladen wird?