Avatar

a planned features for mlf 2.4, eine Bitte an @Milo (Project organisation)

by Auge ⌂, Monday, October 10, 2016, 12:55 (2743 days ago) @ Micha

Hallo Milo

Kann ich GitHub so konfigurieren, dass bestimme Files nicht überwacht werden wie bspw. die config-Files mit sensiblen Daten?

Ja, du kannst in einer Datei namens .gitignore den Pfad relativ zur .gitignore notieren. Ein mMn gutes Beispiel ist im Ubuntuusers.de-Wiki zu finden. Die Datei berücksichtigt alle Verzeichnisse unterhalb seines eigenen Verzeichnisses. Githubs Hilfe zu .gitignore ist ein guter Startpunkt für weitere Infos.

Achtung: Sind für die fraglichen Dateien schon Commits erfolgt, sind diese weiterhin Bestandteil des Repos!

Stopforum-Spam wird abgefragt, ja. Aber ich konnte den Code nicht so modifizieren, dass er auch den Feed von GitHub ausliest. Das werde ich auch nie können, da HTTPS nicht von meinem Provider unterstützt wird:

Sag' niemals nie. Wenn mehrere Kunden Bedarf haben, wird sich dein Hoster einer Änderung vermutlich nicht verschließen können.

Ich werde sowohl den Weg über fsockopen probieren als auch weitere Recherchen über die zu setzenden Parameter für curl anstellen.


Sollte curl gehen, wäre das schön. Mit fsockopen kommst Du bei mir nicht weit, siehe oben. Insgesamt ist es problematisch, da wie nie wissen, was der Endanwender zur Verfügung hat.

Ich habe mit eeiner Funktion, die die Rohdaten begonnen. Wenn irgendwas nicht funktioniert, fällt als Rückgabewert FALSE aus der Funktion raus. Darauf können wir mit einer Rückfallausgabe reagieren und z.B. den Link zum aktuellen Release mit der Bitte, dort regelmäßig nachzuschauen, anzeigen. Der wird von Github entsprechend behandelt und umgeleitet.

Den Weg über die Betas sollten wir zukünftig überdenken! Ein User, der die erste Beta installiert hat, wie die zweite Beta oder das Final nicht mehr über die Updatefunktion einspielen können, wenn sich die Version nicht ändert.

Warum nicht?

Ich würde gar nicht so viel in Versionen denken. Wenn etwas fertig ist, kommt es in den Master und ist im nächsten Release dabei. Ich erkenne keinen Vorteil darin, etwas fertiges dem User vorzuenthalten nur weil es für eine andere Version geplannt war.

Ich würde schon gerne zwischen Bugfixes für bestehenden Code und neuen Features, die z.B. neue DB-Tabellen oder DB-Tabellen-Felder einführen oder relevante Änderungen am Template-Code erfordern und somit Inkompatibilitäten erzeugen, unterscheiden wollen.

Ich habe das PR … zum Anlasse genommen, um etwas aufzuräumen im Update-Script. Für die Bookmarks habe ich eine neue Tabelle hinzugefügt in der DB.

Nachdem die 2.3.7 jetzt raus ist [1], schaue ich mir das mal an.

Mir ist nicht ganz klar, wie diese durch das Updatescript dann in die config-Datei kommt. Ich habe es mal als Kommentar hingeschrieben aber das ist keine schöne Lösung und spätestens bei der Nachfolgeversion unglückliche. Hier hast Du sicher noch was besseres auf Lager. ;-)

Solche Änderungen gabe es doch schon ein paar Mal‽ Es ist ja nicht das erste Mal, dass neue Tabellen hinzukamen. Da sollte sich Beispielcode finden lassen. Wenn nicht, habe ich vergleichbares im 1-er Code.

Tschö, Auge

[1] Ich hoffe, ich habe nichts vergessen, nachdem ich den Tag dreimal erzeugt und nach den ersten zwei Malen festgestellt hatte, etwas vergessen zu haben.

--
Trenne niemals Müll, denn er hat nur eine Silbe!

locked
56591 views

Complete thread:

 RSS Feed of thread