Beiträge von wolf

Zitat von MarkusBEO

Ok, aber dann müsste ich wohl meine Codezeile 2 aufteilen oder auseinander nehmen?

Ja, wenn du es so machen willst, musst du statt SELECT * FROM alle deine Felder einzeln aufzählen:SELECT firstname, lastname, DATE_FORMAT(date, ?%e.%m.%y?) as date, is_active FROM.
Es gibt hier noch einen hacky weg, der ist aber nicht zu empfehlen: SELECT *, DATE_FORMAT(date, ?%e.%m.%y?) as date FROM hier macht man sich zu nutze das MySQL wenn das selbe feld mehrfach abgefragt wird immer das letzte dieser mehrfach felder genutzt wird (dein * enthält ja schon einmal date und dann überschreibst du dieses original date mit deinemm DATE_FORMAT(date, ?%e.%m.%y?)).

Ein Weg ist es, die Daten weiter in einem technischen Format zu halten (so abfragen wie sie aus der Datenbank kommen.
Danach kannst du dise auch genau so Weiterverarbeiten.

Meine Persönliche Empfehlung ist PDO::FETCH_OBJECTstatt PDO::FETCH_ASSOC zu verwenden. Das ist aber nur eine Präferenz meinerseits und ändert quasi nichts am folgenden Code beispiel.
Außerdem würde ich Empfehlen code immer englisch zu halten, dazu gehören auch Datenbanktabellenspalten & Namen.

In jedem fall geht der Code dann so weiter:

//$contacts = $stmt->fetchAll(PDO::FETCH_ASSOC);
$contacts = [];
foreach($stmt->fetchAll(PDO::FETCH_OBJECT) as $row){
    //hydrate values from the database to their respective data type
    $row->date = new \DateTime($row->date);
    $row->is_active = (bool) $row->is_active;//hier noch ein beispiel wie man das noch nutzen kann

    $contacts[] = $row;
}

Das erlasubt dir z.B. jetzt relativ einfach Vergleiche der Daten durchzuführen und eben mit den Daten zu arbeiten ohne immer ein strtotime()aufrufen zu müssen.

Und dann in deiner View-Datei oder wo auch immer du das Datum ausgeben willst:

<?php foreach($contacts as $contact):?>
    Datum: <?=$contact->date->format('d.m.Y')?>
<?php endforeach?>

Gut, das ist vermutlich nicht wirklich hilfreich wenn es darum geht eine Schulaufgabe selbsständig zu lösen

Zeilen 29 - 39 sind logisch vermutlich falsch.
Ich Vermute du versucht in Zeile 31 zu prüfen ob der bmi größer als der des if's davor ist und kleiner des nächsten BMI.

Allerdings ist hier ein fehler.
Zudem frage ich mich ob du überhaupt prüfen musst ob er größer ist als der des if's davor, da durch die else-if die bedingung davor ja bereits fehlgeschlagen ist.

Blöder Tipp von der Seite, Finger weg von file handles wenn man sie nicht braucht.
Nutz doch einfach https://www.php.net/manual/de/function.file-put-contents.php

hier mal ein Beispiel

/**
 * @param string $type
 * @param string $message
 * 
 * @throws \Exception
 */
function log(string $type, string $message) : void{
    $data = (new \DateTime())->format('Y-m-d H:i:s') . ' ['. $type .']: ' . $message;

    if(!file_put_contents(__DIR__ . DIRECTORY_SEPARATOR . 'application.log', $data . PHP_EOL, FILE_APPEND)){
        throw new \Exception('Can\'t write data to logfile!');
    }
}

Was anders ist als in deinem Code / was es daraus zu lernen gibt

1. Der Pfad der Log Datei wird nicht immer von außen mitgegeben, wenn der sich ändern muss, würde ich das z.B. von $type abhängig machen
2. Der Pfad ist absolut, nutzt aber das aktuelle Verzeichniss als Basis
3. Es wird file_put_contents statt filehandles genutzt
4. Das mit dem Zeitstempel ist so einfacher, date_default_timezone_set solltest du oben in deiner index.php aufrufen (bei error_reporting)
5. Es wird ein Fehler geworfen wenn etwas nicht geklappt hat

----

Sollte es nicht funktionieren pack mal die folgenden Sachen vor Zeile 8:

$path = __DIR__ . DIRECTORY_SEPARATOR . 'application.log';
var_dump([
    'path' => $path,
    'file_exists' => file_exists($path),
    'is_writable' => is_writable($path),
    'is_dir' => is_dir($path),
    'is_file' => is_file($path),
]);

Ganz genau so sieht es aus.
Du sagst dem Server "hey, führe bitte alle (X Minuten / jeden 1. im Monat / usw.) folgenden Code aus: (php Script ausführen / URL aufruf / usw..)" und dann macht der Server das automatisch.
Falls dein Hosting das nicht unterstüzt, kannst du dir mit einer freien Alternative zumindest URL Aufrufe (welche ja auch ein php Script ausführen können) machen: https://cron-job.org/de/

In deinem Script führst du dann deinen Check aus und nicht mehr. Und dieses Script lässt du dann immer wieder aufrufen, fertig.

Dumme Frage,

aber PHP ist an und für sich eine Template Engine und lässt sich super dafür nutzen ohne den ganzen Overhead von Smarty & Co.

Eine Trennung zwischen Funktion und Template ist durchaus Sinnvoll, ob man eine Template Engine braucht wage ich zu bezweifeln. Die hauptsächlichen Vorteile einer Template Engine sind:

• Geschwindigkeit durch Caching
• ein Paar Sicherheitsfeatures (wie z.B. auf jedes echo ein htmlentitites anzuwenden)
• Erweiterbarkeit & Standardisierung

Der Rest sind meistens subjektive Argumente wie "einfacher zu Lernen" usw.

Für Hobby Projekte würde ich die Finger davon lassen, außer man will es des Lernens wegen nutzen. Dann würde ich ganz klar die Finger von smarty lassen und https://twig.symfony.com nutzen.

-----

Das eigentliche Problem habe ich aber noch nicht so ganz verstanden, kannst du Stef nochmal ausführen, was du vorhast & woran du scheiterst?

Stef, tk1234 der Vorteil Dateien außerhalb des Docroots abzulegen ist, niemand kann darauf über die URI zugreifen (//example.com/.../config.php aufzurufen ist quasi nie möglich, //example.com/config.php dagegen viel eher).
Dies hilft bei (Webserver-)Konfigurations & Menschlichen Fehlern Datenleaks zu vermeiden. Natürlich ist das keine Garantie aber eben eine Maßnahme mehr.

Das ganze ist nicht relevant wenn alles richtig konfiguriert ist & keine Fehler passieren, überall die benötigten deny Einträge liegen und directiory indexing ausgeschaltet ist. Wir wissen aber das in der echten Welt fehler passieren und Dinge übersehen werden oder auch Maschinen wie Webserver manchmal nicht mehr so funktionieren wie vorgesehen.

Zum Beispiel:

1. In dem Moment wo sich aber z.B. dein Webserver verschluckt und z.B.*.phpdateien nicht mehr über den php parser ausliefert sondern direkt könnten Configurations-Dateien plaintext an den Nutzer augeliefert werden.
2. Irgendwelche debug ausgaben mit kritischen Informationen in einer Datei übersehen/vergessen werden, die zwar im normalen einsatz der applikation nicht eingebunden werden, durchaus aber noch über die URL aufrufbar sind
3. Ein Fehler in einer von dir genutzen composer dependencie vorliegt der dir nicht bekannt ist, welcher ausgenutzt werden kann, weil die composer dateien über die URL aufrufbar sind
4. -- hier kann man noch ne Menge ergänzen, u.A. auch komplizierte Exploits --

tl;dr
Wenn es bei deinem Hoster möglich ist den document root anzupassen, ist das zu empfehlen & nur wirklich öffentliche Dateien (index.php, css, bild und js assets) im public Ordner abzulegen.

Dateiname groß, klein passt?
Unix verhält sich hier anders als Windows.
Möglicherweise können auch irgendwelche (unsichtbaren) Steuerzeichen entweder im Dateinamen oder im Klassennamen befinden.
Zudem würde ich mit einem kleinen `die('foo')` im Kopf der Zieldatei überprüfen, ob die Datei durch den Interpreter läuft (also erfolgreich geladen wird) oder ob es bereits hier scheitert.

Hier noch eine Option, falls das multi-Select nicht gefällt..

<form action="/action_page.php" method="POST">
  <label>Choose a car:</label>
  <label><input value="volvo" name="cars[]" type="checkbox">Volvo</label>
  <label><input value="saab" name="cars[]" type="checkbox">Saab</label>
  <label><input value="opel" name="cars[]" type="checkbox">Opel</label>
  <label><input value="audi" name="cars[]" type="checkbox">Audi</label>
  <br><br>
  <input type="submit" value="Submit">
</form>

kann es gerade nicht testen, die Verarbeitung sollte gleich sein wie bei basi

Da hast du recht @cotton. War fokussiert darauf was vermutlich im Rahmen der Möglichkeiten lag.
Hab meine Empfehlung enstprechend angepasst

Zitat von cottton

$alphabet kannst Du schon mal generieren.

So in etwa (ungetested)

Sollte sogar so gehen

$alphabet = range('a', 'z');

https://www.php.net/manual/en/…1-function.range-examples

Zitat von MarvinTLA

Gibt es da eine Möglichkeit?

Der bessere Weg ist es eine Möglichkeit für den Nutzer oder Sysadmin zu haben der das Passwort automatisch zurücksetzt/ändert.

• Das System sendet dem Nutzer auf Anfrage (Passwort vergessen?) einen (zeitlich begrenzten) Passwort Reset Link per E-Mail zu, sodass dieser sein Passwort selber Ändern kann

Alternativ dazu (einfacher in der Umsetzung, aber nicht der beste Weg)

• Das System erstellt ein neues Passwort und sendet es direkt dem Nutzer zu, sodass der Admin es nie sieht
• Der Admin kann ein neues Passwort eintragen und muss es dem Nutzer manuell übermitteln

Danach kann der Nutzer sich anmelden und sein Passwort wieder auf sein Wunschpasswort ändern

DU machst es dir enorm viel schwerer wenn du es unbedingt mit JS lösen willst, PHP wäre hier die bessere alternative!

MVC Strukturierte Projekte

.htaccess
index.php
(autoload.php)
application/
    config/
    controller/
    library/
    model/
themes/
    theme/
        assets/
            scss/
            css/
            js/
        view/
vendor/

Prinzipiell lohnt es sich PSR Namespaces in verbindung mit einem autoloader zu verwenden, da es einem das Laden der einzelenen Klassen abnimmt.

Alternativ lässt sich der view Ordner auch in den application Ordner schieben und der assets Ordner auf Hauptebene unterbringen, der themes ordner fällt hierbei weg.
Der vendor Ordner kann ebenfalls in den application Ordner verschoben werden.

Für wirkt das etwas so als wollte AdriBloober sich hier den Code fertig präsentieren lassen.

Bitte poste mal deinen Code AdriBloober !

Am besten machst du dazu einen neuen Thread auf im PHP Forum

Stef ohne geringste grundkentnisse ist es wichtig erstmal das bisschen kennen zu lernen.

Nutze lieber file_put_contents($filename, $string, FILE_APPEND)