Beiträge von Ammaletu

Die sind neuerdings scheinbar versteckt, was nicht wirklich sinnvoll ist.Klick oben rechts auf "Screen Options", dann fährt der Bereich aus, in dem Du auswählen kannst, was angezeigt werden soll. Setz das Häkchen bei "Custom Fields" und verstecke die Screen Options dann wieder. Die benutzerdefinierten Felder tauchen dann unter dem Editor auf. WordPress merkt sich diese Einstellung pro Nutzer, sollte Dir die Felder in Zukunft also immer anzeigen.

Links auf # haben in der Regel noch eine JavaScript-Komponente. Wenn die Seite beim Laden einen JavaScript-Fehler geworfen hat, werden solche Links allerdings nicht mehr ausgeführt. Stell doch also erst mal sicher, dass Dein Browser Dir auf der Seite keine JavaScript-Fehler anzeigt (je nach Browser musst Du die Anzeige ggf. erst aktivieren).

Hast Du das Plugin vielleicht von dieser Seite installiert und das ist deren Versuch, einen eigenen Update-Service anzubieten? Ich kenne wpplugins.biz nicht, würde aber von solchen Quellen eher keine Plugins installieren, wenn es nicht unbedingt nötig ist. Um welches Plugin geht es denn?

Schau Dir mal die .htaccess-Datei im Hauptverzeichnis an, würde ich sagen. Das wäre der erste Ort, wo ich nach Umleitungen suchen würde. Davon abgesehen solltest Du wirklich sicher sein, alle Reste des Schädlings gefunden zu haben. Neu aufsetzen ist in der Regel sicherer. Mit einer lokalen Testinstallation ist das auch nicht so nervenaufreibend.

Da fehlt das Menü auf der linken Seite, würde ich sagen. Stell doch erst mal sicher, dass es tatsächlich am Theme liegt, indem Du kurz auf das Standardtheme wechselst und dann noch mal das Dashboard anschaust. Ggf. mal Strg+F5 drücken um Cache-Probleme auszuschließen.

Da schließe ich mich Marcus mal an, bitte höflich bleiben! Und zum eigentlichen Problem: Sowas würde man üblicherweise über den RSS-Feed machen, denke ich, jedenfalls wenn Du da den ganzen Artikel veröffentlichst und nicht nur einen Ausschnitt. Dann kann man in Blog B mit einem geeigneten Plugin regelmäßig den Feed von Blog A prüfen und eventuelle neue Beiträge daraus importieren. Als Quelle kann z.B. auch der Feed einer Kategorie oder eines Tags dienen.

Zitat

Vielen Dank für deine schnelle Hilfe! Deine Tips waren gut. Hab die Einträge in der wp_postmeta erzeugt- aber erst das Abspeichern im Backend hat den Fehler behoben. Wieso ist dies erforderlich bzw welche Veränderung in der DB wird damit erzeugt?

Kann ich Dir aus dem Kopf nicht sagen. Du könntest aber vorher und nachher einen DB-Dump ziehen und vergleichen.

Zitat

nach welcher Systematik wird die meta_id generiert? Scheinbar fortlaufend, aber es werden Zahlen übersprungen.

Kann es sein, dass die IDs über alle Meta-Tabellen gemeinsam sind?

Zitat

Welche Funktion hat die _edit_lock?

Ich nehme an, das setzt WP wenn man die Bearbeiten-Sicht einer Page aufruft. Damit kriegt ein anderer User einen Hinweis, wenn er kurz danach ebenfalls die Bearbeitensicht aufruft. Wird vermutlich gelöscht, wenn eine gewisse Zeit vergangen ist.

Ja, sieht jetzt auch im FF gut aus. Freut mich, dass es nun klappt.

