Beiträge von mensmaximus

    Na dann war meine Vermutung ja ein Volltreffer. Es tut mir leid aber Du bist gehackt worden. Möglicherweise setzt Du Mailpoet ein (sieht zumindest so aus). Deine Installation war viel zu alt und hat Sicherheitslücken. Jetzt hilft nur noch ein Restore aus einem sauberen Backup. Falls es das nicht gibt, musst Du neu installieren oder einen Profi beauftragen der alle PHP Seiten bereinigt (bei einigen Leuten sind das mal schnell 2000 Seiten, je nach Umfang der Installation). Die Datenbank kann man retten, dort sind im Regelfall nur zwei Tabellen "befallen".

    Eventuell muss es

    [COLOR=#333333]wp_blogs (blog_id 1 / site_id 1)[/COLOR]
    [COLOR=#333333]domain = einwunderbarername.org[/COLOR]
    [COLOR=#333333]path = /wordpress/[/COLOR]

    [COLOR=#333333]wp_site (id 1)[/COLOR]
    [COLOR=#333333]domain = einwunderbarername.org[/COLOR]
    [COLOR=#333333]path = /wordpress/

    heißen, also mit abschließendem Slash. Bin mir da nicht mehr sicher, da ich die letzte Installation in ein Unterverzeichnis vor gefühlten 500 Jahren gemacht habe. Ich arbeite immer im Root Verzeichnis.[/COLOR]

    Ich sage es mal so: Wenn Du PHP beherrschst und viel Zeit hast, kannst Du es in Twenty Ten fixen. Alternativ kannst Du auch (relativ) viel Geld in die Hand nehmen und es umschreiben lassen. Dann hast Du aber immer noch ein altes Theme, was bei nächster Gelegenheit wieder Ärger macht und viele der neuen Funktionen gar nicht unterstütz.

    Steige auf die aktuellste Version Twenty Fourteen um. Erstelle ein Child Theme und ändere das Design nach Deinen Wünschen. Dann hast Du zumindest bis 2018 Ruhe ;-)

    [COLOR=#333333]In Deiner wp-config.php nur

    define('DOMAIN_CURRENT_SITE', 'einwunderbarername.org/wordpress');
    [/COLOR][COLOR=#333333]define('PATH_CURRENT_SITE', '/');[/COLOR][COLOR=#333333]

    durch

    [/COLOR][COLOR=#333333]define('DOMAIN_CURRENT_SITE', $_SERVER['HTTP_HOST']);
    [/COLOR][COLOR=#333333]define('PATH_CURRENT_SITE', '/wordpress/');[/COLOR][COLOR=#333333]

    ersetzen. Der Rest ist ok.


    Wenn Du 100000000000% sicher bist, dass Du alle Datenbankeinträge korrigiert hast, kannst Du den Schritt natürlich überspringen.
    Würdest Du das Leben der CPU Deines PC darauf verwetten? Freiwillig ein Betriebssystem mit Cobol programmieren? Nein? Dann noch einmal durch alle Datenbankfelder gehen.

    Im folgenden gilt die Annahmen, das der Tabellen Prefix wp_ heißt, die Domain [/COLOR]einwunderbarername.org (nicht http://www.einwunderbarername.org), Deine Seite nicht SSL verschlüsselt ist und deswegen mit http://einwunderbarername.org aufgerufen wird (und nicht mit https://). Abweichungen von dieser Annahme sind entsprechend zu berücksichtigen.

    wp_options
    siteurl = http://einwunderbarername.org
    blogname = einwunderbarername.org
    home = http://einwunderbarername.org


    wp_blogs (blog_id 1 / site_id 1)
    domain = einwunderbarername.org
    path = /wordpress


    wp_site (id 1)
    domain = einwunderbarername.org
    path = /wordpress


    wp_sitemeta
    siteurl = http://einwunderbarername.org/

    Wenn es dann noch immer nicht geht muss ich doch mal in eine meiner Datenbanken schauen ;-)
    [COLOR=#333333]

    [/COLOR]

    Es gibt zwar kein offizielles EOL Datum aber die Probleme mit Twenty Ten häufen sich. Das letzte Update war im August 2013, was darauf schließen lässt, dass die Entwicklung einschläft. Ein Umstieg auf die neueren Varianten ist ratsam und nicht besonders kompliziert.

    Bei all-inkl.com solltest Du PHP auf Fast-CGI umstellen. Füge dazu in Deine .htaccess Datei folgende Zeile ein "AddHandler php5-cgi .php" (ohne Anführungsstriche).

    Wie schon von anderen erwähnt sind 777 Rechte niemals zu vergeben (isoliert auf einem Development Server zum debuggen ja - sonst nie). Verzeichnisse bekommen 755, Dateien 644 (manchmal auch weniger - je nach gewünschtem Hardening)

    Hast Du schon versucht den Plugin Ordner des Meta Sliders zu löschen (dadurch wird das Plugin deaktiviert) und dann die Seite erneut aufzurufen (dann ist zwar der Slider weg aber die Seite geht möglicherweise wieder)? Auf diese Weise kannst Du feststellen ob es am Plugin liegt.

    Weiße Seiten deuten immer auf einen Fehler im Code hin. Das kann viele Ursachen haben, von fehlerhaften Einträgen bis hin zu einer Hackerattacke.

    Du hast nicht zufällig MailPoet installiert und eine alte Version am laufen?

    Im Theme Enfold von Kriesi kannst Du global und pro Seite entscheiden ob Du keine, einen oder zwei Sidebars anzeigen willst.

    Die Zeilenabstände definierst Du mittels CSS. Zu diesem Zweck legst Du entweder ein Child-Theme an und bearbeitest dort die CSS Datei oder Du fügst Custom CSS im Theme ein wenn es diese Einstellung bietet (Enfold kann auch das). Eine zweite Alternative ist die Verwendung eines CSS Plugins für WordPress.

    Ein Klassiker ;-) Für die Reparatur brauchst Du einen Texteditor, einen FTP/SSH Zugang und Zugriff auf die MySQL Datenbank (phpMyAdmin bei deinem Hoster z.B).

    Im folgenden gehe ich davon aus, dass es sich wirklich um eine Multisite (ein Netzwerk) Installation handelt. In der wp-config steht also "define('MULTISITE', true);". Ist das nicht der Fall muss die Anleitung anders aussehen.

    1. Die Datei wp-config.php vom Server holen (FTP/SCP) oder per SSH auf den Server gehen und die Datei direkt mit einem Editor (z.B. vi) bearbeiten. Folgende Zeilen einfügen und eventuell vorhandene, defines auskommentieren:

    // define('DOMAIN_CURRENT_SITE', '[COLOR=#333333]192.168.1.160[/COLOR]');
    define('DOMAIN_CURRENT_SITE', $_SERVER['HTTP_HOST']);
    define('PATH_CURRENT_SITE', '/');
    define('SITE_ID_CURRENT_SITE', 1);
    define('BLOG_ID_CURRENT_SITE', 1);

    Die Datei speichern und wieder auf den Server laden. In der Datei gibt es auch einen Eintrag für den Tabellen Prefix, z.B. $table_prefix = 'wp_';. Diesen Prefix bitte merken.

    2. Über die MySQL Verwaltung Deines Providers (oder über die Shell per SSH) öffnest Du die Tabelle "prefix_von_oben"options. In obigem Beispiel also wp_options. Jetzt müssen drei Einträge geändert werden und zwar jeweils der option_value Eintrag für option_name "siteurl", "blogname" und "home". Ändere die Werte von "192.168.1.160" auf die neuen Werte (also den Domainnamen und die URL). Wenn das erledigt ist öffnest Du die Tabelle "prefix_von_oben"site. In obigem Beispiel also wp_site. Änder dort die Domain und Pfad (path) auf die neuen Werte ab. Jetzt geht es weiter zur Tabelle "prefix_von_oben"sitemeta (das mit dem wp_ Beispiel spare ich mir ab jetzt). Dort muss der meta_value für den meta_key "siteurl" der site_id "1" auf die neue URL eingestellt werden. Zuletzt noch in der Tabelle "prefix_von_oben"blogs für die blog_id "1", der site_id "1" die aktuellen Werte (domain, path) anpassen.

    Wenn ich jetzt aus dem Gedächtnis keine Tabelle vergessen habe bist Du auch schon durch und Deine Multisite Installation kann wieder aufgerufen werden.

    Vor wenigen Tagen wollte ein User wissen wie er eine bestimmte Anzahl von Benutzernamen und Nicks mittels eine Shortcodes ausgeben kann. Folgende Funktion habe ich vorgeschlagen.

    Wenn man nun in einem Post oder auf einer Page den Shortcode [fwwuq number='5'] einbindet erhält man die Liste der fünf zuletzt angelegten Benutzer in Form von "Anzeigename : Nickname".

    Dieser Ansatz sollte auch bei Dir greifen und die Funktion muss nur entsprechend dem tatsächlichen Bedarf angepasst werden.

    Das Konzept:

    Einen Shortcode definieren, der JS, CSS und Tabelle einbindet. Der Shortcode kann dann auf jeder beliebigen Seite eingebunden werden. Über Shortcode Attribute lassen sich unterschiedliche Tabellen darstellen.

    Die Umsetzung:

    Am einfachsten ein Plugin schreiben, welches die notwendigen Funktionen bereitstellt. Alternativ eine einzige Funktion in der funktions.php.

    Die Schlüsseltechniken:

    - add_shortcode( 'my_table', 'my_table_function' )
    - wp_register_script
    - wp_localize_script (falls Variablen an JS übergeben werden sollen)
    - wp_enqueue_script

    Das Resultat:

    Nur auf den Seiten, auf denen der Shortcode eingebunden wird, werden JS und CSS eingebunden und eine Tabelle angezeigt.

    Die globale Variable muss natürlich den User enthalten, da sie ja global gültig ist. Das habe ich im obigen Code nicht berücksichtigt.

    Definition:
    $my_currency = array([COLOR=#333333]$user->user_login => "EUR");

    Verwendung
    $GLOBALS['my_currency'][[/COLOR][COLOR=#333333]$user->user_login[/COLOR][COLOR=#333333]]

    Neben den Fragen in meinem vorherigen Post, muss natürlich auch Raum für die Diskussion um globale Variablen existieren.

    Wie schon angedeutet würde ich die Sache anders lösen.[/COLOR]

    Einfach eine globale Variable in Abhängigkeit vom User definieren:

    Mit $GLOBALS['my_currency'] kann man nun auf die Währung zugreifen. Wenn die Währung in den Javascripten benötigt wird, geht das via wp_localize_script:

    wp_register_script( 'my_script', 'path/to/myscript.js' );
    $scriptdata = array( 'currency' => $GLOBALS['my_currency'] );
    wp_localize_script( 'my_script', 'my_var', $scriptdata );
    wp_enqueue_script( 'my_script' );

    Im Javascript code kann man nun mit my_var.currency die Währung abrufen.

    Allerdings frage ich mich warum man das Ganze mit einem Shortcode lösen will. Warum erstellt man nicht ein custom user field und schreibt die Währung für den Benutzer ins Profil? Dort könnte man auch Rabatte und sonstiges speichern und die Berechnung in eine Funktion auslagern. Die Ergebnisse dann per Ajax einblenden. Dadurch würde man die teilweise abenteuerliche Berechnung auch nicht im Quelltext preisgeben.

    Und warum wird jQuery in dem Script eingebunden? Das ist bereits in WP enthalten und wird richtigerweise mittels wp_enqueue_script eingebunden. Bei solchen Aktionen ist das nächste Kompatibilitätsproblem fast vorprogrammiert.

    So viele Fragen aber möglicherweise habe ich die Anwendung doch nicht ganz verstanden.

    Die IF Abfrage macht ja auch keinen Unterschied zwischen den beiden Benutzern.

    Die Funktion ist ungeprüft und soll nur das Konzept verdeutlichen.