nicht angemeldet
Matthias Scharwies
Matthias Apsel
Julius
Felix Riesterer
Julius
Julius
Servus!
Ich habe dazu einen Beitrag im SELF-Blog veröffentlicht.
tl;dr → Nachdem es anfangs immer um die „Kern-Technologien“ HTML, CSS und JS ging und PHP nur im Forum stattfand, ist es jetzt auch im SELF-Wiki angenkommen und willkommen.
Wie ihr aus den letzten Änderungen im SELF-Wiki ersehen könnt, hat sich @Julius in letzten Monaten um den PHP-Bereich gekümmert, viel aktualisiert und neu eingestellt und auch weitergehende Vorschläge angedacht:
Julius schrieb uns:
Zum Ausprobieren der üblichen Webtechnologien direkt im Wiki gibt es ja Frickl. Für PHP ist das nicht so einfach und in dem Maße möglich und war bisher auch nicht unbedingt nötig. Abseits einer eigenen PHP-Installation gibt es auch noch Online-Dienste, bei denen man PHP-Code ausführen kann, wie beispielsweise PHP in Browser (der PHP-Interpreter läuft dank Webassembly tatsächlich im Browser) oder 3v4l.org (ermöglicht auf komfortable Art und Weise Tests in verschiedenen PHP-Versionen auszuführen).
Sollen allerdings komplexere Dinge wie die Sortierung von Datenbank-Ausgaben, eine Suchfunktion oder eine Bewertungsfunktion (das Frontend hat Gunnar ja schon mal geliefert) demonstriert werden, ist das jedoch aufgrund der Einschränkungen dieser Dienste nicht oder nur eingeschränkt möglich.
Ich schlage davor, eine Möglichkeit zu schaffen, um diese Beispiele im SELF-Raum hosten zu können. Natürlich können Nutzer der Seite diese nur betrachten und nicht verändern, aber ich denke, dass das in einigen Fällen schon hilfreich wäre. Und natürlich kann man gewisse Dinge auch gar nicht demonstrieren, ein Dateiupload mit dauerhaftem Speichern der Dateien und E-Mail-Versand wäre beispielsweise gefährlich und unnütz.
Außerdem gäbe es endlich eine Möglichkeit, abseits von src.selfhtml.org unkompliziert ZIP-Dateien bereitzustellen, beim Sitemap-Tutorial hätte ich das beispielsweise gerne mit der verwendeten Beispiel-Seite gemacht, damit jeder unkompliziert die Möglichkeit zum Nachvollziehen hat.
Zur Technik würde ich vorschlagen, die Beispiele aus Sicherheitsgründen auf einem separaten Server zu hosten, der nur dafür benutzt wird.
Als Domain sollte ebenfalls aus Sicherheitsgründen (der Beispiel-Code soll keine Zugriffsmöglichkeit auf die Session-Cookies anderer SELF-Dienste haben) etwas in der *.selfhtml.org verwendet werden, aber keinesfalls *.wiki.selfhtml.org. Den Code legt man in einem GitHub-Repository ab, auf dieses kann man dann gewissen Leuten Zugriff geben. Sobald etwas gepusht wurde, triggert ein Hook ein Script auf dem Beispiel-Server und dieses holt den aktuellen Stand von GitHub. Das funktioniert und ist keine Raketenwissenschaft. Im Wiki wird dann (idealerweise mit einer Vorlage) auf den jeweiligen Beispielcode und die gehostete Variante verlinkt.
Aufwand: Vertetbar, da nichts an MediaWiki oder Frickl angepasst werden muss. Ich kann gerne mit dem GitHub-Repo in Vorleistung gehen und Beispiele sammeln, bevor die Infrastruktur steht.
Risiko: Gering. Sollte sich keine(r) mehr um den Beispiel-Server kümmern, kann man den ohne wesentliche Seiteneffekte einfach abschalten und die Referenzen darausaus dem Wiki löschen.
Meine Beteiligung: Bei Bereitstellung einer Domain, eines Servers und idealerweise eines Repos unter github.com/SELFHTML kann ich mich um die Einrichtung und Dokumentation des ganzen kümmern, wenn das gewünscht ist. Bei der MediaWiki-Vorlage brauche ich vielleicht Hilfe.
Beschluss des Vorstands: Wir sind dafür!
Das ist eine Super-Idee, an deren Verwirklichung wir mitarbeiten werden!
Oft kommt man sich als Einzelkämpfer vor - da ist es erfrischend und motivierend, wenn man sieht, wie sich andere reinhängen und Gutes schaffen!
Herzliche Grüße
Matthias Scharwies
Hallo Matthias Scharwies,
Bei der Vorlage helfe ich gern.
Bis demnächst
Matthias
Hallo Matthias,
Bei der Vorlage helfe ich gern.
Dann komme ich mal darauf zurück 😉. Ich denke, als erstes sollte geklärt werden, wie die Vorlage aussehen sollte, damit sie benutzbar ist.
Ich halte es für sinnvoll, die Beispiel-Vorlage zu erweitern, sodass statt Frickl optional auch auf die PHP-Beispiele verlinkt werden kann. Dadurch sehen Frickl- und PHP-Beispiele sich ähnlich, was ich für zweckmäßig halte.
Mir schwebt ein zusätzliches Attribut – beispielsweise php – vor, das dann einen Wert wie /wechsler/ erhält und daraus einen Link zum Code (statt „bearbeiten“ dann „Code ansehen“, und den Link zum Anschauen „Ausgabe ansehen“ statt „ausprobieren“ generiert (Links können durch einfache String-Konkatenationen erzeugt werden). Für die meisten Beispiel wäre eine Darstellung innerhalb eines iFrames unter „Vorschau“ geeignet.
Was ist eure Meinung dazu?
Gruß
Julius
Lieber Matthias,
Ich habe dazu einen Beitrag im SELF-Blog veröffentlicht.
+1 von mir! Aber... ich verstehe das Code-Beispiel im Artikel nicht. Dort steht: <?php echo ();>;
Stattdessen hätte ich <?php echo (); ?> verstanden. Was übersehe ich gerade?
Ich schlage davor, eine Möglichkeit zu schaffen, um diese Beispiele im SELF-Raum hosten zu können. Natürlich können Nutzer der Seite diese nur betrachten und nicht verändern, aber ich denke, dass das in einigen Fällen schon hilfreich wäre.
Wenn dabei angedacht ist, dass die im zugrunde liegenden Git gepflegten Inhalte nur von einem erlesenen Kreis mit Schreibrechten gepflegt werden, der Rest ansonsten nur lesen darf, findet das meine ungeteilte Zustimmung.
Liebe Grüße
Felix Riesterer
Hallo Felix,
Ich schlage davor, eine Möglichkeit zu schaffen, um diese Beispiele im SELF-Raum hosten zu können. Natürlich können Nutzer der Seite diese nur betrachten und nicht verändern, aber ich denke, dass das in einigen Fällen schon hilfreich wäre.
Wenn dabei angedacht ist, dass die im zugrunde liegenden Git gepflegten Inhalte nur von einem erlesenen Kreis mit Schreibrechten gepflegt werden, der Rest ansonsten nur lesen darf, findet das meine ungeteilte Zustimmung.
Ja, das ist der Fall. Quasi ein PHP-Beispiel-Administrator. Dem müsste man aufgrund dem Aufbau des Ganzen etwas weniger fest vertrauen können als dem Administrator des Forums- oder Wiki-Servers, aber dennoch sollte man diese Berechtigung nur bestimmten Leuten erteilen. I. d. R. halt denen, die tatsächlich auch PHP-Artikel fürs Wiki schreiben und die davon Gebrauch machen wollen.
Gruß
Julius
Servus!
Lieber Matthias,
Ich habe dazu einen Beitrag im SELF-Blog veröffentlicht.
+1 von mir! Aber... ich verstehe das Code-Beispiel im Artikel nicht. Dort steht:
<?php echo ();>;Stattdessen hätte ich
<?php echo (); ?>verstanden. Was übersehe ich gerade?
Wo steht das? (ist grad geändert worden! 😀)
Hintergrund ist, dass Julius vorgeschlagen hatte, einen Syntax-Highlighter im Blog einzurichten. Ich hatte diese Bitte noch nicht weitergegeben, heute morgen aber gemerkt, dass es bereits einen gibt. 😉
Allerdings musste dafür der maskierte Code < wieder in < umgewandelt werden, was mir nur unzureichend gelang.
Ich schlage davor, eine Möglichkeit zu schaffen, um diese Beispiele im SELF-Raum hosten zu können. Natürlich können Nutzer der Seite diese nur betrachten und nicht verändern, aber ich denke, dass das in einigen Fällen schon hilfreich wäre.
Den Code legt man in einem GitHub-Repository ab, auf dieses kann man dann gewissen Leuten Zugriff geben.
Wenn dabei angedacht ist, dass die im zugrunde liegenden Git gepflegten Inhalte nur von einem erlesenen Kreis mit Schreibrechten gepflegt werden, der Rest ansonsten nur lesen darf, findet das meine ungeteilte Zustimmung.
Genau so ist's geplant! Es sollen vor allen die auf privaten Seiten gehosteten Beispiele weg!
Herzliche Grüße
Matthias Scharwies
Lieber Matthias,
Stattdessen hätte ich
<?php echo (); ?>verstanden. Was übersehe ich gerade?Wo steht das? (ist grad geändert worden! 😀)
da fehlt noch immer ein Fragezeichen vor dem letzten >...
Liebe Grüße
Felix Riesterer
Hallo Matthias,
SELF-Wiki: Beispielumgebung für PHP?
Julius schrieb uns:
[…]
Ich kann gerne mit dem GitHub-Repo in Vorleistung gehen und Beispiele sammeln, bevor die Infrastruktur steht.
Da ist es: https://github.com/JuliusPC/selfhtml-php-beispiele
Eine Live-Demo gibt es auch[1]:
https://selfhtml.mepnet.de/
Die Beispiele zu Cookies und Sessions sollen in einem zusätzlichen Abschnitt des PHP-Einstigs-Tutorials aufgegriffen werden. Die in einem Beispiel verwendete SQLite-Datenbank liegt außerhalb des Document-Root, wie es auch an mehreren Stellen empfohlen wird – auch wenn sie über das Repository öffentlich verfügbar ist – schließlich soll niemand dazu verleitet werden, das falsch zu machen.
Gruß
Julius
Ich habe mir das SELFHTML-Layout von selfhtml.org kopiert, ich hoffe, dass das ok ist... ↩︎
Dir sollte natürlich vor allem für die Arbeit gedankt werden. Aber es braucht wohl eine Qualitätskontrolle. Ich nehm, für alle, nur mal ein Beispiel:
Die Beispiele zu Cookies und Sessions
if (!isset($_COOKIE[COOKIE_NAME])) {
$aufruf = 1;
} else {
$aufruf = $_COOKIE[COOKIE_NAME] + 1;
}
Hm. Da kann man im Anschluss den Umgang mit grep & co lernen, weil sowas das Error-Log füttert.
PHP Warning: Use of undefined constant COOKIE_NAME - assumed 'COOKIE_NAME' (this will throw an Error in a future version of PHP) in /tmp/test.php on line 2
Und das ist nur die Syntax…
Hallo Raketenqualitätskontrolle,
Qualitätskontrolle ist gut, deshalb poste ich das ja auch hier.
Ich sehe aber gerade nicht, worauf du hinaus willst – Die Konstante ist doch definiert?
Gruß
Julius
Ja. Damit, dass die Konstante definiert wird, hast Du Recht. Viel mehr Sorge bereitet aber die Frage, warum ich das wohl übersehen habe...
Ich schrieb:
Viel mehr Sorge bereitet aber die Frage, warum ich das wohl übersehen habe...
Das habe ich zu konkretisieren. Fangen wir an.
Der Verein sollte wohl einige Regelungen, z.B.
treffen. Übrigens nicht nur für den PHP-Teil.
Ich nehm mal das obige:
if (!isset($_COOKIE[COOKIE_NAME])) {
$aufruf = 1;
} else {
$aufruf = $_COOKIE[COOKIE_NAME] + 1;
}
Als „unschön“ markiere ich, dass 'COOKIE_NAME'. Große Buchstaben und Unterstriche als Trenner sind Merkmale von Namen für Konstanten und Variablen, die von PHP selbst belegt werden. Man muss ja nicht gleich die komplette ungarische Notation verwenden: Aber, wie ich das sehe, wäre hier 'CookieName' angenehmer zu lesen und auf den ersten Blick erkennbar, was das denn wohl sei.
Ich benutze z.B. bei neuen Projekten seit einiger Zeit den ersten großen Buchstabe für eigene Konstanten und Klassen, ersten kleinen Buchstabe für Funktionen und Variablen; CamelCase als Merkmal für zusammengesetzte eigene Namen, Plural für Arrays oder andere Listen, $item für den aktuellen Wert in etwas wie foreach(), jedoch stets $row für eine Zeile und auch sonst gern die Bezeichner, welche PHP.net in der Dokumentation verwendet. Was für das Wiki vorgeschlagen oder vorgeschrieben wird ist aber Ansichtssache.
Auch könnte man vorschreiben/empfehlen, bei Arumentlistenbegrenzern (,), Listenbegrenzern [, ], meinetwegen auch {, } zwischen diesen und dem Inhalt ein Leerzeichen zu setzen:
if ( ! isset( $_COOKIE[ CookieName ] ) ) {
Natürlich auch hinter (und vor) Kommas in Listen und allen Arten von Operatoren.
Das wäre nach meiner Ansicht, die auf einem sich schleichend verschlechterndem Sehvermögen im Kurzstreckenbetrieb beruht, viel besser lesbar.
Dann hab ich noch gesehen, dass die Stellung der Blockbegrenzer {, } bei den Autoren und also Einträgen variiert:
derEine( 'notiert', 'so' ) {
}
derAndere( 'notiert', 'so' )
{
}
Was davon gewählt wird ist mir ebenso egal - aber man sollte sich einigen, denn gegenwärtig hat der im Wiki präsentierte Code eine Außenwirkung, die mit dem erhobenen Qualitätsanspruch nicht übereinstimmt.
Kommen wir zum inhaltlichen Aspekten. Wie schon von anderen erwähnt wurde werfen manche Artikel Äpfel, Eier und Rüben durcheinander, was erst die Übersicht und dann deren Sinn verwässert und offenbar sogar die Autoren auf Ab- und Umwege führt - welche durchaus mit der Threadtrift hier im Forum vergleichbar sind.
Darin hat, so sehe ich das, die Prüfung, ob es sich um ein Bild handelt, viel zu viel Raum. Das würde ich konsequent abtrennen und zwar einmal in „Dateiupload“ und dort z.B. die Größenbegrenzung - und wie man diese korrekt begrenzt - genauer besprechen.
Im womöglich weiteren abgegrenzten Artikel über die „generelle Behandlung von Bilddateien aus Drittquellen“ kann man dann den Dateiupload unter einmaligem Verweis auf den speziellen Artikel „einfach und kommentarlos machen“ und den Besonderheiten der Verarbeitung von Grafikdateien aus Drittquellen (e.g. APIs und „so was“) mehr Raum geben. z.B. bei der Sicherheit: Ich würde dazu neigen, jedes Bild mit den imagecreatefrom*-Funktionen aus der temporären Datei zu kopieren. Und dabei bzw. danach womöglich auch richtig zu drehen, was vor ein paar Tagen Thema war, ferner Thumbnails herzustellen und die Größe anpassen. Wobei man sich natürlich darüber unterhalten kann, ob nicht sogar das schon bei fremden Dateien problematisch ist, weil diese PHP-Funktionen durch das Unterschieben von „merkwürdigen“ Dateiinhalten angreifbar sein könnten.
Auch hier gilt: Was und wie das den Autoren nahegelegt wird ist Sache der Maintainer.
Hallo Jörg,
ich denke, bevor wir uns hier etwas Eigenes einfallen lassen, sollten wir uns nach anerkannten Standards zu richten, in diesem Fall die der PHP-FIG. Ob ich das konstant eingehalten habe, müsste ich allerdings noch mal überprüfen.
Als „unschön“ markiere ich, dass 'COOKIE_NAME'. Große Buchstaben und Unterstriche als Trenner sind Merkmale von Namen für Konstanten und Variablen, die von PHP selbst belegt werden.
So sieht die PHP-Doku das:
„By convention, constant identifiers are always uppercase.“
PSR-1 sieht das für Klassenkonstanten ähnlich.
Auch könnte man vorschreiben/empfehlen, bei Arumentlistenbegrenzern
(,), Listenbegrenzern[,], meinetwegen auch{,}zwischen diesen und dem Inhalt ein Leerzeichen zu setzen:if ( ! isset( $_COOKIE[ CookieName ] ) ) {
Das sind ein paar zu viele Leerzeichen für meinen Geschmack. Ich denke, da sollte man sich ebenfalls an den Regeln der PHP-FIG richten, weiß selber gerade nicht, was die konkret vorschreiben.
Was davon gewählt wird ist mir ebenso egal - aber man sollte sich einigen, denn gegenwärtig hat der im Wiki präsentierte Code eine Außenwirkung, die mit dem erhobenen Qualitätsanspruch nicht übereinstimmt.
Das unterstütze ich, war bisher zwar nicht Fokus, aber das ist dennoch sinnvoll.
Kommen wir zum inhaltlichen Aspekten. Wie schon von anderen erwähnt wurde werfen manche Artikel Äpfel, Eier und Rüben durcheinander, was erst die Übersicht und dann deren Sinn verwässert und offenbar sogar die Autoren auf Ab- und Umwege führt - welche durchaus mit der Threadtrift hier im Forum vergleichbar sind.
- z.B. das Dateiupload-Skript.
Das ist kein Skript, sondern eine Einführung, vielleicht auch ein bisschen ein Tutorial. Es ist bewusst kein komplett fertiges Skript drin, sondern nur Ansätze, damit sich der Leser selbst Gedanken machen muss, um es an seine Gegebenheiten anzupassen. Ein Dateiupload-Skript ist nichts, das man einfach so auf seinen Server schiebt, denn es erfordert Wissen im Bereich der IT-Sicherheit, das der übliche Programmiereinsteiger nicht hat (ich spreche aus eigener Erfahrung). Der blutige Einsteiger lernt erst einmal ordentlich PHP und der Fortgeschrittene sieht in dem Artikel einen Ansatz, wie man einen Dateiupload implementiert.
Vielleicht wirkt es aus obigen Gründen auf dich wie „Äpfel, Eier und Rüben“.
Darin hat, so sehe ich das, die Prüfung, ob es sich um ein Bild handelt, viel zu viel Raum. Das würde ich konsequent abtrennen und zwar einmal in „Dateiupload“ und dort z.B. die Größenbegrenzung - und wie man diese korrekt begrenzt - genauer besprechen.
Im Artikel wird beschrieben, welche Werte dafür in welcher Weise wirken. Wie man sie letztlich konkret setzt, steht im PHP-Manual und ist letztlich auch vom konkreten Setup abhängig. Da in die Tiefe zu gehen, erschien mir unzweckmäßig.
z.B. bei der Sicherheit: Ich würde dazu neigen, jedes Bild mit den
imagecreatefrom*-Funktionen aus der temporären Datei zu kopieren.
Da auch das keinen 100%igen Schutz bietet, ich diese Sicherheitslücken eher als solche in der Server-Fehlkonfiguration (nosniff-Header, Ausführen von PHP-Code in Dateien mit Endungen von Bilddateien) sehe, habe ich beim Schreiben des Artikels davon abgesehen, das zu integrieren. Zudem erhöht man durch die Benutzung der GDlib die Angriffsfläche (das erwähntest du ja bereits). Insgesamt halte ich das für die Komplexität erhöhendes Voodoo, das mehr Sicherheit verspricht, aber in der Summe nicht liefert.
Und dabei bzw. danach womöglich auch richtig zu drehen, was vor ein paar Tagen Thema war, ferner Thumbnails herzustellen und die Größe anpassen.
Das sollte definitiv ergänzt werden, vielleicht in einem anderen Artikel, der nur diese Thematiken abhandelt. Sonst wird es unübersichtlich.
Meintest du nicht mal, dass du gerade Zeit hättest?
Gruß
Julius
Ja. „Anerkannte Konventionen“. Aber auch die ändern sich. (Oder siezt Du Deinen Vater noch?)
Ansonsten habe ich das laue Gefühl, dass Du wohl im Hinblick auf das von mir notierte vermeinst, Dich irgendwie rechtfertigen zu müssen. GuteGüte (Zitat von meinem, längst verstorbenen Wellensittich): Das ist nicht der Fall und das wollte ich nicht zum Ausdruck bringen. Thesen:
Das ist kein Skript, sondern eine Einführung
Schon klar. Ich hab hier und heute so manches Mal sehr um die genaue Wortwahl gerungen und an der Stelle geschlampt.
Meintest du nicht mal, dass du gerade Zeit hättest?
Ja. „Anerkannte Konventionen“. Aber auch die ändern sich. (Oder siezt Du Deinen Vater noch?)
- In dem Punkt habe ich einen - genannten - guten Grund die erwähnte Konvention für „subotimal“ zu halten. Immerhin werden zahlreiche Konstanten in PHP von Erweiterungen gesetzt - Hier mal eine generierte Liste. Da will man (jedenfalls: ich) lieber keinen Konflikt riskieren.
Bei Kleinschreibung riskiert man, dass benutzerdefinierten Konstanten mit den globalen Funktionen kollidieren. Dadurch gewinnt man also nichts.
Für den vorliegenden Fall bietet sich das const-Schlüsselwort an. Dann werden die Konstanten auch im Gültigkeitsbereich des Namespaces angelegt.
namespace SelfHtml\Cookie;
const COOKIE_NAME = 'SELF_test';
Ich schließe mich im Übrigen dem Votum von Julius an, ich würde auch die PSR-Standards bevorzugen. Allerdings ist das auch eine zusätzliche Hürde für Wiki-Autoren, ich würde die Sache locker nehmen.
Hallo 1unitedpower,
Allerdings ist das auch eine zusätzliche Hürde für Wiki-Autoren, ich würde die Sache locker nehmen.
Genau, ich sehe es auch eher als „weiche Anforderung“, wenn jemand etwas sieht oder editiert, das nicht dem entspricht, kann er das ja anpassen und durch die Einigung auf Standards verhindert man, dass jeder das nach seinem Geschmack hin und her editiert (Mini-Editwar im SELFHTML-Wiki).
Gruß
Julius
(Mini-Editwar im SELFHTML-Wiki)
Naja. Mancher ist sauer, wenn man sein Werk verändert. Das ist ein einfacher Effekt. Man überlege wie wohl das negativ assoziierte Wort „Genauheimer“ in die deutsche Sprache kam und ob man sich selbst schon über eine(e) solche geärgert hat und ob man bei einer späteren Betrachtung die „blöde Genauheimerei“ als „gar nicht so schlimm“ oder so gar als „eigentlich begründet“ empfand.
Zumindest bei angemeldeten Benutzern oder solchen, die eine Mailadresse hinterlassen, könnte man wie folgt vorgehen:
Hallo XYZ!
Danke für Deinen Eintrag im selfhtml-wiki (URL ...), Du hast Dir damit viel Arbeit gemacht. Wir haben, zur Vereinheitlichung der Skripte, diese ein wenig an unsere Vorstellungen bezüglich einer einheitlichen Notation angepasst (welche Du unter der URL … findest). Das bedeutet nicht, dass wir Deine Arbeit für „schlecht“ halten sondern nur, dass unsere Skripte einem einheitlichen Notations-Stil folgen sollen, damit diese in ihrer Gesamtheit für die Leser noch leichter erfassbar sind. Wir bitten Dich nun darum, nunmehr die geänderten Beispiele als Ausgangsbasis zu nehmen, wenn Du an den Beispielen weitere Änderungen vornimmst.
Ich denke nämlich, dass, wenn eine solche, von vielen als negativ empfundene Handlung gut erklärt wird, die Akzeptanz steigt, Dann wäre da noch das gute, alte und hilfreiche Prinzip vom Bart und dem Honig.
Hallo Raketenwilli,
(Mini-Editwar im SELFHTML-Wiki)
Naja. Mancher ist sauer, wenn man sein Werk verändert.
Es ist ein Wiki, da ist das fehl am Platze. In erster Linie bezog sich meine Aussage auf den Stil und Vermeiden der Situation, das jeder denselben Code nach seinem Geschmack statt bestimmter Regeln editiert, da nehme ich mich nicht aus (obwohl ich größtenteils bereits intuitiv PSR-1 und PSR-12 folge).
Ich denke, dass man das nicht an die dermaßen große Glocke hängen muss. Primär dürften die PHP-Beiträge aus der Tastatur von fünf Leuten stammen und die formatieren das schon von der Intuition her (oder gar bewusst) nicht wie Kraut und Rüben. Sicherlich wird man das auch noch irgendwie beschließen und es an geeigneter Stelle dokumentieren müssen, aber ich denke nicht, dass man ein Standard-Text brauchen wird, Leute zurecht zu weisen.
Gruß
Julius
Ja „sixt“. Namespaces.
Gut, dass Du das zeigst, denn das fehlte bei meinen Vorschlägen ganz: (Ebenso wie in der von Juius genannten Konvention in Punkt 3 durch die Worte "Code written for PHP 5.3 and after MUST use formal namespaces." vorgesehen:) Die Verwendung von Namespaces mindestens empfehlen, damit beim Copy & Paste keine „Katastrophen“ auftreten. Für mein eigenes Zeug steht das auf der ToDo-Liste.
Apropo „ToDo“: (Obwohl das ja hoffentlich keine Konstante ist...)
Bei Kleinschreibung riskiert man, dass benutzerdefinierten Konstanten mit den globalen Funktionen kollidieren. Dadurch gewinnt man also nichts.
Genau deswegen habe ich mich darauf verlegt, bei eigenen Konstanten in meinem Zeug den ersten Buchstabe groß zu schreiben und statt dem Unterstrich als Wort-Verbinder (oder, beim Lesen: Wort-Trenner) CamelCase zu verwenden. Also 'SelfTest' statt 'SELF_TEST'. Das kann - in meinem Schema - nur mit eigenen Klassennamen kollidieren, die aber ganz anders verwendet werden als Konstanten.
Den Punkt 2.3. „Side Effects“ der PSR-1
A file SHOULD declare new symbols (classes, functions, constants, etc.) and cause no other side effects, or it SHOULD execute logic with side effects, but SHOULD NOT do both.
... würde ich im Wiki bei kleineren Beispielskripten nicht empfehlen wollen, weil das die Funktion oder Klasse und deren ad-hoc-Verwendung in den zugehörigen Demonstrationen „zerreisst“. Wir wissen zwar inzwischen aus den Fragen im Forum, dass manche Anfänger sich „aufregend große und schwierige“ Projekte aufladen. Aber dennoch finde ich, dass eine Aufteilung der kleineren Demo-Skripte meist nicht sinnvoll ist. (außer es geht z.b. genau darum, die Aufteilung zu zeigen) Bliebe man konsequent müsste man eigentlich auch jeden HTML-Part ein Template-File verlegen und da wäre im Endeffekt wohl zu viel auf einmal zu erklären - was den „Side Effect“ mit sich bringt, dass die Beginner bezüglich des Lernens „aussteigen“ und sich alsdann ihr Zeug nur noch zusammenkopieren. Was wir ja hier im Forum auch sehr genau sehen.
Apropo „Beginner“:
Wie wärs mit Festlegung und Anzeige eines Schwierigkeitsgrades?
(Habe das noch beim Schreiben selbst verworfen, weil sowas nach gemachten Erfahrungen mit Typen wie dem gewissen RaketenMeinerEinerSelbst (wohl, häufig) ignoriert wird oder sogar dazu führt, dass „Anfängerkram“ absichtlich übergangen wird.)
Hallo Raketenqualitätskontrolle,
Den Punkt 2.3. „Side Effects“ der PSR-1
A file SHOULD declare new symbols (classes, functions, constants, etc.) and cause no other side effects, or it SHOULD execute logic with side effects, but SHOULD NOT do both.
... würde ich im Wiki bei kleineren Beispielskripten nicht empfehlen wollen, weil das die Funktion oder Klasse und deren ad-hoc-Verwendung in den zugehörigen Demonstrationen „zerreisst“.
Das habe ich geflissentlich übersehen (mir ging es primär um den Code-Stil, das habe ich aber nicht erwähnt, mea culpa) und implizit angenommen, aber du hast recht, das sollte man betonen.
Wir wissen zwar inzwischen aus den Fragen im Forum, dass manche Anfänger sich „aufregend große und schwierige“ Projekte aufladen. Aber dennoch finde ich, dass eine Aufteilung der kleineren Demo-Skripte meist nicht sinnvoll ist. (außer es geht z.b. genau darum, die Aufteilung zu zeigen)
In einen Artikel zu gießen, wie man ein Projekt organisieren könnte (unter Rückgriff auf die PSRs) habe ich auch noch auf meiner privaten ToDo-Liste.
Apropo „Beginner“:
Wie wärs mit Festlegung und Anzeige eines Schwierigkeitsgrades?
Gibt es schon, siehe beispielsweise den neuen Artikel zum Webhosting. Klar, das kann ignoriert werden, aber immerhin kann so einheitlich das Niveau eines Artikels angegeben werden und Voraussetzungen benennen.
Gruß
Julius
mea culpa
Hallo Julius,
mitnichten ging es mir um Schuld („culpa“) noch eine Zuweisung („mea“). Es ging mir auch nicht darum, den Artikel zu kritisieren (im Sinne von „negativ bewerten“), sondern um die einheitlichere Notierung. Wegen der Außenwirkung und der Verständlichkeit.
In einen Artikel zu gießen, wie man ein Projekt organisieren könnte (unter Rückgriff auf die PSRs) habe ich auch noch auf meiner privaten ToDo-Liste.
Hm. (Als „volle Zustimmung“ gemeint.)
Der könnte für mich sehr interessant sein. Ich sehe mein Zeug immer als „klein“ an - und auf Grund der quasi stets nachfolgenden Eskalation hab ich dann den „Salat“ im Sinne von „keine gute Struktur“ und habe durchaus auch schon gesehen, dass Mängel in der Struktur dann zu Schwierigkeiten beim Debugging, Anpassungen oder Erweiterungen von meinem eigenen Zeug führten.
Hallo Raketenwilli,
Ja. „Anerkannte Konventionen“. Aber auch die ändern sich.
Klar, PSR-4 hat beispielsweise PSR-0 abgelöst. Da ist nichts in Stein gemeißelt und wird – wenn nötig – angefasst.
(Oder siezt Du Deinen Vater noch?)
Der Vergleich läuft noch nicht einmal: Das eine hat mit einer anderen, besseren und zu recht modernisierten Eltern-Kind-Beziehung zu tun, das andere mit einer der Einheitlichkeit zuliebe getroffenen Festlegung, damit man einen benannten Standard hat, auf den man sich einigen kann.
Ansonsten habe ich das laue Gefühl, dass Du wohl im Hinblick auf das von mir notierte vermeinst, Dich irgendwie rechtfertigen zu müssen.
Nein, ich habe getroffene Entscheidungen begründet.
Gruß
Julius
Hi @Julius,
hi @Matthias Scharwies,
schön zu lesen, dass PHP nun endlich offiziell einen Einzug in das Wiki haben soll. Und dass @Julius sich dafür stark macht, finde ich echt mutig.
Soweit ich das bisher mitverfolgt habe, gab es früher schon diverse kleinere und größere Artikel zum Thema PHP im Wiki. Wo sind die geblieben?
Mir ist dabei besonders sauer aufgestoßen, dass ein PHP-Beispiel gelöscht wurde, weil der darin enthaltene JavaScript-Anteil irgendjemand nicht gefallen hat.
Inzwischen finde ich überhaupt keinen von den Beiträgen mehr. Zwei davon fehlen mir besonders: die "Never-ending-Story" vom PHP-File-Upload und das Beispiel, in dem eine Anwendungsform von Closures auf einfache Art und Weise gezeigt wurde.
Der File-Upload-Plot war imho der meist aufgerufene Beitrag im Wiki bis die Aufrufzählung abgeschaltet wurde. Nun ist er eben auch nicht mehr erreichbar. Meinem (damaligen) Arbeitgeber und mir hat diese Wissenssammlung aber viel Kummer erspart, und dass sie vermutlich nie fertig werden würde, hat mich nie gestört. Ich weiß von einigen Kollegen in anderen Firmen, dass es ihnen ähnlich ging.
Ich persönlich habe mir irgendwann eine Print-Kopie davon gezogen. Schade nur, dass die nun nicht mehr weiterentwickelt wird. Es kommen doch immer wieder neue Aspekte hinzu.
Ich war bis vor Kurzem freier Mitarbeiter in einem Tourismus-Web-Projekt.
Gestern erfuhr ich, dass die Firma nicht mehr lebt (Insolvenz wg. Corona bei den Kunden). Das wird uns dann vermutlich am Montag offiziell mitgeteilt.
Jedenfalls fehlen meinem Desktop-PC nicht ein paar Kabel für die neuen Festplatten, sondern mein Gerät und meine neuen HDDs stecken jetzt in der Insolvenzmasse (unsere Technik wollte mir das richten wg. Homeoffice) und nun muss ich das Gerät und Zubehör herausklagen. Ergo: kein Geld, Arbeitsgerät weg (und da fragen irgendwelche Trottel, wieso ich irgendwelche Leistungen nicht fristgerecht erbringen kann).
So, genug gejammert.
Fazit für mich: solange es hier üblich ist, Denkansätze, Ideen, Never-ending-Articles im Wiki einfach so von der Platte zu putzen, anstatt sie zumindest in eine ÖFFENTLICH zugängliche experimental Area zu überführen, werde ich hier keind Wiki-Artikel schreiben und werde dies auch meinen Kollegen nicht empfehlen. Und im Forum werde ich mid auch eher zu den Mitlesern gesellen.
Dies auch als Antwort an @Matthias Apsel, warum "ich nicht kann".
Schade, Ihr wart mal führend!
Bis später irgendwann?
me-too
Servus!
Hi @Julius,
hi @Matthias Scharwies,schön zu lesen, dass PHP nun endlich offiziell einen Einzug in das Wiki haben soll. Und dass @Julius sich dafür stark macht, finde ich echt mutig.
Soweit ich das bisher mitverfolgt habe, gab es früher schon diverse kleinere und größere Artikel zum Thema PHP im Wiki. Wo sind die geblieben?
Wie im Blog-Artikel beschrieben, haben wir in einem ersten Schritt neue Inhalte veröffentlicht:
Im Blog-Artikel Wiki-Gardening wurde auch erwähnt, dass man in einem zweiten Schritt eben alle Artikel immer wieder durchgehen muss, da sich die Methoden, Versionen etc. dauernd verändern. Es hat keinen Sinn Artikel stehen zu lassen, die 2014 angefangen wurden und bis heute nur aus Überschriften bestanden.
Mir ist dabei besonders sauer aufgestoßen, dass ein PHP-Beispiel gelöscht wurde, weil der darin enthaltene JavaScript-Anteil irgendjemand nicht gefallen hat.
Meinst du den Zugriffszähler? Da gab es eine Diskussion im Forum mit dem Ergebnis, dass dieser mittlerweile veraltet sei. Der Autor schlug eine Löschung vor. Trotzdem ist er im Test-Wiki noch zu finden.
Inzwischen finde ich überhaupt keinen von den Beiträgen mehr. Zwei davon fehlen mir besonders: die "Never-ending-Story" vom PHP-File-Upload und das Beispiel, in dem eine Anwendungsform von Closures auf einfache Art und Weise gezeigt wurde.
Der File-Upload-Plot war imho der meist aufgerufene Beitrag im Wiki bis die Aufrufzählung abgeschaltet wurde. Nun ist er eben auch nicht mehr erreichbar.
Das stimmt nicht! Unter dieser URL PHP/Tutorials/File_Upload findet sich die neu überarbeitete Version von Julius, die er im April im Forum zur Diskussion gestellt hat: forum.selfhtml.org/self/2020/apr/13/wiki-dateiupload-mit-php
Ältere Versionen kannst du über die Versionsgeschichte einsehen!
Fazit für mich: solange es hier üblich ist, Denkansätze, Ideen, Never-ending-Articles im Wiki einfach so von der Platte zu putzen, anstatt sie zumindest in eine ÖFFENTLICH zugängliche experimental Area zu überführen, werde ich hier keind Wiki-Artikel schreiben und werde dies auch meinen Kollegen nicht empfehlen. Und im Forum werde ich mid auch eher zu den Mitlesern gesellen.
Herzliche Grüße
Matthias Scharwies
Hallo Matthias,
Wie im Blog-Artikel beschrieben, haben wir in einem ersten Schritt neue Inhalte veröffentlicht:
- ToDo-Liste mit PHP und SQL von @1unitedpower
- Abhängigkeiten_mit_Composer_verwalten (von @Julius ; sehr wichtig, da die meisten Projekte heute Bibliotheken, Applikationen wie z.B. den TinyMCE-Editor einbinden)
- Datenbanken_mit_PHP ansprechen (von Julius; wir hatten nie eine Einführung, wie man Datenbanken mit PHP auswertet, hier zeigt Julius wie man das mit PDO macht (ist aber noch nicht ganz fertig)
- PHP/Tutorials/Datenspeicherung (von Julius wie man Daten persistent speichert (JSON, CSV))
- PHP/Tutorials/Formulare mit PHP auswerten (von @Felix Riesterer)
- Reloadsperre (von @Matthias Apsel)
- Einführung_in_Symfony (von mir übersetzt, da CCN-BY)
Sollten wir vielleicht – auch um den Blog wiederzubeleben – vielleicht ab und an (etwa monatlich oder quartalsweise) veröffentlichen, was geschafft wurde? Das Ubuntuusers-Projekt macht das in ihrem Blog so. Weiter unten kann man dann ggf. noch die geplanten Projekte auflisten, wenn es da etwas Spruchreifes geben sollte. Dadurch erhielte der Blog eine sinnvolle Funktion.
Das große Problem beim Blog sehe ich darin, das so ziemlich alle Artikelideen, die ich habe, eher in einem Wiki-Artikel münden (sollten). Es bleiben einzig Beiträge zum aktuellen Geschehen oder Kommentare übrig, die passen thematisch nicht ins Wiki.
Ich denke ein Kommentar, warum die Kritik an PHP sich häufig auf Probleme bezieht, die entweder keine sind oder längst behoben sind, und eine Einführung in RSS-Feeds (angeregt durch diesen Thread) und inwiefern diese in Bezug auf Nachrichtenbeschaffung eine Alternative zu Sozialen Netzwerken sein können.
Das stimmt nicht! Unter dieser URL PHP/Tutorials/File_Upload findet sich die neu überarbeitete Version von Julius, die er im April im Forum zur Diskussion gestellt hat: forum.selfhtml.org/self/2020/apr/13/wiki-dateiupload-mit-php
Vor allem hat sich die URL nicht geändert (obwohl ich das eher als „Datei Upload“ bezeichnen würde, aber das wirkt mir etwas zu denglisch...). Der Artikel wurde sogar auf der PHP-Seite und der Startseite prominenter verlinkt. Er ist dadurch besser als zuvor zu finden.
Ältere Versionen kannst du über die Versionsgeschichte einsehen!
Allerdings ist auf der Seite mit der Versionsgeschichte noch ein weiterer Klick zu den gelöschten Versionen nötig. Das liegt daran, dass ich beim Verschieben nicht den Inhalt der neuen Version aus meinem Benutzernamensraum in die alte Seite kopiert habe, sondern die neue Version anstelle der alten platziert habe und dafür musste man die alte löschen. Fand ich im konkreten Fall sinnvoller, weil die neue Version mit der alten bis auf wenige Sätze in der Einleitung keine gemeinsame Vergangenheit hat.
Gruß
Julius
Servus!
Hallo Matthias,
Wie im Blog-Artikel beschrieben, haben wir in einem ersten Schritt neue Inhalte veröffentlicht:
Sollten wir vielleicht – auch um den Blog wiederzubeleben – vielleicht ab und an (etwa monatlich oder quartalsweise) veröffentlichen, was geschafft wurde? Das Ubuntuusers-Projekt macht das in ihrem Blog so. Weiter unten kann man dann ggf. noch die geplanten Projekte auflisten, wenn es da etwas Spruchreifes geben sollte. Dadurch erhielte der Blog eine sinnvolle Funktion.
Ja! Ja und Ja! @at hatte in Dortmund vorgeschlagen, die Landing Page (die vier Links sind eh in der Navigationsleiste vorhanden; das Missions Statement könnte man verlinken) durch den Blog zu ersetzen und dort Neuigkeiten zu posten.
Neuigkeiten wären eben …
Natürlich würde es eine teilweise Dopplung zum Forum sein. Andererseits sind das Nachrichten des Vereins und der Community und eben keine Fragen und Diskussionen.
Das große Problem beim Blog sehe ich darin, das so ziemlich alle Artikelideen, die ich habe, eher in einem Wiki-Artikel münden (sollten). Es bleiben einzig Beiträge zum aktuellen Geschehen oder Kommentare übrig, die passen thematisch nicht ins Wiki.
Genau!
Ich denke ein Kommentar, warum die Kritik an PHP sich häufig auf Probleme bezieht, die entweder keine sind oder längst behoben sind, und eine Einführung in RSS-Feeds (angeregt durch diesen Thread) und inwiefern diese in Bezug auf Nachrichtenbeschaffung eine Alternative zu Sozialen Netzwerken sein können.
Gutes Thema! Wann ist der Beitrag fertig! 😀
Herzliche Grüße
Matthias Scharwies
Hallo me-too,
schön zu lesen, dass PHP nun endlich offiziell einen Einzug in das Wiki haben soll.
PHP war schon in SELFHTML-aktuell vertreten und dann auch durch Übernahmen daraus und neue Artikel im Wiki. Ende 2018 haben @Matthias Scharwies und @Rolf B (ich hoffe, niemanden vergessen zu haben) dann die vorhandenen, verstreuten Artikel in die Rubrik PHP verschoben.
Ich persönlich habe mir irgendwann eine Print-Kopie davon gezogen. Schade nur, dass die nun nicht mehr weiterentwickelt wird.
Es ist ein Wiki. Du kannst dir problemlos den alten Stand vor meiner Überarbeitung des Datei-Upload-Artikels kopieren und bearbeiten. Die Doku, die von einem erlesenen Kreis gepflegt und an die man mit Wünschen und Forderungen herantreten kann, ist lange tot (etwa seit 2007, weil danach das Projekt in einen Dornröschenschlaf fiel, bis das Wiki als Nachfolger auserkoren wurde).
Das Problem war, dass ein als Tutorial behandelter Artikel viel zu lang (er war unter den TOP-3 der längsten Artikel) und unfertig war. Ein Tutorial soll einen Einsteiger an die Hand nehmen und ihm einen Einblick in eine Thematik geben, das tut die neue Version im Gegensatz zur alten, was nicht heißt, dass sie perfekt oder fertig wäre. Ein Kompendium ist etwas anderes als ein Tutorial.
Es gibt nur ein paar Dinge, die ich verhindern will und werde: Dass dieser Artikel wieder eine unbenutzbare Baustelle wird, zu unübersichtlich wird oder der rote Faden verloren geht. Erweiterte Aspekte zu dem Thema können gerne in separate Artikel gegossen werden und diese können durch Links aufeinander verweisen.
Es gibt verschiedene Ansätze, ein Wiki zu pflegen, wie Matthias schon mit dem Schlagwort „Gardening“ beschrieb. Du kannst einen Garten wild wuchern lassen (unfertige Artikel, Verweise auf noch zu schreibende Artikel), ihn perfekt unter Kontrolle haben oder ein Zwischending aus beidem. So weit ich das SELFHTML-Wiki verstehe, soll sich dem Nutzer des Wikis größtenteils ein gut gepflegter Garten darstellen, aber dennoch nicht um jeden Preis verborgen werden, dass es immer Baustellen gibt. Nur sollte halt vermieden werden, dass Nutzer auf einen interessant klingenden Link klicken und dahinter auf eine Überschriften-Wüste treffen, die mehr verspricht als sie liefert.
Fazit für mich: solange es hier üblich ist, Denkansätze, Ideen, Never-ending-Articles im Wiki einfach so von der Platte zu putzen, anstatt sie zumindest in eine ÖFFENTLICH zugängliche experimental Area zu überführen, werde ich hier keind Wiki-Artikel schreiben und werde dies auch meinen Kollegen nicht empfehlen.
„einfach so“ wird nichts „von der Platte“ geputzt. Der Upload-Artikel siechte seit Jahren vor sich hin. Es gibt einen öffentlich zugänglichen Bereich für Experimente: Den Nutzernamensraum.
Dies auch als Antwort an @Matthias Apsel, warum "ich nicht kann".
Schade, Ihr wart mal führend!
Da kommt sie wieder durch, die Erwartungshaltung: Wir – ihr.
Es ist ein Wiki. Du kannst mit zwei Klicks dabei sein, aber stehst lieber abseits und meckerst über Dinge, die du in der Hand hast oder für die es Lösungen gibt.
Gruß
Julius
Hallo me-too,
@Rakete.* hat in mehreren Beiträgen versucht, hier eine Rechtsberatung unterzubringen. Vielleicht nimmst du auf anderem Weg Kontakt zu ihm auf. Die Informationen können für dich bestimmt hilfreich sein.
Bis demnächst
Matthias
Falls Du Bedenken im Hinblick auf die Wahrung Deiner Anonymität hast:
Noch nie habe ich das getan und nie werde ich - auch nicht im bittersten Streit - mir als „Geheimnisse“ anvertraute oder mir anvertraute und von mir selbst als „potentielle Geheimnisse“ oder auch nur als „potentiell peinlich“ klassifizierte Umstände nutzen oder verbreiten. (Punkt!)
Hallo Jörg aka Rakete.*,
ich habe jetzt 2x einen Teilthread mit deinen Beiträgen gelöscht.
Nicht, weil ich etwas persönlich gegen dich habe, sondern weil das Forum und besonders der Verein nicht den Eindruck erwecken kann, Rechtsberatung zu leisten und nicht wegen "Unsinn" - wie du es in einem der gelöschten Beiträge deutest.
Dass Du Deine Privatmeinung darstellst, ist nicht jedem Forenleser ersichtlich. Im Gegenteil, wer das Forum zufällig aufsucht und die Menge an Raketenbeiträgen liest, erkennt den Stammposter und hält einen Beitrag zu Rechtsthemen, der stehenblieb, möglicherweise für belastbare Rechtsberatung. Und das ist der Löschgrund. Nicht der Inhalt.
Herzliche Grüße
Matthias Scharwies
Und das ist der Löschgrund. Nicht der Inhalt.
Nur leider kann man den bei der konstanten Angabe von „rechtlich bedenklich“ nicht davon unterscheiden, ob befürchtet wird, dass sich womöglich der besonders beispielhafte Herr E. aus I. am B. durch die Wortwahl oder durch einen angeblich „unwahren“ Tatsachenvortrag als „zur Leberwurst gemacht“ ansieht. Es kommt nicht auf die beabsichtigte, sondern auf die tatsächliche Wirkung an.
Ich kann Dir versichern: Der PHP-Wert in meinen Adern sank auf einen Größe bei dem zwar der Corona-Virus zuverlässig „gekillt“ aber leider auch erhebliche Sachwerte vernichtet werden. (Und was war das eigentlich für ein Text mit dem "Du bist freiwillig hier…"?)
Ob das sorgfältig zusammengetragene und dann doch gelöschte Textwerk jetzt eine „Rechtsdienstleistung“ i.S. von §2 RDG war will ich nicht diskutieren. Für mich würde ich das schon im Hinblick auf die bewusst gewählte Selbstbezeichnung als Rechtslaie verneinen - aber spezielle, „bekannte“ Landgerichte haben dazu halt „spezielle“ Meinungen. Ich erwähne das, weil ich mit einem solchen Löschgrund kein Problem gehabt hätte.
Lösung: Einfach angeben.