Deine neue Seite hat dann keinerlei Meta-Infos. Allein deswegen ist so eine Änderung an der DB keine gute Idee. Davon abgesehen müsstest Du nun mal nachschauen, was denn wohin umgeleitet wird. Hast Du zudem mal probiert, die Seite im Backend neu abzuspeichern?

Zitat

Weiß wer, was genau da passiert ist? Trotz zu kleiner memory size hat es irgendwie doch funktioniert?

Naja, WP merkt ja erst, dass nicht genug Speicher da ist, wenn dann nicht genug Speicher da ist. Jedenfalls falls das versuchte Heraufsetzen des Speichers nicht schon deutlich schiefgeht. Soweit ich weiß, versucht WP ja, sich selber mehr Speicher zu geben. Falls Dein Hoster aber nun z.B. diesen Befehl einfach ohne Fehlermeldung ignoriert, dann legt WP mit dem Update los und irgendwo mittendrin ist dann der Speicher alle und das Script bricht ab. Und dann hast Du, wenn Du Pech hast, eben gerade ein paar Dateien aktualisiert und einige andere noch nicht. Da hilft dann nur, das Upgrade eben manuell zu machen. Mit den Upgrade-Paketen von WPD ist das ja auch schnell gemacht bei den kleineren Releases.

Zitat

Sollte man bei diesem "Automatischen Upgrade" vorher ebenfalls die PlugIns deaktivieren?

Nehme ich nicht an. Wenn WP meint, das wäre nötig, wird es das schon selber tun.

Das geht nur mit a-Tags, weil diese inline dargestellt werden, denke ich. Es geht auch, wenn Du der Sub-Liste eine Weite gibst. Das geht aber ja leider schlecht, da Du ja nicht weißt, wie groß die einzelnen Menüpunkte sind.

Sorry, bin gerade etwas im Stress und mir fällt kein guter Workaround dafür ein. :-/

Solange Du eine überschaubare Anzahl statischer Seiten hast, ist das ok. Bei vielen Seiten wird es sicher auf die Performance gehen. Begründung siehe z.B. hier: http://sw-guide.de/2009-02/wordpr…ie-performance/

Das Problem mit relativen Links hast Du aber ja schon erfasst. Selbst wenn Du die alle richtig eingibst (was je nach Permalink-Struktur eben nicht mal geht), wären die Links alle tot, wenn Du die Permalink-Struktur mal änderst (also wenn sich dabei die Anzahl der Ebenen in der URL ändert).

Deshalb ist der stressfreie Weg, einfach keine relativen Links zu nutzen. Das hat auch noch den Vorteil, dass die Links im RSS-Feed funktionieren (da sind relative Links generell nicht funktionsfähig).

