Beiträge von tk1234

Zitat von Andrew Applephobie

mein Verständnisproblem bezieht sich auf die injection welche ich nicht auffinden konnte.

Mir ist nicht ganz klar wie du die "auffinden" willst. Um zu sehen ob ein Code für SQL-Injection anfällig ist, reicht es idR wenn man mal ein ' in das entsprechende Eingabefeld eingibt und sich dann den daraus entstehenden Query anschaut - aber mit prepared Statements bist du da auf der sichern Seite.

Zitat von Andrew Applephobie

Da ich das alte Script abgespeichert habe, werde ich zu einem späteren Zeitpunkt nochmal darauf zurückkommen und mich versuchen

Als Tipp am Rande: um auf alte Versionsstände zurückgreifen zu können ist eine Versionsverwaltung wie git ganz hilfreich - nur als Hinweis für die Zukunft.

Zitat von Andrew Applephobie

Funktioniert das so wie ich es beim zweiten echo versucht habe?
Oder müsste ich den Text in eine $text Variable umwandeln und erst dann mit htmlspecialchars($text) behandeln?

Jein. Klar kannst du den kompletten String durch htmlspecialchars() jagen - bei den festen Texten ist es aber unnötig. Ich weiß nicht was du mit "$text Variable" meinst, aber wie schon gesagt, das Umkopieren von Werten aus $_POST (bzw. auch $_GET) ist und war schon immer völlig überflüssig:

echo 'E-Mail: ' . htmlspecialchars($_POST['mail']) . ' erfolgreich registriert!';

Zitat von Andrew Applephobie

- Der Text in "die" war nur ein 0815-placeholder damit etwas da steht.

Ich versuche noch eine Weiterleitung zum footer, wo sich das Newsletter-Formular befindet wird zu bauen.

Der jetzige Text ist noch schlechter, in der Ausgabe die beim Browser landet steht kein Link.

