Beiträge von Putzlowitsch

    Schade:

    ...denn diese Browser sind ja nun doch recht verbreitet ;-)

    Ok, also beim IE 5 und 6 funktioniert es wie oben beschrieben. Das unter Windows-Registry-Eintrag geschrieben als Datei 'meinekennung.reg' speichern und den Eintrag

    "Platform"="Windows NT; MEINEKENNUNG"

    entsprechend anpassen. MEINEKENNUNG ist nur als Platzhalter gedacht. Das sollte aber schon etwas sein, was im normalen Browserstring nicht vorkommt, z.B: 'id43dr' oder so :-)
    Dann die soeben erstellt Datei doppelklicken und die Frage mit 'Ja' beantworten.

    Beim Firfox in der URL-Zeile 'about:config' eintippen. Bei den vielen erscheinenden Optionen nach unten scrollen bis zur Stelle 'general.useragent.extra.firefox', hier dann den selben Kennstring wie oben an den Eintrag anfügen, z.B. 'Firefox/2.0; id43dr'

    Und nun die oben beschrieben .htaccess erstellen bzw das in die vorhandene vor allen anderen Rewrite-Regeln einfügen, für MEINEKENNUNG natürlich wieder id43dr verwenden.

    Die Datei 'baustelle.html' sollte selbstredend auch existieren.

    Anschließend testen und freuen, oder auch nicht. Ich habe es zumindest nicht getan und nur theoretisch runtergeschrieben :-)

    Gruß
    Ingo

    EDIT: Einen Hinweis will ich aber nocht loswerden. Außer auf der eigenen Seite hinterläßt man diese Kennung natürlich auch auf allen anderen Webseiten, die man mit dem so "gepatchten" Browser ansteuert. Prinzipiell kann das also dann jeder andere auch z.B. für ein User-Tracking verwenden.

    Naja, generell könnte das so aussehen:

    Apache Configuration
    RewriteCond  %{HTTP_USER_AGENT}  !.*MEINEKENNUNG.*
    RewriteRule  ^/$                 /baustelle.html  [L]

    Das bedeutet, wenn die Browserkennung nicht meinen individuellen Kennstring enthält, lade die Seite 'baustelle.html'. Ansonsten geht es normal weiter.

    Das Problem ist halt nur, diese Kennung meinem Browser unterzuschieben. Beim IE 5 und IE 6 ging das mit einem Windows-Registry-Eintrag:

    Code
    REGEDIT4
    
    
    [HKEY_CURRENT_USER\SOFTWARE\Microsoft\Windows\CurrentVersion\Internet Settings\5.0\User Agent]
    "Version"=""
    "Compatible"=""
    "Platform"="Windows NT; MEINEKENNUNG"

    Wie es beim IE 7 oder Firefox oder anderen Browsern aussieht, weiß ich nicht. Ich hatte das mal früher benutzt, um eigene Zugriffe aus der Statistik auszufiltern.

    Gruß
    Ingo

    Naja, wenn man an einem individuellen Merkmal, das auch der Server "sieht", erkennen könnte, ob man selber oder jemand anders zugreift, könnte man schon eine Verzweigung über die RewriteEngine einbauen.
    Am einfachsten wäre da natütlich eine feste IP-Adresse, die man nur selber nutzt. Oder irgendwas mit der Browser-Kennung vielleicht.
    Nur als Anregung :-)

    Gruß
    Ingo

    Das Passwort wird bei der Installation zufällig erzeugt und dann angezeigt. Außerdem bekommt man eine E-Mail mit den Zugangsdaten.

    Falls Du das PW vergessen hast und auch die E-Mail nicht mehr hast, müsstest Du es in der Datenbank ändern.

    Bei der Host-Europe SuperSorglosSkriptInstallation ist es etwas anders. Da kann man selbst ein Passwort eben bei dieser Installation festlegen.
    Und falls man es vergessen und auch noch nicht geändert haben sollte, es steht in der wp-config.php im Klartext drin.

    Gruß
    Ingo

    Wenn es Theme-Spezifisch ist, dann mit einer 'functions.php' im Theme-Verzeichnis.
    Da drin kann dann eine Funktionen 'get_linkleiste' stehen, die man dann an beliebiger Stelle in den Theme-Dateien aufrufen kann. Diese gibt dann entsprechend die gewünschte Linkleiste aus.
    Ich hoffe, das stimmt so :-)

    Gruß
    Ingo

    Tut was für die Unterschicht, tragt lange Unterhosen


    Das erinnert mich wieder daran, das ich mir noch eine (besser gleich zwei oder drei) lange Unterhose(n) kaufen will. So mild, wie im Moment, bleibt der Winter bestimmt nicht.

    EDIT:
    Und noch was. Ab wann gibt es denn PostRank 3, ab 100 vielleicht? :-)

    das geht aber auch nicht schneller mit Doppelposts ... weil die werden von uns gelöscht ... ;-)

    Ähmmm, na gut. War ein Versuch. Ich wills auch nicht wieder tun :-)

    Nunja, ich möchte dennoch darauf hinweisen, daß ich es eher als "Technolgie-Demo" verstanden haben möchte. Es funktioniert zwar erstmal mit einer Standardinstallation ganz gut, ich kann aber mangels umfangreicher Tests noch nichts zu Risiken und Nebenwirkungen sagen :neutral:
    Wie reagieren z.B. andere Plugins auf diesen Hack. Wenn die nicht an dem API vorbeiprogrammierts sind, sollte es keine Probleme geben, aber man weiß ja nie.

    Ich kenne mich zwar ganz gut mit PHP und Datenbanken aus, nicht aber mit Wordpress. So erschließt sich mir immer noch nicht ganz, wozu diese Optionen 'siteurl' und 'home' wirklich notwendig sind, bzw. worin sie sich unterscheiden. Falls also an irgendeiner Stelle 'home' abgefragt wird, und home nicht leer ist, greift mein Filte erstmal nicht. Naja, notfalls muß man das einfach noch für 'option_home' zusätzlich registrieren.

    Gruß
    Ingo

    Entschuldigt bitte vielmals, daß ich das Thema noch mal hervorhole, aber irgendwie hat mir die Sache keine Ruhe gelassen:)
    Und so habe ich einfach mal zum Test genau das gemacht, was ich meine, das dabei rauskommen soll (kann natürlich wieder falsch interpretiert sein).
    Was ich jetzt habe ist ein Blog (also eine WP-Installation mit einer Datenbank), das unter zwei unterschiedlichen URLs mit zwei verschiedenen Themes aufrufbar ist. Die Inhalte sind natürlich gleich.

    Aber vermtulich gibt es für genau diesen Fall schon irgendwo fertige Plugins, interessant fand ich es aber schon, wie einfach es möglich ist (dank Filter), so etwas umzusetzen. Hier also das Ergebnis:
    http://ein.gabedaten.de/
    http://aus.gabedaten.de/

    Gruß
    Ingo

    Ich möchte ein Blog unter einer anderen URL noch einmal verfügbar machen.
    Erst mal kein Problem, da kopiere ich die wp-config.php in die zweite Installation - liegt natürlich gleich im Nachbarverzeichnis auf dem gleichen server, sodass der Zugriff auf dieselbe Datenbank möglich ist - und fertig.

    Ich bin eher von zwei WP-Installationen ausgegangen, die auf die selbe DB zugreifen sollen. Wenn es anders gemeint war, vergeßt meine Ausführungen einfach:)

    Gruß
    Ingo

    Dort wirst Du überall absolute URLs sehen, die WordPress aus der (in den Einstellungen festgelegten) Blog-URL generiert.


    Eben, und die in den Einstellungen festgelegte Blog-URL kann, bzw. sollte bei zwei getrennten Bloginstallationen ja durchaus unterschiedlich sein.
    So werden die Pfade zwar absolut, aber immer mit der eingestellten Basis-URL generiert. Genau so funktioniet das ja bei meiner lokalen Installation, die natürlich auch eine lokale Basis-URL verwendet.

    Gruß
    Ingo

    Hmm, naja.

    Ich habe bei mir das selbe Blog draußen und als Kopie noch mal lokal laufen. Um die Daten gleich zu halten, mache ich vom externen System mit mysqladm eine Dump von allen Tabellen (außer wp_options!) und spiele das dann in mein lokales System ein. Funktioniert eigentlich sehr gut. Außer bei guid werden keine absoluten Links gespeichert (wofür sind diese guids eigentlich gedacht?). Man muß natürlich beim Einfügen von Bildern oder internen Links im Artikel darauf achten, nur relative Pfade zu verwenden.

    Gruß
    Ingo

    Vielleicht habe ich ja auch was nicht richtig verstanden, aber warum soll man nicht aus zwei WP-Installation auf die selbe Datenbank (und die selben Tabellen natürlich) zugreifen können.
    Man muß halt nur absolute Links innerhalb der eigenen Seite vermeiden.

    Gruß
    Ingo

    Das wäre ja fast quasi so etwas, wie das, was bei mir kürzlich eher unbeabsichtigt passiert war:
    http://forum.wordpress-deutschland.org/showthread.php?t=14633
    Nur weiß ich leider auch nicht, wie es dazu kam. Der Effekt trat genau einmal auf, obwohl ich davor und auch später wieder eigene ältere Artikel in neueren verlinkt habe.

    Aber ansich müßte man sowas mit einer Datenbankabfrage erschlagen können, indem man bei einem Artikel genau die Artikel raussucht, die auf den Artikel selber verweisen. Sinngemäß etwas wie:

    SQL
    SELECT guid FROM wp_posts WHERE post_content LIKE '%:self%'

    wobei :self dann die guid des aktuellen Artikels wäre.

    Gruß
    Ingo

    Vielleicht noch ein paar ergänzende Hinweise.

    Bei All-Inkl wird standardmäßig beim Aufruf ohne expliziter Dateiangabe nach folgenden Dateien gesucht: index.html, index.htm oder index.php (in dieser Reihenfolge).

    Vermutlich befindet sich in Deinem Basisverzeichnis noch eine index.html-Datei, so das diese dann als erste aufgerufen wird. Also dürfte es auch reichen, diese zu löschen oder umzubenennen.
    Ungeachtet desse kann es aber nicht schaden, dennoch die gewünschte Reihenfolge der default-Index-Dateien explizit festzulegen. Also z.B.:

    Code
    DirectoryIndex index.php index.html index.htm

    Gruß
    Ingo

    Hab ich nicht ganz verstanden. Bei mir verschiebt sich nicht das Hintergrundbild, sondern der Inhalt davor, also Sidebar und Content, wenn ich das Browserfenster verkleinere oder vergrößere.
    Da das Hintergrundbild unverrückbar "festgenagelt" ist, und damit der Übergang vom helleren zum dunkleren Bereich immer den selben Abstand vom linken Rand hat, sollte auch die "Page" einen festen Abstand dazu haben. Somit bleibt Trennung zwischen Sidebar und Content immer an der richtigen Stelle, egal wie breit das Fenster ist.

    Code
    #page {
        margin: 20px 0 20px 180px;
        padding: 0;
        width: 620px;
        }

    So in etwas (unten beim 2. #page).
    Und im body das "textalign: center" rausnehmen.

    Gruß
    Ingo