Und wieso machst Du da jetzt noch einen zweiten Thread auf (http://forum.wordpress-deutschland.org/installation/8…det-werden.html), anstatt lieber mal die Forensuche zu bemühen? Das wurde mehr als einmal schon diskutiert, und die Fehlermeldung führt ziemlich flott zur Lösung.

Bitte mal in diesen Thread schauen:
http://forum.wordpress-deutschland.org/installation/6…date-jetzt.html

Nichts an diesem Code würde den Text löschen, das kann also nicht gehen. Bei den anderen Seiten macht das vermutlich ein externes JavaScript. Probier es so:

<form action="<?php echo home_url( '/' ); ?>" method="get">
        <input id="search" type="text" name="s" value="Suche" onclick="if (this.value == 'Suche') this.value='';" />
        <input type="image" src="<?php bloginfo( 'template_url' ); ?>/images/search.png" alt="Suche" />
</form>

Dann verlinke doch bitte mal einen Beitrag mit einem kaputten Bild. Sonst fällt mir dazu nicht viel ein, fürchte ich. Wenn es mit direktem Hochladen per FTP geht, wird es ja wohl nicht an Verzeichnisrechten liegen und auch nicht an einem falsch konfigurierten DeepLink-Schutz, was ab und an mal vorkommt.

Ich würde mal beim Support Deines Hosters nachfragen, was für Sicherungsmaßnahmen das auslösen könnten und ob man die abschalten/modifizieren kann. Ich denke, der Hinweis auf ein Verzeichnis ist irreführend. Da wird bestimmt Suhosin oder mod_security einen 403 schicken, und das ist eben die Standard-403-Meldung.

Zitat

*Seufz* Eigentlich wollte ich ja von dem Drupal-Gefrickel (inkl. XAMPP und FTP) weg und mal was "Einfaches" machen :smile:

Naja, eine lokale Testinstanz ist ja schnell aufgesetzt und macht sich sowieso immer gut. Du musst ja nicht die DB von draußen reinziehen, denke ich. Es sollte fürs erste reichen, WP zu installieren und die gleichen Plugin zu aktivieren.

Zitat

Was mache ich aber wenn es dort (wie bei dir auch) läuft?

Dann habe ich folgendes Szenario:
XAMPP Drupal: OK
XAMPP WordPress: OK
Web Drupal: OK
Web WordPress: NOK ?!?

Alles anzeigen

Dann liegt es schon mal nicht an WP, würde ich sagen. Es wäre dann schon die Frage, ob da eine Security-Sache im Hintergrund läuft und die sich vielleicht nur bei Drupal anders auswirkt als bei WP. Wie man das für die dann maskieren kann, weiß ich aber auch nicht genau. Wenn Du den genauen begriff kennst, auf den sie anspringt, kann man natürlich probieren, im Quelltext das halbe Wort mit einem leeren Span zu versehen oder so. Quasi so:

EX<span>EC(@state</span>ment)

Wenn das ein Einzelfall ist, reicht das ja vielleicht.

Zitat

Wenn ich in der CSS Klasse ein li.mainnav > a habe (damit das ganze Li und nicht nur der Text im A-Tag) als Link zählt positioniert er mir das Submenü folgendermassen:

li.mainnav > a wirkt aber auf den Link, nicht auf das Listenelement. Ich würde dabei ehrlich gesagt wenn möglich die LIs als unsichtbare Container nutzen und die A-Elemente so formatieren, dass sie wie gewünscht aussehen.

Zitat

Ist das Submenü relativ zum li, werden die restlichen Lis nach hinten verschoben, und zwar nämlich um die Breite des Submenüs (es ist wie mans sieht eine horizontale auflistung, keine vertikale)

Das ist das, was reative Positionierung ausmacht: Man kann damit ein Element verschieben, aber es bleibt der ursprüngliche belegte Platz reserviert. Das brauchst Du also nicht.

Zitat

Positioniere ich es allerdings absolut so ignoriert es die "position" des Li-Tags und setzt sie absolut an den Browserrand.

Hast Du dem Parent-LI-Tag denn dann aber auch "position: relative;" mitgegeben? Die absolute Positionierung richtet sich schließlich immer am nächsten *positionierten* Parent-Element aus oder am Body-Tag. Es müsste also so in etwa aussehen:

ul#mainnav > li {
  position: relative;
}


ul#mainnav li li {
  position: absolute;
}

Zitat

ich will im Grunde nur meine Div Tags anstelle des Li-Tags setzen so dass es auch die richtige Klasse aus dem CSS File bekommt.

Wenn eine Lösung mit li nicht gelingt, wäre zu schauen, ob man das HTML über Filter anpassen kann. Das wäre allemal besser als die ganze Methode zu kopieren. Da finde ich z.B. diese Filter:

Zum Anpassen der CSS-Klassen der Menü-Einträge:
http://adambrown.info/p/wp_hooks/hook/nav_menu_css_class

Zum Anpassen des HTMLs:
http://adambrown.info/p/wp_hooks/hook/wp_nav_menu_args (Mit ein bisschen Glück ist das genau das, was Du suchst!)
http://adambrown.info/p/wp_hooks/hoo…v_menu_start_el