Beiträge von danielgoehr

Konkret zur Weiterleitung:

Ja, technisch wird das schon so funktionieren. Du musst aber aufpassen, wie die Weiterleitung eingerichtet wird und du hast zumindest eine gewisse Gefahr, dass es Probleme mit deinem Ranking geben könnte.

Was spricht denn dagegen, die Umstellung abzuwarten und erst dann die neue Website tatsächlich zu veröffentlichen, wenn die Domain bei 1und1 wirklich "einsatzbereit" ist? Bis dahin hättest du halt noch die alte Website bei United Domains. Das sollte dann natürlich am besten auch zeitnah passieren, aber ansich geht das ja relativ schnell.

Oder (was wahrscheinlich am besten wäre): Du richtest bei 1und1 alles vollständig für die .com Domain ein. So würde die Seite quasi sofort laufen, sobald die .com Domain umgezogen ist. Du müsstest dann nur nochmal kurz testen, ob tatsächlich alles läuft.

Btw: Ich kenne das bei .com Domains tatsächlich auch, dass es bis zu einer Woche dauern kann.

Schau mal in den Entwicklertools (Taste F12) im Tab "Netzwerk". Da kannst du genau sehen, was der Browser wann lädt.

Da sollte dann auch zu sehen sein, ob er das Pixel sofort lädt oder erst später.

Zitat von schnittchen

und vor allem ist es aufgrund unserer Aufbewahrungspflicht von 10 Jahren in Deutschland überhaupt "erlaubt" dies zu tun?

Letzendlich musst du diese Frage deinem Steuerberater und/oder deinem Anwalt stellen. Das werden wir dir nicht wirklich verlässlich beantworten können. Meiner Meinung nach fällt dies nicht unter die genannte Aufbewahrungspflicht. Die entsprechenden Rechnungen, Listen der Bestellungen, Jahresanschlüsse, etc. natürlich schon. Aber die hast du ja sicher auch noch auf anderem Weg gespeichert (oder ausgedruckt und abgeheftet).

Zitat von schnittchen

[INDENT]Wir empfehlen Ihnen dennoch, eine Sicherungskopie der Datenbank zu erstellen und 50% der alten Einträge zu löschen, um Ihre Website um 50% zu beschleunigen: LIVE Site optimieren - Löschen Sie alte Einträge, die 2-3 Jahre alt sind[/INDENT]

Das es eine Seite 50% schneller macht, wenn man 50% der alten "Einträge" (was soll das überhaupt bedeuten? Produkte? Bestellungen? Posts?) löscht, ist aber eine gewagte These.

Generell müsste man sich das wahrscheinlich anschauen. Jetzt so ganz allgemein eine Aussage dazu zu treffen, finde ich eher schwierig. Zumal wir praktisch keinerlei Informationen über deinen Shop haben.

Ja, es ist auf jeden Fall sinnvoll, die wordpress-eigenen Funktionen zu verwenden. Ich vergesse das zugegebenermaßen manchmal.

Ungefähr so:

function wpde_vg_wort_func( $atts ) {
  
$atts = shortcode_atts( array(
       'pixel_id' => '',
   ), $atts, 'vg_wort' );


$pixel_id = filter_var($atts['pixel_id'], FILTER_SANITIZE_STRING, FILTER_FLAG_STRIP_HIGH);


   return "<img src='http://vg04.met.vgwort.de/na/".$pixel_id."' width='1' height='1' alt='' loading='eager'>";
}
add_shortcode( 'vg_wort', 'wpde_vg_wort_func' );

Dann kannst du den Shortcode so verwenden:

[vg_wort pixel_id="693aeadff6cd24f9cb94366811ea5925d"]

Achtung: Ich habe das jetzt nur schnell runtergeschrieben und nicht getestet. Also bitte vor dem Produktiveinsatz nochmal drüber schauen.

"information_schema" kannst du ignorieren. Dort sind keine für dich interessanten Daten gespeichert. "sqlZahl" sollte deine Datenbank sein. Klick da mal drauf. Dann bekommst du eine Liste mit den Tabellen in dieser Datenbank. Diese Tabellen sollten alle nach dem gleichen Muster anfangen. Das sind dann quasi die vorhandenen Präfixe.

