Beiträge von Ammaletu

Genau kann ich Dir das auch nicht sagen. Nur soviel, sei sehr vorsichtig, was Du da tust, dass Du mit sowas keine Sicherheitslücken aufreißt. Davon abgesehen wirst Du Dir das irgendwo abschauen müssen, denke ich. Entweder in WP selbst oder aber in einem Plugin, welches ebenfalls den Login modifiziert. Es müsste z.B. Plugins geben, die WP mit LDAP integrieren, denke ich, die müssten ja das gleiche tun.

Ich bin relativ sicher, dass das ein Rechteproblem ist. Das Plugin darf einige Dateien offenbar nicht lesen und auch Verzeichnisrechte nicht ändern. Teste vor allem mal, ob wenigstens die .htaccess im Backup-Ordner erstellt wurde, sonst könnten Deine Backups aus dem Netz abrufbar sein!

Davon abgesehen hatte ich das Full Backup vor längerer Zeit mal getestet und konnte diese Sicherung nicht wiederherstellen. Da kamen dann nur Fehlermeldungen. Das SQL-Backup klappt aber hervorragend, und den Uploads-Ordner ziehe ich einfach alle paar Monate per FTP runter und lege ihn mir gezippt auf die Platte. Alles andere (WordPress, Themes, Plugins) hat man ja nornmalerweise eh schon lokal gesichert.

Müsste man Lösung zwei nicht mit Positionierung hinbekommen? Ich stell mir das in etwa so vor:

.main {
  position: relative;
  top: 0px;
  padding-bottom: 3em;
}


.footer {
  position: absolute;
  bottom: 0px;
}

Damit müsste der Footer immer am Ende von "main" stehen, wo durch die padding-Angabe auch Platz sein sollte. Ist jetzt nur eine spontane Idee, nicht getestet, aber könnte gehen, denke ich.

Mit welcher WP-Version arbeitest Du? Ich finde eine entsprechende Datei unter wp-admin in meinem 2.3.3, aber nicht mehr in 2.6.1. Falls Du 2.3.3 nutzt, schau mal nach, ob sie noch da ist.

So oder so stimmt da irgendwas nicht. Ggf. solltest Du die WP-Dateien noch mal mit einem anderen FTP-Programm neu hochladen. Bei den Dateiübertragungen kommt es öfter zu Fehlern als man meinen sollte.

Es gibt eigentlich immer zwei 404-Seiten, zumindest in der Standard-Konfiguration: Links, die von WordPress behandelt werden, liefern die WP-404 aus. Andere Links die Standard-404 des Servers. Das scheint bei Dir auch so zu sein.

Der Link hier zeigt die WP-404-Seite:
http://wishu-blog.net/index.php/allgemein/gibtsnicht/

Und der hier die vom Server:
http://wishu-blog.net/gibtsnicht/

Das ist soweit normal, würde ich sagen. Vermutlich könntest Du das per .htaccess so umbiegen, dass immer die WP-404 angezeigt wird, falls Dein Hoster das erlaubt.

