staging.inyokaproject.org

Hallo Admins.

Das ist mir nun wirklich sehr peinlich, aber dieser Artikel müsste bitte auch komplett gelöscht werden. Mir war nicht klar, das auch Entwürfe gleich in der Baustelle gespeichert werden. Bitte löschen, ich schreibe den Artikel unter einem anderen (den richtigen!) Namen neu und stelle ihn dann ein. Ich bitte um Entschuldigung. Danke.

Hallo,

??? - wo soll es denn sonst gespeichert werden?

Grundsätzlich können wir (=das Wikiteam) nach belieben umbenennen. Welchen Namen hättest du den gerne?

Gruß, noisefloor

Okay, prima. Dann bitte ich freundlichst um Umbenennung in:

PHP/Composer - mit s, nicht mit z.

Merci! ☺

Hallo,

done.

Gruß, noisefloor

Vielen Dank @noisefloor!

@All:

Ein erster Entwurf steht nun bereit. Ich bitte um Feedback und Verbesserungsvorschläge. Danke.

Außerdem:

Da ich noch ein wenig unsicher mit der Inyoka-Syntax bin, weiß ich nicht genau, wie man Ausgaben vom Terminal formatiert. Ich habe jetzt auch hierfür

{{{#!vorlage Befehl
 ...

benutzt. Richtig?

Danke und Gruß M.

mubuntuHH schrieb:

wie man Ausgaben vom Terminal formatiert.

▶ Wiki/Syntax (Abschnitt „Code-einfuegen“)

Gruß Billmaier

Danke, @BillMaier

Ich werde das ändern, möchte aber erst mal sammeln ...und hoffe, dass ich noch thematisches Feedback bzw. ein Okay bekomme...

LG M.

Hallo @mubuntuHH,

ich habe den Entwurf mal mit 16.04 durchgearbeitet, damit das passende Getestet-Flag auch hierfür gesetzt werden kann. ☺

Da Composer bereits in den Paketquellen von 16.04 enthalten ist und der Support für ältere Ubuntu-Versionen hier gem. Richtlinie nicht existiert, könnte der Abschnitt zur manuellen Installation entfallen. Sollte er drin bleiben, habe ich speziell dazu ein paar Anmerkungen.

Für die manuelle Installation ist nur das Paket php-cli notwendig. Anstelle von cURL kann das bereits in der Grundinstallation von Ubuntu vorhandene wget verwendet werden. Die anderen Pakete sind früher oder später bestimmt nützlich, aber von Fall zu Fall unterschiedlich (ich brauche kein git, wenn ich nur Mercurial-Repos bearbeite). Ein vergleichbarer wget-Befehl wäre beispielsweise

wget -qO composer-setup.php https://getcomposer.org/installer 

Zusätzlich dazu bietet sich aus meiner Sicht auch hier die Verwendung der Paketinstallation-Vorlage an.

Im Abschnitt zur Verifizierung sollte klar erwähnt werden, dass dieses Code-Snippet bei negativer Verifizierung automatisch die überprüfte Datei löscht. Der Hinweis, dass man dann nicht weitermachen sollte, ist hier nicht sinnvoll, da ich gar nicht weitermachen kann. Meine persönliche Meinung ist, dass die Verifikation nur verifizieren sollte und nicht löschen.

Am Ende findet sich eine leere Hinweis-Box.

Gefundene Typos: Compser, miitels

kurze Notiz (fürs Wikiteam): Artikel sollte zusammen mit Baustelle/Zend-Framework ins Wiki, damit es keine Deadlinks gibt.

Hallo mubuntuHH,

habe den Artikel gegengelesen und ein paar Typos korrigiert. Ein paar ! habe ich auch noch entfernt, das wirkte etwas zu werberisch. Aber alles Kleinigkeiten. Vielen Dank für den Artikel - auch dieser liest sich sehr schlüssig und klar.

Ein paar Anmerkungen habe ich noch:

1. Die Kursivschreibung (in der Einleitung) nutzen wir im Wiki nicht für Hervorhebungen.

2. Das 'systemweite' installieren im Gegensatz zum 'einzelnen Projekt' wird in der Einleitung noch nicht klar, wenn man das Prinzip nicht kennt. Unten wird es ja dann erklärt. Das ist ok so - vielleicht kann man oben noch ergänzen, dass die Pakete im Unterverzeichnis zum jeweiligen Projekt liegen. Wäre aber Kür.

3. Die Paketinstallatinsvorlage inmitten des Satzes liest sich etwas unglücklich. Kannst du das bitte noch anpassen? Also den Satz am besten vor der Vorlage fertig machen.

4. Die Abhängigkeiten der manuellen Installation sollte m.E. noch in eine Paketinstallationsvorlage.

Eclipse mit PDT:

Die GUI, die dann einer übersichtlichen Anordnung mehrere Reiter hat

Bitte noch korrigieren, ich weiß nicht was du eigentlich schreiben wolltest ☺

Composercat (Leerer Hinweiskasten)

Ps. Hab Cranvils Kommentar jetzt erst gesehen, kann sein dass sich was doppelt.

Gruß BillMaier

Cranvil schrieb:

Gefundene Typos: Compser, miitels

Sowas darf jederzeit gerne und ohne Nachfrage direkt korrigiert werden - sowohl in "echten" Artikeln als auch in der Baustelle, erst recht wenn der Bearbeiter zu erkennen gibt, dass er erstmal durch ist.

Gruß BillMaier

Vielen Dank, Cranvil, dass Du Dir die Mühe gemacht hast, alles unter 16.04 zu testen.

Und Danke an BillMaier für Deine Anmerkungen.

Mit so einem Feedback macht es Spaß, hier zu mitarbeiten! ☺

Ich werde das alles in Kürze umsetzen und im Artikel verarbeiten.

LG M.

So, ich habe jetzt den Artikel noch mal umfangreich überarbeitet und ergänzt, u. a. um eine tabellarische Befehls-Übersicht. Habe auch weitestgehend Eure Vorschläge umgesetzt.

Cranvil schrieb:

Im Abschnitt zur Verifizierung sollte klar erwähnt werden, dass dieses Code-Snippet bei negativer Verifizierung automatisch die überprüfte Datei löscht. Der Hinweis, dass man dann nicht weitermachen sollte, ist hier nicht sinnvoll, da ich gar nicht weitermachen kann. Meine persönliche Meinung ist, dass die Verifikation nur verifizieren sollte und nicht löschen.

Hab's etwas klarer formuliert; das Auto-Löschen aber im Einzeiler gelassen, wegen Sicherheitsriskio. Ist auch die offizielle Empfehlung.

Ich glaube, so langsam könnten wir ans scharf schalten denken, nicht wahr? 😎

BillMaier schrieb:

kurze Notiz (fürs Wikiteam): Artikel sollte zusammen mit Baustelle/Zend-Framework ins Wiki, damit es keine Deadlinks gibt.

Aus meiner Sicht ist der Artikel sonst Wiki-reif.

Gruß BillMaier

BillMaier schrieb:

BillMaier schrieb:

kurze Notiz (fürs Wikiteam): Artikel sollte zusammen mit Baustelle/Zend-Framework ins Wiki, damit es keine Deadlinks gibt.

Aus meiner Sicht ist der Artikel sonst Wiki-reif.

+1

Vielleicht sollte ich mit dem Live-Schalten warten, bis ich auch mit Baustelle/Zend-Framework fertig bin? Wegen der ganzen Links dorthin? Bin dort auch fast fertig, vielleicht noch ein paar Tage.