Solche Plugins müssen selbst ein Cookie setzen. Ansonsten würdest du den Cookie-Hinweis auf jeder Seite wieder neu angezeigt bekommen, egal ob du akzeptiert hast oder nicht. Das ist technisch nicht anders möglich. Aber um das gleich dazu zu sagen: Das ist überhaupt kein Problem. Cookies machen nicht grundsätzlich böse Dinge, sondern sind ansich erstmal dafür da, Variablen über mehrere Seitenaufrufe hinweg zu speichern. Das wird leider oft verwechselt. Die allermeisten Cookies sind nicht problematisch und werden auch nicht zu Tracking "missbraucht".

Die meisten Cookie-Plugins geben auch nicht automatisch einfach irgendwelche Scripte oder Einstellungen frei. Sie speichern die Cookie-Akzeptanz in einem Cookie, das du dann abfragen kannst, um z.B. Google Analytics auszugeben, wenn Cookies akzeptiert wurden.

Wenn man das nicht kann oder möchte, gibt es z.B. dieses Plugin, dass das kann:
https://wp-dsgvo-plugin.com/
Allerdings auch nicht für alle Cookies, sondern nur bestimmte, die man dann über das Backend konfigurieren kann.

Leider ist die ganze Thematik nicht so trivial, wie man erstmal denken würde ...

Also der Sinn erschließt sich mir auch nicht ganz, weil ja normalerweise nicht einzelne Seiten plötzlich nicht erreichbar sein können, wenn die Seite ansich läuft.

Aber du könntest z.B. einen Cronjob erstellen, um stündlich per Curl den Statuscode der Seiten zu prüfen. Falls du irgendwo kein 200 zurückbekommst, schickst du dir eine E-Mail mit der Info, welche URL das war. Die zu prüfenden URLs könntest du dir entweder aus der Datenbank "zusammensammeln" oder z.B. die sitemap.xml verwenden. Es kann durchaus sein, dass ich jetzt irgendwas nicht bedacht habe. Aber so als erster grober Ansatz...

Generell gibt auch die entsprechende Seite im Codex einen ganz guten Überblick:
https://wordpress.org/support/article/hardening-wordpress/

Auch wenn man das nicht alles machen muss und auch nicht alles immer wirklich sinnvoll ist. Aber es liefert für den Anfang schon mal einiges an Informationen zu dem Thema.

Zitat von Raphael

@danielgoehr Nein, natürlich nicht. Das ist ja genau was ich sagte: Man muss sich wohl die Projektgröße ansehen.

Ah ok. Ich hatte das jetzt so verstanden, deswegen die Nachfrage. War aber auch wirklich nur Interesse. :)

Zitat von Raphael

Updates: [...] Im Grunde solltest du täglich nachsehen, vor jedem Update ein Backup machen und vorher/ nachher vergleichen.

Zitat von Raphael

Na ja, man muss halt auch schauen, welchen Zweck das WP-Projekt erfüllen soll. Die von mir beschriebenen Anforderungen sind für ein kleineres Projekt gedacht.

Nur aus Interesse: Bei kleineren Projekten machst du tägliche Updates mit vorherigem Backup und anschließender Funktionsprüfung?
Das wird ja schon bei einer überschaubaren Menge an Kunden schnell ein Fulltime-Job (mit entsprechenden Kosten für den Kunden).

Generell Tutorials ist schwer zu sagen. In der Regel suche ich eher nach einer konkreten Problemstellung, insofern habe ich da nicht so den Überblick.

Der Codex ist aber ansich immer ein ganz guter Startpunkt: https://codex.wordpress.org/

Ja, du kannst es auch so machen. Vorausgesetzt, die Datenbank ist leer, sollte er dann auch die Installation starten. Aber warum kompliziert wenn es auch einfach geht? Du kannst einfach die Dateien hochladen und losinstallieren. Wordpress legt die wp-config.php dann automatisch an.

Nebenbei: Das Video ist von 2013. Ich würde dir empfehlen, eine aktuellere Anleitung zu verwenden.

