Schau mal hier, Beitrag #6.
http://forum.wpde.org/installation/1…alisierung.html
Gruß
helix
Um schreiben oder kommentieren zu können, benötigen Sie ein Benutzerkonto.
Sie haben schon ein Benutzerkonto? Melden Sie sich hier an.
Jetzt anmeldenHier können Sie ein neues Benutzerkonto erstellen.
Neues Benutzerkonto erstellenSchau mal hier, Beitrag #6.
http://forum.wpde.org/installation/1…alisierung.html
Gruß
helix
Mach mal bitte den Test, dass du dein Browserfenster kleiner schiebst. Dann siehst du, woran es eigentlich hängt, und dass da noch mehr im Argen liegt.
Also: siehst du, wenn du ausreichende CSS-Kenntnisse hast.
Wenn du die nicht hast, stellt sich die Frage, wie du es hinbekommen willst – kommt dann in den Bereich, der den Rahmen der Forenhilfe übersteigt. Bzw. es stellt sich die Frage, wer das „verbastelt“ hat?
Gruß
helix
Ehconeo: unsere Likes gehen nicht gegen dich.
Ich musste nur herzlich über Edis Antwort lachen.
Wenn du mehr / genauere Unterstützung brauchst, wäre angemessen, dass du uns erklärst, warum du es für nötig hältst, die Browser-History in der von dir beschriebenen Art zu manipulieren.
Gruß
helix
Ich gebe deine Eingangsfrage mal zurück: Topteaserbox – woooo?
Ich sehe da die neuesten Beiträge. Aber nicht die von dir beschriebenen Texte.
Gruß
helix
Mal per FTP das PlugIn Custom Taxonomy Sort deaktivieren. (Download auf eigenen Rechner und dann aus dem PlugIn-Verzeichnis löschen. Oder den Ordner im PlugIn-Verzeichnis einfach umbenennen.)
Gruß
helix
Das Suchstichwort heißt „History API“.
Stellt sich nur die Frage, warum du die Besucher deiner Seite bevormunden willst.
Gruß
helix
Hm, eigentlich ist es ja kniffliger, vorhandene Einträge in der Datenbank zu überschreiben … an der Stelle hätte / sollte es kein Problem geben sollen.
WordPress neu: Bei dir ging es ja darum, zur vorigen Version zurückzukehren.
Also muss das Backup von vor dem missglückten WP-Update sein. Und das neu auf den Server aufgespielte WordPress muss auch die vorige Version sein. Oder das aus dem Backup.
Ich gehe ja eigentlich davon aus, dass du das alles richtig gemacht hast – aber weil der Teufel ein Eichhörnchen ist (und wo Menschen arbeiten, Fehler passieren ) …
Gruß
helix
Kann man aus eigener Sicherung Seiten importieren, oder muss ich die alle neu machen?
Sollte man normalerweise können.
Aber normalerweise sollte man auch aus dem Backup die ursprüngliche Installation wiederherstellen können …
… Also: was ist schon normal?
Ich denke: ja gut, probier dein Glück (ganz sachlich – das klingt so schnell ironisch).
Aber bitte, tu mir einen Gefallen: Räume jetzt dein vorhandenes BackUp, alles was du dazu hast, schön ordentlich in einen Ordner, den du so beschriftest, dass du auch in zehn Jahren noch wissen kannst, was gemeint war – mindestens unbedingt mit Datum dabei! – und arbeite alles, was du da jetzt ausprobierst, konsequent nur mit Kopien.
Gruß
helix
Soweit ich das sehe, ist das ein Bezahl-Theme. Da halte ich für sinnvoller, wenn du dich an den Theme-Support wendest.
Gruß
helix
Ja, ein weiterer Versuch ergibt Sinn.
Was steht denn in deiner Datenbankdatei jeweils am Anfang einer Tabelle. Bei mir – „mit drop table“ abgespeichert – steht da jeweils: „DROP TABLE IF EXISTS `eigenesprefix_postmeta`“
Tatsächlich steht da „DROP TABLE IF EXISTS `wp_eigenesprefixpostmeta`“ – das macht vielleicht einen möglichen Fehler deutlich: ich hatte damals beim Anlegen in meiner wp-config.php als Präfix „wp_eigenesprefix“ eingetragen. Ohne nachfolgenden Unterstrich. Entsprechend steht es auch ohne nachfolgenden Unterstrich in der Datenbank.
Also bitte auf genaue Übereinstimmung der Schreibweise achten. WordPress fügt so einen Unterstrich (der üblich ist, die Vorgabe mit dem Präfix wp_ ist ja auch mit Unterstrich) nicht selbständig ein.
Gruß
helix
Hast du denn jetzt mal die Permalinkstruktur neu abgespeichert? (Egal, ob zuerst auf Standard gestellt und gespeichert oder direkt die eigene Menüstruktur einfach nochmal gespeichert.)
Hatte das „Problem“ wirklich genau erst gestern: Klon einer Seite auf eine Subdomain, die Pfade waren in der Datenbank alle korrekt geändert, trotzdem habe ich bei meinen Menülinks eine 404-Meldung bekommen. Testweise Permalinks neu gespeichert. Dann ging alles.
Wieweit das dann auch auf die Bildpfade in der Mediathek Einfluss hat, weiß ich nicht. Aber deine Pfade müssten ja eigentlich alle stimmen.
Ich denk nur einfach: Erst die einfachen Dinge probieren. Mit größerem Aufwand kann man danach, wenn das nicht geholfen hat, immer noch drangehen.
Gruß
helix
Doch, das ist logisch, wenn dein individuelles Präfix im Datenbankbackup gar nicht auftaucht …
Guck erstmal, dass mit Präfix wp_ alles da ist und alles funzt.
Und dann kannst du, wenn du Zeit und Nerven hast, nochmal gucken, wie und dass du dein Präfix wieder in ein individuelles Präfix änderst.
Und die Datenbanktabellen mit deinem eigenen Präfix hat dir deine WordPress-Neuinstallation geschrieben – mit dem smarten Default-Inhalt … – nicht aus der sql-Datei gezogen.
Gruß
helix
Nochmal ausführlicher erklärt:
* Du spielst dein Datenbankbackup ein. Da tauchen die Tabellen mit deinem individuellen Präfix gar nicht auf, sondern nur die mit Präfix wp_
* In deiner wp-config.php steht dein individuelles Präfix
* WordPress findet in der Datenbank keine Tabellen mit deinem individuellen Präfix. Also „denkt“ sich WordPress: „Aha, Neuinstallation!“ – Gesagt, getan … mit deinem „neuen“ individuellen Präfix …
Du müsstest dein Datenbankbackup als *.sql-Datei haben.
Mach die mal in einem Editorprogramm auf und sieh nach, ob du da die Tabellen doppelt, d.h. mit unterschiedlichen Präfixen, hast.
Wenn ja, dann hattest du in der vorigen Installation diesbezüglich schon Chaos …
Wenn nein, gilt ziemlich sicher maxes Vermutung.
Und nochmal wenn ja: Dann probier doch mal, dass du in deiner (aktuellen) wp-config.php das andere Datenbankpräfix einträgst (wp_ ?)
Gruß
helix
„Profi“ – grins … vielleicht können wir uns auf so etwas wie „drei Monate mehr Erfahrung“ einigen?
Benzli, was du jetzt beschreibst: Du hast eine Multi-Installation. Da ist das so normal.
Trotzdem, soweit ich weiß – „normalerweise“ – muss man sich auch bei einer Multisite für die einzelnen Unterseiten jeweils extra anmelden, selbst dann, wenn man als Netzwerkadministrator angemeldet ist. Zumindest bei mir war das immer so. Mich hat das extra Anmelden weniger genervt, als dass ich der Sache mal strukturiert nachgegangen wäre …
Und Seiten, die man einmal anlegt, die dann aber für beide Seiten verfügbar sind, ist mit Multisite auch so eine Sache …
---
Heißt: man kann auf einer Datenbank zwei (oder mehrere) WordPress-Seiten / WordPress-Installationen anlegen.
Entweder über eine Multisite-Installation oder Einzelinstallationen mit jeweils unterschiedlichem Datenbankpräfix.
Aber: es sind dann auch getrennte Seiten. In beiden Fällen. An dem Punkt gibt sich das nichts.
Natürlich kann man dann die Menüs in den beiden Seiten so aufbauen, dass man „externe Links“ zur jeweils anderen Seite aufnimmt, so dass es über die Navigation (und gemeinsame Optik) wirkt wie eine einzige Seite.
Alternative könnte sein – aber das habe ich nicht ausprobiert / durchgespielt (also mit Vorbehalt!):
In der Webspace-Verwaltung beide Domains auf den gleichen Ordner routen. Und dann für einzelne Seiten mit entsprechenden Redirects in der htaccess arbeiten.
Gruß
helix
Ich habe das mal in meiner Testumgebung probiert. Bei mir funzt es.
Können wir bitte zuerst die Banalitäten ausschließen?
* Es müssen außer dem Beitragstitel mindestens zwei Zwischenüberschriften vorhanden sein
* Derdiedas Table of Contents wird vor der ersten Zwischenüberschrift eingeblendet
=> das müsstest du eigentlich von den Seiten her kennen (und deswegen wahrscheinlich richtig gemacht haben).
Dann: bei mir gab es eine kleine Irritation. Nicht ganz aufmerksam gewesen beim Testen. Erst dendiedas toc nicht gesehen. Dann mal testweise auch auf einer Seite genügend Zwischenüberschriften eingegeben. Danach habe ich es gesehen.
Jetzt weiß ich nicht, ob das an meiner Unaufmerksamkeit liegt oder ob das eine Besonderheit von toc+ (vulgo: Bug) ist …
Speichere mal testweise eine Seite mit genügend Zwischenüberschriften ein weiteres Mal ab. Danke.
Wenn es dann immer noch nicht da ist: Was verwendest du für ein Theme?
=> Stelle mal testweise auf ein Standard-Theme Twenty-irgendwas um.
Ggf. auch mal alle anderen PlugIns deaktivieren. Wenn es dann tut, der Reihe nach wieder aktivieren, bis es nicht mehr tut …
Gruß
helix
Zu Problem Nr. 1:
Schau, dass du im CSS entweder nur die Sidebar-Widgets ansprichst (normalerweise hat jedes widget eine eigene ID) oder schau, wie du Widgets in der Sidebar ansprechen kannst, also nach dem Schema #id-der-sidebar widget {definition}
Zu Problem Nr. 2:
Das versteh ich nicht. Bitte eine genauere Beschreibung. Oder halt mal den Maintenance-Modus aufheben.
Gruß
helix
Und ich hätte eigentlich keinen Bock auf Rumschrauben am CSS. Aber ich ahnte ja, daß es eines Tages so weit sein würde. Also von mir aus... :grin:
Normale Härte …
Aber schön, dass du es mit Gelassenheit beschreiben kannst.
Und, wer weiß, vielleicht wird es dir sogar ein klein wenig gefallen?
Ich habe sinnigerweise eine Blogkopie und habe die jetzt mal umgebaut auf das gewünschte Design. Wozu hat man Testsysteme? :smile:
Bliebe also die Frage: Wo finde ich das CSS-Geraffel überhaupt und wonach muß ich da eigentlich suchen?
Die Testsysteme hat man natürlich genau für solche Aktionen. Aber bitte mach dein Testsystem ebenfalls auf dem eigenen Server. wordpress.com ist soo anders, da kannst du allenfalls ganz andere Dinge herausfinden …
Normalerweise – also für uns hier im Forum „normal“: in eigenen WordPress-Installationen – verwendet man entweder ein Child-Theme oder ein Custom-CSS-PlugIn.
Bitte versuche, dich in der Richtung ein bisschen schlau zu machen:
* Child-Theme versus Custom-CSS-PlugIn
* Grundlagen von CSS
und frag dann gegebenenfalls nochmal konkreter nach.
Ich hätte die Hauptschriftart gerne einfach etwas größer. Ich sitze defaultmäßig vor einem 24"-Display und denke mir so als Brillenträger: "Nö, das hätte ich gerne größer."
Klar ist das heutzutage nicht mehr so wichtig, wenn das einer mobil abruft, pinched er sowieso. Aber trotzdem und überhaupt.
Das finde ich durchaus den richtigen Ansatz.
Mir geht es als Brillenträger oft ganz ähnlich. Und: ich bin dann auch schnell wieder weg, wenn mich das Thema auch nur ein klitzekleines bisschen weniger interessiert als es anstrengend wird, die Inhalte zu erfassen …
… kann man eigentlich sehr selbstkritisch sehen, aber: es ist so.
Also: um die Schrift generell größer zu machen, musst du finden, wo die Schriftgröße generell definiert ist, meistens (es gibt so Konventionen) ziemlich am Anfang der CSS-Datei bei html oder body.
Aber es sollte halt in der Theme-Editor-Ansicht eine Oberfläche dafür bieten. Also Markieren>Zuweisen>Plugin schreibt irgendwo CSS um. Thema durch.
Wenn es wirklich immer wiederkehrend ist, also z.B. genau der Fall, wenn ein Zitat länger wird, könntest du z.B. eine Klasse .longcite definieren. Und dann in der functions.php des Child-Themes definieren, dass diese Klasse auch im Editor verfügbar ist.
Das ist dann für mittel-Fortgeschrittene.
Fürs erste nur, dass du weißt: da geht schon das eine oder andere.
Gruß
helix
Ja, wahrscheinlich.
Ich bin nicht ganz sicher, aber es kann sein, dass dieser Weg nur dann richtig funktioniert, wenn du deine Bilder konsequent zur jeweiligen Seite hochgeladen hast.
Auch wenn du Bilder ohne Zugehörigkeit zur Seite oder Bilder mit Zugehörigkeit zu einer anderen Seite in einer Galerie ausgeben kannst – WordPress geht eben immer noch davon aus, dass Bilder gezielt zu Seiten oder Beiträgen hochgeladen werden.
Gruß
helix
Da wär ich mal nicht so sicher.
Es ist jetzt gefühlt 1013 Jahre her, dass ich einmal xampp auf einem Rechner hatte. Deswegen weiß ich es a) nicht mehr und b) kann es sich inzwischen verändert haben.
ABER. Es ist nicht selten, dass Anwendungen nur soviel Speicherplatz erhalten, wie am Anfang festgelegt wurde und genau nicht nach Bedarf „mitwachsen“. Darauf deutet deine Fehlermeldung hin. Und deswegen würde ich dieser Frage genau nachgehen, bevor ich ein „daran kann es wohl nicht liegen“ poste. Das Wörtchen „wohl“ ist verräterisch …
Gruß
helix