Beiträge von mensmaximus

    Das scheint mir dann doch viel zu kompliziert für eine solche kleine Anwendung, erstaunlich, dass es da augenscheinlich keine simplere Lösung gibt!

    Anspruch und Wirklichkeit. Nicht alles was man mit Bleistift und Papier am Tresen im Laden innerhalb 30 Sekunden erledigt ist mal eben zu programmieren. BirchPress kann was Du möchtest, allerdings auch nur in der Pro Version, also das festlegen der Länge eines Services.

    Monika: Klingt auch interessant - aber die Einträge des Kontaktformulars müssten dann ja irgendwie an eine Datenbank übergeben werden bzw. an Variablen, die dann die Kalenderdaten speisen. Oder wie meintest Du das?

    Auch hier hast Du das Problem, dass Du zwar mit Plugins wie Formidable Pro eine Datenbank befüllst, die aber wieder der Zeitfaktor, sprich die Länge des Termins, fehlt. Das sind die Funktionen einer eCommerce Lösung.

    Also zumindest hier im Forum enthält Deine style.css ein nicht darstellbares Zeichen am Anfang das gehört weg. Richtig ist:

    Code
    /*
    Theme Name: Hathor-Child
    Template: hathor
    Description: Child theme made of Hathor Theme by imonthemes.com.
    */

    Und in die functions.php gehört kein abschließender PHP Tag (und auch nur ein öffnender am Anfang, dass nur zur Vollständigkeit). Richtig ist:

    PHP
    <?php    
    add_action( 'wp_enqueue_scripts', 'theme_enqueue_styles' );
    function theme_enqueue_styles() {    
        wp_enqueue_style( 'parent-style', get_template_directory_uri() . '/style.css' );    
        wp_enqueue_style( 'child-style', get_stylesheet_directory_uri() . '/style.css', array('parent-style') );    
    }


    Ich gehe davon aus, dass /hathor tatsächlich so heißt und zusammen mit /hathor-child im /theme Verzeichnis liegt.

    Zunächst muss geklärt sein wie der Hack durchgeführt wurde. Oberster Grundsatz nach einem Hack: Trau keiner Datei! Viele Angreifer verbergen Schadcode als Backdoor in Bildern, d.h. jedes Bild im Upload Verzeichnis kann eine Hintertür in Dein System enthalten. Mit der Übernahme der Dateien besteht also ein Risiko, dass der neue Blog das gleiche Schicksal teilt.

    Aber auch die Datenbank kann Schadcode enthalten, entweder als eigene Einträge in der Meta Tabelle oder als Inline Code in den Beiträgen. Es könnten aber auch zusätzliche Benutzer angelegt worden sein, die in WordPress nicht zu sehen sind.

    Und noch einmal: Es muss geklärt wie der Hack durchgeführt wurde. Welche Sicherheitslücke hat diesen ermöglicht? Welches Plugin war das Einfallstor? Diese Plugin darf nicht mehr verwendet werden bzw. nur, wenn es vom Hersteller einen Fix für die Lücke gibt.

    Daher lautet mein Rat nach einem Hack immer: Beauftrage einen Experten

    Gehen wir also davon aus, dass ein Fachmann die Datenbank als ungefährlich und sauber deklariert. Dann ist der richtige Weg wie folgt:

    1. Datenbankdump ziehen (phpMyAdmin, MySQL-Dumper oder direct auf der Console)
    2. Neues Verzeichnis auf dem Webserver für WordPress erstellen
    3. Die aktuelle WordPress Version neu herunterladen und per FTP auf den Webspace in das neue Verzeichnis kopieren
    4. Alle verwendeten Plugins in der aktuellen Version neu herunterladen und per FTP in das neue WordPress hochladen
    5. Wenn 100% sicher ist, dass das Upload Verzeichnis der alten Installation nicht kompromittiert wurde kann es übernommen werden, falls nicht muss man alle Bilder später neu hochladen und die Beiträge entsprechend anpassen. Oft hilft auch ein Backup das garantiert vor dem Hack gemacht wurde, dann braucht man nur wenige Bilder korrigieren.
    6. Neue Datenbank erstellen und den Dump aus Punkt 1 importieren
    7. Die neue wp-config.php anpassen (Datenbankname, Benutzer, Passwort)
    8. Domain auf das neue Verzeichnis legen
    9. In WP einlogen und sofort die Passwörter ändern
    10. Bilder gemäß Punkt 5 ergänzen oder erneuern, falls nötig

    Das ist ein grober Überblick und der Fachmann wird hierzu noch einige andere Dinge durchführen, wie z.B. die Änderung von Tabellen Prefixen, Anpassungen an der .htaccess und die Installation von zusätzlichen Plugins um z.B. die Anzahl an fehlerhaften Logins zu begrenzen oder die User Slugs zu ändern. Es gibt noch vielen andere Maßnahmen um die Sicherheit zu erhöhen, die ich durchführen würde und solche die ich auf keinen Fall empfehle. Das würde den Rahmen hier aber gewaltig sprengen.

    ich frage mich nur noch was eine IF Abfrage sein soll.

    Dann hat sich mein Ansatz für Dich praktisch erledigt, da ja eine Änderung des Templates notwendig wäre und das bedingt zumindest Basiswissen in PHP und HTML. Die Postformat-Lösung von Monika wäre dann die logische Konsequenz. Das setzt aber Voraus, dass das Theme diese auch in der Blogübersicht nutzt und nicht nur in der Single Ansicht.

    Wie SirEctor schon gesagt hat, ist es ohne einen Link zur Seite nicht mehr möglich zu helfen.

    Es steht zu vermuten, dass die angesprochenen Regeln in anderen CSS Dateien definiert werden, die später geladen werden als die style.css. Oder aber eben Deine Aussage darüber, dass Du die Regeln ja 1:1 übernimmst wieder nicht stimmen kann, weil diese ja gar nicht existieren, wenn auch in der style.css des Parent keine Änderung möglich ist, also erst einmal eine Regel geschrieben werden muss.

    Dann könnte man ein zusätzliches Stylesheet als letztes in der Kaskade laden (z.B. Priorität 9999) um zu sehen wie sich eine Regeländerung dort auswirkt. Möglicherweise handelt es sich aber auch um Regeln die bereits mit !important vom Theme definiert sind und deshalb nur mit !important änderbar sind, wenn man sie vor den anderen Regeln lädt.

    Bei manchen Themes ist die 'neue' Vorgehensweise für Childs über wp_enqueue_scripts anstatt @import aber auch schwierig, weil diese mehrere CSS Dateien laden, was man dann natürlich berücksichtigen müsste.

    Aber all das ist Spekulation und kann nur durch einen Blick in den Quellcode der Seite beantwortet werden. Aus diesem Grund bin ich jetzt solange aus diesem Thread raus, bis man das 'Problem' online nachvollziehen kann.

    Gute Provider für eCommerce Seiten, die Dir bei Bedarf auch managed Service bieten sind:

    https://rackspeed.de/ssd-hosting-startup/
    https://www.mittwald.de/hosting/webhosting

    Beide Anbieter liefern auch deutlich größere Systeme und werden daher auch von großen Shopbetreibern genutzt.

    zu 1.
    Der Provider muss sich mit dem Hosting von Applikationen auskennen und in Deinem Fall über Know-how im Bereich WordPress, Woocommerce und eCommerce im Allgemeinen verfügen. Ein schneller Support und hohe Verfügbarkeiten (Preisfrage) stehen ebenfalls ganz oben auf der Liste.

    zu 2.
    Eine SSL Verschlüsselung ist grundsätzlich anzuraten, bei vielen Payment-Gateways sogar Pflicht und um eine PCI-Compliance zu erreichen eine unumgängliche Notwendigkeit. Das Zertifikat bekommst Du bei Hostinglösungen vom Provider.

    zu 3.
    Kreditkartenzahlungen wirst Du zu 99% über eines der Zahlunsgateways abwickeln. Eigene Verträge mit den Kreditkartenunternehmen sind teuer und werden heute nur noch nach strengen Prüfungen vergeben.

    Das es sich bei diesem Projekt um eine kommerzielle Applikation zu handeln scheint, empfehle ich unbedingt eine Beratung durch den Fachmann (WordPress, Woocommerce, Hosting, Recht).

    Als erstes überträgst Du jetzt eventuelle Customs CSS Regeln aus dem Theme in die style.css des Childs.

    Ok, habe ich gemacht, danke.

    Sorry, da stehe ich jetzt auf dem Schlauch. :( Was genau meinst Du damit?

    Entweder Du liest nicht richtig oder Du antwortest ungenau. Wenn Du bestätigst, dass Du die Regeln aus der Custom CSS das Themes übertragen hast, musst Du doch wissen was ich meine. Das hatten wir doch schon am Anfang mit Deine Änderungen im Theme. Also wenn das Theme eine Custom CSS Option hat, dann übertrage die Regeln in das Child Theme und entferne die Regeln aus der Custom CSS Area. Und ob Dein Theme eine solche hat musst Du wissen, es ist Dein Theme. Und wenn Du es nicht weißt schau nach.

    Als erstes überträgst Du jetzt eventuelle Customs CSS Regeln aus dem Theme in die style.css des Childs.

    Zweitens änderst Du die Funktion engine_custom_enqueue_child_theme_styles() wie folgt:

    Code
    function engine_custom_enqueue_child_theme_styles() {
    	wp_enqueue_style( 'parent-theme-css', get_template_directory_uri() . '/style.css' );
    	wp_enqueue_style( 'child-style', get_stylesheet_directory_uri() . '/style.css', array('parent-theme-css') );
    }

    Genau das ist der Anwendungsfall für ein Childtheme, also das Portieren langsamer CSS Regeln aus eine Datenbank in eine schnelle Datei die vom Webserver verarbeitet wird und nicht von PHP.

    Und jetzt tu mir/uns den Gefallen und führe die 4 Punkte aus, damit wir ans Ziel kommen.