Zitat von bronzeton

Hallo,
okay dann sollte es auch über den Eintrag in der wp-config funktionieren.

Jein. Du musst natürlich bei der Installation ein Prefix vergeben, dass dann mit der wp-config.php übereinstimmt. Einfach nur in der wp-config.php ändern wird zu einenr Fehlermeldung führen.

Zitat von bronzeton

Hallo,
Ich weiß nicht, welche Präfixe bereits verwendet werden (nur das eine CMS ist WP, das zweite ist was anderes.)

Wo kann ich sehen, welche Präfixe vergeben sind? (Bitte genaue Angabe, ich hab null intuitives Verständnis, wie dieser MySQL-Kram funktioniert...)

Dein Hoster wird vermutlich sowas wie phpmyadmin zur Verfügung stellen. Damit kannst du schauen, welche Tabellen in der Datenbank existieren. Falls es das nicht gibt, kannst du auch Adminer verwenden (https://www.adminer.org/de/).

Im Prinzip ist es selbsterklärend. EInfach einloggen und das Tool zeigt dir eine Liste deiner Datenbanken und Tabellen an.

Zitat von bronzeton

Hallo,
Naja, wenn ich das neue Präfix "r34atz1" oder "3xv_2" nenne, wird das wohl noch nicht verwendet werden...

Ja, notfalls geht das natürlich auch. Die Wahrscheinlichkeit ist dann sehr klein, dass es ausgerechnet das schon gab.

Hast du den Umzug jetzt mit Duplicator oder manuell gemacht? Falls letzteres: Hast du die Pfade/URLs angepasst?

Eigentlich sind die doch immer gleich, nur halt mit unterschiedlichen IDs in der URL, oder? In dem Fall würde ein einziger Shortcode mit einem Attribut reichen...

Ganz allgemein:
Wordpress nimmt im visuellen Modus einiges an "Code-Optimierungen" vor. Das kann man mögen, kann aber in der Tag lästig sein. Es entfernt dabei eben auch Attribute und (manche) HTML-Elemente, wenn man zwischen Text- und Visuell-Modus hin- und her wechselt. Einzige Abhilfe ist hier, einfach im Text-Modus zu bleiben, was natürlich auch nicht immer und für jeden eine Lösung ist.

Aus o.g. Gründen gehören meiner Meinung nach Tracking-Codes (oder aber z.B. auch Javascript) generell *nie* in den Content.

Mögliche "saubere" Lösungen wären zum Beispiel (wobei es sicher auch noch weitere gibt):
Erstell dir einen entsprechenden Shortcode für das Tracking-Pixel oder verwende ein Custom Field und gib das Feld im Template (oder über einen Hook, z.B. "the_content") aus.

Zitat von DerGaertner

Hallo ich habe folgendes Problem!
Im Bereich Customizer ist es seit ein paar Stunden nicht mehr möglich das menü zu bearbeiten, hängt sich ständig auf! Liegt das am neuen Update?

Was hast du denn gemacht, bevor der Fehler aufgetreten ist? Was wurde genau aktualisiert?
Welches Update ist für dich neu (das letzte Update Wordpress-Update gab es am 18.06.)?

Zitat von DerGaertner

kann ich zu einer älteren Version zurück? Bitte um Hilfe!

Am einfachsten wäre, einfach ein Backup vom voherigen Stand wiederherzustellen.

Vorher solltest du aber auf jeden Fall ein Backup/Dump der bestehenden Datenbank machen.

Welche Prefixes verwenden den die anderen beiden Installationen? Du solltest natürlich (logischerweise) ein anderes für deine neue WP-Installation verwenden.

Zitat von fhwebdesign

Ich würde aufgrund besserer Performance und anderen Faktoren trotzdem zu PHP 7.3 raten.

Ich würde dir aktuell (so lange dein Wordpress und deine Plugins nicht aktuell sind) eher dazu raten, noch auf 7.1 zu bleiben. Jenachdem, wie alt deine Installation und deine Plugins sind, kann es sein, dass noch nicht alles mit 7.3 kompatibel ist und du dir dadurch dann mehr Probleme schaffst, als du löst.