Beiträge von Arne Drews

    Ich kann Ihnen helfen. Ich selbst habe lange danach gesucht, wie man einen Online-Shop erstellt. Dann hat mir ein Freund eine hervorragende Seite empfohlen, mit der Sie problemlos einen Webshop erstellen können SUPR . Es gibt viele verschiedene Designs, die Sie selbst auswählen können. Erfolge.

    Warum sollte man sich für einen Shop entscheiden, der nicht mehr kann, wie ein Shopware, Magento oder OXID und dazu noch ohne freie CE daher kommt?!

    Auf der Seite wird auch offiziell gelogen: Unter den Funktionen steht bei der Basic Variante unbegrenzte Produkte, in der Preisübersicht enthält das Basic-Paket allerdings nur 25 Produkte?!

    Ich habe den Shop nicht getestet, aber meine persönliche Empfehlung, falls ein Shop suchender hier vorbei kommt: Finger weg von SUPR!

    Selbst OpenCart und Presta sind mind. genau so gut aufgestellt.

    In der appContent.js, Zeile 54 wird versucht, auf eine Eigenschaft eines Objektes zuzugreifen, das nicht existiert.

    Vermutlich ist das Objekt fehlerhaft oder nicht instantiiert.

    Beispiel:

    JavaScript
    var _oObject;    // _oObject is undefined
    console.log(_oObject.query );    // cannot read property 'query' of undefined
    
    
    var _oObject = {
        query : 'i am the query property value'
    }
    console.log(_oObject.query ); // i am the query property value

    Ich werfe mal zusätzlich die Frage in den Raum, aus welcher Quelle die Daten kommen. Vom Aufbau her ist das weit entfernt von einem sinnvollem Konstrukt.

    Wären die Namen tatsächlich ein Schlüssel wie bei JSON, müsste man über das Objekt iterieren, um an den Key und das Value zu kommen.

    Sinnvoll in Form von JSON wäre es bspw. so

    So iterierst Du über das Array data, weißt aber, dass Du in jedem Objektelement die Schlüssel name und value hast.

    Getestet:

    JavaScript
    var dataset = '{"data":[{"name":"Peter","value":0.998},{"name":"Uwe","value":0.872541254},{"name":"Beate","value":0.72},{"name":"Maria-Diana","value":0.854745}]}';
    
    (JSON.parse(dataset)).data.forEach( i => {
        console.log( i.name + ' has a value of ' + i.value.toString() );
    });
    Code: Ausgabe
    Peter has a value of 0.998
    Uwe has a value of 0.872541254
    Beate has a value of 0.72
    Maria-Diana has a value of 0.854745

    Javascript benötigt man für die Anforderung nicht, aber um CSS kommst Du nicht rum. Allein das Spalten-Layout ist relativ simpel damit umsetzbar.

    Das Flexmodell wäre aber natürlich die noch bessere Variante.

    Grundsätzlich kannst Du Dich meiner Meinung nach davon verabschieden, vernünftige Websites nur mit HTML umzusetzen. CSS wird Dein ständiger Begleiter sein, das solltest Du Dir anschauen. JavaScript kommt dann als Kosmetik, liegt aber in Deiner Entscheidung.

    Warum in einer Tabelle?

    Grundsätzlich sollte das klappen, wenn man das Bild in einem Container hat und das Bild auf width:100%; setzt. Ggfl. noch max-width setzen, damit es nicht zu groß gezoomt wird. In einer Tabelle habe ich das allerdings noch nie probiert, daher musst Du das mal selber testen oder Dich von der Tabelle trennen.

    JavaScript würde ich hier nicht als Grundlage nehmen. Das ist eine Art Grundfunktionalität, die sollte auch gewährleistet sein, wenn bspw. irgendwelche ScriptBlocker ihren Auftrag zu ernst nehmen.

    Session ist eine gute Entscheidung, aber wenn Du gar nicht weißt, wie die funktionieren, kannst Du auch bei URL-Parametern bleiben.

    Übergebe an die foto.php zusätzlich die GalerieID oder ziehe Sie idealerweise auf der foto.php mit aus der DB ( halbwegs vernünftiges Datenbank-Design vorausgesetzt ) und nutze die für Deinen Zurück-Link.

    Nur der Vollständigkeit halber: Bei Sessions müsstest Du in jeder Datei ein session_start(); an den Anfang des Script setzen und in der galerie.php dann die ID setzen, bspw.:

    PHP
    $_SESSION['current_gallery_id'] = (integer)$_GET['id'];

    In der foto.php sieht Dein Zurück-Link dann so aus:

    PHP
    <a href="galerie.php?id=<?= $_SESSION['current_gallery_id']; ?>">Zurück</a>

    Hinweis: Du solltest Wert, die über manipulierbare Quellen/Wege an das Script übergeben werden entsprechend behandeln!

    Dein Prinzip unterscheidet sich zielführend wenig von der richtigen Variante, nur dass Du wie gesagt sehr unflexibel bist.

    Unflexibel in der Hinsicht, dass Du bspw. nicht auf URLs á la example.com/rgendwas/nochwas eingehst. Das wäre zwar mit einer Anpassung des Pattern relativ einfach anpassbar, aber Du musst dafür die .htaccess bearbeiten, was nicht zielführend sein kann für Produktivsysteme.

    In Deiner index.php vermute ich mal eine Verarbeitung über $_GET, also tippe ich mal ganz stark darauf, dass die RewriteRule nur aus dem Grund mit dem Parameter seite arbeitet, weil Du meinst, dass Du nur so an den Parameter ran kommst. Tatsächlich sollte ( grad getestet, passt! ) das alles aber auch in $_SERVER['REQUEST_URI'] stehen.

    Warum also mit Parametern arbeiten, wenn alles was man braucht schon da ist?

    Das bezeichne ich als umständlich. Du magst das anders sehen, ist Dein Projekt, daher kann ich Dir nur sagen, wie man es richtig macht, aber das muss Dich nicht zwingen es nicht anders umständlicher umzusetzen.


    Zur Erklärung:

    Dein Code aus #5 mal als Vorlage kopiert

    Apache Configuration
    RewriteEngine On
    RewriteRule ^([a-zA-Z0-9]+)$ %{SCRIPT_URL}?seite=$1 [L]

    kann ich auch kurz und knapp so schreiben, um alle URL-Varianten abzudecken ( %{SCRIPT_URL} der Einfachheit im flg. gegen index.php ausgetauscht ):

    Apache Configuration
    RewriteEngine On
    RewriteRule ^(.*)$ index.php?seite=$1 [QSA][L]

    Wenn ich mich nun einfach auf den REQUEST_URI beziehe, kann ich das so umschreiben:

    Apache Configuration
    RewriteEngine On
    RewriteRule ^.* index.php?seite=%{REQUEST_URI} [QSA][L]

    Nun kann man schon erahnen, dass in REQUEST_URI wohl der URI inkl. aller Parameter steckt und diese nicht extra übergeben werden muss.

    Also kann ich auch schreiben:

    Apache Configuration
    RewriteEngine On
    RewriteRule ^.* index.php [QSA][L]

    ...und das führt uns schon in die Nähe des Post #2:

    Apache Configuration
    RewriteEngine On
    RewriteRule ^ index.php [QSA][L]

    Was Dein Prinzip allerdings nicht berücksichtigt - egal, welche der bisher dargestellten Varianten Du nutzt - ist, dass alle Anfragen auf die index.php umgeleitet werden. Wenn Du Pech hast, landen diese Anfragen auch auf der index.php:

    HTML
    <img src="//example.com/bild.jpg">

    Um das zu umgehen, gibt man dem Webserver über sogenannte RewriteConditions bestimmte Regelkonditionen mit auf den Weg.

    Umgangssprachlich zusammengefasst, wären das folgende Konditionen: Gilt nur für nicht physikalisch existente Dateien oder Verzeichnisse.

    Die Kondition als Code müssen wir pro Kriterium setzen, also einmal für die Dateien: RewriteCond %{REQUEST_FILENAME} !-f und einmal für die Verzeichnisse: RewriteCond %{REQUEST_FILENAME} !-d.

    Wer jetzt aufgepasst hat, erkennt schnell, dass wir mit den beiden Zeilen und der letzten Version dieser Erklärung am Ende auf das Resultat aus #2 kommen:

    Apache Configuration
    RewriteEngine On
    RewriteBase /
    
    RewriteCond %{REQUEST_FILENAME} !-f
    RewriteCond %{REQUEST_FILENAME} !-d
    
    RewriteRule ^ index.php [QSA,L]

    Bedeutet also im Grunde: Ist das angeforderte Ziel über das Dateisystem nicht lückenlos abbildbar, springe in die index.php. Darin wären Deine Fälle ebenso abgedeckt, wie jeder andere, reagieren tust Du in der index.php sowieso, Du nutzt Du halt nur z.Zt. noch $_GET, anstatt $_SERVER['REQUEST_URI'].

    Es kann sogar sein, dass auch alles automatisch in $_GET steht, das kann ich allerdings nur vermuten, da ich das kaum nutze.

    Du musst es aber natürlich nicht richtig machen, ich denke nur, dass Du relativ schnell Deinen Kram anpassen musst, wenn Du es nicht so machst.

    Muss ich hier eine eigene Regel erstellen, wenn ich kein Verzeichnis habe? Oder kann man das in eine Regel packen?

    Genau das macht #2. Lies das verlinkte Tutorial, dann hilft Dir der Code auch sicher weiter.

    Beispiel:

    Eingabe in Browser-Adressleiste: https://www.example.com/irgendwas

    Mit einer .htaccess wie in #2, wird die Anfrage wie gewünscht auf die index.php geleitet, da es kein Verzeichnis irgendwas gibt.

    Da ich nicht wissen kann, wo Du den Inhalt der Seite irgendwas am Ende abgelegt hast, gehe ich mal exemplarisch davon aus, dass es eine Verzeichnisstruktur /views/pages/ gibt, wo die entsprechenden Inhalte als .html-Dateien vorliegen.

    Mit der Annahme könnte ich dann in der index.php nach beispielhaftem Prinzip einfach den Dateiinhalt laden und ausgeben:

    PHP
    // creating path to content
    $sContentPath = __DIR__ . '/views/pages/' . trim( $_SERVER['REQUEST_URI'], '/' ) . '.html';
    
    // load content and send to output channel if file exists
    if ( file_exists($sContentPath) )
        echo file_get_contents( $sContentPath );

    Ist lt. meinem Verständnis genau das, was Du benötigst und die übliche Vorgehensweise. Ansonsten musst Du Dein Anliegen nochmal genauer erklären.

    Und das steht alles im Link aus #2.