Welches Plugin das beste ist, kann ich Dir auch nicht sagen. Es gibt eine ganze Reihe mehr oder weniger gut gepflegter Plugins dieser Sorte. Ich persönlich nutze "Code Autoescape" (http://priyadi.net/archives/2005/…ode-autoescape/). Das klappt ziemlich gut, hat allerdings auch kein Syntax-Highlighting an Bord. Und ich bin noch auf 2.3.3, keine Ahnung, ob das bis 2.6 kompatibel ist.

Je nachdem welches Plugin Du benutzt (Link?), kann es sein, dass es mit dem graphischen Editor (TinyMCE) nicht funktioniert. Wenn man den Editor ausschaltet, greift WP wohl weniger in den eingegebenen Quelltext ein. Dann sollten entsprechende Plugins eigentlich recht zuverlässig funktionieren. Mit Editor kann es sein, dass der Editor da schon per JavaScript Änderungen vornimmt, ehe die PHP-Funktion des Plugins den Code vor dem Umschreiben z.B. der divs zu ps retten kann.

Der verlinkte Bug ist als invalid geschlossen, denke also nicht dass das relevant ist. Ich gebe mal eine andere Vermutung ab: Die Funktion is_front_page() nutzt intern die Query der Seite, um zu bestimmen, ob es die Frontpage ist oder nicht. Wenn Du die Query änderst, machst Du diese Abfrage ggf. unmöglich. Wenn Du z.B. eine statische Seite als Startseite verwendest und deren Query im Seitentemplate änderst, geht vermutlich der is_page-Aufruf innerhalb von is_front_page schief. Ob das bei der dynamischen Startseite auch so passieren kann, bin ich mir gerade nicht sicher. So oder so produziert man ggf. hässliche Nebeneffekte wenn man die Hauptquery der Seite zu was ganz anderem ändert (also z.B. Kategorien statt einer einzelnen Seite auslesen). Nutze einfach gleich WP_Query zum Erstellen einer neuen Query, wie Du es in Deinen Ausschnitten ja auch schon gepostet hast. Ok, soweit meine Vermutung. Keine Gewähr für Richtigkeit, es ist eigentlich schon viel zu spät für solche Probleme.

Also mir fällt auf Anhieb nur das hier auf, was mit ziemlicher Sicherheit falsch ist:

{echo " class=\"autor_kommentar\"";} else {echo " class=\"" . $oddcomment . "\"";} ?>>

Da die Variable ja schon class enthält, wäre also richtiger:

{echo " class=\"autor_kommentar\"";} else {echo " " . $oddcomment;} ?>>

Durch die falsche Schachtelung der Anführungszeichen kommt der IE vermutlich aus dem Tritt. Probier das mal. Falls es das nicht ist, wäre ein Link zur Seite wirklich das beste, weil man doch so ohne den Quelltext zu sehen eigentlich nur raten kann.

Also am Code des Themes an sich sollte WP in keinem Fall etwas ändern. Die Sachen, die man in den Beitragen und statischen Seiten eingibt, werden u.U. verändert. Eigentlich immer werden z.B. die Anführungszeichen ersetzt und diverse andere solche typographischen Sachen. Dabei werden auch Absätze und Umbrüche eingefügt.

Dann gibt es noch die Option "falsch geschachteltes HTML korrigieren". Ich kenne die Details nicht, schalte das bei mir aber vorsichtshalber immer aus. Und wenn dann der Kunde den TinyMCE-Editpr nutzt (graphischer Editor, individuell abzuschalten im Nutzerprofil), dann bastelt der auch noch mal am Code rum. Das war aber IMHO immer schon so und sollte sich mit 2.6 nicht speziell geändert haben. Denke ich. Ich schalte TinyMCE bei mir weitestgehend ab, damit man auch ungestört Code posten und Videocodes eingeben kann.

Falls nichts davon so klingt, als wäre es die Ursache Deiner Probleme, schildere uns doch bitte mal genauer, was ersetzt oder verändert wird. Dann ist das sicher leichter zu sagen, woran es liegt.

Davon abgesehen: Dein Kunde sollte sich bewusst sein, dass er durch die Eingabe falschen HTML-Codes die Seite zerschießen kann. Wenn er mit HTML nicht klar kommt, brauchst Du wohl den graphischen Editor und solltest dem Kunden nahelegen, nichts in der Quellansicht zu ändern. Und dann müssen Deine Styles auch mit dem klarkommen, was der TinyMCE ausspuckt. Wenn es an was bestimmten hakt, kannst Du TinyMCE aber z.B. auch gegen den FCKEditor austauschen (per Plugin).

Du könntest mal probieren, ob die Plugins ein bestimmtes Recht definieren, dass man mit dem Role Manager Plugin auch anderen Rollen zuweisen kann. Nur so eine Idee.

Ok, da war ich für einen Moment weggetreten. Du versuchst ja gar nicht, Deine eigenen Widgets zu schreiben. Ok, mal schauen. wenn Du before_widget nicht überschreibst, vergibt WP auf jeden Fall die IDs, die das Widget für sich registriert hat. Und ja, die sieht man dann später im Quelltext der Seite, dafür sind sie ja da.

Wenn man nach "before_widget" sucht, ist das in der widgets.php eigentlich auch ganz simpel zu finden. Dein Beispiel müsste dann vermutlich so aussehen:

<?php
if ( function_exists('register_sidebar') )
register_sidebar(array(
'before_widget' => '<div class="sidebargradient">
<div class="minimize"></div>
<div class="clear"></div>
                <div  id="%1$s" class="sidebarcon">',
'after_widget' => '
                </div>
            </div>',
'before_title' => '<h2>',
'after_title' => '</h2>',
));
?>

Zumindest vermute ich, dass das genauso gehen müsste. Ausprobieren müsstest Du es aber selber.

WP fügt dann wie gesagt die ID ein, die das Widget dafür vorsieht. Bei einem Text-Widgets auf einer meiner Seiten ist das z.B. "text-157208801", bei meinen eigenen Widgets ist es die eingestellte ID. Gerade bei den mehrfach einfügbaren Widgets wie den Textwidgets wird Dir diese automatisch generierte ID für Stylingzwecke aber nichts nützen. Ggf. ist die dynamische Widgetklasse da sinnvoller. Also ergänzen wir die auch noch mal:

<?php
if ( function_exists('register_sidebar') )
register_sidebar(array(
'before_widget' => '<div class="sidebargradient">
<div class="minimize"></div>
<div class="clear"></div>
                <div  id="%1$s" class="sidebarcon widget %2$s">',
'after_widget' => '
                </div>
            </div>',
'before_title' => '<h2>',
'after_title' => '</h2>',
));
?>

Nur eine kurze Idee: WordPress vergibt für seine eigenen Widgets auch IDs, also muss das ja gehen. Schau mal in die widgets.php in wp-includes, wie das dort gemacht ist.

Ich erhöhe mal Deine Chance auf eine sinnvolle Antwort, indem ich rate NIS =
Network Information Service – Wikipedia
Stimmt das oder ist was anderes gemeint?

Wenn Du mit googlen nach "NIS wordpress" keine Lösung gefunden hast, würde ich nicht darauf wetten, dass das schon mal jemand integriert hat. Aber es müsste Integrationen mit Sachen wie Open ID geben. Ich habe leider nicht wirklich viel Ahnung davon, aber ich denke, das ist vielleicht Deine beste Chance, NIS über eine Art Bridge über so ein Protokoll anzubinden. Auch LDAP könnte es geben. Und schau mal, das hier habe ich gerade noch gefunden, vielleicht hilft das ja auch weiter?!
WordPress and LDAP authentication « Tech Explorer

Also ich sehe im IE7, dass einige Abstände größer sind als im Firefox, aber die grundsätzliche Anordnung scheint zu stimmen. Um den IE6 würde ich mich an Deiner Stelle ehrlich gesagt nicht mehr kümmern, es sei denn es ist eine kommerzielle Webseite.

Prinzipiell werden Deine Probleme an den verschiedenen Boxmodels liegen, denke ich. Wie war das... Im Firefox gilt padding + border width + width = tatsächliche Weite der Box, während im IE der width-Wert immer die tatsächliche Weite der Box ist. Als Lösung kann man dem IE ggf. andere Weiten sagen. Dazu einfach eine style_ie.css erstellen und per Conditional Comments einbinden (Forensuche opder googlen). Das ist relativ sauber und funtkioniert gut. Im IE-Stylesheet kann man dann für den IE andere Angaben notieren und wenn es mal sein muss auch Hacks. Validatoren und andere Browser ignorieren das File ja. Klar, es muss dann nach dem normalen Stylesheet eingebunden werden, damit es dessen Angaben überschreiben kann.

Damit man nicht suchen muss, kaputte Umlaute finden sich z.B. hier:
Hallo Welt!

Wenn man im Browser auf ISO-8859-1 umschaltet, sind die Umlaute korrekt. Ausgeliefert wird die Seite ansonsten korrekt als UTF-8, HTTP-Header stimmt, Meta-Angabe stimmt. Und Du sagst ja, dass die DB auch immer schon UTF-8 war.

Es kann vorkommen, dass Plugins die Umlaute zerstören, wenn sie z.B. PHP-Funktionen benutzen, die UTF-8 nicht unterstützen. Wenn es daran liegt, müsste das Problem verschwinden, wenn Du alle Plugins ausschaltest und auf das Standard-Theme umschaltest.

Andererseits gehen dabei normalerweise die Umlaute komplett kaputt, während hier ja nur irgendwas die Umlaute in der falschen Codierung ausgibt. Da wird im Theme aber nicht etwa eine komplett eigene Query unter Umgehung der WP-Dateien aufgemacht oder? Ansonsten würde ich an Deiner Stelle nochmal sicherstellen, dass die Datenbank tatsächlich UTF-8 benutzt. Welche MySQL-Version ist es eigentlich?

Und nur zur Info, ich finde es wesentlich leichter, die Adresse im Datenbank-Dump zu ändern, bevor man den am Ziel wieder importiert. Das geht per Suchen&Ersetzen sehr schön, aber man muss natürlich wissen, was man tut, damit man den Dump dabei nicht beschädigt.

Die .htaccess erstellt WordPress in aller Regel selber. Wenn das nicht geht wegen Dateirechten, sagt WP eigentlich Bescheid, dann kopiert man den Code eben manuell in die Datei.

Falls es dann trotzdem nicht geht, bringt der Server eventuell die Voraussetzungen für die Permalinks nicht mit. Wenn ihr euch da nicht sicher seid, solltet ihr beim Support eures Hosters mal anfragen. Nötig sind:
- das Apache-Modul "mod_rewrite"
- für das WP-Verzeichnis muss die FollowSymLinks-Option eingeschaltet sein
- die AllowOverride-Option muss FileInfo beinhalten (z.B. AllowOverride FileInfo oder AllowOverride All)

Siehe die ausführliche Doku:
Using Permalinks « WordPress Codex

Wenn das bei euch nicht geht, gibt es noch die Permalinks mit "index.php" in der URL, die müssten auch ohne mod_rewrite funktionieren (z.B.
/index.php/%year%/%monthnum%/%day%/%postname%/).

Also ich sehe den Inhalt bei mir problemlos, jedenfalls im Firefox 2. Im IE7 dagegen fehlt der Inhalt. Ok, mal sehen... Die Seite validiert nicht, das ist schon mal nicht schön:
[Invalid] Markup Validation of http://3th.be/2007/01/fruehstuecken-in-wien/ - W3C Markup Validator

Und jetzt wird's merkwürdig: Wenn ich die Seite mit dem IE aufrufe ist der Inhalt des Beitrags tatsächlich nicht im Quelltext. Da stehen nur diese Kommentare, zwischen denen im Firefox der Text steht:

<!-- google_ad_section_start -->


<!-- google_ad_section_end -->

Ich würde an Deiner Stelle also mal schauen, welches Plugin das dort reinschreibt. Das hat dann wohl einen Bug und zusätzlich eine Browsererkennung, warum auch immer.

P.S.: Ok, zu lange zum Schreiben gebraucht. Yep, jetzt geht's bei mir auch im IE7.

Sorry, ich habe noch nie ein Forum installiert, schon gar nicht in WordPress. Allerdings ist bbPress von den WordPress-Entwicklern, also würde ich erwarten, dass man dieses Forum noch am ehesten in WordPress integrieren kann. Infos dazu finden sich z.B. hier: bbPress » Integration with WordPress

Ich glaube, dort geht es aber mehr darum, die WP-User in bbPress nutzen zu können etc. Zur direkten Integration könntest Du mal in deren Forum schauen, z.B. Topics wie dieses hier:
how to include wordpress sidebar.php file in forums « bbPress support forums

Das heißt allerdings (wenn ich's richtig verstanden habe), dass bei jedem Forumsaufruf auch das ganze WordPress geladen wird, was auf die Ressourcen geht. Keine Ahnung, ob man da mit Caching viel machen kann. Wenn Du die Teile des Layouts, die in beiden Seiten zu sehen sein sollen, nicht wöchentlich änderst, könntest Du natürlich auch einfach ein bbPress-Theme erstellen, das genauso aussieht und die entsprechenden Links einfach statisch enthält. Müsstest Du halt anpassen, wenn z.B. eine neue Seite in der Hauptnavigation dazukommt, und Du könntest nicht z.B. die x neuesten Blog-Posts anzeigen. Dafür sparst Du Dir einiges an Arbeit mit der Integration. Naja, kommt am Ende drauf an, was Du genau brauchst.