Und wenn die Fehlermeldungen am Ende der Seite stehen, kannst du als Ziel des Formulars auch eine ID als Ziel angeben (action="#newsletter" und id="newsletter" für das Formular) - ich würde vom Formular im Footer aber eher auf eine extra Seite verweisen welche Fehlermeldungen bzw. Erfolgsmeldung ausgibt (das Formular im Footer verweist also auf die extra Seite, das (bei Fehlern nochmal ausgegebene) Formular auf der Extraseite verweist auf sich selbst.

Zitat von Andrew Applephobie

- Danke, für die Info. Ich wüsste jetzt nur nicht was ich damit machen soll

Das kommt darauf an was du nach dem INSERT überhaupt vorhast. Der while-Block sieht mir auch eher danach aus als wäre er blind irgendwo zusammenkopiert - eine while-Schleife ist nämlich völlig überflüssig wenn es nur einen anzuzeigenden Datensatz gibt … Vielleicht lernst du erstmal weiter Grundlagen …

Zitat von Andrew Applephobie

Auch wenn ich (vermutlich) dieses Problem unten mit meiner zweiten Antwort beseitigt haben, möchte ich Dich trotzdem bitte fragen wie ich diese Lücke überhaupt auffinde. Ok SQL-Injection aber wie?? Führe ich die Injektion schon im Eingabefeld, oder erst nach Absenden des Formulars durch? Wie komme ich zu einer Fehlerausgabe? mit " ' ", oder "order by" komme ich zu keinem Fehler

Ich verstehe dein Verständnisproblem nicht.

Zitat von Andrew Applephobie

Ist der Code jetzt passend und safe?

Jein. Das Speichern der Daten bzw. die Übergabe der Daten an die Datenbank ist richtig (mit benannten Parametern (deswegen hatte ich PDO empfohlen) in den prepared Statements wäre der Code noch besser lesbar aber so ist es auch ok) - du hast aber den Kontextwechsel nach HTML nicht beachtet: die beiden echo-Zeilen geben Daten in den HTML-Code aus, Ausgaben müssen hier deswegen mit htmlspecialchars() behandelt werden.

Außerdem:

- warum verwendest du auf einmal $_GET? bleib (in diesem Fall) bei $_POST

- das Umkopieren von Daten aus $_GET/$_POST war schon immer überflüssig - du kannst auch direkt Daten aus $_POST an execute übergeben

- das "die" ist keine benutzerfreundlichen Fehlerbehandlung

- das fetch() wird wohl so nicht funktionieren (hab es jetzt nicht ausprobiert) da du vorher keine Daten abgefragt hast

Zitat von Andrew Applephobie

Ok, hier kann ich momentan nur Raten, aber ich denke der eingebaute Wert in der Tabelle Newsletter wäre VALUES ('$mail').

Deswegen wäre hier eine Entschärfung nötig, richtig?

Ja, das was in $mail steht muss entschärft werden.

Zitat von Andrew Applephobie

Was ist die falsche Stelle und was wäre die richtige Stelle?

Schrieb ich doch: richtig wäre die Stelle an der die Adresse als Teil des HTML-Codes ausgegeben wird (was allerdings garnicht passiert), falsch ist in der validate-Funktion (die ohnehin Unsinn ist).

Zitat von Andrew Applephobie

Der angesprochene Inhalt ist in diesem Fall die eingetragene E-Mail Adresse, korrekt? Wenn ja, dann reicht es wenn die Datenbank mit Mails befüllt wird - eine Text Ausgabe ist nicht nötig!

Korrekt. Eben, die Datenbank soll mit Mails befüllt werden, nicht mit HTML-Code - und du kannst nicht wissen als was irgendwelche Daten in Zukunft mal ausgegeben werden sollen. (Und ja, mir ist bewusst dass in den meisten Fällen in E-Mail-Adressen keine Zeichen vorkommen werden die von htmlspecialchars() verändert würden, aber das Prinzip der korrekten Behandlung von Kontextwechseln sollte *immer* angewendet werden)

Zitat von Andrew Applephobie

In send.php Zeile 15-18 wird eine Weiterleitung definiert, wenn Eingabe 'empty'. Momentan ist dies auf index.html vorgesehen, aber dazu werde ich noch eine eigene Fehlerseite erstellen

Mach es dir nicht unnötig schwer: verwende genau eine Datei (Stichwort Affenformular von oben) und behandle dort alle Fälle, einschließlich aller zu behandelnden Fehlerfälle - du willst nicht wirklich für jeden Fehlerfall eine eigene Fehlerseite erstellen (die hier auch den Nachteil haben dass bereits eingegebene Daten nicht übernommen werden).

Zitat von Andrew Applephobie

ich vermute du wolltest *braucht keinen Text als....* schreiben

Nein. Das war schon richtig wie ich es geschrieben habe: ein Label-Element enthält die Beschriftung die dem Client sagt was in ein Eingabefeld hineingehört (und hat auch noch den Vorteil dass ein Klick auf den Beschriftungstext den Fokus auf das Eingabefeld setzt, was besonders bei Checkboxen die Bedienung erleichtert).

<section class="news">
  <h3>Jetzt registrieren</h3>
  <form method="post">
    <label for="mail">E-Mail-Adresse</label>
    <input type="email" id="mail" name="mail">
    <button name="btn">Abschicken</button>
  </form>
</section>

Als input-type habe ich email verwendet (das verbessert die Bedienbarkeit auf Mobilgeräten da die dann wissen was da rein gehört), das fehlende id-Attribut von input ergänzt (sonst fehlt die Zuordnung zwischen label und input), außerdem habe ich alle überflüssigen Attribute weggelassen:

- input/placeholder -> da stand ohnehin nur das drin was im label ohnehin schon steht

- button/class -> unnötig, der button ist zum Formatieren über den Selector ".news button" erreichbar

- button/type -> submit ist der Standardwert

- form/action -> bei einem Affenformular wird immer die gleiche URL aufgerufen, das geschieht ohne action-Attribut automatisch

ohne for-/id-Attribut geht es auch wenn du das label erst nach dem Input wieder schließt:

<label>E-Mail-Adresse <input type="email" name="mail"></label>

Zitat von TakeOnMii

Ich habe im Internet gesucht wie ich einen Pfeil mache, weil "-->" nicht so gut aussieht. Da bin ich dann auf eine Website gestoßen auf dieser man Emojis etc. für HTML finden kann mit allen Codes.

»-->« meinte ich auch nicht, aber du brauchst keine HTML-Codes, schreib→ einfach direkt in den Quellcode, nicht → - das geht mit allen UTF-8 Zeichen und das sind deutlich mehr als es HTML-Referenzen gibt.

Zitat von TakeOnMii

font-color und <center> hatte ich schon weggemacht.

Und was ist mit <h1> und der div-Suppe?

Zitat von Andrew Applephobie

Unwissenheit ist mein Problem gewesen, ich programmiere mit VS Code und nutzte bis vor meinem ersten Posting immer nur Live Server als Vorschau-Plugin. Dass da Standart solche Fehlermeldungen nicht angezeigt werden war mir nicht ganz bewusst,

VS Code zeigt deinen Syntaxfehler (das fehlende Semikolon) bereits an - der Fehler ist in deinem Code in #9 immernoch/wieder drin! Ansonsten habe ich den Server von VS Code noch nicht benutzt, ich verwende immer den lokalen Indianer. Übrigens: in PHP-Dateien die aussschließlich PHP-Code enthalten lässt man das ?> am Ende weg.

btw: "Standard" schreibt sich schon immer mit "d" am Ende.

Zitat von Andrew Applephobie

Nachdem ich keine wirklichen PHP und MySQL Kenntnisse habe tu ich mich von Grund auf schwer.

Dann eigne dir erstmal die Grundkenntnisse an - dazu die zu vermitteln ist das Forum nicht da.

Zitat von Andrew Applephobie

- Wo soll ein Kontextwechsel zu SQL durchgeführt werden und warum?

An der Stelle an der ein Wert in einen SQL-Query eingebaut wird und um Zeichen zu "entschärfen" die in SQL eine spezielle Bedeutung haben. Das einfachste wäre übrigens prepared Statements zu verwenden, das macht die Behandlung des Kontextwechsels einfacher/lesbarer - da würde ich aber PDO statt mysqli für den Datenbankzugriff empfehlen.

Zitat von Andrew Applephobie

- Wo befindet sich für den Kontextwechsel die falsche Stelle zu HTML

Der Satz ist etwas durcheinander geraten. Aber der Autor des Videos verwendet zwar die richtige Funktion (htmlspecialchars()) für den Kontextwechsel nach HTML aber leider an der völlig falschen Stelle (in der validate-Funktion). So wird Inhalt der für die Ausgabe in HTML aufbereitet wurde so in der Datenbank gespeichert - aber was ist wenn der Inhalt mal als Text (z.B. in einer Mail) ausgegeben werden soll? Dann hast du da die HTML-Zeichen drin und die Mail wird u.U. etwas seltsam aussehen …

Zitat von Andrew Applephobie

- Ein Affenformular soll überprüfen (in meinem Fall) ob bei 'mail' eine gültige Eingabe vorhanden ist und sonst den Vorgang so oft neu wiederholen lässt bis der Wert passt, korrekt? Ist es zwingend, oder einfach nur Benutzerfreundlicher?

Korrekt, ja. Zwingend ist es nicht, aber es ist benutzerfreundlicher: der Kot[sic!] aus dem Video leitet bei einem Fehler (z.B. leeres Feld) einfach kommentarlos auf das Formular weiter wobei auch schon korrekt eingegebene Inhalte einfach verworfen werden - findest du das benutzerfreundlich? Ja, ein Formular so zu gestallten dass es benutzerfreundlich ist, ist etwas aufwendiger aber die Bedienbarkeit darf niemals leiden nur weil es für den Programmierer aufwendiger ist.

Zitat von Andrew Applephobie

- Das Label-Element war Sinnfrei und hätte dort nicht hingehört. Als "Beschriftung" wird ein H3-Element verwendet

Nein! Das label-Element *muss* da hin, braucht aber einen Text als Beschriftung (nein, das placeholder-Attribut ersetzt diese nicht!). Das h3 ist (hier) die Überschrift des Formulars, hat aber mit der Beschriftung des Eingabefeldes nichts zu tun. Dein input mit type=submit wäre übrigens gerne ein richtiger <button> - gibt auch mehr Freiheiten mit der Beschriftung.

Zitat von Andrew Applephobie

- Kodierung passt nicht weil und wie korrigiere ich es?

Auf Internetseiten sollte immer und überall UTF-8 verwendet werden (nicht nur in der Datenbank, auch die Scripte), damit ist jedes Zeichen abgedeckt welches du mal brauchen könntest. Eingestellt wird das beim Erstellen von Tabellen (oder auch Datenbanken), in Adminer gibt es dafür ein select "Kollationen" bzw. auf Spaltenebene bei den Optionen (unter phpMyAdmin wird das ähnlich heißen, aber das verwende ich schon länger nicht mehr). Bei schon bestehenden Tabellen lässt sich das auch ändern, ggf. muss es aber für die Spalten auch extra geändert werden. Als SQL direkt geht das natürlich auch, da musst du das hinter COLLATE entsprechend angeben - aber du wirst es ja vermutlich ohnehin über eine Admin-Oberfläche machen.

Zitat von TakeOnMii

Sorry für die späte Antwort, aber bei mir in Visual Studio Code zeigt der mir keine Fehler an.

den Fehler mit font-color zeigt VS Code an, die Fehler im HTML nicht da der Code (standardmäßig) nicht validiert wird, nur das <center> wäre anhand der anderen Farbe als falsch erkennbar (wobei der farbliche Unterschied etwas gering ist). Semantisch falsche Elemente kann VS Code (und auch der Validator) nicht erkennen, woher sollen die beiden wissen was da genau geschrieben wurde?

Was mir gerade noch auffällt: warum schreibst du statt &rarr; nicht den Pfeil direkt in den Code? Mit UTF-8 ist das kein Problem …

Zitat von TakeOnMii

Ich habe die Seite zwar noch nicht Online, aber ich kann dir den Code eben schicken:

Ich weiß dass dein Problem (zumindest anscheinend) bereits gelöst ist, aber trotzdem: Bevor du die Seite mit CSS entsprechend formatierst, solltest du erstmal die Fehler im HTML beseitigen: der Code enthält 12 Fehler und 2 Warnungen. Auch Semantisch ist der Code eine Katastrophe und eine einzige div-Suppe: verwende semantisch passende Elemente mit dem du dem Client auch mitteilst was da steht. Die Links zum Beispiel wären gerne eine Liste (<ul>) in einem nav-Element - der Kommentar "Links" ist dann auch überflüssig da das Element selbsterklärend ist. Jeder Link ist dann in einem <li> wobei <h1> und <center> ersatzlos entfallen (vergiss dass es <center> überhaupt mal gab und <h1> ist für die Hauptüberschrift der Seite, nicht für die Navigationslinks).

Übrigens: eine CSS-Eigenschaft "font-color" gibt es nicht.

Zitat von Andrew Applephobie

Über MAMP habe ich die php_error.log Datei in der mir die auftretenden Fehler in einer Konsole angezeigt werden. Wie ich selbst so ein funktionierendes reporting erstelle ist mir noch ein Rätsel bzw. fehlt mir da noch viel an Wissen

Ich verstehe dein Problem nicht wirklich. Fehlermeldungen werden in die php_error.log geschrieben (abhängig von den Einstellungen, die Datei kann auch andere Namen haben), wenn display_errors eingeschalten ist, werden die Fehler gleichzeitig auch ausgegeben. Mit der Konsole hat das erstmal nichts zu tun (wenn auch die unter Zuhilfenahme von tail ganz praktisch sein kann).

Zitat von Andrew Applephobie

Den Link Kontextwechsel habe ich mir durchgelesen, aber momentan ist es noch viel "Bahnhof" für mich dabei. Ich bin für jede weitere Erklärung sehr dankbar!

So läuft das nicht. Du musst schon konkreter werden was genau du nicht verstehst (auch dass ich bzw. jemand anderes bei dem Artikel nachbessern kann), so wäre es ziemlich sinnlos irgendwas erklären zu wollen.

Zitat von Andrew Applephobie

Dazu habe ich ein PHP-Script auf Youtube gefunden, welches ich nachbauen versucht habe.

Finger weg von dem Video! Es ist enthält eine gefährliche Sicherheitslücke: der Autor hat das Prinzip von Kontextwechseln nicht verstanden und behandelt den Kontextwechsel zu SQL nicht (und den zu HTML an der falschen Stelle).

Dazu kommen dann noch Dinge wie kein Affenformular (kein Muss, aber das Prinzip vereinfacht imho die Verarbeitung von Formulardaten), fehlende Beschriftung der Formularfelder (label-Element ist vorhanden, hat aber keine Verbindung zum input; bei dir ist die Verbindung da, aber die Beschriftung fehlt) und die Verwendung von latin1 als Zeichenkodierung statt UTF-8.

Alternativ könnte auch eine handelsübliche Liste in Kombination mit Rahmen und list-style-type, list-style-image oder ::before-Pseudoelement und content-Eigenschaft funktionieren.

Zitat von AndreasB

[…] ist das sehr wohl bedienbar.

Nein, nicht jeder Besucher hat eine Maus und kann sehen wo er klicken muss. Per Tastatur lässt sich der Focus nicht auf jedes beliebige Element setzen und automatisch auswerten/erkennen lässt sich das schon garnicht.

Zitat von langi

Ich wollte damit nur zeigen, dass es kein Button und keine Checkbox ist.

Dann sollte es auch nicht klickbar sein bzw. auf Klicks reagieren - wenn etwas klickbar sein soll, verwende <button>s, sonst ist das nicht bedienbar.

Zitat von McMoneysack91

Auch da war das oberste Verzeichnis mit einigen leeren Dateien gefüllt (wie bei Infinityfree) und man konnte dort nichts hochladen. Erst in dem htdocs.

Dass die Dateien in ein Unterverzeichnis müssen ist völlig normal: nur so kann man Dateien so ablegen dass sie per http nicht erreichbar sind (weil sie z.B. nur von php-Scripten aus erreichbar sein sollen).

Zitat von McMoneysack91

Es scheint also in der Tat am Server zu liegen.

Sag ich doch seit #8 …

Zitat von McMoneysack91

Vielleicht werde ich mich mal nach Servern mit ähnlichen Freiheiten wie Infinityfree umschauen, welche jedoch die Zugänglichkeit eines 000webhost mit sich bringen.

Du wirst keinen perfekten Webhoster finden der nichts kostet - die Server und deren Betrieb kosten nun einmal Geld. Es gibt aber durchaus Webhoster ohne solch merkwürdige Einschränkungen bei denen du reichlich Speicherplatz bekommst. Bei meinem sind bereits beim kleinsten Paket (je nach Laufzeit zwischen 17 und 30 Euro/Jahr) 25 GB Speicher und unbegrenzter Traffic dabei - ähnlich ist das bei aktuellen Paketen anderer Anbieter ebenfalls. Ich glaube auch nicht dass dein Hoster es wirklich zulässt dass du da beliebig viel Daten hoch lädst. Such dir einfach ein Paket für ein paar Euro im Jahr, dann hast du das Problem mit merkwürdig konfigurierten Servern nicht.

Zitat von McMoneysack91

Alle Wörter werden erkannt, h1 h2 h3 werden erkannt, alles tutti.

Ich glaube du hast das Problem noch nicht wirklich verstanden: bei deiner Seite *können* die diversen Tools nichts erkennen da sie nichts ausgeliefert bekommen - die bekommen nur ein Happen Javascript und sonst nichts!

Zitat von McMoneysack91

Das begreife ich noch nicht gänzlich. Heißt das, dass man keinen Inhalt angezeigt bekommt, wenn man Cookies und Javascript deaktiviert?

Richtig. Es wird dann nur der Quelltext aus #8 ausgeliefert. Das passiert übrigens auch wenn du deine Cookies löschst und dann auf die Seite gehst, nur führt der Browser das Javascript üblicherweise sofort aus und bekommt dann die eigentliche Seite ausgeliefert - du merkst das nur an dem ?i=1 was dann an der URL hängt.

Ich weiß nicht wie viel technisches Verständnis deine Freunde haben, aber um Cookies und Javascript auszuschalten muss man schon wissen wo man hinklicken muss, die wenigsten werden das machen - ich habe es auch nur gemacht da die Wörter in dem SEO-Tool darauf hingedeutet haben dass da irgendwas anderes ausgeliefert wird, vermutet hatte ich irgendein Javascript. Probier es doch einfach mal aus was passiert wenn du Javascript und/oder Cookies abschaltest …

Zitat von Sempervivum

Generell kann man sehr wohl Inhalte von Fremdseiten in iFrames anzeigen. Es ist nur so, dass Google und Co. das durch irgend welche Skripts unterbinden.

Keine Scripte, ein einfacher Header reicht. Aber Frames (dazu zählen auch iframes) möchte der OP ohnehin nicht verwenden.

Zitat von MrMurphy

Tut mir leid, aber Pixel für Break-Points sind richtig und zulässig. Das heißt nicht, das die Einheit "em" nicht funktioniert oder gar falsch ist. Beide Einheiten können gleichwertig verwendet werden.

Nein. Relevant für Break-Points sind nicht irgendwelche Bildschirmbreiten sondern die Inhalte der Seite - und die bemisst man eben in em, nicht in px.

Zitat von MrMurphy

Zudem habe ich nur ein Beispiel für eine Lösung gegeben, die funktioniert.

Ein Fan von fertigen "Lösungen" war ich noch nie - so lernt der OP garnichts.

Zitat von MrMurphy

Wenn du eine Grid-Lösung hast die genau so funktioniert - gerne her damit.

Ein kleines Beispiel:

<!DOCTYPE html>
<html lang="de">
<head>
  <meta charset="utf-8" />
  <meta name="viewport" content="width=device-width, initial-scale=1" />
  <title>Grid</title>
  <style>
    section {
      display: grid;
      grid-gap: 1rem;
      grid-template-columns: repeat(auto-fill, minmax(10em, 1fr));
    }
  </style>
</head>
<body>
  <section><button>1</button></section>
  <script>
    var target = document.querySelector('section');
    var button = document.querySelector('button');
    for (var i = 2; i <= 80; i++) {
      var copy = button.cloneNode(true);
      copy.textContent = i;
      target.appendChild(copy);
    }
  </script>
</body>
</html>

(das Javascript ist nur dazu da die Buttons zu erzeugen) Damit werden immer so viele Buttons in einer Zeile gezeigt wie eben rein passen wobei die Buttons mindestens 10em breit sein müssen. Ich muss dir allerdings recht geben: was der OP genau will ist nicht so ganz klar, evtl. sollen immer 8 Buttons untereinander stehen? Ist aber auch kein Problem: einfach in section mehrere Blöcke mit je 8 Buttons einfügen, dann werden die gemeinsam verteilt je nach Platzbedarf.

Zitat von McMoneysack91

ANDERERSEITS: frage ich mich auch, ist das denn alles notwendig? Ich meine, der Inhalt, den ich rüberbringen will wird doch angezeigt. Also ein Mensch kann meine Seite öffnen und den Artikel lesen, sich durch die Navigation klicken, buttons betätigen etc.

Wenn er Cookies und Javascript aktiviert hat und auch keines von beidem auf dem Weg zu ihm irgendwo blockiert wird.

Zitat von McMoneysack91

Mir geht es nur darum, dass die Seite auch durch Suchmaschinen anhand des Inhalts gefunden wird

Da dieses Javascript anscheinend dazu da ist Bots abzuhalten würde ich mal vermuten dass auch Suchmaschinenbots abgehalten werden - und falls der Server auf z.B. den Google-Bot anders reagiert könnte Google da u.U. verschnupft darauf reagieren. Du kannst bei Suchmaschinen aber einfach überprüfen was sie auf deiner Seite finden, einfach nach "site:domain" suchen, bei Google hilft evtl. auch ein Blick in die Webmaster-Tools.

Nachtrag: PHP[1] scheint nicht schuld zu sein, die CSS-Datei wird auch nur ausgeliefert wenn der Cookie vorhanden ist. Das Problem ist dein Free-Hoster (wohl infinityfree.net, nicht .com?) - die haben eben den Nachteil auch mal sowas einzubauen. Google spuckt zu dem Thema auch was aus (Suchworte "infinityfree.net cookie"), genau habe ich das jetzt nicht gelesen, das überlasse ich dir - in die Richtung solltest du aber ggf. weitersuchen.

[1] btw: deine PHP-Version ist veraltet, verwende mindestens PHP 7.3, alle kleineren Versionen werden nicht mehr unterstützt.

Zitat von basti1012

Ich Rate mal das die probleme von deiner include Suppe kommt.

Schwachsinn! Hast du eigentlich gelesen (und verstanden) was ich oben geschrieben habe? Einfach mal die Seite mit deaktiviertem Javascript oder Cookies aufrufen (ggf. Cookies vorher löschen), du wirst eine einzeilige Meldung bekommen das Javascript nicht aktiviert sei bzw. zu Google-Seite wie man Cookies aktiviert, weitergeleitet werden.

Die include-Orgie mag ungewöhnlich sein, das Problem ist die aber nicht - das hast du ja bewiesen da es bei dir funktioniert.

Das Problem liegt irgendwo in den Servereinstellungen, da muss der OP aber schon selbst nachschauen bzw. seinen Provider fragen. Suchorte für die Einstellungen sind .htaccess-Dateien, PHP-Einstellungen[1] (auto_prepend_file fällt mir da ein) aber auch die Apache-Konfiguration selbst auf die man aber idR keinen Zugriff hat.

[1] es wäre interessant was passiert wenn man eine reine HTML-Seite verwendet - wird dann auch das Javascript ausgeliefert oder gleich der richtige Code?

Zitat von MrMurphy

Ich habe mal ein Beispiel erstellt. Je nach Bildschirmbreite 1, 2, 4, 5 oder 10 Spalten.

Was aber Unsinn ist. Alle Buttons in ein Elternelelement sowie Grid-Layout in Verbindung mit minmax() und fertig. Irgendwelche Verrenkungen mit Break-Points sind da nicht nötig, zumal du da ohnehin die falsche Einheit verwendest, Pixel sind da falsch.