Dass die version.nfo für den Updatecheck da ist, das ist mir schon klar, der Zusammenhang jetzt zum Repo war mir nicht mehr in Erinnerung.cmb wrote: ↑Sun Feb 03, 2019 1:30 pmversion.nfo ist für den Update-Check wichtig. In einer perfekten Welt würde man beide Dateien kombinieren, aber die Welt ist nicht perfekt, und zumindest für jetzt kann wohl jeder damit leben, dass es eben zwei Dateien mit ein paar überlappenden Information gibt.
Ich glaube, hier stehe ich immer noch auf dem Schlauch.cmb wrote: ↑Sun Feb 03, 2019 1:30 pmmanu hat geschrieben: ↑02 Feb 2019 14:26
Müsste im xml file nicht auch die URL des xml files beim Entwickler drinstehen. Das will ja in Zukunfts per cron job abgerufen werden.
Sicher eine Möglichkeit. Es kann zumindest fürs erste aber auch einfach so sein, dass ein Entwickler die URL des XML-Dokuments manuell bei Olaf einreicht (und ggf. Änderungen der URL ebenso mitteilt). Gut wäre es vermutlich, wenn das nicht bei jedem 4,5ten Post in diesem Thread passiert, sondern irgendwo eine „Sammelstelle“ eingerichtet würde.
Christoph hat Recht. Deshalb kann man deine Datei auch nicht fehlerfrei im Browser aufrufen.frase wrote: ↑Sun Feb 03, 2019 2:10 pmcmb hat geschrieben: ↑03 Feb 2019 14:30
Das Problem ist nicht das =, sondern das &. Das müsste als Entity-Referenz geschrieben werden, also & – andernfalls denkt der XML-Parser, dass &t eine eigene angefangene Entity-Referenz sei, die aber nicht mit ; abgeschlossen wurde
Olaf hat offensichtlich eine Lösung gefunden, denn ich habe jetzt als Adress drinstehen:
https://www.cmsimpleforum.com/viewtopic ... 332#p66867
Also mit &.
Ich schreibe es nachträglich einfach um.
Ja, das wäre für den Fall also egal.
Das wäre vom Grundsatz schon ideal, unbestritten.frase wrote: ↑Sun Feb 03, 2019 2:10 pmIdeal wäre es, wenn ein Entwickler gleich dort, wo das Repo gehostet ist, ein Formular vorfindet. Er könnte dort online seine XML-Datei anlegen und/oder ändern. Die XML-Datei müsste ebenfalls dort liegen (und vielleicht auch gleich der Download?).
Dazu müsste bei Erstanlage ein Passwort für das jeweilige Plugin oder Template vergeben werden.
Der Admin prüft bei Erstanlage die ganze Chose und gibt sie dann fürs Repo frei. Mit dem Passwort kann der Entwickler Änderungen vornehmen.
Aber ja, ich weiß, dass das nahezu unmöglich ist.
Man muss eben damit leben, dass man zwei Dateien pflegen muss. Fraglich, ob sich das alles durchsetzt.
Schön wäre es schon.
Aber mir ist das zu aufwendig. Da muss ich leider passen.
Ausserdem könnte man sich dann das Ganze Theater mit der xml sparen und die Eingaben direkt als csv, oder besser noch sqlite speichern. Der Umweg die einzelnen xml's auszulesen wäre so nicht nötig.
Ich finde den Aufwand, die xml-Datei auszufüllen, wenn im Moment auch etwas puristisch, nicht unbedingt grösser, als mich anzumelden, einzuloggen und es online auszufüllen. Der Aufwand für Screenshots oder Logo bleibt unverändert.
imagesavealpha(), imagepalettetotruecolor(), imagetruecolortopalette() sehe ich mir bei Gelegenheit an.frase wrote: ↑Sun Feb 03, 2019 2:10 pmSiehe imagesavealpha() (Schlamperei! Diese Seite ist nicht auf Deutsch verfügbar!) Vermutlich wäre es bei Paletten-Bildern auch sinnvoll, diese vor dem Verkleinern durch imagepalettetotruecolor() zu jagen, und vor dem Speichern durch imagetruecolortopalette(). Oder, falls die Bilder von der Größe einigermaßen passen, das einfach den Browser machen zu lassen (<img with="100" height="100">, oder per CSS).
Da wäre ich eher dafür, einfach die originalen angeboten Bilder zu verwenden - unbearbeitet.
Per CSS in den vorhandenen Platz "zwingen" (max-width ...)
Ansonsten, wie schon geschrieben, wenn die Bilder der eingestellten Grösse entsprechen, müsste es funktionieren.
Eben so lange, bis sich die Einstellung vielleicht mal ändert.